読者です 読者をやめる 読者になる 読者になる

PMが知っておくべき稼働を上げて対応は麻薬と同じだという事実

システム

 

稼働を上げて対応は麻薬

下の図はシンプルに稼働人日と欠勤をチャート化したものです。(実測値)

平穏だと欠勤は2%~3%くらいで月に1回休むかどうか程度で、概ねスケジュールに問題が発生しない状態になります。

4月と9月には大量アサインがありましたが、6月は追加要員がありませんでした

稼働量推移

f:id:kitahashi-ryoichi:20150911020406p:plain

※9月途中なので9月1週目終了時点での欠勤率です

欠勤率推移

f:id:kitahashi-ryoichi:20150911020359p:plain

 欠勤率のチャートを見れば麻薬の効果は明らかで、4月増員したことで生産力が向上したため負荷が分散されて体調不良は目に見えて低下、しかしその後順調に仕事量は増えてゆき(シナリオテストの戻り修正等で)5月GWがあったのに欠勤率が高止まりしてます。

 

なぜならGWももちろん働いているからだし、土日の工数がこのグラフに出てきてないですが、土日どっちかは自宅で作業している感じになっています。稼働が限界に近づくと欠勤率が直接上がって結局トータルの生産性が上がっていないことが言えます。

麻薬ゼッタイダメ

 

 

稼働を上げずにトータルの生産量を増やすには?

「集中」とか言いません。別に集中力が悪いから生産性が悪いことなんて滅多にないからです。そもそもPMが個々人の生産性に依存した時点である意味終わっているし、組織とかチームとしても終わっていると思います。

 

最も早くて確実に作れるのは知っている仕事です。

逆に、最もスケジュールがあやふやで遅くなるのはだれもやったことがない仕事です。

1人で完結しない仕事で一番やっかいなのが、お客様がよくわかっていないし、自分もやったことがない仕事とかです。調べて、分かりやすい資料に落とし込んで説明して、お客様と握って、実装して、テストして、全然1周間なんかで終わるイメージが湧きません。こんなのがガシガシ差し込まれて崩壊が始まっていないでしょうか。

 

知っている仕事をとにかく増やす。

個人とチームの両方に、SlackやChatworkやWikiのような仕組みを使って形式知を拡散すること。だれかに負荷が集中することを避け、本当にその人だけが出来る仕事に集中させる体制を取ることで総生産量を高めます。

 

難問を小分けにして解決する

問題解決の方法論として解決できる小さい単位の問題に切り分けて優先順位で対応するものすごい基本的なことです。頭を抱える前に書きだして小分けにして分からないことを整理するという本当に基本的なこと。ただ、こういう問題解決の方法論をSIerの新卒エンジニアが勉強するには自分で本を買ったりしないと知らないわけで、そういう人のメンターを買って出るのも一つの手であります。

 

ゴール感を明確にしてから調べる

お客様分かってない系の調査は事前にニーズ、守るべき価値観の目線を合わせてからゴール感というか着地をイメージして調査しないとふわふわして仕事量が増えがちです。MECEにやり過ぎてもただ無駄工数を積み上げてしまうだけというのはよくある話です。時にはAとBとそれ以外ぐらいざっくりなMECEで判断出来る時もあります。

 

つまり、リーダー陣はゴール感の認識を常に共有しておく必要があります。どうでも良い進捗とかTODOの共有なんかより、ゴール感や意思決定の判断基準を常に共有し続けることのほうが優先度高です。

 

 

逆に稼働を上げたいワーカホリックもいる

別に土日やることがない独身男性で、仕事が好きなやつとかは稼働をあげたいと思っていたりします。仕事にものすごいやりがいを持ち、ビジョンとマッチ度が高い若手を見つけてほど良い高稼働にするのは歓迎。ある意味麻薬なので好んで仕事中毒になってしまうかも。一方で、子供と会えないくらい終電まで働かせて、土日も働いてというのは人間の所業ではない!!

 

 

かんたんに出来る稼働をすぐに上げてしまうのは崩壊のはじまり

自分への戒め