メインコンテンツへスキップ
見出し画像

AIが書き、エンジニアが決める──テックファームが辿り着いた「仕様駆動開発」という答え

    「Vibe Codingで勢いよく作り始めたものの、後半で仕様がブレて収拾がつかなくなった」「仕様書なしでAIに任せたら、レビューの負担が倍増した」……。AIを使った開発をはじめて、このような壁にぶつかったエンジニアは少なくないはずです。

    私たちテックファームも、AI駆動開発への挑戦は試行錯誤の連続でした。その中で導き出した答えが、「仕様駆動開発」を標準プロセスとするという選択です。
    テックファームは、なぜ仕様駆動開発を選んだのか?
    今回の記事では、その背景と、AI時代に変容するエンジニアのスキルについて紐解いていきます。


    📌この記事でわかること

    • AI時代の最適解は「仕様駆動開発(SDD)」である理由

    • AIは行間を読まないため、仕様の厳密さが品質を決める

    • エンジニアの価値は「実装力」から「設計・評価力」へシフトしている


    画像
    仕様駆動開発の取り組みについて説明しているCTO・石立(写真右)

    ■ 開発スタイルを、どう選択するか

    一口に「AI駆動開発」と言っても、そのアプローチは多様であり、現時点でもなお、議論や進化は続いています。ここでは、代表的な2つのスタイルを整理してみましょう。

    まず、ざっくりとした要望を自然言語で入力することから進める「Vibe Coding(バイブコーディング)」。プロトタイプの爆速立ち上げには向いていますが、構造上作りながら考えるため、仕様の揺らぎが生じる可能性が高く、コードベースが大きいものになればなるほど、品質やレビューの負荷などの問題が生じやすくなります。

    そして、私たちが選択した、「仕様駆動開発(Spec-Driven Development / SDD)」です。これは実装に入る前に、人間がAIへの入力となる仕様を確定させるスタイル。何を作るのか、受け入れ条件は何か、制約条件は何かなど、厳密に「仕様」をAIとともに作成していきます。

    CTO・石立は、昨今のトレンドをこう分析します。 「この1年、GitHubやAWSの動向を見ていても『仕様駆動開発』への注目を感じます。とりあえずVibe Codingで動かして、後から『あぁじゃない、こうじゃない』と直すのは、実は無駄が多い。ちゃんとAIに正しい仕様を与えてからコードを生成させるのは、実務レベルの品質を担保する上で避けて通れないものになっています」


    ■「AIは行間を読まない」という大前提

    なぜ、受託開発においてこれほど仕様書が重要になるのか。それは、AIの持つ「極めて論理的だが、空気を読まない」という特性にあります。
    これまでの開発現場では、エンジニアが顧客の要望を「頭の中」にインプットし、それをもとに設計し、実装していました。要望に曖昧なところや、行間に隠された意図があったとしても、文脈から情報を読み取り、補完をしながら、仕様を完成させてきたのです。

    しかし、AIは違います。人間が行ってきたような「行間を読んで、補完をする」ということはできません。

    仕様が曖昧なら、AIは曖昧なまま解釈します。また、仕様書に書いていないことは、AIにとって「存在しない」のと同じです。テックファームが納品物の品質に責任を持つ以上、顧客の要望通りになっているかを厳密にレビューする必要があり、そのレビューの基準となるのが、曖昧さが排除された仕様書なのです。

    具体的なプロセスとしては、エンジニアがAIと対話をしながら、AIが誤解なく理解できる形まで仕様を言語化していきます。AIがそれに基づき各種設計(ドキュメント)を出力する。エンジニアはその設計を承認した上で、ソースコード生成へと進みます。「AIに渡す前に、人間が決めきる」。これが品質を安定させるための絶対条件です。

    画像
    仕様駆動開発のプロセスイメージ(工程におけるAIと人間の役割分担と協働について)


    ■「どう作るか」から「何が正しいか」へ──スキルの重心が変わる

    このプロセスへの移行は、エンジニアに求められる能力の大きな変化を意味します。一言で言えば、「どう作るか(実装)」から「何を作るか・それが正しいか(設計・評価)」へのシフトです。

    1. 情報収集・整理の解像度
      顧客の要望を漏れなく引き出し、AIが迷わないレベルまで落とし込む「言語化能力」がエンジニアにとって不可欠な能力となります。曖昧なまま次工程へ進んでしまった後に修正するコストが、相対的に重くなっているからです。

    2. 上流からのレビュー力
      AIのアウトプットが顧客の真の要望に沿っているか、コードが書き上がる前の『設計』の段階で見極める必要があります。これまでより早い段階で、システム全体を俯瞰する視点が求められるようになります。

    3. 技術への「体系的」な理解と経験
      体系的な理解があり、自分で作り込んできた経験があれば、AIへの指示も的確になるだけでなく、アウトプットの目利きも可能となります。

    つまり、これまで重視されてきた実装力から、言語化能力、設計や評価スキルに重心が変わりつつあるのです。これを受け現場では、若手メンバーが「言語化能力を磨きたい」「もっと設計を学びたい」と自発的に動き出すなど、ポジティブな変化も現れ始めています。


    ■「ドキュメント作成Gem」による暗黙知の継承

    とはいえ、質の高い仕様書をゼロから書くのは容易ではありません。そこでテックファームでは、ベテランのノウハウを詰め込んだ「ドキュメント作成Gem(Google Geminiベースの専用AI)」の整備を進めています。
    これは単なる効率化ツールではありません。「次はアクターの一覧を決めましょう」「この仕様の場合、データの送信後に更新をロックする必要はありませんか?」などとAIがガイドしてくれる、いわば伴走型のサポーターです。業務フローや非機能要件定義など、熟練者が持つ「仕様整理の技術」を誰もが活用できる仕組みを目指しています。



    ■ 編集後記

    仕様駆動開発への転換は、単なるプロセスの変更ではなく、エンジニアに必要とされるスキルの変容や、職種の再定義でもあります。
    「とりあえず動く」のその先へ。顧客と直接向き合い、AIという強力なパートナーを使いこなしながら、真に価値あるシステムを設計する。そんな、エンジニア本来の醍醐味が味わえる環境を、私たちはこれからも磨き続けていきます。

    テックファームが実践するAI駆動開発のリアルな取り組みや、私たちが描く「新しいものづくりの形」については、ぜひ以下リンクもあわせてご覧ください。

    AI駆動開発の取り組みについて(採用サイト)

    AI駆動開発は、受託開発の武器になる──テックファームが実践する新しいものづくりの形(note記事/CTOインタビュー)

     
    独立系SIerとして、25年以上のWebサービス開発実績を持つ「テックファーム」。プライムベンダーとして、お客様の課題解決をサービス設計から開発・デザイン・運用までワンストップで支援しています。 採用サイト:https://recruit.techfirm.co.jp/note/

    あなたへのおすすめ