要件の曖昧な箇所を修正しギャップを無くす
バベルの塔の教訓
「バベルの塔」の教訓は、恐らく史上初のプロジェクト・レビューとも言えるでしょう。つまり、チーム内のミスコミュニケーションがプロジェクトの失敗につながるということです。昨今のプロジェクト・チームはクロスファンクションで構成されることが多く、また世界に展開されるケースもあり、コミュニケーションの問題は未だ根強く残っています。
<お客様が本当に望んでいたもの>
プロジェクトにおいては、問題の定義、ソリューション、設計ツールのアーキテクチャ、さらには組織構造や市場の勢力図など、多くの複雑な要素が絡むため、機敏な対応と継続的なリスク評価が欠かせません。米国プロジェクトマネジメント協会 (PMI)によると、ビジネス目標を達成できなかった5つのプロジェクトのうち2つのプロジェクトで、半分はコミュニケーション関連の問題が原因として存在していたとしています。これをソフトウェア開発プロジェクトで言うと、不完全な要件仕様、仕様変更、ユーザーの情報提供不足などが典型例だと言えるでしょう。
「要件」という用語を、プロジェクトの関係者全員が同様に理解していると思ってはいけません。「要件」の広義の定義は、"実装されるべきものの仕様"です。つまり、システムがどのように作動すべきか、または、システムの特性や属性についての記述のことです。システムの開発プロセスに制約がある場合も考えられます。機能に関係しない(非機能)要件に関しては、様々な動作をシステムがどのようにうまく処理すべきかを定義する必要があります。
ソフトウェア開発プロジェクトにおける要件とは
ソフトウェア開発プロジェクトにおける「要件」は、実に様々な意味を持っています。以下に示されている一般的なプロジェクト文書のすべてが関係する場合があります。(リストは完璧ではありません)
ビジネス要件、技術要件、ステークホルダー要件、設計要件、ユーザー要件、機能要件、顧客要件、非機能要件、システム要件、スコープ、プロセス要件、ハイレベル要件、詳細レベル要件、規制要件、製品要件、ユーザビリティ要件、品質要件、プロジェクト要件、データ要件、ドキュメント要件、ビジネスルール、前提条件、制約など
<「木のブランコ」プロジェクトの漫画>
1970年代の「木のブランコ」の漫画に描かれるように、プロジェクト関係者のそれぞれが先入観や偏見を持ち、前提条件や期待値も異なります。これが最終的な結果に影響を与えます。ITチームやソフトウェア・ベンダーは、お客様に提供できるものは定義できたとしても、そのシステムで必要なものは何かを定義できるのはお客様だけなのです。また、以下の分類や基準に基づき、どのようなプロジェクト・ドキュメントを作成し、レビューを行うかを選択することも必要です。
- 対象者別(例:ステークホルダー、ユーザー、規制当局、顧客の要件)
- 詳細レベル別(例:スコープレベル、ハイレベル、詳細レベル、プロジェクトの要件)
- ビジネス・ドメイン別(例:ビジネスルール、ビジネスの要件)
- システム・製品別(例:プロセス、製品の要件)
- プロジェクト別(例:前提条件、制約、ドキュメントの要件)
- 技術別(例:データ、デザイン、機能、非機能、ユーザビリティ、インフラの要件)
要件に合致したプロジェクト成果物の作成を確実にするためには、文書化とレビューのあらゆる段階において、要件仕様の過程と質の両方を管理できる綿密な計画とモニタリングが必要となります。
計画とモニタリングのためのタスクには以下が含まれます。
- ビジネス、組織、プロジェクトに適応させた要件定義のための優れたアプローチの特質を定義する。
- 異なる種類の要件を理解し、顧客の意見を適切なカテゴリーに分類する。
- 要件を展開させる際は、繰り返し内容を見直しながら、段階的に行う。
- ビジョンとスコープ、ユースケース、システム要求仕様書(SRS)のドキュメントには標準テンプレートを使用する。
- 公式および非公式のレビューのメカニズムとプロセスを定義して、ステークホルダーが効果的に要件の基礎部分をレビューでき、優先順位付けや、明確な承認が行えるよう準備する。
- チームと顧客の教育を行い、要件の変更を常に効果的に処理できるようにする。
IIBAのBABOK 2.0やBorlandのRDMなどの業界団体から、規範となる基準やプロセスが提供されてはいますが、個人の表現力や理解力の差にも対応する必要があります。作成者は、要件定義のための正式なトレーニングを受けていなかったり、日常で使用する言葉を際限なく使用してしまう場合が多いため、以下のような問題が発生する可能性があります。
- 曖昧で不明瞭、主観的な意見が持ち込まれる
- 内容が明確、簡潔ではない、首尾一貫していない
- テストができない
- トリガー、暗黙の要件、例外が見逃されている
標準化されていないビジネス用語や技術用語が使われている場合もあります。例えば、"set"という単語には194種類の異なる用途があると言われています。名詞として58種類、動詞が126種類、形容詞が10種類です。また、「ATM」という頭文字には、129種類の値が存在する可能性があります。さらに、文字通りの意味を意図的に隠す “doublespeak “の例もあります(オーウェル「1984」)。例えば、"negative patient care outcome"(患者の介護におけるネガティブな結果=死)、"carrier alternative enhancement programs"(仕事の代替となる自己向上プログラム=一時解雇)、"fiscal underachievers"(財政的な達成が困難な人=貧困層)などがあります。
要件の作成に当たり、目標とすべき重要なことが2つあります。1つめは、要件を読んだ人が全員同じ解釈ができるようにすること、そして、2つめは、この読者の解釈と作者の意図が一致することです。専門用語を使わずに、明確、簡潔に説明することで、専門用語や略語で埋め尽くされた文書を理解するスキルの無い人や、難解な言葉を避けようとする人も理解できるようになります。
以下の要件記述書についての表を参考に、曖昧な箇所がないか探してみてください。さらに良い書き方は無いか、テストは要件に記述された通りに実行できるかなどを確認してください。
機能要件の説明 | 欠点となる曖昧な部分 |
---|---|
このソフトウェアは、水位センサーをサポートする。 | 「サポート」の意味は何ですか? |
類義語(シソーラス)ソフトウェアは、要求された単語の代替案を約5つ表示する。 | 境界値 – 「約5個」とは、何個ですか?3個、4個、6個、10個以上? 表示される条件は何ですか? |
承認された取引は、後日データベースに計上される。滞納アカウントは定期的に見直される。 | 後日とはいつですか? 定期的とはいつですか? |
このソフトウェアは、アダプターのLEDを50%オン、50%オフの負荷サイクルで点滅させる。 | このソフトウェアは常時LEDを点滅させるのですか? 点滅を開始するトリガーはありますか? |
システム内にブートディスクが検出された場合、そのディスクから起動する。 | ブートディスクが存在しない場合はどうなりますか?これは不一致条件か、それとも例外ですか? |
交差点で赤信号を無視して運転すると、チケットを切られる。 | 「ユーザーがエンターキーを押下」、「イベントがタイムアウト」、「レコードが見つからない」などの暗黙的アクションが欠けています。より良い仕様は、"赤信号を通過して、あなたの車が監視カメラで撮影される、または警察官に停止を求められると、チケットが切られます"となります。 |
“interest"(利子、利息、金利)の額が100より大きい場合は、お客様に通知を送信する。 | “interest" を正しく説明します。"interest" は利子、利息、金利のどれに当たりますか? |
このシステムは、出荷/発送チームによる大量リリースに対するPC構成データのコレクションを提供する。 | 主観により、次のような解釈の差が生まれます。 • このチーム名は出荷/発送である。 • このグループを出荷チームと呼ぶプロジェクトもあれば、発送チームと呼ぶプロジェクトもある。 • 出荷と発送、2つのチームがあり、いずれのチームも大量リリースを行うことができる。スラッシュは「OR」を意味している。 • 両方のチームが共同で大量リリースを行うので、スラッシュは「AND」を意味している。 |
上の表に示されている機能要件は、「システムがすべきこと」や「ユーザーができること」という視点の表現だとすると良いのかもしれません。機能要件によっては、「ユーザー」という一般的な言葉が使われますが、その代替として、アプリケーション利用時のユーザーの役割やクラス、アクター(例: 製造責任者やシステム・オペレーターなど)などの明確な言葉で表す必要があります。また、(任意であることを示す)mayに対して、(より望ましいことを示す)shouldよりも、(確実を示す)shallを使う方が良いでしょう。このように、動詞や助動詞のニュアンスや意味の違い(例えばshall、must、may、might、will、would、could、needs to、has to、should provideなど)によって、要件の解釈を統一させることが難しくなります。
要件を客観的な条件に照らし合わせることで、その要件が、完全か、正しいか、実現可能か、必要か、優先順位が示されているか、曖昧か、検証可能であるか、を測定できます。要件を一貫性のあるものに完成させ、修正も追跡も可能にするためには、要件の基礎となるベースライン全体を包括的に検証しなければいけません。
Easy Approach to Requirements Syntax(要件定義のための簡単な構文アプローチ) (EARS) では、簡潔かつテスト可能な要件定義のための一般的な構文テンプレートが提供されています。このテンプレートは、[任意のトリガー][任意の前提条件] アクターのアクション [オブジェクト] の形式で構成されます。例えば、EARSによる要件仕様は次のようになります。「注文が出荷され [トリガー]、注文条件が “前払い" ではない場合 [前提条件]、システム [アクター] は請求書 [オブジェクト] を作成 [アクション] しなければならない」
開発者およびテスト担当者向けに指定された要件のタイミング、レベルや精度は、以下の要素の影響も受けます。
- 業務は内部用なのか、それとも外部のクライアント用なのか。
- 開発者にかなりのドメイン経験がある。
- 複数の要件に基づいたシステム・テストが行われる。
- 正確な見積もりが必要な場合。
- 既存のアプリケーションを置き換えたなど、前例がある。
- 広範囲に渡りお客様が関わっている。
- プロジェクトチームのメンバーが地理的に分散している。
開発サイクルの早い段階で曖昧な箇所を検知し、解決させるためには、様々な立場にあるチームメンバーが要件の文書を正式にチェックすることが大切です。次のような人がレビューを行うと良いでしょう。
- 要件を作成したアナリスト
- 要件を提供した顧客または代表者(特にユースケースをレビューする場合)
- 要件を実装する開発者
- 要件を検証するテスター
また効果の高い別のレビュー手法は、要件開発の初期段階にテストケースを書き始めることです。ユースケースと機能要件の両方に対し概念的なテストケースを書くことで、特定の条件下でソフトウェアがどのように動作すべきかの理解を深めることができます。この手法により、曖昧な点や欠落している情報が明らかになり、包括的なテストケースを作成できる要件定義書が仕上がります。
また、テキストベースの要件仕様書だけでなく、結果を具体的に視覚化できる、プロトタイプ開発を検討するのも良いでしょう。要件の理解が不十分な箇所に関しては、準備段階の実装を作成することで、理解のギャップを特定し、明確にすることができます。データフロー図、相関関係図、クラス図、コラボレーション図、状態遷移図、ダイアログマップなどの分析モデルを利用することで、要件の代替案や、補完的な見解を提供でき、理解の足りない部分も明確にすることができます。
何もアクションを起こさなければ要件は曖昧なまま、設計者や開発者は推測を強いられることになります。このような状態で、木のブランコの作成を誰かに依頼しますか?
LANSAハイブリッド・ローコード・ソリューションにより、迅速な導入と簡素なメンテナンスが可能になり、あらゆるアプリケーション開発プロジェクトに優れた価値がもたらされます。使い始める準備はできましたか?