« ビジネスリーダーに必要な「経営の3言語」 | トップページ | 「実装独立」な設計をまとめるのは誰か »

2005.08.06

「実装独立」な設計を用意することの意義

システムの企画・開発に際して「実装独立」の視点を持ち込むことは、業務システムを長期的に発展させるために有効な配慮だ。とくに「実装独立」な設計文書を用意することは、変転する実装技術の効果をより少ないコストで享受するための決め手となる。

◆「実装独立な前工程」としての上流工程

業務システムの開発工程は大きく「要件定義」、「設計」、「構築・テスト」、「導入・移行」、「保守」に分けて捉えられる。この中の「設計」はさらに2つに区分すると理解しやすい。これらを「基本設計/詳細設計」と呼び分けることに筆者は慣れているが、「論理設計/物理設計」などと呼ばれることもある。

呼び方が違っても、これらの区分の意味合いはだいたい同じで、要するに「実装手段に無関係な論理構造を定める」のが前半で、「規定の実装手段を用いてプログラミングできる程度の仕様を定める」のが後半である。TH手法の提唱者である椿正明博士の言う「実装独立」であるかどうかによる区分だ。

「実装独立であるかどうか」で「設計」を前後に区分して実践した場合、「前半の成果物」にもとづいて、任意の実装環境で「後半の成果物」を作成できるはずである。わかりやすく言えば、「前半の成果物」が示す内容を、COBOLでもCでも.NETでもJavaでも実装できるということになる。

まあ、原理的にはそうなのだが、「前半」において実装環境がおおまかにも決まっていないことがまずあり得ないため、「前半の成果物」には特定の実装環境の特性が多分に反映されているものだ。たとえば、実行環境のパネルがCUI系なのかGUI系なのかブラウザなのかくらいは企画段階から決まっているのがふつうで、そこらへんの違いで「前半の成果物」に含まれる機能構成の雰囲気もだいぶ違ってくるし、利用可能なプログラミング言語も限られてくる。

そのような実状があるにせよ、前半(基本設計または論理設計)と後半(詳細設計または物理設計)とで実装条件から受ける影響の度合いが大きく異なる点は重要だ。この区切りを以ってシステム開発の工程全体を「上流工程」と「下流工程」に分ける考え方もあって、筆者はこれにしたがっている。上流・下流の言い方は多少語弊があるので、前工程・後工程なんて呼び分けてもいいとは思う。しかし、水源や分水嶺を起点として、プロジェクトの進捗につれて実装手段の違いによる多様性が付加されてゆくイメージを喚起させるゆえに、筆者は「上流・下流」の呼び方が好きだ。

◆「実装独立な設計文書」とは

呼び方はどうであれ、このように区分することの意義はどんなところにあるのだろう。まず、「どんなシステムであるべきか」を検討する過程から実装上の諸問題を切り離すことで、設計問題をより単純化できる点を挙げられる。これに加えて、上流工程の成果物を「企業システムを発展させてゆくための基本論理モデル」として将来的に使いまわせるようになるという利点も見逃せない。

フレームワークやコンテナをはじめとして、今後も革新的な実装技術が後から後から登場して、実装工程の効率化・合理化はとどまらないだろう。ユーザー企業としては、その時その時での有効な実装技術を選定して活用しなければならない。

その際、実装独立な「企業システムとしての論理構造」が手元にあるとしたら、いちばん少ないコストで実装作業に入れる。長い目で見れば、実装技術の発展が論理構造の変更までを要請することもあるが、その場合でも、最新の実装技術にもとづく設計をいちからまとめるよりはずっと安価ですむ。

では、「実装独立な設計文書」にはどのような情報が盛り込まれるべきなのか。

1.業務構成(仕事の進め方や作業間の連係)
2.データ構成(帳簿組織の論理構造)
3.機能構成(パネルの基本イメージとパネル間の連係様式を含むプログラム構造)
これらの3つの要素(企業システムの3要素)を相互に矛盾なく、かつわかりやすく盛り込むべし――というのが、筆者の主張だ。詳細については「三要素分析法」の解説ページで読んでもらうとして、ここでは詳しくは述べない。

さて、ユーザー企業にとっては「実装独立な設計文書に何を盛り込むべきか」とともに、「実装独立な設計文書は誰によって作成されるべきか」が重大な問題だ。そしてここらへんの思慮不足が、開発プロジェクトの成功率が低いことの要因でもある。次回はその点について触れたい。

|

« ビジネスリーダーに必要な「経営の3言語」 | トップページ | 「実装独立」な設計をまとめるのは誰か »

コメント

せいさく0319と申します。
掲載されている日記を興味深く拝見させていただきました。事後の御連絡となりましたが、当方の記事にリンクをはらせていただき、日記を紹介させていただきました。

リンクをはらせていただいた件について、何か差しさわりがございましたら、その旨、御連絡ください。何分、ブログ初心者なもので、ご容赦ください。

また、よろしければ、今後とも、そちらのサイトを拝見させていただくつもりです。よろしくお願いいたします。

せいさく0319 
サイト名 気になるブログ10件
mail:noguchi0319@mail.goo.ne.jp 
http://plaza.rakuten.co.jp/kininaruburogu10/

投稿: せいさく0319 | 2005.08.06 19:24

はじめまして。
最後の段落の 「開発プロジェクトの失敗率が低い」は、「開発プロジェクトの失敗率が高い」の打ち間違いですよね?
皆気づいていて、取り違える人などいないと思いますが一応。

投稿: babie | 2005.08.09 16:38

babieさん、ご指摘ありがとうございます。さっそく修正しました。

投稿: わたなべ | 2005.08.09 19:13

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「実装独立」な設計を用意することの意義:

» 「実装独立」な設計を用意することの意義 [OPC Diary]
設計者の発言 - 「実装独立」な設計を用意することの意義 システムの企画・開発に... [続きを読む]

受信: 2005.08.08 18:32

» [ソフトウェア開発]「何を作るか」と「いかに作るか」 [酔狂人の異説]
ソフトウェア開発において、「何を作るか」とそれを実現する方法である「いかに作るか」とををきちんと区別すべきとよく言われる。最近も以下のようなエントリがそのことを話題にしている。 http://d.hatena.ne.jp/lf1310/20050807#1123392300 http://www.furukawa-select.com/mt/?p=394 http://d.hatena.ne.jp/lf1310/20050809#1123598191 http://watanabek.cocol... [続きを読む]

受信: 2005.08.11 06:25

» [開発]実装から独立した設計? [カレーなる辛口Javaな転職日記]
http://watanabek.cocolog-nifty.com/blog/ 「実装独立であるかどうか」で「設計」を前後に区分して実践した場合、「前半の成果物」にもとづいて、任意の実装環境で「後半の成果物」を作成できるはずである。 そうすると,前半分には何も残らない. 設計のほぼ100%を占める後半の成果物で後半の成果物を作成することになる.おや? まあ、原理的にはそうなのだが、「前半」において実装環境がおおまかにも決まっていないことがまずあり得ないため、 まあ原理的にはそうなのだが,... [続きを読む]

受信: 2005.08.13 00:08

» 「実装独立」な設計を用意することへの異議 [遅レス。]
greentea さんが、「[http://watanabek.cocolog-nifty.com/blog/2005/08/post_d453.html:title]」へ突っ込んでいる。 s/意義/異議/ って書きたかっただけ。 あえて言うとしたら、 まあ、原理的にはそうなのだが、「前半」において実装環境がおおまかにも決まっていないことがまずあり得ないため、「前半の成果物」には特定の実装環境の特性が多分に反映されているものだ。たとえば、実行環境のパネルがCUI系なのかGUI系なのかブラウ... [続きを読む]

受信: 2005.08.13 12:04

« ビジネスリーダーに必要な「経営の3言語」 | トップページ | 「実装独立」な設計をまとめるのは誰か »