新人技術者のためのロジカル・シンキング入門（3） ―― 「必要とされる設計書」の作り方

【2】設計書に求められる三つの要素（2/2）

● 機能間のインターフェースを明確にする設計書

　機能分けと同時に検討を要するのが，機能と機能の間の関係，つまり，それらの間でやり取りされるデータにどのようなものがあるかです．機能間のインターフェースを決めるうえで考えなければならないことを以下に挙げてみました．

• 各単体機能のデータ・フロー
• デバッグのしやすさ
• 単体テスト項目

　機能分けを行ったら，それらの関係がわかりやすくシンプルであることが大事です．複雑に絡み合っているとデバッグの妨げとなり，機能単体のテスト項目も立てづらくなります．

　このことを，携帯音楽プレーヤのデータベースとその上位ブロックの関係を例にとって考えてみましょう．例えば，楽曲データを検索するには，最低限，楽曲に対応するキー項目がデータベースに必要です．ユーザが楽曲を選ぶ画面を表示するには，キーから検索された楽曲名などの情報がデータベースからユーザ・インターフェースまで上がってこなければなりません．

　そして，ユーザが楽曲を選ぶときに必要な情報は，ユーザがパソコンから楽曲を取り込んで登録したときにはすでにデータベースに登録されていないといけないのです．

　このように，ユーザ向けのインターフェースを決めていく過程で，データベースのテーブル仕様はかなり検討が進むはずです．そして，データベースの仕様を明らかにするうえで最初から重要な役割を果たすのは，データベースと上位の機能がやり取りするデータがどのようなものか，ということです．

　第1段階で機能分けができたら，それらの間でどのようなデータがやり取りされなければならないかを考えて，機能そのものをより詳細に検討していきます．機能分けが済んで機能間のインターフェースが完全に固まれば，工程を一つ進めて，各機能のより詳細な検討に入ることができます．

　逆に言うと，機能間のデータに検討もれがあって，それが結合テストの段階で判明すると，たいへん影響が大きくなるのです．例えば，データ登録のときに必要なデータが仕様上で欠けていたという場合を考えてみましょう．この場合は最悪で，パソコンのアプリケーション（ソフトウェア），ユーザ・インターフェース・アプリケーション・サーバ，データベースのすべてに変更が入ってしまうことになります（機能分けの全体像については後述）．

　よく言われる「設計段階での検討もれ」というのは，実はそのほとんどが，機能間のデータに検討もれがあった場合なのです．

　機能間のデータ・インターフェースを決めるうえでもう一つ重要なことは，デバッグしやすい構成にすることです．システム全体をデバッグするときに重要となるのは，バグの原因となっている機能ブロックの特定です．バグの原因を特定するためには，機能間のインターフェースのデータ・フローをファイルにして取り出したり，ロジック・アナライザでプローブしたりします．

　逆に言うと，「デバッグしやすくするには，どういうインターフェースにしておけばよいのだろう」ということを，設計の段階から考えておくべきです．機能間のデータ・インターフェースは，いわばバグを捕らえるための「落とし穴」と言えます（図4）．

図4　インターフェースはデバッグ時の「落とし穴」を考えて
ソフトウェアを設計する際に，「どう作ればデバッグしやすいか」を考えて設計することが大事．例えば，デバッグのためのビルドを行うと，ログが吐き出され，たいていのバグを検出できるような機能を組み込んでおく

　デバッグのための「落とし穴」としての機能間のインターフェースは，テスト工程の側から見ると，取りも直さず各機能ブロックの単体テスト項目の基礎となります．というのは，機能間のインターフェースの動作が確実に保証された段階で結合テストが可能となるため，機能間のインターフェースが設計仕様を満たしているかどうかを確認することが単体テストの目標となるからです．単体機能の確認が完了したら後工程の結合テストを確実に行えるように，設計の段階からくふうされていなければなりません．

　したがって，「テストしやすく設計する」のも重要なポイントとなります．デバッグのポイントは，テスト項目の裏返しでもあるのです．

● 全体像を明らかにする設計書

　機能分けと機能間のデータが決まれば，設計書を見たときにそのシステムの全体像が明らかになってきます．設計書に書かれた機能とその間のインターフェースから読む人に伝わることは，結局，全体のイメージです．

　システム全体の設計書であれば，読む人がその全体像を明確にとらえられるようになっていなければなりません．サブシステムの設計書なら，そのサブシステムの機能分けや機能間のインターフェース，およびほかのサブシステムとのインターフェースが全体像として明らかになっていなければなりません．

　ですから「設計書」と呼ばれるものは，人間がぱっと見てわかるように，1枚にまとまって記述されていることが望ましいと言えます．設計書をぱっと見たときに全体構成が明らかで，機能分けと機能間のインターフェースに矛盾が見つからなくなれば，その設計書は完成したと言ってよいでしょう．