やりたいことを「要件」に翻訳するとはどういうことか

ヒアリングの場で、私はほぼ毎回同じ言葉を聞きます。「何から手をつければいいか分からない」「最終的にどうなれば正解なのかも分からない」。困っていることは確かにある。けれど、それが何なのかをまだ言葉にできていない。多くの会社が、そういう状態で相談に来られます。

これは能力の問題ではありません。日々の業務に追われていれば、自社の困りごとを腰を据えて言語化する時間など取れないのが普通です。ただ、ここで一つだけ知っておいてほしいことがあります。「やりたいこと」と「要件」は別物で、その間には“翻訳”という作業が必ず必要になる、ということです。この記事では、その翻訳とは具体的に何をすることなのかを、実際の相談事例を交えて説明します。

「やりたいこと」は、まだ自然言語にすぎない

「業務を楽にしたい」「AIで効率化したい」「システムを刷新したい」。これらはすべて、人が普段使う言葉、つまり自然言語です。気持ちは伝わりますが、このままでは誰も動けません。「楽」が何を指すのか、どこまでやれば達成なのか、人によって思い浮かべる完成形がバラバラだからです。

私たちが提供するITツールやAIは、あくまで**手段（How）**です。手段は、目的（Why）と、達成すべき状態（What）が決まって初めて選べます。順番が逆になり、手段から入ってしまうと、何のためにやっているのかが最後まで曖昧なまま進み、効果があったのかどうかすら測れなくなります。

「要件」とは、後で正解を判定できる状態のこと

では翻訳の到達点である「要件」とは何か。難しく考える必要はありません。**達成できたかどうかを、後から誰が見ても同じように判定できる「完成イメージ」**のことです。

「業務を楽にしたい」は判定できません。一方、「月末の請求書発行にかかっている8時間を、2時間以内に短縮する」なら、できたかどうかが誰の目にも明らかです。前者が自然言語、後者が要件です。やりたいことを、この「後で正解を判定できる形」まで噛み砕いていく作業が、翻訳の正体です。

事例：「とりあえずよくしたい」の中身を解きほぐす

先日、あるシステムインテグレーターから相談を受けました。彼らは自社で開発・導入したアプリケーションを運用しているのですが、開発をオフショアに委託していたため、そのアプリが内部でどう動いているのかを社内で把握できていない、という状態でした。

最初のヒアリングで出てきた言葉は、「とりあえず、この状況をよくしたい」。これだけです。気持ちは分かりますが、これでは私たちも動けません。「よくしたい」が何を指すのか分からないからです。そこで、目的は何なのか、なぜそれをやらなければいけないのか、どんな機能やライブラリを使っているのか、を一つひとつ時間をかけて確認していきました。

掘り下げていくと、彼らが本当にやりたかったことが見えてきました。アプリの挙動を把握したい。そのうえで、安全にテストやCI/CDといった、一般的なソフトウェア開発ライフサイクル（SDLC）で当たり前に使われている手法を導入したい。これが本音だったのです。

ここで重要なのは、最初の「よくしたい」の中に、実は性質の異なる複数のゴールが混ざっていたという点です。

• コードの全体像をリバースエンジニアリングで把握したいのか
• 安全に変更できるよう、テストやCI/CDといったSDLCの仕組みを入れたいのか
• それらを自分たちで回し続けられるチーム体制を作りたいのか

このどれを優先するかで、私たちの支援内容はまったく変わります。コード把握が主眼なら現状調査とドキュメント化が中心になりますし、SDLC導入ならパイプラインの設計が中心、チーム体制が主眼なら教育と運用ルールづくりが中心になります。「よくしたい」のままでは、このどれにも手をつけられません。逆に、ここまで翻訳できれば、何をどの順番でやるかは自然と決まります。これが、やりたいことを要件に翻訳する、ということの実際です。

AIも、目的になりやすい「手段」のひとつ

いま、この「手段が目的になる」現象が最も起きやすいのがAIだと感じています。「AIを導入する」こと自体がゴールになってしまっているケースは、本当に多い。

もちろん、自社にAIが使えるのかどうかを見極める検証段階では、「AIを試す」こと自体が一時的な目的になるのは構いません。問題は、その先です。AIで業務効率化を実現したいのであれば、どの業務の、どの作業を、どう変えるのか、その結果どんな効果を、いつまでに出すのか——という手段（How）の中身を、具体的かつ正確にしていく必要があります。「AIを入れた」だけでは、楽になったかどうかは誰にも分かりません。AIは目的ではなく、要件が決まって初めて選ばれる手段の一つです。

翻訳は、まず自分の手で「現状把握」から

では、相談に来る前に自分たちで何ができるか。完璧な要件を作る必要はありません。まずは現状を把握し、自分なりに言語化してみることです。

おすすめは、困りごとを 5W1H に当てはめてみることです。なぜそれを解決したいのか（Why）、何が、どこで、いつ困っているのか、誰がその作業をしているのか。そして、いまの状態と、こうなったらいいなという理想の状態を、両方とも書き出してみる。この「現在」と「理想」の差分が、そのままやるべきことの輪郭になります。

書き出してみて、それでも本当に困っていることが何なのか分からなければ、それで構いません。分からないという発見自体が前進です。分かるところまで現状把握を繰り返し、周囲の人に相談してみる。その往復のなかで、ぼんやりした「やりたいこと」が、少しずつ判定可能な「要件」へと翻訳されていきます。

翻訳しきれない部分こそ、専門家の出番

とはいえ、自社だけで翻訳を最後までやり切るのは簡単ではありません。先のSIerの例のように、本当のゴールが複数のゴールの中に埋もれていて、自分たちでは切り分けられないことも多いからです。

私たちがヒアリングで時間をかけているのは、まさにこの翻訳作業です。「とりあえずよくしたい」を、なぜ・何を・いつまでに、まで一緒に解きほぐし、後で正解を判定できる要件にする。手段としてのツールやAIを選ぶのは、その後で十分間に合います。

もし、やりたいことはあるのに要件の形にできずに止まっているなら、その言語化の段階から一緒に進めることができます。まずは現状を、不完全でいいので書き出してみてください。その一枚があれば、翻訳はぐっと早くなります。