優れたプログラムとは (終)
プログラマなら誰しもが優れたプログラムを書きたいと思うだろう。あるいはこれまで作ってきた自分のプログラムはどれもすばらしいものだった、と言う人もいるかもしれない。だが、そもそも「優れたプログラムとは一体なんなのか」という問いに答えることは非常に難しい。なぜならプログラムの価値は、そのプログラムを取り巻く環境によって様々に変化するからだ。こうすれば必ずや万人が「優れている」と認めるような唯一無二の純然たる解はない。あるのはそれぞれの立場からの相対評価と、どれだけ多くの人がそのプログラムに価値を認めるかということだけだ。
企業の理念・存在意義は社会奉仕である。役に立つソフトウェアを売り、社会に貢献し、利益を得る。ソフトウェアは企業活動の結果生み出される生産物であり、人々に使われて初めて価値が生まれる。プログラムを「ソフトウェアを生成するための存在」だと定義するならば、ニーズのないソフトウェア（の元となるプログラム）はただのガラクタだ。
プログラマならこの意見に強烈な拒否反応を示すかもしれない。もちろん生産物の価値だけがプログラムの評価基準だなどと言うつもりはない。ソースコードそのものにも研究や学習、教育といった分野におけるニーズが存在するからだ。特に我々のようなソフトウェアを延々と開発し続けなければならない側の人間にとっては、バイナリ化された実行モジュールよりもソースコードの方に価値があることは言うまでもない。優れたコードは、それがコンパイルされようがされまいが、我々にとって非常に重要な存在なのである。
プログラマであれば、この辺りの話は主に技術的側面に論点が集中するだろう。アーキテクチャやアルゴリズム、生産性や性能といったような部分である。思慮深い人であれば芸術性にまで言及する人もいるかもしれない。美的センスがコードの体裁に大きく影響することは皆さんもご存知のことだろう。
しかしここで注意しなければならないことは、ソースコードの評価は相対的に変化するということだ。例えば、受託されたソフトウェアが顧客の要件を満たしているか否かという視点に立って考えてみるといい。要件を満たしていないプログラムは、その設計思想やアルゴリズムがどんなにすばらしいものであろうとも優れたプログラムとは言えない。それは間違ったプログラムであり、修正されるべきものだ。逆にこのアルゴリズムだけを取り出してどこにでも使える共通部品にしたとすれば、この部品は優れたプログラムと言えるかもしれない。顧客要件、すなわちソフトウェアの用途によってプログラムの優位性が正反対に変化するのである。
よく不特定多数の集まるBBSやメールグループなどで純粋な技術論が噛み合ってない状況を見かけるが、これらの多くは互いの想定している環境や目的が異なっていることに起因している。テストツールを作っているのとフレームワークを作っているのとでは、作り方のセオリーはまるで違う。たかだかちょっとしたテストツールを作るためにグローバル変数を使わないことがはたして「優れている」と言えるだろうか。
このようにプログラムの優位性はソフトウェアを取り巻く環境によって大きく左右され、ソースコードただそれだけを見て評価ができるというわけではない。技術論は複雑な問題の発生しやすい、より大規模で、より長期間のプロジェクトにおける開発を想定して行うべきであり、できれば実際の場面やどのような状況での話かをきちんと決めた上で議論した方が良い。ここにプログラムを語る上での難しさがある。プログラムは純粋な数学などではなく、したがって工学的に語られるべきだ。
上述のような外的要因の話と純粋な技術論とを切り離せない理由は他にもある。その１つにソフトウェア要件がプログラムの設計に大きく影響するということが挙げられる。本来プログラムは拡張性・再利用性の観点から抽象化・汎用化され、品質の観点から疎結合化されるべきだが、ただただ抽象化・汎用化・疎結合化されていればそれでいいというわけではない。これらを進めれば進めるほど開発量は増え、コードは難解になり、アクセシビリティは低下する。例えば共通関数の汎用化を進めていくと引数が増え続けて使いづらくなったり、実装クラスが１つしかないinterfaceがやたらと出てくるようなプログラムは、不要なインプリメントをやめてもっとシンプルなコードにできるはずだ。
したがって設計者は可能な限り抽象化・汎用化・疎結合化の行き過ぎを押さえなければならないが、これには想定されないデータや拡張可能性の排除が必要である。これはソフトウェアが対象とする実際の業務をある程度熟知しておかなければできないことであり、そういう意味ではプログラムの設計は本来（プログラミングに精通している前提で）上流従事者がやるべきものだと私は思う。
優れたプログラムとは、その用途や規模、環境や経緯などの外的要因を考慮し、適度に抽象化・汎用化され、適度に疎結合化されていること、そのバランスを見極めることで作られる。ある一定レベルにまで達したプログラマには、このバランス感覚こそが最も必要な能力となる。バランスを欠いたプログラムは総じて独善的で一人よがりだ。複雑な論理式。行き過ぎた抽象化。ゆがんだ車輪の再発明。自分のスキルをためしたくてウズウズしている中級辺りの者であればたいていは通る道だと言えるだろう。
熟練のプログラマなら自らのバランス感覚に基づき、純粋な技術論においてしばしば良くないとされるコードを書く場合もある。例えばレベルダウンの許されない状況においては、プログラム修正に設計思想を無視した完全に独立したコードを入れる場合もあるし、納期がせまっていれば似たような処理もコピペですませることもあるかもしれない。これらのコードは「レベルダウンしない」「納期に間に合わせる」という個々のプロジェクトにおける優先事項から見れば優れていると言えるのだ。このようなバランス感覚は論理・合理といった左脳的思考のみならず全体把握やイメージといった右脳的思考も必要になる。IQが高いからできるという単純なものではなく、やはり経験の蓄積がものを言う領域なのだろう。
プログラマに必要な能力というものはこの他にも、設計の土台を作るひらめきや創造性、顧客の業務を理解する判断力や社会性、体力や集中力など数え上げればきりがない。優秀なプログラマへの到達とは本当に困難で険しい道のりだ。だが、こうした能力をすべて兼ね備えたスーパーマン、完璧超人のような猛者がきっと存在し、日々優れたプログラムを作り続けることで混沌としたIT業界をしっかりと支えてくれているに違いない、と私は願う。
もちろん現実はもっと厳しいものだろう。良質なプログラムが量産されているような現実などありはしないのかもしれない。完璧超人なんてこの世の中に存在しないから？ いやいや、完璧超人はもっと待遇の良い職業に就くからだ。