ビジネス部門を巻き込もう

社内標準化ではビジネス部門とIT部門の連携が重要

IT部門は、社内標準を振りかざして厳密な「正しさ」を追求すべきではないが、かといって要求にやみくもに対応して混乱を招き、サービスレベルを低下させてしまってもいけない。

公開 2009年05月28日 07時30分

更新 2012年09月04日 18時05分

著者

Niel Nickolaisen

[TechTarget]

印刷する Googleで優先するソースとして追加

　わたしは非IT分野のキャリアを経てIT責任者になった。社内では周知の事実だが、実はCEOがわたしにIT部門を任せたのは、わたしがITについて不平ばかり言うのでうんざりしていたからだ。実際、彼はわたしにこう言った。「そんなに批判するなら、自分でIT部門を運営したまえ」。それからわたしはIT業務に明け暮れることになった。その中にはソフトウェアとアーキテクチャの標準化が含まれる。

　ITを担当する前、ソフトウェアとアーキテクチャの標準は、わたしにとって最大の不満の1つだった。ITスタッフがこうした標準を盾に取ってわたしの構想を阻止しているように見えたからだ。わたしには構想を進めるための技術やアプリケーションのアイデアがあったのに、ITスタッフが「標準」や「アーキテクチャ」にかかわる理由を挙げてアイデアを却下するということが何度も繰り返された。

　ITの仕事に就いてからは、わたしはソフトウェアとアーキテクチャの標準を受け入れるようになった。これらは、システムやソフトウェアが陥りやすい複雑化を防ぐのに役立った。例えばマーケティング担当者が、ある強力なITツールの導入を要望してきたとき、わたしは社内標準を踏まえ、新しいデータベース、プログラミング言語、OSを採用することなく、その優れたソリューションを導入することができた。また、社内標準に準拠することで、Visual FoxProやAcademic Universeなど、一部の社員にだけ必要なツールを導入、サポートすることは考えずに済んだ。

　だがある日、社内標準を徹底するという理由で、ITの適応性や使い勝手の向上を目指す試みに待ったを掛けようとしていたとき、わたしは、以前反発していたやり方を自分も踏襲してしまっていたことに気付いた。わたしも社内標準を口実に使っていたのだ。だが、どうすれば混乱を避けながら、社内ユーザーのニーズに広く対応できるのか。

　相反する面があるこれらの課題の両立に取り組んでいたとき、わたしは、それを自分だけで実現しようとする必要はないと思い至った。そのおかげで適切な手を打つことができた。それは、ビジネス部門の代表者にIT部門のアーキテクチャ標準委員会に出席してもらうだけでなく、そのメンバーになってもらうことだった。

　IT部門のアーキテクトは戸惑い、ビジネス部門の代表者はおっかなびっくりだった。それまで両者は交流がないのが通常だったからだ。委員会の会議は、最初の何回かはやや難航したが、その後は円滑に進んでいった。アーキテクトはビジネスニーズをよく理解するようになり、ビジネス部門の代表者はIT部門の仕事の難しい点をよく理解するようになった。両者の協力の成果である社内標準は、柔軟性を確保しながら複雑化を回避できるものになったと思われた。

　例えば、われわれはデータベース技術と開発環境の標準化では、市場をリードしていると考えられており、将来性のある技術（具体的には、BtrieveではなくOracleやSQL Server、FORTRANではなく.NETやJavaなど）を社内標準とする方針を決めた。また、ERP（統合業務パッケージ）システムやCRM（顧客関係管理）システムにアプリケーションを接続する際は、動作保証があり、テスト、サポートされているインタフェースを介してのみ接続を行うことで合意した。

　こうした共同作業を経て、ビジネス部門では、ITへの要求の取捨選択がより適切になった。ビジネス部門はITソリューションを調べて吟味する際、共同作業を通じて理解したIT部門の視点を加味して選択肢を検討するようになった。例えば、社内標準データベースシステムに対して実行されるアプリケーションだけを検討の対象とした。

　アーキテクトもより寛大な姿勢を示すようになった。アーキテクトは推奨OSをWindowsと定めたが、Linuxなどを選択する余地も残した。ただし、64ビットのDEC Alpha／OSFのようなプラットフォームは選択肢から外した。

　またアーキテクトは、技術動向ではなくビジネス動向の観点から技術をとらえるようになった。以前はなかったことだが、アーキテクトはビジネス部門と協力し、現在の情報を基に、社内標準がどのように進化するかを予測したアーキテクチャロードマップを作成した。こうした社内標準を設けるとともに、標準以外のアプリケーションやOS、データベースなどを管理することのデメリットについてビジネス部門とIT部門が共通の理解を持つことは、どの技術の活用を検討するか、また、使われなくなってきたシステムのうちどれを廃棄するかを判断するのに役立つ。

　こうしたアプローチは、社内顧客へのITサービスに関するわたしの経験則にぴったり合致する。それは、「正しさよりも、役に立つかどうかの方が重要」というものだ。IT部門が社内標準を振りかざして厳密な「正しさ」を追求しようとしている場合、そのIT部門が役に立っているかどうかは疑わしい。だが、その一方でIT部門は、役に立とうとするあまり、要求にやみくもに対応して混乱を招き、サービスレベルが低下してしまう事態も避けなければならない。顧客価値に基づく実際的なアプローチを取ることで、社内標準の選択、適用を的確に進めることができる。

本稿筆者のニール・ニコライゼン氏は米HeadwatersのCIO兼戦略計画担当副社長。

印刷する

この記事の著者

Niel Nickolaisen

社内標準化ではビジネス部門とIT部門の連携が重要

この記事の著者

関連記事

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

社内標準化ではビジネス部門とIT部門の連携が重要

この記事の著者

関連記事

IT部門の「最後の1人」になっても業務効率を維持するには

次世代クライアントOS／Office導入を考える

ITマネジャーが意識すべき予算編成健全化への5つのポイント

現場の抵抗勢力も納得する「ツール導入術」

現場で使われない開発標準―その理由を尋ねてみると……

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓