Posted on by tyskdm

具体例 ：ソフトウェア品質保証体制構築支援

  • 顧客企業から規格・スタンダードなどに準拠した品質保証を求められている
  • 社内の品質保証部署がアジャイル開発へ対応しておらず、チーム側で取り組みたい

ここ数年の間に、上記のようなご相談をいくつかいただきました。実際にはご相談内容を伺いながら進めますが、ここでは１つめのパターンからひとつご紹介します。

1. 相談内容

  • 新規顧客向けに製品を開発することになった
  • その顧客から規格・スタンダードに則った品質保証を求められている
  • ソフトウェア開発の実績はあり一定の品質を維持していると自負しているが、社内で定義された開発プロセスや品質保証体制と呼べるようなものはない
  • 規格・スタンダードの勉強から始めていたのでは間に合わない
  • どう対応したらいいか、ということを考えるところから支援が欲しい

2. ゴール設定

  1. 眼前のビジネスで求められている品質保証要求をクリアする
  2. 社内の品質保証体制を構築する

前もって品質保証体制を構築しておくことができれば時間的にも費用的にも、なにより精神的に楽なのですが、ビジネスが眼の前で動いているケースでは同時並行するしかありません。お話しうかがって相談のうえ、眼の前の課題に急いで対処しつつ、中期的に体制を整えることにしました。

2. アプローチ

まず今現在開発しているソフトウェアが充分な品質をもつことを、顧客に文書で示せる状態にします。こちらはもう時間がないので、最低限度の対応工数になることを目指しました。

  1. 現状実力通りの品質確保活動を説明可能にする
  2. 顧客要求に対して不足する品質活動を追加する
  3. 顧客要求を満足する品質確保活動の実施を記録する

続いて（あるいは並行して）組織的な品質保証体制を整備します。品質保証のベースとなる組織的な継続改善体制をつくります。

  1. 今後のプロジェクトでも適用可能・改善可能であるようプロセス定義の調整
  2. 手段の変更・ツール導入などによる運用の効率化・高精度化
  3. 改善サイクルを運用する仕組みを追加する

3. 具体的な支援内容

以下のような支援を行いました。この例では、Automotive SPICE（自動車業界向けソフトウェア開発プロセス評価の枠組み）が顧客から要求されていました。

3.1. 眼前のビジネスで求められている品質保証要求をクリアする

チームメンバーに工数余力が少なかったため、知恵だし・議論はしてもらいつつ、弊社メンバーが主導して進めました。

1. 現状実力通りの品質確保活動を説明可能にする

まずは現状の把握を行います。ヒアリングおよび実際の成果物から簡易的なアセスメントを実施して、結果をAutomotive SPICEのプロセス評価観点に照らして整理しました。これにより、不足する活動を関係者と共有します。

2. 顧客要求に対して不足する品質活動を追加する

Automotive SPICEのレベル到達判定が目的ではないので、開発中のソフトウェアに対して品質を保証するために最低限度必要な活動を追加します。

このときできる限り現行の開発手順からの変更・追加が少なくなるよう手段を選択しました。具体的な手段は私たちからも提案しつつ、チームメンバーとの議論を踏まえて決定しました。

Agile についての補足

弊社では、Gitとそのホスティングサービス（GitHub / GitLab / Bitbucketなど）、ITS（Issue Tracking System、Jira / Wrikeなど）などを利用したモダンな開発スタイルの経験も多く、アジャイルベースでの開発プロセスに対しても支援が可能です。

また例えば、プルリクをレビュープロセス＆レビュー記録として採用する、変更依頼管理のITSチケットIDをリリースまでの設計トレーサビリティ記録に関連付ける、などツールの利用方法を工夫することで、品質保証のための工数増大を抑制することができます。

ツール整備についての補足

学習コストが大きくならない範囲で、ツールを導入・拡張することもあります。たとえば統合試験の不具合管理にJiraを使用する組織で：

  1. 登録項目のカスタマイズを行い不具合の発生源となった工程を記録可能にして改善に繋げる
  2. 複数チームの不具合管理を統合したシンプルなダッシュボートサーバーを構築する

などの整備を行いました。

3. 顧客要求を満足する品質確保活動の実施を記録する

記録自体は開発チームに実施してもらう以外に方法がありませんが、定期的なモニタリングを実施して現場への意識付けを支援したり、実運用時の運用相談に応じるなどを行います。

3.2. 社内の品質保証体制を構築する

ここからの活動は弊社が主導するのではなく、御社メンバー主導で弊社が伴走支援するカタチで進めることが望まれます。

専任の品質保証担当メンバーがアサインできれば理想ですが、現実的には開発チームのメンバーがSQE（Software Quality Engineer）を兼任することからのスタートが多いと思います。

4. 今後のプロジェクトでも適用可能・改善可能であるようプロセス定義の調整

上記ではあくまで眼前のビジネスを最優先しているため、充分に一般化されていない部分を調整します。

5. 手段の変更・ツール導入などによる運用の効率化・高精度化

手順変更・ツール導入には学習コストがかかります。上記の突貫工事ではこれを避ける（納期に追われているエンジニアに余計な学習をさせない）ことが多いので、現状に近い手段を採用されていることが一般的です。

段階的に、より効率的な方法へ置換えてゆきます。

6. 改善サイクルを運用する仕組みを追加する

現場主体で継続的改善サイクルをまわせるよう、改善サイクルそのものの運用手順を定め、その運用を支援します。

4. 振返りと継続改善

ここまでで品質保証体制の基礎的な骨組みは出来上がっていることになります。

ただこの例では突貫工事で進めてきていますので、まだまだ抜けている部分、現場メンバーの手になじまない部分など、いろいろあるはずです。納品を終えるなど少し落ちつくのを待って、改めて振返りを行うことになります。

またこれ以降はやみくもに品質保証体制整備（プロセス整備）だけを極めようとするとバランスを崩すことになりかねないので、ソフトウェア開発力強化を目指す一環として継続改善することをおすすめしています。

5. まとめ

ここでは、かなりの突貫工事で進めたケースを紹介しました。本来ならもっと落ち着いて段階的に進めたほうがよい内容ですが、限られた期間、限られた工数では、仕方のないこともあります。

杓子定規にならないよう御社の状況・ニーズにあわせて、できる範囲のなかで最大の効果が得られるよう、活動内容をご提案し、支援しています。