今日も読んでいく「リーン開発の現場」。
根本原因
5章と6章を読んだのですが、特に6章が印象に残りました。
ほとんどの場合、「一生懸命働いていない」というのは、問題の根本原因ではないので、「一生懸命働く」を選択するより、ほかの4つのアクションのどれかを選んだ方がいい。むしろ一生懸命働きすぎていたり、考える時間がなかったりするのが、根本原因だったりするんだ。
私は社畜なので何も言えません。
情報の共有と可視化
5章6章に限らず、ここまで読んで思ったのは「情報の共有」と「情報の可視化」を徹底的に行っているということです。
プロジェクトマネージャーにとって、この辺りはやはり基礎であり奥義であるという感じなのでしょうかね。
情報の可視化ではどんな些細なことも文章にしています。「メンバーの考えていること」と、「プロジェクトの進捗」が主でしょうか。
- チームメンバーは何を考えているのか
- 自分は何を考えなければいけないのか
ゴールと現実のギャップ埋めの一つとして、「このプロジェクトはいけると思うか？」みたいなことまでメンバに投票させて公開してるんですよね。
私の所属するプロジェクトは「死んでもやるしかない」って感じなのでこんなこと言える環境が羨ましすぎる。そんな雰囲気なプロジェクトのためか、
チームがゴールを理解していないか、ゴールを達成できると信じられないのであれば、無意識にビジネス目標から自分たちを切り離し、「楽しくコーディングしよう」とか「自分の担当のみ終わらせて家に帰ろう」のような個人的なゴールに集中してしまう。
という一文に心当たりがありすぎます。
明日はどっちだ
他にも、ゴールに集中させるために進捗的なことを可視化・共有しています。
- プロジェクト全体の道のりはどのくらいあるのか
- 今、自分がどこにいるのか
- みんなはどこにいるのか
ゴールが見えないマラソンは辛いですからね。
ぼやけたゴールの害
私も「ふとした瞬間にプロジェクトの進捗に疑問を持つ」ことに心当たりがあります。
- このプロジェクトは大丈夫なのか
- 先週に言われた期限までに果たして終わるのだろうか
- 危ない気がするぞ。ほかのメンバーの進捗もよくわからないし
こういう不安はだいたい当たり、数日後にリーダーが「プロジェクトのスケジュールが危ないので”ほげほげ”します」という決定を教えてくれます。
それまでにチームメンバー間で情報共有をしてはいるのですが、あまりコラボレーション的なことはしません。各人に割り当てられたタスクは各人でやる。アドバイス程度はありますけど。この割り当てられるタスクの粒度が結構大きいので、そのせいでほかの人が手伝うのが難しいのかな、とも思いました。
あと、そもそもプログラマがプロジェクトに口を出せないのもありますね。考えれば考えるほど、自分の所属するチームとこの書籍のチームの文化が違産んだなと実感します。
