良い標準規定を作成しても、現場の開発者がその必要性や効果に納得できなければ、従来の慣れた開発方法を守り続けるに違いない。標準化の取り組みにおいて、この「納得感」の醸成は極めて重要だ。しかし、標準化担当者たちの目は「どういう標準規定にするか?」という点にばかり向けられている。典型的な失敗パターンである。

クニエ 戦略サポートグループ
鎌田 肇、山本 真

 皆さんは、標準化の取り組みにおける「成功」とは、どんな状態を示すとお考えだろうか。それは標準規程を整備することではないし、成果物フォーマットの品質を向上させることでもない。これらの整備はあくまで標準化の過程で取り組むことであって、整備自体を目的としてはいけない。

 しかし、標準化プロジェクトを立ち上げるという企業に話をうかがうと、「何の規程を整備すればよいのか」「同業他社ではどういったプロセスで業務を行っているのか」「参考となる方法論はないか」、ひいては「サンプルを持ってきてくれないか」というように、標準化による「成果物の内容」に焦点を絞って検討しているケースが非常に多い。こうした傾向は「失敗する標準化」の一因となる(図1)。

図1●標準化に失敗する6つの理由
図1●標準化に失敗する6つの理由

 標準化の内容を適切に検討すべきなのは間違いなく、そこに起因する問題により失敗した標準化の事例について、これまで解説してきた。

 だが、標準化の内容と同じくらい大切なのは「取り組みの進め方」だ。いくら良い開発標準を作成しても、開発標準を利用する目的や効果が開発現場に伝わっていなければ、開発者は従来の慣れた方法で開発を進めるだろう。

 今回は、適切なIT標準化成果物を作成しかけていたにもかかわらず、標準化の参考とする方法論に気をとられ、展開に苦しんだ事例を紹介したい。この事例では、CMMIを参考に自社の開発プロセスの標準化に取り組んだところまではうまくいっていた。だが、社員の「納得感」の醸成に苦労した結果、標準化の展開までに想定以上の時間がかかってしまった。

開発ノウハウを全社で共有できない

 情報サービス業T社は、様々な業種に対してシステム開発サービスを提供する企業だ。公共系、製造・流通系、金融系など、顧客企業の業種別に事業部を組織して開発業務を行っており、それぞれの事業部にて開発標準プロセスと成果物が定義され、運用されていた。

 「顧客企業の業種別に開発標準が最適化されている」と言えば聞こえはよいが、あくまで個別に開発標準を用意した結果である。各事業部で標準成果物とされるテンプレート、例えばプロジェクトの作業構成を示すWBS(Work Breakdown Structure)一つを見ても、その書き方や記載するタスクの粒度が事業部ごとに異なっていた。T社は、事業部をまたいで異動した社員が開発方法の差異に戸惑う状況を「課題」と認識していたが、これまでそうした異動が少なかったため、特別に対策を打つわけでもなかった。

 しかし、社内で事例共有会などを開催すると、問題が鮮明になった。業種は違えども、同様のシステム開発をするのに社内の知見を利用しづらかった。そもそも他事業部の開発方法が分かりにくいからだ。開発ノウハウを全社で共有できない状況に危機感をおぼえたT社は、ようやく腰を上げた。会社全体での生産性向上を目的に、全社標準となる開発標準モデルを策定することにした。