開発フェーズのいろは その1

随分前置き(建前)が長くなってしまいましたがそろそろエンジニアの皆さんに役立つお話しをしていこうと思いますｗ
また、かみ砕いた初級編的な位置づけで書こうと思っているので新人営業さんなんかも見て頂けると参考になるかもしれません。
まずはシステム開発の手順とも言える『フェーズ』について考えてみましょう。
今回はウォーターフォールを例として取り上げます。
フェーズは要件定義>基本設計>詳細設計>実装・単体テスト>結合テスト(ITa)>統合テスト(ITb)>システムテスト>受入テスト(UAT)として説明します。
長くなりそうなので3部構成くらいにしたいと思いますｗ

要件定義

要件定義とは？

要件定義フェーズとは簡単に言うと『どんな物(システム)を作るか』を決めるフェーズです。
お客さまの希望するシステムを作るので、お客さまの仕事はどんな仕事なのか、どのお仕事をどのようにシステム化するのかをお客さまと検討します。
本来ならお客さまが主体となって進める作業ですが、お客さまはシステム開発の要件定義などやったことがない事がほとんどでしょう。
ですからシステム開発のプロとして支援するのが大切です。
よく「お客さまの業務はお客さましか分からないので要件を出すのはお客さまの仕事」という人もいますが、これは少し違うかと思います。
当然、その顧客独特な業務などはありますがそれ以前の一般的な業務(例えば物流や販売、経理など)は身につけていればいるほどお客さまの役に立つことができますし、現行の帳票や伝票(手書き含む)などしっかり確認すれば独特な業務などを掘り起こすことが可能です。
ここでオススメなのが会計の知識です。
仕事というのは必ずお金の動きで仕訳が起き最終的に会計として集計されます。
それ以外の部分はお好み次第で良いわけですから判断しやすいでしょう。
好みで決めて良いこととルール上繋がらないといけない部分の切り分けをすることで判断の元とすることができます。

具体的な成果物は？

詳細に言うと膨大な成果物があるのですが、ポイントだけかいつまんで言うと
・このプロジェクトはどんなプロジェクトなのか(プロジェクト計画)
・今回対象となる業務はどんな物で今回どうなるのか(新旧の業務フロー)
・新しい業務のうちどの部分がシステム化されるのか(機能一覧、画面一覧、帳票一覧、バッチ一覧など)
・どんなデータを保持するのか(ERD、テーブル一覧、データ項目定義、データディクショナリ)
・外部システムとはどのようにインターフェースをとるか(インターフェース定義書)
・システムはどのように運用されるか(運用・操作要件)
などが必要になります。
私が重視するのは新旧の業務フロー、機能一覧、データディクショナリです。
どんなお仕事をどのようにシステム化するのか、を端的に表せる資料として、顧客との認識合わせをする事ができます。

作業のポイント

要件定義のスケジュールを引く場合に一番やってしまう失敗は『成果物の作成工数だけを見て線を引いてしまうこと』です。
これが実に難しいのですが、要件定義は機能毎、成果物毎にお客さまと合意をとりながら進めるため、基本的には打合せの回数が大変多くなります。
そのため「打合せ待ちで資料が作れない」という現象が実に多くなります。
ですから基本的には打合せ回数をベースに線を引きましょう。
1回の打合せで2機能進めそうなら、10機能の要件定義は5回の打合せ、週1回でなら5週間掛かると言う事ですね。
また、成果物のレビューも必要なので考慮が必要です。

基本設計

基本設計とは？

要件定義が『どんな物を作るか』なら基本設計は『どう作るか』を検討するフェーズになります。
ただ、このフェーズでもどんな画面にするか、どのような帳票にするかなどお客さまとすり合わせが必要な部分もありますのでどんな物を作るかが部分的に残っています。
それでも基本的には要件定義で決めた事をどのようにシステム化するのかを片っ端からやっつけていくことになりますので、SEの腕の見せ所である事には変わりありません。
画面一覧から画面設計を起こし帳票一覧から帳票を設計する、という形で作業が進んでいきます。

具体的な成果物は？

基本設計では要件定義で作った資料のブレイクダウンが主な作業になります。
・各機能の具体的な設計(画面設計、帳票設計、バッチ設計)
・データベース設計(ERD、テーブル設計)
・外部インターフェースの具体的な設計(インターフェース設計の項目レベル)
そして忘れてはならないのが
・開発基盤設計(共通化、抽象化、部品化)
・技術検証
です。
面倒だったり具体的な開発のイメージが持てないからといって詳細設計以降へ後回しにすると必ずと言って良いほど「今さら共通化できないので今回は個別実装で」という羽目になりますｗ

作業のポイント

私がマネジメントをやっている時に基本設計をやる人にお願いするのは、「システムが実際に動くイメージまで考えてください」と言う事です。
まだ基本設計だしあとで良いか、ではなく、もう基本設計であとが無い、と考える必要があります。
全体を見てシステムの設計が出来るのは基本設計が最後でこれ以降は個別の機能の事しか考えなくなります。
この時点での考慮漏れはシステムの品質に大きく影響する意識を持ちましょう。

おわりに

今回はシステム開発では『上流工程』と呼ばれる要件定義・基本設計について書いてみました。
経験したことがない人にとってはプログラムを作るのがシステム開発と感じている人も多いと思うのですが、バリバリ実装が出来るというのはこうした基盤とも言える部分をしっかりやっているからとも言えます。
上流工程に関わる人はマインドとして「後続のフェーズに参画する人ができる限り楽に正しく作業できるように」という気持ちで設計することが大切ですね。