『倒れない計画術』を読んだ
自分は基本的に任せる系のマネジメントをすることが多くて、うまくいくかいかないかはやっている本人にまかせているんだけど（失敗を本人が学び次の効率を自分で上げてほしいので）、マネジメントサイドで3年間大小様々なプロジェクトを見てきて「あれ」って思う場面もたくさんあって、どうしようもない場合には、しょうがないのでマイクロマネジメントに移行するんだけど、それらが起こらないようにするにはどうしたらいいんだろう？って考えをめぐらせることが多かったので、その整理になるかなと思って、ちょっとありきたりそうな自己啓発本をKindleで買って読んでみた。もちろん、自分自身も全然至らない点が多いので、それを補強するためでもある。
※記事の下に開発でありがちな炎上についても考察追加してます。
(noteのURLの展開良い)
計画錯誤
面白かったのが以下、
研究者は、論文を書いている学生たちに「いつごろ書き終わるか？」と聞き、最短のケースと最長のケースを予測させました。そのとき学生たちが予測した最短日数の平均は27日、最長日数は49日。ところが、実際に論文が書き終わるまでにかかった日数は平均56日だったのです。最短のケースの日数で書き終えた学生はほんの一握りで、最長のケースと予測した日数で書き上げた学生は、半分もいませんでした。
つまりは大抵の人が「これくらいかかったら最悪だわ」って思っていた見積りよりも更に悪い結果でフィニッシュするということ。個人的なサンプリングでもそんな気がします。
もちろんベテランのエンジニアなら、こういう現象を経験則で回避できるとは思うんですが、失敗経験を蓄積できない人だったり、はじめてのことをやる場合はこういう現象が起こりがちな気がします。
本での解決策は、
・自分をよく知る他人に見積もってもらう（アジャイルだと複数人でやるプランニングポーカーとかですね）
・最低2週間は自分の作業をすべて時間計測してみる（結局は経験を溜める、慣れる）
ということでした。
実際にやってみる
自分の作業の記録と測定の方をやってみます。
自分は最近10年くらい使ったiPhoneからPixel3に乗り換えたので、Androidアプリの紹介になってしまうのですが、Sectographを紹介します。
結局このアプリのバックエンドがGoogle Calendar（以下グーカレ）なのですが、グーカレだけを使うよりも良いのは、見慣れた丸いアナログ時計のアナロジーで時間を俯瞰できるのと、予定を選択することで残り時間が見れることです。
しばらくはこれに乗っかってみます。
MACの原則
目標を設定するときに、以下の3に気をつけた方がいいという話のようです。
1. 計測可能(Measurable)
2. 実行可能(Actionable)
3. やることで満足・充足するか？(Competent)
1はまあそうだねって感じなのですが、2をすっぽ抜かすこと多いなと。達成までのアクションを実際に概要でもいいから引っ張ってないと、そもそもちゃんと見積もれない。初期の会社ほど多そう。2が抜けている状態で、上から1としての納期だけ決定しているプロジェクト、結構突っ込んできた。
3も重要で、「僕らってその目標を達成したいんだっけ？」って擦り合ってないと、ずっと不幸。
実践という意味だと、グーカレに登録時にもっと細分化した文章で書く。大きなプロジェクトの場合は、目標達成までの流れをメンバーにイメージできるように落とし込む、ちゃんとメンバー自身のやりたいことやキャリアに沿っているのかをすり合わせるってことが重要そうです。
計画が失敗したときにどうするかをあらかじめ考えておく
if-thenという「○○のときに○○する」をできるだけ列挙しておく、そして一番最悪のケースが来たらどう対処するかをあらかじめ計画しておくって部分がすごい共感できるなぁと思いました。
当然今までの過去を思い出しても、計画通りに全部できるならこういう本を読む必要はないわけでｗ
なので、計画がだめになったときに動きの代案をもっと事前に考えておくべきなんだと思う。
炎上について
別にこの本の内容じゃないのですが、開発だと計画の失敗ってこの話に直結するので考察したいと思う。
炎上とかは炎上することが実は計画時に（神的な視点では）決まっていて、つまり炎上するような計画をしていた＝失敗だと思うんですよね。失敗することを想定していない計画を計画していた。で、僕は失敗でいいと思ってる。
その失敗をできるだけ失敗にしないように刹那的な長時間労働で頑張るんじゃなくて、「あ、ごめん、失敗だった」と関係者に普通に説明して（だって失敗は誰でもするので）、その上で「失敗を活かした」現実的な線を引けるといいんだと思う。
失敗を活かすってのは、当然だけど「失敗する計画を立てたときと同じ頭ではだめ」なわけで、炎上ししていることは一切忘れて余裕を持って失敗を分析して、アップデートされた頭でもう一度冷静に計画をやり直した方がいい。場つなぎ的な延長は、その後の度重なる延長を起こしかねない。
で、最後ちゃんとリリースすれば失敗じゃないので。諦めたらなんとかですね。
現実的な線を引き直せない状況だと以下のツイートみたいにリリース後の不具合も増える。Five Core Metricsって本に書いてるみたいなので、読んでみたい（買った）。
まとめ
他のも4,5個原則があるのですが、それは本書で見てください。自分は結構取り込めそうな気がしているので満足度高かったです。
あ、ただ僕は本を読むときに著者の書いていてることを鵜呑みにすることは全くなく、「この人の言っていることが真実かはわからんけど、新しい視点で色々考察できる、嬉しい」という感じで読んでいることがほとんどなので、他の人が読んだらクソ本かもしれません。すいません。
あとどうでもいいけど、こういう自己啓発本は最初にシンプルで重要なことが書かれていて、ためになった感あるんだけど、後半に行くほど細かく複雑なことが書いてあって、「えーと、それ全部実践できると思って書いている？」って著者に思ったりする。結局は何個かの重要な原理を説いた後に、それを裏付ける系の話や、実践編、落穂拾いなど続いて、消化試合感出る。
もしかしたら複数に分ける前提で、一冊一原理くらいに収めて、めっちゃ短い文章にして、500円くらいでnoteで売った方が良さげ（もうやってる人たくさんいるか）。
まあ開発ならやっぱりこの本を熟読した方がいいですね。という締め。
この記事が気に入ったらサポートをしてみませんか？