上流工程の妥当な品質評価方法とは
システム開発において上流工程の成果物である要件定義書、外部設計書の品質評価をどのようにおこなっていますか。レビューを実施して、指摘箇所の修正を実施したものの、「この要件定義書の品質は大丈夫なの?次の工程に進んでいいの?」と不安に思ったことはありませんか。または、製造、試験と工程が進む中で上流工程の不備による手戻りが発生したことはありませんか。
上流工程の品質が悪いと、後続の工程で問い合わせが増加したり、試験工程で仕様バグが多発したり、とコストの増加や工期の超過を引き起こしかねません。できるだけ早いタイミングで上流工程の品質不良に気がつき、対処することが重要となります。
では、上流工程の成果物の品質は、どうように評価すればよいでしょうか。上流工程では業務の有識者が全ての要件が網羅されているか、リリース後に問題なく運用できるかといった観点でレビューを実施しますが、業務観点以外にも後続工程で外部設計通りに実装できるか、メンテナンスの際に困らない記載になっているかなど、後続の開発を意識した観点でのレビューが必要になります。
NTT DATA品質保証部には、後続を意識した品質チェックを行う「機能仕様書チェック」という取り組みがあります。「機能仕様書チェック」は業務要件のレビューではなく、プロジェクトメンバではない第三者が機能要件に関する要件定義書や外部設計書をチェックし、整合性がとれているか、トレーサビリティに問題はないかといった観点から、機能要件の確定度合いを定量的に評価します。
機能要件の確定度合いを定量的に評価
「機能仕様書チェック」ではファンクションポイント計測時の観点を応用して、機能要件に対する成果物の欠如、成果物間のトレース可否、記述内容の不足や不整合などをチェックすると共に、機能要件の確定度合いを定量的に評価します。
「機能仕様書チェック」では各工程において確定度合いを評価できるだけではなく、成果物の欠如・記述漏れ・不整合などを抽出することも可能です。プロジェクトでは抽出された不具合を修正し、横展開することや、レビューチェックリストの追加などにより要件定義書、外部設計書のブラッシュアップが見込めます。
ファンクションポイント法はウォーターフォール開発、アジャイル開発といった開発プロセス、スクラッチ開発、パッケージ開発、ローコード開発といった開発手法、また開発言語にかかわらず、機能要件の確定度合いを測ることが可能です。
「機能仕様書チェック」の観点・ポイント
実際に機能要件の確定度合いを測る際には、チェックを網羅的に実施することや、複数のレビュアが同等のチェックを実施するために、観点・ポイントを整理します。
以下に要件定義書、外部設計書をチェックする際の観点の例を示します。
- (1)成果物が欠如していないか
- (2)機能が漏れていないか
- 前後の機能と併せて考えたとき、抜けている機能がある
- 他の成果物からは機能があるように読み取れるが、該当する機能が確認できない
- (3)記述内容や記述項目が漏れていないか
- (4)不整合がないか
- 成果物間で、記述内容や記述項目などの整合性が取れていない
- (5)不明瞭な記述がないか
- 複数の意味に読み取れる、意味が理解できないなど、記述内容が曖昧に捉えられる
- (6)ファンクションポイントを算出できる記述になっているか
- 機能の具体的な記述がない
- 機能に紐づく画面や帳票がわからない
- 画面、帳票、インターフェイスの項目数がわからない
- 機能で使用するエンティティの数がわからない
- エンティティの項目数がわからない
特に(6)で記載している「ファンクションポイントを算出できる記述になっているか」については、機能要件の確定度合いを評価するための重要な観点になります。
NTT DATAではこれまで130件以上のプロジェクトに対して「機能仕様書チェック」を実施し、プロジェクトの品質向上に貢献してきました。その中で、プロジェクト特性に合わせたチェックを実施できるよう観点を整理し、蓄積してきました。また、NTT DATAの各プロジェクトの開発メンバが「機能仕様書チェック」を実施できるよう育成活動も行っています。
NTTDATAの開発以外での「機能仕様書チェック」の適用事例
ここで、NTT DATAの「機能仕様書チェック」をNTTDATAの開発以外のプロジェクトでご利用いただいた事例を紹介します。
この事例ではA社が要件定義書、外部設計書を作成し、後続工程である内部設計工程以降をB社が受注し開発することになりました。要件定義工程、外部設計工程が完了し、B社に要件定義書、外部設計書を引継ぎ、内部設計工程を開始しましたが、開始直後からB社からの問い合わせが多発しました。要件定義書、外部設計書に品質不良の疑いがでてきたため、A社よりNTT DATAに相談があり、第三者による客観的な評価として「機能仕様書チェック」をご利用いただくことになりました。
「機能仕様書チェック」の結果、バッチ機能については大きな問題はありませんでしたが、オンライン機能については不具合が多数発見されました。そして、記述漏れや設計漏れ、設計書間での整合性がとれていないことにより、上流工程に参画していないB社がこのまま後続工程を進めるのは難しいという結果を報告しました。さらに、チェック結果と合わせて不具合の具体的な内容と、その対処として推奨される活動内容を提案しました。その報告を受けて、A社はオンライン機能に絞って、品質強化体制を組織し、要件定義書、外部設計書の欠如している部分を追記することや、ウォークスルーレビューにて整合性の見直しを図る対策を実施しました。結果的に内部設計工程中でのリカバリを完了することができました。
この事例のように問題化してからのチェックではなく、要件定義工程の途中や先行開発分の作成完了時点など、早めにチェックを実施することで、問題化を未然に防ぐことも可能です。
さいごに
本記事ではNTTDATAで取り組んでいる「機能仕様書チェック」についてご紹介いたしました。上流工程の品質を担保するために「この工程ではここまで機能要件を確定し、ドキュメント化する」といった意識をもつことが重要になります。機能要件の確定度合いが妥当であるか不安、または要件定義書、外部設計書の品質についての不安など、お困りの際にはぜひお気軽にご相談ください。
NTT DATAではシステム開発ドキュメントのチェックに関する様々なサービスを提供し、第三者の目でプロジェクトが気付かないリスクの示唆や有効なアドバイスを行うことで、プロジェクトの成功に寄与します。
NTTデータ 品質保証部 第三者チェックサービスのご紹介動画:
https://youtu.be/Fg9IiMFzzGo
あわせて読みたい: