品質バラつきにはやっぱり標準化|SHIFTインスペクションチームの取り組み(前編)
はじめに
こんにちは。SHIFTの技術統括部で《インスペクター》をしている馬場です。 この記事では、私が所属するインスペクションチームにおいて、業務の品質と生産性向上のため、SHIFTを象徴する考え方である“標準化”に取り組んだ例について紹介します。 2部構成で説明していきます。
インスペクションとは?(前編)
インスペクションの課題、標準化作成にあたって・その効果(後編)
インスペクションとは?
あまり聞き慣れない方のために、まずインスペクションとは何か、簡単に説明します。 インスペクションとは、ひとことでいうと”第三者視点のドキュメントレビュー”です。 第三者(作成者ではない他者)が各種開発ドキュメントを詳細に検査するレビュー技法であり、ドキュメントに潜む欠陥を検出することを目的としています。
SHIFTでは上流工程で作成した成果物(各種設計書)をチェックする 「仕様書インスペクション」 と、各テスト工程(単体、結合、総合)で作成した成果物をチェックする 「テストケースインスペクション」 を主に行っておりますが、今回は「仕様書インスペクション」についてお話ししていきます!
インスペクションの狙いと期待効果
システム開発では各工程で様々な欠陥が埋め込まれます。
例えば、要件定義で決定した要件が基本設計で漏れてしまったと仮定します。
その場合、「設計漏れ」の基本設計書をもとに詳細設計が行われるので、「設計漏れ」の詳細設計書が作成されてしまいます。以降、「設計漏れ」の仕様のまま工程は進んでいきます。
通常、基本設計書の欠陥は詳細設計工程や初期テスト工程(単体テストなど)では検知されず、後期テスト工程(結合テストや総合テスト)で検知されます。
この例のように、基本設計書の「設計漏れ」が開発後期に発覚してしまうと、設計書の修正のみならず、影響調査、実装の改修、テストの再実行といった手戻りコストが増加し、最悪の場合、当初予定していたシステムリリースに間に合わないといったプロジェクト計画にも影響を及ぼす恐れもあります。
このように、欠陥の発見が後になればなるほど、その対応のコストは飛躍的に増加していきます。 逆に「欠陥を早期に発見すること」で、影響範囲を限定し、最小限のコストで欠陥に対応することができます。
では、上流工程からインスペクションを適用した場合どうなるでしょうか?
第三者の立場で客観的にドキュメントを検査することで、作成者の暗黙知や思い込み、欠陥を早期に発見でき、品質を確保しながら開発を進めることができます。 また、欠陥の傾向を分析し、類似する欠陥の早期発見や欠陥の作り込みを未然に防ぐための対策を講じることで、開発全体の品質向上や上流工程での欠陥除去・予防によるテスト工程でのコスト削減が期待できます。
私たちはインスペクションを活用して品質確保に貢献しています。
インスペクションの指摘例
次にインスペクションの指摘事例を紹介します。
以下の画面処理仕様書は基本設計書を想定しています。 赤枠内ではデータの取得処理(取得対象のテーブル、取得条件、エラー時の処理)が記載されています。
では、詳細設計に進んだとき、詳細設計者はこの基本設計書をもとに必要な内部仕様を漏れなく詳細設計書に書き起こせるでしょうか?(基本設計書と詳細設計書の設計者が異なるケースを想定しています)
おそらく、次のような疑問が出てくるでしょう。
データが取得できなかった(0件)場合、どうする?
どんなメッセージを出す?メッセージIDは? 引数は?
エラーメッセージ出力した後、どうする?(処理終了or処理継続)
エラーメッセージ出力した後、処理継続する場合、どの処理に飛ぶ?
このように記載が曖昧な場合、読み手によって判断が分かれやすくなってしまうと、作成者の意図しない仕様でこの先構築されてしまうリスクが考えられます。 上記の様な欠陥をインスペクションで早期に発見していきます。
次回は後編で!
インスペクションの課題、標準化作成にあたって・その効果(後編)
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/
SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/