« 「他人にとってのわかりやすさ」が至上の価値である | トップページ | 「命名標準」に振り回されないために »

2017.02.10

「科学研究」としてのシステム開発

 システム開発というものは、さまざまな活動に喩えられてきた。よくあるのは、一品モノの製造や、ビルや橋の建造あたりだ。たしかにそれらに似たところもあるが、違うところもある。そもそも喩えというのはそういうもので、喩えが必要になった文脈によって、強調したい共通点は違っている。その場で強調したい共通点以外を含めて鵜呑みにすべきではないし、喩えが不適切と目くじらをたててもしょうがない。

 とはいえ、「製造」や「建築」に喩えられることが多いゆえにこそ、それらとソフトウエア開発との決定的な違いについて理解しておく必要はある。すなわち、ソフトウエア開発には「資材」が要らない、つまり物質的要素が関わる工程が欠落している。無理やり対応させるとすれば、出来上がったソフトウエアを配布用の媒体に焼き付けるとか、マニュアルを印刷するといった過程で、それらが要らないケースも多い。製造や建築において「ソフトウエア開発」に対応する工程は、実質的には「設計」だけなのである。

■「科学研究」に喩える

 この意味で言えば、業務システムをはじめとするソフトウエアの開発というものは、むしろ「科学研究」に喩えるほうが適切だ。システム開発の成果物に相当するものは「研究論文」であって、これをまとめる過程で「資材」は要らない。「構想を練ること(設計)」が活動のほとんどを占めるという点でも共通している。

 科学研究が「仮説検証」の過程という点でも両者は似ている。漫然と課題を調べまわすだけでは、有意義な成果は導かれない。まずは対象全体を俯瞰して「仮説(モデル)」を構築し、その仮説の正しさを検証するための計画を立て、実行する。鍵は、最初に立てた仮説が十分に的確であること、そして、モデルの妥当性の検証計画が効果的であることだ。

 単純なソフトウエアであれば、いきなりプログラミングを始めて試行錯誤するようなやり方でも出来上がるだろうが、業務システムが相手ではそうはいかない。扱う実体も多いしそれらの関係性も複雑だからだ。対象全体のモデルを事前に確立しておかねば、どんなに気の利いた開発ツールを使おうがくたびれ儲けにしかならない。業務システム開発における「仮説」は、とくにデータモデルに体現されるので、その構築にはコストをかけたほうがいい。そのうえで、データモデルの妥当性を検証するためのプロトタイプ(実際に動作するソフトウエア)を一瞬で手に入れるための仕掛けも必要だ。

 「レビューが肝心」という点でも両者は似ている。研究論文というものは、それがまとまるだけで社会の知識になるわけではない。同業者によって緻密に査読され批判されることで、専門雑誌への掲載が認められ、研究者や一般読者の目に触れることになる。成果物に一定の形式が求められるのは、内容の妥当性にまで踏み込んだレビューを効率的に進めるためでもある。

 システム開発における成果物に標準様式が求められるのも同じ理由だ。もしシステム開発においてレビューがまともに機能していないとしたら、(Excelあたりで書かれているとかで)成果物がレビューしづらいか、レビュワーにスキルが足りないかのどちらかである。

■システム仕様の本質

 いくつもの点で似通っているとはいえ、科学研究とシステム開発が本質的に異なっている点はやはりある。その成果物が「機能」する形式が違う。科学論文は「読み手である人間が世界のあり方を理解する」ためにある。ところが、システム開発の成果物は、人間が世界のあり方を理解するためだけでなく、その記述自身として機能するという不思議な性質がある。成果物を機械に渡せば、機械がその内容にもとづいて振舞い始める。世界のあり方に関する仮説(モデル)として構築されたそのものが、世界に組み込まれて動作し始める、と言ってもいい。

 これこそが、システム仕様の本質であり、強みなのだと思う。ある角度から眺めれば、人間に対する「現実に関する仮説(モデル)」の説明に見える。これを別の角度から眺めると、機械にとっての「その現実を制御するための動作仕様」に見える。人間と機械の双方の世界で機能する独特な「検証された仮説に関する研究論文」――それがシステム仕様というものだ。

 この理解は、あらためて「他の誰かがプログラミングするための仕様書」のマトハズレ具合を教えてくれる。仕様書の本質は「システムのあり方を人間に示す説明資料を兼ねた、機械への動作指図書」であって、「プログラムの製造指図書」ではない。30年前なら後者のような理解もふつうだったが、今でもそんな思い込みにしたがって体制化されている職場が竪穴式住居のように残っている。未来ある若者にはそういう場所で馬齢を重ねてほしくないものだ。

 「仕様書の代わりになるように、わかりやすくコードを書こう」と言いたいのではない。あなたが書くものが何であれ、それが「(人間にとっての)端正な仕様説明書」であると同時に「(機械にとっての)構文上間違いのない動作指図書」となるような技術的体制を実現しようと言っているのである。ソフトウエアはそれが可能な稀有な実体であって、その有利性を開発事業において生かさない手はない。仕様書の書き手とコードの書き手が分離しているという旧弊たる分業体制は、ソフトウエアの特性をあまりに無視している。

 けっきょく、「製造」とも「建築」とも「科学研究」とも違う、という話になってしまったが、それにしてもシステム開発が他の何にも似ていない独特なものと考えるのは短絡である。当然ながらどんな活動にも、他の活動と似ているところもあるし独特なところもある。「我々の日々の営みは、他の何にも喩えられない独特な活動である」といった見方は、子供っぽくオメデタイ幻想でしかない。この「ありきたりな活動」の特性を理解して効率改善を図るためには、さまざまなものに喩えて、本質をあぶりださねばならない。

|

« 「他人にとってのわかりやすさ」が至上の価値である | トップページ | 「命名標準」に振り回されないために »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/87674/64875106

この記事へのトラックバック一覧です: 「科学研究」としてのシステム開発:

« 「他人にとってのわかりやすさ」が至上の価値である | トップページ | 「命名標準」に振り回されないために »