大規模言語モデル時代の開発生産性

開発生産性カンファレンスの講演内容です。

Transcript

1. 大規模言語モデル時代の開発生産性 開発生産性カンファレンス 株式会社レクター/日本CTO協会 広木大地
2. 広木 大地 1983年生まれ。筑波大学大学院を卒業後、2008年に新卒第1期として株式会社ミクシィに 入社。同社のアーキテクトとして、技術戦略から組織構築などに携わる。 同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。 現在は、株式会社レクターを創業し、技術と経営をつなぐ技術組織のアドバイザリーとして、 多数の会社の経営支援を行っている。 著書『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリン グ』が第6回ブクログ大賞・ビジネス書部門大賞、翔泳社ITエンジニアに読んでほしい技術 書大賞2019・技術書大賞受賞。一般社団法人日本CTO協会理事。朝日新聞社社外CTO。 株式会社グッドパッチ社外取締役。 自己紹介
3. INDEX 本日のアジェンダ 生産性の定義と開発生産性 なぜ頻度に着目されるのか 大規模言語モデル時代にエンジニアは 不要になるのか
4. そもそも生産性とはなんなのか。
5. ソフトウェアにおける開発生産性とは？
6. エンジニアのアイデンティティに届く問題 定義が曖昧なままの議論は、エンジニアに対する「不信感の表明」だけになってしまう。 生産性ってどうなの？ 💢
7. 生産性はインプットとアウトプットの比率 経営的な生産性は投入資源に対する獲得資源の比率 投入資源 Input 獲得資源 Output 生産性 ＝
8. 経営学的な生産性 同じものをできるかぎり多く作るという生産量がものをいう時代の基準から徐々に推移 物的労働生産性 価値労働生産性 付加価値労働生産性 生産数 従業員数 製品価格x生産量 従業員数 付加価値額 従業員数
9. ソフトウェア開発のアウトプットとは？ ソフトウェアのアウトプットとして ”最適”なものは存在しない。 ソースコードの行数 プルリクエストの数 FPの量 完了したストーリーポイント 開発した機能の価値 サービスの売り上げ どれも一長一短がある エンジニア人数
10. なぜ、ソフトウェアの生産性評価が難しいのか
11. ソフトウェアは最も複雑な構造物 「相互に連携しながら動作しつづける書物」は人類の叡智の集積地になっている。 ソフトウェアは本質的には 2度同じものを持たない。 抽象的な概念の同士の関連性が 物理的制約を持たない 複雑な構造物は抽象化によって隠蔽され、 更なる複雑性を追加し続けることができる
12. ソフトウェアをとりまく性質 開発生産効率は、実際には恐ろしいスピードで高まっているが、複雑性がそれを上回る。 ソフトウェアの複雑性 複雑性あたりのコスト 社会の適応領域 情報処理速度の増加を背景にソフトウェ アの命令数は爆発的に増大。 抽象化によって一人月で対応できるコストで 作れる命令数は増大している。 コストの低減により、社会課題の対応領域 が増え続けている。
13. ソフトウェアは簡単になり続けている。 同一のことをするのであれば、ソフトウェアは民主化され、簡単になり続けている。 高水準言語 データベース クラウド 機械学習 Web フレームワーク IaaS ローコード LLM
14. 複雑なソフトウェアへの機能追加 同じ機能追加でも単純なソフトウェアへの追加と複雑なソフトウェアへの追加で難易度が異なる
15. 開発生産性が難しい理由 ソフトウェアは単位ができてもそれを簡単にする力学が働く。 二度と同じものはつくらないので 個数で評価できない。 時代ごとに同じものは簡単になっていくが 求められる水準は高くなっていく。 複雑性が増大していくと、類似の機能であっ ても機能追加の難易度が上がる。 作られたものがマーケットで どのような値打ちがつくかわからない。
16. そのため、”生産”の評価が難しい。
17. 条件を絞ることで、 便宜的に評価できないか。
18. 開発生産性の3つのレベル ソフトウェアの生産を3つのフェーズで分けて、評価できないか。 PRやコード行数など作業量を評価。それ 自体に値打ちはつかないが、どれだけの 「生産」ができたかを評価する。先行指標に なる。 仕事量生産性 期待付加価値の生産性 実現付加価値の生産性 プロダクトとしてその機能にどれだけ価値 が見込まれていたかを評価して、生産した 価値の評価。工数をかけずに顧客価値あ るものが作れるほど高く それがマーケティングやセールスによっ て、実際に売り上げにつながって実現され た時の評価。遅行指標になる。
19. 開発生産性の3つのレベルと組織の関係
20. 当たり前の話だが、開発部門だけで、 売り上げを作るわけではない。
21. 生産性を上げる生産をどう評価するか？ 開発効率が直接的に売り上げにつながるのではなく、それがの積み上げが優位を作る。 機能開発が効率的にできる。 十分に価値ある機能が開発できる。 それが伝わり顧客が増える。 売り上げが上がる。 直接的には関係してない 積上げ的に関連している
22. 微分的な価値の段階 売り上げ距離、売り上げ速度、売り上げ加速度
23. ビジネスは資産に関する微分方程式 製造力の生産性に関する考え方では、ビジネスモデルの生産性は評価できない。 資産 利益 = フロー = P/L 利益速度=ビジネスモデル,顧客価値 微分 微分 積分 積分 g(t) g’(t) g’’(t) 利益加速度=ビジネス生産力 微分 積分 g’’’(t) Current Future 先行指標 遅行指標 製造力の生産性 ビジネスモデル の生産性 イノベーションの 生産性
24. 生産性のスペクトラムとKPI 現在価値 将来価値 Engineering Manager Sales/Marketing Manager Product Manager 売上距離/収支 売上速度 売上加速度 P/L B/S GP KGI/KPI 担当者 • 売上 • 当期利益 • 案件獲得数 • アポ数等行動量 • オペレーションコスト • 優良顧客数 • 顧客満足度 • LTV • 退会率/Churn • アップセル/クロスセル率 • 開発機能/開発価値量 • テスト自動化率 • デプロイ成功率 • デプロイ数 • ベロシティとその分散 総生産力 gross productivity 継続して改善する 確率が上がる 継続して改善する 確率が上がる に資する仕事 に資する仕事 に資する仕事
25. これら可視化し、改善するための 便宜的なもの。
26. 早い vs 速い
27. ”生産性”って言いたいだけちゃうんか ビジネス現場で人は「よく知りもしない概念」を持ち出して、それっぽいことを言う。 なんか思ったより 時間かかるな エンジニアの “生産性”が低いん じゃないのか？ ちゃんと”マネジメント”できてる？ “生産量”を増やしたい？ ある機能を”早く”リリースしたい？ 残業しないし、 Twitterみてるぞ？ 信頼関係があれば、具体的に議論できる コストは 結構払ってるのに
28. スループットとリードタイム 「速く」することとと「早く」することにはある程度のトレードオフがある。 リードタイム スループット “リードタイム”は、開発を開始してから市場 に投入されるまでの時間。ビジネスにとって の重要性が高い。 “スループット”は、単位時間あたりに生産 できたアウトプットの量。生産性という言葉 で注目されるのはココ。速さ。 開発ライン
29. リソース効率とフロー効率 コンビニレジは、並んでいるときは店員の稼働率が高いが、リードタイムは長くなる。 稼働率やスループットを重視する リードタイムを重視する リソース効率 フロー効率
30. リードタイムとビジネスの三階層 リードタイム評価においてもビジネスの 3階層を意識する必要がある。 ①backlog ready ②the issue in progress ③first commit ④merge to main ⑤running in production Lead time for changes デリバリのリードタイム Cycle time サイクルタイム Lead time for development 開発可能になってからリリースされるまでのリードタイム Lead time after management has made a decision 経営が意思決定をしてから、リリースされるまでのリードタイム delivery coding
31. 一気に運ぶか価値の流れを作るか。
32. 効率フロンティアを目指せ
33. DORA メトリクス(4 keys metrics) DevOpsにおける4つのキーとなるメトリクス(最近は5つ目もあるけど有名なのは 4つのやつ）
34. 目標の構造と Fourkeys 目標は定性目標と定量目標、健全化指標の 3つによって表現される。 定性目標
 定量目標
 健全化指標
 共感しイメージを膨らませるための 
 ビジョンとしての目標 
 定性目標では曖昧になりがちな目指す べき姿をクリアにするための指標 
 定量目標によって、質的なバランスが崩 れないように維持すべき指標 
 “高速で迅速な開発チーム ” リードタイム デプロイ頻度 MTTR デプロイ成功率
35. ソフトウェア開発における「嘘の進捗」 プロジェクトの進捗は、ソフトウェアの不可視性によって見えなくなる。 20％完了 です！ あとは 実装だけ ほぼほぼ 完了です たぶん いけます
36. アジャイルソフトウェア宣言 これまでの「嘘の進捗」を生み出すものから、現物による「動く進捗と品質」への転換 プロセスやツール
 従来重視されてきたもの
 これから重視していくべきもの
 包括的ドキュメント
 契約交渉
 計画に従うこと
 個人の対話
 動くソフトウェア
 顧客との協調
 変化への対応

37. 1 3 2 4 ソフトウェア開発の本質的な難しさ ブルックスの名著「人月の神話 ―狼人間を撃つ銀の弾はない」より筆者によるまとめ ソフトウェアはその規模に対して複雑さが非線形に増大しま す。基本的にソフトウェアというものは一度作られたものであ れば、再利用できます。そのため、どんな人工構造物よりも 複雑になります。 複雑性 ソフトウェアは、文化・業務・経済環境・商習慣、顧客行動な どさまざまな点に連動して、変わり続ける必要があります。当 初の計画通りのシステムが出来上がったとしてもそれは利用 者の要望により変わり続けます。 可変性 ソフトウェアは、それ単独で意味を成すものではなく自分自 身を動作させるハードウェアや、ネットワーク、OS、その他の システムなどと連携しながら、同調することで初めて意味をな します。 同調性 ソフトウェアは、目に見えません。抽象的な概念の相互関係 であり、それは一般に技術者にしか理解できない言語で記述 されます。そのため、ソフトウェアの構造を他の構造物とは違 い見ることができません。 不可視性
38. 本質的なソフトウェアの生産とは 不確実性のある環境への曝露 (Exposure)によって、不確実性が削減された時 • 別システムとの統合 • 受入テスト • 関係者レビュー • マーケットイン • ユーザーレビュー • 市場性調査 関係者への曝露 市場への曝露 通信不確実性 環境不確実性
39. 不確実性に向き合う
40. プロジェクトも不確実性の削減過程 “不確実性コーン”はプロジェクトの本質的な意味を表現している。
41. 不確実性に対してどれだけ曝露するか 開発者 マーケット ステークホルダー deploy feedback 不確実性のある環境への曝露 (Exposure)によって、不確実性が削減された時
42. 頻度は質に転化する
43. フロー効率を高める技術的投資 継続的デリバリーを前提に自動化や効率化を徹底的に進めることで品質と価値効率を最大化する 開発 テスト リリース 開発 リードタイム リードタイム プロダクト型 プロジェクト型 CI/CDなどのデリバリー自動化への投資 継続デリバリーを前提としたアーキテクチャ投資 頻度は「質」に転化する。
44. ドラム式自動洗濯機の”良さ” 新しい「当たり前」となる習慣の価値は、使う前にはわからない。 手洗いの方が よく落ちるよ 全自動は 信用できない 干すのは 手間じゃない 洗剤は 自分で入れる
45. 大規模言語モデルで 何が変わるのか。
46. 実装してみたLLMツール 実際に開発することで見えてきた LLMで開発効率をあげるためには： 自然言語 コマンドランチャー wanna 自然言語からbashスクリプト を自動的に生成して呼び出 せるように保存するラン チャー。 コミットメッセージ生成 git aico ステージ上にある差分を全て 読み込んで、そこからちょうど いいコミットメッセージを提案 してくれる。
49. wanna think / コマンドを考えるコマンド ソフトウェア開発のプロセス設計し、 AIと人間の役割を決めてステートマシンとして実装 生成 名前提案 概要生成と保存 反省とデバッグ 指示出し 実行 保存 追加指示 指示リセット 名前選択 これまでの 指示をまとめる レビュー 保存フェーズ 終了 Exit 問題があれば修正 LLM の仕事 人間の仕事
50. AIが提案し、人間が決める 自然言語を入力するのは意外とめんどくさい。だからできる限り ”意思決定”だけさせる。 LLM の仕事：実装したり提案したり 人間の仕事：目的の提供と意思決定
51. メンバーが提案し、マネージャが決める AIと人間の関係は、メンバーとマネジメントの組織設計に似ている。 メンバーの仕事：実装したり提案する マネージャの仕事：目的の提供と意思決定
52. AIエージェントのアーキテクチャ より複雑なことをするエージェントは、人や外部環境から不確実性を摂取して活動する。 LLM 外部環境 人間 action feedback function_callingで もっと楽にできる！
53. すべての人が AIをマネジメントする マネージャになる。
54. エンジニアは不要になるのか。
55. 銀の弾丸はあるのか。
56. 自動プログラミングとして言及されてきた技法は、 つまるところ高水準プログラミング言語を 使ったプログラミングの婉曲的表現である。 (デイビッド・パーナス)
57. 英語(自然言語)は新しいプログラム言語だ。 LLMは新しいコンパイラだ。 Pythonは新しいバイトコードだ。 (Databricks共同創業者兼チーフアーキテクト Reinold Xin)
58. AIエージェントのアーキテクチャ Function Functional Agent Function Function Programming Functional Agent Functional Agent 関数を利用する関数的なエージェント、それらをさらに利用するエージェントと多層的に問題解決する sandbox上でLLMが生成した コードを安全に動かす Function
59. コードベースの改善をするエージェントの例 ファイルを読む リファクタリングする ファイルを編集する 複雑性が下がりテストが通るまで リファクタリングしつづける 関数として振る舞うエージェントを組み合わせて関数を構成することで複雑に動作させる。 複雑なファイルを発見して 優先順位をつける コードベースの改善を行う 大きなゴールを 分割して統治する。 テストを実行する 複雑性を評価する
60. ソフトウェアエンジニアリングとは何か。 ソフトウェアの持つ本質的問題に対する ”試行錯誤”がエンジニアリング 偶有的な問題 本質的な問題 より小さくなる より大きくなっていく
61. LLM登場でソフトウェアの複雑性は増える 社会の適応領域が増えると総需要が増える。 ソフトウェアの複雑性 複雑性あたりのコスト 社会の適応領域 情報処理速度の増加を背景にソフトウェ アの命令数は爆発的に増大。 抽象化によって一人月で対応できるコストで 作れる命令数は増大している。 コストの低減により、社会課題の対応領域 が増え続けている。
62. これまでと同じ問題は より簡単になる。
63. 個人はよりエンパワーされる。 AIに仕事を奪われるのではなく AIを使いこなす人との 格差が広がる。
64. 不確実性に向き合い 本質的な問題の試行錯誤をしよう