シス開発：設計の質を高める仕様書の書き方 |
たいていのシステムは、何らかの問題を解決するために作られる。その場合、システムに求められる第１の点は、問題が解決できる機能である。解決するといっても、そのレベルは様々だ。少しだけしか解決できないシステムもあれば、完全に近い状態まで解決できるシステムもある。解決の度合いは、システムが持つ機能、つまりシステムの仕様によって大きく変わる。
通常、システムが持つべき機能は、一番最初に検討する。その際には、本来の目的を十分に考慮しなければならない。問題の解決が目的であれば、その問題を十分に解決できる機能を明らかにして、システムの概略仕様をまとめる。この段階での検討は、一般的なシステム設計というより、問題解決の作業に近い。問題点を洗い出し、その原因を調べ、原因を解消するの用対処方法を検討する作業だ。つまり、システムの概略仕様を決定するまでは、問題解決として検討する方法が適している。
注意しなければならないは、問題を解決する方法として、システム化が絶対的に正しいとは限らない点だ。問題の種類によっては、組織構造や運営方法を変えるだけで解決できることもある。したがって、システム化を大前提として考えるのではなく、システム化以外の解決方法も一緒に検討し、比較して良い方を選ばなければならない。
システム化によって解決する場合でも、システムで実現できる機能は様々である。そのため、実現できる機能を幅広く検討して、多くの機能を挙げてみる。当然ながら、何でも挙げるわけでなく、本来の目的に合った機能だけだ。こうして挙げた機能のそれぞれが、目的に関してどれだけ有効なのか評価し、もっとも良いものを選ぶという手順になる。
以上のように、考えられる解決方法を複数挙げ、それぞれの効果を適切に比較して選ばなければならない。こうした手順を踏むことは、物事を検討する基本である。そうすれば、本来の目的に一番合ったシステム概略仕様が得られる。
問題解決の形で検討するものの、システムが持つ特徴も考慮しないと、検討の質が低下してしまう。どういった点を考慮すべきなのか、簡単に整理してみよう。
コンピュータを利用したシステムでは、ソフトウェアによって様々な機能を実現できる。問題の解決方法となるシステムの仕様は、機能を増やそうと思えば何でも付けられる。機能を増やすほど、開発費が増えるし開発期間も延びる。どの程度の機能に限定するかも、重要な検討点だ。
こうした点を十分に検討できるように、システムの機能候補として、非常に簡単な機能から、かなり凝った機能までを挙げる。また、機能の評価には、開発費や開発期間も含める。さらに、開発難易度も違うはずなので、これも評価項目に入れる。こうした点も含めて評価すれば、最適な機能を選べるはずだ。
簡単な機能から凝った機能まで挙げるとき、それぞれ別な機能として挙げる方法と、簡単な機能を基本に置きながら、凝った部分をオプション機能として挙げる方法がある。評価方法が適切なら、どちらの挙げ方でも問題ない。該当する機能に適した挙げ方を採用すればよい。
こうして挙げた機能は、目的に対する効果を、まず個別に評価する。この評価結果が良いものを優先的に選びながら、これらの個別機能を組み合わせたシステム概略仕様を複数用意して、総合的に評価する。このような手順によって、良い概略仕様が選べるはずだ。
システムの構築では、数回に分けてリリースする方法も可能なので、開発する機能を数段階に分ける方法も検討する。この場合は、最終的なシステム仕様を中心に評価しつつ、実現過程を数段階に分けたとして取り扱う。
ソフトウェアを中心としたシステムには、通常の解決方法とは異なる特徴がいくつもある。その１つは、問題解決以外のメリットを同時に生むことだ。システム化で実現する機能によっては、競合に対する強い優位性を持つことも可能だ。こうした面を大きくすることで、問題解決以上のメリットがシステム化から得られるため、システムの概略仕様へ積極的に盛り込んだ方がよいと判断するかも知れない。これも大きく取り上げるべき点だ。
新たなメリットに関しては、問題点としても捉えられる。競合に対する優位性を発揮する機能なら、「競合に対する優位性が小さい」という問題点を解決する方法と考えるわけだ。こうすれば、すべての新たな機能を、問題解決の検討の中に入れられる。あとは各問題点の重要度を適切に設定し、それぞれの解決方法を比べればよい。このような工夫は大切で、検討全体を同じ基準で比較できるようにしてくれる。
システム化によって生じる新たなデメリットもある。中心となる業務をシステム化してしまうと、システムが停止すれば業務が完全に止まってしまう。停止する原因は様々で、ネットワーク回線が不通になるとか、マシンが故障するとか、ソフトウェアの重大なバグでデータが壊れたとか、いくつも考えられる。また、負荷が急に増えて応答が極端に遅くなることもある。こうした点も含めて比較しなければならない。
ただし、システムのトラブルに関しては、ある程度の対策が可能だ。ネットワークやマシンを多重化すれば、片方が壊れても停止することはない。もちろん、その分だけ費用は増す。バグに関しては、テストを十分に実施してできるだけ取り除くとか、サブシステム間で影響を及ぼしにくい設計にするといった対処が可能だ。デメリットの検討では、対処方法も含めて比較すべきである。
システム化には、他にも見逃せない面がある。作成したシステムが本当に役立つためには、実際に使われなければならない。たとえ、本当に役立つ機能を構築できた場合でも、システム本体とは関係のない点が原因で使われないことがあり得る。こうした失敗を防ぐことも、最初から検討した方がよい。
こうした面でもっとも重要なのは、関係する部署の協力だ。これには２つの面がある。まず最初は、問題点や原因を検討する際に、必要な情報を提供してもらうこと。これがないと、本当に役立つシステムに仕上げるのは難しい。もう１つは、システムを稼働させたときに協力する体制である。これも真剣に使おうと思ってもらわなければ、最終的に使わない結果となりやすい。
関係する部門が複数ある場合、システム化によって得する部門と損する部門が生じたりする。手間が減って仕事がラクになる部門と、逆に責任や仕事が増えてしまう部門だ。こうした状態が生じると、得する部門は積極的になるが、損する部門は必死で抵抗して、システム化が失敗しやすい。これは、全部の部門の上位に該当する責任者が、何とか解決すべき問題である。そのことを早めに知らせて、手を打ってもらうしかない。システムの成功に大きく関係するだけに、非常に大切だ。
システムの開発体制も、開発を始める前に整えるべき条件といえる。システムの開発が難しいほど、能力の高い技術者が必要となる。それを揃えられずに開発を開始すれば、大幅に遅れたり、失敗して完成しない可能性が高まる。そのため、開始するための条件として、参加する技術者の能力を洗い出し、それを満たしてから開始しなければならない。もし集まらない場合は、システムの概略仕様を簡単なものに変更するか、習得するまで待つかを選択するしかない。こうした点を考慮せずに開始し、完成が予定より遅れた例が、かなり多いのではないだろうか。
これらの考慮点の中には、システムの概略仕様を検討する前に解決しなければならないことも含まれる。とくに関係部署への対応は、開発部門だけでは何ともならない問題だけに、早目に明らかにして責任者に伝える必要がある。その意味で、真っ先に検討すべき内容といえる。システムが失敗する要因を少しでも減らすことが、最初の段階での検討では重要なのだ。
ここまでの説明から分かるように、システムの概略仕様を決めるまでには、かなり様々な点を考慮しなければならない。そのため、検討内容をよほど上手に整理しないと、適切な検討結果が得られにくい。
こんなときに大きく役立つのは、物事を検討する手法である。問題点の洗い出し、その原因の調査、細かな対処方法の候補挙げ、候補の個別評価、候補の組み合わせ選び、組み合わせの総合評価という具合に、作業を複数の工程に分けて、整合性を確保しながら検討を進められる。もちろん、重要な事柄を見極め、それを重視しながら検討できる。全体としてみると、検討の質をかなり向上させられる道具だ。
検討手法では、上記の各工程で検討内容を書きながら進める。この記述内容は、第三者によるレビューにも使えるので、仕様書としても適している。こうした検討手法を採用するとともに、検討手法での記述方法を仕様書の形式として規定するのが、最良の選択になる。
一般的な検討手法では、評価すべき点までは含んでいない。しかし、システム設計に利用すると決まっているので、絶対に必要な評価項目を事前に規定したほうがよい。そうすれば、大事な点を考慮し忘れて、システムの概略仕様へ欠陥が入り込まずに済む。
ここまで様々な考慮点が出たので、少し整理しておこう。問題解決の形で取り組みながら、システムの概略仕様を決めるまでの作業では、以下のような点を考慮する。
問題解決としてシステム概略仕様を決めるまでの考慮点 ・検討方法：
・汎用的な検討手法を用いて、総合的に最適解を選ぶ
・検討を複数工程に分割し、工程間の整合性を検査する
・過剰な期待をせず、現実に可能なレベルの解を選ぶ
・検討範囲：
・システム化以外の解決方法も挙げて適切に比較する
・複数のシステム案を挙げ、費用や期間も含めて比べる
・システム化で生じる問題解決以外のメリットも考慮する
・システム化で生じる新たなデメリットも考慮する
・システム本体以外の部分も必要なら一緒に設計する
・システム化の機能を数段階に分割する方法も検討する
・成功可能性の向上：
・関係部署など、システム以外の面で協力体制を確保する
・人材まで含めた開発体制をキチンと整える
検討手法を用いて検討する際には、上記の点が考慮されているかどうか、検討者自身が途中で検査する。また、レビュー担当者も同様に、こういった点が漏れてないかどうか確認すべきである。そうすれば、大きな失敗はしないだろう。
以上のように、システムの概略仕様を決める過程では、検討手法を採用して論理的に検討を進めた方がよい。また、その記述方法に従って書きながら検討し、第三者のレビューも受ける。これにより、設計したと言えるレベルを確保でき、検討の質を高められるはずだ。
ここまでの話は、システムの概略仕様を決めるまでの作業を対象とした。それ以降の細かな設計でも、問題解決の視点を忘れてはならない。細かな機能を決める場合も、システムの目的と照らし合わせて、最適な機能を選ぶべきだ。このときの検討でも、検討手法の考え方が役立つ。
（2001年８月６日）
システム設計を問題解決として捉える |
