"実行可能な仕様書のライブラリ"を知的社会資本に“実行可能な仕様書”を作る!(3)(1/3 ページ)

» 2011年09月28日 12時00分 公開
[渡辺 幸三,@IT]

 業務システム開発の最大の問題は設計・開発手法ではなく、「レファレンスモデルの欠落」にある。それゆえ「スクラッチ開発」が十年一日のように繰り返されている。結果的にプロジェクトの成功率は低く、うつ病を患う技術者が減らない。これでは業界そのものが経済社会のお荷物でしかない。「実行可能な仕様書」は開発合理化だけでなく、レファレンスモデルのライブラリ化のための決め手となる。ライブラリが充実することで、ようやく業界は社会に貢献できる。そのとき求められる技術者は「優秀な単能工」ではなく「そこそこの多能工」である。

「仕様書管理システム」としての開発環境

 業務システムの開発・保守において、仕様書とプログラムコードとの不整合が生じやすいという問題が古くからある。保守担当者が交代していくことを考えれば、担当者がプログラムの仕様を端的に理解するために、様式化された仕様書がどうしても必要だ。仕様書とプログラムコードとを整合させ続ける――そのための労苦は避けられないのだろうか。

 第1回で、この問題の本質は、仕様書が苦労して書かれるわりに「そのまま実行できない」点にあると指摘した。そこで、仕様書そのものをプログラムとして実行できるような、すなわち「実行可能な仕様書」を書けるような開発基盤を用意すれば良いと提案した。そのためには「機能のパターン」を整理し、パターンごとに仕様書情報を様式化し、さらにそれらの解釈エンジンを開発すればよいと説明した。

 第2回では、機能のパターン化を推進するためには、データベースを正規化すると同時に、ビジネスロジックを機能定義側からテーブル定義側へ移行するといった、技術的配慮が鍵だと説明した。なぜならそうすることで、無駄に個性的だった多くのプログラムが「薄っぺらでありきたり」なものとなるからだ。また、ビジネスロジックをスクリプトで記述する必要性から、開発者は「設計できるプログラマ」でなければいけないとも指摘した。

 その結果、「仕様書作成作業」がそのまま「プログラミングおよびテスト作業」となる。そのとき「正しいシステム」とは「正しい仕様書の集まり」であり、開発環境そのものが保守フェーズに至るまで、一貫して「仕様書管理システム」である。

 当たり前のことを言っているようだが、従来との違いは大きい。これまではどんなに正しく読みやすい仕様書を書いても、それが適切にプログラミングされない限り「正しいシステム」は手に入らなかった。ところが「実行可能な仕様書」の基盤においては「正しい仕様書」を書くだけで「正しいシステム」が手に入る。

 「正しい仕様書」を書く過程も極めてアジャイルだ。仕様書作成の後にプログラミングが必要な場合、プログラムができ上がって動作させるまで、仕様の正しさを最終的には検証できない。ところが、「実行可能な仕様書」の基盤上では、仕様書を書くそばから実行して、仕様の正しさを検証できる。仕様確立のためのPDCAサイクルが圧倒的に短い。

もう1つの悪習――スクラッチ開発

 では、このような開発基盤(前回同様、この基盤をアプリケーションドライバと呼んでおこう)と「設計できるプログラマ」とを確保しさえすれば理想的なシステム開発のスタイルを実現できるかというと、まだ十分ではない。われわれがやるべきことがもう1つある。「スクラッチ開発」の非効率さに絶望することだ。

 「スクラッチ開発」とは、システムをイチから設計して実装するやり方を言うのだが、私に言わせたら、これも「エクセル方眼紙」や「無駄に個性的なプログラム」に並ぶ悪習である。アプリケーションドライバを活用したとしても、これまでと同じようにスクラッチ開発を繰り返すばかりでは、効果は限定的だ。

 もちろん「スクラッチ開発」にもいい所はある。何よりも、ユーザーの要望にきめ細かく応えられる点は変え難い利点だ。スクラッチ開発でしか手に入れることができないような業務システムも、確実に存在する。

 その反面、さまざまな問題がある。まず、工期が長く開発コストが高い。それに、分析・設計の不手際ゆえに使いにくいシステムができ上がるリスクが大きい。実際、かかわる技術者のスキルレベルが違えば、まるで違うものができ上がる。ユーザー企業にとって業務システムの開発は、有名SI企業に頼もうが小さなソフトハウスに頼もうが、同程度に期待値の低いギャンブルのようなものになってしまっている。また有能で責任感のある技術者たちが、乳鉢ですりつぶされるようなストレスからうつ病を患っている。

 それではあんまりだというわけで、リスク回避策として「パッケージ・カスタマイズ」が有力視されている。ERPなどの業務システムパッケージを購入して、これをカスタマイズするというやり方だ。多くのパッケージが「柔軟なカスタマイズ性」を謳っているし、うまくやれば導入期間も短く済む。

 しかし、ことはそれほど単純ではない。パッケージそのものが高価であるだけでなく、カスタマイズにかかるコストもばかにならない。また、比較的安価で済むカスタマイズ(テーラリング)にも限界があって、それを越えた修正に関しては「アドオン開発」という、さらに高価な開発作業が必要になる。神経質なほどにきめ細かい要件対応を求める日本企業の場合、開発コストはうなぎ上りである。つまるところ、そのコストパフォーマンスはスクラッチ開発と大して違わない。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ