システム開発におけるプロジェクトでは、規模が大きくなればなるほど、いや実はちいさくても小さいなりに標準化は必要です。
今回はその理由と、標準化とは何をすればいいかについて書いてみます。
システム開発プロジェクトの標準化の必要性
標準化が必要な理由
プロジェクトで標準化が必要な理由は、１つは「ばらつき」、複数人で開発したものの作りがバラバラにならないようにです。
もう１つが、「ムダがおおい」、誰かが考えたものがそのままのやり方で使えるのに、別の人がやり方をまた考えるのは、非効率だからです。
ムダとムラ、これを減らすための標準化になります。
複数人、つまり２人以上で開発すれば発生することですので、小規模プロジェクトでも標準化の考え方は必要だし、もっといえば、例え１人で開発するケースであっても、同じ会社内の他のシステムと同じつくりにしておく必要がある場合もあります。
開発した人が、その後もずっとシステム保守をしていくならいいのですが、通常は１０人とか２０人で開発したシステムでも、その保守をしていく人は１人とか２人になります。１人で開発したのであれば、他の人に保守をお願いすることになる可能性は極めて高くなります。
そのときに、保守担当の人が、Ａシステムはこう作ってあるけど、Ｂシステムはドキュメントのフォーマットも違うし、作りも違うしで、把握するのに時間がかかるし、そもそも障害発生時の対応がシステムによって変わってしまっては、リカバリー時間にも影響しそうだし、いいことはありません。
そう言う意味でも、会社レベルで、それが難しくても類似業務とか管理部署等のある一定の範囲では、システムを標準化するのが効率的です。
標準化を実施する対象
では、標準化は何に対して行うかというと、システム開発上、下記４点は実施すべきです。
・ドキュメントの標準
プロジェクトの成果物を統一する目的で作成します。
仕様書や、設計書に記載する内容、実際に記載するドキュメントのフォーマット（テンプレート）、記載レベルなどの記述や書き方のガイド。また、その際にはプロジェクトで利用するドキュメントのコードの体系、ファイル名等も定義します。
例えば、各種仕様書・設計書（※）、の目次、それぞれのフォーマットおよび記述のガイド等
※外部設計書、詳細設計書、テスト仕様書
・開発標準
システムの作り、およびユーザの操作性の統一のために作成します。
画面の見た目・操作性、システムの作り方、共通部品の使い方などの統一します。
画面標準、設計標準、共通部品のガイドやマニュアル、コーディングガイド等になります。
・マネジメント標準
開発の各工程において、納期・品質・コストをコントロールして、プロジェクトを円滑に進めるようにするのが目的で作成します。各工程の完了条件、テストの品質基準（カバレッジ、バグの発生件数、テスト件数、品質の指標）、セキュリティの基準などをつくり品質の統一をはかります。
また、あわせて、プロジェクトを推進するための運用上の決まり事である、進捗報告タイミング、会議開催タイミング、プロジェクト運営のフローなども定義しておきます。
・運用標準
プロジェクト実稼働後の保守する際に円滑に行えるように作成します。
プロジェクト保守運用ルール：連絡先、障害発生フロー等。
これに関しては、プロジェクトをリリースするまでには決めておく必要がありますが、立上げるまでに決定しておけば特に問題はありません。
システム開発プロジェクトの標準化の進め方
ここまで標準化の必要性とその項目について書いてきましたが、実際のプロジェクトを進める中では、「そうはいっても、忙しくて時間はないし、やってられない」という意見は当然あると思います。
実際、標準化・統一化は、必要性はわかっていても、今進めなければいけないことに追われて後回しにしてしまう、ことはよくあると思います。
さらに、１人、２人のプロジェクトでは、やっても標準化する時間が開発の時間を上回るから、そんな時間はとれないよ、ということは往々にしてあります。
成功するプロジェクトは進め方で標準化する
小さなプロジェクトや、工数が少ないプロジェクトで標準化はどうすればいいのでしょうか？
そもそも、システム作りそのものの費用はお客様から頂けても、標準化そのものの作業は、大規模プロジェクトは別にして、なかなかお客様に理解してもらうことが難しいと思われます。
よくあるのは、以前経験したプロジェクトの標準を流用する（というか、契約上問題がないのであれば、そのまま適用してしまう）というのは、標準化の作業時間がとれないときには有効です。
プロマネは各種標準のひな型を、自分なりに一式、保有しておいた方がいいかもしれません。
ただし、実をいうとそれを使って標準化ができるかというと、それでも３０％から６０％程度かも知れません。
標準書と実施しているプロジェクトが一致すればするほど、メンバーの過去の経験と合致すればするほど、標準化の率はあがりますが、まだ十分ではありません。
がんばって標準書を作成しても、それだけれは不十分なのです。
僕はいろいろなプロジェクトの支援にいかせてもらって、さまざまなプロジェクトマネージャー（ＰＭ）と一緒に仕事をさせてもらいました。
その中で、たいていのプロジェクトを成功させるＰＭと、結構問題になって大変なプロジェクトになるＰＭには、進め方に大きな差があることに気づきました。
成功するＰＭは、「あることをやるときには、一歩前にそのタスクを１つはしらせる」を実行していました。
とあるプロジェクトで、オンラインの画面を作成するとします。
工程としては設計フェーズにはいったばかりで、ようやく設計書の１つ目が８割完成したところ、開発開始が２か月後、だとします。
そのＰＭは、あるメンバーを読んでこう言います。
「明日からこの設計書で実際のシステム開発をお願いします。
ちなみに、コーディング規約と実装の標準書はここにあるけど、別プロジェクトで使ってたものだから、使用して問題があったらメモして報告をあげてください」
その人が１つ目の開発を終わるころには、標準書も赤ペンがはいって修正されたし、さらには参考にと展開することができる、サンプルまで準備できました。
実際に複数のメンバーが開発にハイツタイミングには、標準書と実際にそれに合致した、参考となるプログラムができていたのです。
大規模なプロジェクトなら、全く違うパターンのプログラムを数本つくることもありますが、ようするに何かをやるときに同じことなら同時並行するのではなく、先行してやってしまう、ということです。
実際につくらないと標準なんかつくれないから、標準チームが簡単なサンプル検証しながら標準作成、ではありません。
実際のモノを作成して、そのものをサンプルとして展開します。
違いは本物かどうか、ということです。
本物であれば、実際のプロジェクトの成果物としては無駄にはならない、つまり標準化作業で消費した作業時間はムダにならないし、サンプルレベルならできたことが、実際の複雑なプログラム開発レベルではつかいものにならないことが結構発生します。
プロジェクトは、先読みが重要なのですが、実際にやってみないとわからないことが多々ありま。
標準化は、先行開発で行え！
それが、できるプロジェクトマネージャーがいつもやっていることでした。
最後までお読みくださり、ありがとうございました。
システム開発のプロジェクトをご担当される場合に、すこしでも参考にしていただけたら、嬉しく思います。
