複数人で開発を進めるプロジェクトの場合、プロジェクトの標準を決めておく必要があります。
標準があることで、開発するシステムの画面やつくり、ドキュメント等のばらつきをなくし、品質を一定にすることができます。
標準化のメリットは数限りなくありますが、今回はプロジェクトの上流工程、お客様との要件検討や外部設計の検討のときに用意すべき標準を説明します。
開発標準：ユーザとの要件や外部仕様検討のときに必要なもの
プロジェクトの標準というと、ドキュメントのフォーマットなどを中心に考えてしまいますが、実はそれ以外にもいくつかあります。
その中で、今回は上流工程で必要な標準です。
主に決めるべきルール・標準を４つ挙げてみました。
プロジェクトの上流工程で必要な標準
- ドキュメント標準
- 開発標準（画面標準）
- コード体系・ルール
- 管理標準
標準書、またはプロジェクトのルールとして定めておくべき標準は、プロジェクトによっていろいろありますが、上記４つは大きなものですので、複数名で進めるプロジェクトを実施する際には、準備が必要になります。
ドキュメント標準
まずは、ドキュメント標準です。
いわゆるお客様に納品する仕様書のフォーマットおよび、その書き方です。
仕様書なら仕様書として、必要な目次、それぞれのフォーマットおよびその書きかた、書きかたサンプルです。
書きかたのサンプルがないと記述レベルをあわせることができなくて、フォーマットは一緒でも書いているレベルがばらばらということにもなりかねないので、サンプルは用意すべきです。
目次としては、上流工程で仕様書として用意するものを記入します。
例えば下記にしめすようなものです。
・画面／帳票レイアウト、
・処理機能記述
・データベース定義
・他システムインタフェース確認
・共通部品の定義
データ中心の場合は、ＤＦＤを書いたり、オブジェクト指向を使う場合にはオブジェクトモデルを書いたりもしますし、業務フローや運用フロー、システムの概要図など、必要に応じて納品物として定義します。
標準書として落とし込むのは、複数メンバーで記述する、画面、帳票、バッチ処理などの仕様書まわりに絞り込みます。
標準は、複数名で書くことに対するばらつきをなくすのが目的だからです。
開発標準（画面標準）
次に、開発標準です。
お客様とシステム要件・仕様を合意するために同じような内容は統一するという目的で、標準の内容を定義します。
多くのプロジェクトで必要になるのは、画面や表徴などの標準です。
画面標準を例にします。
記載する内容は、見た目に関する内容、操作性に関する内容、処理に関する内容、前提条件などしっかりと定義する必要があります。
見た目に関する内容：
画面のサイズ、レイアウト、フォント、ボタンの配置、画面やオブジェクト等の名前の付け方、ボタンの配置、色などの見た目に関する内容です。
入力項目やボタンの配置については、左から右、上から下とか、ボタンの配置も考え方を示してもいいかもしれません。
操作性/処理に関する内容：
画面は見た目だけでは定義しきれないため、操作性に関してもきちんと定義します。
例えば、Ｗｅｂ系の場合は、戻るボタンをどう扱うとか、入力チェック、エラー処理の動作（ひとつひとつチェックするのか、一括でチェックするのか、エラー発生時のエラーのあつかい等もしっかり定義します）
操作性が各画面でバラバラではお客様も使いにくいし、そもそも後工程で開発にはいったときに、作りも共通化できなくなり、場合によっては手戻りで再検討になったりします。
お客様にとっても気になる部分になりますので、画面の共通操作として事前にまとめて、お客様にも確認いただき承認してもらうのが、プロジェクトの進め方としてはいいと考えます。
入力チェック
チェック場所（クライアント、サーバー）
エラー表示（１件、全件）
表示方法（画面のメッセージエリア、ポップアップ）
エラーチェックをどこまで実施するかの考え方
登録時の動作
確認画面の有無
確認画面の表示方法
ボタン押下後の動作
二重リクエスト防止有無、防止の方法（非活性、メッセージ）
Ｗｅｂ画面特有
ぱんくずリスト（履歴）の表示有無
戻るボタンのあつかい、許可、許可しない、表示する・しない
入力禁止文字
画面のスクロール時の動作
ヘッダの固定、非固定
表示件数、次ページの動作の動き
各ページでの表示件数
その他にもプロジェクト固有の操作性の統一感をだしたりする部分が多々存在すると思います。
最初に実装パターンをいくつか決めてしまって、その範囲でお客様と調整した方が、プロジェクトを円滑に進められます。
また、パターン化することで、共通化も可能になり、プロジェクトの生産性や将来の保守性にも影響してきます。
前提条件：
OS、ブラウザ、そのバージョン等
対象範囲が広がれば広がるほど開発時の考慮点やテストの範囲もひろがりますので、標準にいれるかどうかは別として、事前に定義しておく必要があります。
そういう意味では、サービスレベルとして合意すべき内容は、稼働時間帯など他にもたくさんありますので、事前に定義しておく必要がりあります。
コード体系・ルール
コード体系は標準として独立させるか、ドキュメント標準、画面標準、管理標準それぞれに入れ込むかはプロジェクトで決めたらいいとは思いますが、今回は、ついつい忘れがちな項目になるため、あえて独立して見えるようにしました。
上流工程であれば、お客様が触れるコードについては、まずきちんと体系を定義してください。
例えば、ユーザＩＤ，社員番号、システムＩＤ等です。
あわせて忘れがちなのが、各種ドキュメントのファイル名、画面等のＩＤ、命名基準、データベースの命名基準等です。
忘れずに定義しておきたいです。
管理標準
ドキュメント関連と実際の成果物に直結する標準に加えて、管理系の標準もプロジェクト運営においては必要になります。
報告関係のドキュメント、進捗関係の必要ドキュメント、管理指標、報告タイミング等。
標準というかルールというか、事前に取り決めて展開しておくことでプロジェクトも円滑に運営できるようになります。
進捗報告書などは、フォーマットや管理指標を取り決めて展開しても、実際の記載方法、進捗報告の考え方をルール化しているプロジェクトは少ないかもしれません。
このプロマネだから、こう書かないと指摘されるから、などという過去の経験から判断しているケースもよく見かけました。
課題には必ず対策を書くなど、基本的なことは特に問題なければ事前にルール化しておく方がいいと考えています。
暗黙の了解では、メンバーが変更になるたびに、１から教えたり指示したりする必要がでてきて、それを進捗会議でやっているのは、参加者の時間を奪うことになりかねません。
プロジェクト管理については、標準ルールを、プロマネとして、しっかり策定すべきです。
標準書の作成タイミング
標準は、次の工程が始まる前にしっかり準備しておくことが大切です。
工程別に契約をする場合などは、定義した標準がつくり方や前提条件を定めているわけなので、
見積もりの前提、見積もりを左右するものになる可能性が高くなります。
事前に準備する、逆に言うと、標準を作成するための工数も見積もりには漏らさないということも、プロジェクトを進めるためには大切なことになります。
まとめ
プロジェクトの標準は、各種機能などの実際の成果物と違い、見積もりの項目などからも漏れてしまい、場合によってはおろそかになりがちな項目です。
しかし、今回提示した内容は、決めなければプロジェクト後半、実際に開発をはじめてから問題になる内容ばかりです。
標準化せずにバラバラに開発した場合は、開発者全員がスーパーマンである必要があったのを、標準化でパターンにして、共通化してしまうことで、２割のスーパーマンが共通部分を受け持ち、残りは経験が浅いメンバーでやりきる、ということもできるようになります。
プロジェクトを円滑に進めるために標準化は、忘れずに実施するようにしたいものです。
最後までお読みいただき、ありがとうございました。
