目次
AI駆動開発を「Journey」として捉える、BeeXの見立て
BeeXが提供する「BeeX AI Journey 支援」はAI駆動開発を体験から実業務テーマでの実践、本番システム開発まで段階的に伴走するサービスです。このコラムでは、そのサービスの背景にある「BeeXがAI駆動開発のJourneyをどう捉えているか」という考え方を、もう一段深く書いてみたいと思います。
生成AIを使うと、コードは驚くほど速く出てきます。個人が試す分には、この効果はすぐ実感できます。ただ、私たちが実案件や社内検証を重ねる中で強く感じているのは、速く生まれるコードそのものよりも、その手前で下している判断のほうが、組織にとってずっと大事な資産になる、ということです。この記事は、その一点を軸に書いていきます。
なお、AI駆動開発にはまだ「これが正解」と言えるベストプラクティスがありません。ここに書くのも、私たちが実践の中で組み立ててきた見立てであって、立場や開発スタイルによって見え方が変わる部分もあると思っています。そのつもりで読んでいただければ幸いです。
「Journey」という言葉に込めた意味
AI駆動開発を、一度きりの導入プロジェクトとしてではなく、組織とともに続いていくJourney（旅）として捉える。これがフレームワークの出発点です。
なぜ旅なのか。生成AIに関連したツールやモデルの進化は速く、少し前まで有効だった使い方が、数ヶ月後には最適ではなくなるという状況が続いています。技術の変化に合わせて、使い方も、プロセスも、組織のかたちも、少しずつ更新し続けることになります。つまり「ここに到達したら完成」というゴールを固定しにくい。だから静的な完成形を目指すのではなく、変化に適応し続ける前提で設計する、という発想に至ったのです。
意思決定の視点で言い換えると、これは投資判断の考え方にも関わってきます。一度作り込んで終わりの投資ではなく、現在地を測りながら次の一歩を選び、効果を見て調整する。そういう継続的な意思決定の対象として、AI駆動開発を扱うということです。技術・プロセス・組織の3つの側面が同時並行で動くので、どこか一つだけを完成させても全体は前に進みません。
正直に言えば、「変化に適応し続ける」という構えには弱点もあります。うまくいかなかったときに「適応が足りなかった」といくらでも後付けで説明できてしまう。だからこそ、適応そのものを目的にしないことが大事だと考えています。今どこにいて、次にどこへ向かうのか。それを見失わないための座標軸を持っておく必要があります。
どのStageが優れている、という話ではない
その「今どこにいるか」を測るために、BeeXではAI駆動開発の成熟度を、未導入から戦略的活用まで5つのStageに分けて整理しています。
- Stage 0：未導入 AI開発ツールをまだ導入しておらず、活用の検討をこれから始める段階です。
- Stage 1：個人活用 一部の開発者が個人の裁量でAIツールを使っている段階です。ノウハウは属人的で、組織としてのガイドラインはまだありません。
- Stage 2：チーム展開 チーム単位で導入し、基本的なガイドラインを整えてナレッジ共有を進める段階です。
- Stage 3：組織での方法論確立 組織全体で共通のプラクティスと品質基準を持ち、継続的な改善サイクルが回る段階です。
- Stage 4：戦略的活用 AI駆動開発が組織の競争優位の源泉となり、プロセス・組織・文化が最適化された段階です。
区分はこのように整理していますが、誤解のないように書いておきたいことがあります。このStageは、組織の優劣をつける成績表ではない、ということです。
先のStageほど偉い、というものではありません。Stageは成績表というより地図に近いものだと考えています。地図上でどこにいるかは分かっても、その場所に優劣があるわけではない。事業の特性によっては、Stage 1やStage 2に腰を据えるのが最も合理的、という組織も当然あります。すべての組織が最上段を目指すべきだとは、私たちは考えていません。
Stageを一つ飛ばすことも、状況が変わっていったん後退することも、特定の段階にとどまり続けることも、その組織の状況においては正しい選択になり得ます。大事なのは、自分たちの現在地を共通の言葉で語れるようにして、次の一歩を納得して選べる状態にしておくこと。どこを目指すかは、それぞれの組織が自分たちの事情に照らして決めることです。
そして、どのStageにいても共通して効いてくるのが、次に述べる「判断の過程を残す」という取り組みです。
いちばん残したいのは、意思決定の「過程」
AIが高速に生み出すのは、コードだけではありません。設計書もテストもドキュメントも、同じ速さで出てきます。ただ、こうした生成物は、時間が経てば陳腐化します。前提が変われば、いずれ書き直されていくものです。一方で、なぜその設計を選んだのか、どんな制約を踏まえて、何を捨ててその判断に至ったのか。この判断の背景は、生成物が書き換わっても価値を失いません。むしろ、これこそが組織に蓄積すべきノウハウだと考えています。
これがなぜ重要か。技術の進化が速い領域では、過去の判断の背景が残っていないと、後から困ることになります。「当時なぜこの設計にしたのか」が分からなければ、前提が変わったときに改善の判断ができない。制約条件が変わったことにも気づけない。結局、同じ検討を何度も繰り返すことになります。コードは陳腐化しても、判断の背景は資産として効き続ける。この差は、時間が経つほど大きくなります。
ここで一つ、はっきりさせておきたい区別があります。私たちの目的は、意思決定の過程を組織の資産として残すことです。よく話題になる仕様駆動の開発スタイル（AWSが提唱するAI-DLCなどが代表例です）、本コラムではこうした体系化された開発の進め方をまとめて「型」と呼びますが、これは目的をかなえるための有力な手段の一つであって、目的そのものではありません。
この区別は実務で効いてきます。手段を目的の座に置いてしまうと、「過程を残す」イコール「この型でやる」と短絡して、他のやり方が見えなくなるからです。過程を残す手段は他にもあります。設計判断を記録するADR、design docやRFCの文化、Pull Requestの説明とレビュー議論を残す運用。どれも過程を残す立派な手段です。特定の型が唯一の正解というわけではありません。
では、なぜ確立された型を出発点に採るのか。ベストプラクティスが未確立の領域で、何もないところから自己流を組み立てるより、体系化された型をまず起点に置いて、実践しながら自社に合うかたちへ調整していくほうが、探索のコストが低いからです。型を採る理由は「その型が正解だから」ではなく、「一つ基準線を引かないと、改善のしようもないから」。基準線があってはじめて、良くなったのか悪くなったのかを測れます。サービスで「自社に合ったスタイルの確立を後押しする」と言っているのは、この考え方に基づいています。
型が用意するもの、人が担うもの
仕様駆動のような型を実際に使うと、意思決定の過程について、かなりのことを型が肩代わりしてくれます。
具体的には、やり取りを要約せずそのまま記録に残す。工程の節目ごとに人間の承認を求め、承認があるまで先に進まない。利用者が即答できずに詰まった判断は、追加の質問で深掘りする。関連する判断（規模、技術スタック、データベースの選択など）を同じ場に並べて提示する。こうした「判断の場・材料・記録・承認の機会」を、型は仕組みとして用意し、多くを強制してくれます。ここは型に任せられる領域で、投資すれば素直に効果が出るところです。
一方で、用意された機会を活かしきるところは、人の側に残ります。同じ場に並んだ前提のうち、どれとどれが関係するのかを結びつける。自分が何を分かっていないのかに気づく。並んだ選択肢のうち、どれが後から取り返しのつかない分岐で、どれは後で直せる些細なことなのかを見極める。こうした判断には、経験がものを言います。
たとえば承認の画面で処理がいったん止まっても、そこで何を確認すべきかが分かっていなければ、素通りになりかねません。型は「立ち止まる場所」を作ってくれますが、「立ち止まったときに何を見るべきか」までは教えてくれない。ここが、実践経験の差が出るところです。
だからこそ、不可逆で影響の大きいクリティカルな判断ほど、記録と承認の仕組みだけでは質を担保しきれず、経験のある人間の関与が要ると考えています。そして、そういう判断を担える人材は、実際に判断する経験を通じてしか育ちません。私たちが伴走という形にこだわるのは、まさにこの部分に価値があると考えているからです。
人間の役割は「レビュアー」にとどまらない
AI時代に人間の役割がどう変わるか。よく「開発者は作る人からレビューする人に」と語られます。プレスリリースでも「人は仕様の定義と成果物のレビューに専念する」と書きました。ただ、実践を重ねるほど、レビューという後工程よりも、その手前の「仕様を定義する」側、つまりAIに何をどう入力するかを設計する役割のほうが、成果を大きく左右すると感じています。
成果物の質は、レビューの段階ではなく、その前の入力を組み立てる段階でかなり決まっているからです。入力がよく構造化されていれば、レビューは自分の基準と照らし合わせる確認作業で済みます。逆に入力が薄いままだと、出てきたものを見て「なんとなく違う」とは思っても、どこをどう直せばいいのか分からず、消耗しがちです。
この感覚を突き詰めると、一つの見立てにたどり着きます。AIは人の思考を肩代わりするのではなく、増幅する存在だ、ということです。頭の中に最初の構造の芽、つまり完成のラフイメージや設計の見通しがあるほど、AIはそれをうまく広げてくれます。たとえば「ユーザー登録から決済までを一続きの流れにしたい」、「運用の手離れをよくしたいからServerless寄りで構成したい」といった、ざっくりとした全体像。これくらいの芽があれば十分です。そして、その「広げ方」に道筋をつけるのが型です。この芽を型（たとえばAI-DLC）に乗せると、モブワークというスタイルで複数の役割/立場の視点を取り込みながら、どの画面をどうつなぐか、どこで例外を拾うかといった要件のかたちへ、AIが素早く広げてまとめてくれます。芽を型に乗せることで、AIの増幅があらぬ方向に散らず、狙った方向に働くわけです。反対に、芽が薄いまま進むと、薄い成果物が速く出てくるだけになります。本来なら手を動かしながら考えも固まっていくはずが、成果物だけが先に積まれていく。こうなるとレビューは自身の理解を元にした作業ではなくなり、寄る辺のない答え合わせになってしまいます。しかも速く形になる分、薄いことにも気づきにくい。
この見方は、AI駆動開発への期待に釘を刺すと同時に、背中を押してもくれます。釘を刺す側としては、AIを入れれば誰でも高度なものを作れる、という期待に歯止めをかけます。増幅する元がなければ、増幅しようがないからです。背中を押す側としては、鍛えるべき力がはっきりします。それは、何を解くべきかを定める問題設定の力とそれを設計として組み立てる構造化の力です。いずれもAI以前からエンジニアリングの中核だったものです。
AI駆動開発への投資は、ツールの研修だけでは足りません。何を解くべきかを問う設計思考や、頭の中を構造化する訓練にこそ、組織の力の伸びしろがあります。ツールは変わり続けますが、問題を立て、構造化する力は陳腐化しません。
BeeXの伴走スタンス
ここまで書いてきたことを、私たちの立ち位置としてまとめておきます。
BeeXは、AI駆動開発に唯一の正解があるとは考えていません。実案件と社内検証で培ってきた知見をもとに、お客様が自社に合ったAI駆動開発のスタイルを確立するまで、一緒に歩くことを支援の中心に置いています。
提供したい価値は、ツールや手法の導入そのものだけではありません。型が用意してくれる部分はお客様自身でも進められます。私たちが力を発揮したいのは、型が用意しない部分です。並んだ前提をどう関連づけるか、どの判断を重く見るか、そしてそういう判断を担える人材をどう育てるか。ここに、実際の開発で積んだ経験を持ち込むことが、伴走の核心だと考えています。
冒頭にも書いた通り、この領域はまだ答えが固まっていません。ここで述べたことも、唯一の答えというより、私たちが実践の中で確かめてきた一つの見解です。その上で、コードが速く生まれる時代に組織が本当に残すべきものは何かという問いに、私たちなりの一つの答えを示したのがこのコラムです。
サービスの詳細は、サービスページをご覧ください。皆さんのJourneyに、少しでも役に立てば嬉しいです。
※AI-DLC（AI-Driven Development Lifecycle） は、AWSが提唱する、AIを開発の中心的な協働者と位置づけてソフトウェア開発ライフサイクル全体に組み込む方法論です。詳しくはAWS公式ブログ「AI-Driven Development Life Cycle: Reimagining Software Engineering」をご参照ください。
