こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい

ちょっと興味深いエントリが目に留まりました。「プログラミングへのこだわり」を方向づける: 設計者の発言基本的に、この方自身もプログラマーや開発者をされているようですし、他のエントリを読んでも「プログラマーの地位向上をすべき」ということで、私にとっても非常に共感することをおっしゃっているのです。それでも、ちょっとこのエントリの内容については疑問に思うところがあったので、勝手ながら私の意見を書かせていただきたいと思います。

業務システムの生産性や保守性を高めるための基本は「コードを１行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。

これは、まさにおっしゃる通りですね。もちろん、可読性ということもあるため、厳密には最少のコードが最良というのは言い過ぎですが、基本的には重複がなくロジックが共有化されており、無駄なコードも存在しないというのがよいコードの条件です。このブログで既に紹介してきたように、世界の達人プログラマーと呼ばれる人の書いたどんな書籍を読んでも、基本的にこの考え方は一致しています。誰も保守できない独自のコードを書くべきなどと主張する人はいません。

達人プログラマー―システム開発の職人から名匠への道

プログラマが知るべき97のこと

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

Clean Code アジャイルソフトウェア達人の技

それで、疑問なのは次の部分です。

いっぽう、そんな方針と明らかにそぐわない人たちがいる。彼らはプログラミングそのものに強いこだわりを持っていて、より良いコードをより多く生み出すことに生きがいを感じる人たちだ。チャーミングな彼らの姿を個別案件の開発現場で見るたびに、私はキャスティングの失敗事例を見る思いがして切なくなる。

優秀な開発者であればより良いコードを多く生み出すのではなく、より良いコードをより効率的に書く、つまり、より少ないコードで価値の高いことを実現することにこだわりを持っているものです。XPで有名なケントベックでもリファクタリングの中の一節で、同一のプログラムの無駄をなくすために何十年もかけて同じプログラムの改善をやっているようなことを書いていたと思いますが、新しい機能を作り出すことよりも、むしろ、同じ機能をいかに簡単に保守しやすい状態に維持するのかという点に最大の情熱を注ぐプログラマーも存在するということを忘れてはならないのではないでしょうか。そして、極力無駄をなくすというこだわりはコードの重複を除去するといったミクロなレベルから、ドメインモデルやサービス、OSSやパッケージの再利用というところにも及びます。*1私自身もどちらかというとクリエイターというより、リファクタリングや再利用、テスト自動化による効率化の方に面白味を覚える方ですね。私がプログラミングで最も楽しいと思える作業 = リファクタリング - 達人プログラマーを目指して

ゆえに私は、プログラマを個別案件に引き留めておこうとする開発手法や技術を嫌悪する。個別案件において生み出すことが求められているものは、「こだわりの手作りプログラム」ではなく「使いやすく保守しやすいシステム」である。

たしかに、特定プロジェクトによらずに横断的に使える基盤やツールを開発することはコピーが容易というソフトウェアの性質を考えれば正しいことです。しかしながら、現在は、インターネットから無料で便利なOSSのツールやフレームワークが入手でき、クラウド上で優秀な業務アプリケーションが調達できる時代です。本当に汎用的に使えるソフトウェアであれば、わざわざ自社の閉じた環境で内製しなくても、外部から優れた製品を簡単に入手できます。たとえば、今時O/Rマッピングや画面を30行単位でページングする仕掛けをわざわざ社内独自のフレームワークとして開発するような時代ではもはやありません。
そうであれば、

• 汎用的に実行可能なCRUD処理などは汎用パッケージ、OSS FW、クラウドを流用する
• その会社で本当にコアになる業務ドメインに優秀な開発者を集中させる
• 既存レガシーシステムの有効活用も含めて、企業全体として情報資産を最大限に活用可能なアーキテクチャや改善プロセスを構築する

のような方向にシフトしていくのが合理的であるように思います。つまり、エンタープライズレベルや個別システムレベルなど様々な階層でアーキテクトという役割*2をもっと重視し、既製品を流用する範囲と独自開発すべき部分を正しく選定し、そのうえでコアとなる業務ドメインに対しては徹底的にむしろこだわりを持ったハイスキルのプログラマーを投入して長期間拡張可能なシステムを構築するという方向に持っていくべきではないでしょうか。そのあたりの話は、以下にも書かれています。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

つまり、汎用的に幅広く使える便利ツールや共通部品の開発に優秀なプログラマーを投入すべきというのは一般に正しいことではありますが、一方で

• 本当に汎用的に使える部品なら内製しなくてもOSSやパッケージで既に広まっているはずでは
• 汎用部品の流用だけで全システム開発をまかなえるということは幻想では（使い捨てシステムなどの例外を除き、一般的な案件では案件固有の問題が残るのでは）

という疑問が湧いてくるのです。
SI業界で私がかかわったお客様の状況を考えると

• 技術にこだわりを持った技術者を個別案件とは別の基盤チームなどに配置する
• OSSで入手できるような汎用のツールをわざわざ車輪の再発明のように開発し標準化させる
• 個別の要件の違いを考慮せず、汎用の標準FWを押し付ける
• 個別案件は低スキルのプログラマーを安い単価で外注する
• 結果としてコピペが横行し、リファクタリングや単体試験のない保守不能なシステムができる
• 大量のコストをかけてダメなシステムを長期間保守する
• システムに手を加えられないからいつまでも古いバージョンを使い続ける*3

といった悪循環に陥っているケースが本当に多いのではないかと思います。今後は、既製品の流用でなるべく開発量を抑えつつ、独自開発する領域は良いプログラムへのこだわりのある少数精鋭のチームで取り組むという方向にシフトしていくべきなのではないでしょうか。つまり、そういう個別のカスタム案件にこそ優秀な開発者を配置し、無駄なコードのない保守しやすいシステムを構築すべきなのではないかと思います。
この点については、以下もご参照ください。
頭数要員だけでこなせる仕事が今後もずっと取れると考えているSIerの仮説は間違っている - 達人プログラマーを目指して
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して

*1:職人プログラマーというとなんでも自作しないと気が済まない人をイメージするかもしれませんが、少なくともオブジェクト指向の世界では再利用と怠惰は最大のプログラマーの美徳の一つとされています。デザインパターンやフレームワーク化といったところはそういうこだわりの表れなのです。

*2:海外だと上級プログラマーがアーキテクトのロールを兼ねるということも多いと考えられるため、両者の境界があいまいなのですが、日本のSI業界だとプログラマーはコードを書き下すPGの意味で使われることが多く、期待される役割がかなり違いますかね。だから、「こだわりのプログラマー」といったとき翻訳書で描かれる海外の達人プログラマーのイメージと、実際に業界の現場で意味する対象が大きく異なる可能性は大いにある。日本でこだわるというと細かいところにこだわって、全体的な効率化を考えない人という意味もあるかもしれないですね。

*3:いまだに新規開発でもJDK1.4などの古い書き方をするシステムが主流という悲しい現実もあるようです。