Developers Summit 2024 Day1 参加メモ

Developers Summit 2024

翔泳社CodeZine編集部主催のDevelopers Summit 2024
Day1のみ参加させていただきました。

4年ぶりのオフライン開催

昨年までのオンライン開催も参加したものの、
自宅から開発をしながらの視聴のため
ほとんど参加していないのと同じ状態でした。マルチタスク無理

業務のお休みを頂いて参加するオフライン開催に戻り、
全セッション集中して拝聴することができました。

また、オフライン開催だと途中で他のセッションに移動もしづらいため
タイムテーブル選びに関しても熟考に熟考を重ねて検討します。
これはアレに似てますよね…

結果的に気づきの多い素晴らしいセッションを拝聴することができました。
資料は後ほどアップされたら随時更新いたします。

我々はなぜアサーションするのか～現場に寄り添うANA DXの取り組み～

ANAシステムズ、永和システムマネジメントのお三方によるリレーセッション。
途中から参加でしたが開発組織体制づくりに役立つ内容でした。

アサーションできる関係性作り

「お客様の安全を守るために、組織内でも自分の意思や要求を表明できる
心理的安全性を保つ」＝アサーションできる関係づくりのための
3つのポイント

• お願いする
• 声に出す
• 感謝する

チーム内で率直に発言できる土台づくり

デイリーMTGは1日3回！内容は

• アジェンダ確認で目的を揃える
• もやもや確認
  で「皆が皆の作業状況や困り事を気にかける」ことが目的

レンジャー

３人×３レンジャー（1スプリントごとにメンバーシャッフル）で
開発を進めることにより下記を達成

• 常にモブワーク
• 学習コスト削減
• 苦手分野にも取り組める
• 効率改善

ふりかえり

• Thanks Card
  →賞賛、感謝
• 失敗
  →プロセスの改善
• チャレンジ
  →チームの学びとして共有
• もやもや
  →スッキリするまで話し合う

これらの取り組みでチームに受け入れてもらえる安心感を得ることが大切

会社の契約関係を超えたコミュニケーション

• 協力会社のメンバーともフラットな関係
• インセプションデッキで方向感を合わせる
• クロスファンクショナルチームを目指す

アサーションしやすい環境

心理的安全性がある場
→チーム力向上（リスクに強いプロ集団）

開発生産性？いや、Developer Joyについて語ろう。

アトラシアン　皆川 宜宏さんによるセッション
「開発生産性発想の転換」がエンジニアファーストで素晴らしい取り組みでした。

開発者の生産性

• 定量的
  しかし、コードの書いた量？PRの数？≠品質
• 定性的

発想の転換

どのようにして開発者の生産性を測るか
↓ではなく
どのようにして開発者の生産性を高める手助けができるか

開発者は技術を愛する職人
↓
開発者の働き方の中に価値を見出し、それを還元していくことが必要

以前の状況

開発者の満足度49%

• 多すぎる摩擦（サイクルタイム長い）
• 自律性の欠如（他に優先しないといけないことがある）
• 壊してしまうことへの恐れ

Developer Experience

• ツール、フレームワーク、プラットフォームについてどのように感じているか開発者に確認
• 芸術家が紙とクレヨンで絵を描けと指示される状況はNG
• 適切なツールがない場合は、自分たちで作ることも

Engineering Culture

• どのように仕事を進めるか
• 組織の価値観、規範、意思決定
• 共感できるミッション、ビジョン
• なんでこれ作ってるのかよくわからん、何言っても無駄という状況はNG

現在地を見る

• 開発者に聞こう
• サーベイを取ろう
• 個々のチームの健康状態
  →今週のチームの状態を聞く

エンジニアの生産性を高める手助けを行う専門部隊を配置

• 内部用のサービスを提供
• ツールを管理
• 拡張性の高いプラットフォームを作る
• エンジニアカルチャーを他の職種にも取り込む

改善後

• 満足度は70%に改善
• ただし、常に手入れしないとガタがくるため、定期的な取り組みが必要

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

ビッグツリーテクノロジー&コンサルティングの高安 厚思さんによる
「独断と偏見（ご本人談）」の「すごい人とは」セッション。

すごい人とは？

• 俯瞰的な視点
  • 幅広い視野、体系的理解
• 本質的な理解
  • ネット上だけでない、原理原則を知っている
  • 応用が効く
• 圧倒的なスピード
  • 中途半端を恐れない
  • FBループが短い

まとめると

• Tobeから現実を見て手段を考えることができる
• ロードマップを考え、現時点での落とし所がわかる

技術分類・ロール

コンサルタントと技術者が共通の言語で話せる

技術の習得・マインド

• ターニングクルーガー効果に注意
• 「チョットデキル」までの道のり
  

動作しているものの裏側を知る

• そのライブラリが何をしているかまで理解する
• 定期的に棚卸しをして、わかる領域が増えたか確認する

組織作り

• 書籍購入費用の補助
• 実験用クラウド環境の提供
• 技術的成長やプロジェクト貢献に関する評価を行う
  →技術者へのリスペクトが大切

開発生産性の現在地点について～エンジニアリングが及ぼす多角的視点～

DMM.comの石垣 雅人さんによる「開発生産性」の歴史から現在地点、
今後の課題を多角的に説明いただくセッションで
わかりみが過ぎるの連続で首を振りすぎました。

開発生産性の現在地点

State of DevOps Report

• puppetとDORA(Google買収）二つの流派がある
• ソフトウェアの生産性であること（組み込みは対象外）
• DevOps周辺の生産性であること
  =組織の生産性かどうかは、議論の余地あり

「推測するな、計測せよ」を実践するメトリクスサービスの発展

• チームパフォーマンスツール
• Four keysパイプライン

Developper Productivity Engineeringとは？

「Engineering」であり「Manangement」ではない
プロセスをテクノロジーで支援する取り組みのことだが
下記の問題をはらんでいる

生産性の可視化に対する議論

• そもそも生産性は測れない
• Four Keysの数値を良くしても悪影響にもなる
  UIがどんどん変わってもついていけない
• Devopsの生産性≠組織の生産性
  サイクルタイムとリードタイムの一致

何を計測するのか/誰のために計測するのか

• アウトプットではなくプロセスを計測せよ
• 生産性データが組織を全て網羅するわけではない
• 計測ではなく課題解決に時間をかけるべき

「変更承認」のタイムラグ

バリューストリーム　マッピングを書けば
開発が完了してからリリースまでの間にも時間がかかることがわかる
→エンジニア組織が改善しても、組織生産性にはならない

エンジニアリングの差別化要素がなくなりつつある

競争優位性としての生産性

• 継続的な速さ
  →仮説検証
• 利益損失の最小化
  →売り上げ損失の最小化
  →無駄な開発費用の削減

開発生産性が経営層に伝わらない理由

• 「言語」が違う

• 経営層に向けて開発生産性の単位を変換する必要がある
  

• エンハンス開発

  • 効果が目に見えやすい
    ⇔

• リファクタリング、リプレイス、バージョンアップ

  • 効果が目に見えにくい
  • 膨大な予算をかけて機能を元に戻すだけ
  • ただし、放置すると負債になるのみ（エントロピーがソフトウェアを殺す）

経営層と開発者のすれ違いについては下記Tweetにまとめていただいたスライドが
これofこれでした。

まじでこのすれ違いの話を永遠にしてるけど、言語化が素晴らしい #devsumi pic.twitter.com/Bc2t4OkBsr

— あんどぅ (@integrated1453) February 15, 2024

エンジニアのフロー状態

• エンジニアのフロー状態（集中状態）を継続的に創出する必要がある
• マネージャとエンジニアでタイムボックスが違う（1時間 vs 半日)ことを理解する
  

経営層と開発者のすれ違いループからの脱却

• 開発者が説明責任を果たすことが必要
• 経営層と開発者の信頼関係が必要

生産性が低いチームを強くするには

• まずアウトプットを上げた後にアウトカムを考える
• 数値向上を目的にするとハックしてしまう(無駄にPR回数を増やすなど。グッドハートの法則）
• 他者と比較すると無意味（過去の自分たちと比較するのが大事）

技術を超えた成長へ：エンジニアとしてのマインドセットと学びの旅

NECソリューションイノベータの田中 拓摩さんによる
シンプルで力強いセッションでした。

マインドセットとは

• 人間が持つそれぞれの無意識の思考行動パターン
• マインドセットを変えれば成長度合いが上げられる

とっととやれ　Do it Now

上位5%エンジニアとの違いは2:8の法則
「AWS Re:Iventに行きたい人はカレンダーに登録してね」
との連絡に対し、
80%：そんなことあるわけない
20%：そんなこともあるかもね
と考える。

残りの20%のうち、さらに実際に行動するのはたった4人だが
その4人は、実際にラスベガスに行けるとのこと！

人生のコントロールをしたかったら責任を引き受けろ！

• 責任を取る意思＝判断できる、コントロールできる
  →指示された以上の仕事ができる
• 自分のせいにする
  →状況を自分で変えられるので、怒ることが少なくなる

マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB

イオンスマートテクノロジー香西 俊幸さんによる
MySQL CompatibleなNew SQL「TiDB」に関するセッション
マイクロサービス構築における課題が印象的でした。

TiDBとは

• MySQL CompatibleなNew SQL
• HTAP（トランザクション処理と分析処理を同じインメモリデータベース上で処理する）
• 無限のスケーラビリティ

マイクロサービスのアンチパターン

• 最初からマイクロサービスを構築するのは、実はアンチパターン
• サービス分割の失敗
• サービス間のトランザクション管理、分散トランザクションむずい

マイクロサービスとリンクしていない組織設計

• DevOpsできてない
• メンテナンスを運用でカバー

TiDBがこれらの運用負荷を解決？

下記全てメンテナンス不要。ホットスポットも調整してくれる
アプリケーション側での実装も不要

• スケールアップ
• バージョンアップ
• DDL実行
• シャーディング

マイクロサービスはモノリスより優れているとの先入観があったため、
最初からマイクロサービスで構築する弊害を知ることができて驚き、
ぜひ続報をお伺いしてみたいセッションでした。

AI時代を乗り切るための実装力をつけよう

LINEヤフー　きしだ なおきさんによる
「AIに代替できないプログラミング能力」のセッションで
こちらは副業で行っているプログラミング教室の授業で
大切となる要素が詰まっていました。

プログラミング能力がないと

• 文法を覚えてもプログラムは書けない
• レビュー指摘されても修正できない
• レビューができない

パターンで覚えるのではなく処理の流れを追い、書くことができる能力が必要
→算術とプログラミングの大きな違いを説明した
こちらのスライドが指針となりそうです。

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

ビットキーの佐藤 拓人さんによる開発組織に関するセッション
１→１０フェーズあるあるの連続で共感の嵐でした。

プロダクトをスケールするフェーズで1年半後に残っていた開発メンバーの数はなんと
4人/20人継続的に進化するために問題点を整理し、対応

問題点

• デリバリーに全振り

  • 技術的負債
  • 時間、心を失う

• 属人的で高い能力を前提にした開発プロセス

  • １人１プロジェクトみたいな開発

• プロダクトがわからない

  • 全体像が把握しづらい
  • 認知負荷が高い

• 脆いアーキテクチャ

  • 修正したら他の場所が壊れてしまう

何をしたか

• 人優先

  • 中長期的にスケールするにはデリバリー優先だと破綻する
  • できる/できないではなく、やりたい/やりたくないを大切にする
  • 問い合わせを減らすための改善活動など

• 自立可能なプロセス

  • スクラムの導入
  • 効率ではなく自立可能を目指す

• メンタルモデルの醸成

  • 考え方の下地が揃っていない
  • 状況確認のコストが高くなってしまう
    →考え方をチームで共有
  • モブプロペアプロ
  • イベントストーミング
  • sudoモデリング
  • 実装ポリシーの整備
  • クリーンアーキテクチャ

• 壊れにくい仕組みづくり

  • DDD実装パターン利用で疎結合、高凝集を実現
  • 特定のルールが必ず適用される状況を整備
  • IFの精査

まとめ

ただし0→1のフェーズでは上記は合わないこともあり、
やり方をフェーズに合わせて使い分けが必要とのことでした。

素早いデリバリーよりも中長期的にスケールする取り組みを優先することを
どのように経営層に説明し、納得していただいたかについて
さらに質問してみたかったです。

ChatGPTでちゃんと成果を出していく

最後に生成AI系のセッションを拝見しました。

どのようにChatGPTを活用し成果を出しているか

• コンサル業務、物事が進んでない、やり方がわからないときに役立つ

  • Ex.上場支援、経営支援
    • 海外でEC事業をするにあたって何が必要か洗い出してくれる
    • 一定の前提を与えると回答してくれる
    • 1週間後に回答します→その場でChatGPTに聞いて終了、のスピード感にできた
  • タスクアップ、分解が得意
  • 動けるレベルまでにしてくれる

• 製造業の不得意なところをカバー

  • 網羅性
  • アノマリ検知
  • センチメント分析
  • 農業ですと前提を与えれば項目名なしcsvも分析できる

• システム開発

  • 設計書のレビューをしてくれる
  • 単体テストを作ることができる
  • 受け入れ基準を作ることができる

• ChatGPT以外のAI

  • ChatGPTはツンデレ、悪役ができない
  • 創作には「AIのべりすと」等のChatGPT以外のAIがおすすめだが、精度はまだ低い

プロンプトの重要性

• 開発で繰り返し結果が必要な人はプロンプトを組んだほうが良い
• ケース・バイ・ケースの場合で使う一般ユーザーには不要
• 細かいテクニックを使いすぎるとチューニング大変
• アップデートされると使えなくなったりする
• プロンプトの指標、評価を整えておくのが大事
• プロンプトはシンプルに保って、データ（RAG）の精度を上げる方が大事

今後の課題

• 汎用型AI-特化型AIの連携
  ゼネラリストAIが特化型AIに指示出し、まとめをするのが良い
  →Agent GPTは割と近いことができる

• ノウハウが溜まってないだけ、アプリ開発者が足りてないだけでは？
  →AIアプリ開発をたくさんしていきましょう

というところで、うまくセッションがしまりましたが
まだまだトークテーマもたくさん残っていたため
登壇後のAsk The Speakerも盛り上がっていました。

ChatGPTさんが、まあまあの頻度で嘘をついてくるのは
プロンプトがうまく組めていないことが原因かもとのアドバイスをいただいたため
プロンプト改善に取り組んでみようと思います。

企業ブース

アトラシアンさんのブースではKPTのホワイトボードが参加者の付箋で埋まっていたり
CDataさんのブースでは丸シールで投票するコーナーがあったり、
とオフラインならではの活気にあふれていました。

その中でもTimeeさんのブースは
可愛らしいキャラクターに埋もれていて大人気でした。
入社すると、こちらのぬいぐるみが貰えるらしいです！

まとめ

生成AIや新技術にによって生じた「エンジニアの価値、生産性」に関する
内容が強く印象に残りました。

DMM.comの石垣さんやビットキーの佐藤さんのような
エンジニアリングマネージャでなくても、エンジニア各個人が
ビジネスサイドの方と言語を合わせて、今の自分の開発が
どのようにビジネスに作用するのか、を説明できる力が
必要になることを強く感じました。