外部設計と内部設計って何？って聞かれたので

システム界隈の営業に転職した友人から聞かれたので、カーチャン的なメモ。

自動販売機で考えてみよう

まずは、システムとは何かをおさらいしてみましょう。

システムとは、複数の要素が体系的に構成され、相互に影響しながら、全体として一定の機能を果たす何物かのことである。

システムとは (system)： - IT用語辞典バイナリ

自動販売機の場合、無人で商品を販売する機能を有する機械です。

商品を買う一般人と、商品を補充する管理会社の人が関わっています。
機械と、購入者と、管理する人。
その3つをひっくるめて「自動販売機による、無人販売システム」という一つの世界（システム領域）が成り立っています。

設計というものは、結構面倒くさい

自動販売機は、お金を入れて商品を選ぶと、商品とおつりが出てくる、という単純な機械です。
でも、「お金」とは何なのか？（千円札は当然として、二千円札は受け付けるのか？一万円札は？）
「商品を選ぶ」とは、どんな行動を指すのか？（ボタンなの？タッチパネルなの？）
実際作ってみる前には、いろいろなことを検討していかなければなりません。

取りとめなく考えていくとわーーーー！っとなってしまうので、
大局的な概念から詳細な事柄に向かって、順番に煮詰めていきます。

例えば、
①お金を入れると、商品が出てくる
②お金とは、10円玉、50円玉、100円玉、500円玉、1000円札を指す。これ以外は返却する
③硬貨と紙幣を受け付けるので、投入口は硬貨用と紙幣用を用意する。硬貨用の投入口のサイズは、一番大きい500円玉が入るサイズにする。
④投入されたものが有効なお金かどうかは、重さや大きさなどで判別する。
⑤大きさの判断には部品A、重さの判断には部品Bを使う。

という具合ですね。

「お金を入れる」というトピックス1つについても、こんな感じでどんどん掘り下げていきます。
（実際はもっと掘り下げます。）

何についての設計なの？

ここで、①②③と④⑤の違いに注目してください。

①②③については、自動販売機を利用する人に関係の深い事柄ですが、
④⑤については、自動販売機の動きに関する事柄です。

例えば、初めて自動販売機を使う子供に使い方を説明するときに、
「ここにお金を入れてボタンを押すと、下のほうに商品が出てくるからね。
おつりはこっちに出てくるから、忘れないようにね。」
って教えますよね。

あるいは、今度会社の休憩室に導入しようかな？と考えている社長さんに、
大きさや消費電力などのスペックは説明しますが、
内部のギミックは教えないでしょう。

使用メモリ量、OSといったスペックや、利用する人、繋がっている他のシステムに関わること、
つまりプログラムの外とのかかわりについて設計することを外部設計と呼びます。
逆に、プログラム内部の動きについて設計することを内部設計と呼びます。

システムの現場では、
外部設計には、機器の構成や使用する言語、画面レイアウトなどについて設計します。
内部設計には、変数名や細かい処理の流れを書きます。

外部設計は、お客さん（利用者）に対して仕様の合意を取るために読んでもらいますが、
内部設計は、求められない限りはあまり読み合わせなどは行いません。
ただし、次にそのシステムをメンテナンスする人のために納品物の中に含めるケースが多いです。

基本設計、詳細設計と言う場合もありますが、
「基本的な項目を網羅している」という意味で、外部設計を「基本設計」、
「基本設計をベースに更に詳細に説明している」から内部設計を「詳細設計」と呼ぶこともあります。

（結構イメージで言っている場合もあるので、
開発する会社によって、段階の切り分け方や仕様書に記載する内容が違う場合があります。
そこのところは、現場で確認するしかありません……）

要件定義と何が違うの？

上記を説明すると、「要件定義とは何？」と、追加質問がよく来ます。

要件定義とは、発注元が「どんなシステムを作りたいのか」という妄想構想を練る段階です。

それ以降の設計工程では、システム屋が中心となり、その構想をどんな風に実現していくか？を考えていきます。

よく要件定義でコケるといいますが、自分がほしいものって、意外とわかんないものなんですよ。
「ラーメン」とかの概念が固まっているものならいいんですけど、
システムって「動き」であって、目に見えないものなんですよね。

「なぁんかぁ、あったかい物が食べたいってゆぅかー、
さっぱりめの麺がいいんだけど、ソバやうどんはちょっと違ってぇ。
昨日パスタ食べたから、パスタ以外がいい。」
みたいなワガママなギャルじみたオーダーがふつーーに入るんです。

みんながイメージで語りだすから、得てして妄想大爆発。

まだ1つの部署内で使うシステムなら、共通認識が揃っているからマシなんですが、
全社に関わるシステムを手掛ける場合は、それぞれ立場が違う部署が主張を始めるので、
管理部と営業部と製造部がケンカしだすなんてことも……
↑一番困るパターン

ここで方針やコンセプトが決まるかどうかで、7割くらいの成否が決まります。
現場の「困ってるんですー」を拾い上げて、
整理し、新しいしくみを整える。
システムコンサルの腕の見せ所です。

コンサル費用をケチって（？）この役割を業務が見えてきた中堅に振ることが多いのですが、
その人たちと別に、きちんと「しくみ」を整えられる能力を持った人を立てて、まとめてもらったほうがいいですよ～(;´･ω･)
10人の凡人が1年かかってもできなかったことが、1人のエースが1か月で解決してしまう、
「仕組みを整える」というのは、そんな恐ろしい世界です。

まとめ

以上で、「設計でどんなことをするか」を説明しました。
システム屋さんの仕事について、少しでも伝われば幸いです。

ちなみにテスト工程というのが製造の後に控えており、ちゃんと設計したことが盛り込まれているかを確認する段階となります。

こちらは設計と逆に、コンピューター近い内容のテスト（条件式が正しいか？など）から、
他のシステムとの連携のチェック、
実際に使ってみて狙い通り業務が改善されたか？というテストに進んでいきます。

大体、設計と製造で同じくらいの時間（工数）がかかります。

「システム屋は孤独にコード書いていればいい」
「グダグダ重箱の隅つついていないで、ちゃっちゃと作ってよ。」
なんていう認識は、間違っています！

設計工程は大事！