私はずっとソフトウェア開発者だった訳ではありません。私がThoughtWorksに加わる2年前、私は主にポーカーをプレイする事で生計を立てていました。もちろん、腕にあるタトゥーについて私に尋ねた事があるなら、あなたはこの物語について既にお聞き及びの事でしょう。まだ聞いた事がないのなら、次の機会に一緒にお酒でも飲みながら、気軽に私に尋ねてください。
私は、ポーカーに多くの時間を費やした事を後悔した事はありません。ポーカーは他のトピックにも広く適用できるような数少ない教えを私にもたらしてくれたと信じています。実際私はソフトウェアを開発すればするほど、これら二つの仕事は非常に似ていると言う確信の度合いを深めています。
学ぶ
私はソフトウェア開発を学ぶためのアプローチと同じようにポーカーを学びました: 出来る限り多くの書籍を読むのです。2年以上を書けて、私は自分が見つけ得るすべてのポーカーに関する本を読みました。39冊で数えるのを辞めてしまいました。もちろん、プログラミングに関しても同じ事が言えます。私の目の前には今5冊の本がありますが、これは次に読むためキューに追加されたものです。そして、私は膨大な本のコレクションを持っています。それは私がThoughtWorksに居た3年間の間に読み終えたものです。
.私は本やブログ、雑誌を読む事は、プログラミングやポーカーにとっての本質だと考えています。しかしどちらの職業も、本を読むだけでは十分ではありません。あなたは全ての知識を頭の中におさめる事が出来るでしょう。しかし、どのルールをいつ適用すべきかを知る事こそが、真のプロフェッショナルのあかしなのです。
文章を読む事は学習のために非常に役立ちますが、特定のテクニックをいつ適用するかを決めるのは、ほとんどいつもコンテキスト次第です。本は、あり得る全てのコンテキストを十分に提供する事が出来ません。そのため経験のみが、あなたやあなたの雇用主にとって数千から数十万ドルものコストとなる決断を、素早く下せるような能力をあなたにもたらします。
経験に勝るものは存在しないのです。
高いレベルにおける芸術性
あなたは、平均的なポーカーのプレイヤーを打ち負かすようなコンピュータプログラムを設計する事は出来ます。基本的なルールに従えば、あなたの勝利は保証されます。しかし今日に至るまで、最高のポーカープレイヤーを打ち負かせるようなプログラムは存在しません。これは、高いレベルのポーカーは芸術に等しいからです。もちろん、ソフトウェア開発についても同じ事が言えます。平均的な開発者になるためには、ベストプラクティスのカタログさえあれば十分です。そのクックブックに従えば、平均的なアプリケーションを作れる事がほぼ保証されます。正直なところ、その平均的なアプリケーションと言うのは、ほとんどの場合一般的なものよりも優れています。多くのプロジェクトは失敗に終わっており、多くのマネージャーは、平均的なアプリケーションに対して喜んでお金を支払うのではないかと私は信じています。
.もちろん、より高い基準を設けるマネージャーも居ます。銀行やスタートアップ企業、医療システムなどでは、より高いレベルの利害が存在します。平均的では十分ではありません。こうしたシステムのマネージャーは、ベストなものに対しては喜んでお金を支払い、より高いレベルのスキルを期待します。問題なのは、開発のエキスパートは、平均的な開発者とは異なるスキルセットを持っていると言う事です。平均的な開発者は「何か」を行うための方法を知っていますが、エキスパートは「何か」を行うための理由を知っています。平均的な開発者はクックブックのようなパターン本に従いますが、エキスパートは、パターンを革新すればパフォーマンスを指数関数的に向上できると言う事を理解しています。
このように、エキスパートは異なる視点から世界を見ているので、平均的な開発者がエキスパートと対等に話し合うのは難しいでしょう。美術評論家になるのは簡単ですが、良い美術評論家になるのは非常に難しいのです。
スキルをジャッジする
ポーカーとプログラミングの両方において、絶対に正しい事が一つあります: 自分で考えている程優秀な人は、恐らく誰一人いないと言う事です。自分で考えている程優秀ではない事を知るのが最初の良い一歩ですが、エキスパートたちがどれくらい優秀なのかを知るのは難しいです。スキルレベルを公平にジャッジできるほど、プログラマがエキスパートに十分接している事はほとんどありません。ポーカーのテーブルにおいては、全員がトーナメントに参加していますが、多くの人々が自分の能力にいかに高く賭けるかについて、私はいつも非常に驚いていました。
.同じ事はプログラマたちにも言えますが、彼らのほとんどは情報が不足しています。カンファレンスに参加した事のない技術リーダーは、彼のチームメンバーを彼自身と比較します。もちろん彼は技術のリーダーなので、彼が最高のスキルを持っていると言う可能性は高いです。しかし業界にいる他の才能ある人のレベルと比べると、彼はどこら辺に位置しているのでしょう？もし彼が、自分の中では最高の位置に居ると信じているならば、異なる意見を持つ誰かにであったときに何が起きるでしょうか？学んで自分が成長できるかもしれない事に興奮を覚える人も居るでしょうが、ほとんどの人はおろかにも相反するアイデアを却下してしまうのです。
チームワーク
無頓着な観衆にとってのポーカーは、全員が全員を相手にするゲームのように見えます。実際は、そうしたケースはほとんどありません。普通は掛け金の低いテーブルでさえも、お互いの事を知っている人間が少しは居るものです。こうした知り合い同氏は、テーブルについた他の人を仲間に率いれようと取引をしようとはしませんし、そうする必要もありません。良いプレイヤーを相手にしてお金を儲ける事は出来ないと言う事、腕の低いプレイヤーからお金を儲ける事は当たり前の事です。プロのポーカープレイヤーでさえも、チームとして作業します。それぞれのチームメンバーには自分の取り分があり、彼らのうちの誰かが勝てば、彼ら全員が勝った事になります。彼らは、お互いを知るだけでとどまる事はありません。彼らは全ての人間を知っています。フロアマネージャは、良いゲームが行われているときに彼らを呼び出すでしょう。ウェイトレスは、彼らの対戦相手に対してアルコール度数の強いドリンクを作るでしょう。ディーラーは、"誤って"特定のプレイヤーのカードをひっくり返してしまいます（ひっくり返されたプレイヤーが好勝負を行えるのはまれです）。全員が、お金を稼ごうと一丸となって努力します。
興味深い事に、プログラミングもこれに似ています。多くのプログラマがそれぞれバラバラに区分けされ、全ての問題に対して自身で格闘しています。こうしたプログラマーは、しばしば強いコード所有モデルに従って作業を行います。こうした開発者たちがアプリケーションを作り上げても、その統合にいつも苦労するのを私は見てきました。あいにく統合の苦労など、問題の中でも最も小さなものである事がしばしばです。業務を500ページの要求仕様書にまとめているIT部門を考えてみてください。もしビジネスの方向性を変える必要が生じた場合、システムにとってはあまりにつらい変更要求がしばしばなされます。ビジネスがもはや必要としていない機能を構築するために数百万ドルがプログラマによって無駄にされますが、IT部門は業務を扱うためのより良い方法を見つける事が出来ないのです。
もちろん、このようにしなくてはならないと言う訳ではありません。エキスパートは協力し合います。エキスパートは他のエキスパート開発者とだけではなく、彼らのマネージャー、顧客、業務アナリスト、品質保証部隊、そして彼らの成功に寄与するあらゆる個人と協力します。エキスパートは、より大きな目標を理解しています: 協力し合う事で、全員がお金を儲ける事に繋がるのです。
評価指標
向上心に燃えるポーカープレイヤーは、しばしば彼らが勝った、もしくは負けた手について話します。ほとんどの場合は、彼らは勝てるはずだったのに負けてしまった手について話します。ミスをして負けてしまうことも時々あるのですが、彼らはそうした手については普通覚えていません。逆に、彼らが単に不運だったため失ってしまった手については、いちいち細かくすべてを覚えているようです。こうした話には、彼らの相手が勝ったであろうチャンスの割合も含まれています。ポーカープレイヤーはどれほど多くの手を彼らが失ったか、そしてチャンスを失う事になった原因は何かについて知っているものです。ポーカープレイヤーは、評価指標を知っているのです。しかしプロフェッショナルなポーカープレイヤーは、問題となる評価指標のどこにフォーカスすべきかを知っています。それは勝ち負けの手の数ではなく、勝ち負けの金額です。さらに、ひどく負けてしまう事への心配をうまく変換して、対戦相手の能力が「きちんと不足しているかどうか」を心配するのです。なぜなら対戦相手のミスからあなたは利益を得るからです。本質的にあなたは、対戦相手がお金を自分によこさない事について不平を言っているのです。
評価指標を持つ事は良い事です。しかし、プロフェッショナルはどの評価指標が重要なのか、どれが単なるノイズなのか、どれがその中間に位置しているのかを知っています。
ソフトウェア開発も数多くの評価指標を含んでおり、それらは注目を浴びすぎています。例えばコードの行数を知る事から、多くの価値を得る事は非常に困難です。複雑なアプリケーションは相応の量のコードを必要としますが、そもそも何が相応なのでしょうか？それは言語やツール、その他数多くの要素に依存します。
バグフィックスの数もまた、あまり興味深い指標ではありません。なぜ、フィックスされたバグの数が問題になるのでしょうか？バグの数には価値があるかも知れませんが、どれだけの数がフィックスされたかを知っても、私たちにはさほど意味がありません。
.私のお気に入りは、機能がいくつ完成したかを表すパーセンテージです。機能の実現に必要とされる労力が見積もられていなければ、完成した機能の数には大した意味がありません。そして、必要とされる労力がすでに測定できているのなら、未完了の事柄に費やす労力と、完了済みの事柄に費やされた労力を測定して、進捗を量ろうとしないのはなぜなんでしょうか？完成した機能の割合から何かの価値を見いだすのは、私にとっては困難です。
コードカバレッジは、ひどい負けを記録する事を私に思い出させる指標です。指標に価値はありますが、ほとんどの人々はポイントを間違っています。コードカバレッジが低い事は、恐らくあなたが問題を抱えている事を意味しますが、高いコードカバレッジは、あなたが高いコードカバレッジを獲得したと言う以上の意味はありません。高いコードカバレッジは、高い品質に寄与しません。
ロジックではなく人間
もしあなたがポーカーをしている映画を何かしら見た事があるのなら、あなたはこのような台詞を聴いた事があるでしょう: カードをプレイするんじゃない、人間をプレイするのだ。これは非常に正しい事です。ポーカーは信じられないほど心理的なゲームです。もちろんあなたはカードにいくらか時間を必要としますが、良いカードを得る事は、単にお金稼ぎの一部なのです。一度あなたがよいカードを手にしたら、それらをどう扱うべきかを知る必要があります。レイズすべきか、チェックしてレイズすべきか、単にチェックやコールをすべきか。こうした選択は多くの要因に依存していますが、中心的な要因となるのは、対戦相手を知る事です。良いカードを手にしたときに一番のゴールとすべきは、それらから出来る限り多くのお金を生み出す事であり、どうやってより多くのお金を得るかを知る唯一の方法は、どんなアクションをとれば対戦相手がより多くのお金をくれるかを知る事です。ロジックはあなたの手が勝つ助けになり、人を知る事はお金を勝ち取る助けになります。
人は、ソフトウェアをリリースする上でも同様に重要です。ソフトウェアが単純に物事をうまく運ばせるためのものであるなら、自動化するのはより簡単です。しかし、ソフトウェアは機能の集まりを超えたものです。ゴルフゲームを売り上げるソフトウェアパッケージに関するものです。ディズニーランドへの招待旅行中の家族に、サインしてもらった契約に関するものです。訴訟を再度起こされないようにするため、もはや必要とされないソフトウェアの契約を履行する事に関するものです。競争相手よりも速い速度で、変化を必要とするビジネスに関するものです。
ソフトウェア開発は、ソフトウェアの一部に何らかの形で依存したり、ソフトウェアを使ったり、開発したり、保守したりする全ての組織内の、全ての人間に関連した、全ての変数に関するものです。単純な数式を適用したり、高品質のソフトウェアを生み出すには、あまりにも多くの変数が存在します。代わりにソフトウェア開発のエキスパートは、それぞれの人が作り出す、全ての既知／未知の変数を利用する必要があります。そうした変数に対して、ベストな推測を行う必要があります。あなたがすべき事を知るのは役立ちますが、あなたがしなくてはならない事を知るのはお金に換えられないほど貴重です。ロジックはアプリケーションを作る役に立ちますが、人を知る事は価値を創造するのに役立ちます。
不完全な情報を扱う
.ポーカーの初心者はとても気楽です。よい手が来たら常に賭け、ブラフを行う事はありません。そう、まだ始めたばかりのうちは、あなたは何もすべきではありません（もちろん、あげても良いと思えるお金が大量にあるなら別ですが）。初心者レベルから脱却しようとすると、本当に大変です。一度に大量の情報があなたに押し寄せてきます。あなたはテーブルについている全員の態度に注意を払う必要があります。彼らがお互いにどう接しているか、個々の対戦相手に対する戦歴はどうか、彼らが好んで作る手の種類は何か、誰が勝っているか、誰が負けているか、そして他にも百万もの変数があります。また、あなたは他のプレイヤーが何をホールドしているか、次のカードが何かを知る事は出来ません。あなたは自分が処理できるよりも多くの情報を持っており、しかもそれが全てではないのです。
プログラミングも同様です。ドメインの専門家は全ての知識を持っていますが、前もって全てのドメイン知識をあなたに伝えようとするのは効率的ではありません。それに、あなたはドメイン知識の全てを必要とはしないでしょう。あなたはまた、自分のチームを良く知る必要がありますが、チームメイトについてあなたが知り得ない事や、完全に理解している事もあるでしょう。しかし、エキスパートプログラマーは必要とされるドメイン知識を要約し、チームの原動力を理解し、技術的なビジョンを一貫して提供していく事が可能です。エキスパートプログラマーは、完全な全体像を持つ事はできないだろうという事を理解しており、また考慮に値する事、無視するに値する事も理解しています。圧倒的な量、そして不完全な情報であるにもかかわらず、エキスパートプログラマーは常に正しい決断を行うのです。
素早いフィードバック
平均的なポーカープレイヤーは、フィードバックの少ないポーカーゲームの方が良いです。その理由は、ポーカープレイヤーは情報に基づいてお金を勝ち取るからです。5カード・スタッドでは、ベットを行うことが出来るのは1ラウンドだけです。たった1ラウンドで誰かが漏らした情報を元にあなたはお金を得て、ミスをするのもたった1ラウンドの間だけです。ポーカーのエキスパートは、より多くのラウンドからなるポーカーゲームを好みます。より多くのラウンドを持つポーカーでは、エキスパートがスキルの低い対戦相手から搾取する機会がより多くあります。エキスパートは迅速なフィードバックの価値や、そうしたフィードバックに基づいて彼らのプレイを変化する能力をよく理解しています。いくつかのラウンドからなるポーカーゲームでは、各ラウンドでフィードバックを得る事ができ、エキスパートは現在の状況に合わせてプレイを変化させます。
ソフトウェア開発のエキスパートも、迅速なフィードバックに重きを置きます。ビジネスからの迅速なフィードバックは、間違ったドメインコンセプトをアプリケーションに組み込んでしまう事から救ってくれます。他のプログラマからの迅速なフィードバックは、ソフトウェアが本番に移行する前にバグを特定できます。継続インテグレーションサーバからのフィードバックは、統合に関する迅速なフィードバックを提供し、統合に関する困難を軽減してくれます。もしあなたがアジャイルを好んでいるなら、プログラマとビジネスの双方に対して迅速なフィードバックを返す事から、イテレーションには明確な利益があると指摘するでしょう。しかし、あなたがアジャイルに賛同していなくとも、エキスパートプログラマーは迅速なフィードバックの価値を認識しています。アジャイルでない環境で働いていたとしても、エキスパートプログラマは、無駄な時間と労力を避けるために、出来る限り多くのフィードバックを探しています。迅速なフィードバックは、あなたが正しい方向に向かっているのかどうかを知る事が出来、全てのエキスパートはその情報に価値を見いだしています。
コンテキストがすべて
.ポーカーとプログラミングでは、正しい答えと悪い答えは少ししかありません。あなたはキングを複数枚持っていても、大負けする前にはフォルドすべきなのでしょうか？恐らくそうです。
それはトーナメントなのか現金のかかったゲームなのかによりますし、リミットがあるかないかにもよりますし、あなたがどの椅子に座ったかにもよりますし、既にフォルドしたか、既にキャップしたかにもよりますし、荒れたゲームなのか、全員が我慢強いゲームなのかにもよりますし、その他にもいろいろあります。ポーカーについて私が学んだ事の一つに、こうした全ての要因やさらに多くの事を、答えを出す前に考えなくてはならないと言う事です。
.私はプログラミングをすればするほど、全く同じ事がプログラミングにも言えると実感しています。あるシチュエーションではJavaが最高の選択肢ですが、全てではありません。もちろん、同じ事がほとんど全てのプログラミング言語に言えます。また、ツールについてもこれは真です。Hibernateは素晴らしいですが、そうでなければIBatisも素晴らしいですし、そうでなければ新しいソリューションを見つけたり作ったりする必要があるでしょう。単純に良いと言えるソリューションはほとんどありません。その代わり、適切な状況においては素晴らしいものです。適切でない状況では、それはひどいアイデアだと言えます。
そう、あなたが言語やツールを却下したり、良いと言って周りに触れ回る前に、覚えていてください: 「場合による」と言う事を...
原文はこちらです：http://www.infoq.com/articles/fields-it-depends
（このArticleは2008年4月26日に原文が掲載されました）