SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

DevinではじめるエンタープライズAI開発

Devin導入を全社に広げるには? 小さく始めて組織の力に育てるための、個人→チーム→全社の3ステップロードマップ

DevinではじめるエンタープライズAI開発 第4回

中野 誠(ULSコンサルティング株式会社)[著] / 山河 征紀(ULSコンサルティング株式会社)[著]

【ステップ3】全社:AIDD CoEが各チームの資産を全社標準へ引き上げる

 KPIが8割に届いたチームが2つ、3つと増えてくると、今度は別の問題が見え始めます。チームごとにAGENTS.mdやPlaybookを別々に育てる車輪の再発明、アクセス権限やセキュリティの統制がチーム任せになる統制のばらつき、経営への効果説明の物差しの不一致。この3つは、チームの中からは解けません。

 ここで必要になるのが、AIDD CoE(AIDD:AI-Driven Development=AI駆動開発。CoE:Center of Excellence=知見を組織横断で集約・展開する専門チーム)です。CoEの仕事は大きく3つあります。

  • 資産の集約と標準化:各チームのPlaybook・AGENTS.mdの書き方・ハーネス設計のうち効果が確認できたものを吸い上げ、全社標準として再配布する。新しくステップ1を始めるチームは標準セットから出発でき、立ち上がりが数週間単位で縮む
  • 統制の一本化:アクセス権限・監査・セキュリティのルールを全社で1つに揃え、チームごとの判断のばらつきと統制漏れを防ぐ
  • 投資判断:各チームのKPI(指摘なしマージ率)と、Devinのコスト・削減工数(ステップ1で控えた従来工数と実績の差)を同じ物差しで集計し、経営に示す。削減工数が費用を上回り続けるならさらに広げ、下回り続けるなら対象タスクの見直しへ

 CoEといっても、専任の大所帯は要りません。各チームで改善ループを回してきたリーダーの兼任数名で始められます。大事なのは、ステップ1・2で自然に貯まっていく資産を、散逸させずに全社で再利用できる形へ引き上げる担い手を置くことです。

図2:AIDD CoEが各チームの資産を集約・標準化し、全社標準として再配布する
図2:AIDD CoEが各チームの資産を集約・標準化し、全社標準として再配布する

 見落としてはならないのは、CoEが単なる横断の管理窓口にとどまらないことです。CoEは、どの実装をどのチームが持つかという従来の編成とは別に、AI駆動開発の成熟度という軸をチーム編成に持ち込む起点でもあります。実装を書く集団だったはずの開発チームの役割は、AIへの設計・判断・統制を担う集団へと少しずつ変わり始めます。CoEを置くことは、便利な共有チームを1つ増やすこと以上に、開発組織のレポートラインと役割分担が組み替わっていく、その最初の一歩なのです。

 ここまで来ると、AI駆動開発は一部のチームの特別プロジェクトではなく、全社の開発の当たり前になっています。どのチームでも定型改修はDevinが日常的にこなし、その過程で暗黙知が形式知に変わり、ハーネスが強くなり続けます。第3回のタイプ3で扱った大規模なモダナイゼーションや新規開発に挑むときも、CoEに蓄積されたルールとゲートがそのまま土台になります。

 到達点は、可視化・実装・品質チェックのそれぞれに人間が動かなくても前へ進む仕組みが全社に組み込まれ、第1回の3つの本質的問題に共通していた「人間がボトルネック」の構造が外れた状態です。

 そしてこの構造が外れると、変わるのは開発の速度だけではありません。エンジニアの仕事の重心は、実装そのものから、AIに何を任せどう判断するかの設計と意思決定へ移ります。第1回で予告した、1人が複数のAIエンジニアを率いるテックリードのような働き方が、ここで現実の役割になり始めます。それにともない、チームを何人で組むか、成果を何で評価するかといったマネジメントの単位や基準も、従来のままではいられなくなります。AI駆動開発を突き詰めた先で組織の形そのものが変わり始めます。本稿の到達点は、その入口に立つことなのです。

まとめと次回予告

 第4回の要点を整理します。鍵は、最初から大規模刷新や全社展開を狙わず、個人→チーム→全社の3ステップで小さく始めて育てることです。変革の進み具合は指摘なしでマージされたPRの割合で測り、まずは8割を目安に、ステップを上がるかどうかもこのKPIで判断します。各ステップの勘所は次の3つです。

  • 個人:効果を測りやすく・影響範囲が限定的で切り戻しやすく・合否を機械判定できるタスクを選ぶ。レビュー指摘は改善素材として、AGENTS.md・Knowledge・Skills・CIへ反映する。試す期間は1〜4週間で先に区切る
  • チーム:成功の個人依存を防ぎ、型をPlaybookに落として誰でも同じ品質を出せるようにする。変更が頻繁な領域から任せる範囲を広げ、Devin Reviewでレビューの詰まりを防ぎ、指摘のハーネス反映もDevin自身に任せる
  • 全社:AIDD CoEが各チームの資産を全社標準に引き上げ、統制を一本化し、投資判断の物差しをそろえる

 冒頭の問い「何から始めればいいのか」への答えは、拍子抜けするほど小さな一歩です。PRごとにテストが走るCIを整え、3時間分の変更を1つ任せ、返ってきた指摘を1件ハーネスに反映します。その繰り返しがチームの型になり、CoEの手で全社の標準になったとき、Backlogに積まれた技術的負債は日々の開発の中で削られ、DevinのPRが指摘ゼロでマージされていきます。「人間がボトルネック」という構造は、大規模刷新の号令ではなく、この小さな改善ループの積み重ねで外れていきます。そのときモダナイズされているのは、コードだけでなく、AIを前提とした形に作り替わった開発プロセスそのものなのです。

 次回(第5回)はいよいよ最終回です。AIDD CoEが定着した先にある、Devinを活用した開発組織の未来を展望します。エンジニアの役割はどう変わり、開発組織はどんな形になるのかを解説します。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
DevinではじめるエンタープライズAI開発連載記事一覧

もっと読む

この記事の著者

中野 誠(ULSコンサルティング株式会社)(ナカノ マコト)

 事業会社でのシステム開発を経て、ULSコンサルティングに参画。業務システム刷新、アーキテクチャ設計、スクラム開発、開発プロセス改善などに従事。DDDによるモデリングを得意とし、現場PMとしての実践経験をもとに、技術とプロセスの両面から開発組織の改善を支援している。近年はDevinやClaude C...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

山河 征紀(ULSコンサルティング株式会社)(ヤマカワ マサキ)

 ULSコンサルティング株式会社  AI駆動開発推進室 室長、AI駆動開発コンサルタント 独立系ソフトウェアハウスでプロジェクトマネージャーとして基幹システム開発を率いたのち、2008年にULSコンサルティングに参画。 ミドルウェア開発とITアーキテクチャ設計を専門とし、インメモリーデータグリッドを...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー