プロジェクト標準ってなに？
システム開発の標準化がわからない？
標準化ってなぜ必要なの？
プロジェクト標準（標準化）は、プロジェクトを円滑に運営するために取り決める基準です。
もし、プロジェクト標準が無かったら、属人的で品質にバラツキがある使い難いシステムが開発されます。これではいくら必要な機能を満たしていても使えません。次第に利用ユーザーからクレームが出て、失敗プロジェクトの烙印を押されることでしょう。
今回は、プロジェクト標準とは何か、プロジェクトで準備する3つの標準化と作成タイミングをわかりやすく解説します。
前回のおさらい（プロジェクト計画の書き方）
これまで、プロジェクトを成功させるためにプロジェクト計画を立てること、そしてプロジェクト計画の最初は「プロジェクト概要」をまとめることを解説しました。
プロジェクト概要がまとまったら、次はプロジェクト計画を詳細に落とし込んでいきます。プロジェクト計画でやるべきことは、そのプロジェクト概要を含めて11項目あります。
これらはプロジェクトを円滑に運営するための重要なガイドと言えるものです。この11項目をプロジェクト計画書にまとめ上げ、ゴールに向かってプロジェクトをスタートしましょう。
- プロジェクト概要
- マスタースケジュール・WBS
- プロジェクト体制
- 成果物
- 変更管理
- 欠陥管理
- 課題管理
- コミュニケーション計画（会議体）
- 要員計画
- リスク管理
- プロジェクト標準 今回はここ
今回は、プロジェクト標準を解説します。
プロジェクト標準（標準化）とは
プロジェクト標準（標準化）は、プロジェクトを円滑に運営するために取り決めた基準となるものです。プロジェクト標準をステークホルダーと共有することで、適正なコストと適正な品質で計画通りにプロジェクトをゴールに進めることを目的としています。
これはシステム開発に限ったことではありませんが、ここではシステム開発のプロジェクト標準について解説します。
では、なぜプロジェクト標準が必要なのでしょうか？
なぜプロジェクト標準が必要なのか
もしプロジェクト標準が無かったら、どうなってしまうのでしょうか？
システムを開発する側とシステムを利用する側のそれぞれで、どのような問題が起こるのか書き出してみました。
システムを開発する側の問題
- システム開発メンバーが好き勝手な方法で開発を行って属人的なシステムが出来上がる。
- 過去の経験やスキル、考え方の違いから、出来上がったシステムにバラツキが生じる。
- 現在の運用保守ルールが無視されたシステムとなり、システム運用に手間がかかる。
- 仕様書の書き方やプログラムの構造が人によって異なり、プログラムを変更する時にどこに手を加えればいいかわからない。
システムを利用する側の問題
- 既存のシステムと画面の構造やボタンの配置が違うため使いにくい。
- 利用するシステムによって操作手順が変わるため操作方法を覚えるのに時間がかかる。
- 声の大きい人（立場の強い人）の強引な要求に合わせて、他の画面と違う作りの画面が出来てしまう。
プロジェクト標準が無かったシステムの末路
このように属人的で品質にバラツキがあり、利用ユーザーにとっても使い難いシステムが開発されるでしょう。属人化されたシステムは開発した本人以外には仕様の理解が難しく、プログラムによって作りが違うと難解なパズルとなってしまいます。
開発したメンバーが残っていれば不具合箇所の修正や機能追加もできると思いますが、途中で会社を辞めることも考えられます。
システムが安定稼働するとプロジェクトが解散されてメンバーがいなくなることも多いため、簡単なシステム改修でも時間がかかったり、仕様が複雑で間違った修正を行なったことでトラブルになることも考えられます。 これではシステム稼働後も安定した運用ができません。
何より、必要な機能を満たしていても画面によって操作が異なるようでは使えません。次第に利用ユーザーからクレームが出ることも容易に想像できます。
標準化の必要性
システム開発のプロジェクトにはシステム開発者をはじめ、多くのステークホルダーが参画します。それぞれ過去の経験や考え方の違いから、様々な意見や要望、自分のやり方があるのは当然です。
そのため、個々のプロジェクトの特性に合わせて、あらかじめプロジェクトの判断基準を設けることでステークホルダー全員のベクトルを合わせる必要があるわけです。
それでは、プロジェクトで何を標準化すべきなのでしょうか？
それは、マネジメント標準、システム開発標準、システム運用標準の3つです。
マネジメント標準
簡単に言えばプロジェクトを円滑に運用するための決め事です。
マネジメント標準では、主に以下のものを準備する必要があります。
進捗管理
進捗報告のやり方やタイミング、会議体を検討して決めます。
| 進捗報告のやり方 | ・設計フェーズは、仕様書の作成状況をどう掴むかの観点で進捗を管理 ・プログラム開発以降は、テストの品質と合わせて進行状況をどう掴むかの観点で進捗を管理 |
| 進捗報告のタイミング | ・毎日や週単位など進捗状況を報告するタイミングを検討 ・問題や課題がある場合、その状況を毎日確認して対策を検討 |
| 会議体 | ・進捗確認の会議は毎日リーダークラスで実施 ・問題・課題を共有し、影響範囲の確認と対策を検討 |
品質管理
この活動を実施することですべてのバグが無くなるわけではありません。同じ目線で品質を測定することで異常値をあぶり出し、問題を早期に察知するために実施します。
| 品質目標 | 各フェーズの目標値を設定 |
| 品質測定と対策 | カバレッジ、テストケースの網羅性 バグ発生件数、バグ密度 テスト件数、テスト密度 品質指標、閾値（上限値・下限値） |
| フェーズ完了基準 | 次のフェーズに進めていいかどうかの判定基準を設定 |
変更管理
プロジェクトの途中で必ずお客様の変更要求は発生します。変更要求が発生した場合の運用ルールや運用フローを決めます。
変更管理の目的と手順についてはこちらで詳しく解説しています。
コミュニケーション管理
コミュニケーション管理は、ステークホルダーとのコミュニケーション方法を決めて合意形成を図り、プロジェクト運営を円滑に進めることが目的です。
コミュニケーション管理（会議体）の種類やポイントをこちらで詳しく解説しています。
リスク管理
プロジェクトには必ず問題が発生します。問題が起こってから対処するのではなく、常にリスクが無いかを評価してプロジェクトを進めることが重要です。
リスク管理の目的や手順、対策について、こちらで詳しく解説しています。
セキュリティ ポリシー
情報漏洩対策、仕様書やプログラムなどデータの保全、ウイルス感染対策、不正侵入防止など、情報セキュリティに関する方針を決めます。
| 情報セキュリティの教育 | ・eラーニングなどによる講習 ・定期的な教育実施（少なくとも年に一度） |
| 入退出管理 （執務室やサーバルーム） | ・入退出カードを紛失しないための行動指針 ・持ち歩く時、入退出する時のルール設定 ・カード紛失時の連絡体制（連絡網の設定） |
| パソコン利用 | ・勝手にソフトウェアをインストールしない ・業務に関係ないWebサイトへアクセスしない ・個人デバイスを接続しない ・メール誤送信の防止対策 |
| 社内ネットワーク利用 | ・個人デバイスをネットワークに繋げない ・大量データを送受信しない |
| サーバ管理 | ・高権限ユーザーの厳密な管理 ・高権限ユーザーによるユーザー管理とアクセス制限 |
システム開発標準
システム開発メンバーが好き勝手に開発しないように、あらかじめ開発方法の基準や規則を設ける必要があります。
主に以下のものを準備しておくと、品質を保ちながら効率よく開発することができます。
ドキュメント標準
システム開発で作成するドキュメント（成果物）のフォーマットと書き方を決めて平準化をを図ることが目的です。
また、ドキュメントの保存方法を決めて一元管理します。
| 設計書の種類を定義 | 設計書のフォーマット | ・どのようなフォーマットにするか |
| 書き方のサンプル | ・どのような書き方をするか ・書く内容は何にするか |
|
| 設計書の保存方法 | ファイル名の定義 | ・ファイル名の付け方 ・機能ごとにIDを割り振る ・ファイル名の体系を決める |
| 保存フォルダの定義 | ・フォルダの作成と保管ルール ・作成途中の管理方法（別フォルダ管理） ・レビュー承認後に完成物フォルダに移動 |
|
| 保存サーバの管理 | ・ファイルを保存するサーバの準備 ・定期的なバックアップの設定とログ確認 ・アクセスユーザーの管理と制限の設定 |
画面設計標準
画面に関するユーザーインターフェースの基準を決めます。
要件定義段階で決めて、画面設計を開始する前にステークホルダー全員と共有して合意することが重要です。
| ブラウザ・OSの定義 | サポートするブラウザやOSはどれか ・ブラウザの種類（Edge、Chrome、Safariなど） ・OSの種類（Windows、Mac、Android、iOSなど） |
| 画面のデザインの定義 | 画面の見た目をどうするか ・画面サイズ（解像度） ・フォントや文字サイズ ・ボタンの配置など |
| 画面操作の定義 | 画面の操作方法をどうするか ・画面を固定する箇所、スクロールする箇所の制御 ・ページング制御（1画面に表示する明細件数） ・データ更新前のメッセージ表示や確認ダイアログ |
| 画面アクションの定義 | 画面の動作をどうするか ・アクションボタンの種類と動作 ・チェック処理のタイミング（ブラウザ側でチェックするか） ・入力禁止文字の制御 ・エラーの表示、ログ出力の有無と内容 ・データベースアクセス方法、排他制御 ・データ削除の方法（論理削除、物理削除） |
| 画面遷移の定義 | 画面を切り替えるルールはどうするか ・画面遷移ボタンの有無（戻るボタンの設置有無） ・ブラウザ右ボタンの制御 ・画面遷移時の確認機能（メッセージ表示とキャンセル） ・画面遷移時に新しいウィンドウを開くか |
帳票設計標準
帳票に関するユーザーインターフェースの基準を決めます。
画面設計標準と同様に、要件定義段階で決めて、帳票設計を開始する前にステークホルダー全員と共有して合意することが重要です。
| 帳票のデザインの定義 | 帳票の見た目をどうするか ・印字文字サイズ ・フォントの種類 ・罫線の有無、罫線の太さ、実線・点線 ・カラー、モノクロ ・ロゴ、社印、印鑑、地図など画像の有無 |
| 帳票の種類・サイズの定義 | 帳票の種類やサイズをどうするか ・帳票の種類（単票形式、リスト形式、複合など） ・用紙サイズ（A4、A3、封筒、ハガキ、特殊サイズなど） ・出力枚数（1日平均、月平均） |
| 印刷方法の定義 | どのように印刷するか ・印刷するプリンターの機種 （レーザー、インクジェット、感熱、特殊プリンターなど） ・PDFなどのデータ保存有無 ・バーコード、QRコードの出力有無 |
コーディング規約
コーディングのルール作成と、それに適合した模範プログラムのサンプル提供を行います。
これにより、プログラムの品質が保たれ、メンテナンス性があがることが期待できます。
| コーディングのルール | プログラムをコーディングする時のルール ・繰り返し制御 ・条件分岐 ・コメント記述ルール ・その他制限事項 など |
| サンプルプログラムの提供 | 模範プログラムとして開発メンバーにサンプルを提供 （コーディングルールと合わせて説明） ・照会系の画面サンプル ・更新系の画面サンプル ・単票形式の画面サンプル（1画面に1レコード表示） ・一覧形式の画面サンプル（1画面に複数レコード表示） ※模範プログラムを先行開発する計画を立てること |
命名規約
ユーザーIDや社員番号、画面や帳票など、一意のIDで管理する項目を作成する時のルールを決めます。
また、区分やコードなどの値や桁数に意味合いを持たせる項目の体系を決めます。
| IDや項目名の命名ルール | 様々なIDや項目名を決める時の命名ルール ・ユーザーID、社員番号、顧客番号などのデータID ・画面ID、帳票IDなどのプログラムID ・エラーID、メッセージID、ログIDなどのシステム利用ID ・テーブル名や項目名 ・変数名、関数名 など |
| 区分やコードの体系 | 値や桁数に意味合いを持たせる項目の体系 ・項目の桁数（データを分類するために何桁必要か） ・コードの意味合い（先頭2桁が年、3桁目以降が連番など） ・利用文字（英字、数字、記号など） |
共通部品利用ガイド
システム基盤やアプリケーション基盤が持つ共通部品の使い方をまとめたガイドブックやマニュアルをプログラマーに提供します。
システム運用標準
システム稼働後の運用保守を円滑に実施できるようにするための決め事です。
初稼働直後と安定稼働後の両面で準備しておくと良いでしょう。
| 初稼働直後 （安定稼働するまでの期間） |
インシデント管理 |
| エスカレーションルール | |
| 運用保守体制 | |
| 障害発生時のフロー | |
| 安定稼働後 | データバックアップ |
| バッチ処理運用 | |
| ハードウェア保守 | |
| 問い合わせ対応 | |
| ネットワーク監視（遅延・輻輳） サーバ監視（死活・性能・ログ） |
|
| システムメンテナンス（プログラム改修） | |
| ユーザー管理 （システム利用ユーザー、サーバ管理ユーザーなど） |
このように、準備する標準化はたくさんあります。
ではそれは、マネジメント標準、システム開発標準、システム運用標準はいつ作成するのでしょうか？
プロジェクト標準を作成する時期は異なる
3つのプロジェクト標準すべてをプロジェクト開始前に準備する必要はありません。
それぞれ、いつ標準化を準備するのか以下にまとめます。
マネジメント標準を準備する時期
マネジメント標準はプロジェクトの運営に関する基準のため、プロジェクト開始前に準備します。プロジェクト計画書にプロジェクト標準の項目を追加し、マネジメント標準の内容を記述します。
プロジェクト標準は、プロジェクトのキックオフ時にステークホルダー全員に説明して合意しておくことが重要です。
システム開発標準を準備する時期
システム開発標準は、開発フェーズによって準備するものが変わります。これらはシステム開発に携わるメンバー全員が理解する必要がありますので丁寧に説明することが重要です。
ドキュメント標準
ドキュメント標準は、各フェーズごとに必要となりますので、そのフェーズが始まる前に準備が必要です。例えば、要件定義のドキュメントは要件定義フェーズが始まる前に必要ですし、概要設計や詳細設計のドキュメントはそれぞれの設計フェーズが始まる前までに必要です。
画面設計標準、帳票設計標準
画面設計標準と帳票設計標準は、ユーザーインターフェースの設計を行う前に準備が必要です。これから開発する画面や帳票のベースになるものですので、設計を進める前にお客様（ステークホルダー）にしっかり説明して合意しておく必要があります。
とは言っても資料だけの説明では理解が難しいため、プロトタイプやモックを事前に作成して説明すると理解が深まりますので効果的です。プロトタイプやモックの作成は、プロジェクトの規模によって必要かどうか判断し、作成するのであればその作業コストや日程も計画に入れておきましょう。
コーディング規約、命名規約、共通部品利用ガイド
コーディング規約はプログラムをコーディング開始する前に準備が必要ですが、上述の通りサンプルプログラムを作成する時に必要になりますのでそれまでに必要です。また、命名規約、共通部品利用ガイドも同様です。
システム運用標準を準備する時期
システム運用標準は、システムが稼働する前に準備する必要があります。システムが初めて稼働する時期（初稼働直後）は問い合わせや障害発生時の対応を迅速に行う体制づくりが重要です。そのためには、システム運用標準をステークホルダー全員に共有して理解してもらう必要があります。
遅くとも、お客様の運用テスト（受入テスト）が完了するまでに作成し、本稼働の判定会議（本番環境で運用開始するかどうか最終判断する会議）が行われるタイミングで説明できるように準備しましょう。
プロジェクト標準は流用と蓄積が大事
このように、プロジェクト標準として準備するものは多く、かなりの作業工数が必要になります。プロジェクト標準が必要なのは理解できても、一から作成するのは大変なことです。
工数削減のためにも、社内の過去プロジェクトで利用したものを流用することが前提になりますが、流用するためには過去のプロジェクト情報が必要です。
なので、プロジェクトが完了後は報告資料を必ず作成し、社内で蓄積・情報共有することがとても重要になります。
もし社内に流用できるプロジェクト標準が無い場合は、外部委託先のシステム会社が独自で持っているものを利用することを検討しましょう。
プロジェクト標準の作業コストと活動計画も忘れずに
他のプロジェクトで作成したプロジェクト標準を流用しても、プロジェクトの特性に合わせて見直す工数は必要です。
特に、システム開発標準の画面設計標準や帳票設計標準は、お客様の意向が強く反映される要素が多いため時間と工数が多くかかります。
そのため、プロジェクト計画の段階で、プロジェクト標準の作業コストとプロジェクト標準を作成する活動計画を漏らさないように注意しましょう。
プロジェクト計画まとめ
以上でプロジェクト計画でやるべき11項目の解説は終わりです。プロジェクトの進むべき方向が明確になったのではないでしょうか。
いよいよプロジェクトのスタートです！
作成したプロジェクト計画をステークホルダー全員に説明してプロジェクトをキックオフしましょう。
そして、次は要件定義です。プロジェクトのカギとなる最も重要なフェーズです。
スケジュールが遅れる主な原因のうち、50％以上が要件定義の不備に起因すると言われています。プロジェクトの成否は要件定義で決まると言っても過言ではありません。
もし要件定義の進め方に少しでも不安がある方は、要件定義の記事をまとめていますので、こちらもあわせてお読みください。要件定義が計画通りに完了することを願っています。
