本連載ではさまざまな比べ物に精を出してきましたが、人気のある、よく話題に上る比較は意図的に遠ざけてきました。それはたとえば、コメントは書くべきか、言語は動的型付けと静的型付けのどちらが良いのか、モバイルはWebかネイティブか、といった話題です。こういった論争を生む対立軸の多くは、たいていどちらの主張もそれほどすばらしくないことが多いものです。そして長引く論争に疲れ果てたころ、どこからともなく時代の風が、新しい正しい答えを運んできたりするのです。

時代が答えてくれた論争

時代が流し去った論争は急速に忘れ去られていきます。数ある古い論争の中から、日本の片隅でくすぶっていた火種と、計算機科学史の一幕と言える大きな争いを、1つずつ振り返ってみましょう。

Malloc/Free論争は、10年以上前に日本のニュースグループで起きた論争です。プログラムを終了することがわかっている場合、malloc( )関数で確保したメモリをfree( )関数で解放すべきか否かが論点。OSが解放してくれるから自分ではしない派と、規律を守りすべき派が争いを繰り広げました。

今、この論点を気にかける人はほとんどいないと思います。同様の話題が蒸し返されることもありません。この論争が忘れ去られた大きな理由の一つは、ガベージコレクション（GC）によってメモリ管理を自動化するプログラミング言語が普及したためでしょう。GCは、プログラマ自身がメモリ管理を気にするというアイデアそのものが持つ筋の悪さを明らかにしました。

Goto害悪論の期限はさらに古く、40年以上前にさかのぼります。グラフ探索のアルゴリズムなどで知られるEdsger Dijkstraは、プログラミング言語のGoto文がソフトウェアの品質に与える悪影響を非難する論文を発表しました。論文はACM（Association for Computing Machinery：アメリカ計算機学会）の会報に掲載されました。Goto文を使わないDijkstra自身の主張は「構造化プログラミング」と呼ばれるアイデアの一部となりました。

Goto害悪論は長い時間をかけて廃れましたが、今から振り返るとプログラミング言語が「例外」のしくみを備えたことが廃絶への大きな一歩だったように見えます。結局Goto文が持つ有用性の大半はエラーの扱いに関するものであり、それはもっと抽象度の高い「例外」というアイデアでうまく扱うことができるわけです。構造化プログラミングはエラーを扱ううえで不自由過ぎ、Goto文は目的に対して乱暴過ぎました。近代的なプログラミング言語は例外機構の有用性を示しました[1]⁠。

Dijkstraが起こしたこの論争は、ソフトウェアエンジニアリングに関する論争のひな型となりました。論文からブログ記事まで、何か論争をふっかけるときはDijkstraの論文「Go to statement considered harmful」をもじって「considered harmful」を題名に含めるのが暗黙の了解になっています。

答えを待っている論争

過去の論争が時代の向こうに消えていく一方、いまだにくすぶっている論争も多くあります。そうした論争もいずれ新しい選択肢によって流し去られるに違いないと、筆者は楽観しています。

現在進行形の論争を解決に導く選択肢は何なのでしょう。それがわかれば苦労しません。ただ、ある論争についてよく考えていれば何かヒントが見えてくることがあります。筆者もそんな論点を一つ持っています。コメントvs.コードです。

今でもしばしば蒸し返される論争の一つにコメント不要論があります。ソースコードには詳しいコメントを書くべきか？ 筆者はその昔コメント必須派でしたが、今はどちらもいまいちという結論に落ち着いています。

コメント不要主義者は、コメントに割く労力はコードの可読性を高めるために使うべきだと説き、コメント頼みの読みにくいコードや、コードの変更に追従できず内容が古くなりがちなコメントの性質を非難します。コメント必須主義者は、コードによってとらえることのできない情報や意図があると主張し、それらをコメントとして文書化すべきだと訴えています。

コメントとコミットログ

一見すると、この論争はドキュメントを書くのを億劫がる横着なプログラマと、神経質で几帳面なプログラマのいがみ合いであるかのように映ります。

実際のところ、それはあまり正しくありません。コメント不要主義者も、ある種のドキュメントは案外丁寧に書くのです。そうしたドキュメントの一つがコミットログです。コメント不要主義のコードベースで仕事をしている筆者は、開発者が丁寧なコミットログを書く様子をたびたび目にしてきました。ドキュメントとしてのコミットログにピンと来ない読者は、WebKitのコミットログを覗いてみてください。詳しく書かれたソースコードコメントに匹敵する事細かな説明を見ることができるでしょう。

コメント嫌いの開発者たちが、コミットログの必要性は認めている。これは興味深い事実です。コメント不要主義者の多くはドキュメントを書きたくないのではなく、コメントを書きたくないのです。なぜコミットログは書くのにコメントは書かないのでしょう。コメントとコミットログの違いはどのように説明できるのでしょうか。

メディアの違い、レンズの違い

コメントは、ソースコードのある瞬間を説明しています。言ってみれば写真のようなものです。一方、コミットログはある状態から別の状態への変化をとらえた動画です。またコメントはクラスやメソッドなどの細かい単位で物事を説明するのが主流なのに対し、コミットログは変更全体を一望します。コメントはズームやマクロ撮影のようなもの、一方のコミットログは広角（ワイド）撮影です。

ドキュメントを載せるメディアの向き不向きは、開発スタイルと関係があります。反復的で漸近的な開発スタイルでは、ある瞬間のスナップショットはありがたみが大きくありません。あとに続く変化のせいですぐに古びてしまうからです。むしろその変化自体を追いかけた動画のほうが理解の助けになるでしょう。一方、前もって念入りにデザインを決めるなら、解像度の高い写真的なメディアが役に立つでしょう。

ドキュメントを写すレンズの違いはコードのデザインの影響を受けます。クラス単位の働きより複数のオブジェクトをまたぐ協調と役割分担を重視するなら、広角で景色を収めたくなります。オブジェクト同士の位置関係を一目で見渡せるからです。一方で個々のクラスの完成度を重視して丁寧に磨き上げるなら、その細部をとらえる力があるのはマクロ撮影です。

反復的な開発スタイルをとる若いプロジェクトや、部分的な再利用を気にしないアプリケーションソフトウェアほど、コメントよりコミットログを好むのが自然な成り行きに思えます。逆によく理解され成熟したソフトウェアや再利用を意図したライブラリのコードはコメントを好む傾向がありそうです。プロジェクトやデザインの違いがコメント不要論争の火種だった。そう考えることはできるかもしれません。

より良いメディアとカメラワーク

ところで、そもそもメディアやレンズの違いを受け入れる必要はあるのでしょうか。これらはメタファに過ぎません。メタファの対象が実際のメディアより大きな不自由に甘んじる必要なんてあるのでしょうか。私たちは高解像度の動画を自在なカメラワークで撮影したいのです。

メタファを離れて具体的に書いてみましょう。コメントは空間的解像に偏り過ぎ、時間的解像を損ねていました。コミットログはその逆です。双方を満たすドキュメントは可能なのでしょうか。コメントに相当する粒度のドキュメントが、日々コミットされるソフトウェアの変化をとらえることはできないのでしょうか。そして異なる粒度のドキュメントを自由に渡り歩いてはいけないのでしょうか。

たとえば、クラス単位、関数単位でコミットログが書けたらどうでしょう。それらのコミットログが、コメントと同じくらい簡単にエディタから参照できたら？ GitやSubversionのblame機能はこうした方向性の芽生えだと見ることができます。しかしとても十分とは言えません。コメントとコミットログ双方の利点を備えたツールが現れたとき、コメント論争は歴史の影に消えていくでしょう。

コメント論争は一例にすぎません。多くの論争は、その外側に答えが隠れています。答えそのものがわからなくても、喧騒から離れて静かに考えを巡らせれば答えの輪郭や匂いに気づくことくらいはできるはずです。論陣の一方に肩入れしてその正当性を声高に唱えたり、他方の粗探しに終始していると、答えの行方を見失ってしまいます。

論争の解決には時間がかかります。何らかの論争の中で今まさに選択を迫られている人は、答えを見つける前に異議をはらんだ決断をするほかありません。あなたを責める人もいるでしょう。けれど10年後に振り返れば、どちらも間違っていたと笑っているはずです。論争の中で下す決断は答えの見えない問いをはぐらかすその場しのぎ。そう思うと、少しは気が楽になりませんか。

答えを探す

運良く即断を迫られていないなら、答え探しの旅に出ましょう。

まず最初の準備として、今持っている答えは保留しましょう。それはきっと間違っています。愛着のある正当化一式も、箱に詰めてしまいましょう。その代わり苦痛に目を向けます。どんな苦痛が、あなたを論争に導いたのでしょうか。メモリの解放漏れをデバッグする絶望感。あちこちにジャンプするソースコードを追いかけるストレス。間違いだらけのコメントが招いた混乱。何があなたを苦しめたのか、よく思い返してください。

今度は同じように、論敵の苦痛を探り出しましょう。彼も何らかの苦痛に突き動かされ、時に受け入れがたい主張を叫んでいるのです。その主張に同意する必要はありません。しかし苦痛には共感できることがあるはずです。喉まで出かけた買い言葉を飲み込み、彼の苦痛を聴き出してください。じっと目を見て、その苦しみに耳を傾けてください。

論争を招いた苦痛のリストは出そろいましたか。「⁠面倒くさい」「⁠イライラする」「⁠遅い」「⁠怖い」「⁠わからない」……生々しく身も蓋もない訴えほど問題をよくとらえています。トヨタの「5つのなぜ」と同じように「何がつらいのか」を繰り返し問い、建前の皮を剥ぎましょう。苦痛のリストは、隠された問題によって引き起こされている症状です。その隠された本当の問題を片付けるのが、私たちの探す答えというわけです。

答えのパターン

さて、論争は単なる問題解決に姿を変えました[2]⁠。その問題に挑むテクノロジを想像するのが次のステップです。ソフトウェア開発における問題解決にはそれなりのパターンがあります。冒頭に紹介した過去の例からパターンを考えてみましょう。

Malloc/Free論争はGCの普及によって意味を失いました。GCのように、面倒な作業を自動化するのはソフトウェア技術が得意とするパターンの一つです。GCは自動化の中でも特に込み入った部類に属します。日々の小さな論争の種はもっと素朴な自動化で片付くものも多いはずです。自動化の恩恵はコードの中身にとどまりません。たとえばプロジェクトのルールに関する論争は、プロセスを自動することで片付くものも多いことでしょう。

Goto害悪論争は、例外機構の登場によって廃れました。例外機構は、大局的脱出という強力過ぎる機能にわかりやすい意味、抽象を与えました。気の利いた抽象を編み出すのも、ソフトウェアが得意なアプローチの一つです。プログラマの仕事のうち大きな比重を占める作業でもあります。

コメント論争は、おそらく文書化のための優れたメディアの登場によって姿を消すでしょう。ソフトウェア開発が社会的な営みである以上、コミュニケーションの手段であるメディアが持つ力を無視はできません。ベンチマークやユーザ動向などさまざまなデータをうまく可視化して見せるのもメディアの仕事に数えてよいでしょう。

自動化、抽象、メディア。網羅的とは言えませんが、出発点にはなりそうです。これらは互いに関連し合っています。抽象は自動化のきっかけになります。抽象によってまとめられた雑多な仕事を自動化によって片付けるのは良いアイデアに違いありません。自動化はメディアのコンテンツを作り出し、その流通を支えます。

妥協のベクトル

正しい答えを追い求めるときは、実現の手間や苦労をいったん脇によけて考えを巡らせましょう。すでに問題が山積みですから、それ以上悩みを増やすことはありません。目先の制約に気を取られ過ぎると理想が歪んでしまいます。

それでもアイデアが形になってきたら、いよいよ実現について考える必要があります。アイデアをそのまま実現できることもあるでしょう。とはいえ現実には何らかの妥協が必要になるほうが普通です。妥協をしてしまったら、結局問題は解決しないかもしれない、そう思うかもしれません。けれど振り返ってみると、進んだ歩みに気づくはずです。

論争に決着をつけようとしていたときも、何らかの妥協案が頭をよぎったことでしょう。その妥協は、自分と論敵の間のどこかにありました。第三の答えはふつう、その直線上にはありません。相手との間で綱引きをしても、ちっとも本当の答えには近づかないのです。答えを見つけたあとの妥協は答えにたどり着けないにせよ近づけはします（図1⁠）⁠。

多くの論争は直線上を探索するこの誤りに陥って終わるため、行く末は退屈なものがほとんどです。論争から身を引くことで、違う方向に目を向けられるようになります。

自分が今いる場所以外のどこかに、自分の知らない答えがあるかもしれない。世の論争は、そう気づくきっかけを与えてはくれます。論争にはそんな価値があります。しかし論争それ自体を追いかけても答えは見つかりません。答えは対立の軸を外れたどこかにあります。それを探す旅がソフトウェアエンジニアリングの進歩であり、エンジニアの成長なのだと思います。

さて、積年の論争に決着をつける論点を示す力は本連載にはありません。それでも少しだけ向こうにある正しい答えを探そうと一年間試行錯誤してみたつもりです。その試行錯誤も今回が最終回。お付き合いいただきありがとうございました。