第15回:メモリが安くなったからといって「無限」だとは思わない方が良い|本気で読み解く”人月の神話”(第9章「5ポンド袋に詰め込んだ10ポンド」)

AUTHOR :  田中 耕比古

この章の内容は時代遅れだが、思想は踏襲されるべき

人月の神話【新装版】
人月の神話【20周年増訂 新装版】

今回は、第9章:5ポンド袋に詰め込んだ10ポンド を解説します。本章は「有限なサイズ(5ポンドしか入らない袋)の中に、それ以上のもの(10ポンド)を入れようという無茶」という比喩で、ソフトウェア開発における「サイズの有限性」を説明しています。

ただし、本章は「キロバイト」とかいう単位が出てきてしまう世界ですので、正直なところ、「ギガバイト」「テラバイト」の世界に暮らしている僕たちには無縁な部分も多くありますので、「書いてあることそのもの」ではなく、その「エッセンス(本質)」に注目していくことが大切です。

連載記事一覧は、コチラの最下段から

時代は流れ、記憶媒体は廉価になった

CPUの進化において「ムーアの法則」の存在が明らかになったように、メモリやハードディスクなどの記憶媒体の価格は「ドッグイヤー」もしくは「マウスイヤー」と呼ばれるほどの”スピード感”で下落しています。(正確には、同じ価格で購入できる媒体のサイズが加速度的に大きくなっている、と言うべきでしょう)

その結果、プログラムそのもののサイズを意識せねばならない、という局面は少なくなってきています。例えば、いわゆる「組み込み系」の開発で、最近はやりのドローンとかに特殊な機能を組み込みたいというような場合にはプログラムサイズを気にする必要が出てくるかもしれませんが、比較的レアケースと言えるでしょうか。(ちなみに、昔だと、携帯電話の組み込み系ソフトは、サイズを気にする典型だったんですが、徐々に搭載できる記憶媒体が潤沢になってきていますのでどの程度センシティブな課題なのかはちょっと分かりかねますね)

とはいえ、スペースは有限だと知るべし

もちろん、いくら「メモリが廉価で潤沢だ」と言っても、それはあくまでも”昔に比べて”という相対的な話であって、現実的に無限大のメモリが与えられるわけではありません。

iPhoneやAndroidのアプリで、処理が重すぎるだとか、あるいは、良く落ちるだとか言う話には、この「処理中のメモリの使い方」に課題があるケースが散見されます。いずれにしても、「沢山あるから、あるだけ使ってしまえ」というのは、間違った思想だということですね。(年度末の風物詩である”官公庁の予算使い切り”の話を耳にして、違和感を感じたことのある人は、自分自身にも照らし合わせてみないとダメってことですね)

この”思想”の本質は「コントロールするという意思を持つ」ということ

本章で述べられていることの「本質」は、物事を自らでコントロールしようという意思を持つことの重要性だと僕は思います。

一般的に、何かを得るということは、何かを捨てることを意味します。自由な恋愛の楽しさを得るなら、幸せな結婚生活は捨てることになるでしょう。ダイエットによる適正体重を得るためには、欲望のままに食べる楽しみを捨てることが求められます。世の中は「トレードオフ」で成り立っています。

サイズとスピードのトレードオフは、どちらかと言うと急激に跳ね上がる。

当然のことながら、処理スピードを維持したまま機能を多くすればスペースも大きくなる。だから、職人技の第一の領域は、機能とサイズを交換することにある。

この「トレードオフ」を理解し、何をどの程度優先するかという”考え方”が重要です。そして、それに則った”意思決定(をするという姿勢)”が大切なのです。もちろん、世の中には様々な選択肢があり、さらに厄介なことに、似たようなシチュエーションであっても、実際には、都度都度、微細な条件が変化しています。そんな中で「どのように考え、どのように意思決定するか」ということが、物事を正しい方向に進ませるためには欠かせません。

表現は「プログラミングの本質」と知れ

ブルックス氏は、この章において、2つの提言をしています。それは

  1. プログラミングテクニックの習得をさせる(古い経験ばかりではダメ)
  2. プログラミングの”技法”と、コンポーネントの”組み立て”を意識させる(技法を正しく開発し、コンポーネントとして組み上げる)

の2つです。

これは、非常に基本的な提言ですが、この基本の徹底が「職人技」に繋がります。そして、優れた職人技が、発明を生むとブルックス氏は述べます。

職人技を越えたところに発明(アイデア)がある。簡潔で余分なところが無くてスピードの速いプログラムが誕生するのは、まさにそこである。そういうプログラムは、たいてい巧妙な奇策と言うよりも、戦略的突破と相場が決まっている。戦略的突破は、時には全く新しいアルゴリズムだったりする。(中略)

しかし、データやテーブルの表現をやり直すことで戦略的突破が実現される場合の方がはるかに多い。ここにこそ、プログラムの神髄がある。

トレードオフを理解し、その中での最善のバランスを見極めていくという過程においてのみ、イノベーションが起こります。(意思をもって述べるのなら、「イノベーションを起こせます」と言うべきでしょう。)

本章を読んで「ああ、古い話だな」と一蹴するのではなく、その裏に隠れた”本質”を読み解こうという意識を持てるかどうか。これもまた、思考のスタイルであり、思考の深さの問題なのかもしれません。(関連記事:概念化すると伝えたいことを明確にできる )

連載記事一覧は、コチラの最下段から

 

SERVICE