■ 1. AI登場後の開発現場の現状
- AIによる変化:
- コードの生産が超高速化し、品質も十分な水準
- 手でコードを書くことはほぼなくなった
- 高速化したのはコーディングのみ:
- V字モデルの実装工程は超高速化した
- 上流（企画・要件定義）や下流（システムテスト・運用評価）に行くほどAIの恩恵は小さい
- プログラマーの役回りの変化:
- 中間管理職やベンダー管理者のような役回りになった
- AIにコードを書かせて人間がレビューする形は、外注に投げて納品物を検収するのに近い
- 製造業に近づいたコーディング:
- 製造機械のボタンを押せば製品ができるように、プロンプトを入力すればコードができる
- 工場制手工業から工場制機械工業への転換に相当
- 工場制機械工業との違い:
- 同一品種を量産するのではなく、単一のコードベースを編集し続ける
■ 2. アジャイル開発を見直す動機
- 現在のアジャイル開発の成り立ち:
- リーンソフトウェア開発の影響が大きい
- AI以前に体系立てられたもの
- 問題提起:
- コードの生産が高コストだった時代の考え方を踏襲したままでよいのか
- 原典であるトヨタ生産方式（大野耐一の著書）を見直す
■ 3. トヨタ生産方式の要点
- 目的:
- 生産性の向上、さらに言えば原価の低減
- 生産性を上げるには徹底したムダの排除が必要
- 2本柱:
- ジャスト・イン・タイム
- 自働化
- ジャスト・イン・タイム:
- 在庫ゼロが理想で、必要な分だけを生産する
- 後工程が前工程に、必要なものを必要なときに必要な分だけ引き取りに行く
- 必要な分だけを作ればムダは出ない
- 大前提として、各工程は100%良品でなければならない
- 過剰在庫がムダである理由:
- 保管場所だけでなく、運搬と管理の手間も増える
- 時間の経過で破損や劣化が生じる
- 売れない・使えない不良在庫は損失になる
- 自働化:
- 前工程に異常が発生したら、生産ラインが全て自ずと停止する仕組み
- 異常があるのに他工程が動き続けると、中間在庫が積み上がる
- 例として前工程Bが異常停止すると、後工程は組立不可となり、稼働中のA・Cの部品が滞留する
- 作りすぎのムダ（みかけの能率と必要数）:
- フル稼働で月10万個生産すれば1個当たりの原価は下がる
- しかし需要が月7万個しかなければ、残りは過剰在庫になる
- 作りすぎのムダ（仕事の進みすぎ）:
- 生産能力に余裕があると手待ちが出る
- 空いているので次の作業をやってしまう
- その結果、手待ちが隠蔽され、ムダな生産も発生する
- 少人化:
- カイゼンで向上した生産効率の分は、むやみに生産量を増やさず少ない人数で済むようにする
- 余力の活用:
- 効率化で生まれた余力は、既存人員による内製化や新しい取り組みに充てられる
- 社員教育に割り当ててもよい
- 離れ小島をつくるな:
- 工場に作業員がポツンポツンといる状態はダメ
- 一人では人間同士のチームワークが取れない
- 一人だけの仕事でも複数集めてチームにする
- チームワーク、助け合い運動:
- 後工程が遅れたら前工程が手伝いに行く
- 全員が熟練工ではなく、新入社員もいる前提
■ 4. ソフトウェア開発への適用: 作りすぎのムダ
- 目的は原価の低減:
- AIでコード生産のスピードは上がったが、作りすぎのムダが生じていないかを問うべき
- 将来に備えたコードは在庫のムダ:
- AIによって、コードを生産することはもはや負担ではない
- 将来への備え、拡張性、別の使い方への対応といった名目のコードは在庫のムダになりうる
- そのコードが将来本当に使えるかは疑わしい
- AIがあるなら、必要になったときにコードを生成しても間に合う
- レビューの滞留:
- AI以後、レビューが滞留する話は本当によく出るようになった
- 後工程であるレビューが対応できないのは、生産が過剰になっているから
- これも在庫のムダ
- 少人化とレビュー工程のカイゼン:
- AIの分だけ生産量を増やすのではなく、少人化かレビュー工程のカイゼンを選ぶ
- AIによってできた余力をレビュー工程のカイゼンに振り分ける
■ 5. 各工程を100%良品にする
- Pull Requestの品質担保:
- Pull Requestを投げる際に品質を担保できているかが問われる
- コードをやみくもに量産するのではなく、レビュー負担を小さくすべき
- レビュー負担を減らす最適解はチームによって異なる
- 自動テスト、コード解析、CIの強化:
- AIが機能を壊しても検知できるようにする仕組みであり、自働化に相当
- テストがしっかりしていればレビューも楽になる
- テスト設計・テスト手法の学習:
- テストコードの量が多くても、テスト内容がダメなら意味はない
- AIによる余力を教育に配分する
- テスタビリティの高いコード:
- テストしやすい設計になっていなければ、自動テストは無理がある
- 静的検証の活用:
- テストに限らず、プログラミング言語自体の静的検証も有効な手段の一つ
■ 6. 離れ小島をつくらない開発体制
- 一人作業の問題:
- 一人で黙々と作業を続け、最後にPull Requestを投げられても困る
- コード完成前から要件や実装方針をすり合わせ、Pull Requestのビッグバンを避ける
- コーディング以外は速くなっていない:
- 上流・下流工程はAIの恩恵が小さく、実装だけが超高速化している
- デンキヤギでの実践:
- 2時間スプリントで工程間のギャップを吸収している
- 常にレビューし続けていれば、Pull Request時に確認することはほぼない
- ムダな機能や要件漏れなども早期に検知できる
■ 7. 結論: 生産性の正しい理解
- AI導入の効果と落とし穴:
- AIの導入は生産性向上・原価低減に間違いなく有効
- しかし作りすぎのムダは全てを台無しにする
- 「生産性」を誤用するな:
- コードを速く生産できること自体は生産性ではない
- 生産性は利益（価値）を労働量で割ったもの
- 今回扱わなかった論点:
- 2時間スプリントの詳細
- 1〜2週間のスプリント期間は長すぎること
- 試作・検証と本開発を明確に分離すべきこと
- 計画は常に変わり続けるものであること
- 原典を読むべき:
- 本内容はトヨタ生産方式（大野耐一の著書）のチェリーピックであり、原典を自分で読むべき
- 『ザ・ゴール』でもよいが、ページ数が多い