外部設計終わったけど発注者はまだ何かやる必要あるの？～内部設計編

さて、前回は外部設計の説明をしましたが今回は
「プロが教える超ざっくりシステム開発」
の内部設計編となります。

外部設計をまだご覧になっていな方は以下をご覧ください。

内部設計とは？

内部設計は一般的には「詳細設計」と呼ぶこともあり、その呼称はベンダーによりけりです。
この工程では「システムの内側」を設計します。
「内側」って？
簡単にお伝えすると、外部設計したシステム仕様を実現するための設計となります。
利用者からは見えないところなので、通常お客様が意識されることはありません。

設計の例

たとえば、画面Aのボタンを押されたことで何かしらの処理後、画面Bが表示される仕様だとします。
このとき、

　・画面Ａでボタンを押された画面Ｂを表示する
　・このとき画面Bを表示するために画面Ａから画面Ｂに引き継がないといけないデータ

などの入出力設計

　・複雑な計算のために、一時的にファイルやデータベースを利用して計算を楽にする

などの機能的な設計

　・利用者が意識しないようなエラーが起きた時の対処方法

などがあります。

また、画面でボタンを押したあと、大量データを扱うため数分かかるような機能ががあった場合、
どうやってそれを実現するか考えます。
無策のまま作ってしまうと

　・タイムアウトが発生して操作が継続できなくなる
　・画面が固まって利用者は不安になる

などの懸念があります。
これをどう回避・実現するか、利用性を低下させないか、などを考える（設計する）必要があります。

また、保守性を担保するためにプログラマーが好き勝手作らないように開発におけるルール、あるいは作りやすいような仕組みやルールもこの工程で策定します。

発注者は何かすることはあるの？

いいえ、ありません。

先にも書きましたが、お客様にご対応いただくことは基本的にはありません。
外部設計で決めたことをどのように作りこむのか、実現していくのかを検討・決定する工程です。
要件定義・外部設計まで終えたら、まずは一安心していただければと思います（笑

おまけの情報

ただ、プログラミング工程を外部に委託（発注）する場合には、これだけで足りません。
委託先と仕様の認識齟齬が生じないよう、もっと詳細に解像度を高くした仕様書を用意する必要があります。
その分設計コストも膨れ上がります。
海外（オフショア）に委託となると言語の壁もあるため、さらに詳細な仕様書が必要となります。

このような場合、プログラム設計書と呼ばれる文書などが必要になります。
これはプログラムをどのように組むのか、プログラマーへの詳細な指示書となります。
本来それはプログラマーが自身で考えて作っていくべきと考えていますが、そこまで準備しないと想定と違った仕様が作りこまれるリスクがあるためです。

我々は基本的にはすべて社内開発しているため、上記のような細かい設計はしておりません。不要なのです。
＃一部外部委託することもありますが、その場合でも当社のフロアで当社開発チームの一員として開発にご協力いただくスタンで取り組んでおります。

さいごに

内部設計（詳細設計）工程の成果物については、
やろうと思えば「いくらでも設計書は作れます」＝「お金と時間をかけることができます」。
が、
費用／品質／保守性等のバランスを踏まえ、必要最小限にとどめるよう意識しております。

また、成果物については設計者とは別のSE（システムエンジニア）が不具合・不整合・抜け漏れ等を確認する（「レビュー」と言います）ことで品質をつくりあげていきます。
「レビュー」については、別の機会に説明したいと思います。

次回は次工程の「プログラミング」と「単体テスト」について、軽く触れていきたいと思います。