己をよく知らぬ者は自己変革などできない。ごく当たり前のことだが、なぜかIT部門が「標準化」という自己変革に取り組もうとする時、それを忘れて失敗する。今回は、典型的な失敗事例とその巻き返し策を通して、標準化における現状把握の重要性について述べたい。
鎌田 肇、山本 真
予算の確保も厳しい現状では、標準化の取り組みを計画性なく進めるケースは少ない。目的と対象業務を明示し、それに沿った標準の策定を進めている。コスト削減や業務効率化の観点から導入計画自体が否定されることは少なく、予算とのバランスを意識して作業を進めることになる。しかし、なぜか計画が頓挫するケースが多いのも事実である。
原因はどこにあるのだろうか。少し長くなるが、典型的なA社の事例を紹介しつつ、ポイントを説明していきたい。
開発チームだけで標準化を推進
大手製造業であるA社のIT部門は、協力会社にシステム開発を委託するだけでなく、自社で内製もしていた。社内で開発手法は統一されておらず、開発担当者によって品質、必要工数、納期がバラバラだった。そこで、統一された開発プロセスや品質評価の構築を目的として、開発標準を導入することになった。
社内の承認も得て、標準化プロジェクトの計画立案、予算の確保、担当者のアサインなど、着々と準備を進めていった。また、参考にする標準規程も知名度の高いものを選定した。ここまで作業を進めれば、次は参考とする標準規程と現状の社内業務とのフィット・ギャップ分析となる。
ちなみに、ここまでの作業は、文字通り“開発標準”という言葉に従ってIT部門内の「開発チーム」が主体となり進めていた。A社のIT部門は設計（要件定義／概要設計）、開発（詳細設計／コーディング／テスト）、運用（移行／保守）という3つのチームに大別されており、さらに各チーム内で業務アプリケーション別にグループが分かれていた。このうち、「開発チーム」が主体となり標準化を進めたことが、のちに大きな悪影響をもたらした。
開発工程の標準化だけでは効果が限定的
A社の場合、開発チームだけで標準化を実施しようとしていたため、参考標準規程とのフィット・ギャップ分析では開発チーム内で行っている業務を対象とすることになった。そして、いざ開発チームの業務と照らし合わせてみると、標準規程の中で使える項目が3分の1に減ってしまった。
プログラム開発などに関係する技術的要素については開発チームの業務に該当する。一方、システム構築全体にかかわる業務プロセスの要素や、システム構築の効果測定を主体とした項目については、別のチームである設計チームや運用チームが行っている業務だった。これが、最初につまずいた課題である。
開発標準を定義しようとする場合、詳細設計書の作成やコーディング、テストなどの業務に目を向けがちだが、その場合の効果については限定的となるケースが多い。理由は、知名度が高く理想的な開発標準では、要件定義業務から運用業務まで、システム構築全体としての流れを対象としている場合が一般的だからだ。開発業務と相互に影響を及ぼす業務全体の標準化を実現することで、はじめて高い導入効果が見込める。A社では知名度の高い標準規程を参考にすることで多大な成果を期待していたが、そもそも参考にした開発標準の“思想”とA社での推進体制にギャップがあった。
