プログラムコード至上主義

程度の差こそあれ、多くの人は「ソフトウェアを作ることはプログラムコード を書くことだ」と思っています。そしてそれは間違ってはいません。しかし、 ソフトウェアというのはそれだけでできるものでもありません。ソフトウェア を作る際にプログラムコードの事しか頭にないという状態をここでは「プログ ラムコード至上主義」と呼びたいと思います。

プログラムコード至上主義の弊害

プログラムコード至上主義のもとでは、どれだけ仕事が進んだかは書いたプロ グラムの行で計られます。一日にたくさんの行のプログラムを書ける方が偉い と思われています。確かに毎日何千行もコードが増えていくと仕事をした気に なります。

しかしこれは良くない徴候です。なぜならバグの量はコード量に比例して増え るからです。そして、こうした風潮が一般的になると誰もプログラムコードを 減らそうと努力しなくなってしまいます。問題を整理してシンプルかつエ レガントなやり方で解くより、やたらめったらコードだけ書く方が評価されて しまいます。そんな状況では誰もわざわざ難しい問題について考えようとは しなくなります。本当はそれが必要なのに。

プログラムコード至上主義は最後に破綻します。全部出来上がってさあバグ取 りという段階になって、バグが次から次へと湧いてきます。そして次はバグを 退治した数の多い人が英雄扱いされます。しかし実際は何のことはない、自分 で一生懸命作ったバグを自分でつぶしているだけなのです。そうやって無駄な 時間をコンピュータの前で費していただけなのです。

さらに問題なことに、成果を数字だけで見るとそうした人が評価されがちです。 彼は人の3倍コードを書いて、しかもバグを人の3倍潰した、と。もしかしたら 彼は同じプログラムを人より3倍手間をかけて作っただけなのかも しれません。本来ならコード量ではなく作成したソフトウェアの機能の量で評 価しなくてはいけなのですが、残念ながらソフトウェアの複雑さを定量 的に評価できる方法はなかなかなく、コードが3倍あればやった仕事量も3倍だ と思われてしまいがちです。

プログラムコード至上主義から脱却しましょう。まずは常に「無駄にプ ログラムコードを書いてはいないか？」と自問することです。コードを書くだ けではなく、どういう構造でプログラムを組み立てたらいいかを考えるように しましょう。そのためにはPCの前でキーを叩くだけでなく、紙の上で考えるこ とも人と相談することも必要になってきます。プログラムを書くことが仕事な のではなく、ソフトウェアを設計することが仕事なのですから。

プログラムを書くことは小説を書くこと

上で「プログラムコードは文芸だ」と言いました。プログラムを書く事は小説 を書く事と同じなのです。小説もプログラムと同じく、アウトプットは何百ペー ジにもわたる文章の連なりです。しかし、小説を書く事イコール文章を書く事 でしょうか？

実を言うと、世の中にあまたある素人小説のほとんどはそうです。素人は小説 を書くというとかたっぱしから文章を書き始めます。そうして出来てきた「小 説」を読んでみて下さい。どうしようもなくつまらなく、読むのは拷問に近い ものがほとんどなはずです。

ちゃんとしたプロの小説はそうではありません。登場人物の詳しい設定や効果 的な構成、プロットなど小説の核となるアイデアをまず考えます。そしてそれ を裏付けるために現地取材をしたり文献を調べたりします。こうした作業で材 料がすべて出揃ってから初めて文章が書き出されます。

つまるところ、小説は「文章」ではなく「物語」なのです。物語が文章で表現 されているだけなのです。素人小説が面白くないのは文章が下手なのではなく、 それが表現している物語がちっとも面白くないからです。アイデアも物語の起 伏もなく ^[1]、つまらない話をそれらしい文章で飾っているだけだからです。

プログラムも同様です。わかりやすいモジュール構成や、便利なシステムを構 築するためのアイデアが核です。そしてそれを実現するために、時にはアルゴ リズムや数学的理論で裏付けをする必要があるでしょう。それらの「内容」 をプログラムという形式で表現したのがソフトウェアなのです。

2.3. プログラムセンスとは

よい文を書くにはそれなりの作文センスが要求されます。「作文教室」とか 「わかりやすい論文の書き方」なんて本が世の中にあふれているのはそのため です。しかし、プログラムについてはそうした本がないのはどうしたことでしょ う？世の中における「プログラムセンス」の認知度の低さは残念です。

実際、ソフトウェア技術者の能力は「データベースが得意」とか「制御系が得 意」といったように分野で見られがちです。しかし、優れたソフトウェア技術 者はたいてい何でもこなします。小説家が評論を書いてもエッセイを書いても それなりにさまになるのと同様です。特定の分野についての知識は関連する書 物を読めば得ることができますが、「プログラムセンス」というものはちょっ と本を読んだだけでは身につかないからです。本当はそれが大切なのに、そう した事柄はちっとも評価されません。

「プログラムセンス」が評価されない理由の一つは、評価する側がそれを理解 できないからでしょう。「過去にどんな分野のプログラムを手がけたか」は経 歴を見ればすぐわかります。しかしその人の書くプログラムのセンスはプログ ラムを読めないとわかりません。多くの場合、評価する側にそうした時間も知 識も能力もないのが実状です。

話が少しそれました。「プログラムセンス」というのは、プログラムにおける 作文センスです。「作文教室」や「論文の書き方」という本を見ればわかるよ うに、これは文章の問題ではなく構成の問題です。

2.4. ドキュメント至上主義

今まで「プログラムコード至上主義」はよくないとお話ししてきました。こう 言うと、逆の極端である「ドキュメント至上主義」に陥ってしまう人がよくい ます。

ドキュメント至上主義とは、「プログラムコードを書かず、ドキュメントを書 きなさい」という主義のことです。これに陥ると、やたら「○○仕様書」「○ ○設計書」というドキュメントを書かせます。こうした「ドキュメント至上主 義」はプログラムを書けないマネージャクラスの人間に多く発生します。

ドキュメント至上主義の一番大きな間違いは「日本語で書いてあってきれいな 図が書いてあるものしかドキュメントとみなさない」という点にあります。こ れもまた本質を見失って形式主義に陥っているのです。「○○設計書」の意義 は○○について設計してその結果を残すことにあります。とすれば、他の人が 見てわかりやすい形式なら、その形式は何だっていいはずです。

以前「日本語よりプログラムの方が読みやすい」と書きました。つまり、他の 人が見てわかりやすいなら、「○○設計書」はC言語で書いてあってもいいの です。そして「C言語なんて俺には読めないから日本語で書け」という人はプ ロ失格なのです。

例えば、C言語のプロトタイプ宣言は十分モジュールのインターフェース仕様 書になります。適切にコメントが付けられたJavaのソースはJavadocを使うこ とでドキュメントになります。設計の結果がプログラムという形で明確に残っ ているにもかかわらずドキュメントを書かせるのは無駄以外の何者でもありま せん。

必要なのは分析や設計をすることであって、その結果をどんな形で残すかとい うことではありません。