VOICE

さらなる価値提供を目指して。「品質管理」強化への具体的な取り組み(後編)

関連キーワード

【前編】システム開発の要石――ジークスが今、「品質管理」に再度向き合う理由

品質管理強化に向けたジークスの取り組み

本題に入る前に、まずは前編の内容を簡単におさらいさせてください。品質管理推進グループを立ち上げた目的は、主に次の2つでした。

  • 業務の属人化を解消し、効率的な品質管理を実現すること
  • 環境を整備することでジークスの強みである「ワンチーム」を活かすこと

それまではPM・PLに任せていた品質管理を、専門のグループがまとめて担当することに。プロジェクトを横断的に管理するとともに、プロジェクトメンバーが最大限にパフォーマンスを発揮できるように働きかける……というのが同グループの役割です。

ここからはいよいよ、現在行っている取り組みの具体的な例をご紹介します。

要件定義のチェックリスト作成

要件定義のフェーズで決めておくべき項目をチェックリスト化し、社内に周知・共有を行いました。後述する設計・単体テストを含めて、社内に蓄積された知識や経験をチェックリストに起こしています。これまではPM・PLの“頭の中”で完結していたものを、目に見える形で明示したイメージです。作成に際しては、プロである品質管理コンサルからもご協力をいただきました。

チェックリストは、要件定義開始時にこれから作成すべき成果物の確認のために利用し、終了時には作成した成果物のチェックに使用します。
終了時のチェックは品質管理推進グループで行い、万が一懸念点がある場合にはプロセスの部分を含めてフィードバックをします。

要件に対する仕様のマトリクス(表)化

要件ごとに対応する仕様を整理し、マトリクス(表)としてまとめるフローを設けました。作成したマトリクスをお客様に共有することで、「伝えた要件がしっかりと設計に落ちている」と確認してもらうのが主な狙いです。

また、開発側の目線では、「どの設計書を修正したときにどの仕様に影響があるか」を把握できるメリットがあります。

設計のチェックリスト・設計書フォーマット、設計ガイドラインの作成

要件定義と同様に、設計フェーズで決めるべき仕様などをチェックリスト化しました。

これまでは資料作成の基準はPM・PLに依存していたため、案件や担当者によって作成する資料にばらつきがありました。必要な資料が作成されていない、または、必要な粒度で書かれていないケースがあったことも一因です。

こうした問題を解決するため、チェックリストを作成し、どの案件、どのPM・PLでも同じ粒度の資料が作成できるようにしました。また、設計書フォーマットも統一化し、設計書を記述するにあたって漏れがちな部分をガイドラインとして提供することで、誰が設計を行っても一定の品質を担保できるようにしました。

単体テスト仕様書のフォーマット・ガイドラインの作成

単体テストについても、テスト仕様書フォーマットとガイドラインを作成しました。設計書同様、テスト仕様書を書く人に依存することなく漏れのないテストを実施できるようにし、単体テストフェーズでしっかりと単体バグを出し切ることを目的としています。

単体テスト仕様書は若手の実装者が作成することが多いため、作成した単体テスト仕様書は、品質管理推進グループが確認を行うという流れも導入しています。

今の段階で得られた成果

現時点で品質管理推進グループが行っている主な取り組みは以上です。

改良すべきことは残っていますが、現時点でも着実に成果は出始めています。顕著なのは、仕様のマトリクス化を中心に、これまでブラックボックスだった部分を“見える化”できたことです。また、単体テストの精度が上がり、結合テストへスムーズに進めるようになったのも大きなポイントだと感じています。

今後のさらなる取り組み、ジークスの目指す価値提供

ここまでの内容で、品質管理に対するジークスの向き合い方はあらかたお伝えできたのではないかと思います。

今後は単体テストフェーズ以降についても、さらなる取り組みを進めていく予定です。直近の目標は、テスト結果の集計・分析を自動化すること。将来的には、見積もりや提案、運用方針全体の指標を作ることも想定しています。

ジークスが目指すのは、「デザイン力 × 技術力のパフォーマーとしてITを社会に実装する」 ことです。お客様のご要望に対して企画・制作・開発・運用までワンチームで対応できる、その価値提供を実現・最大化する手段として、今後もさらなる品質維持・向上に向けた取り組みを続けていきます。