段取りと現実
さて、有給消化がはじまる。
休暇とは言え、やんなきゃいけないことが山程ある。
会社登記だとか口座開設とかの手続きはトールに任せるとして、俺は実作業の準備だ。
とりあえず、過去に使っていたプロジェクトマネジメントの管理資料をフォーマットの見直しをする。
インプットしなければいけないデータとアウトプットの形式の可視性を高める。
巴さんに頼んで、巴さんの会社のPA会報告書のフォーマットを確認する。
で、元データから報告書への転記を自動化しとく。
たぶん、各社のフォーマットはバラバラだろうけれど、管理項目は似たりよったりだろうから、基礎データだけは俺たちの会社のものにしといたほうが良いだろう。
あとは、そのデータを入力するフォーマットづくり。
メンバーの稼働工数。
バグ報告。
バグの分類。
メンバーごとのバグ傾向。
バグの発生率の範囲規定。
作成されたプログラムのステップ数カウントは既存ツールを使うとして、稼働工数に対して、メンバー別の生産性の確認。
やれやれ数字をまとめるだけでも一苦労だ。
バグの評価
地味にこの範囲規定ってのが難しいんだけれど、とりあえず俺の今の会社のをパクる。
あんまり知られていないけれど、バグってのは多すぎてもダメだし、低すぎてもダメなんだ。
バグが低いならいいじゃんかって？
それがダメなのよ。
なぜって？それはテストでバグを見つけられていないって判断になるからなんだよね。
特にメンバーごとのバグ傾向が極端に変わった時は要注意だ。
それが携わる機能が簡単になったからなのか？
それともテスト項目が少ないのか？
もしかしたらテストサボってないか？
そういう分析をするわけだ。
特にバグの分類が「単純ミス」になった時はやばい。
要するになんでミスしたか本人にわかってないってことだからな。
そういう時は本人にヒアリングして、ホントの原因ってのを一緒に考えることになる。
メンバーにとっては、ネチネチと自分のミスを掘り返されることになるから不快極まりない。
こりゃあ、新人プロジェクトマネージャにとっては、通過儀礼みたいなもんだとは思うんだけれど、その辺りをうまい具合にPMOである俺たちが分散させるってわけだ。
顧客報告
あとは顧客への報告。
これはPA会フォーマットとは別に作ることになる。
PA会フォーマットだと細かすぎるからな。
どっちかと言えば、PA会資料のサマリを作るイメージ。
ここの自動化は難しいんだよな。
基本データ部分はなんとかなるけれど、文章部分はどうしても「言い訳」を考えないといけない。
社内での対策の実態を共有していても、それをそのまま顧客に伝えても納得してもらえないことのほうが多いからな。
なので、簡潔にまとめつつ、共有しておかないといけない項目を説明する資料が別に必要になる。
管理という作業
こうして整理してみると管理作業ってめちゃくちゃつまんないんだよな。
基本が「悪いところを見つける作業」なんだもんよ。
いや、その上でどうするかという事を考えるって前を向ける部分はあるよ。
でも、その前段階で、どうしてもメンバーのミスと話し合う必要が出てくる。
このミスと向き合うってのが結構精神的に来るもんなんだよな。
ミスした本人もそれを指摘するマネージャーも。
なので「単純ミス」という分類にしないようにメンバーに伝えるわけだ。
単純ミスってなると、本人としてもなんで間違ったかってのがわかってない状態だから、プロジェクトマネージャーとその理由ってのを詰めないとならない。
だって、PA会で絶対に突っ込まれるやつだからな。
これがマジできつい。
メンバーもプロジェクトマネージャーも。
理屈をこねくり回してPA会を通すわけだけれど、その先の顧客説明のときに、単純ミスをしたメンバーを変えろとか言われちまう。
当然メンバーを変えると、それまでの経緯とかの引き継ぎだとか余計な工数がかかる。
なので、単純ミス撲滅を目指して、コミュニケーションが重ねられる。
やれやれ。
それに加えて、経営関連の手続きもやってかないと行けないわけだ。
シンプルに考えて、ヒトが足りないわけだけれど、当然それは当社売上が上がることを意味する。
巴さんのところで、それを受け止めるってのは現実問題難しいだろう。
当面はトールに手続き関連を任せて、俺が実務に注力するしかないか。
とほほ、ミスできないじゃん。俺。
そんな計画づくりで、俺の年休は消化されていった。