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

6.1. 標準化の失敗

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

 開発プロセスの標準化は、失敗を繰り返してきた歴史を持つ。一時的に成功した企業もあるが、時間の経過とともに形骸化することを避けられない。まず、ありがちな標準化の失敗例を挙げてみよう。

 

  • アーキテクチャや開発言語が進化したために、標準化が適用できない
  • プロジェクトの体制が変わった途端に利用できない
  • 過去の習慣にとらわれすぎて変化を許容できない
  • 無駄で無意味な作業が増えた
  • そもそもプロジェクトが標準化を順守していない

 

 アーキテクチャや開発言語・開発方法論の変化に対応したり、利用価値のない中間成果物を減らしたりするためには、プロジェクトが終了した後の事後検証を行い、プロセスの改善に結びつけていく必要がある。標準は一度作って永久に利用できるものではない。

 

 プロジェクトの体制変化に対応できない問題は、体制図は作ったものの、その役割・責任・権限の範囲があいまいである場合が多い。また、プロジェクトできちんとしたWBS(Work Breakdown Structure)を作成していたとしたら、個々の作業タスクにリソースの割り当てを付け替えるだけで、誰がその作業を行うかを決定できるはずである。

 

 一番の問題は、「過去の習慣にとらわれすぎ」「無駄な作業が増えた」ことである。技術者がこのような印象を持つ場合、その技術者は計画せず、場当たり的に作業を行い、それでどうにか動くシステムを開発できたのであろう。この標準化が何を達成するために必要なものかを、プロジェクトメンバに徹底させる必要がある。プロジェクトメンバに徹底させることこそが、標準化を適用するときに一番難しい問題となる。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

6.1. 標準化の失敗 ハッピィ・エンジニアリング関連ページ

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

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