System Design ..Details, Details

By Russ Finney

システム設計 ..詳細、詳細..

Lawerence D. Bell once remarked, "show me a man who cannot bother to do little things and I'll show you a man who cannot be trusted to do big things". During the technical design phase details are important and cannot be taken for granted. No loose ends should exist when the system programming begins. Joel Ross and Michael Kampi in a recent book, Corporate Management in Crisis: Why the Mighty Fall, stated their belief that "attention to details is not nitpicking but an essential and vital part of successful management". This is an important message for the system builder. Paying attention to details is not an easy job, it takes discipline as well as tact. The project team must keep a keen focus on the details during the upcoming design process.
かつてLawerence D. Bellは、「小さな仕事を嫌がる奴を教えてくれれば、大きな仕事を頼めない奴を教えてやるよ。」と言った。技術設計においては、詳細事項は重要で、しかもじっとしていて与えられるものではない。未解決の点があっては、システムプログラミングは始められない。Joel Ross と Michael Kampiは、最近の著書 Corporate Management in Crisis: Why the Mighty Fallで、「詳細事項に注目するのはあら捜しではなく、堅実な管理には重大かつ不可欠なのである。」と、かれらの主張を述べている。これは、システム構築者にとって重要なメッセージである。詳細に配慮するのは、簡単な事ではない。それは日頃の意識と共に臭覚が必要である。プロジェクトチームは、これからの設計作業の間ずっと詳細事項にも大きな関心を払っておかなければならない。

Up to this point everything has been pure speculation. A solid "vision" describing what the system will do, and what the major components will look like, is in place. A vast gap remains, however, between this "vision" and the actual technical realities of implementation. Bridging this gap is Technical Design. This phase focuses completely on making the system a reality. By the completion of the phase, no detailed questions should remain about how a screen will operate, or where information will come from on a report, or how a program will perform required calculations, or any of great number of other detailed issues. The completion of Technical Design means that every individual system component has been completely thought through, documented, reviewed, and finalized.
ここ迄は、全てが頭の中で展開されてきた。「システムが何をするのか、主要な構成要素がどの様なものか」が判る「構想」を纏めた。しかし、この「構想」と実際に導入するシステムの間には、大きなギャップがある。これを結ぶのが、技術設計である。このフェーズではシステムを現実のものにする事に全力を傾ける。このフェーズの終了時には、「画面が動くか」、「報告書のデータは何処から持ってくるのか」、「必要な計算をプログラムにどう書くか」、その他諸々の詳細事項について、いささかの疑問も残すべきでない。全てのシステムの構成要素の徹底的な検討、文書化、レビュー、最終確認が済んだ時、技術設計が終了する。

Many a project manager has suffered the fate of placing his or her success into the hands of the promised "experienced" programmer or the "intelligent" code generator. The temptation is to leave the details until later in order to gain time within the phase. But then the unexpected happens, construction begins, and a key analyst leaves the project, or programmers are assigned who don't understand the technology or the required functionality. Not only are extraordinary amounts of time necessary to stay on top of the construction effort, but the possibility of key requirements being overlooked just increased dramatically! This situation, while it can be overcome in some cases, is all to often the cause of a system disaster in a great many others.
多くのプロジェクトマネージャが、約束された「経験豊富な」プログラマや、「知的な」コードジェネレータの手に、自分の成功を委ねてしまい失敗の憂き目にあった。当面のフェーズの時間を稼ぐ為、詳細を後回しにしたくなる。だが、そうすると次に、不測の事態が起きてしまう。構築作業に入って、中心になるアナリストがプロジェクトを去ったり、技術や機能要件を判っていないプログラマが配属されて来りする。これでは，構築作業を率いるのに非常に多くの時間が掛かるばかりか、重要な要件を見落とす可能性が劇的に増加してしまう! この状況は、何とか凌げる場合もあるが、しばしば大失敗の引き金となる。

Why capture the details now?
何故、詳細が今要るのか？

Here are seven good reasons:
良い答えを７つ掲げる：

1. Most of the details are floating around in people's heads just waiting to be written down.
2. Once the details are on paper they can be reviewed by the other team members and the business clients.
3. A consistent approach to common situations will begin to emerge.
4. New people can be brought in during construction with greater ease if the details are documented and available.
5. It is psychologically relieving to the analysts not to have to carry large amounts of complex detailed information around in their heads.
6. Problem areas, inaccuracies, incomplete analysis, and bad assumptions will be discovered for resolution now, rather than when they could become project sinkers.
7. A sense of completeness is experienced by the team when all of the details are complete, documented, organized, and accessible.

1. 詳細事項の大部分は、人々の頭の中に締ってあって文書に記録される事をじっと待っている。
2. 一旦、紙に書き出されると他のチームメンバーやエンドユーザーによって検討される事が可能になる。
3. 似た様な状況に対して、一貫した手法が考案されるきっかけとなる。
4. もし詳細事項が文書化され参照出来れば、構築作業の途中から参加する人達の負荷が大きく軽減される。
5. 複雑で詳細な大量の情報を頭に入れておく必要が無くなれば、アナリスト達の心理的な負担が軽減される。
6. 問題箇所、不正確さ、不十分な分析、誤解などが見つかり、プロジェクトの足を引っ張る前に、直ぐ対策が打てる。
7. 詳細事項が全て解決し、記録、整理され、参照出来る様になった時点で、チームは、達成感を味わえる。

This is the Fun Part: Creativeness Counts!
ここは面白い部分だ：創造性が物を言う！

Generally, during the design process, creative ideas tend to come in two forms. The first is as a completely new and original approach to a technical or a business problem. The second is as a variation of a familiar approach, with a slight degree of enhancement to give the idea a fresh new "twist". In either case, the technical designers are primarily concerned with developing creative solutions to support complex business requirements.
一般に、設計段階では、創造的な考えは２つの形で提案される。第１は、技術や業務の問題に対する全く新しい独創的な手法としてである。第２は、良く知られた手法に少し手を加え新しい"使い方"をもった変形としてである。どちらにせよ、技術設計者は、元来、複雑な業務要件を満たす為、創造的な解決策を模索している。

In order for this effort to result in the highest quality system possible, the sensible reuse of pre-developed modules (or "classes"), the creation of innovative program designs, and the development of advanced algorithmetic routines, should be encouraged throughout the design process. This "creative thinking" stimulates the team through intellectual challenge, and it encourages technical "breakthrough" solutions to the especially thorny situations. This aspect of the development process tends to be one which system builders thrive on! (Even though quite a few grumble about having to "think" so deeply and intensely - secretly, they wouldn't have it any other way).
この努力を出来るだけ質の高いシステムに結びつける為、開発済みモジュール(または"クラス")の意図的な再利用、革新的なプログラム設計の作成、高度なアルゴリズムを採用したプログラムの開発などが、設計段階を通して奨励されるべきである。この「創造的な考え」は、知的な課題でチームを刺激し、とりわけ困難な問題に対して「抜本的な」技術的解法が出易くする。開発作業のこの見方こそ、システム構築者の拠り所になるものだろう！ (非常な細部まで、一心に、−人知れず−「考える」事に、大勢の者が、文句を言っていても、彼らには他に方法がないのである。)

Sometimes, new ideas appear which are merely cloaked forms of old, trusted, well-used approaches. It may be a routine to control a cursor position, or a highly efficient database call, or an extremely fast algorithm, all of which may have already been completely thought through during a prior project. The system builder should not hesitate to reach into this "grab bag" of past designs for proven innovative ideas. After all, as playright Gene Fowler liked to remark, "if they haven't heard it before, its original!" This reduces the team drift toward creativeness for the sake of creativeness, and it keeps the precious, inventive focus on the areas which truly require unique, specialized solutions.
時々、新しい考えが、既存の、信頼のある、多用されている手法が外見を替えただけだったりする。カーソル位置の制御、 高効率のデータベース呼び出し、非常に高速のアルゴリズムなどが考えられる。それらは、先行のプロジェクトで既に十分に検討されたものであるだろう。システム構築者は、実証済みの革新的な考えを得るのに過去の設計を詰めた「福袋」を見るのをためらってはならない。兎に角、脚本家Gene Fowlerが好んで言った様に、「聞いた事がなければ、それはオリジナルなのである。」 この言葉は、チームが「創造性の為の創造性」を求めて横道に逸れるのを防ぎ、貴重で斬新な考えを本当にユニークで特殊な解法が必要な所に適用するのに役立つ。

The Precedent Sets the Principle
前例が原則になる

Benjamin Disraeli, in a 1848 speech to the British House of Commons, once exclaimed, "A precedent embalms a principle!" This warning should have a special meaning to the system builder who is striving for a consistent design.
Benjamin Disraeliは、1848年、イギリスの下院の演説で、「先例は原理をミイラにする!」と主張した。この警告は一貫性のある設計を目指しているシステム構築者にとって特別な意味を持っている。

Set the program specification level of detail expectations as early in the technical design process as possible. The designers want to know before they begin how far they need to take their specifications. They are only willing to take them to the level of detail which makes sense for the situation at hand. Any further they will consider a waste of time.
技術設計の出来るだけ速い時期に、プログラム仕様書に具体的に何を含むかそのレベルを決めなさい。設計者は、仕様書に着手する前にどの程度の事項を盛り込むか知りたがる。彼らは、そこで必要とされている内容を満足する事しか考えていない。それ以上は、時間の浪費と考えている。

Some "rules of thumb" for appropriate level of detail determination are list below:
詳細さについて適切なレベルを決める幾つかの「経験則」を以下に掲げる：

High Level of Detail Situations:
高度な詳細化

• Hand coded third generation language programming
• Complex database access statements


• 第３世代言語のプログラムのコード
• 複雑なデータベースアクセス文

Moderate Level of Detail Situations:
中程度の詳細化

• Hand coded fourth generation language programming
• Action diagrams already provided
• Straightforward database access


• 第４世代言語のプログラムのコード
• 既存のアクションダイアグラム（動作遷移）
• データベースアクセスの(言葉での)記述

Low Level of Detail Situations:
低度の詳細化

• Code generation using a screen/database/report painter


• 画面/データベース/報告書ペインターを使って作成したコード

In addition, the following tips should be followed in order to encourage the correct design depth during this phase of the project:
加えて、このフェーズで適切な設計の詳細さを保つ為、以下の点を守る必要がある。

• Set up clear and reasonable milestone dates for each of the assigned program specification tasks.
• Establish the specification walk-thru approach which will be utilized by the team throughout the technical design process, before the first specification is even written.
• Complete a first draft of the programming standards which will be followed during system construction, in order to make sure that the technical specifications are initially in line with the anticipated programming approach.


• 全てのプログラム仕様書作成作業に明確かつ妥当なマイルストーンを設定する。
• 最初の仕様書が出来る前に、技術設計作業を通して実施される仕様のウォークスルー手法を導入しておく
• 技術仕様書が、最初から予想されるプログラミング手法に沿ったものになる様、システム構築作業を通して遵守されるプログラミング規準のドラフトの初版を完成させておく。

Copyright © 1999, Russ Finney, All Rights Reserved