第1回 要求仕様に関係する落とし穴：開発環境の整理術

　開発環境の未整理状態は開発工程全体に悪影響を及ぼす要因ともなる。例えば、要求仕様書の管理ミスで、大事な機能を実装し忘れたり……。刻々と変化する開発環境を整理し、開発工程全体に秩序をもたらすにはどうすればいいか。そのノウハウを伝授する。（アットマーク・アイティ編集局）

問題点：機能を実装し忘れる（仕様変更や仕様微調整に対応できない）

顧客に提供したリリース製品について、「期待していたものと異なる」というクレームを受けてしまうことが多々見受けられます。これは、最初に要求事項を把握／定義し切れなかったことが本質的な原因である可能性が高いのですが、要求事項やリリース製品など、開発過程に作成されるものの管理方法に起因するケースも多数見受けられます。

　例えば、要求事項を取り間違えていたり、途中で要求事項が変更されていたのを忘れていたり、製品は正しく出来上がっていたのに、間違えてテスト用のリリースを渡してしまったり。

　このような過ちは、開発環境が次のようなずさんな状態で管理されているときに、特に起こりやすくなります。

• 似たような要求仕様書が多数あり、どれが本来参照すべき要求仕様書かを判断できない状態
• リリース製品が多数存在し、それぞれどの要求仕様書（あるいはその版）に基づいているか特定できない状態
• リリース製品での実装内容が要求仕様書を満たしているのか簡単には把握できない状態
• 要求仕様書やリリース製品が、顧客に提出した後でも手を加えることができてしまい、その結果、顧客に渡したものと同じものが手元にあるか定かではないという状態

　つまり、要求仕様書、リリース製品そのもの、および、要求仕様書に定義された要求事項と実装内容との関連性が、正しく管理されていない場合に、冒頭の問題に発展する可能性が大きくなります。特に開発人数が多いと、混乱が生じやすいのは簡単に想像できるでしょう。正しいものを顧客に提供するためには、これらの管理方法を見直し、上記の管理状態にならないような開発環境を事前に準備し、常に整えておく必要があります。

整理術的改善ポイント

　では、ここから改善のポイントを1つずつ解説していきます。

（1）要求仕様書とリリース製品が正しく保管されていること

（2） 要求仕様書とリリース製品が関連付けされていること

　まず、製品開発時に参照すべき唯一の要求仕様書が、正しく管理されていることが大前提として挙げられます。正しくとは、管理されている要求仕様書が間違いなく参照すべき唯一の要求仕様書であることを識別できること、開発メンバーの全員が同一の要求仕様書を参照していること、勝手な改ざんができないことを意味します。この大前提が成り立っていれば、少なくとも、開発メンバー全員が、同じ要求仕様書を基に同じものを開発しようと試みているといえるわけです。

　次に、この要求仕様書を基に出来上がったリリース製品について、いつでも誰でも、要求仕様書とリリース製品を一対一で特定できることが重要です。このためには、何らかの手段で対応を識別できるようにするほか、対応付けした後での改ざんを防ぐ必要があります。

　上記に2回「識別する」という言葉が出てきます。識別する一般的な手段としては、要求仕様書やリリース製品の名前を規則化する方法が挙げられます。要求仕様書の名前を見れば、顧客や、対応するリリース製品が特定でき、リリース製品の名前を見れば、要求仕様書を特定できる、という具合です。この場合、命名規則を文書などで明確にすること、名前を改ざんできないようにすることが当然必要です。

（3）リリース製品から実装内容が分かること

（a）要求事項とソースコードが関連付けされていること

（b）ソースコードとリリース製品が関連付けされていること

　ここまで実現できて初めて、要求仕様書に定義されていることと、リリース製品に実装されていることとが、合っているか否かを議論できます。間違っている要求仕様書と改ざんされたリリース製品とを比較して、その製品が、顧客が依頼したものと違うかどうかを議論しても意味がありません。ただ、当然ながら、リリース後に要求仕様書に沿って実装されているかどうかを議論できても、リリース時に要求仕様書に定義されていることがすべて実装されていることを確信できなければ、顧客に提供したリリース製品について、期待していたものと異なるというクレームを解決することにはなりません。

　要求仕様書の内容を細分化し、2つの時点の間に行われた変更が、要求仕様書内のどの部分に関係するかを確認できる仕組みを作ると、いつでも、今できあがっているものに、要求仕様書の内容がどの程度反映されているかを確認できるようになります。例えば、次の図のような記録を毎日つけるとすると、7月1日から7月10日の間の変更は、項目A、B、Cの実装だとわかります。。

　ただ、これでは、項目Ａ、Ｂ、Ｃの具体的な実装箇所を後で確認することができません。製品の一部を再利用したり、複数の人が並行して作業を行ったりした場合に問題が生じます。そこで、上記の記録を製品全体に対してではなく、ソースコードやモジュール単位で行ってみましょう。

　この２つを時系列に並べると次のようになります。

　こうすると、製品に組み込まれるモジュール名とバージョンが分かれば、逐次、製品に実装済みの項目が芋づる式に分かるというわけです。要求仕様書がさらにいろいろな仕様書に派生する場合でも、最終的に、大本の仕様書の項目との関連付けが管理できることを念頭に置きます。直接的な文書間の関係を維持する方法も考えられますし、大本の仕様書と最終的なソースコードとの関連性だけを維持し続ける方法も考えられます。また、製品に要求が過不足なく実装されていることを確認するために通常試験を行いますので、この試験の手順書・項目書や、試験結果の報告書などを介して関連付けるのも１案です。逆に試験に関する文書と仕様書は、互いに過不足が生じないように管理されていなければなりません。

　整理しましょう。次のような前提が成り立てば、上記の仕組みを作ることができます。

• 要求仕様書を細分化できること／細分化されていること
• ソースコードがバージョン管理されていること
• ソースコードのバージョンに要求仕様書の項目が必要に応じて関連付け

　られていること

（4） 要求事項の変更管理

　要求仕様書は、一度定まったら製品がリリースされるまで変更されないのが理想的ですが、なかなかそうはいかず、開発開始後に変更される場合が多々あります。このような変更への対応が適切でないことが、やはり、顧客の思いどおりのものを作成できない一因となり得ます。

　この変更に対応するためには、少なくとも要求仕様書が、ソースコードなどと同様に版（バージョン）の管理ができる仕組みのうえで管理されなければなりません。2つの時点において、最初のある時点で存在していた要求事項のうち、次の時点でなくなったもの／変更されたもの／追加されたもの、を洗い出せる仕組みです。この仕組み上においても、

「（2）要求仕様書とリリース製品が関連付けされていること」で説明したリリースと要求仕様書の関連性は、維持し続けられなければなりません。すなわち、リリースされたものが、どの時点の要求仕様書に基づいているのか、常に識別できなければならないということです。

• 要求仕様書 7/30版 リリース 3.5
• 要求仕様書 8/30版 リリース 3.51

　もし、要求仕様書が、項目単位で管理されていて、かつ、項目単位で変更管理ができるのであれば、ソースコードに要求仕様書の差分を明確に関連付けることができます。

　以上、理想論ですので、現実にそぐわない部分も多々あるかと思います。ただ手順やツールなどを駆使して、1つでも上記理想に近づける管理を行うことができれば、それだけミスが少なくなります。大切なのは、上記のような理想論を常に意識して、よりミスの少ない開発環境の整理を心掛けることです。

　次回は、共同作業で頻繁に陥る落とし穴、つまり、ファイルの上書きや重要ファイルの誤った消去などをいかに回避するか、そのノウハウをお送りします。