こんにちは、システム開発一部長の上川です。
先日安原がこんな記事を書いていましたが、社内でこの記事の原稿が公開されたときに、Slackのengineer_blogチャンネルがひと盛り上がりしました。
盛り上がりの細かい話は割愛しますが、みなさん不要なドキュメントは作りたくない、ということ自体には完全同意ではあるものの、「何が必要で何が不要なのか」というところまで突き詰めると、人それぞれ意見が違ったりします。
また、必要不要の枠から少しズレるものとして、障害起因の再発防止策として作らざるを得なくなるドキュメント（これは、理屈上は必要ということなんですが）とかもあったりするので、いろいろ難しいなという感じです。
この辺をさらに突っ込んでいくと、日本の生産性が低いのは無駄な手続きとか無駄な資料作成が多いからだ、、といったような最近よく耳にする議論につながっていくのだと思いますが、今回はこの話がメインではないのでこれ以上は深追いしません。
要件定義書は、どこまで具体的に書くべきか
ということで、今回はドキュメントの話ではありますが、その中でも要件定義書について自分がなんとなくモヤっとしている部分について書いてみたいと思います。
マネックスの基幹システムは今のところウォーターフォールで開発を行っていますが、要件定義書を書いていてよく直面する状況として、「章立て単位で記載の粒度が異なる」というものがあります。
システム化要求を出すユーザー側に、要件定義書に記載すべき要求が網羅的にあることは現実的にはあり得ないので、ユーザー側に強い要求がある部分は要件としても詳細まで踏み込んだものになり、逆にこだわりのない部分は内容が薄くなる、というのは少し考えてみれば当然ですね。
要求にこだわりがないものを決めつけてしまっていいの？
さて、これが「モヤっと」の本題です。
例えば、新しい車を作りたい！という目的に対して、こんな要求があったとします。
（今回は概念的な話をしたいので、敢えてシステム開発としての具体的な要求や各工程における具体的な成果物名（業務フロー図とか、画面設計とか、帳票設計とか、外部IF一覧とか、、、）を使わないようにします）
- 形はセダンタイプ
- 運転席は右側
- 定員は5人乗り
- 山道をグイグイ走っていけるパワーが欲しい
- 駆動形式（2WDか4WDか）は問わない
これらを要件定義書にそのまま落としていくと、上の3つと下の2つでは具体性のレベル感が違うことになり、要件定義の時点ではこれでも先に進めることはできますが、設計工程から先に進むには、曖昧な部分を具体化していく必要があります。
- 山道をグイグイ走るために必要なパワーは具体的に何馬力なのか
- 2WD、4WDどちらで作るのか
といったところですね。
ここで例えば、基本設計をする段階で、「パワーは200馬力」とし駆動形式は「4WD」にすることにしよう、と決めたとします。
そして、これらを考えている時に、トランスミッションを決めていなかったことに気づき、その場でユーザーに確認したら、「こだわりはないので、とりあえず今回はATにする」ということになったとしましょう。
さて、基本設計工程で出てきたこれらの内容は、どこまで要件定義書に記載すべきでしょうか。
そして、これは変更管理の対象になるのでしょうか。
考え方その１：要件定義書には曖昧なことが書かれていてはいけない
この考え方ですと、そもそも「こだわらない」とか「問わない」という状態で要件定義を終わらせてしまったのがいけない、ということになり、不足に気づいた時点で要件定義書をあるべき姿にする必要があるので、
- 基本設計で決めたこと（「200馬力」「4WD」「AT」）を要件定義書に反映させる
- すでに工程が進んでしまっているので、全て変更管理として扱う
ということになります。
考え方その２：要件定義書に書かれていないことが基本設計に書かれていてはいけない
これは、要件定義の時点での曖昧な記載は許容するが、要件定義書と基本設計がマッピングできないものがあってはいけないので、
- 基本設計で初めて気づいた「トランスミッションはAT」の内容を要件定義書に反映させる
- すでに工程が進んでしまっているので、「トランスミッションはAT」について変更管理として扱う
となります。
考え方その３：要件定義書はユーザーの要求のうちシステム化するものを記載したものなので、ユーザー要求のありのままが記載されているべきである
この考え方は、ユーザーにこだわりがないものは要件定義書上は「こだわりがない」という記載のままであるべきで、システム化の都合で具体的に決めなければいけなかったことを決めた結果が基本設計に書かれるべきなので、
- 基本設計で決めたこと（「200馬力」「4WD」「AT」）を要件定義書に反映はしない
- 基本設計工程で決めるべきことを決めただけなので、変更管理とはならない
となります。
さて、みなさんの考え方はどれに近いでしょうか？
自分は、小見出しで「決めつけてしまっていいの？」と書いているくらいなので、その３がよいのではないか、と考えています。
変更管理が、いつの間にかユーザー要求を変えてしまう
開発者目線であったり、ウォーターフォールの開発手法に忠実であろうとすればするほど、「考え方その１」に近づいていくのではないかと思います。
特に、開発を請け負うSIerの立場からすると、変更コストが肥大化する下流工程での変更可能性を小さくしておきたいので、要件定義書をできるだけ具体的に書くことに腐心します。
上の例では、基本設計工程で具体化していましたが、要件定義の段階で、
「パワーは200馬力でよいですか？」
「4WDでよいですか？」
「トランスミッションの要求がないですが、ATでよいですか？」
というQAを上げたりして、決めていくことも多々ありますし、むしろそうすべきというのが一般的な考え方ですね。
しかし、こういうプロセスを経てしまうと、本来のユーザー要件が
- 形はセダンタイプ
- 運転席は右側
- 定員は5人乗り
- 山道をグイグイ走っていけるパワーが欲しい
- 駆動形式（2WDか4WDか）は問わない
であったはずなのに、いつの間にか
- 形はセダンタイプ
- 運転席は右側
- 定員は5人乗り
- パワーは200馬力
- 駆動形式は4WD
- トランスミッションはAT
に変わってしまうのです。
ウォーターフォールは、伝言ゲームのような開発手法であり、場合によっては工程ごとに担当する開発者（SIer）が変わるような時もあり、工程ごとのインプットは「前工程のアウトプット」になるわけですから、ユーザーとどういうやり取りがあって要件定義書が完成したのか、を後続の開発者が知らないケースが多々あります。
そんな時、例えば実装工程でどうしても4WDにすると不都合があることが発覚したとします。でも要件定義書には「駆動形式は4WD」とあるので、無理をして4WDで作ってしまいました、ということが容易に起き得ます。
結果、開発期間が延びてしまったり、完成前のテストで重大な不具合が発生する、となってしまったら不幸の極みです。
要件定義書に戻ったら「駆動形式は問わない」と書いてあれば、不都合が発覚した段階で「2WDにした方がリスクが少ないから変更してもいいか？」という選択肢が出てきやすいのではないかと思うのです。
要件定義書は、ユーザーの想いが正確に書かれていた方がいいのではないか
これが、上川の意見です。
たぶん、要件定義書という成果物をどの立場から見るか、どう利用することを想定するか、によって答えは違うのではないかと思いますが、要件定義書は後の工程で「ユーザーはどうしたかったんだっけ？」という疑問が出てきたときに振り返ってそれを確認できる成果物、であるべきかなと。
ですので、ユーザーにこだわりがないものについては「こだわりがない」と書いてあってよいし、例えば「ドアをロックできる必要はあるが、キーの形状は問わない」という書き方でもよいと思っています。
もう少しシステム的に例えてみると、「電文を暗号化する必要はあるが、暗号化の手段は問わない」といった感じでしょうか。
基本設計でVPNにしようと決めて進んでいったが、不都合があって例えばSSLの方がよいのではないかとなった時、要件定義書に「電文の暗号化はVPNとする」と書かれているのと「電文を暗号化する必要はあるが、暗号化の手段は問わない」と書かれているのでは、上の駆動形式の例にあるように、アクションが変わってくる可能性がありますよね。
ちなみに、実は上の方で書いた「考え方その２」については、この論点からすると実施してもしなくても趣旨からずれることはないのですが、変更管理の手続きをするコスト分だけ無駄かなと思うので、自分は「考え方その３派」です。
基本設計のインプットが要件定義書である、という原理原則に忠実にいくなら、実施すべきなのですが、実効性はそんなに変わらないですよね。
但し、もしユーザーの回答が「考えていなかったが、実はATにして欲しかった！」ということであった場合は、ちゃんと反映した方がよいかもしれません。
さて、長々と書いた割に、ずいぶんまどろっこしい説明になってしまったな、という気もしていますが、みなさんの環境に合った要件定義書の記載レベルを考えるにあたっての一つの気づきになれば幸いです。
最初の方で、
「システム化要求を出すユーザー側に、要件定義書に記載すべき要求が網羅的にあることは現実的にはあり得ない」
と書きましたが、これに異議がある人はあまりいないのではないかと思います。
つまり、後から「ここまで作ってみたら、こっちの方がよいと思う」ということは十分あり得るわけです。
となると、工程が逆戻りしない前提のウォーターフォールという開発手法は、どちらかと言うと開発者に都合がよいもので、あまりユーザーフレンドリーな手法ではない≒ユーザー満足度が高いものが作れる手法ではないのかもしれないですね。
そう考えると、最終的には、べき論ではなく、みなさんそれぞれの会社で一番有益に使えるものであること、が重要なのだろうな、と思う次第です。
