作業のプロトコル決めてる？
課題管理の話はまた今度にして今日はなぜ作業プロセスが大事かというお話。
みんなが大好きな詳細設計工程でお話を進めます。
突然ですが、詳細設計工程でどんな作業をやっているか1分で書き出してください。
Q 詳細設計工程の作業を列挙せよ
A ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
こんな感じで挙げていただいていればオーケーですね。
- 情報収集
- 検討・執筆
- 内部レビュー
- 外部レビュー
- 反映・提出
こうした工程の作業を作業プロセスと呼んだりしますが、作業に関係するメンバが好き勝手に作業をしないように作業の順序や作業方法を統一することを作業標準とか単に標準化と称したりします。
なぜ、こうした作業プロセスの標準化が大切なのでしょうか。
作業の標準化はただ同じやり方にしたいからではないよ
作業プロセスを標準化しようというと細かいルールをたくさん作って面等くさいとか、書類がたくさんできるだけで管理のためにするんだと思うかもしれません。
実際、作業プロセスの標準化が本来の目的を失って管理のための管理になっていることが多いからシステムエンジニアは毛嫌いするんですよね。
まあ騙されたと思って、本当の狙いを確認してみませんか。
- 情報収集
- 検討・執筆
- 内部レビュー
- 外部レビュー
- 反映・提出
WBSを共通化できる
まずは、作業の段取りを５ステップに決めています。ただ、作業順序を決めているようにも見えますが、作業プロセスを５ステップに分けることで、WBSが工程内で統一化されます。WBSのボリューム次第ですが機能をWBSのレベル３にするならば、レベル４はこの５つのステップと共通の作業とすることができます。
「あの機能どこまで完了したの」
「内部レビューまで完了しましたよ」
となればあとは外部レビュー以降が残っているんだな、とわかりますね。
さらに言えば、５ステップ目が作業をexitしてよいか判定するためのゲートウェイになります。
進捗管理を組み込める
次に、作業プロセスが５ステップになったので、進捗が工程内で同じ単位で計測できるようになります。これについては一昨日のエントリでも書いていたので読まれた方は想定できたと思います。
- 情報収集 ○ ○
- 検討・執筆 ○ ○
- 内部レビュー ○ ○
- 外部レビュー ○ ○
- 反映・提出 ○ ○
品質管理プロセスを組み込める
３番目は、品質管理プロセスが組み込めるようになります。というか既に内部レビュー、外部レビューとして組み込まれていますね。
重要なことは、作業プロセスに組み込んでいるので品質管理プロセスを経ないと作業が完了しないという点です。
- 情報収集 ○ ○ ー
- 検討・執筆 ○ ○ ー
- 内部レビュー ○ ○ ○
- 外部レビュー ○ ○ ○
- 反映・提出 ○ ○ ー
誰がどこで困っているかがわかるよ
一番大きいのは朝会などの困っていることでどのステップで困っているかが可視化できることです。なぜなら、作業プロセスが標準化されることでプロジェクトの作業に関する共通のプロトコルになるからです。
プロジェクトが上手くいかなくなる原因のひとつは誰が何をやっているか可視化されず、小さな躓きがプロジェクトの他のメンバの目に触れず、リスクをプロジェクト自ら強化してしまうことになるためです。
