開発生産性カンファレンス 2025 ２日目も参加しました！！
聴講したセッションを中心に感想を纏めます。
- イベントの概要
- １日目の参加ブログ
- セッション
- 1. 開発生産性向上の探求：DevOpsの進化、普遍的な原則、そして生成AIがもたらす変革
- 2. スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
- 3. 開発生産性を測る前にやるべきこと：組織改善の実践
- 4. コードのその先へ：開発者体験を活性化させる方法
- 5. 開発生産性を組織全体の「生産性」へ！部門間連携の壁を越える実践的ステップ
- 6. 開発生産性再定義：安定性が生む持続的な顧客価値
- 7. エンジニアが主体的にビジネスに貢献する〜開発現場からの変革
- 8. 開発内製化のその先へ―技術・組織の協調設計によるプロダクト付加価値向上の実践
- 9. AI時代のソフトウェア開発を考える
- ブース
- まとめ
イベントの概要
テクノロジーで生産性が変わる。
DXで産業が変わる。AIで未来が変わる。
この10年で必ず、世界は歴史的な変化を迎えます。そして、ソフトウェアのつくり方も、数十年に一度の大変革が訪れようとしています。
エンジニアの仕事やエンジニア組織の在り方は、今後どうなっていくのか？
人口減少していく日本社会において競争力をつくっていくためには、何が突破口になるのか？
キーワードは、今大きな注目集めている「開発生産性」です。開発生産性Conferenceは、海外・日本の開発生産性に関する最新の知見を集め、
各企業のベストプラクティスや開発生産性向上への取り組みを通して、
新しい時代の開発のヒントを提供します。
引用：
dev-productivity-con.findy-code.io
１日目の参加ブログ
セッション
1. 開発生産性向上の探求：DevOpsの進化、普遍的な原則、そして生成AIがもたらす変革
dev-productivity-con.findy-code.io
メモ
DevOpsムーブメント。
1980年代の製造業がアメリカに入り状況が一変した。
Lean原則の利用により、当時はできないと思っていた様々なことに活用ができるようになった。
今日話すこと。
・ DevOps研究の現状
・過去4年間で「成功する組織の構築」について得た教訓
・組織のつながりという観点からみたDevOps
・直近の取り組み ―生成AIと開発
DevOps研究の現状。
DevOpsのビジネス価値は我々の想定よりさらに高い。
ハイパフォーマンスは、１日に何回もデプロイする。
重要なことを素早くデプロイし、アウトカムを出している。
その実現にDevOpsが役に立っている。
ハイパフォーマーは仲間を導き、売上成長と相関関係にある。
どんな厳しい環境でもDevOpsの実現は可能である。
参考：
DevOpsには３つの魔法がある。
①誰もが重要な問題を常にオーナーシップを持って並行して解決し関係しあっている。
②あらゆる場所にフィードバックループが存在し、適切な相手に適切なタイミングでフィードバックを得て、学び続けられる。
③計画、実践、実験、改善のための十分な時間が確保されている。失敗から学び改善できる。プロセスから教訓を得て継続的に改善できる。
加えて、仕事には３つの層がある。
①目の前の仕事
②ツールや技術
③チーム構成と連携の仕方
製造業が最高の状態に向かったのは第３層目がキーだった。
システムの成長にとっても、第３層目が重要なポイントとなる。
第３層目の成功を実現するためのポイント。
・コヒーレンス（凝集）
・カップリング（連結・分離）
そのためには、ソシオテクニカルの達人がキーマンとなる。
ソシオテクニカルの達人の役割
・スロー化
一番危険な作業でもリスクを抱えられるように計画する。
例：
・シンプル化
他チームに依存せずオンデマンドに大規模な重要リリースを実現する。
日中のデプロイを実現する。
Amazonは取り扱う商品が増えたことにより相互依存が強くなっていった。
モノリスで身動きが取れなくなっていく中、
チームはAPIを通して相互にコミュニケーションを取れるように変えた。
・増幅
小さい問題が大きくなる前に解消する。
悪いニュースをあえて伝えることができ、聞くことができる環境をつくる。
問題を、特定の人たちのものではなく、全体のものとして扱えるようにする。
情報のやり取りには、生成、伝送、受信、対応、是正措置のステップに分解し、改善できるようにする。
現場の仕事を理解し、どんな障害を抱え、それを助けられるか理解できる状態とする。
・生成AIから得た教訓
今がとても楽しい。
コーディングのプロでなくても生産性をあげることができる。
バイブコーディングを通して、肉体的・物理的な障壁が解消された。
バイブコーディングでFAAFOが実現できる。速さ、目標、構築、楽しさ、選択肢を持てる。
企業がエンジニアに生成AIを渡していく必要がある。
但し、生成AIにも問題はある。
AIを利用することで、モジュラー型アーキテクチャ、高速フィードバックループ、学びの文化を通して、自信の強み弱みを増幅する。
秋に出版の書籍に纏めている。
感想
ジーン・キムさん、『The DevOpsハンドブック』からの学びを技術同人誌にするほど恩恵を受けています。
DevOpsの３つの魔法。付箋に貼っていつも目に見える場所に置いておきたいです。
スロー化、シンプル化、増幅。ソシオテクニカルを意識していきます。
2. スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
dev-productivity-con.findy-code.io
メモ
■Enechain
エネルギーマーケットプレイスを運営するスタートアップ。
電力は価格が安定しないのが難しい。リスクマネジメントが重要。
プロダクトは、eSquare。eScan。
ガバナンスとアジリティを重要視している。
プラットフォームについて。
複数レイヤでプラットフォーム機能を提供。プラットフォーム関連のチームも複数存在している。
開発組織の体制と役割について。21年頃は10人程度のエンジニア組織だったが、今は90人規模。
21年からSREDeskがありインフラの立ち上げをメインとしていた。
23年フロントエンドのデザインチームが生まれ、アプリ、データのPlatformチームが生まれた。
組織と役割について。
SRE：システムの信頼性
Platformエンジニアリング：クラウド領域を中心とした開発生産性
アプリケーションPlatform：アプリケーション領域の開発生産性
Security：セキュリティ
DataPlatform：データ基盤の提供
Designシステム：デザインシステム ※有志により構成
・良かったこと
早い段階で着手でき、タイミングが良かった。
逆にタイミングを逃すと実現できなかった可能性も感じている。
Platformチームはインフラとアプリの橋渡しにもなった。
チームの存在が負債の抑止力としても機能している。
採用もうまくいった。コミュニケーション力や大規模開発経験メンバーが戦力になった。
SREがインフラチームとしてサイロ化してしまっていたことは大変だった。
3Shake社に頼ることが大きかった。
結果的には事業的にも成功をした。
■3Shake
スタートアップの急速な成長を実現するため、サービスの信頼性を担保するためにはPlatformエンジニアリング、SREは重要。
但し、マネージドサービスの利用などにより、優先度としては低くなりがち。
結果、開発エンジニアが片手間で進めることがよくある。
Enechain社に対する支援内容。
組織・文化的側面。運用効率化。セキュリティ・ガバナンス。コスト最適化。
最新技術の活用。開発者体験の最適化。
最新技術の活用においては、enechain社のDevin活用に3Shakeも加わり模索した。
事業規模の拡大につれ、開発メンバーでの片手間での実現困難になっていく。
事業成長を止めないために、SRE、Platformエンジニアリングの構築が重要。
外部に頼ることも有効な選択肢になる。
感想
我々も開発エンジニアがAWSを操作しているので、3Shakeさんのお話に改めてPlatformチームの重要性を感じました。
DELTAさんのブースでのコストカットのお話を聞いた際同様に思いましたが、やっぱりインフラは開発の片手間にやるには複雑過ぎて粗は生まれるだろうし、持続可能性を担保するのも難しいと思う。
また、Platformエンジニアが存在することで技術的負債の抑止力になるという話、QAと似てると思いました。
先にテスト計画設計するとバグが抑えられる。
エンジニアの意識にいかにガードレールや標識を設けるかが重要なのかも。
多角的な支援の内容に改めて3Shakeさんの凄みを実感しました。
3. 開発生産性を測る前にやるべきこと：組織改善の実践
dev-productivity-con.findy-code.io
メモ
カオナビのCTO室は、プロダクト開発だけでなく長期的・横断的な視点での課題解決を担う。
・カオナビの組織改善の大きな流れ
創業2012年。15年にリプレース。17年に現行システム移行。19年に大カイゼン時代。
12年。100%外注だった。顧客ごとに機能カスタマイズしていた。
15年。売上重視、技術負債、運用不安定という要求からリプレースに乗り出した。
17年。サービスのスケールが容易になった。職能別組織が誕生。（企画⇒開発⇒QA⇒リリース）
マルチテナントSaaSは効果的だったが、組織的負債が顕在化してきた。
19年。セクショナリズム、期日コミットがゴール、超大作仕様書からのビッグバンという課題から、開発スピードは鈍化していった。
社内受託開発になっていたため、クロスファンクショナルチームに移行し、ミッションベースの組織に切り替えていった。
組織の変換をどのように実現していったか？
当時状況をヒアリングしていった結果、変化に適応しやすい体制を望む声や、純粋に仕事を楽しめない雰囲気があった。
また、同時にRSGTなどに所属するメンバーや、チーム開発の経験者が増えていた。
カイゼンの転換は、生産性を上げることではなく、下げないことを意識していた。
顧客中心主義の目的を前提にすることで、大きな目的に向き合う人が多くなった。
参考：
・事例効果
悪い傾向として、コミュニケーションのサイロ化が、職能間からチーム間に変化した。
それに対し、いくつかの施策を実施した。
OSTを毎月開催することでコミュニケーションを生み、チーム間の学び合いを生んだ。
他にも交流の場を作った。
価値提供スピードへの支援。FeatureToggleを導入した。
大きなモノリスだからこそ大きな効果があった。結果、開発者体験、リリース頻度が良くなった。
Package By Featureによる複雑性の管理。
モノリスの複雑度が嫌でマイクロサービスに行くのは現実的か分からず、モジュラー・モノリスにした。
改修範囲が明確化し、捨てやすくもなった。認知負荷が減っていった。
問題早期発見。
CTO室は重要だが緊急ではないタスクに取り組む。
やっていることのひとつにCTO室だよりがある。SPACEに基づいた指標を出している。
中長期課題を対応し続けている。（カモペンズ）
フロントエンド、バックエンドでの考える会を開催している。
Slackのワークフローで設計レビューをしている。
・採用広報教育
社内勉強会。カタリバ開発陣が集まる勉強会。３人いればなんとかなる。
外部向けのYoutube配信もしている。
カンファレンス参加推進。
愚直な組織改善を行ってきた。
どうやったら自然に話してくれるか。
横断課題の対応も進めた。
１つ１つの改善を大事にしている。
データ分析ももちろんしているが、そこを主軸にしないようにしている。
チーム間でのコミュニケーションに向けた支援もしている。
感想
吉羽さんのチームの進化についてのお話と重ね合わせて聴いていました。
職能別だとサイロが生まれるけど、フィーチャーチームも全体感を掴みづらくなる。
そのうえで、カオナビ社の実直な組織の進め方とエンジニアリング文化を学ぶことができました。
特にチーム間でのコミュニケーションを促進するためのOSTや勉強会を魅力に感じました。
モノリスを単純にマイクロサービスとしない判断の仕方も、大きなものを扱えない人間に細かいものを扱えるはずが無い的な発言に面白いと思いつつ、その通りとも感じました。
そうした人間的な判断が組織を進化させているイメージができました。
4. コードのその先へ：開発者体験を活性化させる方法
dev-productivity-con.findy-code.io
メモ
数字がすべてを物語っている訳ではなく、重要なのは指標ではない。
・生産性のパラドックス
評価基準によって行動様式が決まる。
アウトプットを指標にしてアウトプットが出ても、意味のあるアウトプットが出なくなる。
また、数値に表れないチームのコラボレーションはないがしろになる。
測定しやすいものだけでなく、意味のあるものを測定する必要がある。
・スピードと持続可能性
スピードを測るための指標は多くあるが、持続可能性は測定しづらい。
コード行数≠価値。コード行数だけを指標とすると誤った奨励となる。
有形な指標にのみフォーカスすると価値を見失いがちになる。（例：ストーリーポイント制度のゲーム化）
そうした指標を採用すると、悪いことにクリエイティブな問題解決からも意識が離れていく。
アクティビティは必ずしも生産性に繋がらない。
アクティビティではなく価値を測定する必要がある。
あまりにも生産性を求められるとエンジニアは燃え尽きてしまう。
数値には表れない貢献が軽視されると、エンジニアにストレスが溜まり、最終的には燃え尽きてしまう。
何が長期的なエンジニアのウェルビーイングに繋がるかを考える必要がある。
アウトプットを重視すると、誤った方向に行ってしまう。簡単にアウトプットを達成できる方針を採用しがちになる。
エンジニアに質の高いコラボレーション、イノベーションを求めるのであれば、価値を計測できる指標を追加する必要がある。
持続可能な生産性を実現するために必要となる要素。
①コラボレーション
コラボレーションは意図して実現する必要がある。
レトロスペクティブ、場と実態の明瞭化、明示的な期待、コミュニケーションの良し悪しのすりあわせ、プロジェクトのプレモーテルなどを実践する。
プロジェクトのプレモーテルについては、間違いそうなことを待つのではなく、予防していくことを重視することで実現する。
オーナーシップを持って取り組むことにより、チーム間での連携を取ることに繋がっていく。
②コミュニケーションと連携
チームが分散していくほど重要となる。
最初はプロジェクト管理ツールにより可視性・透明性を高めて進捗を追う。
目に見えない前提を明示化し、すりあわせることで、お見合いになる状況を無くす。
コンテキストのカスケード。トッププレイヤーだけが明確に状況を把握するのではなく、チーム全体でコンテキストを理解・共有している状態が重要。
そのために、会議を効果的に扱う。コミュニケーションを皆が同じ方向を向かうために取り組む。
③フォーカスタイム
エンジニアの成果が出ないことはスキルの欠如以上に集中力の欠如にフォーカスすべき。
４半期に一度のミーティングを設け、データに基づいたサイクルタイムなどを見て、フォーカスタイムが失われるタイミングを確認する。
ミーティングの優先順付けをし、参加メンバーや同期実施・非同期実施などの効果を見直す。
毎四半期ごとに集中を阻害するパラレルで行うタスクを少なくしていく。
④ツールとワークフロー
役割をはたしていないツールやワークフローは廃棄する。
定期的にチームに効果が無く、摩擦になるものを捨てていく。
KPIも有用なものだけを残していく。
ツールを減らすだけでも生産性はあがる。
⑤心理的安全性
開発者は常に複雑な問題の解決に当たっている。
ストレスのある状態でも、ポジティブになれる状態を作っていく。
心理的安全性が高いとエンゲージメントやデリバリーの質が高くなることが分かっている。
目標は実験として捉えることで、失敗の恐怖が下がり探索が促される。
誰かからのアイデア共有に対しては相手のペースを守るようにする。傾聴をすることで信頼性が高まる。
他者のアイデアは許容するだけでなく、歓迎すべき。興味を持ったコミュニケーションを取る。
結果、建設的なディベートを通じてよりよい考えとなり、お互いをリスペクトできる状態になる。
心理的安全性・パフォーマンスを上げ、学習ゾーンを目指していく。
⑥成長と啓発
明確で一貫性のあるキャリアパスを設ける。
クリエイティビティの向上のためにハッカソンやイノベーションウィークを設ける。
メンターシップを重要とする。
失敗を学びの機会としていく。そのことでチームがレジリエンスを持てるようになる。
マインドセットを転換していく。
より少なくやるのではなく、適切な仕事を適切なやりかたでやる。
そのために、
①今の評価を監査する。私たちが価値を置くものが私たちの振る舞いを決める。
②理由を問い直す。開発者体験と事業の成果は繋がっている。競争優位に繋がる。
③新しい指標を導入する。
④会話を始める。指標の定義をしていく。
・相乗効果を高めるリーダー
メンバー間、チーム間の相乗効果によって生産性を高めることができる。
そのために、
①リーダーが雰囲気を作る
②新しい言語の標準化
③心理的安全性
④模範を示す
⑤望ましい変化に合わせて評価する
⑥上流工程での持続可能なプラクティスを提唱する
ひとりがヒーローのように働き、その対価に高い報酬を支払うような制度を無くす。
そうではなく、開発者の活躍と成果を見えるようにしていく。
コラボレーションを賞賛する。
学びと失敗を透明性のなかで共有していく。スピードだけでなく質を重視する。
チームの価値の指標を設け、行動を補正していく。
持続可能なカルチャーを作っていく。
心理的安全性について。
Netflixでは、社員に対して高いハードルを設けている。その結果、解雇はある。
フィードバックを受けた上で、改善しない場合はそうした結果になる。
失敗は評価されているが、個人の前に会社のことを考えるように促している。
フィードバック文化により信頼関係は保たれている。
感想
今回のカンファレンスで繰り返されてきた内容や、よく聞く話ではあるとは思いつつ、Netflixのような先進的な企業でもそれが当たり前に重要視されていることを理解しました。
そのうえで、おそらく各層・各メンバーの行動レベルにまで落とし込まれ、一貫して意思決定や優先順位に反映されている状態なのだろうと想像しました。
相乗効果を高めることのできるリーダーでありたいと思いました。
5. 開発生産性を組織全体の「生産性」へ！部門間連携の壁を越える実践的ステップ
dev-productivity-con.findy-code.io
メモ
開発生産性の指標とビジネス上の指標はそのままでは比べられない。
時間軸が違うし、言語が違う。結果、開発生産性のレベル１と３では隔たりがある。
部門間での隔たりをなくすための共通言語を作っていきたい。
そのためには、
部分言語をどう作るか。
部分言語からどう共通言語を作るか。
共通言語からどう指標を作るか。
・部分言語の理解と構築
別組織の数値を理解するために、各部門のKPI・数値目的を徹底的に確認する。
kubellでは部門別でヒアリングを行い、決算資料を分析し、ダッシュボードを調査した。
営業利益の分解から考えた。
費用削減のアプローチはできたが、それだけでは持続的な成長は望めなかった。
そこで発見したのはEBITDAだった。
ソフトウェアは資産になり、収益性のあるプロダクト開発を実現することで貢献できる。
発見したものを言語化し、アウトプットをすることで、部分言語を実現した。
・共通言語の設計
部分言語を組み合わせることで相関マップを作り、接続の設計を行った。
相関関係を築くにあたっては、完全性を求めず仮説を出していった。
繋がりがありそうという抽象度でも、検証を重ねて判断を重ねた。
EBITDAをいかに増やせるかを考えた。
全職能の人がフロー効率を重視することで、資産計上ができる多くの施策の完了に貢献できるかを言語にした。
エンジニアの活動を工数に変換し、どう成果を出したかを見えるようにしていった。
これまで習得した部分言語をいかに見える化して広げていき、広げたものを対話を通じて共通言語にしていく。
・共通言語からの指標化
接続の設計と整合性を確立。
指標に対する期待と、どのような行動変容を求めるかを明瞭化した。
そのうえで、複雑にせず、多くを作らないことを重視した。
施策当たりの工数を出し、平均化することで傾向を掴んだ。
指標化にあたる注意点としては、因果関係があいまいになることや、抽象化と数値化のバランスがある。スモールスタートからの対話を通じて解消する。
一度作って終わりではなく、部門間での対話を重ねて生きた言語として成長させていく。
感想
エンジニアとビジネスで共通の指標を持つための実直な実験として聞くことができました。
不確実なものを捉えるためには、対話と実験を重視することが重要であると実感しました。
EBITDA初めて知りました。もっと理解したい。
6. 開発生産性再定義：安定性が生む持続的な顧客価値
dev-productivity-con.findy-code.io
メモ
Vertical SaaSは機能をどんどん積むことが価値が生まれる。
メディカルフォースでは、これからの産業の成長プロセスを合理化することをVisionとしている。
・生産性って何？
開発生産性とは、たくさん開発することか？
その前に何のために開発をしているかを考えないといけない。
顧客はなにをできればよいか？必ずしもリリース量が顧客価値と一致する訳ではない。
プロダクトを通じて顧客との信頼関係を築き上げること。
そのために必要なのは、安定性 * 顧客価値。
・安定性
マインドセットを安定性に寄せていく。
スピードよりも安定にフォーカスできるように会話をする。
安定していると
・未来を語れる⇒予測可能性が持てる
・生産性を守れる⇒長期的成長につながる
・負債の制御を可能にする⇒スピード低下を防げる。健全性と長期的な成長ができる
・組織連携を生む⇒協力的な組織体制を築ける
安定性は顧客からのプロダクトに対する信頼にもつながる。
盲目的にたくさんのコードを書いたり、リリースを繰り広げるのではなく、顧客のための行動にすべき。
・会社全体を開発組織に
スクラムを導入。経験主義 * リーン思考。
価値をどれだけ早く生み出せるが会社の成長に繋がる。
そのために、透明性、検査、適応を重視した。
適応：不確実性に打ち勝つ意思決定
検査：直面した不確実性についての正確な観測とそれらへの適応のメリデメを正確に把握
透明性：検査するためのチーム状態や直面している課題を見える状態にする
スクラムイベントでは、リファインメントを重視している。
スクラムでは、次のスプリントでやる透明性・検査・適応をスクラムイベントで担保する。
スクラム@Scalseを導入している。SMサイクルとPOサイクルがある。
１スプリントで開発とデリバリーを完了させることができる。
感想
生産性はコンテキストに依存することを学ぶセッションでした。
安定してスピードをあげるための取り組みに対するSMサイクルとPOサイクルのお話が興味深かったです。
リファインメントの重視も未来を安定させていく取り組みとしてイメージできました。
7. エンジニアが主体的にビジネスに貢献する〜開発現場からの変革
dev-productivity-con.findy-code.io
メモ
生産性とは？
技術的要素で語られがち。
それを高めること自体は悪いことでは無いが、技術レイヤで留まるとスコープが狭い。
生産性というと工業的なものをイメージするが、ソフトウェアは工業とは違い同じようなものを大量に作るわけではない。
ソフトウェアを提供することで解決される顧客の課題が顧客価値となる。
顧客課題が解決されればそこまで質は問題にならない。アウトカムが重要となる。
エンジニアがビジネスに貢献するためには？
顧客解像度をあげるために、直接エンジニアが顧客のところに出向く。
エンジニアはビジネスに向かっていくにあたり企画やKPIをたてがち。
それでは自分たちができることから出発することとなり、課題からの出発ができていない。
データを見ても何も始まらない。データは仮説の確認のために使うものである。
メンバーが現場に行くことで発見を得ることができる。
現場に行って、その場で話して、課題を聞くことで、課題解決に向けたモチベーションもあがる。
必ずしもエンジニアが営業的である必要はない。自分自身で一次情報を持ってくることが重要。
エンジニアから上がるレポートは解像度が高い。
営業とは違いエンジニアは機能の断面ではなく、システムとして課題を捉えることができる。
ただ、すぐ思いつく顧客課題に合いそうなテクノロジーを提案しても意味は無い。
エンジニアの訪問はディレクターが調整している。
今はオンラインミーティングでも話を聞けるので取り組みやすい。
それまでは、技術的な生産性が高いのに。顧客課題を解消できていないのではという懸念が大きかった。
ビジネスに貢献するためのエンジニア組織とは？
分業すればするほど駄目になる。分業することで部分最適が発生していく。
それを避けるために、役割分担をしないようにしている。
やり方が大事。マネジメントに意思決定は求められるが、相談に乗ることが大半。
エンジニア自身で何をどう作るかを考えて欲しかった。ディレクターが頑張れば頑張るほどエンジニアは受け身になっていく。
結果、エンジニアが顧客課題に対して能動的になっていった。ディレクターやPdMはエンジニアの支援役になる。
一気にやるとしんどいので、地に足付けて少しずつ始めていくのが良い。
お客さんとの距離感が遠ければ、まずはお客さんに近い人に話を聞くのでもよい。
感想
一休さんのエンジニア組織の魅力を味わいました。
エンジニアから上がるレポートが営業より解像度が高い話は、改めてエンジニアが作ったものをユーザーが作っているからだとイメージできました。
エンジニアがヒアリングすることでフィードバックを受けることができることにも魅力を感じました。
広義のストリームアラインドチームをイメージしました。
8. 開発内製化のその先へ―技術・組織の協調設計によるプロダクト付加価値向上の実践
dev-productivity-con.findy-code.io
メモ
■内製組織の立ち上げ事例
デジタライゼーションレイヤ、プラットフォームレイヤ、アプリケーションレイヤに分かれている。
プラットフォームには新旧世代がある。
旧世代は外部ベンダーのパッケージ製品を使っていた。
機能追加に制限があり、開発にかかる時間もかかった。機能追加には高い開発費が発生していた。
結果、ソフトウェアのコントローラビリティが低い状況にあった。
この課題解決のためにプラットフォームの内製化を始めた。
結果、最低限必要なコントローラビリティが獲得できた。
他の２つのレイヤにも柔軟に対応できるようになった。
ポイント
①コア業務・技術を中心に内製化を進めることで、変化に追随できる状況を実現した。
参考：
②フルマネージドサービスを積極採用し、事業の競争優位性に繋がる領域に経営資源を効率よく投下した。
■新チームでの課題設定
デリバリパフォーマンスの向上を通じ、さらなるコントローラビリティの向上に取り組んだ。
DORAのハイパフォーマーを目指した。
特にサービス復旧とデプロイ頻度に注力した。
サービス復旧：Googleクラウドの関連サービスから実施。
デプロイ頻度：テストカバレッジ可視化改善。PRごとに専用環境を構築。（Vercelに似た開発体験）
■プロダクト期待付加価値向上における改善
新規要件に対しプラットフォームチーム起因で期待付加価値の生産性が低い状態となった。
プラットフォームチームに対して、調整が必要なプロダクトチームが複数あった。
プラットフォームチームは共通のデータ・ロジックを持っており、基本的なREST APIしか持っていなかった。
PdMはスムーズにプロダクト間の連携を実現を望むのに対し、開発チームはもっと汎用的な実現を考えていた。
結果、典型的な合成の誤謬に陥っていた。
そんななか、InfoQに名前の挙がったソシオテクニカルアーキテクチャが参考になった。
テクニカルなシステムにフォーカスするだけではなく、組織システムに対してフォーカスする必要があった。
協調のフレームワーク、５つの特性を参考にした。
・目的の整合性（Aligned Purpose）
・共通の語彙（Shared Vocabulary）
・相互依存関係の明確化（Explicit Interdependencies）
・タイミングの同期（Synchronized Rhythms）
・進化への許容性（Permissibility of Evolution）
課題感が大きいのはコンウェイの法則とチーム領域。
逆コンウェイとThinest Viable Platformで解消を目指す。
感想
内製化に対する方針、チーム設計の考え方、実践からの学びの共有は勉強になります。
そして、２日目２度目となるソシオテクニカル。解像度を上げて理解するためにも学習の必要を感じました。
テクニカルな領域をAIが変えていくなかで、より広義なアーキテクト設計が重要になるとイメージしました。
9. AI時代のソフトウェア開発を考える
dev-productivity-con.findy-code.io
メモ
Tim O’Reilly "the end of programming"。
バイブ・コーディングという考え方が生まれた。
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…
— Andrej Karpathy (@karpathy) 2025年2月2日
最近ではcloud codeがプログラミングに対してインパクトを与えている。
今までは生成AIの利用は従量課金が前提だったが、cloud codeは定額制で利用できる。
その結果、定額なので料金を気にせず使えることで、生産性があがり続けている。
品質保証の観点では機能適合性の検証だけ行えばよく、コードレビューを省略することでスループットを最大化している。
今年は2025年の崖のだったが、既に解消されつつある。
「2025年の崖」問題の勝負の年、人類は保守不能なシステムをより高速に構築する手段を得ていた…… https://t.co/QzClUyp5h9
— Takuto Wada (@t_wada) 2025年7月2日
結果、今まではしばらく開発を進めてから顕在化していた問題が、短期間で一気に発生することになった。
適切な設計がされていればコーディングは些細な問題とする意見も出てきている。
・バイブコーディングの魅力と諸問題
プログラミングにおける問題は今までと変わらないが、問題の顕在化が圧倒的に早くなった。
・ソフトウェアエンジニアリングの諸問題
ソフトウェアエンジニアリングは時間で積分したプログラミングである。
多くの人で多くの時間で多くの課題に立ち向かっていくことが、ソフトウェアエンジニアリングである。
そこから今まで多くの学びがあった。
TDDからの学び。未知と既知の陣取りゲーム。設計に終わりが無い。リファクタリングを続ける。
DDDからの学び。ドメインエキスパートとの対話。ユビキタス言語。コードとモデル、コードとドキュメントが双方向。
リソース効率・フロー効率からの学び。ボトルネックの解消。コード⇒レビューとするとレビューがボトルネックに。ペアプロ、モブプロの効果が見えてきた。
ビルドトラップからの学び。新機能開発を増やすことへの盲信。大事なことはアウトカム。
・目指すべきはAIとソフトウェアエンジニアリングの融合
バイブコーディングvsエージェンティックコーディング。
参考：
cloud codeの自走力、並列で開発できる能力は圧倒的。
但し、並列で開発できてもそれだけでは意味がない。人間が扱える必要がある。
AIとの伴奏と委託というやり方を取る必要がある。
伴奏：AIと対話しながらの直列開発
委託：自走するAIたちに任せて並列開発
ドメインの各領域に対して、
コアドメインはAIと伴奏し、一般は製品購入や外部サービス利用、
一般または補完、補完エリアはAIに委託していく。
参考：
・AIを活用していくにあたり
バージョン管理はドキュメントもモノレポで管理する。
品質もバグゼロではなく、よりMTBFからMTTRへの志向を強めていく。
モブプロペアプロがキーではなくなる。
diffを小さくすると複雑性があがるため、構造変更を取り入れてレビュー不要な状態を実現していく。
・現実を見つめる
今はAIエージェントに熱のある状態。
ただ、人は往々にして最初から正しい設計ができない。
今まではコーディングを通して間違いを発見してきたが、今後はその機会がなくなっていく。
結果、自分でわからないことはレビューはできない。
AIは我々の能力を増幅してくれるが、無であるものを有にはしてくれない。
AIから引き出せる能力は組織の能力に依存していく。
能力をあげて、労力を減らすことを考えていく。
自分達の能力をあげるためにもAIを使っていく。
学びを続ける上で、AIは何回同じことを聞いても怒らない。
曖昧な質問からも専門的な知識に行きつける。
・賭けるか否か
抽象度が一つ上がることで、今やっていることが無駄になりそう。
コーディングは競争力を失うのか？コーディングをやめるべきか？
やめるのではなく、選択肢を広げて両睨みでいけばいい。
不確実な状況では、選択肢を狭めるのは危険。
・アマラの法則
世界は大きく変わることは前提。可能性を並べて探索していくのが良い。
感想
t_wadaさん改めて凄い。
いつも応援されているような励まされているような奮い立たされます。
可能性があると思うことを実践し、経験を得て、探索していくことが重要だと理解しました。
昨日の広木さんの知の探索。何も起こらなかった時のことを恐れた方が良いという話を思い出しました。
そして、コアドメインを自分達とAIの伴走で実施し、そうではない部分はAIに委託していくという話に未来をイメージし、いよいよもって私の慣れ親しんできた受託開発という文化は終わりを迎えつつあるのかもしれないと思いました。
そのうえで、探索し、実践し、経験し、学び、よりよい未来を目指していけるよう探索していきたいです。
ブース
本日もいろいろなブースでお話させて頂きありがとうございました。
プロダクトやサービスについてお聞きできたり、エンジニアリングの取り組みや課題感をお聞きできたり、自分の世界を広げることができました。
セッションを聞いて各社の取り組みに刺激を受けつつ、ブースでより現場に立脚したお話が聞けることに刺激と学びを頂いています。
そして、エンジニアの方が自企業のブースに立ってお話している姿は、事業とエンジニアリングの距離が近く見えて、とても魅力的に感じていました。
まとめ
最高で濃厚な２日間でした。
生成AI、指標への懐疑と目的志向、適切なフィードバックを適切な人が受けられる組織設計、事業領域への染み出し・対話の重要性、エンジニアリング文化の醸成、認知負荷の軽減。
改めて、開発生産性はコンテキスト次第で求めるべきものは変わっていき、それを捉えていく営みがいろいろな現場にあることを実感できました。
20代の終わりの頃にどこか遠い世界の話のように映った『イクストリーム・プログラミング』のケント・ベック登壇から、役割の分断が適切なフィードバックを阻害することを学び自分のアウトプットに大きなインパクトを与えてくれた『The DevOpsハンドブック』のジーン・キム登壇、そして、いつも大きな刺激と学びで勇気づけられているt_wadaさんまで。
こんな濃厚な時間を味わえるとは。エンジニア人生のなかで恐らくは一生記憶に残る二日間でした。
ジーン・キムさんのセッションで、ケント・ベックさんも客席にいるのを見かけた時の鳥肌ときたら。
そして、改めていろいろな方とご挨拶することができて嬉しかったです。
コンテキストの異なるエンジニア同士がお互いの領域を想定しながらコミュニケーションを取ることは認識できる世界が拡張すていくことだと理解しています。
純粋に、コミュニケーションできて嬉しい。知らない世界の学びを知れて嬉しいです。
吉祥寺.pmの新しいステッカーも頂くことが出来て嬉しいです。
嬉しいです…！！#開発生産性con_findy pic.twitter.com/uMMCQBIhnq
— 幡ヶ谷亭直吉@技術書典18さ05 (@asagayanaoki) 2025年7月4日
いろんなコンテキストの異なるエンジニアたちが集まって、いろんな方面での開発生産性を語り合って、それで楽しい１日だったと思えるのだから最高のイベントだと思いました。
Findyさん。いつも大きな学びと刺激をありがとうございます。世界を豊かにする一人として現場に持ち帰ります。
