Developers Summit 2024に参加

ベルサール羽田空港で開催された『Developers Summit 2024』(2024/2/15~16)に両日参加しました！

講演資料はこちらにまとまっています。

Developers Summit 2024 公開資料・Xアカウントリンクまとめ

また「Developers Summit 2024 参加」で検索すると、いろいろなまとめや参加記などがあり楽しめると思います。

参加したセッションはこちらです！

2/15

• 15-A-2 AI時代のDevOpsエンジニアのスキルアップに役立つ3つのポイント
• 15-A-3 エンジニアの成長とそれを支える組織の考え方
• 15-A-4 生成AIを本気で推進するトップランナーが語る！AIの展望2024年とその先
• 15-C-5 マイナビの全社データ基盤のモダナイズ
• 15-A-6 アーキテクチャから学ぶKubernetesの全体像
• 15-D-7 7年間1000件の障害事例からわかった、障害対応の改善ポイント～協同で変えるシステム障害対応とは？～
• 15-D-8 “持続可能な”開発を実現するためにスタートアップで実践したこと
• 15-D-9 Platform Engineeringことはじめ～コミュニティと一緒に新たな旅に出よう！

2/16

• 16-A-1 Flight of a Decade:10年間の旅路と再会
• 16-D-2 データブリックスエンジニアが語るデータ・AI基盤の現在地とこれから
• 16-D-3 Elasticが目指す生成AI 活用の将来像
• 16-A-4 GitHub Copilotは開発者の生産性をどれだけ上げるのか？ ZOZOでの全社導入とその効果
• 16-A-5 SIerな会社の中でXR(VR・メタバース）を用いた新規事業開発に挑戦して見えてきた景色
• 16-A-6 マーケットインアプローチで挑む新規プロダクトの立ち上げ
• 16-E-7 良いプロダクト作りのための組織育成（理論＆実践編） 健全なコードは健全な組織、健全なチームから
• 16-B-8 ビジネスドメインの拡大を実現するバクラクシリーズでのモノレポ開発
• 16-E-9 オフラインカンファレンス復活！イベント現地参加の魅力を語りつくすリレーセッション

さらにデブサミ2024 懇親会 にも参加しました！

出発

4年ぶり人生2往復目の飛行機で、ボーイング737-800 に乗りました。 当日カウンターで座席指定すると搭乗率はかなり高めだったと思いますが横一列は私だけ、窓からは視界中央に猫がいて視力の弱い私には現場猫にしか見えず、独特な状況が面白かったです。

羽田空港第１ターミナルに着陸後、第３ターミナルへ連絡バスで移動し、羽田エアポートガーデンへ。 羽田空港大きい！そして綺麗で、ワクワクしました。 会場に着くとたくさんの人が並んでいたりスタッフの方も多かったりして、コロナ明けの人が集まれる状況、そして似たような興味をともにした人たちが集まって真剣に参加している様子は楽しいですね！

セッション

ノートとシャープペンシルを手に持って参加しました。 メモを見ながら、自分なりに解釈した内容や重要だと思った点を中心に振り返ろうと思います。

あくまで私の言葉で書いたものなので、発表内容とは異なることをご了承ください。

15-A-2 AI時代のDevOpsエンジニアのスキルアップに役立つ3つのポイント

これから30～40年でも役立つものは何かを考えるために、過去30～40年がどう変わってきたのかを振り返ってみる。

昔は家にコンピュータがなく、オフィスに巨大コンピュータが存在している状況。 いまはDXの需要が拡大し、要求仕様からコードを生成するのはAIが生成できるようになってきた。 新たな開発手法（DevOpsなど）やツールは旬のテクノロジー。

エンジニアの基盤となる技術は存在し、

• 全体俯瞰
• ビジネス思考
• コミュニケーション

が普遍的で、エンジニアとしての差別化材料で、AIによる代替はすぐにはできない。

オブザーバビリティが重要で、それと反対なのは「監視」（固定された対象、個別の警告しきい値、影響や原因対策は人間が判断）。

DataDogは上記3つのことができる。

Datadog Learning Centerでハンズオン形式で学べて、評価環境はリセットされるが何度も試せる。

15-A-3 エンジニアの成長とそれを支える組織の考え方

すごい人

• 俯瞰的な視点
  • コードレビュー
• 圧倒的なスピード
  • 昨日でたアイデアがもう仮実装されている
  • 中途半端を恐れず、評価のためだけにやっているのではない
• 本質的な理解
  • 既存の一般的な圧縮アルゴリズムを使っていてデータ転送などに課題があったが、実際に使用する場面にて最善の圧縮アルゴリズムを自作することで圧縮率を飛躍的に高めた

ToBeを知っていて、さらに現実も知っている。

• ITコンサルタント
• アーキテクト
• スペシャリスト

で習熟度が違うが、互いに会話が必要であり、融通や理解が必要。

AIの進化で生産性が向上する。

技術の理解では「ダニング＝クルーガー効果」が起きやすい。

ライブラリは簡単に使えるが、そのライブラリが何をやっているのか調べると技術が広がっている。 「ヤクの毛刈り」のように、本質的にやりたいことの他にもいろいろな技術が広がっていて結びついている。

何がわかっていないのかを意識する。

技術者の評価は難しい
技術者へのリスペクトが大切

役員をre:Inventに連れて行って、会場の雰囲気を味わってもらい、結果として会社全体でクラウドを目指す

技術組織を作る→組織化すると予算をとりやすい

スランプになっている人は、励まして次のステップへ進むのを応援する

15-A-4 生成AIを本気で推進するトップランナーが語る！AIの展望2024年とその先

生成AIの用途

• メインの事業
• 付加価値
• 効率化

企業ごとの取り組み

• LayerX
  • 事業で経費精算などを扱っているので、ドキュメントOCRなどに
  • チャットはやらないと決めて、ドキュメント（契約書やIRや論文など）をLLMで処理
  • Google検索もだけれど、やりたいことをインターフェイスに入れるのは難しい
• メルカリ
  • 裏側のロジックでLLMを使う
    • チャットツール内でボットにスライドを投げたら翻訳してくれるツールなど
  • 組織のフレキシビリティが高いと新しいものを取り入れやすい
  • LLMを使ったアプリケーションをいろいろ出していく
    • 画像や動画など幅がある
  • 社内の2000人で試せる
• Algomatic
  • 設立してすぐだから、いろいろできる
  • データがものを言う分野には挑まない

立ち位置や持っているデータが違うと、生成AIに対する取り組み方も違う

今までは、好奇心旺盛が人が空き時間に試して、周りに教えていた。 これからは、必要性を感じないと使わない人にも使ってもらうフェーズ。 また、10倍などしっかり成果を出していく必要がある。

今後展開される領域としてロボットやデバイスなどが考えられる。

5年後は、特にAIを使う人の仕事のやり方が変わる。 仕事の種類が変わり、コード、デザイン、ビジネスの境界が溶ける。 ただ、消費者の体感はあまり変わらない。

15-C-5 マイナビの全社データ基盤のモダナイズ

https://engineerblog.mynavi.jp/mynavi_life/sanka_52_03/

デジタルテクノロジー戦略本部があり、全社横断的に8つの分野でデジタル戦略の立案と実行をしている。

データの流れ
収集 → 加工 → 蓄積 → 検索 → 活用

今まではオンプレで、古くて遅い、増大する要求にスペックが耐えられない、バージョンを管理できないなどの課題を抱えていた。 クラウドに移していろいろなツールを変えることで、扱える開発者が増えたり、スケーラビリティの恩恵を受けたり、レビューをできるようになった。

---

組織、技術それぞれの要件や非機能要件に対して、スケジュール感、社内調整の内容、移行しての成果、振り返っての課題などを知ることができました。

15-A-6 アーキテクチャから学ぶKubernetesの全体像

Kubernetesはコンテナオーケストレーションツールで、今は成熟したプロダクトとして認定されている。 Kubernetesの構成とControllerがどういうもので、何をしているのか、どんなことをできるのかについて知りました。

---

Kubernetesは名前しか聞いたことありませんでしたが、耐障害性が高く、拡張性が高いことを知りました。 何かプロダクトを作ってKubernetesで実行する日が来たら、システム構成を考える際にControllerに何を任せるかを考えるときの参考になりそうです。

15-D-7 7年間1000件の障害事例からわかった、障害対応の改善ポイント～協同で変えるシステム障害対応とは？～

システム障害の年間国内損失額、金融庁への1日の障害報告件数の数値を見て、システム障害は頻繁に起きていて損害も大きい。

• システム視点ではなく、サービス視点
  • データベースが落ちたではなく、ユーザにとって何の機能が何時間使えないのか
• 事象ではなくアクション起点
  • アクション候補（どのような障害があったらどの行動をすべきか）があって、そのアクションを実行するのに必要な情報を集めるなど
• 情報の量より質
  • 大量の情報に全部受け止めるのではなく、アクションをするにあたって判断に必要な情報だけを見る

「大規模なシステム障害」の定義をサービス視点で定義。 それぞれの障害パターンで関連組織（セキュリティ担当、広報など）を決定する（アクションを決める）。 これにより、曖昧で不安だったものが、具体化し安心につながる。

大量のアラートを運用が見て保守にエスカレーションしていたが、エラーメッセージを確認しても意味がなく、エスカレーションの電話をしても対処不要と返ってくるだけ。 電話を自動化し全員を保守とし、不要なアラートの設定方法を教えておくことで、自分が楽になるために自発的に不要なアラートを止めるようになった。 不要なアラートの大幅減に成功し、5年以上も継続している。

→「協同」でシステム対応するのが大切

15-D-8 “持続可能な”開発を実現するためにスタートアップで実践したこと

https://bitkey.co.jp/newsroom/20240201/

チームがスケールを始めた時点で20人いたエンジニアが、1年半後に残っていたのは4人。

当時

• スポットでは開発できるが、継続的にはできない。
• 0から1を生み出すのは前提で、それをどう提供するかを考えていた
• 犠牲：各種設定など運用時の負債、属人化、時間と心
• 属人的で高い能力を前提にしていた
• 1人1プロジェクト状態で、エンジニアとしてはプロダクト全体がわからず、知らぬ間に実装がある状態
• 脆いアーキテクチャで、全体がわからない状態で修正し、テストもない

デリバリー優先 vs ヒト優先

• デリバリー優先：ビジネスが進むとユーザが喜ぶ

• ヒト優先：「やりたい / やりたくない」「気持ちよい / 嫌だ」

  • 「やりたくない」を無くす、「やりたくない」と「やりたい」に変える、「やりたい」をつくる

• メンタルモデルの造成

  • 「考え方」の下地が揃っていない → モブプロ、ペアプロ、イベントストーミング、sudoモデリング
  • 状況確認のコストが高くなる
  • クリーンアーキテクチャの導入、実装ポリシーの導入

• 壊れにくい仕組みづくり　→ 認知負荷を下げる

  • 疎結合
  • DDDの実践パターンにより、特定のルールが必ず適用される状況にする
  • インターフェイスの精査

もともとのやり方がダメ、ではなく、フェーズに合わせて使い分ける。 やり方ごとにメリット・デメリットがある。

15-D-9 Platform Engineeringことはじめ～コミュニティと一緒に新たな旅に出よう！

クラウド技術の発展により、エンジニアが知らないといけないことが激増している。 開発者が開発に集中するために、プラットフォームが何を提供し何を支援できるか。

• Platform as a service
  • 開発者を『顧客』とし、プラットフォームという『プロダクト』を提供する
  • 改善を継続する

アプリ開発者は、早くアプリを世に出して価値を検証し改善したい。 しかしビルド、テスト、デプロイなどで認知負荷が高すぎる。

• 環境構築の難しさ
  • 設定がいろいろあったり、エラーへの対応など
• ドキュメントの不足とアクセスの問題
  • 情報を見つけにくい、古い、専門用語が難しい、社内ではアクセス権限が必要など
• コミュニケーションの課題
  • 誰に連絡するか、コミュニケーションツールのルール、返信が遅いなど

時間を圧迫し、フラストレーションがたまり、自己疑念（自信を失う）

CNCF(Cloud Native Computing Foundation)のPlatform Engineering maturity modelでは、成熟度として1～4のレベルを設けている
→ まずは 1 → 2 が重要

• ゴールデンパス

  • 開発のベストプラクティスを実際に動作する環境とともに提供
  • 開発者の生産性を向上させることが目的
  • 例
    • セルフサービスで環境を払い出せるようにする
    • 最新に更新されたドキュメントを、集約されたプラットフォーム上で公開
  • ことはじめ　←関係者がアクセス可能な形にする
    • 環境構築ドキュメントを更新
    • ドキュメントのリンク集やインデックスを作成
    • 用語集を作成

• チームAPI

  • チーム間のやりとりのルール（インターフェイス）を定義
  • 例
    • 各チームの担当領域の明確化
    • 依頼窓口の明確化
    • 透明性のある状況把握
  • ことはじめ
    • 自チームの役割・担当サービスを公開
    • 自チーム宛のコミュニケーションライン

• できるところから取り組む　→　自分からチーム、組織へと影響を広げていく

  • メンバー：自分がつまづいたところを取り除く
  • リーダー：自チームのミッションと捉える

• 運営コミュニティでの実践例

  • オンボーディングで、タスクをすべて完了したらjoin→何をする必要があってどこまで完了しているかわかりやすい
  • 週報でアップデートをキャッチアップ
  • Slackのチャンネルを目的でわける

16-A-1 Flight of a Decade:10年間の旅路と再会

ぜひスライドをご覧ください！！

見え方について

• 視座
  • 目線の高さ。現場は低く、経営層ほど高い。低いと遠くが見えず、高いと足元が見えない。
• 視野
  • 視界の広さ。時間軸と空間軸がある。視野が狭いと短期的なことしか見えていないとか、自チームのことしか考えられていないとか。
• 視点
  • 何に注目するか。同じところを見ていても評価の仕方によって視点が変わる。視点が小さいと「よく見えている」と言えるし「それしか見えていない」とも言える。

視座が上がると視野が広がる。視野が広がったら、視点を説明する。

意思決定のタイミング、頻度、決断力

• ジュニアエンジニアやシニアエンジニア
  • ジュニアエンジニアは実装を振られて、どう実装するかを考えて（意思決定して）あとは実装するだけ
  • シニアエンジニアは課題を振られて、課題を調査し解決方法を決めたら（意思決定）あとは自分かジュニアエンジニアが実装するだけ
  • ある程度の正解があり、データや先行技術の調査をして仕様を決定するのが一番大きな意思決定
• スタッフエンジニアやプリンシパルエンジニア
  • 誰も正解をもっていないし、そもそも正解がない。ある程度で調査を切り上げて動かないとキリがない。
  • 小さい判断と決定を繰り返して、方向修正しながら進めていく
  • ジュニアエンジニアやシニアエンジニアが解決できなかった（正解がないなど）課題が上がってくる

グレードによって決定のタイミングと頻度が違うからギャップが生じる

• ジュニアエンジニア「前言っていたことと違うじゃん」
• スタッフエンジニア「進めて知見が増えたから軌道修正するのは当たり前」

自身が持つべき影響範囲

• ジュニアエンジニアは「自分自身とその周りの人」

• シニアエンジニアは「ジュニアより広範囲」（自分より下と同じグレードには、チームを超えて影響を求められる）

• スタッフエンジニアは「 自分より上への影響 」（部長やマネージャのパートナーとして意思決定への影響を求められる）

• プリンシパルエンジニアは「経営層の意思決定への影響」（会社の文化を作るなど）

• 50%の確率で失敗する挑戦

  • 2回行って全部正解する確率は25%
  • 3回なら12.5%
  • 4回なら6.25%
  • つまり 失敗していないというのは挑戦していない （確実なことしかやっていない）ということかも？

16-D-2 データブリックスエンジニアが語るデータ・AI基盤の現在地とこれから

S3など全ての生データをもとに、階層構造でデータを加工し処理できる

• データ処理の試行錯誤 → AIアシスタント
• 取得したいデータをSQLでどう表すかわからない → Data Rooms（自然言語でデータ集計）
• データの生産・利用者が増えているものの、データを分散管理または中央管理どちらもデメリットがある → Unity Catalog（あらゆるデータとAI資産を一元管理）
• AI/MLプロダクトの実現に必要なすべてのステップをサポート
  • AutoML（数行のコードでベースラインモデルを作成）
  • Playground（いろいろなモデルに同じ入力を渡して結果を見比べられる）

16-D-3 Elasticが目指す生成AI活用の将来像

Elasticsearchは生成AIにも使える

https://qiita.com/takeo-furukubo/items/e5d43fa734e4338b895f に近い内容でした

• RAG(Retrieval Augmented Generation)
  • 外部ソースから取得した正確で新しい情報を用いて生成AIモデルの出力の精度を上げてハルシネーションを防ぐ
• ESRE(Elasticsearch Relevance Engine)

ポイント

• Elasticsearchでベクトルデータも扱える
• テキストデータとベクトルデータのハイブリッド検索ができる
• ElasticsearchはWebクローラー機能やMLのモデルを動かす機能がある
• テキストデータとリアルタイムデータを組み合わせた検索結果を返せる

16-A-4 GitHub Copilotは開発者の生産性をどれだけ上げるのか？ ZOZOでの全社導入とその効果

https://techblog.zozo.com/entry/introducing_github_copilot の内容をベースとした発表です

現在2か月間のGitHub Copilotの利用状況

• 提案46万件
• 採用
  • 10万件（採用率23.59%）
  • 18万行

目標「ユーザーに届ける価値を2倍にする」 価値 = 量 × 質

まずは量（＝一定期間における案件リリース数）を最大化する。 そのために開発効率を改善し開発速度を上げる。 スループット的な速さ（開発者というリソースの稼働効率）とリードタイム的な速さ（案件に取り掛かってからリリースするまでの速さ）の両方の効率を向上させる

1. 調査と評価
   1. GitHub Copilotについて知る
      1. GitHun社へのヒヤリングと相談が非常に有効であった
   2. 課題の整理
      1. セキュリティ
      2. ライセンス侵害
      3. 費用対効果
   3. 課題への対策の検討
2. 導入計画立案
   1. 経営層への説明と利用料金の見積もり
   2. 試験対象者の選出
      1. できるだけ業務での環境が違う人を選ぶ
      2. 新しいツールを試すのが得意
      3. 導入時にチーム内で教示できる
3. 試験導入
   1. 期間を2週間とし、専用のSlackチャンネルを用意して知見の共有を推奨
   2. アンケート結果の集計と考察
      1. 78.9%がより生産的になった、58%が1日あたり30分以上時間を節約できたと回答
      2. SPACEフレームワークの「満足度と幸福度」「効率とフロー」への影響
         1. 半数が仕事への充実感が増し、コーディング時のイライラが軽減され、より満足度の高い仕事に集中できる
         2. 作業時間の短縮、精神的な負担が軽減される、29.9%がフロー状態に入りやすいと回答
      3. 言語や開発環境で効果にばらつきがある
   3. アンケート結果より費用対効果を見積もる
4. 全社展開
   1. 社内環境の整備
   2. 知見を共有するためのLT会やSlackチャンネル
   3. 1日当たり1時間以上時間を節約できたと答えたのは、業務上LLMについて話すことが多くLLMの活用方法について勉強会に参加している

---

課題を洗い出し方、それに対しての対処法の検討が参考になりました。 また、アンケートをもとに導入効果を測定する方法が勉強になり、数値として表れるのが良いと思いました。 WeboxによるエンゲージメントサーベイやFindy Team+による開発状況の定量的な評価など、いろいろな側面を計測できるようにするのも、現状の把握や課題の発見に役立ちそうです。

16-A-5 SIerな会社の中でXR(VR・メタバース）を用いた新規事業開発に挑戦して見えてきた景色

• 創業50年を超えるSIer
• 2019年からXR(AR/MR/VR)に取り組んでいる
• 技術スタックとしてはWebアプリと変わらない
  • 違いとしては、WebRTCを使ったP2P通信をしている
• 中朝的な「コア技術戦略」に基づいた取り組みをしている
  • https://fintan.jp/page/9577/
• XR開発ならではの難しさがある
  • UI/UX設計やテストなど
  • 技術者が少ない

16-A-6 マーケットインアプローチで挑む新規プロダクトの立ち上げ

https://www.veriserve.co.jp/seminar-event/2024/event-20240215-repo.html

新規事業を考えるにあたって大事なこと

• HowよりWhat・Why
  • 顧客は本当にその問題を抱えているのか？
• Will
  • 誰の、どんな課題を、なぜ私たちが取り組むのか

戦略の種類

• Product-Led Growth（PLG）
• Sales-Led Growth（SLG）

スタートアップの失敗としてよくあるのが、マーケットニーズがない

マーケットイン（市場を探す）には顧客と話してBurning Needs（今すぐに対応が必要なニーズ）を見つける。 実際にやったこととして、インタビュープラットフォームを用いてオンラインでインタビューをした。 30～45分程度で行い、コツとして相手の話した内容を要約して確認した。

見つけたBurning Needsとしてチームコミュニケーションがあった。 情報の種類としては「ストック型」（Notionなど）と「フロー型」（Slackなど）があり、フロー型をストック型にするのはコストが高い。 その中間が必要（GitHubのプルリクエストなど）。

事業仮説を立て、社内ユーザに加えて社外のパイロットユーザを通してテストを行った。

16-E-7 良いプロダクト作りのための組織育成（理論＆実践編） 健全なコードは健全な組織、健全なチームから

ぜひスライドをご覧ください！

個人的には1on1での現状の確認と振り返り、ティーチングやコーチングなど、1on1が重要だと感じました。 また、個から組織へとスキルを転換する仕組みが必要だと感じました。

16-B-8 ビジネスドメインの拡大を実現するバクラクシリーズでのモノレポ開発

https://tech.layerx.co.jp/entry/2024/02/14/183709

https://bakuraku.jp/

Platform Solution（すべてを一つのプラットフォームで完結）とPoint Solution（いろいろなプロダクトを組み合わせる）の間で流行の波がある。

https://tech.layerx.co.jp/entry/2022/12/12/131507 の記事も参考になりそうです。

monorepoは「Not just “code collection”」

リソースカットでリポジトリを構成している。 （go -> serviceA -> … のような形）

• Team Topologies
  • Four fundamental topologies
  • 3 core interactions

API Gateway Patternを採用している。

https://monorepo.tools/

ローカルビルドができる。 monorepoに対応しているツールやサービスは少なく、CLIツールでデプロイなどを行っている。

16-E-9 オフラインカンファレンス復活！イベント現地参加の魅力を語りつくすリレーセッション

オフラインは五感で雰囲気を感じられて、会場に行くからこそ全力で参加して、交流も楽しむ。 良いですね！

懇親会

綺麗な会場で、4人ほどが立って談笑できるテーブルがたくさんあり、料理の配置や飲み物の提供や空のグラスの回収などを行うスタッフが配置されていたりと、快適な空間でした。

いろいろな方に声をかけて名刺交換させていただき、医療系のシステム開発、さまざまなテスト、建築系など様々な業界の方とお話しいろいろなことを伺えました。 普段は立場も全然違いますしまず話せるような機会がない方々とお話し知見を得られたことはとても有意義でした。

感想

このようなイベントに久しぶりに参加しましたが、やはりオフラインでの熱気というか、目の前に人がいてコミュニケーションをする楽しさや一体感を感じました。 𝕏(Twitter)を見たりググったりするのとは違い、まったく知らなかったことを知ることができたり、知っているものが実際にどう使われているのかを知ることができたりと、知見も深まりました。 それとやはり、東京だからこそ情報が集まり、最先端の技術が使われ、活発な共有が行われているのかな、と感じました。

このイベントの準備や運営はかなり労力を必要とすると思うので、こんなに気楽に参加させていただいてありがたい限りです。

たくさんインプットして、自分の状態や立ち位置をより客観的に見つめて、これからどんなことができるのかを考える機会にもなりました。 オフラインイベントは楽しいですね！