SHOEISHA iD

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

CodeZine(コードジン) ProductZine

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

Developers Summit 2026 Summer セッションレポート

AIで実装が速くなった後、何がボトルネックになるのか? インディードリクルートテクノロジーズが1年の社内実証で示した答え

【16-B-9】開発は速く安くなる。開発量は増える。ボトルネックは移動する。AI時代のエンジニアリング組織論

コミュニケーションコストに立ち向かうための2つのアプローチ

フルフル:フルスタック×フルプロセス
フルフル:フルスタック×フルプロセス

 コミュニケーションコストへの対処法は2系統ある。アーキテクチャで境界を切ってパスを断つ「壁を作る」アプローチと、1人が担う範囲を広げて人数そのものを減らす「Nを減らす」アプローチだ。

 インディードリクルートテクノロジーズが志向するのは後者だ。その形を同社は「フルフル」と呼ぶ。フルスタック(バックエンド・フロントエンド・インフラなど複数の技術領域をカバー)×フルプロセス(要求・要件定義から実装・テストまでの複数工程を理解・担当)を指す造語である。「突き詰めると、ビジネス検討からコードまで1人で進めるのが最速で、受け渡しが発生しないからです」と黒田氏は述べる。

 フルフルを進めた現場では座組そのものもフラットになった。従来の深い階層は、事前調整と計画駆動で不確実性を抑え込む設計だった。フラットな座組は、事前調整を最小にしてリアルタイムの調整を最大化する。メンバーが通常より広い責務と判断範囲を担うことで、コミュニケーションパスそのものが減っていくという。

AIが生んだ「保守の急増」にどう備えるか

 一方、増え続けるシステムの維持保守も、同じ問題に直面する。AIで開発コストが下がると、ROI成立境界が下がり、個別事情の開発が増えていく。だが作ったシステムは一定期間でアクティブ開発が終わっても保守コストを生み続ける。しかも個別最適されたシステム群はデータやAPIで互いに絡み合い、1箇所の変更が連鎖障害を招く。依存関係のスパゲッティ化がこれまでにない規模で起きるというのが黒田氏の見立てだ。10個の管理なら今までの体制で回せても、100個になれば話は別だ。黒田氏はあえて後者を前提に置き、常識の外側から保守体制を設計し直した。

 同社は「KTLOセンター(Keep The Light On センター)」として維持保守の受け皿を集約し、まず70リポジトリ規模のマイクロサービス群から着手している。24時間365日のトラブル対応、各種パッチ当て、EOSL対応、バージョン管理、問い合わせ対応を、AI-OPSをフル活用するベトナムオフショア体制で受ける形だ。

KTLOセンター:維持保守の受け皿を集約する
KTLOセンター:維持保守の受け皿を集約する

 もうひとつの可能性として、「FDE(Forward Deployed Engineer)」という職能も見えてきた。個別最適がROIに乗る時代になると、1つのパッケージをN社に売るモデルの前提が崩れる。顧客の現場で業務文脈を理解し、その場で実装し、運用に乗せ、再利用可能なパターンとして共通基盤に還流させる職能だ。「中身を見るとフルフル人材が社外の現場に立つ形になります」と黒田氏は述べる。量産される個別システムはそのまま維持保守の対象となる。前線のFDEが個別最適を作り、KTLOセンターが支える。この2つが揃うことで、事業として成立すると黒田氏は見ている。

1年の観察が行き着いた結論は「制約は消えずに移動する」こと

 SEOでは意思決定がボトルネックになったから、実装を意思決定に従属させた。AirワークのEOSL対応では確率論的な生成がボトルネックになったから、決定論の検証ループに従属させた。KTLOでは受け皿の不足がボトルネックになったから、増える開発をその受け皿に従属させた。組織では判断の受け渡しがボトルネックになったから、組織の形を判断の速さに従属させた。アーキテクチャでは推論の幅が広いことがボトルネックになったから、境界と契約で幅を絞り、検証のしやすさに従属させた。制約理論で言う「制約に他の工程を従属させる」という発想が、すべての事例に共通していた。

SEO・AirワークのEOSL・KTLOの3事例における「制約→従属させた工程→順序の変化」の組み替え
SEO・AirワークのEOSL・KTLOの3事例における「制約→従属させた工程→順序の変化」の組み替え

 1年間の観察を経て、黒田氏はこの構造をひとつの言葉で言い表した。「制約は消えずに移動する」。

 「速くなった実装をそのまま最大化するのではなく、ボトルネックの工程に合わせて組織・プロセス・アーキテクチャを組み替えるところから始めています。皆さんの現場の参考になれば幸いです」と黒田氏は語り、セッションを締めくくった。

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

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
Developers Summit 2026 Summer セッションレポート連載記事一覧

もっと読む

この記事の著者

森山 咲(編集部)(モリヤマ サキ)

CodeZine編集部所属。

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

川又 眞(カワマタ シン)

インタビュー、ポートレート、商品撮影写真をWeb雑誌中心に活動。

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

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

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/29443 2026/09/17 09:00

イベント

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

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

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

メールバックナンバー