「曖昧性とのたたかい~体験的プロジェクトマネジメント論」を読んだ雑記
システムビジネスの特徴を挙げるとすれば、次の3つではないかと考えている。その3つとは、曖昧性、変動性、膨張性である
名内泰藏. 曖昧性とのたたかい (Japanese Edition) (p. 23). Kindle Edition.
見積もりについての曖昧さ
見積もりと向き合う
見積りは必ずしも見通しが立っていない未来を予測し、あたかも確定しているがごとく未来を表現しなければならない業務である。したがって、見積りには想像力、創造力、勘といったあらゆる知的能力が要求される。
名内泰藏. 曖昧性とのたたかい (Japanese Edition) (p. 40). Kindle Edition.
見積もりの難しさを日々感じます。自分が見積もったフェーズが見積もり通りに進行したのが何回あっただろうか？そもそもあったっけ？
本のタイトルにもある「曖昧性」というのは非常に厄介で、向き合う事を敬遠したくなる。どこまで突き詰めても答えが出なさそうに見えるので、一定のところで折り合いを付けようと思い結果ずさんな見積もりが生まれる事がある。
まさに「曖昧性とのたたかい」であり、時間が許す限り考え尽くす必要がある。見積もりを行う時間が巻いて終わるなんて事はきっと無い。
見積もりという名の防御
見積もりを行った時に、見積もりの根拠となる情報もそこに付しておく。見積もり段階でのタスクの内訳を記録することで、追加となったり変更となったりしたものを洗い出せる様にしておく。また、根拠がなければ見積もりを変更するのも容易でなくなる。
詳細すぎる見積もりは見づらいが、内容が不足している見積もりよりは良い。
見積もりを振り返る
「見積もり精度を上げるためには振り返りを行おう」という言葉をこれまでにも聞いた事がある。この本にも書いてあった。自分個人が取り組んだタスクに対しては常日頃、想定外に時間を要したタスクがあれば原因が何だったか考えることがある。
かたやフェーズ単位の見積もりについてはどうだろう？と思いを巡らせてみると、一見問題無い様にも思える。なんだかんだで、最近納期を大幅に遅れる様なことはなかったし、多少の遅れはあっても予定の日付に検収できないような自体もなかった。
しかし、実際は残業をしたり、休日たまにコソコソと勉強をしたりしてたような。思い返せば「見積もりの能力」ではなく「決めた見積もりに間に合わせる能力」のほうが上がってきている気がする。
どちらの力もきっと大事だが、「決めた見積もり間に合わせる能力」が育ちすぎると「見積もり能力」は「問題なし」と勘違いして伸びづらい気がする。また、他のメンバーとの見積もり時間の差が生まれやすく望ましくない労働環境が生じやすい。PJとして成功したから、納期に間に合ったからといって「見積もりは正しくできていた」とは言えない。
「走りながら考えよう」という発想は甘すぎる。「走りながら」というのは単なる「問題点の先送り」にすぎない。やってみなければわからないことが多くても、最初に全貌を考えぬく積りで極力詳細な工程を設計すべきである。
名内泰藏. 曖昧性とのたたかい (Japanese Edition) (p. 91). Kindle Edition.
見積もりの曖昧性と向き合い考え抜いて、差異を少しずつ埋める。テクニック以前に考え方の問題があることがわかりました。
プロジェクト進捗管理における曖昧さ
進捗管理をする目的は何でしょう。
計画と実行の差を明確化することに主眼を置かなければならない。すなわち、遅れを遅れとして正しく認識できることが大事なのであり、これはプロジェクトマネジメントの大前提である。
名内泰藏. 曖昧性とのたたかい (Japanese Edition) (p. 138). Kindle Edition.
進捗を聞く時、できたら良い進捗を聞きたいものです。順調に進んでいたり、巻いて終わってたり。人間、自分を辛い状態に置きたくない、現実から目を背けたい時があります。進捗管理MTGでは様々なバイアスが渦巻いており、誤解を恐れず言うとなかなか信用できない情報が行き交う場になりがちだと思ってます。
定量的に進捗を見る
PM「タスクどうですか？」
メンバー「進捗良い感じです。予定通りに終わると思います」
PM「いいね、次の人〜」
上記の様な会話だと、実際どこまで終わってて何が終わってるかわからないですね。これは極端な例ですが、進捗は実際の結果を見せてもらう事で進捗状況の把握度の不一致が軽減されるといいます。
進捗報告では「責任追及より実態把握を重視せよ」と本では述べられています。「正直な報告をしたけっかガミガミ言うとギリギリまで実態を隠す様にする」人が増えるのはなるべく避けたいです。「なんで〜〜しなかったの？」とか終わった話にすぐ触れて責任追及の様な姿勢に見えてしまうと正しい報告を受けられなくなる可能性があります。同じ視点からのアドバイスや励ましで以て次のアクションを考えましょう。正しい報告が得られない進捗確認MTGでは、問題点を明らかにできない大問題を準備しているMTGに成り下がってしまいます。
「書き直しすれば工程常にオンスケ」
当たり前ですが、線表は書き直せばオンスケになります。結果、正常性バイアスに囚われてバッファを食いつぶしていったり、お客さんは進行に滞りが無いと勘違いしてカジュアルに仕様変更や追加実装を振ってきたりします。スケジュールには極限まで手を入れない。
悪い報告がタイムリーになされないのは部下の躾の悪さより、報告を受けたときのマネジャーの対応に大半の非があると考えて間違いない。
本の中では、メンバーから報告を受けた時に適切なアドバイスを伝えるのが大事だが、できなければ激励をするのも大事だと述べられていました。励ましたり、応援することも相手と同じ方向を向いてるからできる行為で、重要なフィードバックの一つだと思います。
