June 14, 2008
まず大前提として、その仕事が有能であろうがそうでなかろうが、属人性の高い仕事ってのは廃されるべきですよね。まぁ有能ならスルーしてても利益になればラッキーですが、逆に損失に繋がるなら嫌ですよね。
つまり属人性が高いことは基本的にリスクであって、その結果もたらされるメリットがあればラッキーというレベルなので、結局、成果に応じてケースバイケースなので、ルールとしては廃したいところですよね。
研究職なら良いんですが、それ以外の人だと、せいぜい20%ルールとか、お給料を出すカイゼン活動ぐらいで力を発揮して欲しいところですよね。
それに、人がいなくなっても企業には責任は残りますから、あなた死んだらどうなるんですか？明日失踪したらどうなるんですか？というリスクを管理しなきゃいけませんから、リスクは前向きに楽しむものですが、やっぱり儲かる形にするところまでは、本人がんばれって話ですよね。（つまり企業内なら役職者になって組織化するところまでもっていくべき）
話し合いの中で、私が言ったのは、できる開発者が力を発揮できるように、体力勝負になってしまうような縛りはなくして欲しいということ。
そうするとデータの人は言うわけです。すごいコードと、そうでないコードが入り混じると保守がしにくくなる。
全員のコードを同じような感じ(レベル)にするのって、実際は不可能だから、そんなこと気にして、できる人の力をそぐのはもったいないよと私は言いました。
「できる人に関しては、それはそうだね」とこの件はデータの人も納得してくれましたが、「でもできない人はとんでもないコードを書くから、それに対しては縛りを入れる必要がある。」と、またデータの人は言います。
ここから先は、できない人のコードを如何に是正するか？という話になってるけど、そもそも前提条件がおかしくないですか？
それはここ。
「そうするとデータの人は言うわけです。すごいコードと、そうでないコードが入り混じると保守がしにくくなる。」
ここを解決しないと、こんな話先に進まないですよ。
だって、
「すごいコードは、うちの仕事にはリスクの高いコードなので、そういう仕事はうちのビジネスでは不要」
って言ってるんですよ。
すごいコードを書ける人なのにおかしいじゃないですか。
つまり「すごいコード」という言葉は、「能力は高いことは認めるが、なんか非コミュっぽいソースコードでさ、何書いてんのかわかんねぇんだよ」として揶揄する発言なわけですよね。そこが改善できなければ、上にあわせようなんて絶対にしないですよ。
大事なのは認めあえる関係を作ることじゃないですかね。
「すごいコード」が属人的な能力に依存してしまうなら、どう考えても解決すべきは、
「能力の高い人が保守性の高いコードを書き」
かつ
「能力がそうでもない人にスキルや意識を伝搬させるようにし、コードのルールや開発プロセスをできるだけ向上するように最適化し」
かつ
「そういうことが、プログラムを書かない人にも認められること」
の環境作りに力を注ぐべきなんじゃないですか？
このエントリーだけしか見ていないので間違っている可能性は高いですが、ひがさんが書かれていることは全体的な絶対値のボトムアップ方向にだけ傾倒しているように見えました。
ここで言う「すごいコードを書く人」のビジネス面でのスキルアップも絶対に必要だと思います。
（とはいえ、コードレビューすれば、お互いコミュニケーションするので結果的に歩み寄れる可能性はあるので、やることについては賛成ですが、スキルの高い人を軸に置いて全員を上方向に上げるべし、という前提だと失敗すると思います。）
そうすると結局、有能な開発者は部下を始動できる立場＝管理職になれって話なんですよね。そうすると現場から離れてしまう組織構造であればアーキテクトとかラインから独立した実装側のリーダーということになるんでしょうなー。
（しかし、この職はきっとコミュニケーション能力や積極性が一番求められるハズ。何故かというとラインから独立してるから。）
しかし、名選手名監督ならず、というのはノウハウが属人的でスケールしないってことだから、やっぱりバトンを繋いでいくことで多くの人を支える大企業には馴染まないとしか思えないんですが。
きっと重宝されるのは、名選手まではいかなくても名監督になれる人だと思います。そういう人が、名選手とうまくやっていければ、若手選手にも伝搬していけると思うんですけどね。
そんな人は沢山いそうなのになぁ。それをできないようにしている意識なのか組織なのか、その辺はなにかあるのだろうか。やっぱり、適切なコードを作りだす文化が、作る側と作らせる側の間にできていないってのが原因なのかなー。
とりあえずソフトウエアは作業プロセスが可視化されにくいので、他のものづくりの仕事よりも教える機会が少ないというのはあるような気がします。例えば機械を作る作業なら作ってるそばから異音が出たり、仕上がりが一目でわかるので、マニュアルではフォローしきれない細かいノウハウの伝承がその場でできるわけです。コードレビューとかバグ報告などの後追いじゃタイミングを逸してることも多いですしね。そういう意味で人材育成が難しい仕事だとは思います。
くだんの「対決」に参加していたのですが、誤解があるようなので修正させてください。
「すごいコードと、そうでないコードが入り混じると保守がしにくくなる。」が正しく意図が伝わらなかったので、「できない人はとんでもないコードを書くから、それに対しては縛りを入れる必要がある。」と訂正したのです。
「対決」はICレコーダーで録ってあるので、記憶ではなく、いずれきちんと報告できると思います。
matobaaさん！レスありがとうございます。
ネットなので、こちらの読解力不足もあり、いろんな誤解を含んでしまうかもなぁとは思いつつ書かせてもらいました。
もし公開されたら是非聞かせて(or 読ませて?）いただきます！。
僕の視点は、SIerさんが云々というよりはエンジニア組織論みたいなところだったりします。
最近、いろんな本を読んでると、社員は少ないに越したことがない。むしろ育てるなら、ちょっと少ないと思うぐらいが良いなんて話があって、なるほどなーと思っているところです。
そういう意味では大企業として経営していかなければいけないSIerのビジネスってなんか難しそうだなぁなんて思ってるところです。
（いくら案件規模が大きくても、個別案件をこなすのって、いわゆる大企業のモデルじゃないですよね。。。大量生産、規模の経済を追及するからこそ大企業なわけだし。その辺が人月に捕らえられてるのが問題なのかな。）