ソフトウェア開発の工程は大きく分けて、要件定義, 設計, コーディングの三段階からなります。 (実際には、その後にテスト, デバッグなどの段階が続きますし、これらも明確に区別されるわけではなく、互いに絡み合っている部分もありますが、「作る過程」の説明としては大きく外してはいないはず。) これらの段階においては、「何を」「どのように」作るかということが順次決定されていきます。 そこで決められた事項は、仕様書や設計図として文書化され、開発に携わるメンバの間で共有されることになるわけですが、この共有の際に零れ落ちてしまう、あるいは、作る過程では確かにあったのに、完成品からは抜け落ちてしまうものがあります。

例えば、データベースの仕様書には、各テーブルに属するカラムの名前, データ型や、それらが満たすべき制約については、逐一正確に書き込まれます。 しかし、それらの事項がどのような理由・経緯によって決定されたのかということについては、ドキュメントは何も教えてはくれません。 書きあがったプログラムを眺めても、例えば関数名や引数の並びについて、何故そのようになったのか、ということは分からないようになっているのが一般的です。 それらすべてを挙げ連ね、その経緯について事細かに記述することも原理的には不可能ではありませんが、実際にそれを行ったとすれば、おそらく管理しきれぬ程に莫大な量のドキュメントができあがるはず。 (軽く見積もっても、現在のオーダから二桁は上の量になると考えられます。) その情報の洪水の中にあって、本来の仕様書や設計図に書き込まれていた重要な情報は、その他の数限りない、瑣末な情報に埋もれて見えなくなってしまうことでしょう。

けれども、ソフトウェア開発の知識・技術の本質とは、こうした「作る過程」における「瑣末なもの」の中にこそある、と私は考えています。

例えば、建築の現場では、高所作業のために足場を組みますが、この足場は建物の完成時には取り除かれるため、最終的にはそこに残るものではありません。 しかし、この足場をいかに素早く、安定したものを組むか、また、楽に撤収できるようにするかというところに、技術の本質があるのです。 足場は、その上で行われる作業のベースであり、その良し悪しが工事の期間や安全性を大きく左右する要素となることは想像に難くないでしょう。 また、建物が完成してすぐには気付かないかもしれませんが、全体が補修・拡張などの作業を想定して設計されているかどうかは、長期的に見た場合に、その建築物の品質に大きな影響を与えます。

ソフトウェアもこれと同じで、ロジックの共通化、インターフェイスの整備などにより、できあがった「もの」をちょっと眺めただけでは分からない、しかし、決定的な品質の差が生じます。 (参照: 拙速を尊ばない) その差を生み出すのは、一言で表すならば、作られるに際してどの程度「作りやすいカタチ」「壊れにくいカタチ」「直しやすいカタチ」が意識されたか。 しかし、残念なことに、この「作るときの意識 (あるいは思考, 目線)」はドキュメントにも完成品にも残らず、常に抜け落ちてしまうもののようなのです。

形とは、すなわち数字の集合だよ。 数字だけが歴史に残る。 残らないのは、その数字の意味、すなわち、数字と実体の関係。 形は、数字に還元できる。 図面にも映像にも、還元できる。 ドキュメントとして保存することが可能であり、それはほぼ再生される。 コピィできるものは、すなわち形だ。

けれど、形のコピィに何を見るのか、という点に、その時代とその人物の技量が影響する。 形だけに拘った者には、伝達されない情報がある。 それがつまり、あの長谷川って人が言っていた、形を作った意志、つまり型なんだ。 作った本人は、その形に何か別のものをみていたのに、それをコピィした者には、それが伝達されない。 そこで、抽象の技法が模索された。 これまで伝達されなかった情報、形にならないものを、なんとか描こうとした、それが抽象芸術だ。 でも、やっぱり、本質は伝わらないことが分かった。 ようするに、伝達に際して、この最も肝心な情報がいつも抜け落ちることになる。 これが、これまでの人類の歴史の中で、実に大きな障害だった。

『数奇にして模型』/ 森 博嗣

ツイート

Facebook でシェアする