「要件定義」が日本のDXを加速させる。生成AIで設計を誰でもカンタンに

はじめに：なぜ「要件定義」に向き合うのか

DXが進まない理由として、技術の問題や人材不足がよく挙げられます。しかし、SIerと事業会社の両方で現場に立ってきた自分の実感としては、もっと根本的で見えづらい部分に本当の原因があると感じています。それが、要件定義です。

SIerにいた頃は、「顧客の要望がよく分からない」「完成してからズレが発覚する」といった課題に日々直面していました。一方で、事業会社側に立ってみると、「提案されたシステムが思っていたものと違う」「確かに言った通りではあるけれど、本当に欲しかったものではない」と感じることも少なくありませんでした。

どちらの立場でも、相手に対して何かしらの違和感やすれ違いが生まれてしまう。それは、個人の能力や経験だけではどうにもならない構造的な問題だと、次第に思うようになりました。現場では、要件をどうすり合わせるかの仕組みが不十分なまま、誰もが手探りで設計の議論を進めています。

私が社会人になってから20年が経ちますが、要件定義の属人性や不透明さは、当時からずっと課題として語られてきました。にもかかわらず、いまだに多くの現場では明確な打ち手がないまま、同じような失敗が繰り返されています。変わらないままの現実を、そろそろ変えなければならない。その思いから、このテーマに向き合うことを決めました。

DXは"最初の設計"で9割決まる

日本のIT市場は約15兆円規模にのぼるとされています（※出典：矢野経済研究所「IT投資動向調査 2023」）。その中でも、要件定義や業務設計といった上流工程は2〜3割を占め、5兆円以上の規模があるにもかかわらず、その多くは曖昧で属人的なまま進められているのが現状です。

私はこれまで何度も、要件定義が不十分なまま開発がスタートし、プロジェクトが迷走していく現場を見てきました。開発フェーズがある程度進んだ段階で「そもそもの前提が違う」と気づいて設計をやり直したり、ようやくリリースしたものの現場では「全く使われていない」といった事態が起こる。そうしたケースは決して珍しくありません。

こうした失敗の多くは、技術的な実装ミスではなく、初期の要件定義に原因があります。関係者の間で期待値や目的、前提条件が揃っていないまま開発が進めば、完成後にギャップが顕在化するのは当然の結果です。そしてその修正には、多くの時間とコストがかかるだけでなく、プロジェクトそのものの信頼性を損なうことにもなります。

逆に言えば、要件定義の段階で関係者の認識を揃え、目的や構造を明確にできれば、開発はスムーズに進み、リリース後の活用度や定着率も高まります。だからこそ、要件定義はDXにおける分水嶺だと私は考えています。成功するプロジェクトと失敗するプロジェクトの差は、この初期段階での設計精度にこそ現れるのです。

要件定義のプロセスは再現できる

ROUTE06でプロフェッショナルサービスの事業責任者として過ごした5年間、私は数多くのプロジェクトに携わってきました。構想の方向性がぼんやりと浮かび始めた段階から入り、要件定義、UI設計、開発、リリース、そしてグロースの支援まで。一連のプロセスを一気通貫で伴走する案件を、繰り返し推進しました。

その中で私が大切にしていたのは、単に「聞く」ことではなく、「先に見せること」です。お客さまが言語化しきれていないアイデアや期待に対して、こちらから先回りして、仮説を具体化する。初回のヒアリングを経た2回目の打ち合わせには、Figmaで構成した画面イメージや業務フロー案を持っていくのが、私たちのスタイルでした。

「もうこれだけ出せるの？」と驚かれることもありましたが、むしろそれが狙いでした。プロジェクトを前に進めるには、言葉だけのすり合わせでは限界がある。構造化されたプロトタイプがあれば、お客さまの理解は深まり、議論の精度も一気に上がります。何より、チーム全体が自分ごととしてプロジェクトに関わってくれるようになるのです。

このような取り組みを積み重ねる中で、私はある共通項に気づき始めました。設計プロセスには型があるということです。感覚や経験に頼っていたと思っていた部分も、振り返れば、一定の論点整理や判断ステップに沿って動いていました。そしてそれは、ある程度の条件が揃えば、他のメンバーでも再現できるはずだと感じたのです。

たとえば、

業務ヒアリングの中で、どの情報を構造化するか
抽出した課題のうち、どこを出発点に設計を始めるか
類似サービスやIR情報などをもとに、どのように改善方針を立てるか
提案の優先順位をどう整理し、どう納得感のある順序にするか
UIや機能を、どの粒度で可視化するか
設計書や稟議資料に落とし込む際、どの観点を担保するか

これらはすべて、現場で頭の中でやっていたことです。属人化されがちな思考のプロセス。でも、実際には論理として整理可能で、パターン化もできる。私はそこに、要件定義を再現可能にする鍵があると確信しました。

もちろん、全体を完全にAIに任せられるとは考えていません。ただ、人が考えるべき部分と、仕組みで支援できる部分をきちんと切り分けることで、誰でも設計のベースラインに立てるようになる。その環境づくりこそが、私たちがこの5年間の現場で積み上げてきた知見であり、Acsimというプロダクトに込めた思想です。

要件定義を、一部の人の技術や勘に頼るものから、再現性のあるプロセスに変えていく。それは、DXをできる人がいるからできるのではなく、どの現場でも進められるものにするために、私たちが提供すべき価値だと考えています。

思考を仕組みに、生成AIで要件定義を誰でもカンタンに

Acsimが目指しているのは、要件定義を自動化することではありません。人が要件定義をできるようになること。そのために、生成AIが考える過程を支え、プロジェクトの推進者が設計の全体像を描けるようにする。そこに本質があります。

要件定義というと、業務フローを描いたり、機能一覧を整理する作業だと思われがちです。でも実際には、もっと広く、複雑で、重層的な業務が詰まっています。

現場ヒアリング、構想整理、課題の構造化、改善提案、関係者との認識合わせ、画面や機能の具体化、稟議資料の作成。これらすべてが「要件定義に含まれない」とは、もはや言えません。むしろ、プロジェクトの初期に必要とされる動きのほとんどが、要件定義に強く関わっているのです。

私たちは、ROUTE06で数多くのプロジェクトを手がける中で、このプロセス全体を構造化し、思考の順序や観点の切り口に型があることに気づきました。たとえば、「課題をどう特定するか」「改善方針をどう設計に落とし込むか」「どの粒度でプロトタイプを示すか」といった思考の流れは、ある程度整理可能で、支援可能な領域です。

Acsimは、まさにこの思考の補助線を生成AIによって提供することを目的に設計されました。現状把握、課題提起、改善提案、高速プロトタイプ生成、設計書出力、システム稟議。これら一連の要件定義業務すべてを、AIがサポートすることによって、従来は一部の経験者にしか担えなかったプロセスを、誰でも扱えるものに変えていきます。

もちろん、AIがすべての判断を代行するわけではありません。人が考えるべき部分は残しつつ、その思考を広げ、深め、支える役割を担う。推進者が「こういう考え方もあったか」と視点を増やせるような支援を通じて、設計の質とスピードを高めていく。それが、私たちの目指したい姿です。

要件定義は、もっとカンタンになっていい。でも、それは単に手を抜くという意味ではなく、「考えることに集中できる環境をつくる」ということ。Acsimは、そのための道具として開発されました。

なぜAcsimがSIerにとっての武器になるのか

Acsimは、上流工程という曖昧で非効率な領域を仕組みに変えるソリューションです。そして、それこそが、今のSI業界にとって最も差別化が難しく、最も価値のある領域だと私は考えています。

商談の場面を想像してみてください。コンサルティング担当者がヒアリングを重ね、要件を整理し、提案資料を仕上げるまでにかかる時間と工数。属人性が高く、経験値によって提案の質とスピードに大きな差が出てしまうのが現実です。

Acsimを導入すれば、この「提案の前工程」、つまり要求定義から要件定義へつなげるプロセスを、誰でも実行できるようにすることができます。現状の可視化、課題の構造化、改善方針の提示、プロトタイプ生成、設計書出力までを一貫して支援し、提案を型として再現可能にする。それによって、プリセールスや要件定義を得意とする少数の人材に依存せず、組織全体で要件定義力を底上げすることができるようになります。

その結果として、要件定義ができる人材が社内に増えることは、提案フェーズの幅を大きく広げます。たとえば、要件定義ができる人＋ソフトウェアエンジニア（SWE）という新しいユニットを社内で編成できるようになれば、顧客への追加提案や小規模PJの横展開も加速します。提案から実装までを内製で完結できる体制を、小さく・柔軟に組めるようになるのです。

さらに、上流工程から案件を獲得できるというのは、ビジネス上のインパクトも大きいと私は考えています。従来のように開発フェーズから参入する場合、比較されるのはコストとスピードです。一方、構想段階や業務改善の設計段階から関わることができれば、ベンダーではなく選ぶ側のポジションを確保できる。そこには、単なる受託ではない提案価値と収益性の余白があります。

Acsimは、SIerにとって「要件定義力を組織に根付かせるための仕組み」であり、同時に「上流から提案・獲得できるチームをつくるための武器」でもあります。それが、私たちがこのプロダクトに込めた実用的な狙いです。

関係者全員の課題に向き合うプロダクト

SIer、事業会社ともに、それぞれの立場で要件定義の不確かさに悩まされてきました。だからこそ、Acsimは誰か1人のためのツールではなく、プロジェクトに関わる全員にとって役立つプロダクトであることを意識して設計しています。

SIerの立場から見れば、Acsimは開発のズレや手戻りを減らす武器になります。現場の会話から業務フローや機能要件が構造的に整理され、設計書やプロトタイプとして明文化されることで、「思っていたものと違う」といったトラブルを防ぐことができます。要件定義の精度が高ければ、開発やテストも無駄なく進み、結果としてプロジェクトの収益性も高まります。

事業会社にとっては、Acsimが本当にほしかったものを引き出すための思考の補助線になります。社内のユーザー部門や経営層にとって、「こういうことをやりたい」が明確になっていないケースも多い中で、業務を構造的に捉え直し、改善案を形にするプロセスを、Acsimがサポートしてくれる。だからこそ、話しているうちに「これならイメージできる」「これがあれば現場が動く」と納得感が得られる。設計の納得感は、そのまま導入後の活用率にも直結します。

要件定義は、これまであまりにも個人に依存するものとして扱われてきました。でも、本当は関係者全員の情報と視点をつなぐ、最も重要なプロセスのひとつです。だからこそ私たちは、Acsimを全員を救うプロダクトとして育てていきたいと思っています。

設計のやり方を変えれば、日本の開発はもっと進む

私はこの10年以上、開発の最前線で「要件定義」の現実と向き合ってきました。ヒアリングから始まる一連のプロセスは、やればやるほど奥が深く、成果が出るほど属人性が強くなるというジレンマも抱えています。けれど同時に、いくつものプロジェクトを経る中で、その中には共通する構造があることも見えてきました。

Acsimは、その経験と気づきをもとに、要件定義というプロセスそのものを再設計しようとする試みです。現場の思考や判断、対話や調整を支える仕組みとして、生成AIを使って支援する。誰かの勘やスキルに頼るのではなく、「考え方の筋道」をツールに埋め込むことで、誰もが一定以上の品質でプロジェクトの初期フェーズを進められるようにする。

それは単に効率化ではなく、開発プロセス全体の構造を変えていくアプローチだと考えています。最初の認識が揃えば、設計もブレず、実装も迷わず、ユーザーへの価値提供もスムーズになる。上流が変われば、すべてが変わる、それが、私たちがこのプロダクトに込めた想いです。

そしてこの挑戦は、私たちだけで完結するものではありません。現場を知っている人、提案の最前線にいる人、顧客と長く関係を築いてきた人たちと一緒に、Acsimという仕組みを育てていきたいと願っています。

要件定義を、チームで進められる共通プロセスに変える。 Acsimはそのための土台です。今この仕組みを、共に社会実装していけるパートナーと、新しいスタンダードをつくっていきたいと思います。