［ObjectDay2001特集］

XP談義 −その有効性を問う−

ObjectDay2001 実況レポート

平成13年5月18日に品川のホテルパシフィック東京でOBJECT DAY 2001が開催されました。「今日は、オブジェクトのクラス会。」と銘打つだけあって、カンファレンスが終わると、あちらこちらでクラス会の2次会が開催されたようです（笑）

数ある、興味深いセッションの中でも、一際目を引いたのが午後からパネルディスカッションとして開かれた、「XP談義−その有効性を問う−」でしょう。簡単に言えば、Extreme Programming（以下、XP）について、擁護派と懐疑派とに分かれて討論するという内容なのですが、擁護／懐疑派のどちらも、エンジニア経験豊富なパネラーの方々が参加されるということで、XP Seriesは読んだけど実際のところはどうなの？という興味津々の聴講者満員での開催となりました。

■ パネラー紹介／XPの概要

まずは、セッションが始まるということで、パネラーの方々が席につこうとしますが、XP懐疑派の方々の机に、XP否定派と書かれているのを見て、懐疑派の方々に動揺が走っているように見受けられました（笑）

擁護派4人、懐疑派4人に、司会1人という構成でパネルディスカッションが行われましたので、パネラーの方々を紹介させていただきます。（当日配布資料順、敬称略）

司会

• 藤井拓（オージス総研）

擁護派

• 長瀬嘉秀（テクノロジックアート）
• 平鍋健児（永和システムマネジメント）
• 石井勝（アイザック）
• 梅澤真史（オージス総研）

懐疑派

• 藤野晃延（インアルカディア）
• 清水吉男（システムクリエイツ）
• 渡辺政彦（CATS）
• 竹政昭利（オージス総研）

次に梅澤さんの方から、XPについての概要が説明されましたが、XPの概要についてはご存知の方も多いと思いますので、ここでの説明は省略させていただきます。

XPに関しての資料をお探しの方は、Kent Beckの著書を始め多くの本（XP Series）が出版されていますので、購入を検討されてはいかがでしょうか？また、XPの概要／精神をつかむには、「eXtreme programming FAQ」などのWebページが参考になると思います。

■ 擁護／懐疑派主張

XPの概要についての説明が終わったところで、個々のパネラーがXPに対しての考えを主張をする時間が設けられました。ここでは、擁護／懐疑派の主張の中でも、私が印象に残ったものについて挙げていきたいと思います。

擁護派主張

擁護派の主張する、XPを擁護する理由としては、

• ライトウェイトな開発プロセスなので、いくつかのプラクティスは明日からでも実行し、その効果を体験することができるから。
• 標準化や工業的テイラリズムへのアンチテーゼであり、人とのコミュニケーションを重要視しているから。
• XPのプラクティスは広まりつつあるものの、人とのコミュニケーションに主眼を置いている点においては、まだ理解されていない点も多く、オーバー目に誇張することでバランスが取れると考えているから。

といったことを挙げられていました。

特に、平鍋さんが、「XPは、規格や標準化に傾きがちなソフト開発で、ぽっかり空いたスペースへの、目を引くキラーパス。」だとコメントしていたことに思わず納得してしまいました。ここで主張されている「空いたスペース」というのは、"Standards"や"Taylorism"などの標準化を主眼としたものとは、逆サイドのスペースでいて、かつ"Agility"を持ち合わせているようなスペースのことを指しています。Kent Beckがこのスペースへパスを出したことで、現在、Martin Fowler、Ron Jeffries、Robert C. Martinなど優れたソフトウェアエンジニアが走り込んでいます。それぞれのソフトウェアエンジニアがスペースに走り込む理由は具体的には分かりませんが、現在のソフトウェア開発／開発プロセスに何らかの疑問や不満があり、その解決方法の選択肢の1つとしてXPに注目しているのは、間違いないでしょう。

また、擁護派からも、XPを採用するにあたっての注意点が挙げられていました。

• XPをそのまま適用することに注力するのではなく、問題点を解決する一つの選択肢として、XPのプラクティスの中から活用できるものを取り入れるといった柔軟性が必要である。
• Kent Beckが言わんとしていることを的確に捉えることが必要。例えば、XPではドキュメントを書かないとは言っておらず、顧客がそれ（ドキュメントを書くこと）を望むなら、新しいストーリーとして次のイテレーションで実行することができる。

などです。擁護派の方々も実際にXPでのプロジェクトを経験されているだけあり、より実践的／冷静な発言が多いと感じました。

懐疑派主張

次に、懐疑派の主張する、XPを採用することへの疑問点を紹介したいと思いますが、その中でも藤野さんの主張は後で紹介したいと思います。

• XPでは、「明日のことは明日やれ」といっているが、明日のことぐらい見えていないと不安になる。
• XPではなく、CMMを採用したとしても、それを自分の会社／チーム用にカスタマイズすることで、うまくいっている。
• 要求の変更が多発するのは、要求（仕様）の汲み取り能力不足が原因で、きちんとした要求の汲み取りが行われれば、顧客の要求が大きく変わることはない。
• 組み込み系の開発においては、システムの応答時間などを保証しなければならず、相応の設計をしておかないと破綻をきたす恐れがある。
• XPで成功しているプロジェクトというのは、非常にスキルの高いメンバーで構成されており、XPでなくても十分成功したのではないか？

主にこのような主張をされていたと記憶しています。

次に、懐疑派？のメンバーの中でも異色を放たれていた藤野さんの主張を紹介させていただきます。話を聞いていると、どう考えてもXP擁護派に近い発言をされているのは気のせいではないでしょう。「XPの12のプラクティスもKent Beckが新しく考え出したものではなく、昔からその有効性が確認されているものである。」、と発言されているあたりからも、決してXPの本質を否定されているわけではなく、なぜXPを採用するのか？という一点でのみ擁護派と微妙な違い（という程のものでもなくて、”XP”という流行言葉へのアンチテーゼかもしれません）があるように思えます。

さて、まず藤野さんは、ソフトウェア開発プロジェクトにおいて、「ソフトウェアの変更にかかるコストは、時間とともに指数的に増大する」ことの理由から解説されていました。以下、藤野さんの主張の概要です。（あくまでも自分の記憶と、メモからの復元ですので、誤りがあるかもしれないことをご了承ください。）

1回成功した開発プロジェクトを、もう1回行うのは容易なことである。しかし、自分が未経験のドメイン、組織、ソリューションを必要とするプロジェクトにおいては、それらの知識を正しく把握することが難しく、その間違った知識をインプリメントしてしまうため、バグが発生してしまう。もちろんバグは修正されるのだが、そこには制約が存在するために、修正のコストが高くついてしまうのだ。

まずは、「The Five Orders of Ignorance」に当てはめて、自分がどのレベルの無知なのかを知るのも良いだろう。

• 0OI - Lack of Ignorance（知らないことはない）
• 1OI - Lack of Knowledge（知らないことを知っている）
• 2OI - Lack of Awareness（何かを知らないことに気が付いていない）
• 3OI - Lack of Process（何かを知らないことを知る方法を知らない）
• 4OI - Meta Ignorance（The Five Orders of Ignoranceについて知らない）

難しい問題に直面したときに、これらの無知のどのレベルなのかを自問するのもいいし、XPに関して自分がどの程度分かっているかを確認することもできる。要するに、自分の無知がわかったときに、その解決方法の1つとしてXPを適用できるのは良いことだが、XP以外の選択肢が無いようでは困り者だ。

以上が、藤野さんの解説の概要です。特に、「The Five Orders of Ignorance」に関する解説は、惹きつけられる点も多く、藤野さんの話術も相まって聞き入ってしまいました。

ちなみに、藤野さんは、「この説明を聞いただけで、レベル4（4IO - Meta Ignorance）はクリアしているので、ラッキーです（笑）」、といった趣旨の冗談を話されて、聴講者の笑いを誘っていました。

■ ディスカッション

XP談義の後半は、ディスカッション形式を取りました。基本的には、擁護派と懐疑派がお互いに疑問点をぶつけて討論する形式ですが、実際にはXPに対する疑問点を懐疑派がぶつけて、擁護派が反論するというものになっていたようです。ディスカッションの全てがQ&Aで流れたわけではなく、また全てを記憶していませんので、印象に残ったやり取りをまとめてレポートさせていただきます。

Q.
XPでは、分析／設計をしないで、実装を開始し、実装においても明日のことは考えないというスタイルでうまく行くのか？

A.
XPにおいても、分析や設計を全くしないというわけではない。非機能要求などは、最初のイテレーションの前スパイクソリューションで検討が行われるし、分析／設計は、日々の作業として行われている。

Q.
XPでうまくいったプロジェクトは、たまたまスキルの高いメンバーで適用したためにうまくいっただけなのではないか？

A.
スキルが重要なのではなく、チーム内のメンバーのモチベーションが高いことが重要だと考えられる。プログラマーは、楽しく仕事をしたいと考えているとともに、良いものを作りたいと思っているものだ。XPはソフトウェア開発を楽しいものとさせてくれることを、期待させてくれる。
ただし、XPの適用開始段階においては、自分の組織にあったXPのテンプレートを作り出す目的のために、経験をつんだエンジニアでチームを構成することを考えても良いかもしれない。

Q.
XPは大規模開発に適用することができるのか？

A.
何を持って、大規模開発と呼ぶのか分からないが、Martin Fowlerは50人規模のプロジェクトでXPを適用している。ただし、それをXPと呼べるかどうかは分からないけど。（XPを自分のものとすることで、XPを意識しなくなるレベルということが言いたいのだと思われます。）

Q.
ペアプログラミングを取り入れるためには、ひとりひとりが個別にコーディングするよりも、効率的なことが実証されないと、組織で採用することが、難しいのではないか？ペア間での教育効果以外の利点はあるか？

A.
ペアプログラミングは、既に有効な開発方法であることが実証されている。性格の不一致など難しい面もあるかもしれないが、チームの一体感をあげるような方法を採用することで、十分克服することも可能だ。
朝、チームの誰かがトラックに引かれたときに、そのプロジェクトが中断する事態に陥ってしまうかもしれない、という冗談話がある。ペアプログラミングによってチームのメンバーの知識共有のレベルを高く保つことによって、チーム内の誰かが抜けただけでプロジェクトが破綻してしまうというリスクを避けることができるという利点もある。

この中で特に注目したいのは、ペアプログラミングに対しての見解で、質問に対する回答は、懐疑派パネラーである藤野さんが説明されていました。回答の中で、「ペアプログラミングの有効性は既に実証されている。」とはっきり述べていらっしゃいますが、具体的な論文／資料に関しては、参照資料の方に記述したので、是非一読することをお奨めします。
また、チームの一体感の重要性については、「Peopleware」で取り上げられているので、是非一読されることをお奨めします。

■ 私的感想

今回、XP談義のセッションを聴講するにあたり、XP擁護／懐疑派のどちらでもない中立な立場で参加したつもりです。セッション開始時に、パネラーの方が「勝ち負けの挙手などはやらないんですか（笑）」という冗談を言われていましたが、セッションを終わってみるとやはりXPサイドに立っている自分に気が付くのでした:-)
最後に、私的感想をもってレポートを終わりたいと思います。

懐疑派のパネラーの方々は、今現在XPが人気／注目を集めているのは、"シンプルな設計"や"週40時間"といった開発者の心を惹き付けるプラクティスにばかりが取り上げられるからで、こうした面だけが取り上げられることに、非常に危機感をもっている、という見解で話されているように見受けました。

それに対して、擁護派（私個人含む）の見解としては、XPという言葉や、個々のプラクティスなどはかなり広まってきたものの、XPの精神ともいえる、「コミュニケーション」の重要性についての認識は、まだ（全く）十分でないと感じています。確かにCMMをカスタマイズすることでも、コミュニケーションを大切にしたプロセスの構築は可能だと思いますが、具体的な記述はされていませんし、人間系のアプローチが中心となっているXPとは別のものだと感じています。

「プログラマーは、"良い物"を作りたいと日頃から思っていて、トップダウンのプロセスでは、やる気をそいでしまう恐れがある。」とおっしゃっていた、平鍋さんの意見は、実際のプログラマーの思いと一致していると思いますし、そうしたやる気を最大に生かす組織／プロセスとすることで、生産性を上げることができるということは、「Peopleware」などでも明確に論じられています。また、やる気をそがれた開発者が離職してしまうことで発生する損失を無視することはできず、単に別の人間を補填すれば片付くような、簡単な問題でないことは明白です。

では、どこから始めれば良いのでしょう？XPのプラクティス自体は、それ自体が相互に作用することで、最大の効果を発揮するような性質のものですが、"ペアプログラミング"や"テスティング"などは、XPのプラクティスとしての有効性というよりは、それ自体が既に有効であるということが実証されたやり方です。まずは、今現在の組織／チームが抱えている問題点を解決する方法に、XPのプラクティスや、原則であるコミュニケーションが有効な解決策とならないかを検討し、適用するところから始めてはいかがでしょうか？

■ 謝辞

ペアプログラミングに関しての参照資料に関するアドバイスを、藤野晃延＠インアルカディアさんから頂きました。ありがとうございます。

■ 参照資料／リンク

The Five Orders of Ignorance, Phillip G.Armour, October 2000/Vol. 43, NO. 10 COMMUNICATIONS OF THE ACM

Webからも、PDF形式で参照することができる。自分がどこまで知っているのかを確認する良いツールとなるはずだ。

Pair Programming.com https://www.objectmentor.com/pages/pairpro.htm

読んでそのまま。ペアプログラミングについて、多くの資料が集まるだろう。

Jim Coplien https://www.bell-labs.com/user/cope/index.html

Patternsから、「A Development Process Pattern Language」を参照することができる。
Lucid、BorlandやAT&Tなどの組織において、実際に有効であると確認されたプロセスパターンの中に、ペア開発の有効性について触れているパターンが存在する。

Laurie Williams https://collaboration.csc.ncsu.edu/laurie/

ペアプログラミングに関して、実証／研究をされている、Laurie Williamsさんのページ。

eXtreme programming FAQ https://objectclub.esm.co.jp/eXtremeProgramming/index.html

XPについての基本的な知識から、XP関連記事の翻訳ドキュメントなどを参照することができるページ。
また、XP-jpメーリングリストも運営されており、過去記事の公開も行なわれているので、参照していただきたい。

Peopleware : Productive Projects and Teams, 2nd Ed., Tom Demarco, Timothy Lister, 1999, Dorset House

チームの一体感の重要性について知ることができる他、XPの根底に流れる精神を読み取ることができる名著。
他にも、ファシリティについての重要性についても言及していたり、あまり触れられることの無い、離職率の問題にも踏み込んでいる。

Extreme Programming Explained: Embrace Change, Kent Beck, Addison-Wesley
Planning Extreme Programming, Kent Beck, Martin Fowler, et al, Addison-Wesley
Extreme Programming Installed, Ron Jeffries, et al, Addison-Wesley
Extreme Programming Examined, Giancarlo Succi, Michele Marchesi, Addison-Wesley
Extreme Programming in Practice, Robert C. Martin, James W. Newkirk, Addison-Wesley

XPの適用を考えるなら、読んでおくとベターなXP Series。
"ベター"といっているだけで、全てを読まなくても、できるところから始められるのがXPの良いところ。

■ 実況者横顔

（株）豆蔵　栗原哲也

OOの世界に足を踏み入れてからまだ日が浅い若造（実年齢とは関係なかったりします）。RUPベースでの、分析／設計を学びつつも、XPの精神（Demarcoの精神かも）はいつも胸に秘めて精進の毎日。

実際のプロジェクトで、シニアな方と一緒に作業をすると、「そこは、シンプルな設計で良いのでは？」などと、なかなか言い出せない、OOエンジニア見習。
＃っていうか、言えませんよね。ホント（笑）

© 2001 OGIS-RI Co., Ltd.

Index