「要件が決まらない」のは、要件定義の問題ではない。 システム開発で抜け落ちる「構想整理」とは

システムや業務アプリケーションの開発・刷新の現場で、「現場から課題は出ているのに、要件がまとまらない」「要件定義を始めたものの、本当にこの方向でいいのかわからない」という状態になることがあります。

現場の課題を整理し、「何を変えるべきか」を考える工程を飛ばしたまま、要件を決めようとしている。PIVOTでは、この「課題」と「要件」の間にある工程を、構想整理として捉えています。

たとえば現場から、

「入力が面倒」
「システムが使いにくい」
「業務が属人化している」

といった声が上がっていたとします。どれも大切な情報です。

ただし、「入力が面倒だから入力項目を減らそう」とすぐに機能や仕様へ落とすのは少し危険です。入力項目が多いことが原因なのかもしれませんし、同じ情報を何度も入力しているのかもしれません。特定の担当者だけに入力作業が集中している可能性もあります。

つまり、現場から上がってくる課題は、言ってみれば “症状”です。症状だけでは、何を作ればいいのかは決まりません。

必要なのは、一度業務の文脈に戻り、

• 誰が困っているのか
• どの業務・どの場面で起きているのか
• なぜ、その状態になっているのか

を整理することです。

たとえば「入力が面倒」という声も、「特定の業務工程で、特定の担当者に入力作業が集中している」と整理できれば、話は変わります。

画面を改善するのか。
入力作業を分散するのか。
データ連携によって入力そのものを減らすのか。
業務フローから見直すのか。

ここで初めて、「何を変えるべきか」を議論できます。

多くのプロジェクトでは、

課題 → 要件

と進もうとします。

早くプロジェクトを前に進めたいからです。

しかし、本来その間には、

課題 → 整理 → 構想 → 要件

というプロセスがあります。

「要件が出てこない」のではなく、課題を要件へ変換する工程そのものが抜けているケースがあるのです。

構想整理とは、壮大な事業構想を描くことだけを指すものではありません。現場で語られている曖昧な困りごとを整理し、プロジェクトで判断できる言葉へ翻訳していくこと。言い換えれば、現場の言葉を「設計できる言葉」に変える工程です。

この前提が揃って初めて、

「何を作るか」
「何を作らないか」

という判断ができるようになります。

構想整理がないままプロジェクトを進めると、途中でこんなことが起こります。

事業部門は、現場の困りごとや実現したい成果をもとに話します。

一方、IT部門や開発会社は、それを仕様や機能として形にしようとします。どちらも正しいことをしています。

しかし、

「誰の業務を変えるのか」
「何を変えたいのか」
「なぜ、それが必要なのか」

という前提が共有されていなければ、具体的な画面や仕様が出てきたところで、

「思っていたのと違う」

が起こります。

これはデザインや開発の問題というより、その手前で認識を揃える工程がなかったことによるズレです。

だからこそ、要件定義に入る前に一度、「そもそも何を実現するプロジェクトなのか」を見える状態にしておく必要があります。

構想整理というと、開発の前に工程がひとつ増えるようにも見えます。しかし目的は、検討期間を長くすることではありません。

早い段階で、

現場やユーザーの業務を理解する。
課題と原因を整理する。

シナリオや画面ラフなどを使って、目指す状態を見える形にする。何を実現するか、どこまで作るかを判断する。こうした検討を行い、要件定義や開発に進める状態をつくることが目的です。

言葉だけでは認識が揃いにくい場合には、簡易的な画面やプロトタイプをつくり、関係者が同じものを見ながら議論することもあります。完成したデザインを先に作るためではありません。

「自分たちは何を作ろうとしているのか」を、早い段階で確かめるためです。結果として、要件定義の途中で前提から議論し直したり、開発後に大きな認識違いが発覚したりするリスクを減らせます。

実際のプロジェクトでは、

✓ 「システムを刷新したい」という方針は決まっている
✓ 現場の困りごとも見えている。
けれど、何を作ればいいのかはまだわからない

そんな状態は珍しくありません。

PIVOTが支援したあるシステム刷新でも、長年の追加開発によってシステムが複雑化し、社内の誰も全体像を把握できていない状態からプロジェクトが始まりました。そこで、いきなり新しいシステムの要件を決めるのではなく、まず利用実態や業務フローを整理。今後のあるべき姿を仮説として可視化し、ユーザーの評価を重ねながら方向性を具体化していきました。

「何を作るか」を決める前に、「何を変えるべきか」を整理したのです。もし今、

• 現場の課題は出ているのに、要件がまとまらない
• 話し合っているのに、関係者の前提が揃わない
• 具体的な仕様を見るたびに「何か違う」と感じる

のであれば、要件定義の方法を見直すだけでなく、一度その手前へ戻ってみることも必要かもしれません。誰の、どの業務を、なぜ変えたいのか。

ここが整理されて初めて、「では何を作るのか」という議論ができます。

「要件を決められない」のではなく、まだ要件を決めるための構想が整っていないだけかもしれません。

PIVOTでは、現場やユーザーの理解から課題を整理し、構想の可視化、開発へつなげるための要求整理まで、一連のプロセスをご支援しています。

そして、相談するために要件を整理しておく必要はありません。

PIVOTの「よろず相談」では、具体的な発注内容が決まっていない段階から、現在の状況や課題をお聞きしながら、一緒に整理するところからご相談いただけます。

まずは壁打ちするくらいの気持ちで、お気軽にご相談ください。