« 複合主キー「否定派」と「許容派」の論争 | トップページ | システムの仕様情報を正規化する »

2014.01.07

「仕様書プログラミング」とその運命

 米国の確定申告は複雑なので、確定申告用ソフトの開発が奨励され、使いやすいツールがいろいろ登場した。そのため、確定申告の有償支援サービスがあらかた要らなくなって、この5年間で8万人の公認会計士(CPA)が職を失ったという。訴求力のある専門性を持っているか、創造的な役割を果たせる会計士しか生き残れないだろうと言われている。

 わざわざこんな例を挙げるまでもなく、コンピュータが人々の仕事を奪い続けてきたことは広く知られた事実である。そんな動きに関してコンピュータの売り手は「機械的で退屈な仕事は機械にまかせ、人間は創造的な活動に邁進すればよい」と語ってきた。いかにも対岸の火事を眺めるようなお気楽な言い草だし、本来は自発的であるはずの創造性の発揮が強制されるなんて勘弁してほしい。

 とはいえ当然ながら、ソフトウエアの作り手にもこの「創造性の強制」は及んでいる。機械的で退屈なプログラミングがコンピュータによる自動処理に置き換えられ、良くも悪くも創造性が求められるプログラミングしか残らなくなる。それは機械語やアセンブラから途切れず続く言語の高級化にともなう必然である。

 本来のプログラミングには創造性が求められるはずなのに、そもそも「機械的で退屈なプログラミング」なんてものがあるのか。近いものが身近にある。ExcelやWordといった汎用ツールで書かれた「仕様書」を眺めながら行うプログラミングだ。業務システム開発において、昔からこの「仕様書プログラミング」は巨大な工数比を占めてきた。

 「いや待ってくれ。私に与えられる仕様書は不備だらけで、それを補完するためにおおいに創造性を発揮している」という意見があるかもしれない。それはそのとおりだろう。仕事にやり甲斐もあろう。

 しかし、けっきょくその創造性は仕様書の不備ゆえに求められている。もし不備のない仕様書(誰が実装しても設計者が意図したとおりのプログラムが出来上がる仕様書)が用意されたらどうか。プログラミングの過程はひどく機械的になって、やり甲斐や「不備へのイライラ感」に代わって「緻密過ぎることへのウンザリ感」に悩まされるだろう。まあじっさいはそんな仕様書を書くには労力がかかり過ぎるので、多かれ少なかれ不備が残らざるを得ない。それゆえ仕様書プログラミングには、やり甲斐とイライラ感とウンザリ感とが交錯する。

◆アジャイルで救われるか

 仕様書プログラミングのそんな根源的不全感を打破する手法として「アジャイル」が期待されている。それで「事前にこまごまと仕様書を書く必要はない。メモでじゅうぶん。動くコードを書きながら、あるべき仕様を探ればよい」といった主張がなされたりする。

 耳に心地よく響くかもしれないが、この開発スタイルは困った事態を招く。業務システム開発において、仕様書をはじめとする包括的ドキュメントは決定的に重要だからだ。病気や事故といったさまざまな理由で、保守担当者はある日突然職場に来なくなるものだ。そんなとき、包括的ドキュメントが整備されていなければ、残された人々は途方にくれるしかない。

 「そんな事態になったとしても、私のコードを見れば仕様はわかりますよ」と担当者は言うかもしれない。しかし、仮に彼の端正なコードが後任者によって理解できたとしても、「代々の担当」によって適切に維持されるとは限らない。じっさい業務システムは、第三者にとっての可読性の低さゆえに、保守担当者の雇用意義を強化するためのダシにされやすい(なにしろ担当者にその意図がなくてもそうなる)。担当者の退職後に保守できなくなって事業の足をひっぱっているシステムはそこらじゅうにある。アジャイルがそれを助長しないといえるだろうか。

 「必要に応じてコードからドキュメントを生成すればよい」と考えた方がおられるかもしれないが、悪手である。わかりにくい日本語の文章を外国語に自動翻訳すれば、さらにわかりにくくなる。それと同じく、わかりにくいコードからは、さらにわかりにくくしかも膨大なドキュメントが生成されるだけの話だ。かといって、コードから手作業で仕様書を起こすやり方も現実的ではない。仕様書を修正することが強制されていないため、遅かれ早かれコードと仕様書とが乖離する。けっきょく、コードを書いた当人にしか保守できなくなる。そして彼はある日職場から姿を消す。

◆「コード駆動」から「仕様書駆動」へ

 繰り返そう。事業活動のインフラである業務システムには、仕様書をはじめとする包括的ドキュメントが欠かせない。なぜか。ソフトウエアとして複雑巨大でありながら、第三者による保守の容易さが担保されていなければならないからだ。そして、業務システムが支援する事業活動は常に変化・発展するものだからだ。

 ということであればシステム開発者は、手間ひまかけて仕様書を書いて、これにもとづいて手間ひまかけてプログラミングするやり方とは手を切れないのか。しかもそこまでしても、保守フェーズでのコードと仕様書の乖離が避けがたいのだ。どうしたらいいのか。

 うまい手がある。前々回の記事で説明したような「仕様書でシステムを駆動するための開発基盤」を事前にプログラミングしてしまえばよい。これによって、それまでなしくずし的に受け入れられてきた「コード駆動」から、コンピュータに支援された実際的な「仕様書駆動」へのアーキテクチャの転換が起こる。

 その結果、仕様書プログラミングが要らなくなるだけでなく、仕様書の作成過程までが合理化される。基盤においてシステムのあり方についての類型化やイディオム化が徹底されているので、最小限の仕様を規定すれば、動作に必要な諸条件が自動的に補完されるためだ。また、専用のCADツールを使うことになるので、仕様要素間の整合性維持も格段に楽になる。いったんこれに慣れると、ExcelやWordで仕様書を書くやり方の非効率さと素人臭さに耐えられなくなるだろう。

 ただし私は「仕様書駆動」においても、個々の案件をノンプログラミングで扱えるようになるとは考えていない。ある種のビジネスルールは、プログラミング言語でしか正確に記述できないからだ。ゆえに、仕様書で制御できる領域をなるべく広げ、コードでしか表現できない領域をなるべく狭める――そのために、プログラミングのパワーやアジャイルの知恵を利用するのである。

 仕様書駆動の利点はまだまだある。「動くコード」ならぬ「動く仕様書」で仕様の妥当性を即座に検証できる。仕様書とシステムの動きとの間に乖離が生じ得ない。仕様変更を気兼ねなくやれる。仕様書が充実しているので担当者の交代にも対処しやすい。将来的にシステムを別の基盤上で再構築することになったとしても分析コストが少なく済む。

◆プログラミングによる合理化は止まらない

 良いことづくめに思えるが、この枠組みが普及する過程である種の苦労ももたらされる。設計と実装が融合するとともに生産性が格段に高まるため、開発人員が極端に少数で済む(無駄にコストを増やすので余剰人員は要らない)。そのため技術者は、要件定義からプログラミングまで幅広いスキルを身につけておかねばならない。仕様書プログラミングを前提とするPG,SE,SA,PMの分業体制にこだわってはいられない。ユーザと協働するための成熟した社会性も求められる。

 見方によれば厳しい。しかしこれもまた、米国で大量の会計士が職を失ったのと同じく、強力な合理化手段としてのプログラミングの苛烈な一面がもたらす現実だろう。そしてそれはけっして見慣れぬ風景ではない。われわれ自身、言語の高級化によって合理化され、鍛えられ続けてきたではないか。次は旧態依然とした業界のあり方が合理化される番かもしれない。プログラミングの可能性と破壊力を侮ってはいけない。

|

« 複合主キー「否定派」と「許容派」の論争 | トップページ | システムの仕様情報を正規化する »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「仕様書プログラミング」とその運命:

« 複合主キー「否定派」と「許容派」の論争 | トップページ | システムの仕様情報を正規化する »