川村渇真の「知性の泉」

システム設計:細部までの仕様を科学的に設計する


システム開発の中心的な要素

 システム開発の中心部分は、何と言ってもシステム設計だ。システム自体の仕様を決める作業なので、機能、性能、品質などに大きく影響する。その意味で、きちんと実施しなければならない。
 ある程度の規模を越えたシステムでは、改良しながら長く使い続けるため、設計で考慮すべき点はかなり多い。代表的な考慮点を挙げてみよう。

システム設計での代表的な考慮点
・機能:分析で求めた要件を満たす
  ・基本機能:問題領域に関係した基本的な機能
  ・運用機能:スムーズな運用を実現するための機能
  ・非常時機能:トラブル発生時に分析や回復を支援する機能
・性能:実用に耐えられる応答性を確保する
・信頼性:利用者に迷惑をかけない程度の安定動作
・安全性:事故や外部の攻撃などからシステムやデータを守る
・柔軟性:機能改良を容易にして、変更コストを減らす
・操作性:操作を覚えやすくて使いやすく
・理解容易性:理解しやすい形で情報を提供する

 以上は大まかな考慮点でしかなく、実際の設計では、さらに深く具体的に掘り下げ、より細かな点まで幅広く検討しなければならない。もっと特殊な考慮点を追加することもあるだろう。

幅広い能力が必要なので何人かで分担すべき

 今度は、システム設計の対象を見てみよう。採用する技術、システムの基本構造、データ構造、個々の機能の細かな仕様、ユーザーから見えるインターフェースや構造など、代表的なものだけでかなり多くの項目が含まれる。

システム設計の対象となる代表的な要素
・将来のシステム改良の予測と現実的な対応方法
・利用する技法や技術と、それを達成する製品
・全体の基本構造(中心となる制御構造を含む)
・データ構造(とくにデータベース部分)
・個々の機能の細かな仕様(クラスやインターフェースの仕様)
・関連する他のシステムとのインターフェース
・エラー処理やトラブル対処の基準と実現方法
・システム側の作業と人間側の作業の切り分けと、作業全体での流れ
・ユーザーから見た構造(各画面の関連や構成など)
・共通となるユーザーインターフェース規定

 以上は、大まかに挙げた項目だけだ。これを見て分かるように、これらを考慮して設計するのには幅広い能力が求められる。システムの規模が大きい場合は、個々の能力も高いレベルが必要とされる。スーパーマンのような技術者でない限り、一人で全部の能力を持つのは不可能に近い。求められる能力を数個に分類し、個々の分野で優秀な技術者を集めるのが、現実的な対処方法だろう。それらの人々がリーダー格として中心になり、その下に関連する技術者を配置する。
 このような形であっても、システム全体を技術的に把握できる人材が必要となる。どの能力も一通り持っていて、技術的に適切な決断をできる人が望ましい。ただし、該当する人材は非常に少なく、見付けるのは大変だ。仕方がないので、最初に集めたリーダー格の中から、一番適した人を選ぶしかない。

設計とは論理的で科学的な作業

 設計という作業の中身を、よく理解することも非常に大切だ。設計内容を何となく決めるのではなく、論理的で科学的な検討を経て、条件を満たす最適解を導き出すのが、本当の設計である。「コンピュータ・サイエンス」と表現するように、システム設計は科学的なものなのだ(システム以外の設計も本当は科学的でなければダメなのだが)。
 システム設計で重要となるエラー処理の設計を取り上げ、もう少し具体的に説明してみよう。エラー処理を設計する際には、どのようなエラーが起こりうるのか、最初に全種類を洗い出す。メモリー不足、回線やハードディスクなどの故障、プログラムのバグといったシステム側のエラーだけではない。利用者の入力ミス、1日1回限定の処理を2回以上実行、処理のし忘れなど、利用者による運用上のエラーもある。考えられるエラーの全種類を明らかにする。
 洗い出したエラーは、重要度、発生場所、システムとの関連度、典型的な対処方法の違いなどで分類する。こうして分けるのは、分類したグループごとに対処方法の基本ルールを決めるためだ。発生の頻度や可能性、発生したときの被害の大きさ、人間による対処の容易さ、システムによる対処の容易さなどを考慮して、グループごとの対処方法を設定する。ある種のエラーは、システム側で全部を処理できるだろう。別なエラーは、人間とシステムで分担して解決する。どうしようもないエラーだと、システム側ではまったく対処しないこともある。また、どんな処理をどこに入れるべきかなど、具体的にどう作るのかも正確に指定する。こうして定めた基準をもとに、実際の設計でエラー処理を組み込む。
 以上のように論理的で科学的な工程を経て、設計を進めるわけだ。エラーのグループごとに対処方法を決める際にも、論理的で科学的に検討するのは言うまでもない。どの要素の設計であっても、科学的に最適な内容で設計できるように、きちんとした作業工程を採用し、各工程での検討点を明確にする必要がある。

具体的に細かく規定するのが設計

 どの程度まで細かく決めるかも、設計では重要となる。あいまいな状態のまま設計を終わらせると、後になって問題が生じ、致命的なバグになりかねない。
 システム設計とは、システムの仕様を決める作業である。仕様とは、具体的で明確な記述を意味する。どのような操作で動かすのか、何を表示するのか、どのデータをどんな風に処理するのかなど、違う解釈ができないように規定する。また、登録件数などの限界値も明示し、それを越えたときの対処方法も決める。
 ユーザーインターフェース関連では、操作方法の標準化だけでなく、処理の成功を確認する方法や、エラーが発生したときの通知方法なども設計に含まれる。このように、システムに関する細かな部分まで規定し、製作工程で疑問が生じないようにするのが設計だ。そのためには、何でも具体的に、できるだけ数値で記述する必要がある。
 仕様を細かく規定するには、システム全体での標準化が欠かせない。エラーを含むメッセージにIDを付けるとか、エラー情報の渡し方を定めるとか、メソッドのパラメーターの並び順を統一するとか、いろいろな部分が対象となる。これらの標準化は、個々の機能を設計する前に決めなければならない。標準化することで、個々の機能の設計に集中できるとか、仕様書の記述量が減るメリットも生まれれる。
 参加メンバーが科学的で細かく規定する設計方法を知らない場合は、教育して習得させる必要がある。それには時間がかかるので、開発が始まる前に終わらせるべきだ。また、このような設計方法が初めての人ばかりだと、失敗する可能性が高まる。どのグループでも少なくとも半数は、経験者を入れなければならない。

実際の設計で役立つノウハウが必要

 技術進歩の激しいコンピュータ業界では、次々と新しい技術が登場する。最近では、オブジェクト指向技術が注目されているし、先進的な開発者は既に使っている。
 このような新しい技術を使う際、技術的な知識を単に知っているだけでは上手に設計できない。オブジェクト指向技術を利用した開発なら、大きく3つに分け、プログラム・レベルの設計、システム・レベルの設計、問題領域レベルの設計で、オブジェクト指向技術を生かした設計ノウハウが必要となる。
 このように実際の設計で役立つノウハウは、どんな技術や技法であっても存在する。それを習得していないと、質の高い設計は不可能に近いので、大規模なシステム開発では必須といえる。
 オブジェクト指向技術のように、特長を生かすのが難しい技術だと、設計ノウハウも難しくなるのは当然だ。また、分散オブジェクト技術やオブジェクト指向データベースなど、オブジェクト指向技術の適用範囲が広がったため、習得すべきノウハウも増え続けている。難しくて量が多いと、習得に時間がかかるし、誰もが習得できるわけでもない。
 設計ノウハウを習得するためには、誰かが教えてくれるか、ノウハウを記述した資料が必要だ。幸いなことに、オブジェクト指向技術に関しては、設計ノウハウに関する良質な翻訳本が何冊か登場しているので、状況はかなり明るくなってきた。それらの本を読んで理解し、実際のシステム開発で試すと、良い設計ノウハウが身に付けられるだろう。習得した人が登場し、別な人に教え始めれば、習得する人がどんどん増える。それにより、難しいシステム開発をこなせる体制が出来上がるはずだ。

仕様書作成やレビューと組み合わせて設計の質を向上させる

 システム設計の質を向上させるためには、ここまで説明した設計技術を身に付けただけでは不十分。設計内容をきちんと仕様書にまとめ(作業が大変なので上手に手を抜くことも大切)、設計者とは別な人が設計内容をレビューする必要がある。このような作業全体を統括するのがプロジェクト管理技術で、システムの品質を確保するのに役立つ。
 前述のように、何を設計する場合でも、いくつかの工程に分割して作業を進める。各工程で得られた設計内容は、次の工程への入力となる。レビューでは、設計した内容の善し悪しだけでなく、前工程設計内容と矛盾していないかも調べる。一番最初に参照するのは、分析工程で得られたシステム要件で、システム全体の設計内容と矛盾していないか検査する。
 システム設計が終わると、システムを構成する要素の細かな仕様が決まる。その仕様を見ながら、プログラミングや定義ファイル作成といった実装作業が進む。こちらの作業でも、必要に応じてレビューするし、テストによって機能を検査する。
 以上のように、システム設計の前後の工程との整合性は、おもにレビューで確保するわけだ。当然ながら、整合性の検査も科学的に評価しながら進める。

 システム設計は非常に幅広く奥が深いので、簡単に説明できるテーマではない。ここでは、システム設計に求められる大枠というか、本当に重要な面だけに絞って解説した。システム設計で何が大切かや、どのように考えて作業すべきかは、だいたい伝わったと思う。
 実際のシステム設計では、クラス設計や画面設計といった具体的なノウハウが求められる。また、設計途中で重要な問題点に気付くなど、最初の予定どおりに進まない事態が発生することもある。このような内容に関しては、別なページで解説するつもりだ。

(1999年7月28日)


下の飾り