Computer Weekly製品ガイド

「ITのクロックアップ」の鍵はアジャイルではなくアダプティブIT

経営陣からの、ITプロジェクト加速を求めるプレッシャーが強まっている。容認できないリスクを犯すことなくそれを実現する方法について解説する。

　企業はIT管理の方法を根本から見直す必要がある。新技術をいかに速く導入できるのかは、経営にかかわる問題になった。

　業界横断的な経営者団体CEB（旧Corporate Executive Board）がビジネスリーダー3000人を対象に実施した調査では、3分の1以上が最優先課題として製品やサービスの開発、新市場への参入、規制コンプライアンスを挙げた。

　IT部門は、そうした要求にいかに速く対応できるかが問われていると、CEBのマネージングディレクター、アンドルー・ホーン氏は話す。

　「組織がいかに速く変化できるかを最大の懸念に挙げるCEOが増えている。そのペースを鈍らせるのも、加速する助けになるのもテクノロジーだ」。ホーン氏はComputer Weeklyにそう語った。

　CEBによれば、従来のようなIT管理方法では現代のビジネスニーズに対応できない。長期に及ぶ開発サイクルから、ペースの速い短期間の開発を支持するアジャイルプログラミングへ移行したとしても、それだけでは企業が必要なレベルに到達することはできない。

ITがペースを速めるべき理由

　IT部門は常に、ビジネスニーズに対応するペースを速めるようプレッシャーをかけられてきた。10～15年前には、ITシステムを標準化して開発時間を削減するアイデアがヒットした。部門ごとに複数種類のERPを導入するよりも、組織全体を横断する単一のERPを導入する方がはるかに理にかなっていた。

　ホーン氏によると、当時のCIO（最高情報責任者）はそれでうまくいっていた。だがクラウドコンピューティングやデータ分析、モバイル技術が台頭すると、IT部門は経営陣の要求に追い付くことができなくなった。

　「現在は非常に競争が激しい環境になった。社内にはレガシーシステムとビッグデータ、分析ツール、顧客のための技術が存在している。それらを標準化することも、グローバル化することもできない」とホーン氏は言う。

　企業はこの状況を認識し、スピードに関する2つのアプローチを採用するようになった。IT部門内に専従チームを設けて、急ぎのプロジェクトに専念させている。この高速チーム（別名「タイガーチーム」）はイノベーションに照準を絞り、アジャイルプログラミングを使って実験的な先端プロジェクトの開発に当たる。

　CEBの調査では、このアイデアがある程度うまくいっていることが分かった。だが約15％を超すプロジェクトが高速チームに割り当てられると、生産性は急激に悪化し始める。

　「タイガーチームは優秀な人材で構成されており、迅速に成果を出す。このチームは華やかで、経営上層部からも絶賛される」。CEB米IT部門のマネージングディレクター、ジェイミー・キャペラ氏は、2015年10月に開かれたCIOのためのマスタークラスでそう語った。「そして次に絶望の谷に突き当たる」

　タイガーチームは単独では機能しない。プロジェクトを進めるために低速チームのIT担当者の助けを借り、アジャイルを採用していない社内の他の部門と連携する必用がある。作業負担が臨界点に達すると、高速チームは組織全体の惰性に足を取られるようになる。

　別の問題もある。キャペラ氏が指摘するように、野心的なITプロフェッショナルなら、低速チームで働きたいとは思わない。「高速チームが組織され、クールな名称が与えられ、新しいオフィスに配置される。そうなれば低速チームの誰もが高速チームに入りたいと思う。そこから士気の問題が生じる」（キャペラ氏）

　組織はこれまでに、IT需要の変化への対応を加速させるため、2つの変化の波を切り抜けてきた。そして今、「アダプティブIT」という3つ目の変化が浮上している。

　この答えは、複雑性が増す環境から浮上したものだ。もし必要があれば組織全体で迅速にプロジェクトに対応できる。CEBのホーン氏はこれを「ITのクロック周波数向上」と表現した。

　ITチームは各プロジェクトのニーズに応じて、作業のペースを速めたり落としたりする。この2つの働き方を切り替えることへの満足感は高い。

　ホーン氏は、「チームはそのときの状況に応じて、速度が最も重要かどうかを判断できる。そしてそれをコストや信頼性と照らし合わせる」と解説する。

　アダプティブIT部門の構築は難しく、CIOはIT部門の運営方法や他部門との関係について根本から考え直すことを求められる。

　CEBが発表した調査では、組織の6％はその切り替えを行い、29％は実現に向け積極的な動きに出ている。

コミュニケーションのボトルネック排除

　企業は、開発サイクルを妨げている障害を見つけることで最も大きな進歩を得る。一般的には、アジャイルITチームが組織の他の部門と衝突すると、障害が発生する。「スケジュールの食い違いが問題になることもある。ITチームは次の週にアーキテクチャを決める必要があるのに、アーキテクチャチームは月に1回しかミーティングを開かない。あるいは、至急リスク検証を行う必要があるのに、組織内にリスク検証のできる人物が1人しかいない」といった事例をホーン氏は挙げる。

　次のステップとして、形式主義は最低限に抑える。ITは極端なプロセス指向になり、ITILやアジャイル開発といった手法が流行している。「良い意味で、これはIT部門がコントロールを保つ助けになる」とホーン氏は話している。

　だが実際のところ、CIOはどの程度プロセスを必要としているのか。アダプティブ企業は、思ったよりもずっと少ないプロセスでやっていけることが分かっている。そうした企業は合理化されたプロセスをデフォルトとする。もし開発者がもっと厳格なプロセスを求めれば、その費用対効果について論議しなければならない。

CIOがペースを速めるために

この記事の著者

関連記事

• 

  もっと速く、もっと小さく、もっと安く──2016年注目のフラッシュテクノロジー

• 

  1150万文書から関係性を洗い出せ――「パナマ文書」解析プロジェクトの舞台裏