プロセス
本当に安定した品質は、作業を後から確認するだけでは実現できません。プロセスとは、品質に関わる行動が、開発やテストの流れの中に自然と組み込まれている状態です。その流れが整っていないと、品質確認は後追いになり、手戻りややり直しが繰り返されます。プロセスは、判断が日々の行動として再現されるかどうかを左右します。
この構造で現れやすい兆候
- 不具合や品質問題が、開発の後半やリリース直前になって見つかることが多い
- 同じような手戻りや修正が、スプリントやプロジェクトをまたいで繰り返されている
- 工程ごとの確認内容や進め方が、案件や担当者ごとに異なっている
なぜ起きるのか
これは、判断を行動に落とすためのプロセスが、構造として整理されていないことに起因します。
品質が、後工程でまとめて確認するものとして扱われている
品質に関する判断が開発の途中では行われず、最後にまとめて確認するものとして捉えられていると、プロセスは常に手戻り前提になります。前工程で立ち止まって判断する理由がなく、問題は後になってから表面化します。
品質に関する判断点が、プロセスとして定義されていない
どの工程で何を判断すべきかが明確になっていないと、品質に関わる行動は個人の裁量に委ねられます。その結果、判断は場当たり的になり、前倒しでの確認や合意が定着しません。
判断を省略しても、失われるものが見えない
品質に関する判断を行わなくても、その場では進捗や成果に大きな影響が出ない状態では、判断は後回しにされがちです。判断点がプロセス上の必須条件になっていないため、品質行動は流れとして埋め込まれません。
プロセスとして品質をどのように捉えるか
プロセスは、 技術や仕組みと、日々の行動の関係から品質を捉える構造です。
どれだけ適切な判断があっても、 それがどのタイミングで、どの行動として実行されるかが整理されていなければ、 品質は安定しません。
プロセスとして品質を捉えるとは、 判断を前提とした行動が、 個人の裁量ではなく、 再現可能な形でプロセスに組み込まれているかを確認することです。
プロセスとして品質を捉えられるようになったとき、品質に起きる変化
プロセスが構造として整理されると、 品質に関わる行動は個人の裁量に依存せず、 再現可能な形で積み上がります。
その結果、品質に関する判断は、 毎回やり直されるものではなく、 前提として現場に実装されるようになります。
判断と行動のズレが起きにくくなることで、 リリースや優先順位に関する意思決定も安定します。 経営や事業の判断が、現場で意図せず変質するリスクは下がります。
アジャイル開発プロセスに品質を組み込む
アジャイル開発を導入している企業のなかには、サイロ化した組織が原因でソフトウェアの品質、コスト、納期に関する問題が生じていることがあります。QA to AQを導入することで、そのような問題を効率的かつ効果的に解決することができます。
プロセスを増やすことが目的ではありません。
今ある開発やスプリントの流れの中で、品質に関わる判断と行動を判断点として整理・設計します。