決まらない要求の開発と管理：現場の声からプロセス改善を深掘りする（2）（2/2 ページ）

明確にした要求を
どのように整理するか？

　前項のテーマにも関連しますが、モレなどの要求の不具合を防ぐためには、要求の整理の仕方、まとめ方も重要になってきます。ここでは、参加者の皆さんがどのように要求を整理しているかを紹介します。

　まずは整理するための基本となる、要求の開発段階で作成する成果物に関してです。

			顧客からのぼんやりとした要求を、要求仕様書にまとめ、それを詳細化した個条書きの要求文書を作成している

			製品企画書から、機能リスト、UI仕様書、インターフェイス仕様書に要求をまとめている

			顧客から要求仕様書を受領し、それを分析して、社内の要求と合わせて機能仕様書にまとめている

　形式はいろいろありますが、何らかの要求に関する成果物は作成しているようです。ただ、ここでも設計にかかわりそうな成果物がいろいろと出てきました。イテレーション開発を行っているにしても、ある程度、作業フェイズとそのゴールを意識して作業に当たるのがよいと思います。

　ここで挙げられた成果物に記述される要求の内容は、以下のようにさまざまなものがありました。

			最先端の製品を作れ！ A社に勝つ製品を作れ！

からはじまり、

			○○のデータが××の値のときに“ABC”と表示する

というものまで、幅広い粒度で記述されているようです。

　ですが、どちらも要求（要求仕様）であることには違いはありません。それぞれの組織で定めた作業フェイズの範囲や、新規開発／派生開発、対象としている製品などによって異なってくるはずです。

　また、上記から分かるように、要求には上下関係があり階層構造で定義されます。抽象的で内容の範囲が広い要求を、ブレークダウンして要求の範囲を狭めていきます。

　ブレークダウンするときのポイントは、

• テストが実施できるまで分割する
  
• 要求内容の中に2つ以上の振る舞いを記述しない
  
• 時間の計画、状態の変化で分割する

など、いろいろなやり方があります。この辺りはいろいろな専門書が販売されていますので、参照してみてください。

要求に変更が発生した場合の管理方法は？

　要求が明確になったら、今度はそれをプロジェクトの完了まで管理しなければなりません。管理の主な作業内容は“変更の管理”です。具体的には、以下のような作業になります。

（1）要求の追加／変更／削除の発生を認識し記録する（以下「要求変更」）
（2）要求変更の影響範囲を分析する（エンジニアリング面、管理面）
（3）要求変更の影響範囲を利害関係者で合意する
（4）要求変更の対処を実施する（エンジニアリング面、管理面）
（5）対処の状況を監視する

　参加者の皆さんの組織では、ほぼ適切にこれらのプロセスが実施されているようでした。プロセスとして定義されていて（手順化されていて）、要求変更の状況が記録されていることが理想ですが、現場で必要十分な程度には実施されているようです。

　影響範囲の分析では、以下のような意見が挙がりました。

			要求マトリクスを見て判断を行っている

　大変、成熟度が高い組織だと思います。要求からの下位の成果物に対するトレーサビリティをマトリクスとして作成しておき、それに基づき影響範囲の特定を論理的に行っています。

　自動車関連や医療関連のバリデーション、また、CMMIやA_SPICE、機能安全などの各種認証モデルなどでも要求されるので、最近では話題となっています。

　現場にいきなり要求変更が落ちてくる意見も聞かれました。

			上司も技術者なので、企画、営業などからの要求をその場で判断し、現場に対しては「やるぞ〜!!」が最初のインプットになる

　影響範囲の分析は、要求変更の実施決定の後になってしまい、日程、コスト的なしわ寄せが現場にのし掛かる場合もあると思います。ビジネス的な判断から仕方ない場合もあるのでしょう。ぜひその後、現場に対するフォローを確実に実施していただきたいと思います。

　また、要求変更によるすべての影響を、コストに換算し判断している組織もありました。

			技術的な影響で掛るコスト、リリースが遅れることによる損失コスト、要求変更を行わなかった場合の販売の低下コストなどを明確にし、総合的に判断している

　理想的な要求変更の実施判断だと思います。ただ、この意見を挙げた方が問題視されていたのは、コストの見積もりがKKD法で行われていることだそうです。見積もりを行う人が、過去の類似事例からこれくらいでできるのではないかと検討するようです。その際の人間的な要素も定量化が難しいようです。

　ぜひ、KKD法から、データを基に検証できる見積もりへとステップアップしてほしいものです。

　過去の要求に関するデータを蓄積するためには、要求を分解する粒度、大きさがポイントになります。この要求の粒度に対してこのような結果になったと、データが測定できて紐（ひも）付けできると、有効なデータを蓄積できます。

やはり要求の開発、管理は難しい……

　要求開発、仕様策定などの上流工程は、時間的なプレッシャー、成果物の実態が存在しない不安から、プロセス自体を未実施、または簡略化してしまう場合があります。また、最近のソフトウェア開発では、構築するシステム、ソフトウェアがとても複雑化し、開発サイクルも非常に短くなっています。

　また、そのような状況では、プロジェクトの初期段階で要求をすべて洗い出すことは難しいと思います。要求の変化を考慮した、スパイラス、インクリメンタル、イテレーション開発など、さまざまな開発の進め方が考えられていますが、それぞれのサイクルでの要求のモレや不整合は大きな手戻り、追加作業を生んでいるはずです。

　自分たちに適した開発のスタイル、要求開発の作業範囲、要求の表現方法を、組織の中でぜひとも議論してください。

　要求開発、管理を最適化していくことで、きっと組織や自分にとっての新たな時間が獲得できるはずです。その時間を、高いレベルの設計や実装、新たな技術の習得などの、モノづくり業界で働く中での最も建設的な部分につぎ込むことができたら、エンジニア冥利（みょうり）に尽きるのではないでしょうか？ ぜひ、難しい要求開発・管理に関して、前向きに挑んでいただきたいと思います。

　次回は、今回のテーマからつながる「要求から成果物へのトレーサビリティ」です。またまた難題ですが、ご期待ください。（次回に続く）

筆者プロフィール   横河ディジタルコンピュータ株式会社 組込みプロセスシステム事業部（EPS事業部） コンサルティング企画部 清水 祐樹（しみず ゆうき） 金融機関におけるエンタープライズ系開発で、長らくプログラマ、システムエンジニアとして活動後、通信計測器メーカーにてハードウェア・ソフトウェアが連携した開発に従事。現在はCMMIの視点から、組み込みソフトウェア開発、ハードウェアを操作するためのフロントエンドGUI開発などの顧客に対して、プロセス改善の支援に従事。 ▼組込みソフト開発現場が抱える課題の解決を考える勉強会 http://www.yokogawa-digital.com/eSPITS/seminar.html