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

by hirokidaichi

Slide 1

Slide 1 text

大規模言語モデル時代の開発生産性開発生産性カンファレンス株式会社レクター/日本CTO協会広木大地

Slide 2

Slide 2 text

広木大地 1983年生まれ。筑波大学大学院を卒業後、2008年に新卒第1期として株式会社ミクシィに入社。同社のアーキテクトとして、技術戦略から組織構築などに携わる。同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。現在は、株式会社レクターを創業し、技術と経営をつなぐ技術組織のアドバイザリーとして、多数の会社の経営支援を行っている。著書『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』が第6回ブクログ大賞・ビジネス書部門大賞、翔泳社ITエンジニアに読んでほしい技術書大賞2019・技術書大賞受賞。一般社団法人日本CTO協会理事。朝日新聞社社外CTO。株式会社グッドパッチ社外取締役。自己紹介

Slide 3

Slide 3 text

INDEX 本日のアジェンダ生産性の定義と開発生産性なぜ頻度に着目されるのか大規模言語モデル時代にエンジニアは不要になるのか

Slide 4

Slide 4 text

そもそも生産性とはなんなのか。

Slide 5

Slide 5 text

ソフトウェアにおける開発生産性とは？

Slide 6

Slide 6 text

エンジニアのアイデンティティに届く問題定義が曖昧なままの議論は、エンジニアに対する「不信感の表明」だけになってしまう。生産性ってどうなの？ 💢

Slide 7

Slide 7 text

生産性はインプットとアウトプットの比率経営的な生産性は投入資源に対する獲得資源の比率投入資源 Input 獲得資源 Output 生産性＝

Slide 8

Slide 8 text

経営学的な生産性同じものをできるかぎり多く作るという生産量がものをいう時代の基準から徐々に推移物的労働生産性価値労働生産性付加価値労働生産性生産数従業員数製品価格x生産量従業員数付加価値額従業員数

Slide 9

Slide 9 text

ソフトウェア開発のアウトプットとは？ソフトウェアのアウトプットとして ”最適”なものは存在しない。ソースコードの行数プルリクエストの数 FPの量完了したストーリーポイント開発した機能の価値サービスの売り上げどれも一長一短があるエンジニア人数

Slide 10

Slide 10 text

なぜ、ソフトウェアの生産性評価が難しいのか

Slide 11

Slide 11 text

ソフトウェアは最も複雑な構造物「相互に連携しながら動作しつづける書物」は人類の叡智の集積地になっている。ソフトウェアは本質的には 2度同じものを持たない。抽象的な概念の同士の関連性が物理的制約を持たない複雑な構造物は抽象化によって隠蔽され、更なる複雑性を追加し続けることができる

Slide 12

Slide 12 text

ソフトウェアをとりまく性質開発生産効率は、実際には恐ろしいスピードで高まっているが、複雑性がそれを上回る。ソフトウェアの複雑性複雑性あたりのコスト社会の適応領域情報処理速度の増加を背景にソフトウェアの命令数は爆発的に増大。抽象化によって一人月で対応できるコストで作れる命令数は増大している。コストの低減により、社会課題の対応領域が増え続けている。

Slide 13

Slide 13 text

ソフトウェアは簡単になり続けている。同一のことをするのであれば、ソフトウェアは民主化され、簡単になり続けている。高水準言語データベースクラウド機械学習 Web フレームワーク IaaS ローコード LLM

Slide 14

Slide 14 text

複雑なソフトウェアへの機能追加同じ機能追加でも単純なソフトウェアへの追加と複雑なソフトウェアへの追加で難易度が異なる

Slide 15

Slide 15 text

開発生産性が難しい理由ソフトウェアは単位ができてもそれを簡単にする力学が働く。二度と同じものはつくらないので個数で評価できない。時代ごとに同じものは簡単になっていくが求められる水準は高くなっていく。複雑性が増大していくと、類似の機能であっても機能追加の難易度が上がる。作られたものがマーケットでどのような値打ちがつくかわからない。

Slide 16

Slide 16 text

そのため、”生産”の評価が難しい。

Slide 17

Slide 17 text

条件を絞ることで、便宜的に評価できないか。

Slide 18

Slide 18 text

開発生産性の3つのレベルソフトウェアの生産を3つのフェーズで分けて、評価できないか。 PRやコード行数など作業量を評価。それ自体に値打ちはつかないが、どれだけの「生産」ができたかを評価する。先行指標になる。仕事量生産性期待付加価値の生産性実現付加価値の生産性プロダクトとしてその機能にどれだけ価値が見込まれていたかを評価して、生産した価値の評価。工数をかけずに顧客価値あるものが作れるほど高くそれがマーケティングやセールスによって、実際に売り上げにつながって実現された時の評価。遅行指標になる。

Slide 19

Slide 19 text

開発生産性の3つのレベルと組織の関係

Slide 20

Slide 20 text

当たり前の話だが、開発部門だけで、売り上げを作るわけではない。

Slide 21

Slide 21 text

生産性を上げる生産をどう評価するか？開発効率が直接的に売り上げにつながるのではなく、それがの積み上げが優位を作る。機能開発が効率的にできる。十分に価値ある機能が開発できる。それが伝わり顧客が増える。売り上げが上がる。直接的には関係してない積上げ的に関連している

Slide 22

Slide 22 text

微分的な価値の段階売り上げ距離、売り上げ速度、売り上げ加速度

Slide 23

Slide 23 text

ビジネスは資産に関する微分方程式製造力の生産性に関する考え方では、ビジネスモデルの生産性は評価できない。資産利益 = フロー = P/L 利益速度=ビジネスモデル,顧客価値微分微分積分積分 g(t) g’(t) g’’(t) 利益加速度=ビジネス生産力微分積分 g’’’(t) Current Future 先行指標遅行指標製造力の生産性ビジネスモデルの生産性イノベーションの生産性

Slide 24

Slide 24 text

生産性のスペクトラムとKPI 現在価値将来価値 Engineering Manager Sales/Marketing Manager Product Manager 売上距離/収支売上速度売上加速度 P/L B/S GP KGI/KPI 担当者 ● 売上 ● 当期利益 ● 案件獲得数 ● アポ数等行動量 ● オペレーションコスト ● 優良顧客数 ● 顧客満足度 ● LTV ● 退会率/Churn ● アップセル/クロスセル率 ● 開発機能/開発価値量 ● テスト自動化率 ● デプロイ成功率 ● デプロイ数 ● ベロシティとその分散総生産力 gross productivity 継続して改善する確率が上がる継続して改善する確率が上がるに資する仕事に資する仕事に資する仕事

Slide 25

Slide 25 text

これら可視化し、改善するための便宜的なもの。

Slide 26

Slide 26 text

早い vs 速い

Slide 27

Slide 27 text

”生産性”って言いたいだけちゃうんかビジネス現場で人は「よく知りもしない概念」を持ち出して、それっぽいことを言う。なんか思ったより時間かかるなエンジニアの “生産性”が低いんじゃないのか？ちゃんと”マネジメント”できてる？ “生産量”を増やしたい？ある機能を”早く”リリースしたい？残業しないし、 Twitterみてるぞ？信頼関係があれば、具体的に議論できるコストは結構払ってるのに

Slide 28

Slide 28 text

スループットとリードタイム「速く」することとと「早く」することにはある程度のトレードオフがある。リードタイムスループット “リードタイム”は、開発を開始してから市場に投入されるまでの時間。ビジネスにとっての重要性が高い。 “スループット”は、単位時間あたりに生産できたアウトプットの量。生産性という言葉で注目されるのはココ。速さ。開発ライン

Slide 29

Slide 29 text

リソース効率とフロー効率コンビニレジは、並んでいるときは店員の稼働率が高いが、リードタイムは長くなる。稼働率やスループットを重視するリードタイムを重視するリソース効率フロー効率

Slide 30

Slide 30 text

リードタイムとビジネスの三階層リードタイム評価においてもビジネスの 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

Slide 31

Slide 31 text

一気に運ぶか価値の流れを作るか。

Slide 32

Slide 32 text

効率フロンティアを目指せ

Slide 33

Slide 33 text

DORA メトリクス(4 keys metrics) DevOpsにおける4つのキーとなるメトリクス(最近は5つ目もあるけど有名なのは 4つのやつ）

Slide 34

Slide 34 text

目標の構造と Fourkeys 目標は定性目標と定量目標、健全化指標の 3つによって表現される。定性目標  定量目標  健全化指標  共感しイメージを膨らませるための   ビジョンとしての目標   定性目標では曖昧になりがちな目指すべき姿をクリアにするための指標   定量目標によって、質的なバランスが崩れないように維持すべき指標   “高速で迅速な開発チーム ” リードタイムデプロイ頻度 MTTR デプロイ成功率

Slide 35

Slide 35 text

ソフトウェア開発における「嘘の進捗」プロジェクトの進捗は、ソフトウェアの不可視性によって見えなくなる。 20％完了です！あとは実装だけほぼほぼ完了ですたぶんいけます

Slide 36

Slide 36 text

アジャイルソフトウェア宣言これまでの「嘘の進捗」を生み出すものから、現物による「動く進捗と品質」への転換プロセスやツール  従来重視されてきたもの  これから重視していくべきもの  包括的ドキュメント  契約交渉  計画に従うこと  個人の対話  動くソフトウェア  顧客との協調  変化への対応 

Slide 37

Slide 37 text

1 3 2 4 ソフトウェア開発の本質的な難しさブルックスの名著「人月の神話 ―狼人間を撃つ銀の弾はない」より筆者によるまとめソフトウェアはその規模に対して複雑さが非線形に増大します。基本的にソフトウェアというものは一度作られたものであれば、再利用できます。そのため、どんな人工構造物よりも複雑になります。複雑性ソフトウェアは、文化・業務・経済環境・商習慣、顧客行動などさまざまな点に連動して、変わり続ける必要があります。当初の計画通りのシステムが出来上がったとしてもそれは利用者の要望により変わり続けます。可変性ソフトウェアは、それ単独で意味を成すものではなく自分自身を動作させるハードウェアや、ネットワーク、OS、その他のシステムなどと連携しながら、同調することで初めて意味をなします。同調性ソフトウェアは、目に見えません。抽象的な概念の相互関係であり、それは一般に技術者にしか理解できない言語で記述されます。そのため、ソフトウェアの構造を他の構造物とは違い見ることができません。不可視性

Slide 38

Slide 38 text

本質的なソフトウェアの生産とは不確実性のある環境への曝露 (Exposure)によって、不確実性が削減された時 ● 別システムとの統合 ● 受入テスト ● 関係者レビュー ● マーケットイン ● ユーザーレビュー ● 市場性調査関係者への曝露市場への曝露通信不確実性環境不確実性

Slide 39

Slide 39 text

不確実性に向き合う

Slide 40

Slide 40 text

プロジェクトも不確実性の削減過程 “不確実性コーン”はプロジェクトの本質的な意味を表現している。

Slide 41

Slide 41 text

不確実性に対してどれだけ曝露するか開発者マーケットステークホルダー deploy feedback 不確実性のある環境への曝露 (Exposure)によって、不確実性が削減された時

Slide 42

Slide 42 text

頻度は質に転化する

Slide 43

Slide 43 text

フロー効率を高める技術的投資継続的デリバリーを前提に自動化や効率化を徹底的に進めることで品質と価値効率を最大化する開発テストリリース開発リードタイムリードタイムプロダクト型プロジェクト型 CI/CDなどのデリバリー自動化への投資継続デリバリーを前提としたアーキテクチャ投資頻度は「質」に転化する。

Slide 44

Slide 44 text

ドラム式自動洗濯機の”良さ” 新しい「当たり前」となる習慣の価値は、使う前にはわからない。手洗いの方がよく落ちるよ全自動は信用できない干すのは手間じゃない洗剤は自分で入れる

Slide 45

Slide 45 text

大規模言語モデルで何が変わるのか。

Slide 46

Slide 46 text

実装してみたLLMツール実際に開発することで見えてきた LLMで開発効率をあげるためには：自然言語コマンドランチャー wanna 自然言語からbashスクリプトを自動的に生成して呼び出せるように保存するランチャー。コミットメッセージ生成 git aico ステージ上にある差分を全て読み込んで、そこからちょうどいいコミットメッセージを提案してくれる。

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

wanna think / コマンドを考えるコマンドソフトウェア開発のプロセス設計し、 AIと人間の役割を決めてステートマシンとして実装生成名前提案概要生成と保存反省とデバッグ指示出し実行保存追加指示指示リセット名前選択これまでの指示をまとめるレビュー保存フェーズ終了 Exit 問題があれば修正 LLM の仕事人間の仕事

Slide 50

Slide 50 text

AIが提案し、人間が決める自然言語を入力するのは意外とめんどくさい。だからできる限り ”意思決定”だけさせる。 LLM の仕事：実装したり提案したり人間の仕事：目的の提供と意思決定

Slide 51

Slide 51 text

メンバーが提案し、マネージャが決める AIと人間の関係は、メンバーとマネジメントの組織設計に似ている。メンバーの仕事：実装したり提案するマネージャの仕事：目的の提供と意思決定

Slide 52

Slide 52 text

AIエージェントのアーキテクチャより複雑なことをするエージェントは、人や外部環境から不確実性を摂取して活動する。 LLM 外部環境人間 action feedback function_callingでもっと楽にできる！

Slide 53

Slide 53 text

すべての人が AIをマネジメントするマネージャになる。

Slide 54

Slide 54 text

エンジニアは不要になるのか。

Slide 55

Slide 55 text

銀の弾丸はあるのか。

Slide 56

Slide 56 text

自動プログラミングとして言及されてきた技法は、つまるところ高水準プログラミング言語を使ったプログラミングの婉曲的表現である。 (デイビッド・パーナス)

Slide 57

Slide 57 text

英語(自然言語)は新しいプログラム言語だ。 LLMは新しいコンパイラだ。 Pythonは新しいバイトコードだ。 (Databricks共同創業者兼チーフアーキテクト Reinold Xin)

Slide 58

Slide 58 text

AIエージェントのアーキテクチャ Function Functional Agent Function Function Programming Functional Agent Functional Agent 関数を利用する関数的なエージェント、それらをさらに利用するエージェントと多層的に問題解決する sandbox上でLLMが生成したコードを安全に動かす Function

Slide 59

Slide 59 text

コードベースの改善をするエージェントの例ファイルを読むリファクタリングするファイルを編集する複雑性が下がりテストが通るまでリファクタリングしつづける関数として振る舞うエージェントを組み合わせて関数を構成することで複雑に動作させる。複雑なファイルを発見して優先順位をつけるコードベースの改善を行う大きなゴールを分割して統治する。テストを実行する複雑性を評価する

Slide 60

Slide 60 text

ソフトウェアエンジニアリングとは何か。ソフトウェアの持つ本質的問題に対する ”試行錯誤”がエンジニアリング偶有的な問題本質的な問題より小さくなるより大きくなっていく

Slide 61

Slide 61 text

LLM登場でソフトウェアの複雑性は増える社会の適応領域が増えると総需要が増える。ソフトウェアの複雑性複雑性あたりのコスト社会の適応領域情報処理速度の増加を背景にソフトウェアの命令数は爆発的に増大。抽象化によって一人月で対応できるコストで作れる命令数は増大している。コストの低減により、社会課題の対応領域が増え続けている。

Slide 62

Slide 62 text

これまでと同じ問題はより簡単になる。

Slide 63

Slide 63 text

個人はよりエンパワーされる。 AIに仕事を奪われるのではなく AIを使いこなす人との格差が広がる。

Slide 64

Slide 64 text

不確実性に向き合い本質的な問題の試行錯誤をしよう