この記事に新しい情報はない。魔法の答えもない。ただ、私たちがすでに知っていることを改めて確認するだけだ。

前提を整理すると、この記事でのITとは、サービスプロバイダーやコンサルタントではなく、組織内部の機能を指す。そして成功とは、ITが客観的にも主観的にもバリューセンターとして認識され、競争優位として活用される状態だ。そのために必要なのは、組織の能力を高め、無駄な作業をなくすことだ。それ以外はすべて余分なコストに過ぎない。

卓越したITチームは、何年も先を行き、課題を楽しみ、問題をイノベーションの機会と捉える。リソースは限られているのに、プレッシャーや重荷を感じていない。そして、何か特別なことをやろうとせず、理になかったことをしている。

「バリューファースト」「シンプルに」「フィードバックで改善」——こうした理念に反対するITチームはないだろう。しかし成功するITチームは、これらが深い原則から自然に生まれてくる。

以下に、卓越したITチームに共通する原則をまとめる。

1. 顧客ではなく同僚の関係
   ITILやアジャイル、COBITは「提供者と顧客」モデルに基づいている。外部のサービスプロバイダーには適しているが、社内のITに当てはめると弊害が出る。取引的な思考に縛られ、チャージバックなどの仕組みが戦略に取って代わる。結果として、サイロ化、資金の断片化、優先順位のズレが生じる。

   組織内の人々は同僚だ。同じミッション、同じ目標を持つ。取引的な関係より、相談型の関係の方が本当のバリューを生む。「このプロセスを変えてみてはどうか」——そういう会話こそ、ITが積極的に持つべき対話だ。

2. ビジネスの現場に近くいる
   ITは組織のプロダクトに近い場所にいて、文脈の中で意思決定することが重要だ。放っておくと、依頼や指示を待つだけのコストセンターになりがちだ。

   コストセンターではなくバリューセンターとして機能するITチームは、受け身ではなく自ら積極的に関与する。専門知識を発揮し、ニーズを先読みし、見えない課題を先手を打って解決する。指標だけに依存すると、ITは指標を満たすことに特化してしまう。数千ドルを節約するために数百万ドルの機会を逃すことは珍しくない。何を測るかが、チームの行動を決める。戦略的な貢献より効率指標が優先されれば、チームはやがて戦略への関与をやめてしまう。

3. 管理職による監督より、現場のリーダーシップを重視する
   技術チームは最小限の監督で自己組織化して働ける。一方、日々の判断を要するシステム、プロセス、依存関係の量は膨大だ。大きな階層型組織はこのスピードとスケールに対応しにくい。

   人が増えるほど適切な場所に配置されにくくなり、バックログが積み上がり、技術的負債が蓄積し、やがて組織図が変わる——そしてサイクルが繰り返される。

   成功するITチームは、マネジメントの機能を広く分散させる。全員が戦略に貢献することを促されるが、誰もそれだけに専念しない。リーダーシップは役職ではなく、判断と行動で価値を生み続ける人から自然に生まれる。

4. コンパクトで機能横断的なチーム
   ITチームはスケールが難しい。平均的なフルサービスのIT部門は20〜100人の間に効率のピークがあり、それを超えると効率が落ちる傾向がある。20人のチームでは全員が何かを担わなければならない。所有意識がリーダーシップを育て、協働を促す。全員が何かを担い、全員が協働すれば、20人が100人分の仕事をこなせる。しかし100人を超えると、伝統的な組織思考が支配し、専門性がサイロ化し、所有意識が薄れていく。

   本質はサイズではなく協働だ。小さなチームでは協働が自然に生まれるが、大きなチームでは設計によって意図的に協業の状態を生み出す必要がある。機能横断性（クロスファンクショナリティ）は、小さなチームの協働的な性質を、スピードとスケールで再現する手段だ。専門知識をポータブルにし、許可や調整を待たずに良い意思決定を下せるようにする。依存関係はリスクを増やす。機能横断チームはこうした協調コストを削減し、システムをより速く、より安定させる。

5. ベンダーとの関係では独自性を大切に
   ベンダーへの依存は、自社の戦略を他人のロードマップや障害に縛りつけるリスクがある。完全な独立は現実的ではないが、重要な依存関係を形成する際には出口戦略を持つことが賢明だ。

   成功するチームはベンダーを基盤ではなくアクセラレーターとして扱う。モジュール性と柔軟性を重視し、ベンダーに問題が起きても業務を継続できる体制を設計の段階から作っている。自社独自の強みを守ることが、組織の競争優位につながる。

6. 設計でリードする
   「正しいことを簡単なことにする」——これは成功するガバナンスの発想だ。「最良の仕事は誰もしなくていい仕事だ」——これは成功する自動化の発想だ。「最良のサポートは誰も電話したくないが電話したくなるもの」——これは成功するサービスの発想だ。

   これらは別々の問題に見えるかもしれないが、成功するITチームにとっては同じ規律、つまり設計の表れだ。設計はITにおける最も重要なマネジメントの仕事だ。良いトラブルシューティングは1つの問題を解決するが、良い設計は同種の問題が起きる前に解決する。成功するチームは症状ではなく、システムそのものを修正することに注力する。

卓越したITは「ただ機能する」

ITがコストセンターと見なされがちなのは、かつて組織のオーバーヘッドだったものの名残があるからだ。タイプライターやバインダーはコンピューターやサブスクリプションに変わったが、認識は変わっていない。

ここで紹介した原則はすべて、ITをオーバーヘッドではなく価値の源泉にするためにある。同僚として関わることで無駄な摩擦がなくなり、機能横断性が協調コストを下げ、ビジネスに近くいることが努力を優位性に変え、分散されたリーダーシップが組織の推進力を高め、良い設計が問題を未然に防ぐ。

最も成功するITチームは外から見ると地味だ。穏やかで、静かで、派手な指標では測りにくい。しかし組織が競合にできないことを、より速く実現できるよう支えている。「ただ機能する」——それが彼らの自然な状態だ。特別なトリックはない。必要なのは、すでに知っているやり方を実践することだけだ。