ＤＲＩ通信４７号「要件定義」２０００．８．１
やや早めに梅雨が明けて、非常に暑い日々が続いています。そのなかで風邪
を引いたりしている人もありますが、皆様お元気ですか。森総理もＩＴとい
うご時世、情報関係の景気はやや持ち直しているように感じます。
さて今月は、要件定義という題で、システム開発方法論を考えてみます。わ
れわれ、しばしば大手ＳＩのプロジェクトの上流工程で、データモデリング
のお手伝いをさせて頂くことがありますが、不思議に思うことがあります。
それは、進捗管理がガントチャートで行われ、ＰＥＲＴ図が使われない、そ
のためいつまでに要件定義が終わるのか、どのようなドキュメントが作られ
るのか、がはっきりしない、ということです。永らくその理由を考えていま
したが、ふと最近そのヒントらしきものを見つけました。そこでその仮説を
述べ、皆様のご意見を伺いたいと思った次第です。
要件には、性能要件やコスト要件もありますが、ここでは機能要件だけを考
えます。企業は「 顧客ニーズに基づく良い商品を安く速く作る」といった目
標のもとに、組織を作り分業しています。各組織はその業務遂行のために情報
を必要とし、またその業務遂行の結果発生した情報を報告します。必要な情報
はデータベースから読み取り、生成した情報はデータベースに書き込むとい
うのが、データ中心のアーキテクチャですが、次第にこの方向に進みつつあ
るといえるでしょう。
このときの情報は、人間が読み書きできるものですから、原則として画面・
帳票の形式をとります。したがって「要件定義とは、この画面・帳票をいつ
誰が誰当てに作るか、そこにはどのようなデータが記述されるか」になりま
す。「それがどのようなデータか、また他のデータとの関係いかに」を明ら
かにするためにデータモデリングが行われます。
ユーザはそのデータがメインフレームに存在するのか、ＮＴに存在するのか
に頓着する必要がありません。ユーザ要件とは、本質的に実装独立、概念レ
ベルのものといえます。ただし決してアバウトなものではありません。主要
項目だけあれば、あとはあっても無くても良い、製造担当者にお任せ、とい
うわけではありません。もちろん１００％全項目となると永遠に決まりませ
んが、当該プロジェクトで実装するものは、ユーザ要件としてユーザが決め
なければなりません。ユーザごとのニーズの違いはＤＡに調整してもらいます。
システム設計とは、目的を達成するためのアーキテクチャを定め、構成部品
を明らかし、実装に変換すること、すなわち次の（１）→（２）→（３）の
過程をとることであり、（２）が明らかにされるべきユーザ要件であると考え
ます。
概念 物理
概要 （１） （４）
詳細 （２） （３）
（１）→（２）は、業務モデルおよびデータモデルを用いて、個人差少なく実
施できます。（２）→（３）も、部品が固定されているので、やはり個人差
最小で、また精度高く所要工数見積を行うことができます。
ところが、先に述べた大手ＳＩは（２）を省略し、（１）→（３）または
（１）→（４）→（３）進め方を行っているように見えました。すなわち概
念は概要で済ませ、物理の世界に早期に入り、物理の世界で部品展開を行う
のです。おそらく担当者は永らく現行システムの開発・保守を通じて現行シ
ステムの物理、すなわち物理ファイルや物理プログラムになじみ、これから
の差分として新規システムを考えた方が得策であるとの計算、あるいはそれ
しかできないからかと思われました。
すなわち「マイナーな保守」に対する方法論「物理差分メンテナンス」を、
再構築や新規システム開発に適用しようとしている。「どうせ現行の物理環
境は大幅には変えられない、物理ファイルと物理プログラムを変更し動かせ
ば良いのだ」というのならば、ガントチャートを使うのが良く分かる。戸田
コンサルタントの言う「詳細設計決戦主義」や、折角作った概念ＤＢ構造図
を無視し、現行ファイルを持ち出してきて、これを修正して対応したがる理
由も良く分かります。
この方式であると、設計における詳細化は、実装環境／ソフトウエア環境で
行われる。どうしても機能分割になり、ＳＡのスキルに左右される。多忙な
スーパーＳＥが、分割を行うまでは、今後の作業が見えないから、ガントチ
ャートとして書くしかできない。その試行錯誤でやりなおしが頻発する。ユ
ーザは、ＩＴの混入するドキュメントであるため、十分レビューできず、実
装が終わってから、論理レベルの仕様変更が発生する。
われわれも（２）が完全に終わるまで（３）を開始すべきでない、とは考え
ていません。パーフォーマンス検討のため、早期に物理ファイルを作成し、
インデックスの張り方を試行するなどは大いに必要と考える。しかし（２）
はメンテナンス対象として完成すべきものと考える。メンテナンスは常に
（２）にもどって行う。
将来はＡＳＰによるアウトソーシングが、一般化すると考えますが、そのと
きのアウトソーシング契約は（２）によって行うべきと考えます。（２）は
どんなにアウトソーシングしても、ユーザ企業として、責任を持って管理す
べき最後の砦ではないでしょうか。
« 【第46号】３種の言語【第48号】リポジトリと方法論 »
