シス開発：設計の質を高める仕様書の書き方 |
システム設計内容を仕様書の形で記述するためには、設計内容の全体像を適切に理解するとともに、上手に分解しなければならない。その分解は、設計の進み具合と一致する形でないと、実用的ではない。
こうした条件を満たすには、基本的な３階層でシステムを分解する。設計する順番に並べると、システム構造設計、ソフトウェア構造設計、プログラム設計となる。細部まで明確に分けられるわけではないが、大まかには３階層に分解する。３階層の概略は、次のとおり。
システム設計内容の基本３階層 １：システム構造設計
・システムに関わる全体像を設計する
・ソフトとハードに関する概要を含める
・人間の作業内容やルールの概要も含める
・システムの運営体制の概要も含める
・システムの目的や期待効果を明らかにする
・規模が大きい場合は、複数システムに分解する
・設計作業を問題解決として捉える
・どんな条件を満たせば成功するかを明確化する
・本当に実現可能かを確認する（メドを立てる）
・上記概略の細かさは、メドが立つ程度まで
２：ソフトウェア構造設計
・ソフトウェア全体の構造を設計する
・単体プログラム（クラス）分けにまで落とし込む
・必要に応じて、共通化や拡張性を考慮する
・情報表示やエラー処理のルールも規定する
・データベース製品などの選択も含む
・個々のプログラムの外部仕様の概要を規定する
３：プログラム（クラス）設計
・個々のプログラム（クラス）の外部仕様を細かく規定する
・エラー処理など、個々に考慮べき点を明確化する
・性能や信頼性など、重視すべき点を明確化する
・必要なら、最適な内部構造を規定する
・外部仕様に適した形で内部構造を作る（実装）
上記は、ソフトウェアに関する設計を中心に書いてあるため、ハードウェアや人間のルールなどの設計は省いてある。実際には、２番のソフトウェア構造設計の層に、ハードウェア設計と問題領域（人間系など）の設計がある。ハードウェア設計といっても、実際にはマシンや機器の選択になることが多い。問題領域の代表例である人間系の設計には、人間が行う作業内容や運営ルールの設計が含まれる。３番のプログラム設計の層にも、データベース用のデータ定義、表示画面や印刷レイアウトなどの設計がある。しかし、分かりやすくするために省略した。
１番の「システム構造設計」という名称だが、実はしっくり来てない。良い言葉が思い付かなかったので、仕方なくこの表現にした。素直に表現すればシステム設計だが、それだと２番も含むように感じるので、区別するために「構造」という言葉を加えた。
作業の流れとしては１〜３番の順になり、前の作業の設計内容が次の作業で使われる。１つずつ進むごとに、設計内容が細かくなっていくわけだ。
１番のシステム構造設計でもっとも重要なのは、システムの目的に照らし合わせて、本当に役立つ内容を設計することにある。つまり、システムの構築で、狙っていた目的が達成される点だ。
そのためには、システムの目的を明らかにする必要がある。しかし、システムの目的という表現は適切でない。システムは問題の解決方法であり、システムによって何かが達成または解決されること自体が、真の目的となる。このような視点で考えると、本当の目的が明らかになる。当然、システムの構築では解決できない問題や、システム構築と一緒に何かを実現しないと解決できない問題もあるだろう。システムを必ず構築するわけではなく、検討の結果として、システムを構築しないこともあり得る。この点も考慮するのが正常な検討方法だ。
本来の目的のためには、システムの構築が必要だと分かった場合でも、システムを必ず作るべきだとはいえない。システムを構築することで、本来の目的を確実に達成できるとは限らないからだ。システムの概略仕様が決まった段階で、どの程度の効果がありそうなのか、ある程度まで予想できる。また、システムの構築と運用に必要なコストも、ほぼ求められる。このように効果とコストの両方を明らかにして、もし目的を達成できなければ、通常はシステムを構築しないと判断する。
当たり前のことだが、システム仕様の中身によって、期待される効果は大きく変わる。システムを構築すべきか判断する前に、最良のシステム仕様を求めなければならない。その際に基準となるのは、本来の目的である。それに照らし合わせて、システムの概略仕様を設計する。
本来の目的から、システムに必要な機能を求める作業は、まさに問題解決と同じだ。本来の目的は、何らかの問題を認識していて、それを解消するために存在する。目立った問題はないが、理想とは違っているのも、問題の１つと捉えられる。こうした問題を解決するための方法を求めるのが問題解決手法であり、システム構造設計の初期段階で利用する。また、システム仕様から求められた効果の大きさを評価するのも、問題解決手法の範疇である。つまり、システム構造設計の作業は、問題解決が中心であるといえる。
このような形で設計作業を進めると、本来の目的とって、本当に役立つシステム仕様が得られる。反対に、システム構築では解決できないと判断されることもある。どちらの場合でも、質の高い検討から得られた結果なら、そのとおりにするしかない。
システム構造設計の役割を、実際の例で見てみよう。失敗した例の方が分かりやすいので、代表的な例を取り上げる。
失敗の代表例といえば、何といってもオンラインショップだ。システムとして開発したものの、期待した成果を上げていない方が圧倒的に多い。その大きな原因は、オンラインショップを単に作ることだけ考えていて、どのようにすれば成功するのか、ほとんど検討していない点だ。
システム構造設計の作業を適切に行うと、オンラインショップが必要だと結論付けるための、本来の目的から明らかにする。利益を増やすとか、認知度を広げるとか、ユーザーの声を集めるとか、複数の目的があるだろう。その目的を達成するために、どのような条件を満たさなければならないのか、最初に明らかにする。それを元にして検討した結果、オンラインショップが一番の解決策だと分かれば、ショップの中身の検討に移る。
オンラインショップに必要な機能は、本来の目的の達成に必要な条件を考慮しながら求める。一般的な機能だけでなく、サイトの使いやすさや人間の対応など、成功に必要な要素を幅広く洗い出す。それを機能やデザインとして構築するわけだ。こうして中身が明らかになったら、どれだけの効果が期待できるのか、冷静に評価してみる。評価の質を高めるために、調査や実験が必要かも知れない。もし評価結果が悪かったら、改良を何度か試みて、再び評価する。もし最終的な評価結果が悪い場合は、ショップのシステムを開発しないと判断する。
もしショップが本当に必要だと感じているなら、半年とか１年ほど経過してから、再び検討してみればよい。優秀なメンバーを引き入れるのも効果があるだろう。新しい視点やアイデアが出て、成功するシステム仕様が得られるかも知れないからだ。
上記のようなことを指摘すると、「今回は勉強や調査も兼ねていたから、失敗することは予想していた」などと、後付けの言い訳を述べる人もいるだろう。もし勉強や調査が主な目的なら、それに最適なシステムを構築したはずである。コストをかけたくないので、ショップとしての機能は簡単に作り、いろいろなことが調査できる機能を少し組み込んむ形で。そうでないなら、後付けの言い訳でしかない。
後付の言い訳が可能になるのは、最初のシステム構造設計の段階で、適切な検討が行われていないからだ。適切に検討していれば、本来の目的、成功の条件、実現すべき機能、期待される成果などが、システム仕様書の形で残っているはずである。それがないから、後付けで何でも言えてしまう。
もっとも大切なことは、システム構造設計を適切に行うことである。それを省略したり手を抜くと、失敗の確率が格段に向上する。
設計内容の基本３階層は、設計内容を分解した結果である。３つの設計内容がかなり異なるので、それぞれに適した仕様書の形式を用いなければならない。
１番のシステム構造設計は、もっとも基本的な部分だ。システムの構築を前提とするのではなく、本来の目的を達成するための方法を設計する。多くの場合は問題解決として捉えられ、その手順で作業を進める。設計の成果物である仕様書も、問題解決の流れに沿って作る。
この段階の設計では、実現可能なシステムの機能を何種類か挙げ、それぞれのコストを大まかに求める。そのコストには、維持費や定期的な改良も含まれる。正確な予測は難しいので、かなり多めに見積もるのが基本だ。同時に、各システムの効果も洗い出す。そして、コストよりも効果が明らかに大きいシステムがあれば、最良の達成方法として選択する。実際には、競争から脱落しないことが目的の状況もあり、そうなると、効果が小さくても構築するしかない。もちろん、コストを最小限に抑えながら。
２番のソフトウェア構造設計では、多くの記述方法がすでに開発されている。最近の代表例はUMLだ。このような標準的な記述方式だけでは、ソフトウェア構造を全部記述できないので、必要に応じて独自の形式を追加する。また、標準的な形式でも、そのまま使うのではなく、使いやすく改良して利用する。
３番のプログラム（クラス）設計では、プログラムの外部仕様と内部構造を設計する。内部構造に関しては、実装しながら設計することが多い。この場合、ソースコードを分かりやすく作り、それが仕様書の代わりとなる。
３階層の設計内容は、互いに関係がある。上位の設計内容と整合性を確保しなければならない。その検査が容易になるように、個々の設計内容にIDを付け、関連を整理して記述する必要もある。
仕様書というのは、設計内容を記述したものだ。設計した結果だけでなく、それを得た理由や検討範囲まで含んでいる。設計が終わった時点で作るのはなく、設計しながら作り、設計の作業効率を大きく上げるための役割も持っている。また、第三者によるレビューが可能な形式で作り、設計の質を高める役目もある。
３階層に含まれる全部の仕様書は、どれも役割を持っている。共通の役割は、設計内容を明らかにして、適切な方向に進んでいると確信することだ。目的を達成できる形で、本当に実現できるとの確信が得られる範囲内で、可能な限り手間を省くことが求められる。
このような役割なので、記述する内容の細かさは、設計内容の適切さを確認できるレベルとなる。この確認できるレベルは、参加者の能力に依存する。能力が高いほど、細かな内容を書かなくても、実現可能かどうか判断できるからだ。
ただし、仕様書は設計した後でも使われる。そのため、参加者の範囲には、設計の参加した人だけでなく、システムを保守したり改良する人も含まれる。その人達が理解できるようなレベルで記述する必要もある。こちらも同様に、参加者の能力に大きく関係する。
実際には、非常に優秀な参加者ばかり集まることはない。そのため、ある程度まで細かく記述しないと、設計内容が適切かどうかを確認できない。また、いくら優秀でも、記述しないと確認できないので、ある程度の細かさの記述は残る。
細かさ以上に重要なのが、記述する範囲。正常系の処理内容だけでなく、例外処理も必要な細かさで記述する。例外処理には、ソフトウェアだけでなく問題領域の内容も含める。他に、性能、信頼性、使い勝手なども、必要な箇所で明確に示す。
こうした記述で大事なのは、記述内容をできるだけ共通化すること。例外処理はID付きの共通事項として記述し、個々のプログラム（クラス）や問題領域の作業から参照する形にする。こうすれば、大きな手間をかけずに、細かな部分まで明確に指定できる。
３階層に分けた設計内容を、世間で得られる情報と照らし合わせてみよう。２番のソフトウェア構造設計と、３番のプログラム（クラス）設計に関しては、様々な情報が簡単に得られる。また、これらの設計内容を記述するための標準規格も充実しつつある。
それに比べると、１番のシステム構造設計に関しては、有益な情報が得られにくい。そればかりか、単行本や雑誌の記事という形で、間違った情報も多く流通している。
このような状況になった主な理由は２つある。まず、この種のノウハウを持っている人が非常に少ない。それでも、書籍流通やネットワークが発達した現代社会なら、ノウハウを広めることができる。しかし、そうなってはいない。この手のノウハウを単行本として出そうとしても、売れないという理由で却下されやすい。もし出版できたとしても、部数が期待できないの価格を高し、売れない原因の１つとなる。つまり、買う人が少ないというのが２番目の理由だ。
結果として、システム構造設計のできない技術者があふれ、本来の目的を達成できないシステムが数多く作られている。また、システム構造設計の部分を、自分には関係ないと思っている技術者も、意外に多いようだ。良いシステムを設計するために一番重要な要素なのに。
なお、本サイトでシステム設計と表現するとき、１番のシステム構造設計だけの場合と、２番のソフトウェア構造設計まで含んだ場合の２種類がある。どちらかというと、後者の方が多い。もちろん、一番大事なのは、１番のシステム構造設計である。
（2003年２月23日）
システム設計内容の基本３階層 |
