Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
78 lines (44 sloc) 6.12 KB
title tags
顧客親近性
agile
team organization
requirements analysis

http://www.martinfowler.com/bliki/CustomerAffinity.html

トップクラスのエンタープライズソフトウェア開発者になるために必要なものは何かという話になると、だいたいフレームワークや言語の知識や複雑なアルゴリズムやデータ構造を理解する能力だろうという方向に話が進む。 だが、プログラマや開発チームにとって最も重要なのは、私が「顧客親近性」と呼んでいるものだ。 これは、ソフトウェアが対処すべきビジネスの問題、そして、そのビジネスの世界に生きている人々に対する関心および親密さを表すものである。

顧客親近性には様々な側面がある。 まずは、ビジネスへの関心である。ビジネスのプロセス、そしてビジネスルールへの関心だ。 私はこれまでに携わってきたドメイン——医療、金融派生商品、給与管理、リース業務——に常に魅了されてきた。これらは非常に興味深いドメイン問題の例である。いずれも整理し理解しなければならない複雑さを多数抱えたものだった。 ORマッピングやリモートプロセス通信といったプロジェクトの側面——私はこれらをエンタープライズシステムの配管作業と呼んでいる——には同様の面白さはない。

もちろん、配管工事をきちんと行うことはチームにとって重要なことだ。 しかし私は、ビジネス問題により多くのエネルギーを注げばより効果的にチームが価値を提供できると信じている。 だからこそ、配管工事をできるだけ簡単に解決するためにフレームワークを使用するのだ。

顧客親近性のもうひとつの側面は、ドメイン専門家とのコラボレーション能力である。 私はプログラマが詳細なドメイン知識を身に着けている必要はないと思っている(もちろん有用なことではある。しかし、重要なことではない)。 知識よりも重要なのは、その知識を持った人とコラボレーションできるかどうかだ。

顧客親近性を重要視しているからこそ、私はエクストリームプログラミングやアジャイル方法論のファンなのだ。 「アジャイル」を生み出したSnowbirdでのワークショップにおいて、Kent Beckがアジャイル仲間たちにXPについて簡単に説明したとき、彼はXPの技術的要素ではなく、顧客と開発者の相互関係のあり方を変えたいという願いについて説明した。私は、これは特筆すべきことだと思っている。

この両者の関係付けが誤っていることが多いようだ。 特に、顧客チームは開発者にストーリーを提出しさえすればよいと信じているところがあるようだ。この関係付けは、要求というものはそこらに転がっており、集めさえすればよいという考えなのだろう。 いずれにせよ、これはコラボレーションではない。 開発者はドメインに携わる人間と一緒になってアイデアを創出していく必要がある。 開発者はこの過程を通して、ビジネスについての理解を深めていくのだ。

Kentが「アジャイル」以外に提案した名前は「対話型(conversational)」ソフトウェア開発だった——双方向のコミュニケーションであるところがポイントだ。 テレコムプロトコルのように定義されたものではないが、どうすればソフトウェアがビジネス価値を高められるかを両者で何度も議論を繰り返すことには、真の価値がある。 この対話は生焼けのアイデアかもしれない。 しかし、その中から価値のある機能が育っていくのだ——顧客が考えてもいなかったものが出てくることがよくある。

組織がこの顧客親近性を鎮圧しようとすることがよくあり、 私はいつもイラっとするのだが、これは認める認めないの話ではなく、 他の決定による結果として出てくるものなのだ。 組織的な障壁が鎮圧を助長していることもある——ちょっと他部署の人間と会話をするためだけに、自分のマネージャに頼んでその部署のマネージャと調整してもらわなければならないようなケースを見たことがある。 そのような状況では、ビジネスの内側に入っていくことなどできやしない。

エンタープライズソフトウェアはデータをこねくり回しているだけで退屈であるとか、才能のある人間は複雑なアルゴリズム、ハードウェアハック、膨大な計算量などが必要とされる「本物の」ソフトウェアを作る、などといった話をよく耳にする。 だがそれは、顧客親近性が欠如しているからではないかと思う。 ビジネスソフトウェアの真の知的挑戦とは、ソフトウェアがビジネスにとってどのように貢献できるかを見つけ出すことである。 そのためには技術スキルとビジネス知識の両方が必要となる。 ビジネス側の人間と密接に仕事をすることでビジネス知識を高めていき、 また同時に、顧客満足を目指していく。 これこそがエンタープライズソフトウェアの楽しみである——そしてこれが、よい製品を作り出すための鍵となるモチベーションになる。

自分の作っているソフトウェアが対象とするビジネスについて学びたいと考えている優秀で能力のある人間は数多く存在する。 だが、組織によってそれが難しくなっていることが多々ある。 そういった状況が変わるまで、我々の業種はポテンシャルを発揮できないままだろう。

You can’t perform that action at this time.