製造業向けコンサルのDNAから生まれた、SHIFT流「AI駆動開発」

司会：本日はSHIFTが推進する「AI駆動開発」について話を聞いていきます。

まず、SHIFTといえば基盤事業でもあるソフトウェアテストのイメージが強いですが、なぜいま、AIを使った開発手法の確立に力を入れているのでしょうか？

白木：SHIFTのルーツからご説明した方がわかりやすいかもしれませんね。SHIFTはもともと、製造業向けの業務改革コンサルティングからはじまった会社です。

職人の技術を「標準化・形式化」し、誰でも高い品質で再現できるようにする。この思想をIT業界にもち込んだのがSHIFTの出発点です。

ソフトウェアテスト事業で急成長できたのも、徹底した「仕組み化」があったからです。そして、仕組み化のノウハウをさまざまな事業に適用したことで、サービスラインナップを広げてきました。

そして、SHIFTでは幅広い領域の事業運営にAIを積極的に活用してきました。その過程でSHIFTが内製してきたAIプロダクトは多岐にわたります（下図）。

お客様のDX推進をご支援するノウハウ、AI内製・活用で得たノウハウをかけあわせれば、開発現場をさらに進化させられるはず。

そんな考えから生まれたのが、システム開発の上流工程から下流工程までにAIを組み込む「AI駆動開発」です。

設計開発プロセスをAIといっしょに人間が協働して推進していくことで超高速ウォーターフォールを実現するというのが主なコンセプトとなっております。

最上流工程であるRFPをお客様からいただいて、それをインプットとして各工程をAIがメインで対応していく。

そのアウトプットを人間がレビューを行い、人間が承認しましたら次のフェーズに行くというのが、我々のAI駆動開発の全体像になっております。

生産性の向上と、品質の担保を目的に使っているのが、独自のシステム開発フレームワーク「SHIFT DQS（Development Quality Standard）」です。

DQSは、もともとはAIのためのものではありません。どのエンジニアがつくっても一定の品質と生産性を担保できるように、設計や実装のルールをテンプレート化したものです。

開発のスペシャリストたちの知見を集約したDQSとAIをかけあわせて、エンタープライズのお客様向けのシステムで要求される品質を目指しています。

自律型AIをのりこなす、秘伝のレシピ「DQS」

司会：AI駆動開発には、AIエージェント「Devin」を採用しているそうですね。

白木：はい。私たちはDevinを提供するCognition AI社と戦略的パートナーシップを結んでいます。

Devinの最大の特徴は「自律型」であることです。従来のチャット型AIとは違い、目的を伝えると、自分で計画を立て、コードを書き、エラーが出れば修正し、デプロイまで自律的に行ってくれます。

最初は検証に時間がかかりましたが、DQSと組みあわせることで真価を発揮することがわかってきました。

司会：具体的に、どのようにDQSとDevinを組みあわせているのでしょうか？

白木：簡単にいうと、要件定義から実装までの各工程をAIがメインで担当し、人間がそれをレビューして承認するという流れです。

例えば、API設計書や機能一覧といったドキュメントには、DQSで定めた厳密なテンプレートがあります。

「この項目は必ず書く」「フォーマットはこうする」といったルールファイルも整備しています。これをDevinにインプットとして渡すんです。

Devinは作業を開始すると、「DQSのボイラープレートとルールを読み込みました」と反応し、それらに従って実装計画を立ててくれます。

司会：人間が細かく指示しなくても、Devinが自分でルールを読んで進めてくれるわけですね。

白木：そうです。頼れるパートナーになりつつあります。特にDevinの機能の一つである「Playbook」が便利です。

これは手順書のようなもので、1回実行するだけで「設計書を読んで、コードを書いて、テストする」といった一連の流れを自律的にこなしてくれます。

司会：人間はプロンプトを打つ手間さえ省けるようになると。

白木：はい。プロンプトの書き方で品質が変わるのも防げますし、標準化された手順をPlaybookにしておけば、誰が実行しても同じ成果物が得られます。これがSHIFTの目指す品質保証の形です。

実装の「試行錯誤」をAIが肩代わり。デザインと開発の距離をゼロにする技術

司会：現場での具体的な取り組みとして、「フロントエンドイチゲキ開発プロジェクト」があるそうですね。

馬塚：通称「イチゲキPJ」です。フロントエンドを爆速で、まさに「一撃」でつくってしまおうという取り組みです。

フロントエンドはユーザーの目にふれる重要な部分でありながら、意外とバグが出やすく、修正工数もかさみますから。

司会：具体的にはどのようなフローなのでしょうか？

馬塚：まず「Figma to Code」というステップでは、デザイナーの役割を再定義しています。

「絵を描いて終わり」ではなく、Figma上でコンポーネント分割まで意識してデザインしてもらい、そこからAIを使ってReactのコードを生成します。

デザイナーが「ここは同じUIをもったコンポーネントです」と定義することで、Reactコードの無駄が減るうえ、手戻りを減らすことができます。

次の「画面設計 to Code」というステップでは設計書をAIにインプットし、フロントエンドを生成しています。

フロントエンドの実装は端末ごとの差異やユーザー操作による状態変化に影響されやすく、この部分を短納期で仕あげられれば、プロジェクト全体の工数をかなり短縮させられます。

司会：AIが書いたコードの品質はどのように担保しているのですか？

馬塚：人がレビューする前工程で使う、「レビュー用のAI」を用意しています。社内では「Revin（レビン）」と呼んでいます。

実装担当のDevinがプルリクエストを出したらCIパイプライン内でRevinが立ちあがり、DQSの定める実装ルールへの準拠性を機械的にチェックするんです。

テストコード作成も同様です。実装した本人がテストを書くと「自分の思い込み」でテストしてしまいますよね。

ですから、テストコードを書くのも別のAIにやらせます。客観的な視点で検証させることで、ハルシネーションや実装漏れを防いでいます。

「仕様駆動開発（SDD）」で解決する、AI時代の正しい手戻りの作法

司会：もしAIの実装に不備があったり、仕様変更があったりする場合は、コードを直接直すのでしょうか？

馬塚：「設計書を直して、もう一度生成させる」というフローを徹底しています。いわゆる「仕様駆動開発（SDD）」の考え方です。

司会：手戻りが大変ではありませんか？

馬塚：それが、AIのおかげで逆転現象が起きているんです。これまでは実装コストが高かったので、設計に戻るのを嫌がってコードだけで継ぎ接ぎ修正をしがちでした。

いまではAIが一瞬で実装してくれるので、「設計書さえ直せば、あとはAIが書き直してくれる」という状態になっています。

これにより、ドキュメントと実装の乖離という、開発現場の長年の課題も解決しつつあります。

少ない工数で最大の利益を。AI時代に再定義されるエンジニアの価値とキャリア

司会：ここからは、みなさんからいただいた質問にお答えしていきたいと思います。

Q．今後は、エンジニアの役割が変わってきそうですね。「コードを書く」という作業の価値はどうなるのでしょうか？

馬塚：確実に変わります。コードを書くこと自体はスピードも質もAIに軍配があがります。エンジニアの価値は「何をつくるか」「どう設計するか」を決める上流工程にシフトしていくでしょう。

白木：私は前職のスタートアップ時代、自社サービスを立ちあげてはクローズするというサイクルを何度も経験してきました。そのなかで痛感したのは、結局、価値は『何をつくるか』という上流工程に寄っていくということです。

AIは暗黙知を理解することや意思決定はできません。お客様が何を求めているのか、業務背景はどうなっているのか。

それを噛み砕いて、AIが理解できる詳細な設計書やドキュメントに落とし込む力。ひいては課題解決する力こそが今後求められるスキルだと思います。

Q．AIが書いたコードをレビューするスキルも必要になりそうですね。

馬塚：そうですね。「AI時代に品質保証の仕事はなくなるのでは？」と聞かれることもありますが、私は逆だと思っています。

AIが大量にコードを生産するからこそ、「それが本当に正しいのか？」「要件を満たしているのか？」を検証するQA（品質保証）の重要性はむしろ高まります。

白木：いまの段階ではまだAIを100%信じることはできませんから、最終的な責任をもってレビューし、承認する人間の役割は不可欠です。

ただ将来的には、コードの中身をみるよりも、テスト結果や挙動の正しさを判断する方向にシフトしていくかもしれませんね。

馬塚：「よいプログラマーは怠惰であれ」という言葉がありますが、AIを使って楽ができるなら、それに越したことはありません。コーディング自体がゴールではなく、ビジネスの成功やお客様への価値提供がゴールですから。

司会：AIを最強のパートナーとして使い倒す。そんなSHIFTが描く未来のエンジニア像が提示された1時間となりました。本日はありがとうございました。

（※本記事の内容および対象者の所属は、イベント開催当時のものです）