失敗する標準化,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20091225/342674/,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　業務プロセスの「標準化」は、プロセスの品質を高め、より良い成果を安定して生み出すために必要とされている。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,だが、標準化に取り組んだ多くの事例が失敗に終わっている。かえってプロセスが非効率になってしまう例さえある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,窮屈なばかりで効果が薄い標準化はもういらない。「失敗する標準化」の原因を明らかにするとともに、成功への道,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,筋を提言したい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■目次,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,1,窮屈で効果薄の標準化はもういらない,,,,,,,,,,,,,,2010/01/13,,,,,,,,,,,,,,,,,,,,, ,2,業務を把握できていない組織が陥る罠,,,,,,,,,,,,,,2010/01/26,,,,,,,,,,,,,,,,,,,,, ,3,「過去の成功」は過去のものでしかない,,,,,,,,,,,,,,2010/02/9,,,,,,,,,,,,,,,,,,,,, ,4,ときには、属人化だって悪くない,,,,,,,,,,,,,,2010/02/23,,,,,,,,,,,,,,,,,,,,, ,5,関連部門の「反感」を買う標準化,,,,,,,,,,,,,,2010/03/09,,,,,,,,,,,,,,,,,,,,, ,6,「納得感」なければ誰も標準を使わない,,,,,,,,,,,,,,2010/03/30,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　窮屈で効果薄の標準化はもういらない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,戻る,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100205/344256/?P=5,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　業務プロセスの「標準化」は、プロセスの品質を高め、より良い成果を安定して生み出すために必要とされている。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,だが、標準化に取り組んだ多くの事例が失敗に終わっている。かえってプロセスが非効率になってしまう例さえある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,窮屈なばかりで効果が薄い標準化はもういらない。「失敗する標準化」の原因を明らかにするとともに、成功への道,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,筋を提言したい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準化は、なぜ失敗してしまうのだろうか―。昔から標準化の取り組みは盛んだが、どういうわけか同じような,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,失敗を繰り返している。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　最近のIT業界には標準化への取り組みに効果を発揮する様々な方法論が存在している（図１）。変化に強いIT,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,のあり方を定義する「EA」、ITガバナンスの確立や内部統制の整備を支援する「COBIT」、開発組織に継続的な改,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,善を促す「CMMI」、そしてIT運用におけるノウハウを集約した「ITIL」など、上流から下流まで標準化の推進に役立,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,つ方法論は一通りそろっている。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図１●標準化の推進に役立つ方法論,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　しかしながら、標準化への取り組みに失敗した事例は後を絶たない。「CMMIを参考にして開発プロセスの生産,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,性向上に取り組んだが、ミーティングと作成文書が増えて、逆に生産性が下がってしまった」とか、「運用人員削,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,減を目的にITILで運用業務を見直したら、今まで実施していなかった業務を追加することにより、結果として人員,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,を増加する必要が出てきた」といった話を、みなさんもよく耳にするだろう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　これらの失敗例は、まだ目的が明確なだけに救いようがある。目も当てられないのは、取り組みが中途半端な,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ケースだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　こんな例がある。「誰もが同じ品質のアウトプットを残せるように、運用業務手順を標準化しようとした。だが、標,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,準的な手順の定義が難しく、品質目標も設定しないまま、必要最低限の手順だけを標準化した。その結果、以前,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,より品質が低下し、トラブル対応が増えてしまった」という。まさか、と思われるかもしれないが、このような失敗例,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,は決して珍しくない。これが標準化の実情である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　窮屈で効果薄の標準化はもういらない （2/5） ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20091225/342687/?P=2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■標準化の失敗例から浮かび上がる6つのパターン,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　「標準化」とは、もともと自分たちが行っている業務を誰もが行えるようにして、業務の品質を保つための活動で,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ある。いま実行していることを広く展開するだけなので、標準化したい業務の内容が分からずに失敗することは少,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ないはず。それなのに、なぜ失敗してしまうのだろうか。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そこには、次のような6つの要因がある（図２）。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図２●標準化に失敗する6つの理由,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　本連載ではこれら6つの失敗要因について、それがどのような状況で生まれるのか、どのように対処することで,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,失敗を減らせるのかを、事例を示しながら解説していく。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　第1回は、開発プロセスの標準化に取り組みつつも、（１）自社内に存在しない知識やノウハウを前提に標準化,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,を進めた結果、標準化に失敗してしまった企業の事例を紹介したい。この事例ではCMMIやCOBIT for SOXを標,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,準化の前提としていたが、これら方法論の使い方について理解が足りず、「あるべき姿」を教科書的に追及してし,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,まった。その結果、できあがった標準プロセスは現場にとって窮屈すぎるものとなってしまった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　「教科書的に追及してはいけないことくらい知っているよ」という声も聞こえてきそうだが、以下の事例を見れば、,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,CMMIやCOBITなどの方法論が持つ”魔力”に、少しずつ引き込まれていった経緯が分かる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■「最善」を求めた開発標準プロセスがあえなく形骸化,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　2年前、大手製造業U社は内部統制の対応を進めていた。その際、IT全般統制（IT部門の業務プロセス全般に,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,かかわる内部統制）に関して監査法人から指摘事項があったのを契機に、U社IT本部は開発標準プロセスの再,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,定義に着手した。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　当時の開発標準プロセスは、同社が以前取り組んだ「物流業務再構築プロジェクト」の成果物を中心に、これま,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,でに行ってきた開発標準の暗黙知を形式知化したものだ。開発プロセスや各開発プロセスの成果物は、U社の独,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,自の切り口で定義されていた。過去にこの開発標準プロセスを基に大規模開発プロジェクトを成功させた経験が,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,あり、IT本部のB本部長はこれまでのシステム開発品質にさほど不満を持っていなかった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　だがIT全般統制での指摘事項に対処するには、開発標準プロセスの修正が必要だ。さらなる品質向上を目指,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,すべく、今までの開発標準プロセスの見直しを決意した。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　窮屈で効果薄の標準化はもういらない （3/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20091225/342687/?P=3,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■新しい標準プロセスの策定作業までは順調だった,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　開発標準プロセスの再定義に向けて、B本部長は部内にプロジェクト・チームを立ち上げた。開発プロセスを横,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,断的に検証できるよう、IT本部の各部門からそれぞれメンバーを選出した。このプロジェクトの目的は、IT全般統,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,制における指摘事項への対応と、開発標準プロセスの適性化である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　早速プロジェクト・チームは現行の開発標準プロセスが抱える課題を調査し始めた。まず、開発標準プロセスと,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,して必要な要件を満たしているのかを調べるために、ソフトウェア開発組織の能力を示す指標として有名なCMMI,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,を活用することにした。開発標準プロセスで定義されている要件を「プロセス管理」「プロジェクト管理」「エンジニア,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,リング」「支援」というCMMIの4区分に整理し、必要なプロセスが網羅されているのかを、くまなく点検した。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　加えて、IT全般統制の指摘事項を改善するために、IT全般統制関連の参考資料を探した。だが当時、日本国内,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,には参考にできる資料がまだ存在しなかった。このため、米国で利用されている「COBIT for SOX」を基に開発プ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ロセス上のリスクと要件を抽出することにした。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　こうして開発標準プロセスを点検した結果、CMMIやIT全般統制の観点から、たくさんの課題が見えてきた。例え,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ば現状のシステム保守体制は、アプリケーションの開発者が引き続き保守も担当することが多かった。該当アプ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,リケーションのシステム環境を最も理解しているのは、その開発者であると考えたからだ。しかし、内部統制の「職,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,務分離」の考え方に従えば、開発者と保守担当者を分けることを検討しなければならなかった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■あまりの面倒さに”簡略化した手続き”が一般化,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　それまで現行システムの品質に一定の満足を得ていたB本部長は、予想を上回る課題の多さに驚いた。体制,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,面や手続き面の不備が見つかった事への対応は当然として、「CMMIにきちんと対応した開発標準プロセスを作,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,成しなければならない」と判断した。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　再定義された新たな開発標準プロセスは、無事にIT全般統制での指摘事項を解決して現場に適用されることに,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,なった。改編のポイントは、承認手続きの強化と開発体制の強化である。プロジェクト・メンバーおよび関係者一,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,人一人の役割と責任を明確にしたことで、今までより安定したプロジェクト推進が可能になり、品質が向上するも,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,のと期待された。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　だが、新しい開発標準プロセスを適用したプロジェクトが増えるにつれ、現場から不満の声が聞こえるようになっ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,てきた。例えば、開発作業を外部の協力会社に依頼している場合に不都合が生じた。以前は、プログラミングと,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,単体テストを協力会社で実施し、そのテスト結果をIT本部の担当者が受け取ることで完了としていた。だが新しい,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,開発標準プロセスでは、責任者による承認手続きが追加された。責任者が承認するためのミーティングが急に増,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,えて、関係者のスケジュール調整が難しくなっていた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IT本部が主観となる開発プロジェクトではまだよかったが、事業部門が主観となる開発プロジェクトではもっと大,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,きな影響が出た。事業部門本来の業務が忙しい時期には、承認作業に手間取り、スケジュールの遅延につなが,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ってしまったのだ。プロジェクトマネジャはこうした現状に対処すべく、開発標準プロセスとは異なる”簡略化した手,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,続き”で承認手続きを進めた。これが一般化し、新しい開発標準プロセスはあっけなく形骸化してしまい、IT全般,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,統制の実効性が失われてしまった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　窮屈で効果薄の標準化はもういらない （4/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20091225/342687/?P=4,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■そもそも方法論の適用方法に無理があった,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　一般に、現行の業務プロセスに対して標準的な方法論を参考に改善するケースは多い。U社の事例では、内部,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,統制をきっかけにCMMIやCOBIT for SOXなどの方法論を参考に開発標準プロセスを再定義した。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　まず1つ目の問題点として、U社は方法論に記載された標準的な要求事項に目を奪われてしまったようだ。「実,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,際の開発業務で、負荷がどれだけ増減するのか」という考慮が足りなかった。標準化の目的が「方法論の導入そ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,のもの」にすり替わってしまったケースでは、よく見られる現象である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　多くの方法論は、「あるべき姿」を示すための要求事項を示している。ただし、それらが実施手順を示しているわ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,けではないことに注意が必要である。方法論には、「～を行うべき」や「～を実現していること」と記載されてはい,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,るが、「一連の業務を～の順番で行うべき」とは記載されていない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　U社の場合、CMMIやCOBIT for SOXの観点から、標準プロセスに組み込むべき「承認手続き」や「成果物」を洗,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,い出すところまでは正しかった。問題は、これらを既存の標準プロセスに組み込む段階で「一連の業務をどのよう,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,に組み立てるか」を十分に検討しなかったことにある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■静的要件と動的要件を混同しない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　方法論をベースに標準化を進める場合は、「静的要件」と「動的要件」を念頭に置いて検討するのが定石だ（図,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,３）。「静的要件」とは、標準化に必要な要件を抽象的に表現したものと考えてほしい。方法論自体は「静的要件を,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,まとめたテンプレート」に過ぎない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図３●静的要件と動的要件を混同してはいけない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,方法論を用いた一般的な標準化の流れは、まず現在の業務フローと方法論を基に、標準化の要件（静的要件,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,）を定義する。次に、この静的要件を現場の実情に合わせて「動的要件」に変換する。ここがポイントだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　方法論はテンプレートなので、そこに記されたすべての静的要件を自社で実装する必要はない。ただ、自社に,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,取り込むと決めた静的要件は、現場の実情に合わせて「動的要件」に変換する必要がある。結果的に、静的要件,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,を標準プロセスの一部として単純に組み込める場合もあるが、多くの現場ではそう簡単にはいかない。U社の事,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,例が示すとおりだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　U社のB本部長らは、自社の開発標準プロセスをCMMIの視点で比べた結果、予想外に多くの課題があることに,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,驚いた。自社開発標準プロセスに対する自信が揺らぎ、「CMMIにきちんと対応すべきだ」という思いが非常に強く,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,なったのかもしれない。これが進むべき方向を狂わせたのではないだろうか。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　U社は既存の開発標準プロセスを策定する際、開発業務の暗黙知を形式知化し、独自の開発プロセスや成果,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,物を定義している。つまり、現場の業務に即した標準プロセスを作り上げる力を持っている。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　だがなぜか、既存の方法論を前にすると、その体系化された知識・ノウハウに圧倒されてしまいやすい。U社を,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,はじめ多くの企業が、静的要件を自社に合わせてカスタマイズすることに消極的になってしまいがちだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　「標準化」という言葉からは、業務プロセスもそこで行う業務内容も「標準的な仕様を採用する」ようなイメージが,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,浮かんでくるかもしれない。だが、業務プロセスは企業ごとに異なる。方法論通りに標準化できない場合や、方法,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,論に記載されたすべての要求事項を満たさない場合などで不安を感じることもあるだろうが、「過ぎたるは及ばざ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,るが如し」である。自社にとって必要とされている要求事項と業務プロセスを、現場の視点でまとめていくことが標,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,準化のポイントだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　窮屈で効果薄の標準化はもういらない （5/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20091225/342687/?P=5,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■もう1つの失敗原因「仏作って魂入れず」,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そしてU社の事例に内在するもう1つの問題は、作成した標準に”魂を込める”という取り組みが欠如していたこ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,とだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　どんなに立派な標準プロセスを定義したとしても、「はい、どうぞ」と現場に渡すだけで定着すれば苦労はない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,むしろ、「新しいもの」はいつでも敬遠されがちだ。その壁を乗り越えるための工夫や活動が必要だと誰もが知っ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ているが、実際にどう進めればいいのか戸惑うケースも多い。仏（標準）を作っても、魂が入らず（定着せず）、形,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,骸化してしまうケースは非常に多い。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　”魂を入れる（定着させる）”ためのポイントは、現場主導で標準化を進めること。ここでは、「標準が完成してから,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,定着化を始める」のではなく、「標準化プロジェクトを始めるときから定着化への取り組みが始まっている」という点,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,に注目してほしい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準化の計画段階では、現場から標準化を企画するメンバーを集め、自分たちのための標準化であることを十,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,分に周知しよう。標準の策定段階では、実際に標準プロセスに則った業務を行うものとして、現場で運用可能なレ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ベルの要求事項と業務プロセスを検討する。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準の運用段階では、標準化策定メンバーを中心に「定着化活動」を行う。実際に策定にかかわったメンバー,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,だからこそ、愛着と主体性を持って標準化の必要性を社内に説明できる。そして新標準を評価する段階では、新,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,たな標準仕様に則って業務活動が行われているかどうかをモニタリングし、定期的に改善していく。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準化とは、束縛ではなく、より主体性を持って業務を行うための活動であることを忘れてはいけない。目標の,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,実現に向けて、標準化の内容を適正化する活動を常に念頭に置いてほしい。U社のケースでは、社内から標準,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,化を策定するメンバーを募ったところまでは良かったが、定着化に向けた支援が不足していた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　「内部統制元年」となった2008年度は終わり、標準プロセスをIT全般統制に対応させた会社も少なくないだろう。果,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,たして、あなたの会社の開発標準は”魂の入った標準”として、形骸化せずに運用されているだろうか。この機会にぜ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,ひ確認してみてほしい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　実際に運用されていない標準プロセスには露ほどの価値もない。むしろ、トラブルの温床になることさえある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　業務を把握できていない組織が陥る罠,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,戻る,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20091225/342688/?itp_leaf_backno,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　己をよく知らぬものは自己変革などできない。ごく当たり前のことだが、なぜかIT部門が「標準化」という自己変革に,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,取り組もうとするとき、それを忘れて失敗する。今回は、典型的な失敗事例とその巻き返し策を通して、標準化にお,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,ける現状把握の重要性について述べたい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　予算の確保も厳しい現状では、標準化の取り組みを計画性なく進めるケースは少ない。目的と対象業務を明示,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,し、それに沿った標準の策定を進めている。コスト削減や業務効率化の観点から導入計画自体が否定されること,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,は少なく、予算とのバランスを意識して作業を進めることになる。しかし、なぜか計画がとん挫するケースが多い,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,のも事実である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　原因はどこにあるのだろうか。少し長くなるが、典型的なA社の事例を紹介しつつ、ポイントを説明していきたい,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■開発チームだけで標準化を推進,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　大手製造業であるA社のIT部門は、協力会社にシステム開発を委託するだけでなく、自社でも内製もしていた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,社内で開発手法は統一されておらず、開発担当者によって品質、必要工数、納期がバラバラだった。そこで、統,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,一された開発プロセスや品質評価の構築を目的として、開発標準を導入することになった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　社内の承認も得て、標準化プロジェクトの計画立案、予算の確保、担当者のアサインなど、着々と準備を進めて,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,いった。また、参考にする標準規程も知名度の高いものを選定した。ここまで作業を進めれば、次は参考とする,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,標準規程と現状の社内業務とのフィット・ギャップ分析となる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ちなみに、ここまでの作業は、文字通り”開発標準”という言葉に従ってIT部門内の「開発チーム」が主体となり,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,進めていた。A社のIT部門は設計（要件定義/概要設計）、開発（詳細設計/コーディング/テスト）、運用（移行/保,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,守）という3つのチームに大別されており、さらに各チーム内で業務アプリケーション別にグループが分かれていた,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。このうち、「開発チーム」が主体となり標準化を進めたことが、のちに大きな悪影響をもたらした。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■開発工程の標準化だけでは効果が限定的,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　A社の場合、開発チームだけで標準化を実施しようとしていたため、参考標準規程とのフィット・ギャップ分析で,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,は開発チーム内で行っている業務を対象とすることになった。そして、いざ開発チームの業務と照らし合わせてみ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ると、標準規程の中で使える項目が3分の1に減ってしまった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　プログラム開発などに関係する技術的要素については開発チームの業務に該当する。一方、システム構築全,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,体にかかわる業務プロセスの要素や、システム構築の効果測定を主体とした項目については、別のチームであ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,る設計チームや運用チームが行っている業務だった。これが、最初につまずいた課題である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　開発標準を定義しようとする場合、詳細設計書の作成やコーディング、テストなどの業務に目を向けがちだが、,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,その場合の効果については限定的となるケースが多い。理由は、知名度が高く理想的な開発標準では、要件定,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,義業務から運用業務まで、システム構築全体としての流れを対象としている場合が一般的だからだ。開発業務と,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,相互に影響を及ぼす業務全体の標準化を実現することで、はじめて高い導入効果が見込める。A社では知名度,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,の高い標準規程を参考にすることで多大な成果を期待していたが、そもそも参考にした開発標準の”思想”とA社,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,での推進体制にギャップがあった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　業務を把握できていない組織が陥る罠（2/5） ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20091225/342688/?P=2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■身動きがとれなくなり、頓挫・・・,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　とはいえ、参考標準規程の対象項目が少なくなっても部分的な効果は期待できる。このため、A社では引き続き,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,前向きな姿勢で標準化プロジェクトを進めていった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　だが、今度は身動きが取れなくなる壁が待っていた。同じタスクなのに、業務アプリケーションの担当グループ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,によって、設計チームや運用チームとの業務分担がそれぞれ異なっていることが判明したのだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　一例をあげると、概要設計は設計チームで行い、詳細設計を開発チームで行うグループもあれば、詳細設計ま,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,で設計チームに任せているグループもあった。また、単体テストを開発チームで行うグループもあれば、運用チー,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ムで行っているグループもあった（図１）。これはルールが部分的にしか決められていなかったこと、また、ルール,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,が決められていても、それを守らないグループが存在したことなどが要因であった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図１●設計/開発/運用の役割分担がアプリケーションごとに異なっていた,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　本来なら、設計チームや運用チームを巻き込んで標準化を進めなければならない局面だが、A社の標準化プロ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ジェクトはそこに踏み出せなかった。それはなぜか。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　実は標準化を推進する際には併せて考えなくてはならないことがある。それは業務の「責任と役割」である。他,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,チームの業務に介入して標準化を行うことは、そのチームの責任範囲や役割自体を変える可能性があり、IT部門,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,全体やIT部門以外の組織にも影響を及ぼすことになる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ただし、開発チームがそこまで踏み込んで対応しようとすると、関係者の負荷が倍増し、短期的な実現も見込め,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,なくなってしまう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　結果として、標準化対象を大幅に絞り込もうとした。開発チームだけで実現できる範囲、すなわちプログラミング,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,を中心としたほんの一部だけを対象にしようと考えた。しかし、これでは当初想定していた統一化の実現規模や,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,導入負荷に見合うだけの成果が得られなくなってしまう。結局、このプロジェクトは頓挫してしまった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　業務を把握できていない組織が陥る罠（3/5） ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20091225/342688/?P=3,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■己を知ることによってスタートラインに立てる,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　A社の標準化プロジェクトが中止に追い込まれた根本的な原因はどこにあったのだろうか。それは大きく2つに,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,分けられる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　1つは、標準化を導入する際に、自チームで行っている業務の「責任と役割」をしっかり把握していなかったこと,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,である。計画時に把握できていれば、標準化が及ぼす影響を正しく見積もることができ、途中で標準化対象を大,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,幅に絞り込むような事態にはならなかっただろう。これが一番の失敗原因と考える。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　「責任と役割」は、業務プロセスが確立された組織では明確になっているはずだ。業務プロセスが確立されてい,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,る場合、各業務における権限や対象要員、報告管理などにおいて、制約と自由が定義されているからである。そ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,の定義の中で、各組織や担当者の責任と役割が決められていく。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　もしA社に業務プロセスが確立されていたならば、自分たちの業務の中で、誰が何をどこまでの責任と役割によ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,って業務を行っているかが理解でき、さらには強制力や説得性を意識して、現在の業務と標準化の可能性を検討,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,できたであろう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ただし、業務プロセスをきちんと文書で定義し、実行し、見直しを行っている企業・組織は少数派だ。IT業務に関,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,しては特に無頓着になっているケースが多く、実情を踏まえて標準化を進めようとするなら、業務プロセスの確立,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,と標準化をセットで進める必要があるかもしれない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　2つ目の失敗原因は、参考とする開発標準の選択を誤った事である。自分たちができることを意識して標準を選,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ばないと、せっかくのバイブルも宝の持ち腐れになる。そればかりか、できないことを切り捨てることによって、本,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,来目指すべき全体最適の効果が消滅することもある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　A社における開発チームと設計チーム間の業務を振り返ってみよう。設計チームで行う概要設計と開発チーム,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,で行う詳細設計に関係する標準化が実現されれば、両者の間の意思疎通はスムーズになり、生産性や品質を高,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,めることにつながる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ところがA社では、標準化対象の業務範囲に制約を設けた。開発チームだけで標準化を行おうとした場合、概,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,要設計に対する適切な標準化は望めず、設計チームとの連携部分は改善できない。そうであれば、限られた範,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,囲で最大限の効果を得ることを目的に定義されたもの、例えば詳細設計以降の技術標準などを参考にした方が,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,、現状よりも高い効果を得られるはずだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　業務を把握できていない組織が陥る罠（4/5） ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20091225/342688/?P=4,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■失敗は成功の始まり,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ここまで失敗原因を中心に述べてきたが、A社の事例について少し明るい話もしていきたい。標準化プロジェクト,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,が頓挫したとき、担当者はモチベーションが下がっていて、どこから手を付ければプロジェクトを再開できるのか,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,途方にくれていたが、いくつかの巻き返し策により息を吹き返した（図２）。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図２●失敗から立ち直るための巻き返し策,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　担当者は気付いていなかったが、プロジェクト内で今まで検討してきたことは非常に有益であった。例えば現状,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,業務を把握するための作業は、今まで見えていなかった、あるいは見て見ぬふりをしてきた業務上の課題を明ら,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,かにした。関係者の間で課題を共有し、今後の業務統制の足掛かりにもなった,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そこで、プロジェクトを再開するにあたり、把握した現状業務を可視化してみた。業務プロセス・フローを作成し、,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,それをたたき台にして関係者と議論を重ねた。まずは標準化の実現に注力し、適用範囲と業務の変更が可能な,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,領域との相関関係を明確にしていった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　プロセス・フローを作成するにしたがい、一部の業務アプリケーション・グループで既に小規模の標準化を実施,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,していることが判明した。これは当初の現状分析では把握できていなかった。理由は、業務アプリケーション・グ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ループごとに業務内容がバラバラだと判明した後、個別に詳細な業務まで調べる気力を失ってしまったからだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　一部の業務でも標準化しているのであれば、その展開範囲を広げられる。もちろん、そのままの形では無理だ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ったが、展開可能な部分もあった。また、標準化の定義や周知、定着までの方法を参考にすることも可能であっ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,た。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　プロセス・フローの作成により、現状業務を可視化し、有意義な情報共有や現状把握がなされた時点で、プロジ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ェクトの意義と貢献度をIT部門全体に説明。プロジェクトの継続に対する理解を獲得した。途中で投げ出さずに取,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,り組んだことで、プロジェクトの知名度が向上し、開発チーム以外の人たちからもプロジェクト活動への参加申し,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,込みが自発的に生まれた。同じ問題意識を持つ人が案外多いことも分かった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■一攫千金がすべてではない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準化を実現させようとすると、どうしても大きな効果を狙いたくなる。対象範囲を広く設定し、新しく統一された,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,作業方法を短期間で軌道に乗せようとしたくなる。確かに、開発標準を適用する場合にも、設計から運用まで関,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,連する業務を一気通貫で検討した方が効果は大きい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　しかし、今までのやり方を変えるのだから、口で言うほど楽ではない。もし容易に実現できるとすれば、前述した,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ように業務プロセスが確立されていて、業務上の変更に積極的に取り組める組織か、小規模な範囲の改善を目,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,指す場合のいずれかだろう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　A社の場合、開発チームが自分たちで対応できる範囲を想定し、対応に無理のない計画を立てたはずであった,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。ところが自チームの現状と他チームとの関連性を把握していなかったために、目論見と異なる結果となってしま,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ったのだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そこで、プロジェクトの再開に当たっては、良いところ悪いところをすべて含めて現状を把握した後に計画を見直,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,した。一発短期での対応はやはり無理なので、まずは可能な対応から成果を確認しつつ取り組むことになった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,以下は開発チームが再提示したプロジェクト方針の概要である。まず（１）開発チーム内で標準化し、（２）設計チ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ーム/運用チームとの接点にまで範囲を広げ、（３）最終的にIT部門全体で標準を確立する、という3ステップのマ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,スタープランを立てた（図３）。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図３●プロジェクト再開マスタープラン,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　実施スケジュールに関しては、継続性をしっかり保ちながら実施することを重要視し、Step（１）が1年間、Step2（,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,２）がその後の半年間とし、Step（３）に関しては内部統制への対応を含めて実施することにした。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　業務を把握できていない組織が陥る罠（5/5） ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20091225/342688/?P=5,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■自分たちの業務把握がリスクの低減につながる,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　A社の事例では、最終的には業務の現状を根気強く把握したことによって、当初の想定を超えた効果を生み出,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,した。だが、もし最初から現状を理解していたらどうだろうか。実現範囲をあらかじめ想定し、厳しい現状に即した,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,参考標準規程を選択していただろう。また、初期の段階では効果が少なくても、ステップ・バイ・ステップで着実な,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,対応を取ることにより、効果を高められたはずだ。プロジェクトの停滞もなく、スケジュールも予定通り進捗してい,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,たと思われる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ここで、前回紹介した「標準化の失敗例から浮かび上がる6つのパターン」を振り返ってみたい（図４）。A社の事,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,例は、2つ目の「標準化の対象業務に関する現状把握が甘すぎる」という失敗パターンに当てはまることが分かる,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図４●標準化に失敗する6つの理由,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　A社では、作成したプロセス・フローを適時見直して内容をアップデートしている。管理資料ゆえにアップデートを,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,面倒くさがるケースが多いであろう。だがA社では、標準化への取り組みをきっかけに、業務改善に重要な位置づ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,けとなる成果物であることを認識した。また、業務プロセスの構築意義についても身をもって理解するに至った。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　もし現状の業務プロセスを把握していない、または可視化していない場合は、少しずつでもプロセス・フローを作,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,成することを勧めたい。作成初期の段階は面倒であり、持続には根気が必要な作業であるが、標準化の効果的,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,な導入を可能にする以外にも、今後一層求められる業務の効率化や自社への貢献、法制度への対応などに必,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ずや役に立つであろう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　その時にはフローの管理方法をきっちりと整備し、形骸化、陳腐化しないように常に最新の業務が反映されてい,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ることも重要である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　「過去の成功」は過去のものでしかない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,戻る,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100126/343786/?itp_leaf_backno,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　きちんと定着したか否かは別にして、標準化に取り組んだことのない企業はないだろう。少数派ではあるが、標準,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,化に成功した企業ではプロセスの品質や生産性を向上させている。だが、そうした”成功企業”にも落とし穴が待ち受,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,けている。技術や環境の変化に追随できないと、標準プロセスが「足かせ」になり得る。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　過去の成功体験を形式知化した「ベスト・プラクティス」というものには、その輝きが急速に失われる危険性があ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ることを忘れてはならない。今回は、標準化に一度は成功したにもかかわらず、いつの間にか成功実績が「過去,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,の遺物」となり果ててしまった小売業のD社の事例を基に、標準化に失敗する原因を解説する（図１）。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図１●標準化に失敗する6つの理由,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■”自慢”の成功体験,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準化を実現するためには、それなりの期間と費用が必要であり、現実的な実行までには困難が伴う。それだ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,けに一度標準化の取り組みに成功すると、強烈な「成功体験」として当事者に印象付けられる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そのため、標準化について新たな取り組みが必要になる際に、どうしてもその成功体験が影響を及ぼす。それ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,は必ずしも良いものとは限らず、状況によっては成功事例やベスト・プラクティスと決別することも必要になる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　全国展開している小売業のD社は、一般消費者向けの商品販売を通じ、顧客情報、取引先情報など多種多様,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,な情報を取り扱っている。企業の社会的責任を果たすに当たり、情報の適切な取り扱いと安全管理のために、全,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,社を挙げて情報セキュリティ管理の標準化に取り組んだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　「過去の成功」は過去のものでしかない（2/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100126/343786/?P=2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　マーケットの動きよりも早く情報セキュリティの重要性に気付いていたD社は、情報セキュリティの必要性が今の,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ように議論される前から取り組みを始めていた。取り組みが早かったことのマイナス要因としては、世間には前例,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,があまりなく、試行錯誤をしながら情報セキュリティ管理の標準化に取り組んだことが挙げられる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　D社の社員だけでは知見と経験が十分ではなかったため、外部業者の知見も活用し、計画の策定から規定づく,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,り、現状業務への反映方針を定義していった。その甲斐もあり、自社の業務に沿った標準を確立し、全社への展,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,開・周知徹底に活動の中心が移っていった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準プロセスを展開する際には、企業利益に直結しない取り組みに対して事業部門からの抵抗があり、必要性,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,やリスクの説明および関係者の理解にかなりの労力を費やした。最終的には経営層を巻き込み、トップダウンで,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,全社に徹底させた。その結果、業務リスクが減り、顧客の信用を獲得することで売り上げアップにも結び付いたと,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,いう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　この取り組みは、「ベスト・プラクティス」「先進事例」として他社が参考にするほど、大きな成功を収めた。D社の,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,関係者は、自らが構築した標準への自信に満ち溢れていた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■経営環境とのズレの解消へ、再び「栄光」を目指す,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　しかし、D社をめぐる状況は年々変化していった。その後、D社も他の企業と同様に事業の拡大、事業内容の変,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,更とそれに伴う組織変更、情報システムの再構築などが起こっていた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　このように経営環境が変化すると、当然のことながら以前の経営環境を前提にしていた標準化の内容を見直す,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,必要がある。D社ではセキュリティ標準を構築しているので、役割分担、責任所在、セキュリティ対象となる情報や,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,データ、業務プロセスや標準化プロセスなどを、環境変化のレベルに合わせてアップデートする必要がある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　もしセキュリティ標準の見直しが後手に回れば、顧客管理における新規情報の取り扱いや、新業務プロセスへ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,の対応などが疎かになる。そして実際に、現場では対応が疎かになり始めていた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そこで、既にあるD社のセキュリティ標準に対し、現状の経営環境に合わせた見直しを実施することになった。プ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ロジェクトのメンバーには、豊富な経験を買われて、前回の標準化に携わった関係者たちが選ばれた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　「過去の成功」は過去のものでしかない（3/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100126/343786/?P=3,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■自社の標準は、実はイレギュラーな存在だった！,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　繰り返すが、D社は、今まで自分たちが試行錯誤して取り組んできたこと、そして他社が成功・先進事例として注,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,目するほどの成果を出してきたことに、大きな自信を持っていた。しかし、一般的な法則ではあるが、過去の成功,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,体験が強烈であるほど、企業や組織は成功体験の棄却が困難になる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　最初に標準を定義したときは、業界でも対応事例が少なく、一般的な標準規程も出回っていなかった。それゆえ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,、外部業者の対応を参考にD社独自の標準を定義したのだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ところが、ここに落とし穴があった。時代の流れは速いもので、D社が見直しを始めた頃には、セキュリティ標準,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,としてISOのセキュリティ規格や個人情報の取り扱い認証などが世間に出回っていた。D社の標準は個別最適の,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,色彩が強く、世間のスタンダードから外れていたのだ。また、当時、外部業者から知見として提供されていた参考,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,標準も、影響力を持ち始めたグローバル標準と異なる部分が多かった（図２）。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図２●セキュリティ要件におけるD社標準と世間とのギャップ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準の見直しを始めた当初、担当者たちは以前の取り組み方を参考にD社独自標準の改修を目指していた。と,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ころが改修内容を検討する段階で、新規に取引先となった会社のセキュリティ標準を知る機会があり、自社の標,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,準と世間の標準にギャップがあることに気付いた。それでも最初は「自社の標準の方が最適」との思いが強かっ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,たが、念のために同業他社の事例を調べていくにつれ、「自分たちの標準はイレギュラーな内容だ」と認めざるを,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,得なくなった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　担当者のショックは大きく、一時はモチベーションも大きく下がった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　しかし、気を取り直して参考標準を選び直し、既存の標準とのギャップ分析を一から実施することで、時代と経,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,営環境に合った新標準を再構築したのだった。この際も外部業者の協力を仰いだが、他社事例と標準化動向の,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,知見を重視して選定した。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　事業部門への定着化でも再び労力を費やすことになったが、今までの経緯を正直に説明し、現時点における必,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,要性を丁寧に訴えることで理解を育んだ。最初の取り組み時に協力的な事業部門もあったので、円滑に進められ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,た部分もあった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　見直し作業を通じて担当者が学んだことは、「過去の成功体験は、現在または将来において必ずしも最適・有効,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ではないこと」、そして「過去の成功は、あくまでも一つの取り組み例として、今後の検討の参考にとどめるべきで,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,あること」だ。人間であるがゆえに、過去の栄光を意識せずにはいられない。それを乗り越えられるかどうかが重,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,要な点である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　「過去の成功」は過去のものでしかない（4/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100126/343786/?P=4,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■ベスト・プラクティスという言葉の”魔力”,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　D社の事例では過去の成功が「ベスト・プラクティス」と呼ばれていた。言葉の響きが良く、”ベスト・オブ・ベスト”,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,的な要素があると思われるだろう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　しかし、その目的を理解して利用しないと、標準化への取り組みの際に思わぬ方向へ導いてしまうことがある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ベスト・プラクティスという言葉の解釈については広義、狭義を含めて多様ではあるが、ここでは「過去の成功事,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,例や失敗事例を基に、目的を実現するために最も優れていると思われる実践の方法をまとめたもの」としたい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ベスト・プラクティスに触れるときの心得としては、「あくまでも過去の取り組みを基にまとめたものである」という意,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,識を持つ必要がある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　また、世間一般の標準規格で提供されるベスト・プラクティスは「テンプレート」と考えるべきだ。自社の特性に合,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,わせて「取捨選択」と「カスタマイズ」することを前提としている。上記の点をよく理解していないと、ときにベスト・プ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ラクティスは「現状にそぐわないワースト・プラクティス」になってしまう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■D社が犯した、大きなミス,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　お気づきの読者も多いと思うが、前述のD社は標準化の取り組みにおいて「大きなミス」を犯している。もしその,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ミスがなかったら、問題を起こすことなく、過去の成功体験の呪縛から脱却できた可能性がある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そのミスとは、「標準化自体の管理プロセスの欠如」である。実は過去の成功に縛られずに見直しや破棄を行う,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ためには、標準化の運用そのものを整備するのが一番効果的である。D社も一度構築した標準化があまりにも評,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,価が高かったために、現状に満足してしまい、見直すことを意識しなかったのだ。冷静かつ客観的な判断が当時,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,にあれば、標準化自体の運用管理方針をきちんと定義し、見直し作業を必須作業としてルール化できたかもしれ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ない（図３）。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図３●標準化の構造体と管理プロセス,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　「過去の成功」は過去のものでしかない（5/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100126/343786/?P=5,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　標準化の取り組みを適切に運用管理するためには、客観的な視点と継続するための体制が必要である。標準化,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,の取り組みに関与した担当者は、内容を一番把握しているので、見直しを行う際の担当者としてはとても有効である,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,。その反面、主観的な判断が混入する可能性も高い。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　そこで、できる限り第三者が経営環境と標準内容を客観的に比較し、評価することが重要となる。さらに、年度単位,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,でも構わないので、継続的に再評価するプロセスを構築することも大切だ。不況下では人員確保も難しいと思うが、,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,せっかく構築した標準化への取り組みを無駄にしないためにも、ぜひ適切な運用管理方法を検討していただきたい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　標準化に取り組む際には、根本的な目的に立ち返り、常に既存の取り組みを疑ってみてほしい。また、現在の経営,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,環境を踏まえ、「標準化の目的を実現するためには何が最適であるのか」「既存の標準のどこを改善・改革すべきか,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,」を考えなければならない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　標準化自体を再評価し、取り組み内容を見直すことは、担当者の立場にもよるが「自己否定」につながることが多,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,い。作業の負荷も高い。それゆえ、一度決めた取り組みを「そのまま継続したい」という雰囲気に流されやすい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　しかし、継続的に効果を発揮させ、自分たちの取り組みを意味のあるものにするために、強い意志の下に継続的,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,に取り組まなければならない。ぜひ勇気と気概を持って取り組んでいただきたい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　ときには、属人化だって悪くない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,戻る,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100127/343814/?itp_leaf_backno,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　標準化は業務活動に必要不可欠なものだが、それが企業や組織の「強み」を破壊してしまうとしたら、そんな標準,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,化を実施してはいけない。業務には、標準化すべきものと、そうすべきでないものがある。ある点に注目すれば、「標,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,準化すべきか否か」が自ずと明らかになる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準化の効果としてよく期待されるのは「属人化の排除」だ。ご存知の通り、属人化とは特定の業務プロセスが,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,特定の担当者に強く依存して行われる状態を指す。特定の担当者に業務が集中しがちになり、「会計システムは,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,、あの人が対応しないと仕事が回らない」とか、「この帳票システムの設計書のレビューには、あの人がいないと,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,不安だ」といった事態に陥ってしまう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　属人化は、IT部門ではよく起こる問題である。IT部門の業務は、専門的なITの知識が問われつつ、さらに業務,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,の知識も問われる。2つの異なる知識と幅広い経験が求められることから、どうしても担当できる人が絞られてくる,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。IT部門の業務は、とりわけ属人化しやすいといえるだろう。この問題をなんとか解決したいと考えるのは自然な,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,発想である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ただし、意外に思われるかもしれないが、属人化は必ずしも「悪」として排除すべきものではない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　例えば、特定システムの運用に関する緊急依頼やトラブルに対して、技術力の高い個人が対応したからこそ解,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,決に至ったという話はよくある。身近で見聞きした読者も多いのではないだろうか。これは企業にとって大きな「強,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,み」となる。そういう部分はあえて残し、「ミスやトラブルを減らしたい部分」を標準化することで、より高い業務品質,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,を実現することができる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　今回は運用業務の標準化に取り組んだ結果、「良い属人化」を排除してしまった事例を取り上げたい。これも「,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,失敗する標準化」の典型例の1つである（図１）。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図１●標準化に失敗する6つの理由,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■「属人化排除」の取り組みとして標準化を推進,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　グローバルに事業を展開する製造業C社のIT部門では、物流システムを担当するグループや生産システムを担,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,当するグループなど、システム運用を業務アプリケーション単位で組織していた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　C社のIT部門は、システムの利用現場から信頼されていた。各運用グループのメンバーは担当業務に精通して,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,おり、業務部門の要望や緊急の依頼にも柔軟に対応していたからだ。各メンバーは担当業務の運用を長期にわ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,たって続け、ときには業務部門の人よりも業務プロセスの全体像を把握し、複雑なノウハウを身に付けていた。そ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,のためIT部門長のA氏は、業務部門に満足度の高いサービスを提供していることに誇りを感じていた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　ときには、属人化だって悪くない（2/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100127/343814/?P=2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　だがA氏は、2つの課題に対処しなければならないと考えていた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　1つは、システム運用プロセスがグループ別に異なること。先日も、物流システムと工場在庫システムを連携さ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,せる案件で問題が発生した。システムの運用方法を巡って、物流システム担当者と工場在庫システム担当者の,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,意見が衝突したのだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　工場在庫システム担当のT氏に話を聞いてみると、「物流システムの運用品質に従ってシステムを改修すると、,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,工場在庫システム側に新たな業務対応が増えるので了承できない」というのだ。一方、物流システム担当のB氏,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,は、「これまでの改善の成果なのだから、この運用をやめるわけにはいかない」と譲らない。お互いがそれぞれの,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,システム運用方法を主張していたために、この案件の検討が一時止まってしまった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　もう1つの課題は、運用業務の属人化が高まっていたこと。現在は業務アプリケーション単位で運用グループを,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,編成し、複数人で対応している。特定の業務を属人化させないための配慮をしてきたが、それでも最近は「この人,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,が対応すれば安心できる」という雰囲気が出来上がっている。今はこれといって支障を感じないが、もし担当者が,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,急にケガや病気で入院するような事態になったら、一体どうなるだろうか。業務に支障を来すようなことを発生さ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,せてはならない、とIT部門長のA氏は案じていた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■ITILを基準に自社プロセスとのギャップを分析,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　2つの課題を解決するために、A部門長は各運用グループの運用基準を作成することにした。手始めに、明文化,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,されていない運用方法や、本来の役割でないにもかかわらず実施している業務活動を白日の下にさらすべく、現,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,状の運用プロセスを調査した。運用管理のベスト・プラクティスであるITIL（Information Technology Infrastructure,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,Library）の標準的な運用プロセスと自社の現行プロセスを対比させ、フィット・ギャップ分析により過不足を抽出し,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,た。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　すると、本来は業務部門が行うべき業務をIT部門で行っている部分や、運用グループ間での業務プロセスの違,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,いが明確になった。この結果を踏まえて、A部長はITILのITサービス・マネジメントで定義されている運用プロセス,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,を中心に、標準化に取り組むことを決断。特に属人化されていた業務は徹底的に排除し、業務知識があればだ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,れでも対応できることを目標に運用基準を策定した。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　新しい運用標準を導入すれば、新たに整備した運用標準によって人材の固定化が解消し、柔軟な人材配置が,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,可能になるだろう。さらに、グループ間の業務プロセスの違いも解消され、統一性のある対応を取れるようになる,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,と期待された。C社のA部門長でなくとも、多くの人はそう期待するのではないだろうか。それが標準化の主要目,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,的なのだから。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　ときには、属人化だって悪くない（3/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100127/343814/?P=3,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■すべてを同じ色に染めても、効果があるとは限らない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　だが現実には、期待したほど改善されなかった。確かに同じプロセス、同じテンプレートを用いて運用するように,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,なり、IT部門として統一性のある業務が行われるようになったが、新たな問題が生まれた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　例えば、IT部門の標準業務活動から外れる業務活動に対して、早急に業務部門に引き取るように改善依頼を,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,出していたが、なかなか業務部門から受け入れられずに調整が難航した。業務部門として見れば、過去の経緯,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,から生産性と品質が下がると分かっているのだから、引き取りたくないのは当然である。一方、IT部門としては、,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,当該業務を引き取ってもらえないと、以前と同じ担当者が対応せざるを得ない。結局、両者の間で折り合いがつ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,かなかったため、特定の個人に業務負荷が集中するという状況が続いた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　業務には、標準化によって高い効果が得られるものと、そうでないものがある。悩ましいのは、どの業務を標準,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,化すれば効果が高いのか、企業によって異なることである。標準化に取り組む際は、自社における標準化のポイ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ントは何なのかを、まず押さえる必要がある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　運用業務を例に挙げると、システムをできる限りトラブルなく運用することが大切なので、世間のベストプラクティ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,スを参考に自社の業務内容を見直すことは正しい行為だと考えられる。ただし、そこで識別された課題を、そのま,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ま対応すべき要件と考えてはいけない。世間では標準的な運用内容だったとしても、それが自社に当てはまると,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,は限らない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■「属人化を排除すべきか否か」の判断基準とは？,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ここまでは、「属人化」の問題を必ずしも「悪」として排除すべきでないことを述べてきたが、もちろん「悪」として排,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,除すべき「属人化」は多い。悪い属人化は、早急に解消したいところだ。ここからは、属人化の良し悪しを判断し、,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,「強み」を破壊することなく適切に標準化するためのアプローチについて説明したい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　まずは一呼吸おいて、標準的なプロセス（ベスト・プラクティス）を基準に自社の業務をフィット・ギャップ分析して,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,いるなら、その結果を読み返してもらいたい。そこで識別されたギャップは、属人化した業務や、運用グループに,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,よって内容が異なる業務だ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ここで、「世間では実施しているのに自社では取り組んでいない・・・」と恥ずかしがらずに、改めて確認してほし,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,いことがある。それは、ベスト・プラクティスとされる標準的なプロセスに対して、「なぜ自社ではギャップが発生し,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ているのか？」をじっくりと考えてほしいのだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　ときには、属人化だって悪くない（4/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100127/343814/?P=4,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　C社の場合は、プロセス品質の課題として物流担当グループが業務面で異なる対応をしていることが分かった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,物流担当グループの運用業務は、システム運用業務だけでなく、本来なら業務部門が行うべき帳票出力のオペ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,レーションも手掛けていることがギャップとして抽出されたのだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　C社のIT部門は、自部門の運用標準として次の4つの活動を定めようとしていた。（１）システムの利用方法に対,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,して問い合わせを受ける窓口業務、（２）定められた業務を繰り返し実施する定常業務、（３）ITに関するトラブル対,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,応を実施する障害対応業務、（４）ITインフラの管理業務、である。物流担当グループが手がけている帳票出力,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,オペレーションは（２）の「定められた業務を繰り返し実施する定常業務」からはみ出していた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　それでは、なぜ物流担当グループだけ業務部門側の運用にも手を出したのか。過去の経緯をたどってみると、,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,システム操作に起因する帳票出力のトラブルが多発していたため、IT部門側で請け負うことにしていたという。IT,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,部門の物流担当グループには業務内容とシステムの操作方法に習熟したメンバーがいたため、苦もなく対応でき,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,た。業務は属人化してしまうが、業務効率が良いため、このやり方が現在でも続けられていたわけだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　このように、なぜ現在の対応を行っているのか、ギャップの由来や経緯を把握することは標準化を行う上で重要,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,なポイントだ。なぜならば、ギャップは通常の業務プロセスには存在しない、自社にとっての「強み」か、もしくは「,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,弱み」である可能性があるからだ（図２）。その由来や経緯を知ることはギャップの影響を特定することにつながり,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,、「強み」となっているのであれば、運用標準に派生した業務内容を明記して残すことができる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図２●属人化に至った経緯や由来に着目する,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　単純に「弱み」であるか、理由もわからずギャップとなっている要件は、標準化の対象としてしまってよい。C社の,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ように物流業務だけ帳票出力オペレーションを手掛けているケースでは、物流システムの担当者のノウハウを十,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,分に活かすことにより、価値を提供している。あえてこの部分を残すという判断も”あり”だ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　ときには、属人化だって悪くない（5/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100127/343814/?P=5,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■プロセスの属人化？成果物の属人化？,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ただし、その担当者がいなくなると業務が回らなくなる状態は避けたい。そこで次に、ギャップが「プロセス上の,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,属人化」なのか、それとも「成果物上の属人化」なのかについて確認してほしい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　属人化の排除には、大きく2つの目的がある。1つはプロセス品質の属人化の排除。標準的なプロセスに従うこ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,とで、誰もが同じ結果を出せるようにすること。もう1つは成果物品質の属人化の排除。誰もが同じ情報を把握で,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,きるように成果物の内容を標準化することだ。この2つの目的を両方達成することで、属人化が排除されたと考え,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,られる（図３）。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図３●プロセスと成果物の属人化,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　「プロセス品質の属人化の排除」では、標準的な業務プロセスの設定に加え、各プロセスで必要とする情報を記,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,載したり、そのプロセスを完了させるための条件などを明示したりする。またプロセスを実施する上でのノウハウ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,やスキルなども明記されていることが望ましい。このような活動に取り組むことで、特定のプロセスにおいて「何を,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,したら良いのかわからない」という状態を作らないようにする。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そして「成果物品質の属人化の排除」では、成果物を作成する上で記載する項目や必要とする情報を設定する,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。成果物が提供する品質は定義された項目と入力情報の品質に依存するようになるため、求める品質に応じて,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,詳細に項目を設定していく。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　自社が持つ「強み」を活用する戦略的な標準化に取り組む際は、少なくともプロセス品質の属人化の排除か,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,成果物品質の属人化の排除のどちらかに取り組んでおくべきだ。どちらかのアプローチで業務知識を可視化して,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,おけば、その業務活動が孤立して「あの人でなければ分からない」という状況を抑制できる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　C社の場合、物流業務だけ帳票出力業務をIT部門が請け負うことにするのであれば、業務フローも帳票の成果,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,物内容も文書化しておくべきだ。標準化に取り組むときには、プロセスか成果物を可視化することを忘れてはいけ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　関連部門の「反感」を買う標準化,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,戻る,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100205/344256/?itp_leaf_backno,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　標準化の進め方を一歩間違えば、事業部門から大きな反感を買う―。標準化の内容そのものが重要なのは当然,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,として、その進め方にも十分な配慮が必要だ。「IT標準への期待・満足度」は、時間の経過につれて変化する。「幻滅,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,期」を乗り越え、成果を手にするための施策を考えていきたい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準化を推進する過程では、往々にして次のような事態が起こる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ある事業部門が新しいビジネス・モデルの検討を終え、システム開発プロジェクトで、業務システムの設計開発,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,フェーズに入ったとしよう。自分たちが思い描くビジネス・モデルを「明日にでも実行したい」という気持ちがあるた,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,め、それを実現可能なIT製品やサービスがあるなら、すぐにでも調達して活用してほしいと考えるだろう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　にもかかわらず、様々な会議の場で、IT部門が「IT標準」をしきりに気にしていたとしたら、どう思われるだろう。I,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,T部門は、より大きな成果を生むためにIT標準を利用しようと苦心しているわけだが、それはなかなか伝わらない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。「業務要件よりIT標準を優先させるかのような態度」と受け取られれば、事業部門はIT標準をプロジェクト推進上,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,の「阻害要因」とみなすかもしれない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そう、同じプロジェクトで1つのゴールを目指す仲間のはずなのに、事業部門にとってIT部門が「抵抗勢力」と映,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ってしまうのだ。読者の皆さんも、似たような経験があるのではないか。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IT部門が「抵抗勢力」とならずにIT標準を推進するには、事業部門の関係者にIT標準に対する理解を深めても,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,らうための活動が不可欠である。せっかく整備したIT標準なのだから、十分に活用され、期待通りの成果が出るよ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,うに推進したい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　今回はIT標準を整備して展開活動を行った結果、十分な理解を得られなかったN社の事例を取り上げ、なぜ標,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,準化が失敗するのかを考えていきたい。この事例では、事業部門出身の情報システム部長が、かつてシステム,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,開発プロジェクトに参画したときの苦い経験を基にIT標準の改定に取り組んだ。しかし、「IT標準に対する事業部,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,門の期待」をうまくコントロールできず、あやうくプロジェクトに支障を来すところだった（図１）。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図１●標準化に失敗する6つの理由,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　関連部門の「反感」を買う標準化（2/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100205/344256/?P=2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■営業出身のシステム部長がIT標準の啓蒙活動に失敗,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　国内の大手サービス業N社では、新年度の人事異動により、IT部門にR部長が就任した。R部長は以前、営業,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,部門に所属しており、CRM（顧客情報管理）システムの構想から導入まで、ITに強くかかわり、推進してきた経験,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,がある。ビジネスとITの両方に知見を持ち、バランスを取りながら推進する行動力やリーダーシップに一定の評価,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,を得ていた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　R部長はCRMシステムの導入時に、業界でシェアを拡大しているクラウド・コンピューティング型サービスの利用,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,を強く推した。営業部門が今欲しい機能を短期間で導入できるだけでなく、既に多くの企業で実践されており、豊,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,富な導入実績があったためだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　それに対して当時のIT部門は、既存のIT標準にクラウド・コンピューティングの利用が考慮されておらず、社内で,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,クラウド・コンピューティング型システムの導入実績もないことから、即座に「待った」をかけた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IT部門はその後、社内で当該システムを検証し、IT標準も改定。正式にクラウド・コンピューティング型のCRMシ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ステム導入へと至ったが、リリースに向けて少々時間を要した。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　R部長は、この時の経験から「ビジネス機会を逃さずに現場のニーズを生かすシステムとITインフラをタイムリー,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,に提供し続けるべきだ」という信念を持っている。それを軸にR部長はIT部門を運営していった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■定期的にIT標準を見直すプロセスを導入,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　就任して間もなく、R部長は既存のIT標準の見直しを開始した。N社のIT標準は、ITアーキテクチャのレベルで標,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,準的に利用する技術が決められている。例えばデータに関する標準なら、どういった技術を利用してバックアップ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,環境を構築すべきか、などが定義されている。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　しかし、N社には定期的にIT標準を見直すプロセスは整備されていない。新たなシステムを導入する際に、必要,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,に応じてIT標準を改訂していった。そのため、新システムを構築する時は事業部門とIT部門の間でIT標準にかか,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,わる調整が必要となり、その対応に手間取ることもたびたび発生していた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　R部長は、まずこの状況の改善に着手した。年に1回、年度末の1月～3月に自社のITアーキテクチャと世間のIT,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,動向を見比べて、IT標準を定期的にアップデートしようと考えた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　さらに、改定したIT標準を各事業部門に説明する機会を設けて、事業部門に理解を求める活動も推進した。例,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,えばIT標準を改訂した目的について、「利用技術の陳腐化を防ぎ、社内のシステム品質の向上を図る」「IT標準で,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,全社的に統一したシステム環境を構築し、それによりシステム導入期間の短縮や導入コストの削減につなげる」,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,と高らかに宣言した。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　R部長は、このような説明会を通してIT標準のメリットを周知していけば、事業部門にIT標準の意義を理解しても,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,らえるだろうと期待していた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　関連部門の「反感」を買う標準化（3/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100205/344256/?P=3,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■以前と変わらぬ意見の衝突,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　だが、R部長の目論見はあっけなく崩れた。システム開発プロジェクトにおいて、IT標準で定義したソフトウェア,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,やハードウェアの利用は順調に進んでいったが、一向に改善されない問題が発生していた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　それはR部長自身も以前に経験したことだ。事業部門とIT部門の間で、「これでは事業部門が今欲しい機能を短,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,期間で導入できない」とIT標準のアーキテクチャを巡り意見が衝突してしまったのだ。またIT標準で定義したサー,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ビスを利用しようとすると、「想像以上に導入コストがかかる」などの声もちらほら聞こえてきた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IT標準を定期的に改定するプロセスを導入したばかりとはいえ、「IT標準を利用しやすく整備した」と自負して,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,いたR部長は、この状況に頭を悩ませた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■「幻滅期」での満足度アップが鍵,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IT標準は、整備すれば期待する効果を発揮するような、即効性のある規定ではなく、むしろ「遅効性」の性質を,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,持つ。いくつかのシステムの開発や運用を経て、またIT部門と事業部門のそれぞれで共有されていくにつれて効,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,果が見えてくる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そのため、IT標準を周知して定着化するプロセスの巧緻が、その成果に与える影響は大きい。IT標準を導入す,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,る際には、関係者に事前説明会を実施すればよいという雰囲気になりやすいが、それは全く見当違いである。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　N社の事例においてまず認識しておきたいのは、IT標準に対する「事業部門の期待の変化」だ。その変化を図,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,式化したのが図２である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図２●IT標準への「期待」をコントロールする,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,「幻滅期」をいかに乗り越えるかが勝負,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IT標準を整備して事業部門に説明会を開催し、その目的や効果を説明した段階では、事業部門は「これでビジ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ネスのアイデアを具体化しやすくなる」とか、「システム開発の技術面で悩まなくて済む」など、IT標準に対して過,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,度に期待する傾向がある。これがフェーズ1の段階、「過度な期待」だ。この段階では特に問題は起こらないが、IT,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,標準への期待が高ければ高いほど、後に大きな幻滅に転じるリスクがある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そしてシステムの基本設計が始まるころ、事業部門は次第に「IT標準の実像」を知るに至り、「IT標準に伴う、い,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,くつかの制約」に窮屈さを感じるようになる。想像していたほどの効果がないと疑うようになり、IT標準に対して不,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,満を募らせる。これがフェーズ2の段階、「幻滅期」。冒頭で紹介した、IT部門が「抵抗勢力」と見なされてしまう話,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,は、この幻滅期での出来事である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　だが、実際に情報システムの利用を続けて経験値も上がり、IT標準の価値を理解し始めると、現実的な利用方,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,法が身についてくる。「このIT標準サービスを利用して商品マスターを実装すると構築が早い」という意見や、より,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,良く利用するための協力体制、利用プロセスに関する意見が出てくるようになる。これがフェーズ3の段階、「成熟,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,期」の訪れである。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　このように、事業部門がIT標準を十分に使いこなし、その効果を享受するには、早くフェーズ3の状態に移行させ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ることが不可欠である。そのためには、以下の3つのポイントを意識してほしい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,（１）,,過度な期待を抑制する,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,（２）,,期待されているうちにIT標準の利用を習慣化する,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,（３）,,事業部門の声をIT標準に反映する,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　関連部門の「反感」を買う標準化（4/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100205/344256/?P=4,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■（１）過度な期待を抑制する,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　時間やコストをかけてIT標準を整備するのだから、できるだけ高い効果を出したいと考えるのは当然だろう。だ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,が、IT標準に期待しているのはIT部門だけではなく、事業部門も同じように期待していることを忘れてはいけない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。自分のビジネス・モデルやアイデアをITの制約なしで実現したいと願っている事業部門にとって、IT標準は果た,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,して「心強い味方となる存在」なのか、はたまた「憎むべき敵となる存在」なのか、心のどこかで見極めようとして,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,いる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IT部門がその期待に応えるのは大切なことだが、必要以上に効果を誇張してしまうことは避けるべきだ。期待す,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,る効果を適切に事業部門に伝えるには、マーケティングの基本である「４P」と「４C」を意識してほしい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　「４P」とは、製品（Product）、価格（Price）、流通（Place）、プロモーション（Promotion）という4つの頭文字Pを取っ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,たマーケティング・ミックス理論。売り手の視点で、製品をどのように提供していくかを検討するときのツールとな,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,る。IT部門では、IT標準の内容や効果、推進方法などを検討する際に、「４P」を参考にするとよい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　次に「４C」は、顧客価値(Cunstomer value）、顧客コスト（Customer cost）、利便性（Convenience）、コミュニケー,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ション（Communication）の4要素で構成される。売り手側の視点で見た「４P」を、顧客側の視点でとらえ直したもの,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,だ。こちらは、ビジネス・モデルやアイデアの実現に対してIT標準はどのような価値を提供するのか、価値を享受,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,するためにはどの程度の負担があり制約を受けるのか、などを検討する際に「４C」を参考にするとよい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　「４P」と「４C」の具体的な説明は割愛するが、そのエッセンスを基に、事業部門の期待をうまくコントロールする,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ための方法を紹介する。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　まず、4Cの検討から始める。図3の右側を見てもらいたい。事業部門がIT標準に期待する価値（顧客価値）、IT,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,標準の利用に伴う制約条件や負担（顧客コスト）、利用のしやすさ（利便性）、そして事業部門の意思疎通方法（コ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ミュニケーション）を把握して、事業部門の視点からIT標準の説明内容を考えてほしい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図３●「４P」と「４C」を利用したIT標準のアピール方法の検討,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　4Cの各要素は、それぞれ4Pの要素（図3の左側）に対応しているが、視点が全く異なることに注目してもらいた,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,い。N社の事例では、「標準化を進めたい」というIT部門の視点（4P）のみで説明していた。事業部門がIT標準を評,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,価するポイント（４C)のうち、「制約条件や利用負荷」「使い勝手」などへの説明が足りず、結果として過度な期待を,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,植え付けてしまった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　それゆえ、標準化の取り組みにおいては、「４C」を起点にして、そこに「４P」を加味するアプローチを採るべきだ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　関連部門の「反感」を買う標準化（5/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100205/344256/?P=5,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■（２）期待されているうちにIT標準の活用を習慣化する,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　「鉄は熱いうちに打て」という諺（ことわざ）がある。鉄は真っ赤に熱せられているときは柔らかく形を整えやすい,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,が、冷めて固くなってしまうと形を整えにくい。このことから、若いうちに鍛えるべき、または熱意があるときに事を,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,始めると進めやすいことを表し、機を逸してはならないことを意味する。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準化の推進にも同じことがいえる。事業部門の期待が高いうちに標準化の意味や効果を説明して理解を求,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,め、少しでも早く定着化させておきたい。たとえ過度なものであったとしても、期待を抱いている間に、IT標準を活,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,用するための運用プロセスを４C視点に４P視点を加えて説明し、正式にリリースし、ある程度の運用を始めること,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,が重要だ。その間は、事業部門も「IT標準に伴う、いくつかの制約」より効果に理解を示して、IT標準に前向きに,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,協力してくれるだろう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そしてもう1つ、事業部門側の立場から考えると、彼らとしても熱く期待しているときの方が「打たれやすい」。つ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,まりIT標準の制約を受け入れやすく、それに伴う痛みも比較的少なくて済む。その結果、幻滅期から成熟期にか,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,けて満足度を向上させるための取り組みが軽減され、IT標準が効果的に機能する可能性が高くなる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　「鉄は熱いうちに打て」。このほうが、IT部門と事業部門ともに苦労が少なく、IT標準をフェーズ3の成熟期に移行,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,させやすいのだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■（３）事業部門の声をIT標準に反映する,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　幻滅期は主に2つの原因から訪れる。1つは先に説明したように事業部門の期待が過度であった場合。IT標準,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,が適切に効果を発揮していたとしても、事業部門がそれ以上の期待値を持っていたら、幻滅してしまうのは時間,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,の問題だ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そしてもう1つは、IT標準が効果的に機能しなかった場合だ。例えば、今まではシステム・データのバックアップ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,機能を個別に構築していたとしよう。そこで統合バックアップ・サービスを構築し、各システム・データのバックアッ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,プを1つの統合バックアップ・サービスで実現する標準化に取り組んだとする。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　さて、事業部門はリアルタイムのバックアップを要求していたが、コストの都合で統合バックアップ・サービスでは,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,提供していなかった。これでは事業部門が求めるタイミングでのバックアップを実現できず、幻滅期が近づいてし,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,まう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　この原因については、事業部門のモチベーションを向上させる「チャンス」として対応したい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IT標準はITに関する業務プロセスの品質を高め、より良い成果を安定して生み出すために存在するが、その成,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,果を求める理由は「ビジネスの成功」にある。統合バックアップ・サービスの実現により安定した業務品質を提供,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,し、かつ運用コストを削減できるとしても、使わなければその効果は限定的となる。IT標準を「利用される標準」と,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,して成熟させていくには、事業部門の声を取り入れて改善していくことは常に求められる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ただし、事業部門から多くの要望があるからといって、無作為に取り入れたのではIT標準を提供するための負,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,荷とコストを上げるだけだ。厳格にIT標準を守ることと、役に立つIT標準を提供することのバランスを検討して、そ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,の判断結果を事業部門に伝えるようにしてほしい。対応できるのであればよし、対応できなくとも妥当性のある理,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,由を提示できれば、事業部門の落胆を最小限にできるだろう。同様のニーズが集まれば、今後実現できる可能性,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,が高まることを伝えるだけでも良い。事業部門のビジネスを支えるためにIT標準が存在していることを伝えたい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　N社ではプロジェクトの終了後、上記の点に気付いたR部長が2つの手を打った。まず、IT標準をIT部門内だけで,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,検討するのではなく、事業部門のメンバーを加えた。どういった説明内容を織り込むと事業部門のメンバーの心,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,に響くのかを検討した。そして、来期の事業計画の内容からシステム化に必要な要件を引き出し、その要件に適,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,合するIT標準を事前に検討し、拡張性と柔軟性を備えたIT標準としてアップデートすることにした。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　このように、事業部門とIT部門の思惑や期待を最初にすり合わせるようにしていけば、R部長が直面したような,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,トラブルは未然に防げる。その後、N社では全社的に「成熟期」に入り、IT標準がしっかりと定着した。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　今回は、IT標準はただ関係部門に説明すれば効果を得られるものではなく、「期待や満足度の変化」を意識して,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,適切にアピールすべきことを説明した。ぜひ自社のIT標準の説明方法に「４C」の視点が組み込まれているかどう,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,か、確認してみてほしい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　「納得感」なければ誰も標準を使わない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,戻る,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100326/346248/?rt=nocnt,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,　良い標準規程を作成しても、現場の開発者がその必要性や効果に納得できなければ、従来の慣れた開発方法を,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,守り続けるに違いない。標準化の取り組みにおいて、この「納得感」の醸成は極めて重要だ。しかし、標準化担当者,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,たちの目は「どういう標準規程にするか？」という点にばかり向けられている。典型的な失敗パターンである。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　皆さんは、標準化の取り組みにおける「成功」とは、どんな状態を示すとお考えだろうか。それは標準規程を整,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,備することではないし、成果物フォーマットの品質を向上させることでもない。これらの整備はあくまで標準化の過,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,程で取り組むことであって、整備自体を目的としてはいけない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　しかし、標準化プロジェクトを立ち上げるという企業に話をうかがうと、「何の規程を整備すればよいのか」「同業,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,他社ではどういったプロセスで業務を行っているのか」「参考となる方法論はないか」、ひいては「サンプルを持っ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,てきてくれないか」というように、標準化による「成果物の内容」に焦点を絞って検討しているケースが非常に多い,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。こうした傾向は「失敗する標準化」の一因となる（図１）。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,図１●標準化に失敗する６つの理由,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準化の内容を適切に検討すべきなのは間違いなく、そこに起因する問題により失敗した標準化の事例につ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,いて、これまで解説してきた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　だが、標準化の内容と同じくらい大切なのは「取り組みの進め方」だ。いくら良い開発標準を作成しても、開発標,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,準を利用する目的や効果が開発現場に伝わっていなければ、開発者は従来の慣れた方法で開発を進めるだろう,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　今回は、適切なIT標準化成果物を作成しかけていたにもかかわらず、標準化の参考とする方法論に気を取られ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,、展開に苦しんだ事例を紹介したい。この事例では、CMMIを参考に自社の開発プロセスの標準化に取り組んだ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ところまではうまくいっていた。だが、社員の「納得感」の醸成に苦労した結果、標準化の展開までに想定以上の,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,時間がかかってしまった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■開発ノウハウを全社で共有できない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　情報サービス業T社は、様々な業種に対してシステム開発サービスを提供する企業だ。公共系、製造・流通系、,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,金融系など、顧客企業の業種別に事業部を組織して開発業務を行っており、それぞれの事業部にて開発標準プ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ロセスと成果物が定義され、運用されていた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　「顧客企業の業種別に開発標準が最適化されている」と言えば聞こえはいいが、あくまで個別に開発標準を用,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,意した結果である。各事業部で標準成果物とされるテンプレート、例えばプロジェクトの作業構成を示すWBS（Wor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,k Breakdown Structure）一つを見ても、その書き方や記載するタスクの粒度が事業部ごとに異なっていた。T社は,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,、事業部をまたいで異動した社員が開発方法の差異に戸惑う状況を「課題」と認識していたが、これまでそうした,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,異動が少なかったため、特別に対策を打つわけでもなかった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　しかし、社内で事例共有会などを開催すると、問題が鮮明になった。業種は違えども、同様のシステム開発をす,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,るのに社内の知見を利用しづらかった。そもそも他事業部の開発方法が分かりにくいからだ。開発ノウハウを全,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,社で共有できない状況に危機感をおぼえたT社は、ようやく腰を上げた。会社全体での生産性向上を目的に、全,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,社標準となる開発標準モデルを策定することにした。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　「納得感」なければ誰も標準を使わない（2/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100326/346248/?P=2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■高品質のプロセスができたと考えていたが・・・,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　全社開発標準モデルの策定に向けて、T社は製造・流通系事業部の社員で構成したプロジェクトチームを発足,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,させた。基本的にCMMIの開発プロセスを参照して全社標準モデルを検討したが、現実に使える標準にすべく各,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,事業部の開発標準プロセスを可視化してプロセスを確認し、全社開発標準の検討を進めていった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ただし、CMMIの全領域を取り込んだ開発標準プロセスを導入することは、現状に対して改善すべきタスクが多,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,すぎた。今回のプロジェクトの目的は「全社で共通利用できる開発標準を策定すること」なので、組織全体で開発,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,プロセスに一貫性のある状態とするCMMIレベル３のプロセスを取り込む形で改善策を作成することにした。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　必要以上に「あるべき姿」を追い求めるべきではない。現時点のT社では、レベル4で求められるような定量的な,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,管理、さらにはレベル5の最適化に向けた取り組みは時期尚早と考え、全社での標準化を実現してから段階的に,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,取り組むべきということで意見が一致した。T社としては、CMMIの要件を押さえ、かつ各事業部の開発プロセスの,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,良いところを組み込んだ開発標準プロセスとして、高品質のプロセスができたと考えていた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　こうして全社開発標準が完成し、各事業部門に対して説明を開始したとこで、社員からたくさんの意見が上,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,がってきた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　なぜかというと、全社開発標準の存在は多くの社員にとって初耳の出来事であり、そのような取り組みが社内で,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,行われていることすら知らない状態だった。事業部別に開発ノウハウを蓄積している現在の状態に不満を持つ社,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,員が多く、そういった標準を作成するのであれば、自分の考えも伝えたいという人も出てきた。また、管理職から,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,は、今まで部門内で利用してきた開発標準を全社開発標準に切り替えたとして、その効果が定量的に示されてい,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ないことを問う声が上がった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　開発標準プロジェクトとしては、現状を憂慮して意見を出したいという前向きな社員が多いことから、標準化の取,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,り組みが不可欠だという認識を強めた。だが同時に、現状の内容のままリリースしても、社内に不満がくすぶり、,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,うまく浸透しないことも分かった。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　T社は、全社にリリースする時期をやむなく延期。全社開発標準プロセスを広く浸透させるために、仕切り直しを,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,余儀なくされた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■社員の理解を得る標準化の進め方とは,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　先に述べておきたいのだが、その時に作成していたT社の開発標準は決して悪い内容ではなかった。CMMIレベ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ル３を考慮して全社で標準化を推進するための要件を押さえ、また今までに使われていた成果物をテンプレート,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,化するなど、使いやすい内容だった。社員から開発標準に対して多くの意見が集まったのは、現状に対して問題,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,意識を持つ前向きな社員が多いからこそだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　これだけ意識の高い社員が多いのだから、もしT社が初めからその声を生かしながら全社開発標準を検討して,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,いれば、問題は起こらなかっただろう。T社の取り組みで決定的な影響を与えたのは、「適切な推進計画」の欠如,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,、特に「コミュニケーションプラン」の実施を欠いていたことだ。「CMMI」という方法論を妄信し、プロジェクトメンバー,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,の意識が開発標準の内容にばかりむいていたせいなのかもしれない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IT標準の内容を検討する際に、汎用的な標準フレームワークを活用できることはこれまでの回で説明してきた,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,が、それは推進アプローチについても同様に活かすことが可能だ。ソフトウェアプロセス改善活動の計画・実行を,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,支援するためのモデルとしてカーネギーメロン大学　ソフトウェアエンジニアリング研究所（CMU/SEI）が策定した,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,IDEALモデルは、IT標準の推進プロセスの参考になる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　CMU/SEIというと、真っ先にCMMIを思い浮かべる方も多いだろうが、その連想は正しい。IDEALモデルは、CMU,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,/SEIが作成したCMMIのプロセス改善活動を行う際に活用されることを踏まえて検討されている。さらに、ITIL,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,（Information Technology Infrastructure Library）など他のフレームワークを活用した改善活動でも適用できる汎,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,用性の高い改善モデルとなっている。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IDEALモデルの「IDEAL」とは、プロセス改善活動における5つのフェーズの頭文字をとったものだ。それぞれ開,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,始（Initiating)、診断（Diagnosing）、確立（Establishing）、行動（Acting）、展開（Learning）を意味している（図2）。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,図２●IDEALのプロセス改善活動における5つのフェーズ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　開始フェーズでは、プロセス改善活動を開始するに先だって背景と目的を確認し、責任者の承認を取って推進,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,体制を整備する。診断フェーズでは、調査や可視化を行った上で改善対象を評価。将来像と比較して抽出した課,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,題を基に改善策を検討する。確立フェーズでは改善策の優先順位を検討し、実行計画を策定する。そして行動フ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ェーズで実際に改善策を実行し、展開フェーズで実行した結果の分析、改善策の評価を行い、次のプロセス改善,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,計画へと移行していく。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IDEALモデルの詳細については他に委ねるが、今回はIDEALモデルの5つのフェーズを踏まえて、T社が標準化,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,の推進計画、特に適切なコミュニケーションプランを実現するための3つのポイントを説明する。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　「納得感」なければ誰も標準を使わない（3/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100326/346248/?P=3,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■全社を巻き込む推進チームを結成する,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　前述したように、T社の標準化プロジェクトチームは製造・流通系部門の社員が中心となっていた。開発標準が,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,全社で標準化できていないことに、強い問題意識を持つメンバーが集まっていたので、各部門の開発標準を集め,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,たり、CMMIの項目を押さえたりするなど、開発標準の内容検討を精力的に進めることができた。内容の検討につ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,いては強力な体制が整っていたと言える。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ただし、開発標準を現場で活用してもらうためには、開発標準の内容が会社にとって適切であることに加え、も,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,う１つ大切なことがある。それは「全社を巻き込んでいる状態を作り出すこと」だ。マネジメント層から現場までが,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,全社開発標準の必要性をきちんと認識し、理解を深める必要がある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　IDEALモデルにおいて、マネジメント層に理解を深めてもらうことは、開始フェーズにおける「オーナーシップの,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,明確化」で行うとしている。これからプロジェクトの体制を整えたり、現場の協力を得て円滑に調査を進めるために,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,も、早い段階からマネジメント層の理解を得ておくべきだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　マネジメント層の理解を得るには、まず現状の課題や問題点をまとめて、開発標準化を展開する必要性を訴え,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,る必要がある。さらに、その効果を定量的に示すことが求められることが多い。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　T社開発標準プロジェクトでは、以前は全社開発標準の利用率を80％以上にすることを定量効果の1つとして提,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,示していた。だが、それは「効果に結び付いているかは分からない」と指摘を受けていた。そこで、過去の開発プ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ロジェクトを調査し、各開発工程の標準的な工数を算出。標準テンプレートの活用により、全体で約20％の工数,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,削減を目標とすることでマネジメント層の理解を得ることにした。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■標準化の推進には、現場にいるメンバーの参画が絶対条件,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　次に現場の理解だが、こちらは開発にかかわる全社員を対象として課題や問題を共有すれば、集まる情報も多,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,くなるだろう。しかし、限られた時間の中では難しい場合が多い。そこで各部門の有識者だけでもヒアリングを行,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,い、課題の抽出や問題意識の共有を行いたい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　また、開発標準に対して意識の高い社員が誰なのかも聞き出し、各部門で全社開発標準の推進に参画するメ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ンバーを検討しておこう。このメンバーには、これから展開する全社開発標準に関して、それぞれの所属部門に,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,おける推進役を担ってもらう。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　だが、得てしてそういった人材は多忙を極めているので、完全に参画してもらうことが難しいケースもある。その,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,場合はアドバイザーとしてミーティングにだけ参加してもらうなど工夫してほしい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　さらに、全社開発標準の取り組みは、どこか1つの部門だけで実行しても、他の部門からは自部門との関係性,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,が薄いとして軽視されやすい。また、開発現場のメンバーが参画せずに、品質管理などのメンバーを中心に検討,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,しても、現場を巻き込む強力な推進と浸透は難しい。各部門からのメンバー参画は絶対条件である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　このようにして全社を巻き込んだ推進体制を構築するためには、マネジメント層の理解を得つつ、各部門のメン,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,バーが参画し、協力を得られるコミュニケーションプランを作りだすことが重要である。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　「納得感」なければ誰も標準を使わない（4/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100326/346248/?P=4,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■標準化を浸透させるプロセスを省略してはいけない,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準化の取り組みは、すぐに効果を得ることの難しい活動だ。IDEALモデルが提示している各フェーズおよびプ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ロセスは段階的に示されており、一つ一つ取り組んでいくと相応の時間と手間がかかる。そのため、途中のプロ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,セスを「可能であれば省略したくなる」が、それは得てして遠回りする結果となる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　特に標準を作成する取り組みにおいては、参考とする標準化フレームワークを妄信してしまい、より良い標準仕,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,様を作ることに注力してしまいがちだ。本来、よく見るべきなのは現場で起きている問題であり、また開発現場の,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,声に耳を傾け、こちらの声を伝えていくコミュニケーションプランを整備していくことが重要だ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　T社の場合、開発標準の作成に着手する前に、各事業部門の開発現場に全社標準化の取り組みを説明してい,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,なかった。さらに、現場の開発者が今起きている問題、改善したいと考えている課題に関して、実行期間の関係,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,からうまく収集できなかった。その結果、開発標準が完成して説明会を開催したところで様々な意見が挙がる事,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,態に陥ってしまったわけだ。開発標準のビジョンの浸透、社内でのコミュニケーションが不足していた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　標準化のように、現場に変革をもたらすような取り組みは、標準化仕様の品質を高めることと同じくらい、開発現,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,場と問題意識を共有するコミュニケーションを取り続けることが重要だ。そのためには標準化プロジェクトが考える,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ビジョン、そして現在の取り組み状況を分かりやすく提示し続ける必要がある。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　ビジョンとは、アプローチやタスクを示したものではなく、今回の取り組みを通じて実現すべき「将来の姿」であり,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,、全社で開発標準を適用していく「意志」であり、何を目指しているのか全社で醸成すべき「共感」である。その内,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,容を伝え、フィードバックを得て、お互いの認識をすり合わせていく活動を継続的に行うのがコミュニケーションプ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ランの役割となる。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　例えば会社のポータルサイトに開発標準プロジェクトのサイトを開設して、ビジョンを展開したり、随時検討状況,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,を伝えていくのも良いだろう。議論の結果や、標準化される項目などが社員からわかる状況を提供することで、お,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,互いを理解し合う機会が増える。手間のかかる活動かもしれないが、開発標準の取り組みは認知されて初めて,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,成果の上がる活動だ。ここで手を抜いてはいけない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■短期的に得られる成果を積み上げる,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　T社では作り上げた全社開発標準を展開すべく、全社で説明会を実施したが、このタイミングでいきなり全社に,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,適用するのはリスクが高かった。元々は各事業部門の開発標準であるとはいえ、新たに定義された開発プロセス,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,や承認フロー、成果物テンプレートなどが本当に現場で成果を上げるのかは、実際に適用してみないと分からな,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,い部分がある。何かしら改善事項が見つかった場合に修正するとしても、一度全社に展開した内容を修正するの,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,は、開発標準プロジェクト側も利用者側も負担が大きい。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 失敗する標準化　「納得感」なければ誰も標準を使わない（5/5）,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,http://itpro.nikkeibp.co.jp/article/COLUMN/20100326/346248/?P=5,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　また、適切な内容であったとしても、開発標準が浸透して効果を実感するまでには時間がかかる。短期的に達,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,成可能な目標なり成果を設定しておかないと、推進力が低下してしまう恐れがある。標準化の取り組みに今後も,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,協力していくことで成果が上がっていくことを、開発現場をはじめ、開発標準プロジェクトの推進メンバー自身も実,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,感できていなければ、途中で諦めたり、ときには反対勢力に身を投じてしまうかもしれない。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　そこで開発標準を部分的にパイロットテストすることを勧めたい。パイロット適用する際には、特定の部門だけ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,で開発標準を適用して効果を検証するパターンや、開発標準の一部分を切り出して適用するパターンなどがある,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,。いきなり全社に適用せずに、段階的に検証して効果を確認するとともに、改善点を抽出して、開発部門が使い,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,やすい標準へと修正していく方が良い。この活動も大切なコミュニケーションプランとなり得る。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,■T社の巻き返し,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　T社ではこのような３つのコミュニケーションプランに着目して、各部門から開発標準プロジェクトに参画するメン,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,バーを改めて募り、各部門の管理職や社員の声を反映しながら開発標準を改定していった。その検討過程はポ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,ータルサイトで公開し、検討内容の展開に力を注いだ。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　全社展開する前には、製造・流通系部門に部分的に適用して、標準化のプロセスや成果物の使い勝手を検証。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,その評価を踏まえて、改めて全社展開を進めた。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,　今回は、開発標準を検討するプロセス、特にコミュニケーションプランに着目して「失敗する標準化」の原因を説,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,明した。標準化の成功はコミュニケーションプランの成功に左右されるといっても過言ではない。「標準化の内容,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,を検討すること」と「プロセスの展開」、この両方のバランスを取りながら、皆さんが標準化の取り組みを推進し成,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,功することを願う。,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,