確かにそれも「根拠」と言えるけど、今欲しい情報はそれじゃないんだ！

要求工学、要求開発、要求管理、ビジネス・アナリシス、等々、こういった領域の国際標準や様々なフレームワークなどの中で、「要求」と伴にその「根拠(あるいは理由)」を示す(引き出す、書き残す、管理する)ことの重要性やメリットが謳われています。

5W1Hのフレームワークで言えば、HowやWhatだけではなく、Whyを示すことの重要性が語られていることに相当すると思います。
実際、様々な場面で根拠情報は活用されることがあり、有用であるのは間違いない、と経験的にも感じます。
現場で使われている要求を記載する文書の定型フォームに「根拠(あるいは理由)」の記載欄が設けられていたり、要求管理システムの各レコードに「根拠」を記録する属性が設けられていたりしているのもよく見ます。

ところが、そのような「根拠」情報を参照してみると、
「いやいや、確かにそれも根拠と言えるかもしれないが、今欲しいのはそういう情報ではなくて、、、」
ということもよく起こります。
担当者任せにすると、かなりばらついた内容が記入される結果となり、活用したい場面で期待が裏切られることも少なくありません。
そこでどういう情報を示すべきなのかの指針をもっと明確にしておきたい、と考えるようになるわけです。

ところが、自分が書き残す時にはいろいろな活用場面を考えながら、なんとなく何通りかあると気付いている根拠を並べているものの、それをちゃんと人に説明できる程には自分で整理できていないことに気が付きます。そこで国際標準やフレームワークをいろいろ調べてみたりもしましたが、この問題を解決するような気の利いた説明や表現は見つかりませんでした。
名の知れたコンサルタントのご著書等を拝読しても、はっきりしません。良い事例と悪い事例がいくつも示されていたりするのですが、結局その区別の基準がどこにあるのか、はっきりした指針としては示されていませんでした。

実は私もコンサルタントの端くれとしての仕事を受けることもあるので、これは少し困ったことでした。単に主観に基づいているだけだと誤解されてしまうと、説得力が無くなり、実行してもらえなくなってしまうからです。

ところが、この問題意識を持ち続けていたところ、ある時ある事に気付き、それからとても見通しが良くなるようになりました。指針としての上手い説明が見つかったのです。本稿ではそれを紹介することにします。

根拠には４種類ある、と考えてみる

根拠として示されることは、大きく以下の４つの種類のに分けることができます。

(1) 「要求」の出処（情報源）
(2) 「要求」するきっかけとなった事象や明らかになった事実
(3) 「要求」する理由(考え方)
(4) 「要求」が実現した際に達成されると想定される状態や目標

各種類の説明は次節に回します。
まず確認したいことは、現場では、記載する人によって、あるいはその時々によって、これら4種類の情報のうちのどれか(場合によっては複数種類)が示される事態となってしまっている、ということです。
これがばらつきの原因になっていると考えられます。

さて、それではこの4種類があるとして、結局それらのうちのどれが欲しい情報なのでしょうか？
それがわかれば、もっと確実に種類が限定できる表現をして、「余計なものは要らないからこれだけ示せ」と説明したいところです。

しかし、少し考えてみただけでも、欲しい情報の種類は場面によって異なるだろう、と気付きます。
なので、「根拠」の情報は有用だ、と実感することが多い一方で、「今欲しいのはその情報じゃない！」ということも起こってしまうのでしょう。

そうならないようにするためには、この4種類の情報を全部集めておきたくなります。
そこで記入欄を4つに分け、それぞれを記入してもらうようにすれば良いように思います。

実際、例えば『JIS X0166：2014(ISO/IEC/IEEE 29148：2011)システム及びソフトウェア技術−ライフサイクルプロセス−要求エンジニアリング』においても、その『5.2.8 要求事項の属性』の中で、「情報源」と「根本的理由（rationale）」は別の属性として示されています。

しかし、結局のところ中身の区別が出来ない人に、記入欄だけ細かく分けて用意しても、見当はずれの内容が示されたり、コピペで同じ情報が記入されたり、といった具合で、実際にはこれは期待したような解決策にはなりません。
それどころか、記入する際の敷居を高くしてしまいます。
今記入しようとしている情報を、どの記入欄に記載するべきなのか判断しなければならなくなり、それが面倒で記入をサボってしまったり、迷っているうちに記入すべきことを忘れてしまったり、そんなことになってしまっては元も子もなくなってしまいます。

ですから、最初はとにかく「根拠」欄にそれらしいことは何でも放り込むように記入してもらう、やはりそれが良い方法なのだろう、と思います。
そしてその質を評価する段階で、4種類に区別した場合、何が揃っていて、どれが抜け落ちているか、見分けられるようになっていると良いと思います。

4種類がどういう関係にあるかを理解することで、区別できるようになる

少し慣れれば、この4種類は簡単に判別できるようになります。その理解を簡単にする説明を今から示します。ただ、実際にはどこに分類すべきか意見が分かれるようなものも出てきます。
そういう時に思い出して欲しいのですが、分類すること自体が目的なわけではないということです。
後工程で困らない運用にしておけば良いわけです。
それでは、4種類をもう一度以下に示します。

(1) 「要求」の出処（情報源）
(2) 「要求」するきっかけとなった事象や明らかになった事実
(3) 「要求」する理由(考え方)
(4) 「要求」が実現した際に達成されると想定される状態や目標

まず、他の種類に比べて(1)の「情報源」は、特に難しくないと思います。既にここまでこの記事を読んで頂いており、「根拠」に挙げられる情報の種類の一つにそれがあり、分類の一つにしておいた方が良さそうだ、と気付けば、もうその判別はできるようになっていると思います。
「どこどこ部門からの要求である」とか、「誰々が欲しいと言っていた」というのは「事実」の記録でもありますが、「情報源」の方に分類しておいた方が良さそうだ、とほとんどの場合は合意してもらえると思います。法規制や国際標準などについては意見が分かれるかもしれません。

さて、残る3つの種類の区別を考えてみましょう。
(2)と(4)は、それぞれその内容だけが示されれば割と簡単に区別がつくと思います。
しかし、大抵は一つの文の中で(3)と一緒に示されたりします。しかも一部の情報が欠落した(省略された)中途半端な形で示されることが多いので、もやっとした感じになっていることが多いです。
何か不十分な感じがするが、「それでは根拠になっていない！」とは言えないので、ほとんどそのまま放置されます。
本来、(3)の内容として期待されるのは、例えば「(2)を解決すべき問題であると捉えており、「要求」が実現することでその問題が解決するのだ」という関係性や考え方を明らかにするような情報になります。
少しわかり難くなってきてしまったかもしれませんが、時間軸に並べてみるだけで、だいぶ見通しが良くなります。以下の図のような関係をイメージできるようにしておくと、簡単に区別ができるようになると思います。

実際、この図を示した後の方が、自分の記載した情報の種類をすぐに正しく判別できる人が増えるようです。（十分なサンプル数で調べたわけではありませんが。）
この図では、何らかの機能システムが開発され、それが機能することで要求が実現されるものとしています。この機能システムは技術システムでも、何らかのスキルや役割などをもった人あるいは組織等でも良いと思います。

さて、ここでちょっと実例で確認してみましょう。
USDMの提唱者である清水吉男氏の著書『[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?』(技術評論社，2010) に記載されている事例をここで取り上げてみることにします。

この著書の中で、「要求」の一つとして「インクの残量を調べて、印刷できない可能性があれば印刷を依頼した人のPCに知らせてほしい 」というものが示されており、さらにその要求に関する、様々なことが記載されています。

たとえば、この要求がどんな状況のなかで出てきたのかを考えて、依頼者との会話（ヒアリング）のなかでそれとなく探ってみます。その結果、この人は、以前に200ページの文書を印刷した際に、時間がかかるのでしばらくコーヒーを飲んで休憩したあとに戻ってきたら、半分ぐらいのところか らインク切れによって文字がかすれて見えない、という経験をしていてそれがこの要求を発した理由だったことがわかります。
こうして「要求」を追及することで、 この要求で解決したいこと（状況）が明らかになる のです。
ヒアリングする際に、この要求が有効とする背景を考えてみて、
「皆で使い合いしている状況であれば、この機能はありがたいですね」 と誘ってみることで、依頼者の本音を引き出すこともできます。
その結果、
〚 印刷中に文字がかすれたくないから〛
というのが理由だとわかったりします。

書籍の引用部分から、(2)～(4)に相当する情報を抽出してみましょう。
(2)に相応しい部分は以下の部分です。

「以前に200ページの文書を印刷した際に、時間がかかるのでしばらくコーヒーを飲んで休憩したあとに戻ってきたら、半分ぐらいのところか らインク切れによって文字がかすれて見えない、という経験をした」

次に、(3)に相応しい部分を探してみましょう。以下の部分で良いと思います。

〚 印刷中に文字がかすれたくないから〛

この表現では(2)の内容が「印刷中に文字がかすれた」と要約されていると思います。そしてそれを失敗や問題と認識しており、その過去の失敗を繰り返したくないので「要求」するという考え方の理由を示しています。
ここでちょっと余談ですが、これはインタビューで聞き取った内容そのものの方には含まれていませんね。
聞いた側が表出化されなかった情報を忖度し、補って表現したものと思われます。

さて、最後に(4)に相応しい部分を探してみましょう。
「 この要求で解決したいこと（状況）が明らかになる のです。」と記載されていますが、解決された状況がどのような状況なのか、どこにも明示はされていません。
仕方ありません。ちょっと想像してみることにしましょう。
過去の失敗を繰り返したくないわけですから、「印刷中に文字がかすれない状況」でしょうか？
インク切れたら無理ですね。「インクが切れたら、文字がかすれた無駄な印刷が起こらない状況」でしょうか？
結局、ここに示された情報だけからでははっきりせず、この情報が欠落しているということがわかります。
ここで、「要求」が「インクの残量を調べて、印刷できない可能性があれば印刷を依頼した人のPCに知らせてほしい 」なんだから、(4)は「インクの残量を調べて、印刷できない可能性があれば印刷を依頼した人のPCに知らせが来る状態」である、と同語反復的な理解をしていると、後で痛い目をみたりするわけです。

さて、(4)の情報が欠落している、あるいははっきりしないことは、(2)や(3)の情報があってこそ、そしてこれらの種類の違いの区別がつくからこそ気が付きます。
「要求」以外の情報が無かったら、多くの人が簡単に同語反復的理解に陥ってしまうことが想像されます。
ここで取り上げた例は、まだ「要求」だけの情報からでも、いろいろと経験から想像し、補うことができそうに思います。しかし、経験が浅い領域であったり、抽象度や粒度によってはさっぱり想像が及ばないということもいくらでもありそうです。そう考えるとちゃんと根拠を示しておくことは本当に大事なことであると再認識させられます。

区別ができるようになったら
（あれっ、何のために区別するのでしたっけ？）

ここで示した種類ですが、それを何のために区別したいのかといえば、それは必要なものを揃えたいからでした。揃っていないと、「今欲しいのはその情報じゃない！」ということになる可能性が出てくるからです。

ただ、いつでもこの4種類の情報が全て揃っていることが必要、というわけでもないです。
特に要求開発の期間の前半と後半で、必要性の度合いが変わってきます。

前半は目標や目的の情報があるよりも、事実や原因、問題と認識していることの情報が揃っていることが望ましいと思います。
なぜなら、問題が示されていると、例えば技術者は保有している技術的知見等から、様々なソリューションの形態を考案し、提案することができます。
一方、目標や目的の情報しかないと、そこがゴールとして設定されてしまい、そこに示した以上のものが出てくることがほとんど無くなってしまいます。
もっとも、企画段階で技術者に限らず様々な知見を持ったメンバーで良く練られたゴールが設定されている場合は、この話は当てはまらないかもしれません。
ただ、主機能から外れる細部に至るまで、予め練りに練られている、ということも少ないと思うので、一般的にはこのように心得ておく方が良いと思います。
私個人の経験としても、「なんだ、その問題を解決したいのだったら、もっとエレガントな方法が提案できたのに！」と後からわかったケースは多数ありましたので。
先に事例を引用した清水吉男氏の著書にも、以下のような記載があります。

「理由のほうを優先して要求を変えることを提案してみてください。」
「要求に理由をセットすることで依頼者の思いを的確に把握 でき、実現性とのバランスから適切な方向に誘導することで、あとから仕様が変更される可能性を潰すことができるのです。また、理由を考えることで、この要求の変化の方向が見えることがあり、予想される変化に耐えられるように設計のなかで配慮することもできます。」

先程からの事例でもそうです。「要求」通りに「インク残量が少ないことを知らせ」ても、離席してしまったりして気付かれなかったら同じ失敗は繰り返されます。元々の問題が示されていれば、他に「要求」した方が良いことがあるはずだ、と提案ができます。

さて次に、要求開発の後半になった時のことを考えてみましょう。
今度は目標や目的の情報が揃っていることが重要になってきます。それは品質要求を考えたり、より良いテストを設計するのに欠かせない情報になるからです。
先の事例で、結局、「要求」通りに「インクの残量を調べて、印刷できない可能性があれば印刷を依頼した人のPCに知らせる 」機能だけが忠実に実装されたとしてみましょう。
そのとき根拠に「 印刷中に文字がかすれたくないから」と示されている場合と、「インクが切れたら、文字がかすれた無駄な印刷が起こらない状況を達成したい」と示されている場合とでは、設計されるテストの内容が変わってしまう可能性が高いと思います。

この事例は、経験から想像し易い領域だと思います。それでも差が出そうです。担当者の経験が浅い領域であったり、抽象度や粒度によっては大きな差が出るものと想像します。
遅くとも、テスト設計の前までには目標や目的の情報を揃えておくべきだ、と気付きます。

ところで、「そんなことを言われたって、インタビューの機会はめったに得られないのだから、最初から全部聞き出すつもりで臨まないとどうにもならないよ！」などということもあるかもしれません。
確かに、そのプロジェクトのおかれた状況によって、いろいろと制限も出てきてしまうのは仕方ありません。
いずれにしろ、作戦を立てて臨みたいものだ、と思います。

おわりに

この話、「なんとなく分かったような気もするけど、もっと有効な違う流儀があるような気がする」と思われた方も多いかもしれません。
実は私自身、そう考えたので、いろいろ探したのです。かなり近い話をしているものはいくつも見つかりました。しかし、ズバリこの話、というものは見付けられていません。
「いやいやそんなことはない。同じような説明が○○にも書いてあるではないか。」と思う方もいるかもしれません。しかし、そう思う方は、少し違う領域の話なのに何で「同じような説明」になるのか、それも良く分かっている方なのだと思います。
そういった「同じような説明」との対応関係や比較はいくつかしてあります。それについてはまた別途書いてみたいと思っています。

あまり他の知識を使わなくても、この説明だけで理解して実践できるようなことを今回は狙いました。
狙い通りになっているはずなのですが、、、