2軸4象限でフロントローディングの方針立てを整理する

 テストクラスタフロントローディングがよく話題になるようになっています。これに関して、作業や課題を2軸4象限で整理すると検討を整理できる場合があります。チームで課題を話し合うときの議論の整理といった、簡易的・アドホックな使い方限定のプチフレームワークですが、今回その整理方法について触れたいと思います。

2軸4象限

 整理に用いる2軸は次の通りです。

  1. 早期にやるべきかの必要性(あるいは重要性):
    • 早期にやるべきか、早期にやらなくてよいか(後回ししてもよいか)
  2. 早期にできるかの実現性:
    • 早期にできるか、早期にできないか

 これを図にして、次のような4象限マトリクスにします。それぞれA、B、C、Dの象限を割り当てます。

f:id:goyoki:20190922013034p:plain

※一般的な必要性(or重要性)と実現性のマトリクス分析を、フロントローディングに適用したものになります。

 おおよそですが、それぞれの象限ごとに、フロントローディングを進めるにあたっての対応方針が異なってきます。

4象限ごとのフロントローディングの対応方針

A、B、C、Dに対し、フロントローディングを進めるにあたっては次のような方針立てを行います。

「D:後回しにしてよい&早期からできる」の対応方針

  • Dの作業の例
    • 後のプログラミングで検討しても支障のない、詳細なIF仕様の設計など
  • Dに対する方針
    • 該当作業は、重要度と余裕に応じて実施します。後回しにするなら、いつ実施するか方針立てします。
    • このDに属する作業については、早めに処理する方針を立てれば、後の余裕を確保できます。ただやり直しや陳腐化のリスクの点で、B象限とA象限対応を優先する方が無難な場合があります。

「C:後回しにしてよい&早期からできない」の対応方針

  • Cの作業の例
    • 顧客リリース物のチェックなど
  • Cに対する方針
    • 後回しで実施します。Cに属する作業については、後々実施すべきタイミングで確実に実施できるように、中期的な方針立てを実施します。

「B:早期にやるべき&早期からできる」の対応方針

  • Bの作業の例
    • プロジェクト成否へのインパクトの大きいリソース確保の調達計画など
  • Bに対する方針
    • 重要度に応じて、実施します。Bに属する作業については、該当する作業をきちんと識別して確実に実施する方針を立てるのが重要です。

「A:早期にやるべき&早期からできない」の対応方針

  • Aの作業の例
  • Aに対する方針
    • フロントローディングにあたって、知恵を絞って方針を工夫する対象です。3つの方針で対応していきます。
      1. 早期にできるようにして、B象限に移動させる
        • e.g. 未知未経験で早期に実施できない → 反復開発やプロトタイプで早期に実践経験を積んで、未知未経験を早期に解消する
      2. 後回しできるようにして、C象限に移動させる
        • e.g. 要求が未確定なために早期に実施できない場合 → 想定される要求を数パターン設定し、それらに対応できるように、外部インターフェースに可変点を設ける
      3. ステークホルダと調整してスコープ外にする

 全体の対応方針ですが、フロントローディングの推進ではA象限、B象限への注力が重要になります。逆にC、D象限の前倒しで時間を浪費して、本質的なA、B象限がおざなりになることも多いです。

アーキテクチャ設計での例

 フレームワークの使い方は主に次の2パターンです。

  1. 識別した作業の方針立て
    • 課題や作業を識別した後、それらがこの4象限のどこに分類されるのか考えることで、方針を考えます。
  2. 課題や作業を分析するための観点
    • 4象限を観点にして、課題や作業を分析します。

 アーキテクチャ設計を例にとると、チームメンバーで、アーキテクチャドライバを観点にして課題を出し、課題を重要度と4象限で分類して、フロントローディングの対応方針を立てるといった使い方をします。