スキルの低い人が生産性における問題ならその人を何とかするのが根本解決だよねと話したら、人に強要することなんてできないじゃないですかーという反応をいただいた。
これはすごく的を射たもので、チームを引っ張ってモノづくりをするうえで・チームを引っ張らせてモノづくりをするうえで重要な着眼点になると思っている。 個人の尊厳や主体性は最大限尊重すべきだし、様々な発想を持ち込めること（多様性）こそがチーム結成の価値の1つでもある。もしも開発プロセスやそのツールをガチガチに固めてしまうことで自由なチャレンジができなくなるのだとしたら、それは価値ある生産物を主体的・継続的に提供する能力の低下につながるだろう。そもそも変わりゆく環境の中で、1つのプロセスがずっと最適である保証も無いのだ。
では、どうするべきなのか。基本的には以下の原則を守ることだと思っている。
- チーム全員が同じ方向を向こうとすること
- 気づきの機会を提供すること
- 多様性を活かした事前確認・反省をすること
マネジメント層・リーダー層が注力すべきは1。どのような価値をユーザに届けたいのか、その速度・量・質はどの程度なのか、きちんとビジョンを提示しないとチームはまとまることができない。方向さえ合っていれば、それぞれが全く異なる主義を持ったり発想を展開したりしても互いに助けあうことができるし、最終成果物が価値を届けるものであることも揺らがないだろう。
2もまた重要で、これこそが私が静的解析ツールに注力している理由。スキル差*1があることやうっかりミスがあること*2は前提として考え、モノが形になる前に「要求レベルに満たないものを検知し、要求レベルに引き上げる」仕組みを整えてやる必要がある。
例えば今実装しているfindbugs-slf4jは、SLF4Jの恩恵を最大限得るために必要な知識を補完する。デプロイ前に「ちょっと待った、そこはこう直した方がいい」と呼びかける機会を、自動化という効率のよい手法で提供することができるのだ。
「ルール強要」でなく「気づきの機会の提供」であることもまた重要で、そのためにはツールが上げるレポートを重視したいという意識・文化を作る必要もある。ここはリーダーの振る舞いも重要になるだろう。
最後に3。これは上下関係とは関係なく、各メンバーの専門性・特殊性を正しく理解して頼ってしまうことだ。新人でもコーディングにセンスがあるならばレビューする側にまわればいいし、それによって非リーダー層にもより強い主体性が芽生えることもある。 もちろん可能であれば、各個人の専門性（経験・知識）をシステムで自動化してしまい2.に組み込む方が良い。人の手間が減らせるのはメリットが非常に大きく、個人の成長を超えたチームとしての蓄積になる。ただ経験のシステム化は静的解析ツールにしろシェルコマンド（grep, awk etc.）にしろコストが高く、判断が難しい。
もちろんこれらにはデメリットもある。人力に頼る面が大きいこととプロセス内のステップが増えることがその筆頭である。これによるスピードの低下は品質やチーム戦力の向上を考えると充分に見合うのではないかというのが今の考えであるが、今後変わっていくかもしれない。
