1. はじめに
2. ACESのR&D部門とAIエンジニア
- 2.1 組織図上の立ち位置
- 2.2 何を作っているか
3. 顧客に価値を届けるまでの3つの壁
4. 【作る】R&Dとソフトウェアの接続
5. 【価値を届ける】事業部との連携
6. 【改善・拡張】アーキテクチャ戦略
- 6.1 アーキテクチャの可視化と共有
- 6.2 グレーな部分を残す
7. 今後の課題 - 大LLM時代への適応
8. むすびに

1. はじめに

初めまして、株式会社ACESのR&D部門でAIエンジニアをしている阿久澤（@kei_akuzawa）というものです。

採用面談の場ではACESでAIエンジニアとして働くことの魅力や特徴についてよく聞かれます。私が強調するのは「社会実装と付加価値の実現にこだわっている」というポイントです。このポジショニングは、特にインターンとして応募して下さる大学生/大学院生の方に刺さっているような実感があります（当たり前ですがインターンを検討している方の多くは、自身の培ってきた技術がどのように社会に役立つかを試す場を探しているのだと思います。）

とはいえR&Dと事業の接続は一般論としても非常に難しいものだと思います。上記のように、我々はR&D活動と事業の接続に対して一定の自信を持っているものの、さまざまな問題が噴出しているのも事実であり、継続的な改善・課題解決に取り組み続けています。

本ブログでは、R&Dと事業の接続に向けてAIエンジニアチームが意識していることや、課題解決に向けた格闘の歴史について簡単にご紹介します。会社ごとの事情によってポイントは変わるかと思いますが、ACESにおけるN=1のケーススタディに興味を持っていただければ幸いです。

💡なお、本記事で紹介する取り組みは松田達哉さん、久保静真さん、田村浩一郎さんを中心とするチーム全体の成果です。一方で、記事の内容に誤りや不十分な点がありましたら、その責任は筆者（阿久澤）にあります。また記載内容は個人の視点・解釈が多分に含まれており、ACESとしての公式な見解を示すものではないことをご承知おきください。

2. ACESのR&D部門とAIエンジニア

2.1 組織図上の立ち位置

まず、ACESの組織図はざっくり以下のような形になります。

つまり、DXパートナーやAIソフトウェアなど、直接顧客に接して売り上げを上げる事業部とは独立した形でR&D部門が存在していました。この狙いを一言で言えば規模の経済です。DXパートナー事業では多くのパートナー企業様と個別性の高いプロジェクトをそれぞれ行なっており、規模の経済を発揮するためにはプロジェクト横串の共通部品を作るR&D部門が必要と考えられました。加えてDXパートナー / AIソフトウェアの両部門に対してR&D部門は横串を通すことを期待されています（※ ただし後述の通り現在こちらの構造は見直し最中です）

また注意点として、AIエンジニア（AIの専門性を軸としたエンジニア）はR&D部門だけではなく事業部にも在籍します。役割の違いとしては、R&D部門のAIエンジニアは横串で使える再利用生の高いAI開発を行うのに対して、事業部のAIエンジニアは個々のプロジェクト・ユースケースに特化したAIを作り込んでいるようなイメージです。本記事では、私が所属するR&D部門のAIエンジニアの活動にスコープを限定して語ります。

2.2 何を作っているか

R&D部門は大きく分類して二つのものを作っています。

一つ目は、AIモジュールです。これは、AIの機能を再利用性の高い形でモジュール化したものです。わかりやすく言えば物体検知、行動認識、音声認識などのAIが相当します。逆に言うと、特定のユースケースやドメイン固有のロジックが混ざりすぎていて、他のプロジェクトでの再利用性が薄いものはAIモジュールではないと定義しています。

二つ目は、顧客の業務プロセスに迅速にAIをインテグレーションするための共通基盤です。本記事はAIエンジニアの活動がスコープなので、以降では共通基盤の話はあまりしません。

以下に、R&D部門の作っている二つのものが、事業部門を通じてどのように顧客に価値を届けているか、簡単に図示しておきます。

3. 顧客に価値を届けるまでの3つの壁

さて、AIをモジュール化し、そのモジュールが事業部で稼働し、顧客に付加価値を生み出す・生み出し続けることが、私たちの目指すゴールです。

ここに、大きく三つの壁があると考えます。

【AIモジュールを作る】大きな不確実性が内在する中で高精度なAIの開発を行い、また最終的にAIモジュールという再利用性の高い高品質なソフトウェアにまとめ上げる
【顧客に価値を届ける】R&D部門と事業部や顧客の間に距離がある（前節の図より）中で、顧客からの要求に正しく応えて付加価値を提供する
【改善・拡張し続ける】一度導入されたAIモジュールを改善し続けて、また新たなプロジェクト / プロダクトでの再利用を促す

この記事では、上記の三つの壁に対して私たちがこれまでどのような対処をしてきたかを一部抜粋してご紹介します。今回ご紹介する取り組みは、それぞれ①開発プロセス②戦略連携③アーキテクチャ設計の観点からのアプローチです。

4. 【作る】R&Dとソフトウェアの接続

さて、AIモジュールの開発過程には、次のような課題があります。

AI開発に内在する不確実性コントロール: AIのモデル出力が確率的である、またモデル学習において事前に精度の見通しを立てることが難しいなど、AI開発には不確実性がついて回ります
モジュール開発に要求されるソフトウェア開発スキルの高さ: PoCのようにAIの精度検証レポートを作って終わりではなく、最終的には再利用性が高いソフトウェアとしてAIを落とし込む必要があります
上記二つのためのスキルセットのミスマッチ: 1と2は異なる専門性を要求する（AIの専門家 / SWE）が、これらの掛け算を持つ人材が市場に少ない

これらの課題に対処するため、ACESでは以下のような取り組みを行いました。

4.1 V字開発プロセスの導入

ソフトウェア開発のV字開発プロセスを、AIモジュールの開発にも導入することに決めました。狙いとしては、要件定義やテストを実施し、AIモジュールのソフトウェアとしての品質を担保することです。R&D部門のAIエンジニアは大学（院）でAIの研究をしていたリサーチのバックグラウンドを持つ方が多く、ソフトウェア開発スキルにばらつきがありました。明示的にプロセスを導入する（例えば、要件定義・テスト設計のテンプレートを作成したり、レビュー体制を整える）ことで、AIエンジニアのスキル育成・標準化を図りました。

4.2 PoCと本開発のフェーズ分離

通常のソフトウェア開発と比較した特徴として、AIモジュール開発ではPoCフェーズと本開発のフェーズを明確に分離しています。この狙いとしてはいくつかあります。

第一に、PoC時における過剰なソフトウェアの作り込みを避けて、検証のスピードを重視
第二に、ソフトウェア開発のケイパが十分に育っていないインターン生等であっても、PoCにタスクを切り出すことで依頼が可能になり、リソース効率を最適化できる

「AI開発においてPoCと本開発を分ける」というのはDeepLearningの黎明期から存在する一般的な考え方だと思います。そこでACESにおける特徴を一言付け加えるとすれば、V字開発の内部にPoCが組み込まれている、つまり要求定義の後にPoCが実施されることです。こうしてPoC段階から明確なゴールイメージを設定することで、ユーザーにどういった価値を届けたいのか・そのためにどこを担っているかの共通認識が醸成され、手戻りやPoC止まりを減らせると考えています。

💡 PoCと本開発の考え方については、DeNAの@yurfuwaさんのこちらのスライドをとても参考にさせていただいております。 https://speakerdeck.com/yurfuwa/ai-project-management-flow-and-build-trap-review

4.3 アジャイルによる加速

V字開発を取り入れたとは言ったものの、長期のウォーターフォール開発ばかりをやっているわけではありません。すでにプロダクト上で稼働しているAIモジュールのバグ修正や微改善など、細かいアップデートも数多く行われています。またAI開発には大きな不確実性が内在するため、そもそもアジャイル開発と相性が良いと考えています。

💡 不確実性とアジャイル開発の関係性については、広木さんの書籍をとても参考にさせていただいております。エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

そこで我々は、以下のようなアジャイル開発のベストプラクティスの導入も行ってきました

プロダクトバックログの運用
2週間単位でのタイムボックス型イテレーション
デイリースクラムの実施
（and more…）

特に拘ったのは、先に導入されたV字開発とアジャイルを突合させるための整備です。これら二つでは開発管理に用いる代表的なツールやドキュメント、概念が異なります。例えば

V字開発: 要求定義書、要件定義書、基本設計書、テスト設計書
アジャイル: プロダクトバックログ、スプリントバックログ、ユーザーストーリー

これらを対応づけて、何の目的で・どこに・何を書くか、以下の図のように整理を行いました。

ちなみに、当初はNotionを使って上記3つ全てのDBを管理していました。しかし、スプリントバックログはAsanaの方がツールの使い心地が良い、また依頼・要求についてはSlackの方が依頼者が気軽に投稿しやすいといった課題も見えてきており、調整が続いています。

5. 【価値を届ける】事業部との連携

1章の組織図でも示したように、ACESではR&D部門が事業部と独立した形で設置されていました。そのため事業部・延いては顧客との距離が遠くなり、ニーズや要望が正しく十分に伝わりづらい構造になっています。そのため

事業部とR&Dの間で「伝えているのに反映されない/そんな要求は受け取っていない」という衝突が起きる
R&D側で独自に課題を想定して技術開発を進めてしまい、後に事業部の優先順位や顧客ニーズと合っていないことが判明
厳格な要求定義が必要な新規開発に挑戦しづらく、既存のAIモジュールの精度改善などわかりやすい要求に対してリソースが集中

といった問題が起きていました。

5.1 要求の受入口を絞る

口頭・Slack・Notion――と窓口が散らばるほど、要求はロストしやすく、優先度もブラックボックス化しがちでした。そこで、以下のような仕組みを導入しました

目的	ツール/会議体	内容
要求を“確実に”受け取る	依頼DB	事業部メンバーがフォーム感覚で登録。
要求の棚卸しと整理	連携定例	依頼DBの新規追加項目を確認し優先度合わせ

ここでのポイントは、窓口を“１つに絞る”ことでした。複数経路を残したまま「DBにも登録してね」とお願いすると誰もやりません。そこで、「登録されていない要求は存在しない」ルールを徹底するようにお願いしました。

この仕組みは、直ぐにワークして依頼を急増させたわけではなかったのですが、うれしい副次効果を生みました。それは「要求の伝達プロセスに問題がある」という意識を事業部側と共有できたことでした（依頼DBを毎週眺めて登録数が十分に増えていかない状況を見ると、自然とそのような気づきがえられます）。この気づきと認識共有が、問題解決の第一歩となったと考えています。

5.2 事業部の中に入る

前節の仕組み化以上に効果があったのは、シンプルに「事業部のチームの中にR&Dメンバーが入って直接コミュニケーションを増やすこと」でした。

そうです。議論をひっくり返すようで申し訳ありませんが、冒頭の組織図は壊れつつあります（※少し別文脈の経営判断として組織図の見直し・再編を試みているような状況であり、今後どうなるかはわかりません）

具体的に以前と大きく変わった点としては、以下のようなものがあります。

アサインメント単純化: R&DメンバーはDXパートナー事業部／AIソフトウェア事業部のどちらか１つのみを見る。
日常ルーチンの統合: 事業部のデイリースクラムやスプリントプランニングに同席。オフィスでも同じ島にデスクを配置

これにより純粋にコミュニケーションの量が増大し、自然と要求の受け渡しが改善しました

とはいえ、この組織形態の変更は、「事業部間に横串を通す」と言う当初の目論見からは外れてしまっており、またリソース効率よりもフロー効率を優先した判断とも言えます。総論としてどちらが良かったのかはわかりませんが、少なくとも要求の伝達効率が上がったのは事実です。

5.3 優先順位を付ける

要求が順調に溜まったら、次に 「どれから着手するか」 決めなくてはなりません。ところが、R&D部門と事業部はそれぞれの視点で異なるものを見ているため、優先順位付けを合意するのは難易度が高いです。

一般論としてプロダクト開発では、概ね以下のような手順で優先順位付けを行います。

要求を集める
要求を開発テーマに落とし込む
開発テーマの一覧を並べる
開発テーマをRICEなどでスコアリングし、順位を決める

以下では私が担当した「音声認識の精度向上」の文脈を例に、具体的な苦労を説明します。とりわけ難しかったのは、3番「開発テーマの一覧を並べる」の後に、その選択肢が本当に網羅的かどうかを示すことでした。なぜなら、R&Dで一般に扱うような専門性の高い選択肢と、事業部のBiz含む多様な人の選択肢は、空間が全く揃っていないのです。

視点の違いを表した例として、「音声認識の精度向上」と聞いた時に、

AIエンジニア: 機械学習モデル改善
事業部（特にBiz）: より良いマイクを顧客に配布

といったふうに、全く違う選択肢を想起したりします。

この認識を揃えるために試行錯誤がありましたが、行き着いた結論はシンプルで、「AIの精度向上に寄与しうる要素の地図を描いてから、具体の開発テーマを配置する」というものでした。

戦略に関わる部分なので大分ボカしていますが、ざっくり言うと以下の図のようなイメージです。

上記の図では、まずAIの構成要素を入力 → 処理 → 出力のように分解します。入力や処理の構成要素がさらに分解できそうな場合は分解します（図の赤色; 事前学習 / Finetuneなど）。ここまでで、精度に寄与する要素を洗い出します。

このような一枚絵を作っておけば、「マイク品質の向上」「訓練データ量の増加」といった精度向上施策＝開発テーマをすべて同じキャンパス上に配置することができます（図のオレンジ色）。各ステークホルダーが「自分の観点がマップ上のどこにあるか」を即座に把握することが出来るようになり、視点の非対称性を最小化することができます。そして、「抜け漏れがあるのでは？」という不安が消え、議論を網羅性から優先度へと進めることが出来るようになりました。

6. 【改善・拡張】アーキテクチャ戦略

AIモジュールが事業部の行う様々なプロジェクト / プロダクトに対して規模の経済を働かせるためには「再利用性」の高さが重要です。しかし理想として聞こえは良いものの、実際は再利用性を高めるための汎用化・個別化のちょうど良い塩梅を見つけることは大変です。

個別化しすぎ: プロジェクト個別のユースケースに依存するロジックが紛れ込むと再利用しづらい
汎用化しすぎ: プロジェクトでの使い方がわからず事業部に活用されない

といったようなトレードオフがあります。

またAIモジュールが実際に稼働するようになると、顧客からの精度改善要望などのVoC対応も含めた、保守運用作業が発生します。この際に「個別化しすぎ」でAIエンジニアが個別のビジネスロジックにまで広がっていると、AIエンジニアのメンテナンスコストが上がり、本来の役割であるAI技術のR&Dに十分なリソースを割けなくなる危険があります。

6.1 アーキテクチャの可視化と共有

上記の問題に悩まされましたが、根本には責任分解点についての明確かつ技術的な共通認識がなかったことが原因と考えています。具体的に言うと、R&Dチームの中に暗黙的に存在していたAIモジュールの定義が、他の事業部を含むステークホルダー全体に対して技術的に明確な形で表現できておらず、またそれを伝えるためのコミュニケーションも足りていなかったのだと思います。

そこで我々は、AIモジュールの役割を技術的に明確な形で表現するために、改めてアーキテクチャパターンを以下のような図に起こしました。

この図は、

AIモジュールがpython packageの形で配布されること
AIモジュールの責務にプロジェクトに固有のビジネスロジックを含めないこと
AIモジュールはそのまま利用されるのではなく、プロジェクト固有の調整が必要となること

などを端的に表しています。

このような図示を行うことで、それまでふわっと存在していたAIモジュールの定義やそれに基づく責任分解点が、エンジニアなら具体的に（コードレベルで）想起できる状態になりました。これにより、例えば、

「今まではR&D部門のAIエンジニアが、AI処理マイクロサービス部分のビジネスロジック部分まで開発・運用を担っていたので、もう一度リソース配置を見直そう」

といった会話がスムーズにできるようになりました。

（このほかにも、実はR&Dチームの共通基盤を含めたより巨大なアーキテクチャ図を書いたことや、C4モデルに従ってアーキテクチャ図を書くことでBizも含めた説明性の向上などにも取り組んできましたが、本記事では割愛します）

6.2 グレーな部分を残す

このように責任範囲をクリアになったおかげで、AIエンジニアの専門分野への集中が進んだように思います。しかし、完全な境界線が引けているかと言うとそういったわけではありません。私（AIエンジニア）がビジネスロジック部分を書く場合も残ってますし、逆に事業部のSWEの方にAIモジュールに対してPRを出してもらうこともありました。

そもそも「ある処理が汎用的か個別的か」を将来のプロジェクトの展開まで見据えて事前に定義するのは困難です。加えて、責任分解点をはみ出してお互いのソフトウェアにある程度理解がある方が、フロー効率をあげたり、属人化の少ないロバストな組織づくりに役立つかもしれません。責任分解点についての共通認識という土台を前提にしつつ、運用はファジーで良いかもしれません。

7. 今後の課題 - 大LLM時代への適応

近年のLLMの台頭により、AIエンジニアを取り巻く状況も大きく変わりつつあります。

一つ目の大きな変化は、モデル内製の優位性が相対的に低下したことです。LLM登場前のAIエンジニアの主要ミッションといえば 「独自モデルを内製し精度で差別化する」 ことでした。しかし、OpenAIのGPTをはじめとする基盤モデルが台頭することで高精度モデルのコモディティ化が進み、“モデル単体” での競争優位が作りにくい 状況が生まれています。

この新しい環境下で、かつてAIエンジニアと呼ばれた人々は、以下の領域への転換や拡張を迫られているように感じます

基盤モデル側: 巨大な計算リソースを用いた基盤モデル自体の開発や、独自データによる継続的なファインチューニングなど、専門性を突き詰める
ビジネスプロセス側: APIやオープンソースの外部AIモデルを活用して、人間のビジネスプロセスをより多く・より高精度に代替や拡張をする

例えば2の方向に進む場合は、5章で述べたアーキテクチャ設計なども全面的な見直しが必要と考えています。

💡LLMによるAIエンジニアの責任範囲とアーキテクチャ設計の変化については、AI Shiftの安井さんの記事に分かりやすくまとまっています https://zenn.dev/aishift/articles/c897d0e095c3d8

二つ目の大きな変化は、シーズベース開発の重要性が増していることです。4章では「事業部の要求を受け、優先順位を付ける」流れを重視してきました。しかしLLMの進化速度は、要求が顕在化する前に機会が陳腐化するレベルです。技術起点での高速検証が大事になりつつあります。

弊社ではこの状況に対して、FBループを高速化するために、導入ハードルが低い社内の業務に対してまずはAIを導入することが大事という仮説を持っています。この辺りは具体的に進んでいる案件もあるので、他のメンバーが共有してくれることを期待しています！

8. むすびに

本記事では、ACESのR&D部門のAIエンジニアが、AIモジュール開発を通じて事業部と連携し、顧客に価値を届けるまでの取り組みについてご紹介しました。①R&Dとソフトウェアエンジニアリングの融合、②要求の受け渡しと優先順位付け、③継続的な改善・拡張を可能とするアーキテクチャ設計など、課題解決に向けた複合的な施策を実施しています。

しかし、昨今のLLMの急速な進展もあり、私たちも常に変化を求められています。ACESでは、このような変化をチャンスと捉え、共に課題に立ち向かう仲間を募集しています。AI技術を通じて社会にインパクトを与えたい方々のご応募をお待ちしています！