ボトルネックを探せ！個別最適で終わらないソフトウェア開発へのAI導入
はじめに
ClaudeやCodexなどといったAIコーディングエージェントの登場により、ソフトウェアの実装は明らかに速くなりました。しかし、それをリリースまでのリードタイムの短縮や頻度の向上につなげられるかどうかは、組織によって大きく異なっています。コードを書くというのは、機能が利用者に届くまでのプロセスの一部でしかないのです。
AI導入は工程ごとの道具の話ではなく開発プロセス全体を組み替える話だ、という指摘はすでに各所で語られています。では、組み替えるとして、どこから手を付ければよいのでしょうか。何が変われば、リリースまでの時間が実際に縮んだと言えるのでしょうか。組み替えた形を、どうやって維持していくのでしょうか。
このブログでは、AIをシステム開発に導入するための考え方について話をしていきたいと思います。
リードタイムのどこが詰まっているか
一つの変更が、アイデアの着想からリリースに至るまでの時間は、各工程の作業時間の合計ではなく、最も長く滞留する場所でほぼ決まります。実装だけを速くしても、その手前にある要件定義や仕様合意、後ろにあるレビューやQA、リリース判断が変わらなければ、届くまでの時間は短くなりません。前後の工程で処理できる量が変わらなければ、単に待ちが増えるだけです。
待ち行列が長くなれば、一件あたりの滞留時間も一緒に伸びます。開発者の体感では「自分の手は速くなった」、組織の実感では「リリースの頻度は変わらない」という冒頭のギャップは、ここで生まれています。
意思決定者にとって、これは測り方の問題でもあります。効果を生成された行数やプルリクエストの数で測れば、導入は成功したように見えます。しかし、着想からリリースまでのリードタイムや、単位期間あたりに届けられた変更の数で測ると、まだ何も変わっていないことが多くあります。指標を後者に置き換えないと、次にどこへ投資すべきかが読み取れません。どの工程に費用をかけるかを決めるための情報が、前者の指標には含まれていないからです。
ボトルネックを探せ
ある日、急に実装速度が二倍になったとします。しかし、もし何を作るか決まっていなければ、開発者は手持ち無沙汰になるだけです。
では、バックログに実装待ちが積み上がっている状況を考えましょう。すると、今度はレビュー待ちが増えていきます。レビューできる人の数も、一人が一日に読める差分の量も変わらないまま、レビューを待つ変更だけが増えるからです。
これは、ボトルネックがコーディングからコードレビューに移ったことを意味します。レビュアーを増やしたり、レビュー観点をしぼったり、変更の要約や指摘の下書きをAIに任せたりする手が考えられます。あわせてCIのマシンパワーを増やす必要があるかもしれません。そして、レビューの問題が解消したら、次はおそらくQA待ちが増えるでしょう。
このようにボトルネックは次々と動いていき、AIエージェントの性能も向上を続けるので、改善のループを回し続ける必要があります。
工程の境界に残る受け渡し
では、各工程にAIエージェントを入れれば済むかというと、それでは足りません。工程の中の作業をいくら速くしても、工程と工程のあいだにあるものは、そのまま残るからです。
ここで言う受け渡しとは、仕様書やチケット、レビュー依頼、QAの手順書、リリース判断のための説明といった、次の工程に渡すためだけに作られる中間生成物と、それを受け取った相手が着手するまでの待ちを指します。リードタイムの中で大きいのは、多くの場合こちらです。一件の変更を実装する二時間より、レビューを依頼してから見てもらえるまでの二日のほうが長くなります。工程単体の高速化が全体に届きにくいのは、削っているのが短いほうだからです。
だとすると、効く打ち手は二種類に整理できます。工程の境界そのものを動かすか、境界をまたぐときの受け渡しを減らすかです。
境界を動かす例として、軽微な仕様変更がすべて開発者のキューに積まれている状況を考えます。依頼を書き、順番を待ち、実装され、意図どおりか確認する、という往復が一件ごとに発生しています。ここでプロダクトマネージャがAIを動かして変更そのものを作り、開発者はレビューだけを担当する形にすると、依頼と着手待ちの往復が一度なくなります。作業が速くなったのではなく、工程の境界が一つ後ろへ動いています。
受け渡しを減らす例は、上流と下流の両方にあります。
上流では、要件を言葉で詰め切ってから実装に渡すかわりに、AIでプロトタイプを速く回し、動くもので合意する形が取れます。仕様書という中間生成物を経由した往復が減り、合意の対象が文章から動作に変わります。開発者が営業に同行して要件理解を深めたり、顧客側に入って開発するフォワードデプロイドエンジニア（FDE）として課題発見から手掛けたりするのも、この一種です。いずれも以前から行われてきたことですが、動くものを用意する手間が下がったぶん、取りやすくなりました。
下流では、QAの手順書を、仕様と実際の差分から起こさせる形が取れます。
開発とQAが同じ変更を別々の表現で書き起こし、後から突き合わせる手間が減ります。
どちらも、工程の中の作業効率を上げる話ではありません。境界をまたぐたびに発生していた翻訳と待ちを、一段減らす話です。工程の中を速くする導入と、工程の境界を薄くする導入は別物で、リードタイムに効きやすいのは後者のほうです。
理想のプロセスを先に描けない事情
境界の動かし方が分かるなら、理想のプロセスを定義して一気に移行すればよいのではないでしょうか。しかし、その進め方は取りにくいのが実情です。
モデルの得手不得手が数か月で入れ替わるからです。プロセスを設計するときには、「AIに任せられること」と「人間が持つこと」の線引きを前提に置きます。役割分担も、工程の区切り方も、受け渡しの形も、その線引きの上に組み上がります。線引きが動けば、その上に組んだものが揃って前提を失います。半年かけて理想形へ移行し終えたころには、移行の前提のほうが先に変わっています。
現実解は漸進的なものになります。上流から下流までを一度並べて見渡し、待ちの大きいところから順に解消していきます。一つ解消すると、こんどは別の場所が最も長い滞留になります。
自社の開発対象と体制による違い
いままで、システム開発のボトルネックは、ほとんどの場合コーディングでした。そのため、多くの組織が開発者の採用を進め、手厚いサポートで作業に集中できる環境を整えてきました。しかし、これは変わりつつあります。
では、次にどこが詰まるかは、それぞれの組織によって違います。まず、開発対象の性質に依存します。利用者に直接届くプロダクトか業務システムか、規制や監査で求められる検証がどれだけ重いか、抱えているレガシーがどれだけあるか。体制でも変わります。開発者の人数、役割分担の細かさ、外部への委託の有無、レビューを誰が担っているか。
同じ「AI導入」という言葉でも、レビューが詰まっている組織と仕様合意が詰まっている組織とでは、打つ手が重なりません。前者ではレビューの負荷を下げる仕組みが効き、後者では上流でのプロトタイピングが効きます。入れ替えて適用すると、どちらもほとんど効きません。
他社の成功事例をそのまま持ち込んでも成果が出にくいのは、このためです。事例が効くのは、詰まっている場所が偶然そろっているときに限られます。どの工程から触るべきかを一般解として示せる銀の弾丸はなく、自社の工程を並べて確かめるところから始めるしかありません。
まだ答えを持っていない三つの問い
この進め方には、容易に解けない問題があります。
一つめは、詰まっている場所をどう見つけるかです。チケットが未着手のまま経過した期間、プルリクエストがレビュー待ちとなっている時間、QAに要した期間あたりが候補になります。ただ、これらを揃えれば詰まっている場所を特定できるとは言い切れません。仕様が固まらないまま費やされる時間のように、チケットが起票される前に消えているものや、工程間の手戻りなどは、どの指標にも現れないからです。
二つめは、人間がボトルネックになっている工程の扱いです。レビューやリリース判断が遅いのは、多くの場合、品質のために意図して置かれた制約でもあります。速さのために外してよい待ちと、外してはいけない待ちを分ける万能な基準は存在しません。
三つめは、漸進的な進め方そのものが抱える危険です。目の前の待ちを順に潰していくと、工程ごとの局所最適を積み上げただけで終わることがあります。上流から下流までを見渡す視点を、組織の中で誰が持つのか。この役割は、既存のどの職種にもきれいには収まりません。
逆に言うと、こういった問題こそが、AIではなく人間が受け持つべき責任だと考えています。
まとめ
リードタイムを短縮するためには、ボトルネックを特定し、それを解消する必要があります。しかし、工程単位でAIを入れても、その工程の中が速くなるだけで全体は縮みにくいままです。効きやすいのは、工程の境界を動かすか、境界をまたぐ受け渡しを減らすかのどちらかです。そして、どこが詰まっているかは開発対象と体制によって違うので、他社の答えをそのまま借りることはできません。
まずは自分たちの工程を上流から下流まで並べ、どこで変更が待たされているかを確かめるところから始めてみてください。
株式会社エレクトリック・シープでは、AI開発とAI導入の支援を行っています。どの工程から手を付けるかの整理や、その先の環境づくりに踏み込んだ支援が必要であれば、ご相談ください。
