危機の本質 ソフトウェアとコトバ – 13

IT記者会Report(http://itkisyakai.org)掲載の岸田孝一氏(SRA)のエッセイが50回目となりました。
健筆健在を祝して、今回だけ公開します(通常は登録会員に公開)。


危機の本質 ソフトウェアとコトバ – 13

 「ソフトウェア工学」の概念が提唱されたのは、1960年代の末にヨーロッパで2回にわたって開催されたNATO科学委員会主催のワークショップであった. その背景には,コンピュータ・ハードウェアの高性能化にともなって次第に巨大化・複雑化してきたソフトウェアの開発があちこちで納期の遅れや品質の問題などの深刻なトラブルを引き起こすという事実が存在した.

 しかし,オルテガ=イ=ガセットが,ガリレオ・ガリレイについての考察を述べた一連の連続講義の冒頭で指摘したように,事実はそのまま現実であるわけではない.むしろ逆に,現実を隠蔽する働きをする(『危機の本質 − ガリレイをめぐって』,オルテガ著作集4,白水社所収).オルテガによれば,事実とは,ヒエログラフに刻まれた絵文字のようなものである.それは、きわめて明瞭な輪郭をわれわれの目にはっきりと示しているが,その明瞭な外観が,まさにわれわれを大きな謎の前に立たせ,困惑させるのである.たとえば,空の上の天体の動きは,太古の昔から人間の眼の前に明確な事実として存在していた.しかし,コペルニクスが地動説のモデルを提唱するまで,その事実の背後にある現実は明らかにならず,さまざまな謎として人びとを混乱させただけであった.

 事実によって隠された現実を発見するためには,われわれは,ひとまず事実をほうっておいて,自己の内面に沈潜する必要がある.そうして,想像力を駆使して自分自身にとっての現実を作り上げる作業にとりかかる.やがて,空想世界におけるその現実がもたらす事実がどのようなものかが理解できたとき,初めてそれを周囲に見られる事実と比較することが可能になる.両者が一致すれば,象形文字の謎が解かれ,隠されていた現実が見出されたことになるのだと,オルテガは述べている.

 Empirical Software Engineering とか,プロセスの「見える化」とかいったキャチフレーズに踊らされている方々は,オルテガのこの指摘を十分に噛みしめたほうがよい.経験や見える化によって目の前に提示された事実をそのまま現実だと誤解してしまうことの危険に人びとはまだ気づいていないように思われる.

 さて,ソフトウェアの歴史に目を戻すことにしよう.1957年に創刊されたアメリカ計算機学会の機関誌 CACM に1960年代に掲載された注目すべき論文のリストが Wikipedia の挙げられている:

 “Quicksort" (C.A.R. Hoare, 1961)
 “DPLL Algorithm” (Martin Davis et.al, 1962)
 “ALGOL 60 Revised Report” (J.Backus et.al, 1963)
 “Original Paper on Simula-67” (O.J.Dahl et.al, 1966)
 ”Structured Program Theorem” (C.Bohm et.al, 1966)
 “GOTO Letter” (E.W.Dijkstra, 1966)
 “THE Operating System” (E.W. Dijkstra, 1968)


 このリストを眺めて,まず気づかされることは,1960年代におけるソフトウェ技術開発が,コンピュータという新しい「知的玩具」を動かすために必要なプログラムをどうしたらきちんと作れるかという問題に焦点を当てて進められていたという事実である.その背後には,コンピュータ・プログラミング(ソフトウェア開発)という仕事が,だれにでもできるやさしい仕事ではなく,しかるべき技法やツール(プログラムング言語も含めて)の整備が必要だという現実認識があった.

 もうひとつ,上記のリストに挙げられた論文のほとんどがヨーロッパからの投稿であったということも重要な事実である.おそらくそれは,コンピュータ・ハードウェアの開発やさまざまな分野への応用のスピードが,アメリカや日本と比較してゆるやかであり,人びとにこの新しい技術の本質について考える時間的余裕を与えたからではないかと考えられる.

 1968年(ドイツ)および1969年(イタリア)で2回にわたって開催され,世の中に「ソフトウェア危機」というキャッチフレーズをアピールしたワークショップがヨーロッパの主宰で開催されたという事実は,危機意識の高まりがどのあたりにあったのかを物語っている.人びとの頭のなかには,(1) 技術やツールの整備の遅れ,そして(2) 開発に必要な人材の不足,という現実認識があった.そのことは,たとえばこのワークショップが終わってすぐに開催されたソフトウエァ工学セミナーの内容を見れば明らかである.このセミナーのテキストは “Software Engineering: An Advanced Course” として出版されている (Springer, 1975).わたし自身そのころ新しいOSの試作開発に携わっていたので,同書におさめられた Dijkstra の論文 “Cooperating Sequencial Processes” に大きな刺激を受けたことを覚えている.しかし,周囲を見回してみると,このテキストを真剣に読んでいる人間は(少なくとも日本では)残念ながら見あたらなかった.

 1960年代半ば以降,コンピュータ・ハードウェアの進歩は急激に進み,社会的ニーズの増大にともなって,さまざまな分野への応用が本格化した.しかし,技法やツールの整備そして必要な人材の育成という問題は依然として未解決のままであり,あちこちでソフトウェア開発プロジェクトの深刻なトラブルが多発した.そうした「危機」的状況にどうやって対応すべきかについて,アメリカ側の考え方はヨーロッパの視点とはかなり異なっていた.十分な教育を受けていない技術者たちが未熟な技法やツールを用いて,指定された期間内に開発を終わらせるべく悪戦苦闘している事実を,ひとまず Given Condition として受け入れる.その上で,自動化ツールによる生産性の向上や新しいテスト技法を用いた品質保証,定量的マネジメントによる納期管理を試みてみたらどうかというのが,アメリカや日本などコンピュータ利用先進国サイドの人びとの現実認識だったのである.

 いわゆる「ソフトウェア危機」の本質にかかわるこうした認識のギャップは,その後のソフトウェア工学発展の道筋を考えるさいに大きな影響を及ぼした.1987年カリフォルニア(モントレー)で開かれた第9回ICSEのオープニング・セッションが終わったとき,Dijkstra流の構造化プログラミングを現場で実践することに熱心だった Harlan Mills (IBM) が「どうしてこの場にDijkstra をはじめとする ACM Turing 賞の受賞者がひとりも顔を見せないのか?」と,プログラム委員長だったわたしに文句をいっていたことを思い出す.

アクセスカウンター