しがないプログラマの雑記帳

冴えないおじさんの、備忘録な雑記

Developers Summit 2024 Kansai に参加してきました

2024/9/18 に開催された、 Developers Summit 2024 Kansai (通称: デブサミ) に参加してきました。
初めてデブサミに参加しました。

この記事では、聴講したセッションについて、簡単に内容と感想を書きます。

聴講したセッション

コンピュータ技術とサイバーセキュリティにおける日本の課題、人材育成法および将来展望

著名人である、登 大遊 氏の「けしからん」発表を聞いてきました。

概要

日本の課題として、 IT 人材が育っていないことが課題の 1つとして発表内で取り上げられていました。
かつては、 IT 技術に興味のある人たちが、個人的に技術で遊んでみて学ぶという、自然的発生で IT 技術が出来上がってきたが、 現在はシステムが複雑になってきて、個人では難しくなってきたと述べられていました。
そのため、 自然的発生から、組織内での人材育成にシフトが必要 とのことでした。

感想

個人的には、「遊び」で使えるリソースを提供してくれる組織があったら、すごく魅力的だなと感じました。

一方で、以下の 2つが課題になりそうだなと思いました。

  • 組織自体に人材育成のためのコストを払えるだけの余裕が必要そう
  • 自然発生的に技術で遊ぶような人材の発掘が難しそう

「日本」という国単位で見たら、ある程度大きな組織を前提としているのかもしれないですね。

APIファースト、そしてTime To First Call削減への道筋

概要

前半では API ファーストについて、後半では Time To First Call について説明されていました。

API ファースト では、 API をプロダクトとして考え、ビジネスにもたらす価値に焦点を当てるという考え方と述べられていました。
開発の視点では、API の設計に焦点が当たるとのことでした。

Time To First Call (TTFC) とは、いかに短時間でAPI の初回呼び出しができるかというメトリクスと述べられていました。
API 提供者は TTFC を分析して、 API やドキュメントなどを改善するとのことでした。

感想

API ファーストの考え方は、 TDD と通ずる考え方だと感じました。
コードを書く前に API の入出力を定義すれば、その APIユニットテストもあらかじめ実装できるようになります。
また、テストを書くことで、ユースケースも明確にできると思いました。

TTFC というメトリクスは初めて知りました。
今回のセッションだけでは理解がしきれなかったので、未来の私に託すことにします (笑)

もう苦労しない!事例から学ぶ認証基盤開発のベストプラクティスとは?

概要

セッションの前半では認証基盤について、以下の 3つの課題について述べられていました。

  1. 認証基盤のサイロ化
    • 開発したサービスごとに認証の仕組みが異なり、認証基盤の共通化が困難になってしまう
  2. 属人的なメンテナンス
    • 認証の仕組みがサービスごとに異なることで、メンテナンスも開発者に属人化してしまう
  3. 複雑な認証トレンドへの追随

後半では、Auth0 で認証基盤を統合した事例について説明されていました。
IDaaS の導入側が考慮すべき点について述べられていました。

感想

セッションの最初の方で、 ID とパスワードによる認証がマストであるのが 5~10 年くらい変わらないと述べられていたのは少し驚きました。
パスワードレスやソーシャルログインなども出てきたとはいえ、 ID とパスワードによる認証もまだまだ現役なんだなと感じました。

後半は Auth0 の導入例についてでしたが、 Auth0 はほぼ触ったことがないので、今後少しずつ触ってみたいと思います。

シリコンバレー流ソフトウェア開発術

概要

セッションの冒頭で、 「正しいソフトウェア開発」は存在しない と述べられていました。
良い開発手法は常に変化するものであり、その時は最適解でも、その後も最適とは限らないとのことでした。

また、開発手法について、名前をつけることよりも開発メンバーと文化の方が重要であると述べられていました。

ソフトウェア開発のスキルについては、アプリケーションを作成するためのスキルだけではなく、 アルゴリズムやコンピュータアーキテクチャなど、基礎的なスキルも重要であると述べられていました。

感想

ソフトウェア開発のスキルについて、基礎的なスキルも重要という内容に、内心で頷きながら聴講していました。
基礎的なスキルがどの程度習得できているかを測る意味合いでも、基本情報技術者試験応用情報技術者試験は有用だと思います。

大阪大学フルスタックで研究開発!量子コンピュータクラウド化を支えるDevOpsの取り組み

概要

最初に、量子コンピュータを実現する量子ビットについての基礎知識が説明されていました。
その後、量子コンピュータクラウド化について、システム構成やクラウド化を実現するための技術などについて述べられていました。

感想

興味本位で聴講しましたが、量子コンピュータについての基礎知識が足りなくて、ほとんどついていけませんでした...
ただ、量子コンピュータクラウド化が実現されれば、量子コンピュータがもう少し身近になるのかなと思いました。

Gmailの新ガイドラインでエンジニアが知っておくべき、これからの「メール配信」のあり方- “適切に届ける”ためのベストプラクティスを探る-

概要

Gmail が送信者向けのガイドラインを更新しましたが、その意義について説明されていました。
メール配信の歴史を背景に、 受信者にとって快適な受信トレイの実現 が重要であることが述べられていました。

また、 DMARC の対応だけでは不十分である可能性についても示唆されていました。
他にも、 hard bounce に対しては速く対応することも重要であると述べられていました。

感想

メール配信の技術には、ほとんど携わったことがなかったので、 Gmailガイドラインの更新についての概要や、 DMARC がどのようなものかの概要を把握できました。
DMARC だけでなく、 SPF, DKIM についてもちゃんと学んでおきたいと思いました。

マネジメントor技術は二者択一?「中途半端」なエンジニアの生存戦略

概要

登壇者が所属されている 株式会社スマレジ が大事にしてきた開発の価値観として、次のことを重要にしてきたとのことでした。

  • 生涯現役
  • エンジニアはビジネスマン
  • 要件定義ではなく要求定義

前半では上記の価値観について説明され、後半ではスマレジへの転職の前後の体験談について話されていました。

感想

「ビジネスのわかるエンジニア」になることができれば、エンジニアとして生き残っていくのに非常に有利になりそうだと思いました。
ただ、そこに辿り着くまでの道のりはとても険しそうだなと感じました。

私は技術を触っていきたいと思っているのに加えて、マネジメントについて食わず嫌いで苦手意識がありました。
今回の発表を聞いて、苦手意識が解消したわけではありませんが、マネジメントについても経験して、 ビジネスサイドの考え方もある程度把握できるようになれたらいいなと思いました。

デブサミ2024関西コミュニティLT

関西で活動している各コミュニティについての紹介 LT でした。

参加したことのあるコミュニティもあれば、初めて名前を聞くコミュニティもありました。
今回の LT で紹介されたコミュニティ以外にもコミュニティが存在していることを考えると、関西も IT 技術のコミュニティは決して少なくはないのかなと思いました。

そのほか

朝起きるのがしんどくて二度寝したら、家を出る時間が結構ギリギリになってしまいました... 😅
なんとか最初のセッションに間に合って良かったです。

参加証も行きしなにコンビニで印刷してきましたが、やっぱり前日にしておくべきだったなと思いました。
本当は、前日に買い物に行った時に、ついでに印刷するつもりだったけれど、完全に忘れていました。
もう一度外に出るのが面倒だったので、当日行きしなに印刷しようと後回しにしたのも仇となりました。

教訓: 準備は早めに

現地で受付後、A4 の参加証を 4つ折りにして表面が氏名、裏面がタイムテーブルになる仕掛けになっていることに感動しました。

スポンサーブースでは、運よく 2つ当たりクジを引き当てて、ノベルティをもらえました ✌️

まとめ

  • たくさんセッションを聴講した
  • 事前準備は後回しにしたらダメだと改めて学んだ
    • いい加減ちゃんとできるようにしたい
  • スポンサーブースのくじ運が良かった

短めに書くつもりが、思ったより長くなりました... 😅