自分戦略研究所 | 自分戦略研究室 | キャリア実現研究室 | スキル創造研究室 | コミュニティ活動支援室 | エンジニアライフ | ITトレメ | 転職サーチ | 派遣Plus |


外資系コンサルタントのつぶやき 第23回
プログラミングスキルをもっと評価すべき

三宅信光
2004/5/19

   プログラミングは新人の登竜門だが

 今回のお題はプログラミングです。といっても私はプログラミングの専門家ではありません。せいぜい下手の横好き程度で、実際は素人レベルといった方が正しいでしょう。ですから、ここでプログラミングのノウハウを論じるつもりはありません(できるわけでもありませんが)。私がお話ししたいのは、もっとプログラミングスキルを高く評価することはできないだろうか、ということです。

 私の会社では、プログラミングといえば、新人が行うべきものというイメージがあります。これは、新人が入社してくると、まずプログラミングをさせ、それによってシステムとはどんなものなのかを学んでもらい、その後さらに上流工程へ進んでいく、というキャリアモデル(というほどのものではないですが)があるからです。

 ある程度のトレーニングはプロジェクトに配属される前に受けますが、せいぜい1カ月くらいのもの。ですから、下手の横好きレベルの私から見ても、プロジェクトに配属されたころの彼らのスキルには疑問符が付きます。もちろん、学生時代からバリバリとプログラミングをしていた、あるいは特別に適性があって、あっという間に高いスキルを身に付けてしまう人もいますが、それは例外的な存在です。

   新人が先輩を仕切る場合も

 こうした素人新人プログラマ軍団を何人かの先輩が率いて開発に携わるのですが、この先輩たちも当然それほど長いプログラミング経験があるわけではありません。せいぜい3年間ぐらい、場合によっては新人の1つ上の世代が新人を指導、統率することが多いのです。もちろん、1年間とはいえ、実践で鍛えられているので侮ることはできません。トレーニングを受けた程度の新人とは比較にならない力を持っているわけですが、やはり経験不足のように思えます。

 そんな中に学生時代からかなり高度なプログラムを組んだ経験を持つ新人が配属されると、指導するはずの人間が逆に教えられてしまうこともままあります。実際にあったことですが、配属されて1カ月もたったころには、その新人が2年目の人間も含めて面倒を見るようになっていたこともありました。その新人、なかなか人が悪いところがあり、先輩に難しい宿題を出して困らせて喜んでいましたが……。

   本来のプログラミングのあり方

 本来、プログラミングは高度な知的作業であると私は思っています。ただ動けばいいレベルであれば、それほど難しくはないかもしれません。使うロジックはだいたい同じようなものですし、いまの高性能なマシンであればパフォーマンスにそれほど気を使わなくても何とかなるケースが多いのも事実です。しかし、それでよいのでしょうか。

 転職する前にいた会社で、私は会社のシステムを発注する立場にありました。その当時、付き合っていたベンダの中にとても優秀なプログラマのAさんがいました。Aさんと一緒に仕事をしていてとても楽しかった思い出があります。私のつたない仕様書を見て、さっとプログラムを組んでくれて、一度テストしてデバッグをするともうそれで実運用をしても障害が起きることはほとんどありませんでした。Aさんはプログラマという肩書きなどではなく、普段は上級SEとして仕事をされていました。ただ、たまに難しいプログラムがあると、「どれどれ」といった感じで乗り出す、そんな方でした。そのベンダとしてはAさんにマネジメントに加わってほしいと思っていたようですが、Aさん自身がプログラミングが好きだったのか、「マネジメントなんかやりたくない」と話してくれたのを覚えています。

 Aさんが組んだプログラムのソースをよく読ませてもらいました。COBOLで組まれていたそのソースは、まず何よりも読みやすい。コメントが入っており、どの処理が何を意味するか、きちんと分かるようになっていました。当たり前のようですが、意外と守られていないことです。

   プログラミング力でシステムが変わることも

  Aさんが作成したソースであれば、別の人間が後でメンテナンスするにも問題なくできると判断した記憶があります。当初はそのベンダのやり方なのかと思っていましたが、同じベンダのほかの人がプログラミングしたソースは、確かにコメントは入っていましたが、Aさんが組まれたソースコードのコメントの方が、入れ方が適切で、格段に読みやすいと感じました。

 さらに、パフォーマンスが良いのです。複雑なプログラムを2本お願いしたことがあり、時間の関係で1本はAさん、もう1本は別な方に組んでもらったことがありました。複雑さはAさんにお願いしたプログラムの方が難しかったのですが、出来上がりはAさんの方がはるかに早く、かつ、出来上がったプログラムの動きもAさんが作った方が軽快でした。そのことをAさんにいうと、「彼はまだ経験がないから、たぶんその辺が……」といいながら、ちょこちょことソースを変更してくれました。途端にそのプログラムの実行速度まで見違えるように早くなったことが、とても印象に残っています。

 Aさんに「どのくらいソースを書いているんですか?」と聞いたことがありました。「アッセンブラを使っていたころからだから、どのくらいになるのでしょうねぇ」と笑うばかりで、結局教えてもらえませんでした。が、その当時30代後半でしたから、10年以上はプログラムを組んできたんだと思います。

 いまの会社に入ってから、自分でプログラミングをする機会はありませんが、ほかの人が組んだプログラムなら、これまで何回か見たことがあります。Aさんが組んだプログラムに比べ、やはり品質がかなり落ちるのではないか、と思うことがよくあります。言語によって良いコードとされる書き方は多少異なるかもしれません。とにかく、どのプログラムソースもプロが書いたコードだと感じることはないのです。Aさんが書いていたソースコードは、紛れもなくプロフェッショナルが書いたコードでした。

   プログラミング能力はもっと高く評価しよう

 私の会社では優れたプログラムを書くことができる人をあまり高く評価しません。確かに、クライアントと話し合って業務要件をまとめたり、戦略めいたものを提案する方がクライアントに対しても印象を強く与えることができるのかもしれませんが、せっかくの提案も優れたプログラマがいなければ実現するのは難しいはずです。少なくとも現在私の会社が提供しているレベルでよいとは思えません。

 以前に国内のある大手システムインテグレータ(SI)が作ったシステムについて苦言を呈したことがあります(「第21回 国内の大手ITベンダのスキルは低い?」。もしかしたら、大手SIも私の会社と同じような誤りをしているのでしょうか。私の会社と大手SIとの違いがあるとすれば、大手SIには優れたプログラムを書く方がたくさんいるのだと信じていたのですが……。

 新人プログラマが作ったプログラムは取りあえず動くレベルでも、後でメンテナンスをする際に読みにくく、そのために仕様変更する場合でも手間がかかったり、稼働当初は障害が発生しなくても、仕様変更などメンテナンス時にトラブルを起こしがちです。また、データの少ない稼働初期には何とか動くプログラム(もちろん、当初はそんな事実に気付いていない)であっても、しばらくするとパフォーマンス障害が発生することがあります。私が見ているシステムでは当初稼働した際に作成されたコードの90%くらいは、結局何らかの理由(多くはパフォーマンス障害)で書き直す必要があった、というケースもありました。

   上流へ、上流へ、といった道だけが正しいのか

 いま、コンサルタント会社に限らず、システム関連の職業ではプログラマは駆けだしの仕事であり、なるべく早くその上のポジションに就かねばならない、といった風潮があるように見えます。これは、早く高単価のポジションに就かせて売り上げを伸ばそうという意識の表れです。ですが、その結果として作成したシステムの品質が低下しているように思えるのです。

 システムの品質低下は開発コスト以上に運用コストに響きます。優れたプログラマが書いたソースは運用コストを下げることができます。それはバグの少なさ、パフォーマンス障害を引き起こす可能性の低さ、仕様変更への対応の容易さなどに表れるはずだと思っています。

 優れたプログラマへの評価はもっと高くあるべきなのではないでしょうか。新人プログラマを何人も使うくらいであれば、一見開発に時間がかかるように思えますが、ベテランのプログラマを利用した方が、開発期間、コスト、さらには運用管理についても良いのではないかと考えることが最近多くなっています。

自分戦略研究所、フォーラム化のお知らせ

@IT自分戦略研究所は2014年2月、@ITのフォーラムになりました。

現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。

これからも、@IT自分戦略研究所をよろしくお願いいたします。