「効率化」って言葉が嫌いだけどプログラマになった
会社の上司に聞かれたらしかられるだろうタイトルであるが、私は「効率化」が嫌いだ。
「効率化」、いろいろな諸問題を明確にして、現代社会のプレッシャーを現場レベルで格段に上げた代物だが、良い点もあれば悪い点もある。効率化という言葉だけですべてが潤滑に回るわけではない。
効率化とはまた別の話になるが、会社にはノルマというものが存在する。
数字で表せば、人はその数字を達成するべく努力する。一方、それにかかるコスト意識などでがんじ絡めである。結果、たとえ仕組みが悪いせいで到底達成できない数字が目標と掲げられていても、数字を達成していない人が悪い、という結論になってしまう。この場合、本当に悪いのは、数字の根拠になっている基準である。基準があいまいであれば、数字なんて何の意味も持たない。
ただ、基準がしっかりしていれば、ノルマは大切である。人間というのは、1つ設定された数字について自然に「達成したい」という気持ちになるらしい。数字でノルマを表せない場合は、評価もされにくい。そういう意味で数字は大切である。
効率化も同じだと考える。基準があれば、効率化というキーワードは常に意識に入れておく必要があるが、基準もないのに効率化ばかりに注力して、後々の非効率的な作業が増えてしまう点については見逃されている。
コラムでは、プログラマが一般的に行う「コードを効率化・部品化して納期を早く仕上げること」以上に、「他人が見て分かりやすく再利用しやすいコーティングが必要ではないか」ということを書いていきたい。あくまでプログラムについて考えた場合、過剰な効率化による分かりにくいプログラムは好きじゃない、ということを一番言いたい。
どんなに高度な計算処理や効率化も、いきなり入った新人にとってはただの難解な小説で、改修すれば即バグが発生してしまう代物になりかねないということだ。
プログラムにおいて、難解なプログラムを読み解いて答えを見いだすのは、なかなか骨が折れる作業になる。
昔のプログラムによくあるパターンとしては、ドキュメントもないし何年も改修を続けていて、新人が怖くて改修できないプログラム。これはなんの意味があるのだろうか。
ここで私が新人の時の話をしてみたい。
＜つらかった駆け出しプログラマ時代＞
僕は大学を出て、なにかモノを作る職業に就きたいと考えていた。ただとびきり優秀なわけでもなく、なんとなくシステム開発という道を選んだ。深い考えは……正直なかった。とにかくなにかを作ってみたかったのだ。そして、とある東京のシステム開発をしている会社に入社することになり、入社前の研修でプログラムの演習をはじめて行った。
初めて作って、正しく動いた時はうれしいものだった。
いろんなプログラムを自分で作れるようになりたいって思って入社を迎えた。ある意味で希望を持って入社した。
入社した当時は、仕事に対して「ああだのこうだの」なんて不満もなく、ただ目の前にある仕事に対して一生懸命働くことになる。中小企業では、早めに実践投入されるのが当たり前で、納期がゆるい仕事は最初の1～2案件だったと思う。すぐ実践に投入されて、コーディングに突入、もちろん仕様書もないし、口頭と手書きの指示で、「習うより慣れろ」という、摩訶不思議な言葉のもと、プログラムを作成して提出する。
そこで、運良く先輩のレビューでコーディングミスなどが発覚するとする。その時に口癖のように「なんでこうしたの？」と聞かれて困る。2～3案件こなすうちに、そんな先輩のレビューも漏れて、朝礼の場でバグ発生者血祭りの宴が始まってへとへとになる。
＜納期の厳しさ＞
そうして、プログラムの納期の厳しさを入社して半年で味わうことになる。ただ、私は最初に納期の厳しさを知って良かったと感じている。何社か経験していく際、この感覚が甘いと、自分の会社ではよくても他の会社では通用しない。納期に甘いのはプログラマとして致命的だ。
もちろん、いろんな事情があるのは理解しているが、それを加味しても、与えられた納期にあがきもせずに、文句ばっかり言って案件を頓挫させることは、本人にとって良い影響を与えないと思う。
ただ、いろんな問題は現場に山積しているので、現場では文句を言い合ってストレス解消をして、納期に対しては工夫を怠らないのが大切だと思う。コストをかけて、諸問題を適切に処理してくれるマネージャは、経験上あまりいない。現場から、本当に納期・品質の必要性を考えて努力し、結果を出さなければ、納期・品質に関しては解決しない。
結局、解決できるのは技術がある現場だけだと思う。
現場にいない人間の方法論を受け入れるほど、現場の人間は心が広くも余裕があるとも思えない。
この点がある程度、納得できる職場にいる人は幸せだと思う。先輩や過去のマネージャ職の人たちの努力や学習の結果だと思う。ただ、私がいた現場はそれほど、恵まれた環境ではなかったように思う。
＜そして10年たった＞
そうして、実践にてプログラムを進めていくことになるが、そこで感じた違和感を十数年たった今でも感じている。プログラムが難解すぎて改修できない……またはしたくない。
変数に変数が入り乱れ、無限とも言えるfor文で、どの値がどのようになるとOKで最大値がいくつかも分からない、こんな処理をなんの疑問もなく懸命に読んで、改修をしてバグを発生させる。このパターンが何年も恒例の行事のように、はたまたなにか大人になる試練かのように繰り返される。
これは正しいのか？
コメントに｛＊この処理はこうかも？｝と、いかにも自分が原因ではありません的なコメントがついてしまうような処理があると、プログラムをどう正当化すればよいのかが分からない。それが、いかに正しいアルゴリズムで正しい計算処理を行っていようと、難解であればアウトだ。
鬼のように何人ものコメントが入っているプログラムも汚くていじる気にもならないし、どうすればよいのか分からない。
<プログラムはクイズではない！！>
そんなわけで、分かりやすいプログラムを記述していくことでのメリットと、結局はたどり着くことのないであろう「理想の開発」ってなんだろう？ ということを一度じっくり考えてみたいと考えるようになった。