これはなに？

developers summit 2024というイベントで講演を聴いてきたので、自分用のメモ目的でまとめます
（未完成です）

Developers Summit 2024

セッションごとの感想

事業で成果を出すCTOたち

CTO3名によるディスカッション形式

CTOとしての意思決定の場面

• M&Aする
  • 相手方の組織文化などを注意して確認する。
  • エンジニアによる意思決定など
• 会社全体の方針を決める
  • クラウドを使う、生成AIを活用する、etc.
  • 決めるのはあくまで「大まかな」方針
    • 詳細は現場の人が一番詳しいので、技術選定はサービスの担当者に担当させる。
• 長期視点での判断
  •  CTOは事業の成果について責任を持つので、長期的な視点での判断は担当する必要がある
  • 企画の対応期日など
• 組織がやりづらそうにしていたら、キャッチして体制を改善する
  • 権限の移譲など。
    • 他責にならないように注意が必要（各自がチケットだけ切って放置される、など）

意思決定に関して心掛けていること

• 意思決定の背景を現場に伝える
  • 不足していると足を掬われることがある。
  • 伝わっていない場合は、相手の顔色を見ればわかる。解決は、時間をかけて対面で話すことでしかできなさそう。
    • このため、話しやすい雰囲気を作ることを心がけている

CTOのハードな仕事

• 成果を出すこと
  • 作って終わりではなく、収益を大きくするための改善が必要になる
    • （が、この視点を現場のエンジニアに持ってもらうのには苦労している）
• 会社の命運を賭けること
  • 経営は、次にどうなるかわかったものではない。
    • 不確定要素がとても多い
    • エンジニアの立場でいうと、工数見積もりを任された時のあの感覚に近い
  • 「ハイリスクだが会社の将来が開ける選択肢」を眠らせるのか、すぐとるのか。など決定が必要。
    • 当然不安にはなる。
    • が、おかしなことをしていたら周りの誰かが指摘してくれるので大きな問題は起きない
      • 技術負債が発生するのは、先の意思決定よりは、やると決めた後の進め方のせい
• 現場のエンジニアに対して自分の価値を示すこと
  • エンジニアを抱えるということは一種の投資である
  • 気持ちだけでは伝わらないので、数字で示す必要があると考えている
    • 数字とは例えばコスト、リターンなど。

感想

• CTOの苦労は現場エンジニアの苦労とは大きく異なる
  • 基本的には意思決定の重さに起因する
• 現場のエンジニアには経営の視点を持つ人が多くない。持っていたら上位の意思決定の肌感も理解できてスムーズに仕事が進められるだろう。

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

一言でまとめると、datadogのエンジニアによるオブザーバビリティの重要性の話。

技術・スキルの分類

• 技術には流行り廃りがあるが、生成AI登場により大きな転換点に到達している
• 旬なテクノロジーと基盤のスキルがある
  • 旬なテクノロジー
    •  Dev Ops, マイクロサービス, クラウド, etc.
  • 基盤のスキル
    • 全体俯瞰, ビジネス思考, コミュニケーション
    • 発表資料中の説明は「過去何十年かでエンジニアの差別化材料となり、今後もAIでの代替が当面困難であるもの」
• 基盤のスキルを身につけた上で、その上に旬のテクノロジーを習得する、という2階建の構造が求められている。
  • が、1階・2階の間に介在する概念としてオブザーバビリティがある。

オブザーバビリティ（可観測性）

• 取得したデータを元にシステムの状態を推測・把握する手法
  • この説明だけだと「監視」と同一のように思われるが、異なる概念。
• マイクロサービスアーキテクチャのデメリットを緩和できる
  • マイクロサービス間の複雑な依存関係の可視化
  • 処理ごとの所用時間の可視化
  • エラーの生じた箇所の可視化
  • etc.
• datadogはオブザーバビリティツールである
  • 以下を可視化できる
    • API間の参照関係
    • 処理時間
    • web画面のクリック状況
    • etc.
  • プロジェクトの関係者全員が、一つのダッシュボードをみればあらゆる状態が可視化できる点が特に良い

感想

• 監視は知っていたが、オブザーバビリティという概念は知らなかった
• datadogを使えば実現できるが、datadogを使えない環境ではどうすればいいのか？代替策はある？
• 結局はビジネス観点を持っておくと良いぞ、という話だと思う。

サービスの危機に立ち向かうリーダーシップ～インシデントコマンダーの役割と戦略～

一言で言うなら、インシデントコマンダーという役割の説明と、その作業に役立つPagerDutyの機能の話

• 障害対応によってエンジニアは成長する
• 障害対応を一人で担当すると、当人は成長するが、組織の改善の機会は減ることになる
  • ノウハウは組織に共有された？
  • 二次災害が起きるリスクは小さくなる？
• ビジネスは基本的には価値送料の最大化を目指すが、インシデント対応はそれを妨げる要素である。
  • 小さく抑えるために、効率的に対応できる体制を作るのが望ましい。
• ところで、インシデント対応に入ると、自分は正義の味方をやっている気持ちになりがちだが、悪の組織の気持ちを持っている方が合理的だし、組織にとっても良い。

インシデントコマンダー

• • インシデント対応において最大の権限を持つ人。一番えらい。
  • インシデント対応時に、各作業者に指示を出す人
    • インシデントコマンダー本人が作業に入ってもいいが、まずは本来の役割に専念するべき。
  • ステークホルダーへの説明も行う人
• PagerDutyにはインシデントコマンダーの作業を楽にする機能が盛りだくさん！
  • 最近では生成AIを活用するものも追加されている
    • ポストモーテムの自動生成
    • インシデント説明の要約
    • etc.

感想

• インシデントコマンダーは大変だが、権限もある
• PagerDutyは使っていたが、こんなに高機能なのは知らなかった。

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

一言で言うと、生成AIトレンドのこれまで・これからについてのディスカッション

チャットというUI

• LayerXはドキュメント作業の改革だけを目標にしていて、チャットはやらないと決めていた点で他社とは異なる。
  • そもそもチャットというUIは、生産性の向上のためには不適なのでは？
    • hubotが思ったより定着しなかったことから。
  • でもslackはユーザージャーニーは良く、チャットというUIは人々に浸透している。
    • メンションつけてメッセージ投げたら、特定の処理が行われる、などは良い形。

次にくる適用先

ロボット

マイナビデータ基盤

一言で言うと、ETL環境を刷新したので具体的な移行内容とふりかえりの話。

可用性の難点が多くあったが、コスパ等も検討しながら技術選定をした

感想

• 巨大な移行は大変
• 技術選定の理由は納得できた
• クラウドサービス側のバグがあり得るのはさすがに対処できないので辛い
• 会社の文化に起因する難しさもあることがわかった

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

一言でいうと、Controllerに注目したKubernetesの中身の解説。

感想

むずかしかった。。

僕らは何を作ったらいいのか

一言で言うと、新たなサービスを作る際のユーザーインタビューでの試行錯誤についての話

ユーザーインタビューについて

• 新サービスを開発するにあたって、ユーザーインタビューをした
  • ユーザーの意思決定の過程を詳細に知ることがゴール
  • ユーザーを集める方法は色々ある。（Amazonギフトカードを支払う。linkedIn、カンファレンス発表）
• 注意点
  • 本人の体験によって話されていない場合、深掘りできない
    • 「キャラの設定がしっかり作られていると、勝手に動き出す」という話の、逆。
  • “great!”と言われても肯定の程度は場合による。
• 会話の展開の仕方で相手の引き込まれ方が変わってくる
  • 落語を参考にしていた
• ユーザー（市場）を知ることは大事ではあるが、誤ったものを作っても損なわれるのはせいぜい１ヶ月程度だろうから、あまり重く捉えることはない

感想

• 作る前に需要を正しく把握することが大事な点は理解
• ユーザーによって状況は違い、必要としているものも異なるはずなので、需要の理解はそもそも難しい課題である
• インタビューの仕方によって引き出せる情報が異なるなら、特にどういう方向に工夫するのが良いのだろうか？