属人性排除の功罪
ソフトウェアの開発においては長年、属人性の排除が叫ばれてきました。今回は属人性の功罪について考えてみます。
属人性の排除の目的
- 定められた成果物を作成することにより、他の人にも理解しやすいようにすること
- 誰が担当しても一定の品質を保つことを可能にすること
- 成果物が一定の形を為しているため工程管理しやすい
だいたいこんな感じだと思います。私もメーカ時代には規約を作成したり、成果物の設計をしたりしていました。まぁその時は当たり前に良いことだと思って取り組んでいたわけですが・・・
属人性の排除によるデメリット
どういうことかというと、こういった属人性の排除を行うには、規約を決めたりするなどの制約を課すことになります。重要なのはその基準は、出来ない人に合わせることになります。したがって、一定の製品品質は保たれるけれども、コード品質は圧倒的に下がります。そしてそのコードは、ほぼ書き換えられることはありません。さらに長年使用することで、コード品質はさらに下がっていきます。これはプロジェクトに出来る人が投入されたとしても、制約により修正を禁止されてしまうためです。コード品質は低きにしか流れません。みなさんの中にも経験のある方は多いと思います。コードを見ても同じようなコードですから勉強になるわけでもなく、正しく書けているかどうかくらいしかチェックしないので、優秀な人材がもっと良いところへ移っていくのもわかると思います。
なぜこのようなことになるのか考えると、コードに対する考え方が大きいのではないかと考えます。つまり属人性を排除するという目的には、作成されたコードは「資産」である。という考え方があるのではないでしょうか。資産だから使いまわす。改良して騙し騙し使う。ということになります。ところが、実際にはコードの品質は落ちていくので、これを資産と言うのは無理があり、むしろ不良資産となっています。
属人性を認めるとどうなるか？
では逆に属人性を認めるとどうなるでしょうか。
- 優秀な人材は自分の腕試しでチャレンジできる
- プログラマの生産性に個人能力が大きく依存する
前者は良いことですが、後者は微妙です。個人能力に依存しすぎると特定の人材に頼ることになってしまいます。ところが属人性を認めると言うことはおそらく、特定の人材に頼ることが必ずしも悪いことではない場合があります。
前回のエントリで書いたように、組込み技術からモバイル技術に移ることで開発スタイルが変わってきます。3年でコードを捨てるような開発を考えると、コードは資産にはなりません。リリースした瞬間からコードは「不良資産」ということになります。優秀なプログラマであれば、改善はもとより、更に良いコードを書くことが可能です。新規にコードを書くことで個人能力も上がります。レビューシステムなどを併用することで、より良いコードを見ることが出来るようになり、周辺の人の能力を引き上げるようにします。この全体の底上げを行わないと特定の人に集中しすぎて失敗してしまいます。そして、そういった人材が離れないように企業側が良い環境を提供する。というのが属人性を認めた場合の開発になります。実際に今伸びている企業が行なっているのがこの施策です。
まとめ
メーカなどの製造業の多くは、ソフトウェアの開発の生産性を上げるという目的のために属人性の排除という施策を行なってきました。ところがその施策は行き過ぎてしまい、社内のエンジニアのスキルが上がらないという結果をもたらしてしまっています。そのため企画だけ作って外注に丸投げし、さらには自分たちもよくわかっていない成果物の作成を強いるという状況になっています。
そろそろプログラマをハードウェア製品の構成部品と考えることを止め、優秀な人材を確保するべく技術戦略を作成して実行することが必要です。ソフトウェア開発は属人性が発揮されるクリエイティブな業種です。ハードウェアと同じように扱うのは時代遅れと言わざるを得ません。特にこれからのモバイル技術では、体験的に他と違うこと。品質よりもクリエイティブであることが求められています。
