「要件の把握と合意」について

はじめに

主にCMMIを参考にして、仕事の進め方で重要なポイントや考え方について記載していきます。

仕事とは？

「仕事」とは、誰かの「要件」を満たすことと定義できるでしょう。ですから、「要件」を把握することはなによりも優先されるべきプロセスと考えられるでしょう。

CMMIでの定義

CMMI(Capability Maturity Model Integration)では主にREQM(要件管理)に割り当てられているプロセスです。ちなみにCMMIでは無秩序な状態を成熟度レベル1と定義しており、成熟度レベル2で着手するべき6つのプロセス領域の1つにあたります。

CMMIでは、REQMのプラクティスとして5つを定義しています。

- SP 1.1 要件を理解する
- SP 1.2 要件に対するコミットメントを獲得する
- SP 1.3 要件変更を管理する
- SP 1.4 要件の双方向の追跡可能性を維持する
- SP 1.5 プロジェクト作業と要件の間の整合性を確保する

この中で、SP 1.1の「要件を理解する」がもっとも困難であり、もっとも取り組みがいのあるプラクティスです。SP 1.2以降は(重要なプラクティス・考え方ではありますが)SP 1.1に従属しているものに過ぎません。SP 1.1に深く取り組むために事前に「「品質」について」というnoteを記載したのです。

要件とは？

CMMIの用語集の一例では「問題の解決または目標の達成のために、利用者が必要とする条件または能力」とあります。ここでは「必要とする」という言葉が重要になってくるでしょう。明示的かどうかは問題ではなく、「必要とする」ものはすべて要件と解釈されるべきです。

要件の分類

要件をどのように分解するかについても議論や研究がありますが、ここでは僕個人の考え方を述べます。最初に大きく3つに分類されると考えています。

- 機能要件
- 品質要件
- プロセス要件

「機能要件」とは成果物が持つべき機能のことです。一般的に要件提供者が明示してくれることが多いと考えられます。
次に「品質要件」、前述の「機能要件」の達成レベルなどを定義します。異常発生時に自動でリカバリするのか、顧客にメッセージを提示するのかなどの異常系の実装レベルや検証のレベルもここで定義していくのが良いでしょう。品質要件は開発環境は開発者のスキルとも関係しますので、利用者からの明示は期待できません。「「品質」について」というnoteを参考に、品質特性を意識した品質要件を考えてみすことをお勧めします。
最後に、このnoteで特に伝えたいこととして「プロセス要件」の合意をお勧めします。どのような開発手法・業務手法を取るかを事前に共有・合意しておくと良いでしょう。打ち合わせ、進捗報告、成果物のリリース、開発側の体制、開発者のスキルなどを事前に共有・合意することで、より高いレベルの合意をすることが可能になります。言い方を変えれば、プロセス要件を合意することで機能要件・品質要件の裏付けを要件提供者側と共有することが可能になりますので、さらなる要件を要件提供者側から引き出すことが可能になります。

終わりに

要件管理は要件提供者の言うことを箇条書きにすることではありません。要件提供者の言うことを理解し、要件提供者の言葉の背後にある隠された要件を把握し、引き出し、より高いレベルでの合意を得て、最終的な顧客満足に繋げることこそが必要です。参考になりましたら。