顧客親和性

一流のエンタープライズソフトウェア開発者を構成する要素を検討する際、話題はフレームワークや言語の知識、あるいは複雑なアルゴリズムやデータ構造を理解する能力に及ぶことが多いでしょう。私にとって、プログラマー、あるいは開発チームにとって最も重要な特性の一つは、「顧客親和性」と呼ぶものです。これは、ソフトウェアが対応するビジネス上の問題、そしてそのビジネスの世界に生きる人々に対する開発者の関心と親密さのことです。

顧客親和性には多くの側面があります。まず一つ目は、ビジネス、そのプロセス、規則への関心です。私はこれまで、ヘルスケア、デリバティブ、給与計算、リースなど、仕事で関わってきた分野に常に魅了されてきました。これらはすべて、組織化し理解する必要がある、非常に複雑なドメインの問題の例です。私にとって、オブジェクトリレーショナルマッピングやリモートプロセス通信など、エンタープライズシステムの配管と考える側面には、同じような興味はありません。

チームが配管を機能させ、制御下に置くことは重要ですが、ビジネス上の問題により多くのエネルギーを注ぐほど、チームはより効果的に価値を提供できると信じています。これは、可能な限り配管を解決し、簡素化するフレームワークを使用する良い理由です。

顧客親和性のもう一つの側面は、ドメインエキスパートと協力する能力です。ドメインに関する詳細な知識がプログラマーにとって重要なことだとは思いません。役には立ちますが、重要ではありません。知識よりも重要なのは、知識を持つ人々と協力する能力です。

顧客親和性を高く評価していることが、私がエクストリームプログラミングや他のアジャイル手法を強く支持する主な理由の一つです。ケント・ベックが「アジャイル」という言葉を生み出したスノーバードワークショップで、XPをアジャイルの仲間に要約した際、XPの技術的な要素ではなく、顧客と開発者の相互作用の性質を変えたいという彼の願望を述べたことは、非常に重要でした。

私はこの関係が誤って伝えられているのをよく耳にします。特に、顧客チームが開発者に投げつけるだけのストーリーを思いつくだけであるという考えが一部にあります。この特徴づけは、要件が収集されるのを待っているだけであるという概念によく似ています。どちらにしても、それはあまり協力とは言えません。そうではなく、開発者はドメインの人々と協力してアイデアを生み出し、その過程でビジネスについて多くのことを学ぶ必要があります。

ケントが「アジャイル」に提案した名前の一つは「会話型」ソフトウェア開発でした。重要なのは、それが双方向のコミュニケーションであるということです。これは定義できるテレコムプロトコルのようなものではなく、ソフトウェアがどのようにビジネスを強化できるかについての活発な議論こそが、真の価値が存在する場所です。この会話の多くは、未熟なアイデアであり、そのいくつかは価値のある機能に成長します。多くの場合、それは顧客が当初考えたものではありません。

私が不満に思うことの一つは、組織が顧客親和性を抑えようとすることが多いということです。人々がそうすることを認めませんが、他の決定の一般的な結果です。組織的な障壁は、抑制に寄与する可能性があります。ビジネス側の誰かと会話するためだけに、マネージャーに別のマネージャーと手配してもらう必要があるような場所に出会ったことがあります。それでは、ビジネスの仕組みを理解することをあまり奨励できません。

エンタープライズソフトウェアは退屈で、単にデータをシャッフルするだけであり、才能のある人々は、派手なアルゴリズム、ハードウェアハック、または多くの数学を必要とする「本物の」ソフトウェアを作成するとよく言われます。これは通常、顧客親和性の欠如が原因だと感じています。ビジネスソフトウェアの真の知的挑戦は、ソフトウェアがビジネスに実際に貢献できるものを理解することです。それを見つけるには、優れた技術的知識とビジネス知識の両方が必要です。ビジネスの人々と緊密に協力してこの知識を開発し、それを行う際に顧客を喜ばせることは、エンタープライズソフトウェア開発を楽しいものにします。そして、モチベーションは、優れた生産的な仕事をするための鍵です。

自分たちがソフトウェアを作成するビジネスについて学びたいと思っている、優秀で有能な人々はたくさんいます。組織は、彼らがそうすることを困難にすることが多すぎます。それが変わるまで、私たちの職業は、その可能性を十分に発揮することができないでしょう。

2012年4月26日に再投稿