このエントリーをはてなブックマークに追加LINEで送る

6.3. 標準化適用時の問題

ハッピィ・エンジニアリング表紙

 標準化策定後には、実際のプロジェクトに適用していくことになる。ここでの問題は、そもそも標準化の目的が徹底されていないことに起因する場合が多い。ありがちな問題は、以下の2点に絞られるだろう。

 

  • 標準化が実際のプロジェクトに合わない
  • 標準化を順守するのが困難

 

標準化が実際のプロジェクトに合わない

 「標準」を自分が関わるプロジェクトに「適用」することをせず、「標準」そのものがプロジェクトに合わないと言っている場合が多い。「標準」はあくまでも「標準」であり、そこに「万能」という意味は含まれていないことを認識すべきである。「ひとつとして同じプロジェクトはない」以上、標準がそのまま形を変えずに適用できるはずがない。

 

 ただし、「この標準は、今回のプロジェクトには合わない」という言い訳が免罪符として使用されることは少なくない。一般的に見て、標準化に準拠していない、いいかげんなプロジェクトは、標準化を徹底したプロジェクトと比較して、作成するドキュメントの内容が薄い傾向にある。工程が下流に進めば進むほど、技術者はドキュメント作成を嫌がり、いやいやながらにやっつけ仕事で行っていることを考えると、少しでもドキュメントの作成を少なくする方向に意識が向かいがちである。*1

 

 「標準が適用できない」という免罪符を否定しつつも、むやみに感情的な標準化反対論を発生させないためには、あらかじめ標準化と現実とのギャップを埋める手段を講じておく必要がある。例えば、標準化そのものは、大規模で難易度の高いプロジェクト向けにやや冗長に策定しておき、実際のプロジェクトでは、十分に検討したうえで、「このプロジェクトに適用しない項目を明示的に外す」のである。この作業をプロジェクト計画時に利害関係者合意の下で行うことで、標準化を形骸化させず順守するのが可能になる。また、このようにしたうえで、順守状況を見ると、SIベンダや開発会社のこれまでの仕事の進め方やスキルレベルを認識できるという副次的な効果もある。

 

 その一方で、時間の経過とともに作り上げた「標準」が古びてしまうことがある。アーキテクチャや基盤技術の変化、開発方法論の変化、ビジネスモデルの変化など、適用が難しくなる要因はさまざまである。

 

標準化を順守するのが困難

 大規模な開発プロジェクトでは、システム監査が入ったり、システム品質管理部門がプロジェクトの監査を行ったりするなど、かなり厳格な標準化順守のチェックが行われる。さらに、一部のユーザ企業では、ITガバナンスを確立するために、システム部門に元SEや熟練SEを在籍させることが増えつつある。そのため、過去と比較して、納品物の検査が厳しくなる傾向にある。

 

 しかし、中小規模のプロジェクトでは、標準化の順守は非常に難しい。標準化プロセスを順守しているかを監査しながらプロジェクトを進めていくのは困難である。また往々にして、プロセスが進むにつれてプロジェクトチームは標準化から外れていってしまう。

 

 さらに、皮肉な話だが、取引先のSIベンダを「信頼している」ユーザ企業ほど「成果物品質」への要求水準が甘くなり、いいかげんな設計ドキュメントが横行しがちである。

 

 これに歯止めをかけるには、マネジメントプロセスまで含めた標準化が必要なのである。

 


*1 結果的には、正確なドキュメントをきちんと作成しておくほうが、バグの修正に必要な時間を減らすことができるのだが、どうしてもプログラマは目先のことしか見ない傾向が強い。
シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

6.3. 標準化適用時の問題 ハッピィ・エンジニアリング関連ページ

6.1. 標準化の失敗
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
6.2. 標準化策定時における問題
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
6.4. 標準化のあるべき姿
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
6.5. プロジェクトにおける標準化の利用
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
6.6. 標準化の維持
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング