　要求の開発・管理は、ソフトウェア開発において非常に重要なフェイズ／作業と考えられています。しかし現実には、開発期間などの問題で、“要求が曖昧（あいまい）なのを承知のうえで、開発工程に取り掛かってしまう”なんてこともあるのではないでしょうか。要求の明確化が重要だと認識していながら、まだまだ実際の組み込みソフトウェア開発では、十分に実施されていないのが現状のようです。第2回勉強会の参加者の皆さんも、混沌とした状況の中で苦労しながら、要求の開発・管理を実施されているのだと感じました。

　今回は、そのような開発状況の中で、「どのように要求を明確にし、またそれをどのように管理するのか」を深掘りしてみました。なお、勉強会（本稿）では、“要求”と“要件”を区別せずに議論を行いました。

要求はどこから発生するのか？

　要求を開発するために、まず明確にしなければならないことは、要求の出所をしっかりと把握することです。要求のモレを防ぐためには、ソフトウェア開発に対する要求提供者を明確にし、要求提供者のソフトウェア開発に対する目的・目標や、要求提供者の依存関係などを明確にしておく必要があります。そのことが、定義した要求の整合、合意を取るために非常に重要になってきます。

　要求の出所として、以下のような意見が挙がりました。

顧客、ユーザー、（親会社）
自社のハードウェア部門、企画部門、営業部門、評価部門
学会や論文、法規、規格
経営ロードマップ

　扱っている製品、システムの特徴によって要求の出所は異なってきますが、共通していえることは、“要求の提供者も、明確な要求やイメージを持っていない”ことです。「とても曖昧で断片的であったり、その場での思い付きの要求であったり……」との意見が、すべての参加者の皆さんから聞かれました。

　また、非機能要求、一般的には品質や性能、信頼性、ユーザビリティなどはどこから出てくるのかを聞いてみました。


			過去の製品から蓄積された実績データを基準として導き出す


			品質保証課からの意見

　非機能要求も顧客やプロジェクトメンバ、組織の内部でコミットメントして開発を進めなければなりませんが、その出所は過去の実績からが多いようです。

　非機能要求に関しても最終的にはソースコードなどの成果物に落とし込まれます。非機能要求は制約として表現して、その制約を満たすように設計・実装を行っていくことになります。

曖昧かつ抜け落ちてしまう要求との格闘

　このように非常に曖昧な要求が各所から出てきて、それを自らが詳細化し、要求を作り上げている組織がほとんどです。その中で、以下のような問題点や意見が挙がりましたので、順番に見ていきたいと思います。


			定められている規格をベースに設計・実装したが、通信ができない

　これは、規格や法規などを理解する時点での認識、とらえ方が人によって異なることや、要求の表現方法が適切でなく、設計者に正しく伝わらないことで、問題が発生している可能性があります。

　要求の提供側（この場合は規格）からの視点で、要求の表現が妥当であるかを確認していくことが重要になってきます。


			要求開発時に、要求をどこまで製品、システムに盛り込むのかのせめぎ合い

　要求の開発は、次工程の設計者などが行うことが多く、その時点で実装面も考慮してしまうことが原因の1つにあります。

　要求の開発と、要求の優先順位付けは別に扱う必要があります。要求の明確化の段階で優先順位を考慮してしまうと、実装に工数が掛かりそうな重要な要求より、それほど重要でない要求が採用されてしまう可能性があり、システムそのものの機能性が損なわれてしまうことになります。


			決められない要求と、決めたくない要求が存在する

　「決められない要求」というのは、新規開発などでよくあり得ることで、ある程度の設計・実装を行わないと、要求自体を明確に定義できない場合です。

　「決めたくない要求」とは、決して後ろ向きな発言ではなく、顧客、ユーザーの声をできる限り反映させたいとの思いからの意見です。ただし、これは単純に決定を遅らすだけでは、日程的にもコスト的にも限界があります。

　適切なオプション思考をソフトウェア開発に盛り込み問題を回避します。そのためには、変更の可能性がある要求を考慮し、優れたアーキテクチャ設計を採用します。そして、モジュール化・カプセル化を行い、パラメータによりインターフェイスを分離しておくことが必要です。

　次に、以下の意見について考えてみたいと思います。これはどちらの組織でも、解決したい問題点の上位に挙げられるものではないでしょうか。


			要求を開発していく段階で、考えの及ばない範囲はどうしてもモレとして発生してしまう

　まず大切なことは、自分たちの組織の中で、要求・仕様・設計などの範囲、定義を明確に持ち、要求開発のゴールを設定することです。今回の勉強会で強く感じたのは、これらの境目がなく、何となく要求の開発、仕様検討、設計を行っているのではないかということです。

　要求と仕様はどちらも“What”です。組織によってはさらに上位の要望という概念が存在する場合もあります。要求は実現したいことをそのまま表し、抽象的な表現になることがありますが、仕様は、要求を実現するために分解された、システム、ソフトウェアの具体的な振る舞い、在り方を表現することになります。そして設計は“How”です。

　これらの作業範囲を定義し、要求開発のゴールを明確にして、いまはどこまでの範囲を考えなければならないかを意識することが、モレを防ぐうえで重要です。

　そして、要求にはそれが発生した根拠が必ず存在します。その根拠も含めて要求を引き出して記録し、共有します。要求の内容とともに根拠を検討することで、要求の曖昧さが排除されます。また、根拠から関連して考える範囲が広がり、考えが及ばずモレが発生することを防げる可能性が高くなります。

　根拠の検討に関しては、以下のような意見が挙がりました。


			要求を検討する際に、顧客との会話の中で根拠を聞き出すようにしている。だが文書化はしていない

　大変よい活動をされていると思います。できれば聞き出した根拠を、要求と併せて成果物に記述して管理するのがよいと思います。

　また、要求のモレを防ぐ工夫として以下のような意見が挙がりました。


			認識のズレを起こさないように、顧客、関連部門との確認と合意を徹底している


			部分的にモデルベース開発を実施し、モデルの動作で要求提供者と確認している


			イテレーション開発を行い、社内の仮想顧客（評価部門など）にリリースし、検証、妥当性の確認を行っている