仕事の基本ルール
■ゴールの得点
何かの仕事をはじめる時に、「最終的なゴールイメージはこんな感じ」というのを想定してはじめるようにしてます。
140点 −ちょっと出来すぎ
120点 −上出来だろう
100点 −ま、このくらいはやれるだろう
80点 −ちょっと出来が悪いかな
60点 −できが悪すぎ、ちょっと仕切りなおしが必要
こんなイメージで、ゴールポイントを決めていきます。
仕事をはじめる前に、このゴールイメージを決めずに仕事をしている人をときどき見かけます。
私は部下と面談をする時(1年に2回)、必ずこれを聞きます。これに答えられないと、考えなおし。
■仕事の進捗具合
で、仕事の進捗を測るためのカーブイメージを簡単な絵に書きます。
横軸が時間(おおよそ半年)、縦軸が出来上がり具合。
出来上がり具合というのは、仕事のマイルストーンです。
たとえば、プログラムを作るときには、
要件定義書作成完了 10%
機能仕様書作成完了 25%
移行計画書作成完了 35%
コーディング完了 50%
デバッグ完了 60%
評価完了 80%
リリース・導入活動完了 99%
フィードバック 100%
にわけて、それぞれに日付を当てはめるわけです。
横の%が進捗具合です。感覚で分けると進捗具合がぶれるので、これ以外のレベルは分割してません。例えば、コーディングが半分くらいできたので、55%です、というのは認めません。完了しない限り50%のまま。
これを日程に対応させて、進捗状況を報告してもらうわけです。
たとえば、作業開始から30日目に機能仕様書が完了するはずだったのに、まだできていないとすると、進捗状況は 10/25*100 で、40点 が進度になります。
逆に、もう移行計画まで作り終わっているのであれば、35/25*100=140点で超順調なので、もうちょっとスローダウンしても大丈夫、などと判断します。
要は、目標進度を数値化して、それを現実の進度と比較して、これを現在の進度として数値で表すようにすることで、かなり正確な進度がわかります。これを
「どう？」
「順調っす！」
「どのくらいすすんでる？」
「まぁ、8割は完了しました」
なんていう会話をすると、その人の8割はコーディングのことで、上司の聞きたいのはゴール(プロジェクトの完了)までの残り時間だったりすると、後で悲惨なことになります。
これを、最初にどこまでできたら何点、と最初にある時点でのゴールを決めておくことによって、正しい進捗状態が把握できます。
■仕事の品質
上記は、日程での進捗状態でしたが、これを同様に機能で測定します。
例えば、
PCアプリにおける画面数
機能仕様書の機能一覧の行数
WBSタスク数
などといったものです。
私がよく採用するのが、機能一覧の個数。
最近はアジャイル開発をするようになったので、上記の日程が各機能ごとに別々の日程で進みます。このため、この機能を組み合わせないと進捗具合がわからないのです。
つまり、各機能において、それぞれの日程充足率(上に書いた40点、140点といった数字)の平均と偏差を取らせて、それを進捗度として報告してもらいます。
ただし、一定以下のものは0点などと足切りをして、本人に都合の悪くなるような報告をさせます。
そうすと、報告する側としては、あまり悪い数字は報告したくないので、なんとかすべてを一定の水準にしようとします。
さらに、ユーザ要望以外の(機能仕様書にない)機能を実装した場合には、加点できるようにしておきます。もちろんそれがユーザが望まないものであったとしても、別に要求機能自体が満足されていれば、文句は言われません。
■数値化して、それを判断できるようにすること
ま、とにかく、
何時の時点でどこまで出来ていたらOKにするのか
どこまで出来が悪かったら緊急事態と判断するのか
というのを、最初の計画段階で明確にしておくことです。
これがされていないと、
夏休み症候群
に陥ります。
