「要求」を言語化する技術
僕はIT系の職種の方にはもちろん、非IT系の職種の方にも強くおすすめしているスキルがあって、それが「要求」を言語化する技術です。
これまでの社会人人生で、この能力があるのとないのとで、依頼先の人の力をどれくらい引き出せるかが圧倒的に変わってくるなというのを体感してきました。
※今回の話は、要求の抽象度の話など微妙に業界で統一的な見解があるものでもないので、僕の持論ぐらいに思っていただけると幸いです。
前提
ビジネスの（特にIT系の）現場では、「こんなものが欲しい」という漠然とした話から、具体的な機能や納品物を生み出すプロセスが日々行われています。しかし、このプロセスでは結構な確率で問題が発生します。
例えば、依頼内容が曖昧すぎて、最終的な成果物に齟齬が生じたり、逆に、細かな内容まで書きすぎて依頼される側が全部を守ろうとして大変になるなどです。
こういった問題を避けるために重要なのが、「要求」の言語化です。
「要求」の言語化とは何か？
「何かをやりたい」もしくは「何かをやって欲しい」そういう場合にその依頼はこの図のように抽象度で分けることができます。
この図が示すように、依頼には「要望」「要求」「要件」「仕様」といった段階があります。私たちが目指すべきは、「要求」のレベルでの言語化です。
なぜなら
「要望」は曖昧すぎて具体的な行動に結びつきにくい
「要件」や「仕様」は技術的な制約が強すぎて、創造性や柔軟性を阻害する可能性がある
からです。
「要求」レベルでの言語化は、目的と制約を明確にしつつ、実現方法に柔軟性を持たせることが可能になり、その依頼を受けて仕事をする側の能力を存分に引き出せる可能性があります。
要求の言語化の例：電気ポット
先ほどの画像の資料の例が非常にわかりやすいので、さらに引用させていただきます。
例えば、電気ポットの例においては、要望レベルは「電気ポットが欲しい」や「あったかいお湯を出すマシンが欲しい」といったものです。
これだけで作業にとりかかることもできそうですが、実務の中でこのレベルで作業に取り掛かり始めると、詰めないといけないことが多く非常に非効率になります。（このレベルのものを出してあとは聞いてくださいと言われると、無限クイズ大会をしている気分になります）
これに対して要求の例は以下のようになります。
いかがでしょうか。それが求められている背景や制約条件がわかったことで、とても検討が進めやすそうではないでしょうか。
それに対して、要件（システム開発では主に開発側が作るもの）は以下のようになります。
要求を元に、実際に開発をするために必要な事項が整理されていることがわかります。
よくシステム開発で「要求を具体的にしてください」と伝えると、要件や仕様を検討しようとがんばってしまう人がいるのですが、
要件が決められてしまうと、逆に開発においてとれる選択肢の自由度が下がってしまい、書く側も徒労に終わったりするので、お互いに不幸な状況になってしまいます。
あくまでも欲しいのは「要求のレベルの具体化」なのです。
なぜ「要求」が大事なのか：例をもとに
さらに理解を促進するために、今回の例に当てはめて、なぜ「要求」が大事なのかを考えてみると、たくさんの理由が浮かび上がってきます
言い忘れている制約条件がありがち
早く沸かしたいと言われるけど、実際電気代がかかりすぎると怒られる等
目的によってHOWが大きく変わる
例えば同じ電気ポットでも、赤ん坊のミルクを作るのが主眼の場合と、コーヒーを普段入れるのが主眼の場合でとるべきHOWが変わることが多い
また、要求者が気づいていない「衛生観点も大事」みたいな目的があるとその途中で大事なものにもこちら側も気づけることがある
要求者しか知らない隠れた前提はめちゃくちゃある
例えば、「水道水を普段使っておらず、基本的にウォーターサーバーから使いがち」だとすると、カルキ抜き要件は必要なくなるなど、普段要求者がどうしているかを知らないとわかりようがない隠れた前提がめちゃくちゃある
要求者すら知らない隠れた前提もめちゃくちゃある
例えば「空焚き予防が必要」などは、言われないと出てこないが、言われたら「当然それは欲しい」となる。そう言った要件もめちゃあるので、要求を眺めながら実は隠れた要求や要件がないかをこちら側では考える
そもそも要求者が求めているものが求めているものではなかったということもよくある
例えば要求を整理してみると「これって、電気ポットではなくて電気ケトルの方がよくないですか？」「なんなら、お湯がでるウォーターサーバーの方がよくないですか？」となることすらすごく多い。しかし「電気ポットが欲しい」と言われてそれにだけ答えると、最終的に双方不満を持つことが多い
ユースケースを想像すると新たに出てくる要求もある
例えば、コーヒーを注ぐといっても、ドリップコーヒーかインスタントコーヒーかによって、「お湯の注ぎ口は細い方が良いのか、大きい方が良いのか」すら変わってくる
要件は出されると技術者側の検討難度が上がったりする
例えば「電気ヒーターで湯をどんな時でも出せるように」と要件を言われると、「魔法瓶の技術」や「ガス形式」でとても良い技術があっても提案できなくなったりします。（依頼者側は大抵、「そんな考えて書いたんじゃないのに・・・」というのですが、当然受け取る側は書かれた内容に何らかの意図があると読み取るので、その範囲内で考えようとします。）
また、少し俯瞰した視点からみると、この「要求」は適切に書けると普段の業務における「依頼側と受託側の責任分解点」とすることができます。
そうなると、依頼した業務を受託する側からのアウトプットが不満だった時に、自分の出した要求を見直して、要求に書けていないことなのであれば、完全に自分の問題だと捉えることができて次への学びになりますし、要求に書いているのにできていないということであれば、受託側で何らかの問題が発生しているとして捉えることができます。
業務で実際に要求を作る際の項目例
いろんなパターンがあるので以下はあくまで例になります。基本的には要件に入らなければ詳しければ詳しい分には問題ないことの方が多いと思います。
概要
依頼したい内容の概要。電気ポットでいうと「10度くらいの水道水を入れたら、95度くらいのお湯になっている状態を作りたい」など
背景
なぜこれを要求するに至ったのか。「最近、朝10時からのMTGが増えたため、コーヒーをいちいちやかんでお湯を沸かすのが朝忙しい中では嫌になってきた」など
目的
なぜこれをやりたいのか「美味しいコーヒーをいれるためのお湯を短時間で沸かしたい」など
スコープ（どこからどこの範囲でこれを実現したいのか）
どの範囲でこれをやりたいのか「対象とする液体は水道水だけでよい。ただし朝のコーヒーだけでなく、掃除の時や料理の時などでもお湯は使う想定」
逆にノンスコープ（水道水以外の液体は使わないなど）がある場合もここに書く
インプット
何を与えるのか。ポットであれば常温の水道水。
加工
インプットにどんな変化を加えたいのか。ポットであれば加熱をすること。
アウトプット
最終的に何を出せば良いのか。ポットであれば95度くらいのお湯。
制約条件/与件条件
隠れた制約条件がないか意識しながら書き出す「1分以内で沸いていること、電気代は２円以内であること」「掃除は週に1回くらいしかしないようにしたい」など
対象ユーザー
「庶務さんでも使える必要がある」など
ユースケース
「朝起きて、ポットに水を入れて、ボタンを押して、お湯が沸いたらそれをインスタントコーヒーを入れたコップに注ぐ」など
要求を言語化する際は、箇条書き＋インデントなどを使って、階層構造を見せるように表現できると、どの中に何が入っているかがわかりやすくなるのでオススメです。
また、要求には「動詞＋目的語」が含まれていると仕様化しやすいという性質もあったりします。「電気ポット」ではなく「お湯を作り出せる」のように、可能ならそういった表現を考えたり、自分の書いた要求に動詞が入っているかはチェックしてみても良いかもしれません。
実務で使う際の重要ポイント
システム開発系の実務で使う際には、インプット・加工（データ活用系案件で必要になることが多い）・アウトプットがイメージしづらいかもしれませんが、これらは「情報・データ」などが入ります。
例えば、退職金の予測をするという業務であれば、「インプット：従業員の年齢情報と現在の職位情報」を元に「加工：人事規定で決まった数式に基づいた加工」を行い、「アウトプット：従業員ごとの65歳定年時の退職金予測金額のCSV」を出す。のようになります。
この際、「加工」は曖昧だったとしても、インプットとアウトプットは項目や中身も含めてサンプルを出せると、圧倒的に検討しやすくなります。
「退職金予測金額」なんてイメージしたらわかるじゃん、と思っても、実際にアウトプットを考えてみると「本当に従業員番号と退職金予測金額だけでよい？、いざサンプルデータ作ってみたら、従業員番号の横に名前は最初から欲しいし、退職金予測金額もその人の予測退職日とセットで渡した方が良くない？」などと色々な論点が出てきます。
そのためにも無理にでもアウトプット検討をすることは大事です。
また、今回は「要求を自分で検討する」という前提で書いていますが、一方でシステム側には「一定考えた上で早めのタイミングで相談する」ということも自分はオススメします。
早めに軽く相談すると、思ってもいなかった項目や開発する上では重要な論点が聞けたりすることが多いです（例えば開発的には標高が高い場所でポットを使う前提かどうかで気圧の対策が変わる、など）。そのため自分が受託する際は早めに相談はして欲しいが、実際に要求する際には極力要求を言語化してくることをお願いしています。
現代は圧倒的に優秀なエンジニア不足が叫ばれていますが、個人的には優秀なエンジニアの方ほどこの「要求をうまく言語化できる」人との仕事を好むように思います。
また、本件は本質的にITに限らず業務の中で「依頼すること」「依頼されること」がある場合には、似た構図の問題を抱えがちだと思いますので、非IT職種の方も要求の言語化の技術を学んでいただいて損をすることはないかと思います。というか、実際非IT業種の方でもよっぽどこの技術が磨かれている方（自分の経験上オペレーション業務設計の得意な方とかでめっちゃくちゃ凄腕の方と会ったりすることがありました）いらっしゃったりするので、普通に業務に活きることがあるのではないかと思っております。
ちなみにこの業務どうすればいいかなーと途方に暮れた時も、自分に対して要求を言語化して依頼してみると、見え方が変わって一気に解決することすらあったり、それをLLMに入れるだけで解決することがあったりします。
参考資料
三菱電機ソフトウェアさんの「要求・要件仕様を効率的、高品質に作成する方法」
https://www.mesw.co.jp/business/report/pdf/mss_29_03.pdf
今回の記事に図や例を引用させていただきました。
「要求を仕様化する技術・表現する技術 -仕様が書けていますか?」
この分野の名著。若手の頃何度も読み返させていただきました。
今回の内容をさらに深めていきたい方にはおすすめの本です。
Amazon
この記事が気に入ったらサポートをしてみませんか？