« 「実装独立」な設計を用意することの意義 | トップページ | 「CONCEPTWARE/財務管理」は無償で公開 »

2005.08.13

「実装独立」な設計をまとめるのは誰か

最新の実装技術を用いて、既存の業務システムを刷新する。または、最新の実装技術に合わせて業務プロセスを改善したうえでシステムを刷新する。この課題をより安価かつ確実にこなすために「実装独立な設計文書」を事前にまとめておいたらいい。それが前回の話だった。ではその文書を、誰がどういうタイミングでまとめるべきなのか。

◆実装担当ベンダーに丸投げすべきではない

システムを刷新することが決まって、数社のシステムベンダーに概要を説明したうえで見積りしてもらう。その中からいちばん安めで工期が短めな提案をしたベンダーに、要件定義から導入までを一括委託する。これは今でも珍しくない「一括発注方式」とでも言うべきやり方だが、ユーザーとベンダー双方にとって問題が多すぎる。開発されるべきシステムのイメージが不明確なままで無理やり見積もられたコストや工期がアテにならない点は言うまでもないが、ここで取り上げたいのはそれとは別の問題だ。

その体制で「実装独立な設計文書」が用意されるとは考えにくい――という問題である。仮にユーザー側がその作成を正式に依頼してあるとしても不安は残る。なぜなら、作成されたものがほんとうに「実装独立」であるかどうかを検証する方法がないからだ。だいたい、実装までを担当することがすでに決まっているのであれば、ベンダーはプログラミングやテストのしやすさだけを主眼にした設計文書だけを残そうとするだろう。ベンダーにとっては当座の案件のシステムを稼動させることが最重要で、将来の実装技術の変化にともなうシステム刷新のしやすさなんて二の次三の次だからだ。結果的に、システムのあり方を概観できるような設計文書(基本設計書)がまともに作られないままに実装が始まって、完成してから「我々が欲していたものはこういうものではない」と言われてしまう。

もしユーザーがうまく立ち回って、実効的な基本設計書を作ることを要求すれば、多くのベンダーはかえって困惑してしまうだろう。なぜなら、彼らはそれを作るための技術を持っていないし、そもそもそれは彼らの専門ではないからだ。システムベンダーは限られた種類の実装手段に特化して、開発案件の受注と完遂をはかる。だから、「実装独立なシステムの論理構造を構想する技術」を習得するための強い動機が彼らにはない。これはべつにベンダーが自己研鑽を怠っているのではなく、経済主体としての自然なあり方というだけにすぎない。

◆ユーザー企業が主体となってまとめる

そういうわけなので、「実装独立な設計文書」のとりまとめは開発プロジェクトの前半の課題として、ユーザー企業によって主体的になされるべきだ。情報システム部員がいるならば彼らが難しい部分を担当すればいい。そのような要員がいないのなら、基本設計を専業にしているベンダーや腕のいいITコンサルタントに支援してもらいながら作ればいい。

そのうえで、仕様変更の管理方針や、ベンダーとユーザーとの役割分担を明確にした資料なども添えて、あらためて何社かの実装ベンダーに見積もりを依頼する。その際、基本設計書のとりまとめに関わったベンダーは意図的に入札から除外する。「どんなシステムであるべきか」は基本設計書で謳われているので、ベンダーにはそれを実現するためのコストや実装方法の有効性、および基本設計の整合性検査能力を具体的にうったえる。ユーザーはそれらの提案をトータルに評価して委託先を決定する。この体制を「分離発注方式」と呼んでおこう。

◆設計に「三要素」を盛り込むことの意義をサンプルで確認する

分離発注方式の場合、別のベンダーによって監修された低品質な設計文書にもとづいて後続工程を実施するハメにならないような工夫が要る。実際、ページ数や見てくれだけはご立派な「なんちゃって要件定義書」や「なんちゃって基本設計書」の例を筆者もいろいろと見聞きしたし、そういうものに苦労させられたひとりでもある。だからこそ、前回説明したように「基本設計書には何を盛り込むべきか」を重要視しているのである。

論より証拠。筆者の言う「業務システムの三要素(業務構成、データ構成、機能構成)」が盛り込まれた、基本設計書のサンプルをXEADで確認してみてほしい。sample.xeadという付録のコンテンツでもいいし、近々に公開予定の財務システム向けのレファレンスモデル「CONCEPTWARE/財務管理」でもいい。「三要素」を盛り込んだ基本設計書の効果とともに、企業が自社の業務システムをこのような形で掌握しておくことの意義を理解してもらえるだろう。

|

« 「実装独立」な設計を用意することの意義 | トップページ | 「CONCEPTWARE/財務管理」は無償で公開 »

コメント

実装独立な設計を実施する主体はユーザ企業であるべきというご意見に全面的に賛同します。
しかし、外部の協力を得てやれば良いとしても情報システム部門に、それをやるだけの権限と意欲と人材が不足しています。
ましてや、情報システム部門がない会社では業務部門に「自社で実装独立な設計を実施すべし」という意識を求めるのは、さらに難しいことに思えます。
情報システムに対する企業としての意識が変らないといけないのでしょうね。

投稿: motomura | 2005.08.17 11:07

本村さん

既存システムを刷新する際に、システムの設計思想がまるで理解できないゆえに、必要以上に高いコストをかけて再分析せざるを得なかった...実際にそういう痛い目に会うまで、実装独立な設計に対する企業人の意識は変わらないような気もしますね。とはいえ、CONCEPTWAREみたいなレファレンスモデルが流通し始めたら、また様相は違ってくるとも期待しています。

投稿: わたなべ | 2005.08.18 18:21

業務定義書を作成しているのですが、業務定義書と操作マニュアルとを分けるかどうかで悩んでいます。操作マニュアルとなると、説明が画面の項目単位になってしまい、頁数が増えるし、業務フローレベルではあまり設計や製造の役には立ちにくいので。

投稿: mkato | 2005.09.12 14:34

mkatoさん

画面のあり方を項目やコントロールのレベルで説明したものが操作マニュアルだし、それぞれの業務において手順をどのように遂行すべきか(画面をどのように使うかを含め)を説明したものが業務マニュアル(業務定義書)です。さらに、各業務がどのように連係しているかを俯瞰するための資料が業務フローです。実装工程において最終的に仕上げられる操作マニュアルや業務定義書よりは、基本設計のそれらは多少雑駁なものにはなりますが、基本設計の妥当性を評価するためにいずれもはずせません。

投稿: わたなべ | 2005.09.12 22:01

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「実装独立」な設計をまとめるのは誰か:

» [開発]実装から独立した設計?(その2) [カレーなる辛口Javaな転職日記]
http://watanabek.cocolog-nifty.com/blog/2005/08/post_040b.html なぜなら、作成されたものがほんとうに「実装独立」であるかどうかを検証する方法がないからだ。 検証する必要はない.真の意味で「実装独立な設計」などはまずあり得ない.よって検証するまでもなく,常に「実装独立でない」と判定しておけばほぼ100%あたる.ほとんどサハラ砂漠の天気予報. だいたい、実装までを担当することがすでに決まっているのであれば、ベンダーはプログラミングやテ... [続きを読む]

受信: 2005.08.13 22:44

» [process] [Real Java Development]
・・・この課題をより安価かつ確実にこなすために「実装独立な設計文書」を事前にまとめておいたらいい。 (中略) 筆者の言う「業務システムの三要素(業務構成、データ構成、機能構成)」が盛り込まれた、基本設計書のサンプルをXEADで確認してみてほしい 真の意味で「実装独立な設計」などはまずあり得ない. 同じ設計と言っても、前者は外部設計に着目しているのに対し、後者は内部設計に着目していると見受けられる。ものづくりの観点では両方合わせて設計として成り立つのであるが、情報システム開発では要件が不確定なことが... [続きを読む]

受信: 2005.08.14 00:27

« 「実装独立」な設計を用意することの意義 | トップページ | 「CONCEPTWARE/財務管理」は無償で公開 »