プロジェクト開発標準として用意すべきもの【下流工程（設計・製作・テスト）】

システム開発のプロジェクトでは、標準を用意しておくことが成功につながります。

今回は、下流工程（設計・製作・テスト）の標準について説明します。

上流工程では、お客様と開発するものを確定するため、開発するシステムが外見、お客様から見た統一感がなくならないように標準化をしました。

下流工程では、開発対象そのものの作り方がバラバラにならないように、そして品質にバラつきがでないような標準化をすすめます。

標準書、またはプロジェクトのルールとして定めておくべき標準は、プロジェクトの制約にあわせて準備します。

標準書をゼロからつくるのは時間もかかるため、会社や組織で準備している標準に不足がある場合は、他のプロジェクトなどからの転用も検討します。
転用する場合には、転用して問題がないか、標準の利用制約については事前調査をしっかり行います。

開発標準：設計・開発・テストで必要な標準

今回は、下流工程で必要な標準です。

主に決めるべきルール・標準を列挙しています。

各標準について内容を説明します。

ドキュメント標準

設計書やテスト仕様書のフォーマットおよび、その書き方です。

設計書に必要な目次、それぞれのフォーマットや書きかた、そのサンプルになります。

設計書の標準の場合は、標準そのものはフォーマットにして、サンプルのかわりに実際に開発した１本目を例として展開するのが効率的です。

ただし、これをする場合、１本目をコピーして作成する標準的な使い方になりますので、１本目の品質が重要になります。

スケジュール上余裕を見たうえで、標準作成・事前開発タスクを実施し、その中で設計・開発・テストを実施して、作成したものを展開するのがおすすめの進め方になります。

ドキュメントの標準として準備するものは下記に示すようなものです。

設計ドキュメント

• 処理フロー図
• 処理記述
• クラス一覧・クラス図・クラス定義
• メソッド記述
• メッセージ一覧
• インターフェース定義（プログラム間、システム間）

テストドキュメント

• 単体テストケース
• 結合テストケース
• システムテストケース
• ユーザテストケース

単体テストとそれ以降のテストケースはフォーマットを変える場合もあるため、必要に応じてテストケースの書きかたを標準化します。

成果物という意味ではプログラムもその一つですが、そちらはコーディングルールとして標準化するのが一般的です。

開発標準（設計）

実際の設計パターン、実装パターンのルール化になります。

これは、上流工程で定義した例えば画面標準等にあわせて、その標準を実現するための設計方法の記述になります。

例えば、画面標準上に下記記述があったとします。

「入力チェックはクライアント側で実施し、エラーがあった場合は、エラー箇所にフォーカスをあてメッセージエリアにエラーメッセージを表示する」

設計する場合、共通関数をつくってその関数を呼ぶ出すことにするのか、ルールに従ってつくってもらうのかで、作り方がかわってきます。
共通関数を呼び出す場合には、例えば以下のようになり、必要に応じてメッセージのＩＤを付与したり、することになります。
「各項目に対して、入力チェックを実施後、エラーメッセージ表示関数(ErrorMessage)を呼び出し、エラー箇所にカーソルを移動する」

この部分は実装方法によってかわってきます。

ここまで記述せずに、「エラーチェックを行いエラーメッセージを表示、エラー箇所にカーソルを移動する」程度で統一記述にして、実装時に実際の実装したコードを標準パターンとして展開するのが、効率的な場合もあります。

どのような進め方をするのかは、プロジェクトと体制などによって変わりますので、状況にあわせて標準化のやり方はかわってきます。

設計・実装のパターン化対象例

• エラーチェック/表示方法
• データベースへのアクセス方法/デッドロック回避方法
• ログの出力方法、出力レベル設定
• 次ページ画面表示方法
• データの更新方法

実プロジェクトでは、業務にあわせて標準化してください。
標準化した方が、全体の効率があがりますので、設計・実装は標準化を進めることをおすすめします。

コーディングルール

プログラムの書きかたになります。

コーディングルールには、変数名や関数名の付け方、やコメントの書きかた以外にも、コーディング上の制限なども記載します。

例えば、if文のネストは3層までにするとか、Pythonで３項演算子は使わない等です。
このあたりの制限については、データベースを利用する場合、大規模プロジェクトでは性能を確保するためには、ＳＱＬ文には一定の制限(Join数制限等）をつけた方がよい場合が多いため、必要に応じて標準化を実施します。

コーディングの記法については、以前記事にしていますので、必要に応じて参考にしてみてください。

テスト標準（品質指標）

システムの品質をあげるために、品質の指標を定義することは必要になります。
プロジェクトは、限られた期間・リソースで実施することになりますので、指標がないと、どこまでテストをすればいいかがあいまいになるし、複数のチームで開発している場合、チームごとに品質が一定しなくなってしまいます。

品質の指標とは、設計のタイミングには、ドキュメント枚数あたりの設計レビューの指摘数を一定の範囲内に決めておくということです。

その範囲からはずれた場合に、その理由を考えることで正しいテストがおこなわれたかをマネジメントレベルで判断することが可能となります。

例えば、指摘数が多すぎる場合、指摘された個人のレベルが悪いのか、書きかたが悪いのか、その機能だけ特別難易度が高いのか等、理由を特定することで対策につなげることができます。

指摘数は少なければ少ないほどいいわけでもありません。
レビューアのスキルが低くて適切なチェックができていない、レビュー観点が不足している等の課題も考えられるからです。

指標は、閾値にすることで品質の向上を狙います。

テストにおいても基準値を設定します。
テストケース数や開発規模の考え方を明確にした上で、開発規模に応じたテストケース数、バグ摘出数に閾値を設けるということです。

この場合も、バグの発見が少なければ少ないほどいいわけではありません。
十分なテストが行われていない可能性があるからです。

単体テスト、結合テスト、システムテスト等、テストごとに閾値を設けて、各テストで十分な品質をだせているかをチェックすることで、品質向上を狙います。

管理標準

設計・開発工程は、プロジェクトの中では最も人数が多い工程になるのが一般的です。

状況を把握するための管理指標を明確にすることで、問題の早期発見、早期対策が可能となります。

成果物数、テストケース数などを指標として、毎週の進捗目標を定め、達成・未達成をポイントでみることで大局的にプロジェクトの進捗状況が把握できます。

日々、状況を視える化するｋとで、遅れた場合には早期対策をうつことが可能となります。

下流工程では、開発するそのもののバラつきをおさえ、品質を保つためにも標準化は重要になります。

標準はその標準を利用するタスクが始まる前に、しっかり準備して手戻りがないようにプロジェクトをすすめることが、プロジェクト成功のポイントとなってきます。

最後までお読みいただき、ありがとうございました。