ユーティリティと戦略の二分法

私のキャリアを通じて一貫して見てきたテーマの一つは、ソフトウェア開発の性質と重要性です。数年前、見込み客が営業担当者に「ソフトウェアは下水管のようなもので、確実に動作してほしいし、詳細を知りたくない」と言いました。これは、ニコラス・カーが「ITは重要ではない」で語ったアプローチです。[1]対照的に、ITがビジネスにとって明確な戦略的イネーブラーであり、新しい市場への参入や市場シェアの大幅な増加を可能にしている多くの企業のために仕事をしてきました。では、ITは下水管のようなユーティリティなのでしょうか、それとも戦略的資産なのでしょうか？

私は、システムによってどちらにもなり得ると考えています。ユーティリティITの古典的な例は給与計算です。誰もが必要としますが、ほとんどの人が「ただ動作する」ことを望んでいます。

では、ユーティリティプロジェクトと戦略的プロジェクトを区別する要因は何でしょうか？私の考えでは、それは根底にあるビジネス機能が差別化要因であるかどうかです。この機能をどのように実行するかが、競合他社よりも優れているための重要な要素である場合、この機能をサポートするソフトウェアは、可能な限り優れたものにする必要があります。ロス・ペティットが述べているように「これはテクノロジーの性質によるITの分離ではなく、テクノロジーがホストビジネスのために何をするかによる分離です。」

この二分法に関する最も重要な点は、ソフトウェアプロジェクトには2種類あり、それらはまったく異なる扱いが必要であることを認識することです。戦略的取り組みの人員配置、運営、予算編成の方法は、ユーティリティプロジェクトの方法とはまったく異なります。あまりにも多くの場合、人々は一方に良いことが他方にも良いと仮定し、必然的にトラブルが発生します。

もう1つの結果は、戦略的なプロジェクトはごくわずかであるということです。80/20の法則が当てはまりますが、実際には95/5に近いかもしれません。確かに、二分法をまったく認識しないことが最も一般的ですが、あまりにも多くのプロジェクトが戦略的であると考えることも一般的です。

これらの取り組みが異なる最も重要な点の1つは、リスクがどこにあるかです。ユーティリティプロジェクトの場合、最大のリスクは、何らかの壊滅的なエラーです。下水管が壊れたり、給与の支払いを忘れたりしないようにする必要があります。したがって、それが起こらないように十分な注意を払う必要がありますが、それ以外の場合はコストを可能な限り低く抑えたいと考えています。しかし、戦略的プロジェクトでは、最大のリスクは競合他社よりも先に何かを実行しないことです。そのため、迅速に対応できる必要があります。コストは、何かを実行しないことによる機会費用がソフトウェア開発自体のコストよりもはるかに大きいため、それほど問題ではありません。

これは静的な二分法ではありません。戦略的なビジネス活動は、時間の経過とともにユーティリティになる可能性があります。企業がその活動を差別化要因にする方法を見つけた場合、ユーティリティが戦略的になる可能性は低くなります。（Appleは、パーソナルコンピュータの設計でこのようなことを行いました。）

この二分法が役立つ1つの方法は、カスタムソフトウェアを構築するか、パッケージをインストールするかを決定する際に役立つということです。ユーティリティの定義は差別化要因がないことであるため、明白なことはパッケージを使用することです。戦略的な機能の場合、競合他社と同じソフトウェアは、差別化する能力を損なうため、使用したくありません。

多くの場合、人々はこれを認識し、ユーティリティ機能のためにパッケージを購入しますが、その後、このパッケージをカスタマイズするために巨額の費用を費やします。これは同じように無駄です。私の見解では、ユーティリティ機能の場合、パッケージを購入し、ソフトウェアに合わせてビジネスプロセスを調整します。通常、これは政治的に実行不可能であるため、回避策は低レベルのソフトウェアチームに作業させることです。大惨事を回避するために十分な注意を払いますが、それ以外の場合は、ハイグレードなチームは必要ありません。

この二分法が影響を与えるもう1つの方法は、アジャイル手法の役割です。ほとんどのアジャリストは戦略的な考え方をする傾向があり、アジャイルの特徴である柔軟性と迅速な市場投入は、戦略的なプロジェクトにとって不可欠です。しかし、ユーティリティプロジェクトの場合、アジャイルの利点はそれほど重要ではありません。ユーティリティ機能にアジャイルアプローチを使用することが間違った選択になるかどうかはわかりませんが、それほど重要ではないことは確かです。

多くの分類と同様に、その間には多くのグレーゾーンがあります。しかし、これは、コントラストを高めて、より二元的な考え方を強いる強力な議論があると思う珍しいケースの1つです。ロスがこの投稿の草案に関する議論でコメントしたように、「『グレーゾーン』は、物事を間違ったカテゴリに積み上げる許可を与えます。本当にユーティリティであるものが、実際にそうであるユーティリティとして処分されるのではなく、過度に重要視されます。」戦略的バケットに入れるものを最小限に抑えるために傾いた二元的な決定を強制することは、ITイニシアチブでしばしば欠けている焦点を提供するのに役立ちます。

ロスは、ユーティリティと戦略的な作業の両方を担当する単一のIT部門があってはならないと主張するほどです。2つに必要な考え方と管理態度はあまりにも異なっています。まるで、倉庫を設計するのと同じ人に美術館を設計することを期待するようなものです。

バイモーダルIT

最近、いくつかのコンサルティング会社がバイモーダルIT（またはツースピードIT）の概念を普及させています。[2]一見すると、これはユーティリティ/戦略の二分法と同じように見えますが、実際にはまったく異なる概念です。バイモーダルITは、間違った方向に向かう道でもあります。

最初の違いは、バイモーダルITが、根底にあるビジネス活動ではなく、レイヤーによるITシステムの分離に基づいていることです。バイモーダルITは、動きの速いフロントエンドのエンゲージメントシステムを、遅いが信頼性の高いバックエンドの記録システムから分離します。しかし、戦略的なビジネス機能で迅速にイノベーションを起こそうとする場合、通常はフロントエンドとバックエンドの両方のシステムで迅速な変更が必要になります。

バイモーダルITに関する私の2番目の不満は、分離の推進理由が、急速に変化するエンゲージメントシステムが本質的に欠陥でいっぱいであり、速度を上げるためにこれらの欠陥を容認するという考えであることです。しかし、Thoughtworksやその他の主要なアジャイル組織での10年以上の経験から、このトレード可能な品質仮説は誤ったトレードオフであることがわかります。通常、迅速なサイクルタイムでアジャイルアプローチを導入すると、生産上の欠陥が桁違いに減少することがわかります。実際、このように欠陥を減らさなければ、それほど迅速にサイクルすることはできません。高品質（および低欠陥）は、迅速なサイクルタイムにとって不可欠なイネーブラーです。

さらに探求するには...

• ロスの記事は、IT部門のグラス・スティーガル法を求めています。
• マーク・マクニールは、プロジェクトをトラクター、原子力発電所、最先端として語っています。
• ニール・フォードは、SOAなどの統合の取り組みは、戦略的になることはできないと指摘しています。
• ジェズ・ハンブルは、バイモーダルITモデルの3つの欠陥を説明しています。