プログラマーの条件付け

私はコンピューター・サイエンスの学位を取得していませんので、多くのプログラマーが受けた「従来の」トレーニングに関する直接の経験に基づいた話はできません。とはいえ、私は多くのプログラマーやビジネス畑の人々とともに複数のソフトウェア開発プロジェクトに取り組んできました。ですから、それらの人々がソフトウェアを作成しようとするときに、どのように考え、また行動する傾向があるのかについては、気の利いたことが言えると思います。私もプログラマーですので、最初にプログラマーについてお話ししましょう。

プログラムに親しむ

私の父は医師です。彼から飽きるほど聞かされた話があります。「医学部に入って、卒業して、実習期間を終えて、やっと医者になれるんだ。」ほとんどのコンピューター・サイエンスの学卒者についても、似たようなことが当てはまるのではないかと思います。彼らは多くの理論 (その中には、非常に役立つものもあります) を学んで大学を卒業しますが、どうしたら良いコードが書けるのかについては、あまり学んでいません。私は大学でコンピューター・サイエンスを専攻していませんので、そうした理論の多くを学び損ねています。そのことで不自由を感じることもありますが、ほとんどの場合は気になりません。

私がプログラミングを始めたのは22歳のときで、大学を卒業してすぐのことでした。Andersen Consulting社のトレーニングを受け、指導者のヒントを助けに、なんとかその場をしのいできました。ほとんどの人も、同じようにやっています。仕事をしながら、たいていの場合はその会社の環境に合わせてある程度味付けされた形で、プログラミングを身に付けるのです。残念ながら、彼らの指導者や教師も同じことをしてきたのです。習慣、慣用的な語法、個人的な好みなど (その多くは、あまり良いとは言えないものです) が、ある世代から次の世代へと引き継がれます。このようにして、ほとんどのプログラマーは、(おそらく、できるかぎり早く) 仕事を仕上げることを学ぶのです。

次の4つの行動パターンは、たいていのプログラマーに当てはまるようです。

• プログラマーは、業務の意思決定者に上手に話をする方法を知らない。
• プログラマーは、問題が教科書どおりに解けるものと思い込んでいる。
• プログラマーは1人で作業することを好む。
• プログラマーは、テストはコーディングの後で行うものであると考えている。

上に戻る

ビジネス畑の条件付け

ビジネス畑の人々は、彼らなりのトレーニングを受けますが、その内容は、プログラマーが受けるトレーニングに比べて、かなり多様性に富んでいます。しかし、結果は似たようなものです。ビジネス畑の人々は、自分たちのソフトウェア・プロジェクトを危機に陥れるように振る舞うことを条件付けられています。

業務遂行のコスト

経費管理を担当するビジネス畑の人々は、一日中計算をすることがありますが、なぜ ソフトウェアが必要なのかを考える方法は知らないようです。多くの場合、その機能や、それらの機能が自分たちの業務に (直接または間接に) もたらす金銭的な価値の業務上の優先順位について、きちんとした概念を持っていません。これは、プロジェクトを管理する比較的下位の管理者についても、会社の指導者層についても、当てはまります。

多くの企業環境では (大企業の場合には特に)、一般社員は、上層部の人々が命令で支配していると考えがちです。何らかの命令が上から降りてきて、一番下にいる人々はただそれを実行することだけを期待されています。プロジェクトを管理する立場の人々も、蚊帳の外に置かれ、自由を束縛されています。彼らは多くの場合、考える権利を与えられていません。したがって、命令が下されると、言うがままに従い、なぜ そうすべきなのか、あるいはすべきでないのかという細かな問題は、「食物連鎖」の上位にいる人々に任せきりになっています。

しかし、全知全能と思われている最上部の人々も、これと似たり寄ったりなのです。業務上の意思決定は、最終的には、何が「旬 (しゅん)」であるのか、つまり最も人目を引くのかによって決まることが多いのです。「他社が皆やっているのなら、うちでもやるべきだ」というわけです。勝ち組みに加わろうとする、いわゆる「バンドワゴン」効果が働いているのです。問題は、ビジネス畑のリーダーたちがソフトウェアについて誤った考え方をしていることです。彼らは、ソフトウェアを、なんらかの費用を伴う資産としてではなく、費用そのものと考えています。ソフトウェアを、戦略的な強みではなく、必要悪あるいは生産手段であると考えているのです。

かかわり合いはご免だ

ビジネス畑の人々がソフトウェア・プロジェクトに「かかわる」という場合、誇張が含まれている傾向があります。通常は、深く関与することなどありません。ソフトウェア開発者がときおり彼らに質問をするはあるとしても、この手続きもおざなりのものです。プロジェクトは通常、開発チームがウォーターフォール・モデルの変形版を使用していない場合であっても、分析設計から始まります。ビジネス畑の人々が意見を述べる機会が多いのは、この段階です。しかし通常、技術チームは、ビジネス畑の人々たちがすべてを知り尽くしているものと期待しています。「今後1年間にこのソフトウェアが行う必要のあることを、すぐに言ってみてください。僕たちは後で考えを変えても構わないというかもしれませんが、それは冗談ですからね。あなたたちがここで決めたことは、石に刻み付けておきますよ。」

ビジネス畑の人々は、神経質になるに違いありません。自分の知らないことについて、決定的なことを言わざるを得ない立場にいるのです。これにより、彼らはほとんど間違いなくIT生存競争に巻き込まれてしまい、細かなことは投げ出して、開発者が解決してくれることを期待します。協調性に富んだ創造的活動にふさわしい方法とは言えません。

社内の主導権争い

競合により制約に拍車がかかります。プロジェクト・マネージャーは、より地位の高い人から仕事を押し付けられ、それを下の人に転嫁するのです。開発者は、すべての人々を満足させる必要があります。その対象には、システムがインターフェースを提供する必要のある他の部門の人々に対してでもです。その人達が、アップストリームかダウンストリームか関わらずにです。しかし、誰かの感情を害したり、誰かを不幸にしたりすることは避けられません。

上に戻る

思考パターンを打ち破る

ほとんどの会社は、長年かかって築き上げられた、このような行動様式に凝り固まっています。その結果、ソフトウェア・プロジェクトは人々を翻弄し、完成したときにはだれも満足しないものになってしまいます。

これでは、救いようがありません。いつまでもこのまま我慢しているわけにはいきません。そのためには、行動様式を変える必要があります。私は思考プロセスの専門家ではありませんので、経験に基づく話だけをさせていただきます。私は時々、まず始めに開発者はこれまでと別の考え方をするように試みるべきであり、それが行動に影響を与えるはずであると信じることもあります。しかし、私の場合、たいていはそうした方法はうまくいきません。最初に行動を変える必要があるのです。考えは後からついてきます。私にとって最良の方法は、考え方を変えようという意図をもって、異なった行動を取ることです。そのために、XPを役立てることができます。

XPを使用するには、典型的な条件付けとは相いれないような行動様式が必要です。可能な最良の結果をXPから得て、読者自身や組織のために適切であるかどうかを判断するための唯一の方法は、ある期間の間、できるだけ多くの (できればすべての) プラクティスを行ってみることです。読者とそのチームがひたすらそれらの有効性を探り、社内でソフトウェアを作成する人々の間で、より健全な習慣を醸成してください。

XPのプラクティスが人々の考え方を変えるために役立つのは、それらの人々がプラクティスの使用 を開始した場合だけです。そのためには、XPを頭から信じ込むこと、あるいは少なくとも判断を保留する必要があります。XPは「常識的」ではありませんので、最初のうちは戸惑いを感じるかもしれません。とうてい自分には向いていないと感じるかもしれませんし、あなたの会社には向いていないかもしれませんが、試してみなければ、はっきりしたことは分かりません。とにかく、試してみるに越したことはありません。2週間ほどXPを試してください。その際、次の2つのことを心がけてください。

1. 奇異な感じがしたり、好ましくないと思ったりしても、やめないでください。
2. 今行っていることについて、別の考え方をするように努めて意識してください。

最初の心構えは、読んでいただけば分かると思います。2番目の心構えについては、多少の説明が必要です。プログラマー向けのXPのプラクティス (ペア・プログラミングなど) やビジネス畑の人向けのXPのプラクティス (ストーリーの作成など) を行うときには、これまでと異なる考え方をしなければうまくいきません。すぐに別の考え方を取り始めることは無理でしょうが、見せかけることはできます。

見せかけの振る舞い

なじみのないプラクティスに出合ったときには、次の2つの方法でそれらしく振る舞う必要があります。

1. その仕事を気に入っているように振る舞ってください。心底から 気に入っているように振る舞うのです。
2. そのプラクティスがあなたに求めているような方法で考えているように振る舞ってください。

もちろん、すでにこのプラクティスが気に入っている 場合には、そのように見せかける必要はありません。しかし、もし気に入っていない場合には、無理やりにでも、気に入っているふうに行動しなければなりません。いつもこのプラクティスを心がけてください。この方法によらなければコードができないように振る舞ってください。このプラクティスが嫌でしかたがないという場合には (ほとんどのプログラマーは、ペア・プログラミングのような、「論争的な」プラクティスを好きになるか嫌うかのいずれかです)、それを表に出してもやむを得ませんが、その後で必ずその気持ちを収めてください。不信感があってもそれを抑えて、とにかくやってみてください。これは、意思の働きです。あなたの思考傾向または経験が、不機嫌になったり避けたりすることを命じているだけですので、実際にそのように反応する必要はありません。

では、異なった考え方をしているように見せかけて振る舞うとは、どのようなことなのででしょうか?まさに、書いてあるとおりです。Ron Jeffriesは、ある記事でこの点に関して述べていますが、気付いていなかったようです。YAGNI (「You Aren't Gonna Need It; 将来必要にならないもの」) プラクティスは、我々が別の考え方をする必要があることに気付かせてくれる、と彼は言っています。

私たち科学技術者のほとんどは、複雑なことを扱う自分たちの能力を自負していて、最新の事柄を学ぶのが大好きである。私たちは、自分の仕事が単純で保守可能なプログラムを今すぐに作成することであり、わずかなWebページをサポートする巨大なエンタープライズ・ソフトウェアを構築することではない、と気付かせてくれるものを必要としている。

彼は、YAGNIが私たちプログラマーに、新規機能が必要であることが分かるまではソフトウェアに機能を追加すべきでないことを気付かせてくれる、と付け加えています。なぜ追加すべきでないのでしょうか?というのは、ビジネスでは、後で何が「必要」になるかをうまく予測できない場合が多く、この考え方を推進すべきだからです。また、他のプラクティスをある程度十分にこなしていれば、後で必要であることが分かってから、余分なコストなしに機能を追加することができるからです。YAGNIは私たちに、単純さへのこだわりを守らせます。これは、XPが必要としている新しい考え方の一部をなすものです。次に、プログラマーに関する他の例を見てみましょう。

• ペア・プログラミングでは、2つの頭脳のほうが1つの頭脳よりも優れている、と考える必要があります。相棒が愚か者であるとひそかに考えるようではいけません。知識のギャップがあるのですか?それなら、ギャップを埋めるべきであり、心の中でその人を見下すのはやめてください。ことによると、その「愚か者」があなたの見落としていたことに目を配っていたり、すばらしいアイデアを思いついたりすることもあるのです。
• テスト第一主義の開発では、先のことを考える必要があります。確かに、テストを行わなくてもクラスの1つぐらいは作れます。コードは簡単です。しかし、100のクラスがあってバグが発生したらどうなるでしょう?テストを行っておくことで、きわめて早くバグを分離できるはずです。テストをしていないと、デバッグに何時間もかかる可能性があります。テストを先に作成するためには、あなた自身に関する不愉快な事実、つまりあなたが完全でもなければ全知全能でもないということを受け入れる必要もあります。
• ストーリー作成プラクティスでは、あなたは顧客役 (customer) がソフトウェア開発を推進すべきであると信じる必要がありますが、ここで言うのは本当の意味で 推進することです。仮定された機能がどれほどすばらしいものであっても、何かを作り上げることはできません。

ビジネス畑の人々のための例もいくつか示しておきます。

• ストーリーの作成には、自分がソフトウェアを駆使することができ、またそうすべきであると信じる必要があります。「これは自分のソフトウェアなのだ。誰かに、このソフトウェアがどのようなことをするのかを話さなければならない」と考える必要があります。
• 頻繁にリリースするためには完ぺきを期すよりもある程度で満足したほうがよい、と考える必要があり、また、実際のユーザーからのフィードバックは、最終的に希望しているソフトウェアに向けてプロジェクトを「かじ取り」するための最良の方法である、と考える必要があります。多少不格好な部分があっても、完成前に実際の人々に向けてなんらかの形でリリースするのがよいことである、と考える必要があります。
• 顧客テストのためには、あなたが このテストを作成することには、明らかに余分な手間をかけるだけの価値がある、と信じる必要があります。確かに時間がかかります。プロジェクトを成功させたいですか?それならば、開発者たちに対して、彼らがあなたの要求を満たしていることを証明するためのテストを実施して、ある機能が「完成」したことを教えてください。もっともらしい難癖を付けて、その点をあいまいにしてはなりません。

これまで述べた思い込みをすべて含めた例を次に示します。読者がプログラマーであるなら、たとえあなたから見て心配な点があるとしても、顧客役に操縦をまかせてください。あなたが行うべきことについて顧客役が「ストーリー」を作り、受け入れテストによって機能の完成が告げられるまでは、一切コードを書かないでください。顧客役が求めていることに同意できないときには、顧客役が行っていることを本人に考えさせるような質問を行うだけにしてください。そのストーリーのばかばかしさについてまくし立ててはなりません。チーム内の他のすべての開発者にも、この決まりを守らせてください。あなたが顧客役である場合には、漠然とした決定を行い、プログラマーに解釈をまかせようという衝動を抑えてください。後で考えを変えるように要求できることを承知したうえで、できるだけすばらしいストーリーを作るように努めてください。そして、なんらかのことについて (どのようなことでもかまいません) 意図的に考えを変更してください。読者がプログラマーである場合には、顧客役の考えが変わったことに対してよい反応を示して、この循環を終わらせてください。顧客の考えが変わるのを期待していたように見せかけるのです。

このように見せかけることにより、習慣が形成され始めます。このような習慣により、あなたの考え方が変わります。そうしたことが自然なことに思われてきます。

上に戻る

価値を重視する

最後に行うべきことは、これまで述べてきたこと以上に非常識に思えることです。読者はチーム内のビジネス畑の人間として、自分が要求したそれぞれの機能 (あるいは機能のセットと言ったほうが適切かもしれません) のビジネス上の価値を、最大限の努力を払って (金額によって) 定量化する必要があります。これは、ソフトウェアのためのビジネス・ケースであり、このコラムでもう1つ記事を書くだけの価値があると思います (そのためには読者の意見による後押しが必要ですので、ご意見をお聞かせください)。さしあたっては、私の考えを簡単に述べさせていただきます。あなたのチームが作成しようとしているソフトウェアのそれぞれの機能ごとに、次の2つの質問に答えるようにする必要があります。

1. この機能はどのような価値の要求に答えるものであるのか (つまり、顧客役のどのような出費が減るのか、あるいはどのような収入が増えるのか)?
2. それはどの程度の金額になるのか?

これらの質問に答えることは、必ずしも常に可能でないことは認めます。不可能な場合には無理をする必要はありませんが、試す前から不可能であると決め付けてはなりません。機能の要求側にとって、なぜそれを要求するのかを理解することは重要です。このソフトウェアのために誰かがお金を払うのです。そうしたお金と引き換えに何を得るのかを知る必要があります。

上に戻る

考え方を変える際の注意

XPでソフトウェアを開発するためには、あなたの考え方を全般的に変更する必要がありますが、新しい考え方が特に風変わりに思える点がいくつかあります。次のことに注意してください。

• 顧客役は、開発者の指示に従うだけでなく、常に 自ら開発を推進する必要があります。開発者は、顧客役をチームの一員として考える必要があります。顧客役は自分自身 をチームの一員として考える必要があります。
• 顧客役は、上からの恣意 (しい) 的な圧力によるのでなく、業務上の必要に基づいて開発を推進する必要があります。
• 顧客役は業務上の必要性を、きわめて特定された機能のストーリーに変換する必要があります。そのようにしないと、プログラマーは何をコーディングしてよいのか分かりません。
• 顧客役は (おそらくは他の人々の助けを借りて)、開発者にそれぞれのストーリーが完成したことを告げるための、受け入れテストを指定する必要があります。
• 開発者は、機能を追加させるためのストーリーが顧客役によって語られなければ、機能を追加することができません。
• 開発者は常にプログラマー・テストを作成する必要があります。

これらのことは、これまでのやり方と根本的に異なります。そのためには、訓練が必要です。その訓練は、多くの場合、プロジェクトの成功が増えることによって報われます。自分の立場を守ってください。今後の記事で、思考パターンの変更方法に関する具体的な提案を行う予定です。

上に戻る

変更は上層部に影響を与えるものでなければならない

上のセクションの2番目の個条は、読者としては多少抵抗を覚えるのではないでしょうか。「顧客役は、上からの恣意 (しい) 的な圧力によるのでなく、業務上の必要に基づいて開発を推進する必要があります。」読者の言うことが聞こえてくるようです。「いいかRoy。君はそんなに 単純な人間なのかい。上からの圧力は、いつだって存在する。そいつ (圧力) が坂道を転げ落ちて来るんだ。」なるほど、そのとおりです。しかし、圧力に対する対応を変える必要があります。

プログラマーのプラクティスを覚えていますか?顧客役が1回の反復で行える量の倍ほどのことを、しかも昨日になって要求してきたときには、プログラマー役はどう答えますか?「いいえ」と答えるか、要求内容を変更して「はい」と答えるかのどちらかです。週100時間労働に取りかかることを同意してはなりません。ビジネス畑の人々も、同じことを行うようにする必要があります。これが、組織の最上部までさざ波となって影響を与えるはずです。すべての人 がこのように振る舞い始める必要があります。それ以外のことは、非現実的です。

こうした変化が最上部から始まると言いたいところですが、多くの場合、そうはいきません。下からの変化が必要な場合もあります。変化を開始させる方法は、人々が、短期的な圧力から逃れるために上司にうそをつくのをやめることです。そのようにしないと、実現できないときに自分自身への怒りをためてしまうことになります。本当のことを言ってください。「いいえ、そのようなことはできません。こういうことならできる と思いますので、こうしたいと思います。」お偉方から、出て行けと命じられる可能性があります。私は、そのようなことにならなければよいと願っています。しかしMartin Fowlerはこう言っています。「組織を変えることができないなら、組織を替えなさい。」ほかに、現実的な居場所を見付けてください。物事が変化しない理由はただ1つ、私たちが変更を拒んでいるためです。

上に戻る

来月の予定

顧客役は、XPが最も本領を発揮できる役割であり、ほとんどのIT組織にとってなじみのないものです。あまりに非公式で、しかもあまりに多くの権限を備えているため、ほとんどの人にとって、付き合いにくい存在です。しかし、XPプロジェクトを成功させるためには不可欠です。顧客役の存在しないXPプロジェクトは、ユーザーがプロジェクトの終了時に実現されると期待しているものと、大きくかけ離れる運命にあります。来月は、XPチームに顧客役を含めるために、心理的および組織的にどのような変化が必要であるのかをお話しする予定です。

参考文献

• 『エクストリーム・プログラミングの神秘を解く』 シリーズのすべての記事をお読みください。
  • 「XPの真髄」に立ち戻る 第1回: XPの誇大宣伝を詳しく検討する
  • 「XPの真髄」に立ち戻る 第2回: プログラマーのプラクティスを全体像に当てはめる
  • 「XPの真髄」に立ち戻る 第3回: 顧客役と管理役のプラクティス
  
  
  
• オリジナルのXPの真髄 (developerWorks、2001年3月) をお読みください。
  
  
• Extreme Programming with IBM VisualAge for Java (developerWorks、2001年4月) では、最新のJava IDEでXPを使用するためのベスト・プラクティスがいくつか示されています。
  
  
• Misconceptions about XP (Ron Jeffries著) には、XPの思考方法に関する彼の考えが述べられています。
  
  
• 見せかけの振る舞いがもたらす利益については、RonによるPretend You're Not Afraid を読むことをお勧めします。
  
  
• Javaテクノロジー関連の参考文献は、developerWorksJavaテクノロジー・ゾーン に豊富に掲載されています。
  
  

XPについてさらに学びたい方は、以下の著作を参照してください。

• Extreme Programming Explored(William Wake著、Addison-Wesley、2001)
  
  
• Extreme Programming Applied: Playing to Win(Ken AuerおよびRoy Miller著、Addison-Wesley、2001)
  
  
• Planning Extreme Programming(Kent BeckおよびMartin Fowler著、Addison-Wesley、2000)
  
  
• Extreme Programming Explained: Embrace Change(Kent Beck著、Addison-Wesley、1999)
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• プログラマーの条件付け
• ビジネス畑の条件付け
• 思考パターンを打ち破る
• 価値を重視する
• 考え方を変える際の注意
• 変更は上層部に影響を与えるものでなければならない
• 来月の予定
• 参考文献
• 著者について
• コメント