要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

【初心者向け】【システム設計】外部設計と内部設計に関する説明

筆者が新人の頃、その用語を聞いて混乱した用語がある。「外部設計」と「内部設計」だ。ある人は「基本設計」と「詳細設計」のことだよと言うかもしれない。ある人は、「上流工程の設計」と「下流工程の設計」のことだよと言うかもしれない。システム開発業界では、〇〇設計という用語がとても多く、人によって認識が違っていたりする。色々な先輩に聞いて回ったが、みんな説明が違うので、筆者もしばらく混乱した記憶がある。今回は、筆者なりにしっくりきている「外部設計」と「内部設計」について、整理する。

外部と内部

設計をする際に外部設計内部設計という言い方がなされる。外部/内部という言葉は、それぞれ、「システムの外部」/「システムの内部」を意味している。システムの外部というのはシステムの使い手から見える部分である。例えば、外観であったり、ディスプレイであったり、ディスプレイ上に表示されるユーザーインターフェースが、システムの外部である。他方で、システムの内部というのはシステムの使い手から見えない部分である。例えばハードウェアを分解して見られる中身の配線であったり、画面上のボタンをクリックした後の処理アルゴリズムが、システムの内部である。

外部設計スコープと内部設計スコープ

外部と内部という分け方をすると、外部設計が上流工程で、内部設計が下流工程と捉えられがちだが、筆者の考えは異なる。上図にて、外部設計スコープと内部設計スコープを示しているが、上流工程で決めなければならないスコープは、必ずしも外部設計とはならないことが、直感的にわかるであろうか。システムの外側の部分だけ設計しても、そのシステムが本当に動きそうかどうかはわからない。ここを設計しておかなければ、後で大きな手戻りを発生させかねないという設計工程を上流工程と呼ぶならば、一部の内部設計工程も、上流工程になり得るであろう。そのような工程の代表が、システム構成設計(アーキテクチャ設計)とデータ構成設計(データモデル設計)だ。この2つは、システムにおける内部の情報処理、および、情報の管理について記載してある設計書だ。これらの設計工程については、別の機会で記事を書くこととしたい。ともあれ、外部設計=上流工程でもないし、内部設計=下流工程でもないことに注意しよう。
また、上図では、外部設計スコープと内部設計スコープを完全に区切った形としているが、これらの間には、記載としての「のりしろ」が存在しうることに注意したい。内部設計というものは、外部設計工程で書かれている内容を実現するために記載される。外部設計で記載されている内容は、必ず実現せねばならない内容だ。その内容を実現するために、内部設計工程では、外部設計書を上位設計書として、内部的な処理を細かく記載していく。内部設計書では、外部設計でどのような記載がなされていて、それをさらに深掘りして、どう設計するのかが記載される。言い方を変えると、内部設計書は外部設計書を参照する。外部設計書の記載が変わると、それらを参照している内部設計書の記載は、のきなみ変更となるものだ。だからこそ、外部設計書が上流工程で、内部設計書が下流工程という見方がなされる。くどいようだが、必ずしも内部設計=下流工程ではないことには注意しよう。
ポイント:システムの外部を設計するのか、内部を設計するのか、常に意識しよう

外部設計

詳細な説明に関しては別の機会に譲るとして、外部設計ですべきことを整理したい。外部設計とは、システムの外側に関する設計のことで、システムを使う側から見た場合における、システムの振る舞いを明確化する作業のことを指す。システムの中をブラックボックスとして、どんな入力をしたらどんな出力が返ってくるか?が、システムの振る舞いとなる。例えば、ボタンを押したら、LEDが光るというシステムがあった場合、ボタン押下が入力で、LED点灯が出力である。これらの入力出力に関する振る舞いの明確化作業を、IF設計と呼ぶ。IFとは、インターフェースの略語である。「インター」は「交わる」という意味で、「フェース」は、「接する」という意味だ。つまり、システムの使い手とシステムが接するところがIFである。システムの使い手とシステムが、入力と出力を通じてどうやりとりをするかを決めるのがIF設計だ。
IFの設計ができると、システムの動きがわかるので、運用の設計ができるようになる。運用とは、「ものをうまく働かせ使うこと」のことだ。システムをうまく働かせ使うために、いつ、だれが、どのように、使うのか、を定義していくことが大事だ。注意したいのは、その機能は、手動実行か、自動実行(スケジュール実行)か、という点だ。手動実行の場合、何もしなければ、システムは何もしない。自動実行の場合は、何もしなくてもシステムが勝手に出力をし続ける。設計する機能は、手動なのか、自動なのか、明確化しておこう。特に、自動実行機能については、外部設計の段階で一覧化して管理しておこう。スケジュール実行される機能の実行時間が重なってしまうと、局所的な負荷集中により、システムがサービスを継続できないことがあるためだ。
さらに必要なことは、概要レベルでの機能設計だ。IF設計にて、入力/出力を具体的に設計しているものの、それらは全体としてどのような機能を提供するのか?に関して記載することで、システムの使い手は、システムの使い手を想像しやすくなる。また、機能以外についても、概要レベルで設計しておく必要がある。これらは非機能と呼ばれ、機能ではないもの全般を指し、例えばセキュリティ性能であったりする。

 

外部設計

まとめると、外部設計としてやるべきは、下記だ。
①    IF設計:外部から見たシステムの入出力
②    運用設計:外部から見たシステムをどう使うか
③    概要機能設計:外部から見たシステムの機能の概要
④    概要非機能設計:外部から見たシステムの非機能の概要(セキュリティなど)

ポイント:外部設計では、IF設計と運用設計をしよう。さらに、概要レベルで機能/非機能設計をしよう

内部設計

内部設計ですべきことを整理したい。内部設計でやるべきことは、実装ができるレベルまで、設計書を具体化することだ。外部設計書に書いてある内容をさらに具体化して記載をすることとなる。注意すべき点は、外部設計書に書いてある内容で実装ができる部分については、わざわざ詳細な設計書を書く必要はないという点だ。外部設計書は、システムの使い手から見たシステムの動きを定義するのに対して、内部設計書は、システムの作り手側から見て、システム実装に必要なことを定義するという違いがある。
システム実装に必要なことを定義する内部設計において、重要な作業が2つある。それは、システム構成設計(アーキテクチャ設計)とデータ構成設計(データモデル設計)だ。システム構成設計は、建築で言うところの骨組み設計である。システム開発における骨組みにあたるものは、システム全体の構成図、すなわち、通信線(有線無線)を介してシステム内の各ブロックがどのように結合され、どのように情報が処理されていくのかを示したものである。各ブロックの詳細を描く必要はない。システム構成設計は、早い段階でやっておかねばならない。なぜならば、それを後で変更するのが極めて難しいからだ。一階建の建物を後で二階建てにするのが難しいのと同様、システムの根幹機能を後から変更するのは難しい。変更による影響の分析をしっかり行い、全体整合を検証し直さねばならないからだ。データ構成設計は、ビジネスで言うところの帳簿にあたる。どのような帳簿を用意し、どのような入力規則とし、データの一貫性を保つために、どのようなデータ構成とすべきかを検討していく。
システム構成設計とデータ構成設計は、外部設計か内部設計かでいうと内部設計であり、システムを成立させるための根幹の設計にあたる部分である。建築において、安全性を担保するために建物の土台と骨組みを決めるのと同様、システムの世界でも、システムが壊れない(入力と出力を適切に行い続ける)ための土台と骨組みを決めることが必要だ。システムが壊れないように、構造を設計することが、堅牢なシステムを作る上で大切なことなのだ。

 

内部設計

まとめると、内部設計としてやるべきは、下記だ。「非機能」という表現はカバー領域が広く、やっかいだが、別の機会で整理したい。
①    システム構成設計
②    データ構成設計
③    詳細機能設計
④    詳細非機能設計

ポイント:外部設計では、IF設計と運用設計をしよう。さらに、概要レベルで機能/非機能設計をしよう