最近いくつかのプロジェクトで同じことが起きてます。
「何か問題があると個人の問題にする」という現象です。
「個人の問題」
例えば品質問題。
ある個人のコードの質が悪かったんです。たまたま結合試験で気づきました。試験担当者がたまたまコードを見ながら試験したから気がついたんです。
「あいつの書くコードはちょっとなぁ…」という意見が複数出ました。
例えば生産性。（生産性って言葉はあまり好きじゃないのですが、プロジェクトではこの言葉を使っていました。技術力と同じような意味なんですが）
ある個人のスキルがあまり高くなく、コードを書くのに時間が掛かります。システム開発の経験も少ないのでプログラム言語、業務仕様の理解も他のメンバーより時間が掛かります。
チームとしても顧客の求める計画を達成できていませんでした。
「あいつがチームの生産性を落としてるから計画通り進んでないんだ」とマネージャーは言いました。
本当に悪いのは何か？
個人が本当に悪いのでしょうか。
確かにスキル不足は否めませんが、チーム全員がプロフェッショナルであれば問題は出なかったのでしょうか。
1つ目の問題（結合試験でコードの不備が見つかる）では以下のような問題がチームにあったのではなかったでしょうか。
- なぜコードレビューで見つからなかったのか
- なぜ単体テストで見つからなかったのか
- スキルが低いとわかってるはずなのになぜ放置しているのか
２つ目の問題（生産性の低い個人）ではそもそも個人の問題でありませんでした。
- スキル不足の本人はドキュメンテーションや試験などの作業でプロジェクトに貢献していた
- ちゃんと計測してみると、そもそもチーム全体としての生産性は悪くなかった
- 技術的課題、手戻りなどのリスクを無視した計画となっていた
サッカーに例えると
このような状況をサッカーに例えてみると、
- あるディフェンダーはフォワードに抜かれて点を取られるシーンが多い
- あるフォワードはボールを取られるシーンが多い
という目立ちやすい問題をみて、
「あのディフェンダーは簡単に抜かれるからダメ」とか「簡単にボールを取られるフォワードは役に立たない」というのと同じです。
表面的な問題から安易な答えを出さないこと
「フォワードに抜かれて点を取られる」という状況を考えるのが大事です。
そもそもフォワードと1対1になっているのは守備戦略の上ではあってはならないことでしょうし、フォワードが簡単にボールを取られるのは味方から孤立していて何もできない状態なのかもしれません。
表面的な好ましくない現象から安易な原因を求めるのは危険です。
「質の悪いなぜなぜ分析」の分析結果が個人攻撃になってしまうことが多くあるように、「なんとなく」で原因を考えると個人のせいになってしまいます。
僕がみたいくつかのプロジェクトでも本当の原因は個人ではなかったように思えます。
プロセス、システムは機能してるか
じゃあ何なのか、というとプロセスやシステムがうまくいっていませんでした。
個人のイマイチなコードが気づかれずに残っているのは、明らかにコードレビューが機能していないんです。
「コードレビューを必ずする」という（当たり前の）開発プロセスのもと、Gerritというツールでコードレビューを運用していたんですが、これがちゃんと機能してなかった。
"レビューツール（Gerrit）に慣れていない"、とか"忙しくて細かくレビューしていない"のような他の問題/原因がありました。
また生産性の話も、チーム全体の生産性は当初計画を上回るものでした。ただ計画に余裕がなくリスクが顕在化した時にリカバリーする動きが管理層でとれませんでした。
"リスクはなく開発を予定している機能は計画した生産性で完了する"というプロジェクト計画となっていました。
個人の生産性問題はわかりやすい形で表面化していただけで問題の本質ではありませんでした。
組織やチーム全体の問題としてとらえる
サッカーチームが負けるのはディフェンダー一人の問題でしょうか。点が取れないのはフォワードのせいでしょうか。
その前にチームのリスク管理や点を取る戦略が欠けてないでしょうか。
と、昨日の「今日は本当に申し訳ない。僕は、その一言しか言うことがない。次で取り返したい。自分の判断ミス、普通にクリアしていれば…」というFC東京の森重選手の言葉を聞いてこんなことを考えたのでした。
個人のミスはしゃーない。その個人のミスをチームとしてどうマネージメントしているかが大事なんじゃないでしょうか。
