開発生産性カンファレンス 2025 １日目に参加しました。
聴講したセッションを中心に感想を纏めます。
- イベントの概要
- イベント参加の背景
- セッション
- 1. オープニングセッション
- 2. 開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった
- 3. レベル1の開発生産性向上に取り組む─日々の作業の効率化・自動化を通じた改善活動
- 4. 開発組織の進化・スケーリングと「開発生産性」
- 5. 自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ
- 6. ソフトウェア品質を数字で捉える技術。事業成長を支えるシステム品質のマネジメント
- 7. 無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
- 8. ソフトウェアエンジニアリングの人類史 〜AI エージェント時代の知識創造企業〜
- 9. 事業成長を加速するエンジニアリング組織の構築：受託型から価値提案型への挑戦と失敗の軌跡
- 10. 大事なことは経営者の意識変革。トヨタグループ KINTOテクノロジーズ 代表が語るエンジニアが競争力の源泉である理由
- サイン会
- ブース
- まとめ
イベントの概要
テクノロジーで生産性が変わる。
DXで産業が変わる。AIで未来が変わる。
この10年で必ず、世界は歴史的な変化を迎えます。そして、ソフトウェアのつくり方も、数十年に一度の大変革が訪れようとしています。
エンジニアの仕事やエンジニア組織の在り方は、今後どうなっていくのか？
人口減少していく日本社会において競争力をつくっていくためには、何が突破口になるのか？
キーワードは、今大きな注目集めている「開発生産性」です。開発生産性Conferenceは、海外・日本の開発生産性に関する最新の知見を集め、
各企業のベストプラクティスや開発生産性向上への取り組みを通して、
新しい時代の開発のヒントを提供します。
引用：
dev-productivity-con.findy-code.io
イベント参加の背景
- 昨年参加の開発生産性Conferenceが最高だった。
- ケント・ベックに会える機会なんて人生の中でそうそうないはず。
- １日通して聞きたいセッションがあり朝から参加！！
セッション
1. オープニングセッション
メモ
「つくる人がかがやけば世界はもっと豊かになる」
日本のITのグローバル化を目指している。
Findyは挑戦するエンジニアをサポートするプラットフォームを開発する企業。
開発生産性カンファレンスは各企業のベストプラクティスを共有することで開発のヒントとする会にしたい。
将来的には日本だけじゃなくグローバルなイベントにしたい。
2025年テーマは、「作り方が変わる、未来が変わる」。
生成AIとの協働の時代に開発生産性をどう扱っていくか。
Findy社のテックリードによるPR数も直近Devinによるものが増えてきている。
Findy、本日からCM開始。
どんな時代も創る人が未来を切り開いていく。
生成AIの利用や開発生産性をあげることでイノベーションの数を増やしていき、未来の課題を解決していく。
感想
Findyさんがやっていることがいつも格好良すぎて刺激を頂いています。
CM、ドラゴンボールな中ブルマというのが素敵。
2. 開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった
メモ
開発者の生産性は、単純な問題ではない。
何かを良くしようとすると悪くなるということがある。
改良しようとして悪くすることがエンジニアリングにはよくある。
それが、AIの台頭によってより悪化している。
現実的な時間の制約以上にやるべき仕事があり過ぎる。
皆がそうした状況に直面している。
いくら生産性をあげても、そうした問題は付きまとう。
生産性をケント・ベックはジーニー（魔法のランプ）と呼んでいる。
・生産性の定義
生産性は比率である。生産性 = 出力 / 入力。
生産性を良い方向に使っていきたい。
マッキンゼーはレポートを作るにあたりナイーブだった。
レポートの内容はものごとを悪化するものばかりで役に立たないアドバイザーだった。
測定の問題。
ものごとを改良しようとしたのに、悪化するのはなぜか。
英国のグッドハート。測定値が目標になったら良い指標じゃなくなるという考え方がある
タイピングの速度を指標とした場合、それまで良い開発とタイピングに相関があったとしても、速度が目標値になることで本質からずれていく。
グッドハートの再解釈。指標が目標になった時点で良い指標ではなくなる。
観察できる統計的規則性は、制御目的で圧力が加えられると崩壊する傾向がある。
何も測定したくないわけではない。
開発プロセスを測定することに対しての価値は認めている。
測定・分析・解釈することで、ソフトウェア開発を理解したいと思っている。
ソフトウェアの素晴らしいところは純粋な知的アクティビティであること。
PR数をプログラマーごとに数えていくと、効果的に働く人とそうではない人に分けることができる。
よいプログラマーはより小さなPRを出している。
小さいPRは読みやすい。衝突しづらい。欠陥も少ない。
結果、チームでの協働がしやすくなり、ポジティブなフィードバックを回すことができる。
ただ、PR数が多いことを正として、エンジニアにプレッシャーをかけるとどうなるか？
より状況が悪くなる。最下位を避けることで、非効果的なPRが増えていく。
かつて、コードの行数が指標だった時があった。
同じように、やりたいことはコード行数を書くことでは無かった。
グッドハートは楽観的過ぎた。
指標は統計的には正しくてもプレッシャーを与えると一定性がなくなる。
一定性を作り出していた仕組み自体が壊れてしまう。
プレッシャーの伴う指標はシステムを壊す。
指標が多ければ多いほど、ひとつひとつのシステムに対する影響が分かりづらくなる。
一連の指標が整理されており、特に考えなくてもよい状態は心理的な不安を消すだろうが、クリエイティブにエンジニアリングができる状態からは離れていく。
指標によって柔軟な思考やクリエイティビティは無くなっていく。
新たな数値に対してプレッシャーをかけようとすると、
システムが本当に目指すべき目標を廃棄するだけでなく、目指すべきではない新たな目標を採用する。
まずはプレッシャーを軽減するために目標を放棄する。
次に指標を達成することが目的化し、良くない状況になる。
本番環境で障害0を目指すなら、障害報告をしないようになる。
新たな目標は本来目指すべき目標と乖離し、それを叶えることが焦点となると何も良いことが起こらない。
価値はEffort=>Output=>Outcome=>Impactとつながる。
測定値がシステムの目標を歪めることがある。
長い時間をかけてプログラミングすることは良くない結果を招く。（Effort）
結果、良くないシステムが生まれる。（Output）
ただ、右に進めば進むほど、そのことは計測しづらくなる。
Outputの効果の比較は、Outcomeから見ると比較しやすい。
（ボタンが２つある方が使いやすいか、１つの方が使いやすいかなど）
ただ、そこからEffortは見えない。
Impactから見ると収益の話になる。収益の指標からは開発者の生産性の評価は難しくなる。
ただ、そこから評価をすると、目標とすべき本質を捉えることができる。
生成AIをもとにFeatureを作る時間が減った。
今まで10時間かかっていたものをAIは1時間で作ってくれる。
でも、成果物が出来上がるまでの時間を指標にしているとシステムが歪んで行く。
少ないEffortでOutputを増加することはできるが、エンジニアにとっての学びは減る。
結果、長期的にシステムから得ることができる価値はさがる。
指標をもとに気づきを奨励することが重要となる。
プレッシャーを与えるのではなく、Developer自身に気づきを与えることが重要となる。
プッシュではなく、プルできる環境を作ることで、チームに目的意識を持たせる。
KPIは採っても、それをもとにチームを変えようとしない。
そうすることで、チームは大局観に立ち、共通の目的に進んでいくことができる。
感想
ケント・ベック最高！！！！人となりも含めて大好き過ぎました。
生では見れずサテライトで、サイン会では行列からあぶれてしまったけど、恐らく人生で一番ケント・ベックの近くにいることができた１日でした。
指標は成功の結果の背景にあるひとつの局面だけを捉えたものであって、エンジニアリングの価値を網羅的に捉えたものにはなり得ない。
エンジニアリングは指標で捉えられるほど、単純ではなく複雑で複合的なものであり、かつ時代のコンテキストと共に変化していくものであると改めて思いました。
そのうえで、指標については、その時その時でエンジニアが自分たちの調子をよりよくするために確認するメーターとして利用するぐらいが良いんだと改めて思いました。
メトリクスの話からは以前Autify末村さんのセッションで教わったGojko Adzicさんのお話も思い出しました。
3. レベル1の開発生産性向上に取り組む─日々の作業の効率化・自動化を通じた改善活動
dev-productivity-con.findy-code.io
メモ
好きな言葉：効率化
レベル１の開発生産性とは。
レベル１：仕事量の生産性／レベル２：期待付加価値の生産性／レベル３：実現付加価値の生産性
参照：
レベル１、事業の価値にそのまま繋がるわけではないが、重要。
エンジニアの負荷を取り除くことで向上することができる。。
そのために取り組んできたこと。
・自動化
・開発サポート
・情報共有の改善
ポストモーテム。対応に当たっていないメンバーとの温度差がある。
絵本にすることで、教訓として伝わらないか試してみた。
複雑な仕組みを体で理解するために。人間配信モジュールに。
PR管理の人間ボット。解決策は泥臭く。
制限するのではなく解決を。人によってリマインドをする。
こまめなレビュー文化や滞納が少なくなった。
面倒くさいことに敏感になり、日々の負荷を生成AIとともに解消していく。
感想
アウトプットを苦しめるための認知負荷やノイズをどう取り除くかのお話として受け取りました。
特にシステムの作りを体験として学ぶのは目から鱗でした。
システムの作りを覚えるだけでなく、チーミングとしても機能しそう。
チームの忘れられない思い出になりそうと聞いていました。
4. 開発組織の進化・スケーリングと「開発生産性」
dev-productivity-con.findy-code.io
メモ
企業は数字が大好き。けど、誤解をしている。
文脈の無いデータは無意味。
有効な測定基準を開発するためには現場についての深い知識が相当必要となる。
数字＝開発生産性。好きな人が多い。
生産性=産出 / 投入。産出 = 物的生産性。付加価値生産性。
ただし、人によって生産性など抽象的な考え方に対しての捉え方が違う。
そうなると、分かっているようで、実は分かり合えてはいない関係になる。
それを解消するために、コンテキストを揃える必要がある。
物的生産性 = チームが作れる数。効率。
付加価値生産性 = チームが生み出せる価値。効果。
組織やチームで自分たちの開発生産性についての定義が必要。
そのためにはコンテキストが重要となる。
プロダクトのステージや、チームの構成・役割で考える。
・プロダクトのはじまり。最初のチーム
仮説検証のための２、３人。少人数なのでプロセスもない。
仮説検証結果は成功／失敗で終わる。
優先すべきは、取り組む価値がありそうなネタを見つけること。
この後投資する必要があるかどうかを判断するために、顧客フィードバックが重要となる。
見なくていいもの。稼働率などの効率。コード品質。売上。
・プロダクト開発をはじめる。
ある程度人が増えるとプロセス（段取り）が必要となる。
１チームなのでアーキテクチャはモノリスになる。
優先すべきこと。プロダクトが成功に向かっていること。
プロダクトの価値は、プロダクトのチームの外に出さない限り分からない。
短い間隔で外に出して、チームの思い込みが無い状態を作っていく。共通理解を形成する。
優先しないこと。完璧な役割分断。プロセスの細分化。稼働率。
・プロダクトがうまくいき始めると人が増える
人を増えていく。
競合に負けないようマーケットシェアを押さえるための付随する仕事が増えていく。
足りないスキルセットを埋めていく。
優先すべきこと。プロダクト。リリース頻度やリードタイム。技術的負債。
やらなきゃいけないことが増えていく。セキュリティ。コンプラ。認知負荷をいかに下げるかが重要になる。
優先しないこと。ひとりひとりのタスク量の均等な割り振り。
人を増やしても課題が増える。生産量が増えなくなっていく。
・複数チームによるアジャイル開発への進化
フィーチャーチームとなる。チーム間の同期が重要となる。
スケーリングは難易度高い。多くのチームは
優先すべきこと。プロダクト。全体のスループット。阻害要因。調整ごとの最小化。
優先しないこと。チームの比較（全体が重要）
・そのままスケーリング（難しい）
開発者の認知負荷は増え続ける。チームの依存関係を減らし疎結合にする。
チームの分離。チームトポロジー。ドメイン、サービスで切り出し、アーキテクチャも見直す。
独立してそれぞれリリースできる状態を作る。境界を作る。ドメインごとに重要な要点が切り分けられる。
チームが分かれるとプロダクトを忘れる。ただ、最大の関心はプロダクトであるべき。
優先すべきこと。プロダクト。顧客価値への集中。チームの自律性と裁量。
優先しないこと。チーム間で合わせること。チーム同士の比較。
チームをどう分けるかはちゃんと設計する必要がある。
Platform切り出しがよくあること。結果、Platform自体がプロダクトになる。
サービス志向として利用者に提供できているかが重要となる。PaaP。
どれだけ機能作ったか、全チーム作っているか、などは関心毎にならない。
専門性の高い機械学習、AIを切り出す。ComplicatedSubsystemチーム。
ブラックボックスとなる。
優先すべきこと。問題解決の品質。デリバリータイミング。受発注に当たる健全性。
優先しないこと。他チームと同じやり方や指標。
支援系。Enablingチーム。
優先すべきこと。スキルトランスファー。サポート対象チームの成長・成果・自走。
優先しないこと。Enablingチーム自体の成果。
支援系は周りからしか評価ができない。
チーム構造はプロダクト開発を進めるにつれて必ず変わっていく。
但し、プロダクトは１つとは限らない。複数プロダクトの場合は違う話になる。
チームの構造は変わり続ける。
結果、チームごとにステージや関心事が違うため、開発生産性の意味はひとつの企業や組織での統一ができない。
見るべき指標はチームごとに違う。
初期のチームは定量的に測るのが難しい。
データは定性的でも良い。見せかけの数値で測るよりも良い。
プロダクトの利用状況は明らかにすべき。プロダクトに関心の重心を置く。
すべてのチームの状況においても見ておいた方がよい指標はエンゲージメント。
皆が安心して楽しく仕事ができることがどのステージでも意味がある。
ミッション、ビジョン、ゴールの明確化。OKRで明瞭にする。
数値の要不要についてチームで議論・判断する。
外からの提案はそのまま受け取らない。悪意があって言っていなくても、たとえ善意からでも余計な仕事になる。
各チームが自分たちで意味のある開発生産性を定義し、最大化することが重要。
自分たちでコントロールする。
感想
ケント・ベックが指標をプレッシャーとして扱うのではなく、エンジニアに気付きを与える程度のものが良いと言っていたのに対して、本セッションではその指標をエンジニアが自分たちで考え判断し扱っていく重要性を学びました。
外部から与えられた指標は背景や思想を失って機能しなくなるので、自分たちで考える必要がある。
エンジニアはどこかからきた要件を捉えるのではなく、ユーザーストーリーを捉えよって話と一緒じゃないか、と思いました。形式は本質を隠す。
気付けば、チームでDORAの4keysについて眺めたことはあるけど、自分たちにとっての開発生産性とは何かを会話したことがありませんでした。
自分たちのコンテキストに従って頭を絞って判断していく重要性を学びました。
5. 自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ
dev-productivity-con.findy-code.io
メモ
■ログラスのミッション
良い景気をつくろう。経営管理プロダクトを作っている。
メインユーザーは経営企画の方。
企業の予実管理はまだまだアナログなところが多い。
細かい状況を見切れず意思決定をしている状況。
ログラスはそうした情報を効率的に分析できる状態を作っている。
■これまでのログラス
ログラスの生産性カンファレンスは今回３回目。
去年はホールプロダクト開発について扱った。
チーム全体でプロダクトを捉えられるようにホールプロダクト開発を志向し、FASTに取り組んだ。
■FASTへの挑戦
前提となるログラス社の課題。
・ドメインの複雑さ×横断的体験の整合性
・パフォーマンス課題への継続的な対処
・認知負荷とチーム間連携のトレードオフ⇒フィーチャーチームによりサイロ化が生まれた。
デリバリー、ディスカバリー、双方が組織全体に向き合えるようにFASTに取り組んだ。
FASTはOSTから着想得ており、流動的なチーミングを実現する。
課題に対しての期待する効果が高く、チャレンジすることを決めた。
■１年間の学び
・流動性の解釈の深まり
FASTに取り組みはじめてからは各スロットで流動性高く人が動いていた。
FASTの運用が落ち着くと人の出入りは落ち着いていった。
既存事業と新規事業の流動性を期待していたが、FASTだからといって外部との出入りがしやすい訳ではなかった。
出力を高めるためにはコレクティブの安定性も重要だった。
スクラムよりも小さいチーム単位を構成できることを期待したが戦力が分散していった。
チームに充分なメンバーがそろっているかは重要な視点となった。
・自律性の解釈の深まり
過度の自律性への意識があった。
FASTでやっているから自律性が重要なわけではなく、基本的に自律性は重要。
ただ、FASTの大きな単位で自律性を捉えることは難しかった。
プロダクト全体に対してだれか一人の志向に依存するのではなく、全体で考えることを求めていた。
ただ、自律性を合議と捉えると歪んでしまう。
POがスタンスを取る=自律性を損なう、ではない。
・サイロの力学
スクラム時代にはチームごとのサイロがあり、コミュニケーションコストがあった。
FASTではスロットが生まれて、同じ傾向があった。
環境次第でサイロの力学は生まれる。チーム間の共同の視点が依然として重要となる。
・守破離の捉え方
守。普段の活動で重要視できている部分はあるが、そうでない部分もある。
価値基準が自然となじむまでには時間がかかる。
スクラムの透明性、検査、適応は定着している。
アンラーニングできていないともいえるが、バランスを考えたい。
破。ある程度開発の先々の見通しを立てる取り組みをしている。
流動性に対して抑える形にも向かっている。最善の形を模索できている。
■開発生産性にどう向かうか
大規模モノリスが前提。生産性の計測がスクラムでもFASTでも難しい。
プロダクトコードは線形的に増加しながら、一人当たりのコード変更量のペースは維持していきたい。
新規機能リリース、改善リリースはダウントレンドがあった。
開発規模の増加に伴い、非機能的な対応が増えている。
そうした中で生成AIはゲームチェンジャーになってきている。
FASTと開発生産性。
仕事量の生産性：アクションしやすく流動性によるフロー効率を高めることができている。
付加価値生産性：難易度が高い。取り扱う状況はできたが道半ば。
FAST導入によって得られた定性的な部分。
アジャイルに本質的に捉える取り組みができ、メンバーの外部発信も進んだ。
VPoEとしてのアカウンタビリティ。
組織の在り方を大きく変えたが、生産性が戻ってきている。
今までをアンラーニングし、どうすればアジャイルにできるか考えることができた。
生産性の測定では測ることができない組織としての学習という価値を得た。
短期の合理性も重要だが、長期目線の取り組みを維持する価値・文化・アイデンティティの強み作りを維持できるよう説明することがVPoEとしての責務。
今度エンジニアチームでの振り返りイベントもある。
感想
吉羽さんのフィーチャーチームになるとプロダクト全体を志向しづらくなっていく、という話の延長線上でお聞きすることができました。
その回答の一つがホールプロダクト開発であると理解しました。
良い景気を作るというミッションに対して、一丸となって試行錯誤できることが凄い。
そしてその実践からの学びの共有により、いつも大きな刺激を頂いています。
6. ソフトウェア品質を数字で捉える技術。事業成長を支えるシステム品質のマネジメント
dev-productivity-con.findy-code.io
メモ
タイミーではチームトポロジーをもとにしたチーム編成が行われている。
タイミーは生産性に対して、プロダクト主導型組織と戦略的意図で取り組んでいる。
・戦略的意図とプロダクトイニシアチブ
・プロダクトイニシアチブの実行効率
実行効率を高めるために開発生産性を位置づけている。
プロダクトイニシアティブを開発組織が爆速で維持でき、当たり前の品質を顧客に届けることができることがありたい姿。
システム品質と開発生産性は相互作用する関係として捉えている。
システムの品質とは？
利害関係者の明示・暗示的ニーズを満たす度合い。
品質特性ごとに品質の受益者は異なる。
生産性と品質。
システム品質を上げる取り組みはデリバリを加速させる。
プロダクトイニシアティブを爆速でデリバリし、当たり前品質を確立する。
タイミーでやっていること。
4keysは指標としてみてはいるが、数字自体にはそこまで意味を持たせていない。
ケイパビリティの判断と仮説検証の評価に利用している。
業績評価にも用いていない。
正の相関と自分たちの組織とのギャップを捉えるために利用している。
組織が大きくなっていくと専門的な組織の細分化が起こっていく。
安定運用が期待されるチームと、デリバリ・納期コミットが求められるチームとで対立関係が生まれやすくなる。
上位層での決定が働きづらい構造になりやすい。
ただ、それを正しく認識したうえで、開発生産性とのトレードオフにしないPlatformエンジニアリングチームを組成して対処している。
開発生産性をプロダクト開発に纏わる組織全体の関心事として扱えるように組織設計をしている。
４つの軸で生産性の実現を目指している。
観察、課題仮説、改善のフレームワーク、フィードバックループを回す。
フィードバックループ。
ソフトウェア品質の状態をエンジニア自体がフィードバックを受けられるように組織設計している。
フィードバックを楽に素早く受けれるようにする。
どこに生産性のボトルネックがあるかに目を向ける。
ボトルネック特定の切り口に目を向ける。
定性・定量の情報をもとに改善を繰り返す。
信頼性。
ユーザージャーニー軸、アーキテクチャ/データフロー軸で考える。
ボトルネック特定の切り口から課題仮説を持って検証・修正を繰り返す。
一次情報の観測から課題仮説を作る。そのために、定量・定性の一次情報を収集し続ける。
観測状況からよりよい状況に進むための仮設、アクションプランを立てて、実行し改善を繰り返す。
改善の道筋を立てるための指針については、課題仮説の切り口として巨人の肩にも乗る。
感想
速さと開発スピードのトレードオン。
エンジニアに対する品質のフィードバックを作ること。一次情報からの改善を繰り返すことを実直に行えること。丁寧さ真摯さ実直さを感じました。
CTO山口さんのブログも学ぶところが多かったです。
7. 無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
dev-productivity-con.findy-code.io
メモ
■無意味な開発生産性の議論。開発生産性という重圧
すぐ改善してと言われる重圧。なんとなく遅くないか？で生産性が取り上げられる。
・早さを求めるプレッシャーで、詰めるべき要件が煮詰まらないまま先に進んだり、品質が保証できないまま進んでしまう。
・小手先の指標が台頭しハックされていく。
・エンジニアだけが生産性を求められる。全体目線で見るべき。
■感覚に頼らない生産性低下の予兆検知
最初は全体像を捉える。
0=>1では健全だったソフトウェアがリリースを繰り返すことで変更容易性を失っていく。
それを解消するために、予兆検知、抑制、解消をしていく。
各工程・各領域をモニタリングし、どのプロセスがソフトウェアを悪くしているかを検知し、アラートを出す。
おすすめの４つのポイント。
1. 見積りと実績値の差分
超概算、詳細、開発、リリース時で差分を取る。
超概算から詳細（PRD/DD）の差分が大きい。
開発からリリース時も大きいが複合的要因が多く判断を見誤りがちになる。
2. 障害件数の再発防止策の完了件数
3. 投資している開発区分で予兆検知
正しいプロダクトに正しい工数を部門として投資できているか。
運用コスト大きくなってないか？リファクタリングに時間かけられているか？
4. エンゲージメントスコアの低下
■AIエージェントによる働き方の変化
今までは物理的に時間と人が同期していたが、AI誕生により人の物理的な時間と成果物とが非同期になってきた。
今は成果物のスピードに人間によるPRレビューが間に合わないが、それもAIが解消できる気がする。
そのなかで、人は何をするのか？
入口と出口を判断するガードレールは人が行う必要がある。
そのため、コードの読み書きのためのスキルは継続して必要となる。
品質を伴った生産量があがっていく。
結果、生産性の議論はなくなる気がする。
ただ、AIの活用有無によって企業ごとの優劣は大きくなっていく。
DMMでは開発フェーズのみではなく、リードタイム全体でAI活用を捉えられるようにしている。
AI-BPRを前提に作り直す。
結果、すべてのプロセスが開発生産性の議論に上がるようになる。
AI投資に対して、人員を増やすかどうかの話がある。
人を採用すると人件費がかかる。AIエージェントはライセンス費を出せばよい。
AIに対する投資対効果は、人の代替としての比較だけではなく、それ以外の使い方も含めた多元的な評価をする必要がある。
特にスピードだけでなく、品質を考える必要がある。
感想
生成AIの開発スピードにより、エンジニアの生産性の議論が無くなることを想像しました。
そのうえで、ビジネス全体でAIを活用した生産性を考える必要があることを理解しました。
そうした状況下で、エンジニアがどのような役割を担うかが重要だと思います。
自分がどうありたいかを常に考えていく必要があると感じました。
8. ソフトウェアエンジニアリングの人類史 〜AI エージェント時代の知識創造企業〜
dev-productivity-con.findy-code.io
メモ
私たちの働き方はどうなっていくのか。
AIによって人間の仕事は奪われるのか？いつだって人間の仕事は奪われてきた。
技術の進歩は常に人間の仕事を奪ってきたが、それは非人間的な仕事だった。
新しい技術にオープンマインドでいることが重要。
この20年でも技術は変わってきた。
メモリ管理が不要となり、データセンターとの契約が不要となり、OSのセットアップ不要となった。
ソフトウェアは常に簡単になり続けている。
目に見えないけどソフトウェアは安くなり続けている。
同じものを作ろうとしたとき、どんどん簡単になってきている。
ここ10年で5-10%は安くなり続けている。
ジュボンズのパラドックス。
ソフトウェアが簡単になるにつれて、社会への適応範囲が増えていっている。
仕事がどうなるかは、需要と供給が決める。
今まではソフトウェアの需要に比べて供給が追い付かない状態が続いていた。
文字とソフトウェア。
かつてのエジプトは文字を扱う人間は特権的な人間だった。
それが識字率があがり、文字が一般的なものになっていった。
ソフトウェアを書くことも当たり前になっていく可能性がある。
歴史的に観るとプログラミングは終わるかも知れないが、ソフトウェアは社会にとって当たり前なものになる。
現にUSのソフトウェアの求人は少なくなっている。
求人減少はマクロ経済と税制の要因が支配的。
不景気で求人が減る。その後、ジョブレスリカバリーが起こる。
景気が回復しても、雇用回復が遅れる。
企業は景気回復中に業務プロセスの改善や自動化を進めた結果、以前と同じ成果をより少ない人数で出せるようになった。
結果、生産性のために増員は不要と判断されていた。
生産性の改善サイクルと景気後退がかみ合うと、長期成長の発射台になる。
一次的には雇用減少するが、長期的な成長が生まれる。
結果、仕事は２極化する。高技能専門職と低技能サービス職に偏り、中間層の仕事がなくなる。
1/100になることはそこまで難しいことでは無い。
新技術を早期に触り継続してアウトプットすることで達成は可能。
変わってしまうかも知れないことを恐れるより、変わらないことを恐れた方が良い。
日本では労働力は高くなり、半導体は安くなっている。
人がやってきたことは機械に置き換えていった方が良い。
目的と手段の梯子があった場合、手段を半導体と置き換えていく。
組織を変革、成長、運用と構造化した場合、運用が半導体に置き換わっていく。
組織に求められることが変わる。
変革を作ることができる多様なチームが当たり前になっていく。
社会の一部が半導体と置き換わることで、ジョブディスクリプション型、OKR型の企業が多くなってきた。
人間の仕事は意思決定や判断が中心になっていく。
偶有的複雑性は解決しやすい状態となり、本質的な問題に取り組める状態になっていく。
AI時代の仕事について。
仕事の高密度化は今に始まった話ではない。
AIのアウトプットによる休みの無い仕事によってAI疲れが始まる。
HPよりMPが削られていく。
AI時代の生産性はどのように考えれば良いか？
効率化の視点が変わる。
標準化やマニュアル化から、可視化と最適化に。正しさの視点が変わる。
できる化。仕事を人に委譲できる状態にする。
自働化。人が動かなくてもよい状態にする。自動適応できるようにする。
自創化。仮説検証し、想像するフェーズも自働化する。
生産性改善のレベルを分ける。できる化⇒自動化⇒自創化をしていく。
レベル１：最低限のできる化。生産性改善0-5%。
レベル２：専門家bot化。生産性改善5-10%。
レベル３：社内ナレッジに紐づいた業務エージェント。生産性改善20-30%
レベル４：ワークフローインテグレーション。生産性改善40-60%。
レベル５：知識創造プロセスへの組み込み。生産性改善70-90%。
このように業務の効率化をすれば生産性はあがるのか？
生産性向上を組織として享受することが難しい。
タスク生産性によって、付加価値生産性を本当にあげられるかどうかに向き合う必要がある。
その場にとどまるには走り続けないといけない。
最終的には生産性は市場との総体優位によって生まれる。
両利きの経営。知の探索と知の深化。
技術的革新のタイミングでは新しい事業のために知の探索をウェイトを挙げる必要がある。
そのためには。組織を変革していく必要がある。
AI推進はボトムアップで進めるフェーズは終わり、人事戦略と統合して考えていく必要がある。
では、われわれはAI時代に何を付加価値とするか？
文字で起こったことが、ソフトウェアでも起こることが想定される。
・2000年代。記録による共同作業のためのシステム（SoR）
・スマホ登場以降。顧客とのコミュニケーションのためのシステム（SoE）
・AIエージェント時代。知識創造全体を自律的に行うシステム（SoK）
文字に起こった変革が早回しで起きていく。
SECIモデルと知識創造プロセス。
AIエージェントが介在した自動化を実現して、自創化を実現していく。
マクロの幻想より、ミクロの現実を見よう。
組織も個人も知の探索と知識創造システムへの投資で変化を味方にし、自らAIを使って走ることが重要になる。
感想
何も起こらなかった時を恐がった方が良い、が刺さります。
ボトムアップでのAIを活用できるようにし、人事戦略と統合した活用を考えていく必要性について、企業ごとの優劣が大きく出そうと思いました。
個人レベルでも生成AIを利用して、知の探索を実践し、これからの世界に適応していく必要があると実感しました。
9. 事業成長を加速するエンジニアリング組織の構築：受託型から価値提案型への挑戦と失敗の軌跡
dev-productivity-con.findy-code.io
メモ
食のサブスクを提供。大きくBtoB、BtoCに分けられる。
今回はOisixの話。
IT部門への要求の変化。
共働き世代に向けた時短ミールキットの需要があがった。
ビジネスのPDCAを回し、ミールキットを訴求し、QCDを守る。
コロナ禍はサービスを止めないことが重要視された。
コロナ後の反動減の状況を迎え、新しい価値を探求していくことが求められている。
そのための、事業に技術を適用することが求められている。
アウトカムに向けた取り組みをビジネスと考えていくことが求められている。
ビジネスに貢献といっても何から取り組むべきかが難しかった。
まず、事業部の人たちとの対話を始めた。
組織変更から始めた。領域ごとにPjMが事業部とのハブになり検討を始めた。
課題。議論に関われず、ストレスになることが多かった。
認められるためにやったこと。分析依頼を率先して受けデータに関わりドメイン知識を得た。
チームごと領域に取り組むようにした。PjMもPdMに。
課題。
・PdMの守備範囲が広くリソース不足に。開発側からビジネス側に寄せた。
結果、PjMも再度用意した。RACIチャートにより責務を定義した。
・技術的負債の解消が難しくなった。事業直結の価値を見える化して動きやすくした。
・横連携が難しくなった。横断的な定例会を設けた。
挑戦の先に見えてきたこと。
エンジニアからの提案と実行がでてきている。
感想
今回、自分の環境と一番近い開発組織の話として聞いていました。
事業領域でエンジニアが活躍していけるように試行錯誤していく実践こそが、エンジニアリング組織が成長していくことと学びました。
そうして、組織成長を試行錯誤できることも組織の強い意思を感じました。
10. 大事なことは経営者の意識変革。トヨタグループ KINTOテクノロジーズ 代表が語るエンジニアが競争力の源泉である理由
dev-productivity-con.findy-code.io
メモ
経営者目線でどうした意識改革が必要か。
40年以上前にトヨタ自動車に入った。
所属は転々としていた。現場が大好き。
KINTOはトヨタファイナンシャルサービス株式会社の直下になる。
2018年1月にトヨタ自動車はモビリティカンパニーへの変革を発表。
トヨタにいるとそれができないので、現状を変えるためにトヨタファイナンシャルサービスに移った。
車の貸し借りのためにもファイナンシャルに行く必要があった。
当初想定。車の利活用とオンラインで見る。コンビネーションでの実現を考えた。
KINTOからKINTOテクノロジーズを設立した。ソフトウェア資産手の内化と人的資産の最大活用。
トヨタとソフトウェアの給与体系も合わなかった。エンジニア用の制度を持ちたかった。
エンジニア出身ではない経営者の認識。
最初は分からないことだらけだったので人に任せた。
内製も外注も大きな意識の違いがなかった。
早く作ってもらうことしか考えず丸投げだった。
内製開発部隊と月次で業務報告、解説の場を設けていた。
繰り返すことにより、会話が噛み合うようになっていった。
その頃に会社を外に出したほうが良いと思ってきた。
一番最初の気づきは、丸投げシステムの拡張性の悪さ。
ツギハギだらけで全部捨てるしかなくなった。
反省点は意思決定の誤り。後から見れば重視すべきは拡張性だった。
とにかく会話してわからない部分は教えてもらうことで意識が変わっていった。
エンジニア目線と経営者目線でお互い分かるように話し合った。
エンジニアとコミュニケーションを柔軟にしていった。
エンジニアから気楽に提案があり、エンジニアのクリエイティビティを知った。
社員が会社のために気持ちよく働いてくれる状況を作るようにしている。
企業としては成果を出して細かい部分は捕らわれないようにしている。
エンジニアは自己評価が低い気がしている。
最初事業部が上から目線でやってきた。悪いことにエンジニアも下から目線だった。
健全な関係を築けるようにしている。
事業目線でのインパクトをエンジニアが意識できるようにしている。
エンジニアが事業を考えないと新しいものが生まれないと思っている。
ビジネスの現場を見てできることを提案できるようにしたい。
今はエンジニアから事業の提案も始まっている。企画ができる人間と一緒にプロトタイプを作り始めている。
社内で議論するぐらいなら、外に出していけるようにしている。
自分をフル活用したいエンジニアを募集している。
after partyあり。
kinto-technologies.connpass.com
エンジニアの実力値の認知がされていない。
その構造を打破すると活躍の仕方が変わっていく。
感想
KINTOさんの魅力を痛感しました。
エンジニアがオーナーシップを持って働くことができる環境の強さを感じました。
そして、それを実現できる企業文化を形成する重要性も学びました。
純粋にエンジニアの価値に対する信頼が嬉しかったです。そうした方が代表なのは本当に良い企業だと思います。
サイン会
ケント・ベックさんのサイン会は開始時間とともに現場に向かうと既に長蛇の列。
人数制限でサインを頂けず涙。数年単位で引きずる痛手でした。
そんななか、t_wadaさんに２冊サインを。うれしい。
SQLアンチパターン第一版が出た頃はちょうど新卒で入った企業から２社目に移る頃でした。
自分のプログラミングがどういったレベルなのかが分からず、SQLアンチパターンやリーダブルコードが大きな指針になってくれたことを覚えています。
第２版も読んで学びを深めます！！
ブース
多くの企業ブースや書籍販売ブースを回らせて頂きました！！
各企業様いろいろな取り組みをされていて面白いし、勉強になります。
まとめ
昨年に引き続き１日中楽し過ぎました。
エンジニアリングのことを考えるだけで楽しいのだから幸せな職業です。
ただ、昨年とは生成AIの取り扱われ方が大きく違うと思いました。
昨年までは生産性の4keysにいかに立ち向かっていくか、のようなテーマが多かったように感じますが、今年は4keysの話自体が少なかったように思えます。
それは、生成AI台頭により4keysに対するハードルは下がる、量から質、よりアウトカムにフォーカス時代になったからではと思いました。
（…と書きつつただの勘違いかもとも思っています）
生成AI時代において、個人的には事業やプロダクト領域にいかにエンジニアが染み出していくか、と、チームとしていかに有機的にプロダクト成長に関わっていくかが、重要にしたいポイントです。
本日聞くことができたセッションはどれもそれに対する実践を学べるもので、貴重な１日となりました。
かつ、それぞれのセッションが同一テーマを扱っているからか双方に影響のある内容も多く、１日を通して見えてくるものもありました。滅多にない体験です。
それにしても、最近、カンファレンスでご挨拶させて頂ける方たちが増えていることが本当に嬉しいです。
私にとっての開発生産性は、いろいろな方たちのアウトプットからの学びや刺激に依るところが確実に大きいと思っています。
ありがたいです。
明日も終日２日目参加です！！
