はじめに
私がSEになりたての頃、システム開発に何を知っていればよいのか、何をすればいいのかが分からず苦しんでいたことがありました。
SEになったものの何から手をつけていいかが分からず、現場を去っていく方も多いかと思います。
私の周囲でも何人もの人が辞めていきました。
そんな人を少しでも減らすため、これからシステム開発をする人たちの一助となればと思いシステムを開発するための基礎知識について書いていきます。
一般的なプロジェクトの進め方
BtoB向けのシステム開発では一般的にはウォーターフォールモデルでプロジェクトを進めていきます。
ウォーターフォールモデルではWebシステムを作成する場合、主に要件定義、設計、製造、試験、リリースという工程が定義されています。
しかしながらこれらの工程の中でどういったことをするかということはプロジェクトによってまちまちで、現場の裁量によるところが多いのが現状です。
各プロセスで必要になるアウトプット
プロジェクトを進めていくためには各プロセスでどのような成果物が必要であるかを明確に定義する必要があります。また成果物のフォーマットも定義しておくことで、プロセス間での抜け、漏れ、重複を防ぐことができます。
方式設計
ハードウェアの構成要件やネットワーク構成や対応ブラウザといった環境面を定義します。
プロジェクトリーダやプロジェクトマネージャになってくるとこの辺りも考えることになります。
基本設計
要件からシステムに落としこむための設計工程です。
画面設計、帳票設計、DB設計、IF設計、バッチ設計などを作成します。
基本設計までをシステム発注側に確認してもらうことが多いです。
詳細設計
基本設計から製造に落としこむための設計工程です。
クラス図、パッケージ図、コンポーネント図などを作成します。
プログラマが読んで実装に落とし込める内容を記載します。
重要なこととしては基本設計→詳細設計→製造というプロセスにおいてなるべく整合性を失わないための工夫をすることです。
例えばDB設計を起こした場合、DB設計書からDBのテーブルを生成するためのソースコード(DDL)を自動生成できるようにする、コード定義書から、enumのファイルを自動生成できるようにするなどといったことをしておくと設計と実装の乖離を少なくできます。
ソフトウェアにおいては改修を積み重ねていくと設計書と実装の乖離が進んでいきます。
設計書は役にたたないからソースを読めといったことは日常茶飯事です…。
上記のように整合性を保つ工夫をしておかなければあっという間にソースが設計書になります。
まとめと今後の展望
システム開発のおおよその流れは掴めたでしょうか。
大規模なプロジェクトになると要件定義、基本設計、詳細設計、製造がすべて別の会社ということもあります。
各工程で決めるべき内容について入念に決めておけば、プロジェクトの手戻りを最小限に抑えることができます。
これからの記事内では具体的な例を元にどのようにしてシステムが作られていくかをお見せしたいと思います。
