システム開発工程ver4

皆さんは、システムエンジニアとしてどの工程を担当していますか？
上流工程を担当していますか？それとも下流工程を担当していますか？
 
フリーランスで働く以前に、システムエンジニアとして働く以上、システム開発工程を理解しておく必要があります。
 
そこで、シリーズ企画として、システム開発工程の概要から各工程の大切なこと、やっていく上でのコツをこのシリーズ企画でお届けしています。
 
今回はver4として、「内部設計」についてお届けします。
 
ぜひ、内部設計に従事されている方、内部設計の仕事をされたい方は、ぜひご覧ください。

システム開発の上流工程の最後である「内部設計」の仕事と、仕事を行う上でのコツを私の経験談からお話します。

内部設計が、上流工程の最後の工程になります。
「外部設計書」から、「内部設計（詳細設計）書」を作成することが主な仕事になります。
 
さて、いきなりですが、クイズです！
上部の図で２人に「見る」の矢印が出ていますが、一体、誰のことを指しているでしょうか？

答えはこちらです。

「コーディングする人」と、「単体テストをする人」が見る設計書となります。
わかりましたでしょうか？

ここでお伝えしたかったのは、コーディングする人と、単体テストをする人が見るということは、設計書を見ただけで、プログラミングができる設計書を作成する必要があるということです。

そのためここからは、システムの思考で設計書を記載することになります。
ただ、内部設計書は、外部設計と同様で、一つの成果物を作成するわけではなく、以下の成果物を作成します。

＜外部設計書の種類＞
・処理詳細仕様書（IPO）
・クラス図
・モジュール構成図
・アクティビティ図
・シーケンス図
などです。

内部設計でも作成する成果物が多く、プログラミングを意識したシステのム内部処理を考えて記載することになります。
そのため、ユーザさんには見せない成果物になるので、システム目線で記載しても良い成果物で、ユーザさんと接する機会はないため、システム開発に集中できる工程とも言えます。

なので、システムのことを考えたい人は、内部設計の工程から携われると良いと思います。
各種設計書については、外部設計書と合わせて、別の記事で纏めてみようと思います。

私が思うこの内部設計を行う上でのコツですが、以下４点だと考えています。
　①あいまいな表現はしない。文章だけでなく、図や表を利用する。
　②内部処理の利用方法を十分に理解しておく。
　③画面側処理と、サーバー側処理で行う内容を、明確にしておく。
　④エラーハンドリングを十分に検討する。

内部設計書を見て、コーディング、単体テストを行うことになります。
そのため、条件式などを曖昧な表現にしていると、バグを作りこむ原因になるため、注意が必要になります。

「条件式（個数が１以上の場合）」の記載にするとプログラマーは、「if（kosu >= 1）」というプログラミングを行います。

もし、この記載の他に「条件式（個数が１を超える場合）」や、「条件式（個数が１未満の場合）」などの記載があった場合は、どうでしょうか？

不等号として、「＞」なのか。「＜」なのか。はたまた「＜＝」なのか。プログラミングに困ります。そのため、内部設計書はユーザさんには見せない設計書のため、ある程度の専門用語を利用し、「条件式（個数＞１の場合」のように、不等号などの記号を直接記載することや、フローチャートや表を利用し、伝わりやすい表現で記載することが大切です。

内部設計では、複数の内部処理を適切な順番に呼び出すことで、１つの機能を設計していいきます。その過程で、既に準備されている内部処理を流用することや、新しい内部処理を作成することがあります。
その「内部処理」を、新しく作成する必要があるのか。や、既存処理を流用できるのか。を考える必要があり、その考えるために、システムの内部処理を十分に理解しておく必要があります。

内部処理を十分に理解していない場合、正しい順番で処理を呼び出す設計ができない。や、同じ内部処理を複数作成することになるため、内部設計書を書く前に、内部処理について理解しておくことが大切です。

最近は、画面（クライアント）側とサーバー側に分かれてプログラミングをし、最終的にその２つをつなぎ合わせて、システムとして稼働させる方法がメジャーになっています。

そのため、画面側のみできる処理や、サーバー側のみできる処理、その逆で、どちらでもできる処理があります。

どちらかのみできる処理は、できる方でやれば良いのですが、どちらでもできる処理の場合は、どっちで処理をするのか。を明確にしておく必要があります。
明確にせずにプログラミングした場合、両方ともに同じ処理を実装することや、両方ともに実装されていないことがあるので、画面側、サーバ側で行う処理を明確に決めて、記載しておくことが大切です。

内部設計書では、プログラミングを意識した設計が必要です。
つまり、プログラム内でエラーが起きた場合の、対処を十分に設計する必要があります。

外部設計書では、システムが正常に稼働した場合の流れを中心に記載されていることが多く、システムが想定外でエラーになった際の挙動などはあまり記載されていないです。

なので、想定外でエラーになった際に、どのような挙動とするのか。を明確に、設計書内に記載する必要があります。
記載していないと、想定外エラーが発生した際、何が起きているかを調査できない事態が発生するので、エラーハンドリングを十分に検討することが大切です。

いかがでしたでしょうか？
こちらが内部設計の仕事とコツになります。
この工程からは、システム開発のみに携われる工程なので、実際に手塩をかえて、細部にこだわってシステムを作成することができます。
こだわることができると思うと、非常にやりがいがある工程だとおもいませんか？