
ユーチューブ
エンジニア
.png?fit=crop&w=335&h=200)
皆さんは、システムエンジニアとしてどの工程を担当していますか?
上流工程を担当していますか?それとも下流工程を担当していますか?
 
フリーランスで働く以前に、システムエンジニアとして働く以上、システム開発工程を理解しておく必要があります。
 
そこで、シリーズ企画として、システム開発工程の概要から各工程の大切なこと、やっていく上でのコツをこのシリーズ企画でお届けしています。
 
今回はver3として、「外部設計」についてお届けします。
 
ぜひ、外部設計や内部設計の仕事に従事されている方、外部設計や、内部設計の仕事をされたい方は、ぜひご覧ください。
ここからは、システム開発の上流である「外部設計」の仕事と、仕事を行う上でのコツを私の経験談からお話します。

外部設計から、システム開発が本格的に開始されます。
 「要件定義書」から、実際にシステムを作成するための工程になります。
 
 外部設計は、まだユーザよりの内容ですが、プログラミングを意識した成果物を作成することが必要です。
 要件定義書と、システム処理の両方を意識しながら、「外部設計(基本設計)書」と呼ばれる成果物を作成するのが主な仕事になります。
 
 ただ、外部設計書は、一つの成果物を作成するわけではなく、以下の成果物を作成します。
 
 <外部設計書の種類>
 ・画面レイアウト、画面項目定義書
 ・帳票レイアウト、帳票項目定義書
 ・画面イベント定義書
 ・テーブルレイアウト定義書、データ定義書、E-R図
 ・外部IF一覧、外部IF定義書
 ・CROD図
 などです。
 
 外部設計工程になると、作成する成果物が多くなり、内容もシステムをきちんと理解していないと書けないものになりますので、いかに「システム理解」と「要件理解」をしているかが重要です。
 
 また、要件定義では決めきれなかった内容を、ユーザさんと打ち合わせすることもあるため、少しだけユーザさんと接する機会があることも外部設計工程の特徴といえます。
 
 なので、システム開発に携わりたいけど、ユーザさんと接する機会が欲しい方は、外部設計をしてみても良いかもしれません。
 外部設計書の種類の詳細については、別記事で纏めてみようかと思います。
 
 
私が思うこの外部設計を行う上でのコツですが、以下4点だと考えています。
  ①システム改修の場合は、改修を行うシステムの処理内容を細部まで理解しておく。
  ②新規システム構築の場合は、自由な発想で処理内容を考える。
  ③お客さんと話すときは、システム視点の話だけではなく、ユーザさん目線で話す。
  ④後続工程(設計・開発・テストなど)のことも意識し、プログラマーの方が読みやすく、理解しやすい成果物を作成する。
システム改修の場合は、システム内の一機能の改修を行う外部設計が多いです。
 そのため、改修を行う機能の知識がないと、使いやすいシステムで、品質が良いシステムを開発することができません。
 設計工程だと要件定義とは違い、機能の細部まで知る必要があり、一機能の中のこの処理をどう組み替えるのか。という要件定義より、システムに一歩踏み込んだ視点を持つことが重要です。
 
 
新規システムの構築の場合は、元になるシステムがなく、ユーザ要件とIT要件だけが存在する状態になります。
 そのため、どのような画面で、どのような処理を実現するのか。という点は、システム開発する人に任せられることが多いです。
 なので、自由な発想で考える必要が多くなりますので、在るものから考えるのではなく、無いところから、何かを生み出す思考が必要になってきます。
結構、システム利用されるユーザは、システム開発やIT技術を知らない人が多く、システムでは実現が難しい要望を言ってくることがあります。
 そのため、開発者の視点と、ユーザ視点ではギャップが生まれることが良くあります。
 
その結果仕様検討会という会議で、ユーザさんと検討する場面があった場合は、単にシステムとしてはこういう挙動になります。というシステム視点の考え方だけではなく、ユーザさんが何を実現したいのか。という思考と、ユーザさんに伝わる説明の仕方を意識して、会議に臨む必要があります。
外部設計は、要件と開発を繋げる橋渡しとある工程です。
 そのため、外部設計の内容を元に、プログラマーが実際のシステムを構築していきます。
 なので、プログラマーがいかに読みやすいか、また伝わりやすいか。を意識して、外部設計書を作成することが重要です。
 
 プログラマーが読みづらい設計書だと、バグを生み出すやすく、また、プログラマーに意図が伝わらず、効率よく開発が進めることができなくなります。設計者からしたら当たり前。と感じる内容も、プログラマーからしたら、当たり前ではないこともありますので、主語や当たり前の内容でも、設計書に記載しておくことが無難です。
 
 そこで、プログラマーの方に伝わりやすくするために、フローチャートを作られることもあります。
 また、こちらも別記事でかけたら良いなと思っています。

いかがでしたでしょうか?
こちらが外部設計の仕事とコツになります。
ユーザさんとも会話でき、システム開発にも携われる工程になります。
直接ユーザさんの声も聴くことができるため、やりがいが感じやすい工程でもあると思います。実際に手塩をかえて作成したシステムが、ユーザさんに役にやっているのか。や、直接感謝の言葉もいただけこともあるかもしれません。
そう思うと、非常にやりがいがある工程だとおもいませんか?
 
