先月末に実施された開発生産性カンファレンス2024に参加しました。とても勉強になったので自分の備忘録のためにも参加レポートを書きます。
1. カンファレンス概要
カンファレンス名：開発生産性カンファレンス2024
開催日時：2024年6月28日-2024年6月29日
場所：虎ノ門ヒルズフォーラム
URL：
dev-productivity-con.findy-code.io
2. どんなカンファレンス？
カンファレンスのページを抜粋しつつまとめると、国内外の企業の開発生産性に関するベストプラクティスや開発生産性向上への取り組みを共有し日本のエンジニアリングの向上につながることを目標とする、というようなカンファレンスです。
虎ノ門ヒルズフォーラムの4Fと5Fを使って4会場分のセッションが2日間続くなかなか盛りだくさんのカンファレンスでした。
3. 全体を通した所感
参加前は「開発生産性のカンファレンス」ということでforkeysなどの色んな指標や、それをどう集計するかのような技術的な話、つまり開発の内向きの話が多いのかと思っていました。
実際には、どちらかというと開発生産性を向上すると会社にとって何が嬉しいのか、何を目標に開発生産性向上の取り組みをすると良いのかといった、開発生産性向上の施策を事業部や会社視点で見たときに良い方法があるかというような話が多かったように思います。
それでいて、開発生産性がよくなるような開発の仕方（アーキテクチャ設計、自動テスト）の話もあり多様な話が聞けて非常に勉強になりました。
４. セッション各論
資料URLが見つけられなかったセッションは内容のメモを概要欄に記載しています。
E2Eテストを自動化したら開発生産性はどうなった？hacomonoの事例紹介
スピーカー: mabl株式会社 おだしょー、株式会社hacomono 森島 諒
資料URL:
印象に残ったこと:
- 自動テストが楽になっても開発のフィードバックが遅ければ開発自体の生産性は良くならない、てのは開発生産性向上の施策をよく設計しないといけないポイントだと思う
学んだこと:
- E2Eテスト自動化でつまづきやすいポイントとそれをどう乗り越えたかという事例は参考になった
- 流行の生成AIを使ったテスト自動化ツールの情報が知れた(めっちゃ便利そう)
- mablとは、生成AIを使った自動UIツール
- UIテストが壊れたら自動的に修復
- プロンプトでアサーションを実現できる
- テストコードのjavascriptのスニペットを生成してくれる
- mablとは、生成AIを使った自動UIツール
実践チームトポロジー：プラットフォーム性とイネーブリング性の戦略
スピーカー: 株式会社タイミー 赤澤 剛
資料URL: speakerdeck.com
印象に残ったこと:
- イネイブリングチームとして「Dev Enable」という学習文化の推進をするチームを置いているのが印象的だった
- 学習文化の推進とエンジニアがエンジニアリングに集中するための環境や制度の提供が目的
- 学習の基盤があっていいなーという受け身の感覚というより、エンジニアを成長させるということを目的におい専門チームを置くというアプローチが他にはないなと思う
学んだこと:
- ストリームアライアンドと最強の仲間たちという表現は、どこに軸を置いてチーム構成するべきなのかとてもしっくりきた
- プラットフォームチームやイネイブリングチームはSAチームを強化するための最強のチームとなるべき
- SAチームの課題感や将来どうなっていきたいかが、これらのチームの活動のトリガーになる
- そのため、SAチームは自分たちに必要な能力は何で、何が不足しているのか自己診断を継続的に実施する必要がある
技術的負債の解消のための設計アプローチ hacomono編
スピーカー: 株式会社hacomono みゅーとん、野崎 才門
資料URL: なし
概要:
前半が技術的負債解消のためのリファクタリング、後半がAtomic Designの話
- リファクタリング
- まずテストコードがなかったのでとにかくテスト書く
- 責務でロジックを割ってロジックの純度を上げたい->chain of responsibilityを適用して責務ごとに分割
- 同じような処理があるが利用場面によって使う変数と使わない処変数がある->builderパターンで必須変数と任意変数を表現
- Atomic Design
印象に残ったこと:
- テストコードを書くことで安心してリファクタリングできるというのと開発者のメンタルモデルの構築に繋がった
- 開発の導入とか教育としてテストコードを書いてもらうってのはありかもしれない
- Atomic Designはもともとデザイン向けの考え方なので無理にフロントエンド開発に当てはめるとうまくいかない
学んだこと:
- Atomic Design適用の事例は普通に適用すると難しそうだなと思うところがうまく解消されていて参考になった
組織横断支援チームによるFour Keys計測基盤の構築と活用に向けた取り組み
スピーカー: サイボウズ株式会社 三村 遼
資料URL:
印象に残ったこと:
- 指標があるから分析ができるというのは改善活動を回す第一歩で重要である
- 組織横断支援チームとして開発チームの負担にならないようにの配慮が行き届いている
学んだこと:
- 他チームを支援する施策を進める側としてのL&Lが参考になった
- 各チームが使っているツールを無理に統制せず、指標集計用のWebAPIを提供して使ってもらう
- Forkeysのお試しは全員強制ではなく挙手制にする
- 施策を試す際は最も前向きなチームから始めること
Metrics-informed development; theory and practice
スピーカー: Gradle, Laurent Ploix
資料URL: なし
概要:
- 開発生産性の指標に対するMental Frameworks
- 開発生産性の指標のdependency graph : effort(実装) -> output(コード) -> outcome(開発の満足度) -> impact(利益)
- 指標から示唆を導く際の階層構造 : Data -> information -> knwoledge (Dataが下層、knowledgeが上位層)
- 指標のユースケースとL&L
- 指標を調査するときにdependency graphの先行指標があるか確認する、現場に近い指標ほど計測しやすい
- DORAメトリクスが使いにくいと思ったら、先行指標として現場に即したlocalなDORAを計測しても良い(運用環境ではなく開発環境の状態に置き換えるとか)
- リスクと有効性に対する危うさ
- メトリクスには必ずバグがあると念頭におくこと、イテレーションして改善すること
- 指標はあくまでinformしてくれるだけ、仮説を持って指標を使うこと
印象に残ったこと:
- 指標及びその源泉となるデータにはバグがあると念頭におく、指標を絶対視しないこと、これはスピーチの中でも何回か登場したキーワードであり重要な考えだと思う
学んだこと:
- dependency graphに沿った先行指標の考え方として「技術的負債の可視化」が例に上がっていて参考になった
- 技術的負債自体を集計するのは難しい、なので先行指標を見出すようにする
- 技術的負債があると思われるソース、コンポーネントを決める(これは主観的な評価で良い)
- 関連する指標を集計する(最終コミット時間、コード数...)
- 技術的負債のあるソース/ないソースとの相関等をとって分析し、どの指標が技術的負債に通じるかを決定する
- 技術的負債自体を集計するのは難しい、なので先行指標を見出すようにする
「開発生産性を上げる改善」って儲かるの？に答えられるようにする
スピーカー: DMM.com 石垣 雅人
資料URL:
印象に残ったこと:
- スピーカーがDMMの部長さんで、事業責任者の立ち位置からソフトウェア開発をどう見ているのか説明してくださり、普段のエンジニア目線とは違い印象的だった
学んだこと:
- 開発生産性を語るには、事業責任者が何に関心があり、何を重視しているかを知ること、またソフトウェア開発に関する仕組みを理解する必要がある
- 事業責任者は究極には「狙ったタイミングでモノが出てくるのかどうか」が知りたいので、管理上の指標は本来は必要ない
- 信頼がないと(細かく)管理したくなる、信頼を得ることが重要、信頼を得る糸口として開発生産性のデータを使う
- 利益を上げる見込みが高いモノは「資産」になる、そうでなければ「費用」として計上、「利益率の高い」製品を「たくさん」作る必要がある
アーキテクチャレベルで考える開発生産性
スピーカー: DMM.com ミノ駆動
資料URL:
印象に残ったこと:
- 「自社サービスの競争優位性はなんですか」と聞かれてパッと答えられなかった、重要なポイントを意識できていない証拠
- 良い設計するという点においても重要な機能に時間をかけるべきというのは印象深かった(良い基盤的なアーキテクチャ、仕組みをどう作るかを意識していたので...)
学んだこと:
- ドメイン駆動設計は「レイヤードアーキテクチャ」など「戦術的設計」が取り上げられがちだが、「コアドメイン」や「隔離されたコア」など「戦略的設計」も非常に重要
- 漫然と良い設計を目指すのではなく自社サービスの競争優位性を分析し、競争優位性の高い機能に開発リソースを集中する
開発生産性の観点から考える自動テスト
資料URL:
印象に残ったこと:
- 開発生産性の観点から、自動テストの目的は「工数削減」と考えがちだが保守コスト等を考えるとこれはアンチパターン、「ソフトウェアの成長を持続可能にする」という中長期的なところを目的にするべき
- 「テストでは品質は上がらない。テストは気づき。品質を上げるのはコーディング」は本当にその通り。テストからのフィードバックを早くして、テストしやすいコード＝変更しやすいコードを目指したい
学んだこと:
- 単体・結合という考えはいつもスコープに悩むのでTest Sizeという考えは線引きがはっきりしてていいと思った
- 小テスト: 1プロセスの中で完結する(ファイルアクセスNG、データベースNG)
- 中テスト: 1マシンの中で完結する(外部サービスアクセスNG、他サーバNG)
- 大テスト: 任意の場所で実行可能
