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

6.2. 標準化策定時における問題

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

 標準化活動が失敗する要素は、以下の2点に絞られる。

 

  • 標準化を策定すること自体が失敗する場合
  • 標準化を実際のプロジェクトに適用する場合の失敗

 

 本節では、標準化策定の失敗の原因について記述する。

 

  • 体制の問題
  • 想定の明確化不足
  • 管理面の考慮不備
  • 合理性の欠如

 

体制の問題

 標準化策定を行ううえで一番難しい問題は、「誰が標準化を策定するか?」である。標準化の策定には、開発プロセスの知識、マネジメントプロセスの知識、プロジェクトの実施経験、アプリケーションやシステム基盤の実現方式に関する知識など、非常に多くのスキルが要求される。

 

 スキルの高いメンバは、非常に忙しい存在であり、これだけ幅広いスキルを持つメンバを標準化策定作業に専任者としてアサインするのは非常に困難である。ある程度は現業と並行して作業を行うことが可能だが、現業に追われる時間が長く続くことで、作業が停滞し、いつしか標準化策定の作業が「存在しなかったもの」となってしまうこともある。

 

想定の明確化不足

 標準化されたプロセスが適用しにくい理由として、標準化プロセスの想定が明確ではないことが挙げられる。想定が不明確なものを実際のプロジェクトに適用するのは困難である。

 

 想定の配慮不足のありがちな例としては、標準化されたプロセスが新規開発に照準を合わせたものになっていることが挙げられる。現在のシステム開発では、二次開発や保守と呼ばれるような、すでに動いているシステムの改修作業のほうが、新規の開発案件よりもはるかに多い。しかし、新規開発と二次開発(保守)の工程はすべてが同一ではないのである。

 

 新規システムでは、基盤設計・基盤構築・運用設計などの工程が含まれる。これらは保守において行われることが少ない工程である。逆に保守の場合は、ドキュメントやソースコードの調達、既存システムの構成を調査するなどの、新規システムにはない工程が含まれるのである。

 

 さらに、エンジニアリングプロセスに関しては十分に標準化している場合であっても、標準化の恩恵を受けられていないことが多い。このようなときには、たいてい、マネジメントプロセスを標準化していないことが問題である。プロジェクトを的確にコントロールしていくためには、マネジメントプロセスの標準化が必要不可欠である。

 

管理面の考慮不備

 標準化してみたけれど、その恩恵が可視化できない、という問題もよく話題に上がる。
 標準化を検討するうえで重要なことのひとつが、標準化を適用した場合の利点である。「品質が高まる」「進捗が可視化できる」「リスクを早期に想定できる」など、標準化の目的を明確にする必要がある。しかも、これらの目的を設定した場合、効果を期待するには開発プロセスのみの標準化では不十分である。「変更管理」「品質管理」「進捗管理」「リスク管理」などのプロセスを標準化して初めて、プロジェクトが標準化の恩恵を受けることが可能になるのである。

 

 前述したとおり、標準化の対象範囲は開発プロセスだけにとどめず、マネジメントプロセスまでを対象とすべきである。

 

合理性の欠如

 標準化を策定するメリットのひとつは、生産性の向上である。作業プロセスが明示されることで、作業者が「やるべきことは何か?」を考える必要がなくなり、行うべき作業に集中できるようになる。

 

 しかし、生産性を向上させるためには、作業プロセスの明示だけでは配慮不足といえよう。ドキュメントの構成が十分に検討されていなければ、生産性が低下する。例えば、ドキュメントに一貫性がなく、1カ所にまとめるべき情報が複数のドキュメントに分割されたり、同じ内容が複数のドキュメントに重複して記載されたりする場合がある。変更の多いシステム開発のプロジェクトにおいて、このようなドキュメント構成の不備は、生産性と品質を大きく低下させる。

 

成果物を定義する上では、作業プロセスのほかに、変更の発生をふまえて、作業が最終成果物に直結する構成になるように十分に検討すべきである。標準化を策定する際には、実際にどんな具合に作業が組み上がっていくかという観点で十分にレビューし、無駄な作業が増加しないような配慮が必要となる。

 

コラム:中間成果物

 

 生産性という観点で標準化を考えた場合、中間成果物が乱造されていないか、という点で標準化を見直す必要がある。本来は最終成果物にまとめるべきものが、ドキュメント構成に問題があり中間成果物の乱造につながっている場合が非常に多い。このような中間成果物は否定されるべきである。

 

 しかし、いかに入念に標準化を策定したとしても、最終成果物に直結しない中間成果物を作成する必要がある。なぜならば、技術者がプログラミングに必要なドキュメントの多くは、エンドユーザには理解できないという問題があるからである。対象システムをユーザに理解してもらうには、「ユーザが理解可能なドキュメント」を作成する必要性が出てくる。多くの中間成果物は、ユーザ〜SIベンダ間で、あるいは技術者間のコミュニケーションと合意形成のために必要不可欠である。

 

 中間成果物の多用、特に恣意的なイメージや図表の氾濫は明らかに問題だが、それをむやみに制約した場合、現在の開発現場では大きなコミュニケーションギャップが発生しかねない。

 

 つまり、標準化においては、「否定的に扱われる中間成果物」は最終成果物にまとめるべき内容のものであり、「コミュニケーション上必要な中間成果物」と混同しないように注意しなければならない。

 

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

6.2. 標準化策定時における問題 ハッピィ・エンジニアリング関連ページ

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

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