モノ作りの成否は要求開発にかかっている
要求開発は面白くないものと思われる人が多いように感じられますが、製品開発における最上流で市場要求を実現すべく、さまざまなアイデアを製品に織り込めるとてもチャレンジャブルでクリエイティブなワークができる機会だと思います。要求開発は「システムをどのように設計したら期待される効果を出せるだろうか？」とか「このシステムにはどんな改善ができるかだろうか？」など、技術者の頭の中でさまざまなアイデアを構想して思考の羽を思う存分羽ばたかせられる段階であると思うからである。そして、技術者の頭の中のイメージをいかにして現実世界へとブレイクダウンいくかまでが要求開発の範囲なのです。とても自由度が高くワクワクしませんか？
要求開発は面白くない？
それでは、そんなクリエイティブな活動であるはずの要求開発が、なぜ面白くないと思われてしまうのでしょうか？
その理由の１つに要求開発は文書化だけと思われていることがあります。
要求仕様に関する文書の整理整頓だけと思われているので、めんどくさい、手間がかかる、時間がかかるとネガティブな印象を持ってしますのです。そして、ソフトを作る側が要求仕様書を忖度してうまいことソフトを作ってくれないかなぁ？なんて思ってしまうのでしょう。これは要求開発の根幹を成すクリエイティブな部分をやれていないがために起こってしまう残念な誤解なのです。要求開発は本来、クリエイティブでエキサイティングな技術者にとってとても面白い創作活動になるからです。
また、不十分な要求仕様書であっても、技術力の高いサプライヤや、継続的に取引のあるサプライヤの担当者ならば、要求仕様書の不十分な行間を読んでうまく作ってくれることもあります。しかし、それで本当によいのでしょうか？もしそれでよいとしてしまうと、製品品質はサプライヤの担当者依存になってしまいます。技術力の高い担当者に当たれば良い製品が作られるかもしれませんが、ハズレを引いてしまうと品質がガタガタなんてこともありますし、効率もかなり悪くなるかもしれません。これは決してサプライヤ側の問題だけとは言い切れません。元々の要求仕様書に不備や不明確なところが多いために品質不良や何度も要求仕様の内容確認をするはめになったり、作り直しになることによって工数を増加させてしまっている場合もあるからです。
要求開発が嫌いという人の中には、実際にものを作る方を好む傾向があります。作っていく過程で直せば良いと思っていることが結構あります。トライ＆エラー的にやることは経験を積むという観点では価値があるかもしれません。しかし、安易にトライ＆エラーをすればよいと思っている人は、延々と終わらないトライ＆エラーを続けることになる可能性もあります。もちろん経験豊富な匠ならば要求開発プロセスなどのステップを踏まなくても素晴らしい成果物を一発で生み出すことができるかもしれませんが、昨今のシステム要求の大規模化と複雑化の波に、さすがの巨匠であっても限界になってきているように感じます。探索的な研究においてはトライ＆エラーによって新たな知見を見つけることに価値があると思います。そしてその知見を要求開発を通して要求と仕様とを抜け漏れなく確定していければ理想的だと思います。
要求仕様って何？
技術者の頭の中のアイデアを実際のモノへと実現する過程に要求と仕様があります。それらをいかに発案者である技術者のイメージを要求と仕様という形にしていくかが極めて重要なことです。この過程で抜け漏れやコンフリクトを発生させていると実際のモノが作れなかったり、とんでもない問題を内在させたままリリースされてしまうからです。
ここで要求と仕様を明確にしておきましょう。
要求
システムに対してユーザが抱く希望や要望
システムによって実現してほしいこと
仕様
要求を実現するために定義されたシステムの具体的な動きや制限
要求がないと
要求が定義されていないでタイミングチャートなどの制御に関する細かい仕様しかない場合には、その仕様の示す目的が不明なため、仕様自体の妥当性を判断することができません。要するに本当に作りたいものかを仕様からだけでは判断することができないということです。仕様として記述されたシステムの振る舞いで作って欲しいものなのか判断できませんが、そのように仕様として記述されていると、サプライヤとしてはその通りに作らなければなりません。作ってみて結果的に実物で試した時にやっぱりダメでしたとなると、当たり前ですがやり直しになります。最終的な製品の価値が同じならば手戻りを生じる分だけコストが増しますし、リリースまでの時間も多くなってしまい機会損失が大きくなるのです。
仕様がないと
要求文書に仕様の記載がないと、仕様の定義が設計工程まで持ち越されてしまうことになります。早期の仕様確認ができず仕様の抜け漏れが設計工程で発生してしまうことにあります。
曖昧な要求や仕様は、そのまま下流工程へ受け渡されてしまうと、開発終盤での問題を引き起こす可能性があります。また、要求漏れや要求を誤って解釈されたものが作られてしまうこともあります。
間違ったモノが正しく作られてしまう
昨今、モデルベース開発による開発改革が行われていますが、要求定義工程の問題はモデルベース開発だけでは解決しません。モデルベース開発によって正しくモノが作られたとしても本当のゴールに辿り着けない場合があります。それは、期待されている要求とその仕様が適切な情報としてまとめられていないと、その情報（不適切な要求仕様情報）に基づいて期待されたモノと違ったモノが正しく作られてしまうからです。要するに開発へのインプットである要求仕様が肝ということなのです。
要求仕様を好き勝手に書かれると
よく見る残念な要求仕様に「要求」「仕様」「設計」「補足説明」がミックスされているものがあります。思いのまま書かれているため、要求のようなものが書かれていると思ったら、仕様が書かれていたり、これは設計か？と思うようなフローチャートや状態遷移図が書かれていたります。「補足」と書かれているのに、そこに重要な数値が記載れていたなんてこともあったりします。「要求」「仕様」「補足説明」を明確に分けて、それぞれに適した内容を書くようにしなければ、後工程の設計に混乱させてしまいます。ましてや要求仕様に「設計」らしきことを書くのは以ての外です。
特許的観点と要求仕様
知的財産（特許）の観点から見ると、既存機能の組み合わせでは基本的には特許にはなりません。例えば、スマホ＋カメラではそれぞれの機能を同じパッケージにしたに過ぎませんから特許として認められません。特許にするためには進歩性が必要だからです。この特許要件は要求開発においても重要な要素となります。
要求機能の進歩性は何か？を明確にしなければ製品としての価値、セールスポイントが存在しないことになるからです。要求開発によって、機能の新規性、進歩性を明らかにすることは、特許によって自身の技術を保護することや、これから作る製品のセールスポイントを明らかにすることにつながります。また、他社の特許に抵触していないかを確認することにもなります。他社の特許に抵触してしまうようなことになったら大変なことになります。金銭的な補償ももちろんですが、改善対応、企業の信用失墜にもなりかねません。要求開発の段階において、自社製品のセールスポイントとして特許とすべきところや、他社の特許に抵触しないように十分に検討とチェックをしていかなければならないのです。
要求仕様の大切さ
ソフトウェアや制御やプラントなどのモデルをサプライヤに依頼する側と、受託するサプライヤ側のそれぞれの思うことの例として表１に記載したようなことが挙げられます。
依頼する側としては「作る側でうまくこっちの思いを忖度していい感じのモノを作ってくれないかなぁ」とか、「まぁサプライヤさんに任せておけば大丈夫だろう。気に入らなかったら、その時にダメ出しすればいいや」とか思っている人もいるかもしれません。
一方で依頼を受ける側としては「出てきた仕様のとおりに作ればいいでしょ」とドライに考えるサプライヤさんもいるでしょう。「情報が少ないけどどうしよう、、、、聞きたいけどウザがられるし、、、想像で作ってダメだったら直せばいいかな」などとサプライヤ側の担当者が勝手に行間を想像して作ってしまうこともあるかもしれません。
ですが、依頼する側、受ける側の共通な思いとしては「気づいていないところを無くして想定外の失敗を極力減らしたい」「依頼側（受託側）との認識の違いを減らして、やり直しを減らしたい」というのがあるはずです。
要するに、依頼する側と依頼を受ける側の認識が一致し、作るべきものの情報が完全であることが望ましいということです。情報が不足していると、依頼を受けた側は、わからないことがあったら都度聞くか、勝手に想像して作るしかありません。勝手に作った場合、結果的に望ましいものなら褒められるでしょうが、間違っているとクレームとなって怒られてしまいます。時間もコストもかかるので依頼側も受託側も共に嬉しくない状況になるのです。正解な行動としはわからないことがあれば都度聞くことですが、問い合わせのために工数は増えてしまいますし、開発の遅れや当初見積もった開発費をオーバーしてしまうかもしれません。受託側としては追加費用として要求できたらよいですが、なかなかそんなことはできません。そうなると受託側のコストが多くなって場合によっては赤字になってしまいます。
要求開発はこのような実際の開発に入ってから右往左往してしまい、コストと工数を増加させてしまう要因を回避するための手段、フロントローディングの手法なのです。
必ず要求仕様分析は必要か？
探索的な研究とかフィジビリティスタディの段階では必ずしもカッチリした要求開発はいらないかもしれません。ただし、部分的に活用してアイデアをブラッシュアップしたり、不足部分を見つけたりすることに活用できるとも言えます。
また、ソフトを作るだけなら仕様だけでもよいかもしれませんし、優秀な設計者なら面倒なプロセスだと思ってしまうかもしれません。頭の中にすべてがあり、自分で何もかもできてしまうからです。全員がそんな優秀な人ならよいかもしれませんが、誰かに依頼するとなると情報伝達の過程で抜け漏れを生じてしまい、せっかくの優秀な人の素晴らしいアイデアもうまく実現されないかもしれません。
要求が明確に記載してあれば、仕様の適切さをチェックすることに利用できます。また、要求の理由（根拠）があれば要求自体を精査することもできます。仕様だけだと、その仕様を満たすものを作るしかありません。しかし、要求が記載されていれば、その仕様が本当に要求を満たすものか検討することができます。そして、その要求の理由（根拠）が記載されていれば、その要求が出てきた理由、誰が何のためにどうして必要なのかを理解することができます。モノ（例えばソフトウェア）を作ったものの、あまり良い評判がないということは、このあたりの要求の導出や、要求の根拠が間違っていたからかもしれませんね。
また、要求開発をしっかりとできるようになると依頼側にも受託側にも良いことがあります。OEMなどの依頼側であればサプライヤの技術力に依存しなくできますし、コストの安いサプライヤに出せることになります。一方で、サプライヤであれば、開発段階になって初期の見積よりも開発コストが増えたり、実際の開発段階で工数爆発を起こしてしまうことを抑止できますし、OEMの信頼を得られ、高い単価で依頼を受けられるようになるかもしれませんし、多くのOEMから依頼が殺到するかもしれません。
以下のYouTubeで要求開発の大切さについて紹介していますのでご関心がある方はぜひご視聴ください。
要求開発をやってみよう！
例えば、図1 に示す内容から実際にものを作ることはできでしょうか？
たぶん作ることはできると思いますが、作る人によってバラエティに富んだ最終成果物ができることでしょう。しかし、それは依頼側にとって望んだ製品だったのでしょうか？運よく依頼側が期待するモノになっているかもしれませんし、思っていたモノとは違うモノになっているかもしれません。この図1からは、何となく作って欲しいだろうもののイメージは分かりますが、期待されている要求や、抑えなければならない仕様値がまったくわかりません。そのため、赤い球を追いかけて動く車を作られるでしょうが、動き方や精度などが規定されていないので、出来上がるモノの性能は作る人によって様々なモノになる可能性があるのです。
作って欲しいモノが期待するモノになってもらうために、期待する要求と抑えるべき仕様を抜け漏れやコンフリクトを少なく、できればゼロにするために、要求開発プロセスを踏んでいくことになります。世の中には様々な要求開発手法がありますが、ここでは、JMAAB(Japan MBD Automotive Advisory Board)の要求開発WSにて作り上げた要求開発手法のについて紹介します。
要求開発の６ステップ
JMAABの要求開発WSにて作り上げた要求開発手法の次の６ステップからなります。
関心事抽出
スコープ定義
要求分析
機能要求定義
非機能要求定義
要求仕様定義
対象となるシステムのステークホルダの関心事を抽出するところから始まり、システムを取り巻く環境、センサやアクチュエータなどを定義するスコープ定義、そしてステークホルダの関心事やスコープ定義情報を元にして、システムの要求を分析していきます。その要求から機能要求と非機能要求を定義し、最終的に要求からシステムが実現すべき仕様へと導いていきます。このプロセスはJMAABの要求開発WSで作り上げた「実践！今すぐ使える要求開発」に詳しく説明されています。
ここでは「実践！今すぐ使える要求開発」のプロセスに基づいて、図１のシステムの要求開発の６ステップに沿って要求仕様書まで作ってみたいと思います。
ここで挙げたステップは一例です。すべてをこの通りに使ってもよいでしょうし、自分が不足しているなと思うところだけ使ってもよいと思います。これらの手法をベースに自分流にアレンジしてもよいでしょう。要求や仕様の抜け漏れやコンフリクトを少なく、できればゼロを目指すために要求開発のさまざまな手法があります。先人たちが編み出した手法をすべて忠実に使うことだけが正解だとは私は思いません。あなたの現状に合わせて適宜つまみ食いをして自分流に変えていってよいのです。要は要求仕様が抜け漏れなくコンフリクトがなければよいのですから。
とは言え、まずはこの６ステップを使って事例のシステムの要求開発をしてみましょう。これから１つのステップずつ記事を書いていきますので、興味のある方はそちらの記事を参照してください。