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

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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

26. 早い vs 速い
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

34. 目標の構造と Fourkeys
    目標は定性目標と定量目標、健全化指標の
    3つによって表現される。
    定性目標

    定量目標

    健全化指標

    共感しイメージを膨らませるための
    

    ビジョンとしての目標
    

    定性目標では曖昧になりがちな目指す
    べき姿をクリアにするための指標
    

    定量目標によって、質的なバランスが崩
    れないように維持すべき指標
    

    “高速で迅速な開発チーム ”
    リードタイム デプロイ頻度
    MTTR デプロイ成功率
    

    View Slide

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

    View Slide

36. アジャイルソフトウェア宣言
    これまでの「嘘の進捗」を生み出すものから、現物による「動く進捗と品質」への転換
    プロセスやツール

    従来重視されてきたもの
 これから重視していくべきもの

    包括的ドキュメント

    契約交渉

    計画に従うこと

    個人の対話

    動くソフトウェア

    顧客との協調

    変化への対応

    

    View Slide

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

    View Slide

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

    View Slide

39. 不確実性に向き合う
    

    View Slide

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

    View Slide

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

    View Slide

42. 頻度は質に転化する
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

47. View Slide

48. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

55. 銀の弾丸はあるのか。
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide