最近、「ＸＰ（eXtreme Progrmming）」が話題になっています．日経コンピュータ（2001/6/4）にも、大々的に特集が組まれていますので、多くの人は、その存在に気付いていたことと思われます．
ＣＭＭの時は、日本で広く知られるようになるのに、アメリカで発表されてから５〜７年もかかったが、ＸＰの場合は、３年弱で日本中に知れ渡ることとなった．これはインターネットの普及が背景にあるのと、ケント・ベック氏の戦略の上手さもあるのではないかと思っています．日本人と違って、彼らは自分をアピールするのが上手い．どうすれば、自分をアピールできるかを、良く心得ています．私自身、先のオージス総研の「Object Day 2001」でこの問題に関わったこともあって、このあとしばらく、ＣＭＭとの関係について触れていくことにします．また、ＸＰを信奉する人たちが、果たして、本当にＸＰを理解しているのだろうかということも、しっかり見ていきたいと思っています．
本質を見誤るな
私は「ＸＰ」を否定するつもりはありません．私の知る限り、「ＸＰ」のプラクティスには、ソフトウェアの開発に有効な方法が幾つか含まれています．ただ、それらが、巷間云われているように、ＣＭＭなどの「プロセス優先」の世界と、そんなに対局にあるわけではないと思っています．ＣＭＭを叩いて見せるというのは、自分の考えをアピールするために、その時点で人気の高いものを叩くという方法で、アメリカ人の常套手段です．
オブジェクト指向の時にも、彼らは、構造化手法を否定することで自分たちの手法をアピールするという方法を使ったわけです．そのことで、多くの日本のソフトウェア技術者がミスリードされました．当時、オブジェクト指向に取り組んだ多くの若者は、彼らのアピールに乗って、一緒になって構造化手法を否定することで、時代の先端を走っていると錯覚しました．おそらく、多くの人は構造化手法とは何かということも殆ど知らなかったはずです．雑誌や本に書いてある「問題点」を鵜呑みにするだけで、実際に、構造化手法の陥りやすい弱点を知っていたでしょうか．そうしたアジテーションに便乗した代償として、「設計する」というこのと本質を学ぶ機会を失った可能性があります．結果として、いつまでも「複雑さを解消」しきれないまま要求をコードに変換するはめに陥ったわけです．当然、「週４０時間」なんて、全く別の世界の話です．
私には、今回の「ＸＰ」も、その普及に当たってこれと同じ手法を使ってきたと見ています．しかも１冊目の「入門」では、非常に”のど越し”のいい言葉や表現が使われています．全く見事です．まえがきには、「本書はＸＰの背後にある考え、ＸＰのルーツ、哲学、ストーリー、神話について述べられている」とはっきりと断っています．あくまでも「伝導の書」なのです．だが、現実世界での混乱の中にいるソフトウェア技術者にとって、そこは光り輝いている世界に見えたことでしょう．自分たが居る世界とは全く別の世界に見えたことでしょう．自分の周りにある問題を一気に解決してくれる「銀の弾丸」に見えたかもしれません．
でも、そのような人たちも、２冊目の「実行計画」を手にして、戸惑っているのではないでしょうか．「実行計画」は、「プロジェクトの計画を立てる」ということに多くのページが割かれています．「見積り」の重要性も書かれているし、「バグへの対応」も、入門書と違って触れられています．ただし、バグはどうすれば減るのかは書かれていませんし、見積りはどうすればうまくできるようになるかは書かれていません．計画書については比較的多くのページを割いていて「現実」に近くなっているのですが、果たして、読者が、「計画を立てる」ためには何をすればいいのか、という「具体的イメージ」を持つことが出来たでしょうか．くだらないことをしないで済むような計画というものを、どうすれば書けるか、果たして分かったでしょうか．優れた「計画」が必要であるというのは、ＣＭＭでも早い段階で主張しているところです．ＣＭＭには、計画が有効に働くためには、どのようなことについて書かれれば良いかというガイドも示されています．もちろん、すべての項目を埋める必要はありません．組織の状態に応じて「ライトウェイト」に対応すればいいのです．
ベック氏やファウラー氏には、これらの計画はサラッと出来るのでしょうが、果たして、ソフトウェアエンジニアリングを殆ど勉強していない人にとって、２冊目の「実行計画」からは、行く手に光が見えたでしょうか．もしかすると、現実の世界に引き戻されたかもしれません．やっぱり、「計画」を書くんだ．やっぱり見積もらないといけないんだ、と．（「ＸＰ」の個々のプラクティスについては、別に触れる機会があるかと思っていますので、ここでは深入りしません）
週４０時間の制限の中で、顧客の要望を満たし続けるために有効な方法や知識は、それらを包んでいる「パッケージ」が「ＣＭＭ」であろうと、「ＸＰ」であろうと、それほど大きな違いはないと思っています．それが、ソフトウェアの開発を上手くやるための本質というものです．
彼らは並の人ではない
ＸＰを提唱したベック氏や、その後に合流したファウラー氏と言えば、世界中が認めるスーパー・プログラマーです．もちろん「プログラマー」といっても、日本の組織で使われている「プログラマー」とは、まったく異なります．ファウラー氏は、その前には「ＲＵＰ」の推進者でもあったわけです．何れにしろ、彼らはソフトウェア・エンジニアリングに精通している人たちです．その人たちが、気が短くなった顧客の要求を満たすために、余分なものを削ぎ落として本当に必要なことだけに絞り込んだら、「eXtreme」になったわけです．ただ、気をつけて欲しいのは、ソフトウェアの開発に当たって、これらのプラクティスだけで済むとは限りません．でも彼らは、これらのプラクティスの隙間を埋めることができるのです．しかも無意識のうちに身体が反応することでしょう．それは、知っていて削ぎ落とした人のみができることです．
ページ＝ジョーンズ氏の本の中に「技術習得のレベル」というのがあります．
段階１：無知の段階 ― その技術について聞いたこともない
段階２：気がかりな段階 ― その技術について文献を読んだことがある
段階３：見習いの段階 ― その技術について３日間のセミナーに通った
段階４：実践しようとする段階 ― その技術を実際のプロジェクトに適用しようとしている
段階５：職人の段階 ― その技術を仕事の上で自然に自動的に使っている
段階６：名人の段階 ― その技術を完全に消化していて、いつルールを破るべきかを知っている
段階７：エキスパート ― 専門書を著作し、講演し、その技術を拡張する方法を探究するこれを見て分かるように、彼らの行動は「段階６」以上のレベルの人としての行動なのです．
念のために補足しておきますが、「いつルールを破るべきか」というのは、その手法が最初に提案されてから時間が経っていたり、適用される範囲が広がったりして、その手法を取り巻く状況が、必ずしも初期の状況とは違ってきます．その「差」を埋めるべく、今までのルールを変更する必要が生じるわけです．構造化手法にしろ、オブジェクト指向にしろ、「リアルタイム拡張」が出てきたのは、まさにその結果なのです．そして、これが出来るのは「段階６」以上の人だということです．読み易さに惑わされるな
ＣＭＭの場合は、最初に翻訳されてきたのは、“堅苦しい”ＣＭＭそのもので、殆どの人は、一読して”分からない”と云う印象を抱いたことでしょう．そこでは標準書にありがちな「一般化」された表現が並んでいて、読者は、それぞれの項目を、自分で「具体化」して読む必要があります．確かに、ＣＭＭを道具に使っている者の目から見ても、ＣＭＭの文献の堅苦しさは拭えません．また、この種の文献を読むための「辞書」を持ち合わせていない人が多いことも、ＣＭＭの普及が進まない原因と思っています．
もっとも、つい最近、『ＣＭＭによるプロセス改善入門』という文献がでましたが、著者はＳＥＩ関係者ではなく、ＣＭＭをプロセス改善のガイドとして使っているコンサルタントが書いたものです．この本を読むかぎりでは、ちょうど私と同じスタンスのように思えます．とはいっても、この本は、今日の時点ではまだ多くの人には読まれていないと思います．
この他に、ＣＭＭの堅苦しさに加担しているのが、多くの組織における「ISO-9000」の取り組みです．このISO とＣＭＭが、殆ど同列に扱われていることも、ＣＭＭに対して受け身にさせてしまった原因と考えています．
これに対して、「ＸＰ」は、実に軽快に打って出てきました．書籍も既に２冊が翻訳されていますが、最初は「伝導の書」で、つぎは、少し現実的な「取り組みの書」で、何れも、電車の中で読める程度のボリュームだし、内容も平易な言葉で書かれているので、読者は、その時点で持っている「辞書」でも、読めると錯覚してしまう．この点では、ＣＭＭは、あまりにも硬すぎました．ただ、だからといって本質を見誤らないようにして欲しいものです．
また、ＣＭＭの時と違って、「ＸＰ」はインターネットの時代に提唱されたことも、普及のスピードを早めた思っています．それだけに、必要以上に騒がれてしまう危険もあります．アメリカのサイトの情報もしっかり目を通してください．日経コンピュータに、ＸＰに関するサイトが幾つか紹介されていますが、「IEEE」のサイトにも、違った視点の情報が掲載されています．
ＸＰがうまく行くように見えるわけ
日経コンピュータの特集を読んでいると、まるで今までの問題が、これで解消されるような方法であるかのように書かれています．同じようなことが、オブジェクト指向による開発が広がりを見せたときにもありました．そして、同じように、成功事例（にしては不十分だが）が紹介され、取り組んだ人たちの体験が、活き活きと語られていました．
実は、このとき取り組んだ人たちに共通していることは、全員が「能動」であるということです．誰からも「ＸＰ」で開発しなければならない、と指示されたわけではありません．誰よりも早く「ＸＰ」の存在に気付き、その考え方を使って開発してみたい、という強い欲求が自分の中にあったということです．この「能動」といことが、すべてに於て有効に作用します．「能動」で行動している時は、決して出来ない理由を並べてこないということです．新しいことへの挑戦には、分からないことやちぐはぐな事に出会います．問題は、そのとき「どうすれば良いか」という思考の下に、別の方法を考えつくかどうかです．「能動」で動いているときは、そんな時でも、何か方法があるはずだと考えて、文献を再度読み直してみたり、インターネットで情報を探して見たり、それでも見つからないときは、自分で工夫するものです．その結果として、納期を大きく外すこともなく、「ＸＰ」の実感みたいなものが体の中に残るのでしょう．
それともう一点は、「ＸＰ」の実施に無理をしていないということです．ある程度、これなら出来るかなという感じをもったテーマに対して、「ＸＰ」で取り組もうとしていることも、好ましい結果を生む要因になっているとおもわれます．
ただ、日経ビジネスで紹介されている事例の幾つかは、「ＸＰ」で実践してみたと云うには、まだまだ不十分かと思われます．幾つかのプラクティスが効果的に実施出来た場合、おそらく、結果として「週４０時間」が達成されるはずです．それが実現していない間は、「ＸＰ」としては不十分だと云わざるを得ません．「週４０時間」というのは、別に「ＸＰ」に限られたものではありません．ＣＭＭに取り組む以前に、私自身が「週３５時間」を実現していました．構造化手法をベースとして、派生モデル開発という独自のプロセスを持ち込み、詳細スケジュールを使って進捗を把握するというやり方です．それが、今の私のＣＭＭへの取り組みの源泉になっているわけです．
あの時も、私は誰からも指示されたわけではありません．一人でやっている状態では、自身を疲弊させない方法を手に入れないと厄介なことになる、という強い気持ちが「能動」で行動させたものと思っています．二十歳半ばの時に、昨日まで一緒に仕事をしていた仲間の一人が、１５時間後には病院のベッドで部屋の天井まで血で染めて死んでいきました．息を引き取るまでの約２時間、私は部屋の隅で為す術もなく、その光景を見ているしかありませんでした．これは、私にとって一生消えない衝撃です．
プロセス改善に対する誤解
「ＸＰ」が出てきた背景には、「ＣＭＭ」の取り組みにも問題があったからだと思っています．第一は、ＣＭＭが大規模の開発を中心とした組織向けに用意されたことです．５〜１０人程度のプロジェクトも、たくさんあるはずですが、そのような組織では、ＣＭＭで勧めているような、ＳＥＰＧやＳＱＡといった組織グループを立ち上げることはできません．リソースとしても、そのような余裕は無いでしょう．それと、プロジェクトの期間も、３〜６ヶ月といったものも少なくないでしょう．そうなると、ＣＭＭなどの大掛かりなプロセス優先の取り組みは、重すぎる嫌いがあります．実際、早い段階から、ＣＭＭに対してもっと軽装にすることを指摘する動きはありました．おそらく、現場の人たちにも、そのように写ったことでしょう．
分野によっては、既に「ＲＡＤ」の流れもあって、短期間で仕上げるための開発プロセスは、求められていたのだろうと思います．ＣＭＭが、それに対して適切な解決策を提案しなかったのかもしれません．そして、ＣＭＭのようなプロセス重視の取り組みに対して、機械的であり「非人間的」というイメージも、そこから広がったのではないかと思っています．予め用意された「標準プロセス」に対して、全員が作業を合わせていくことになりますが、ここで「組織の標準」と「各自の作業のイメージ」に距離感が生まれてしまい、作業が「受け身」になってしまうことが、「ＸＰ」の人たちの攻撃に的になったわけです．
特に、日本では「ISO-9000」が、組織の実情とは関係ないところで認定されているため、審査のために余分な作業が発生しているという「事実」は、誰もが知っていることです．そういった「ISO-9000」の矛盾も、「プロセス」に対して疑いの気持ちを抱かせることに繋がっているものと思われます．大きなプロジェクトも小さなプロジェクトも、同じような（中間成果物）を書くことに意義を見出せないのも事実ですし、殆ど効果を上げない「ＳＤＲ」というレビュープロセスも、白けてしまいます．実際に、無機質な感じのするレビューが行われています．
このような「非人間的」といわれるＣＭＭの問題は、「テーラリング」をどのように解釈するかということと、プロジェクトの計画やプロセスに対する“合理性”をどのようにして確保するかということの解釈のばらつきが原因ではないかと考えています．ＣＭＭに於ける標準プロセスの「テーラリング」は、「組織の標準プロセス」から「プロジェクトの標準プロセス」へ展開するときに、不要なプロセスを省き、今回のプロジェクトに必要なプロセスを追加したり、変更したりして、プロジェクトの実情と、そこで用いられるプロセスとのギャップを埋めるのが目的です．そのためにも、組織の標準プロセスの定義は、重すぎないほうがよいと考えています．適切な粒度のプロセスであることと、そこでの定義が細かすぎないこと．関連する成果物の定義も、比較的簡単にしておくことで、個々のプロジェクト用にテーラリングせざるを得ないように仕向けることができます．
場合によっては、さらに「個人のプロセス」にテーラリングすることも勧めています．つまり、自分の責任範囲については、このようなプロセスで進めていくというものを作ることが大事なのです．この時期に「ＸＰ」に取り組んだ人たちが活き活きしていたのも、そこに「自分のプロセス」がイメージされていたからでしょう．大事なことは、人から与えられるのではなく、自分で考えることです．第一、人が考えたプロセスをそのまま上手く実行できることは容易ではありません．少なくとも、そこには明確な「理解」と「納得」が必要になります．そうなると、その作業をする人のスキルによっては、他の人によって定義されたプロセスを理解出来ないこともあります．繰り返しますが、実際に作業をする人が、「自分はこうやって進める」というものをイメージすることが大事です．
ＣＭＭの取り組みの中で、こうした自分のプロセスにするための「テーラリング」が行われていないことが、「プロセス」を血の通わないものにしてしまっているのです．逆に云うと、「ＸＰ」も、今は能動的な人が取り組んでいるので問題にならないでしょうが、やはり自分でテーラリングしないと、同じことが起きてしまうかもしれません．
もう一つ、「ＣＭＭ」の取り組みが非人間的に受け取られてしまう原因となっているのは、「ISO-9000」や「ＣＭＭ」が、その組織の文化を無視するような形で、組織の中で画一的に進めていることも挙げられます．ＣＭＭのようなものは、一々、組織の実情に合わせて定義できないので、どうしても一般化した表現になります．したがって、これに取り組む人たちの中で、自分たちの文化を考慮した取り組みに変えれば良いわけです．要求仕様書の構成や内容も、その組織の文化の影響を受けます．必ずしも同じ様式である必要はありませんし、同じプロセスである必要はありません．
ちょうど、ＣＭＭのＶ１．０の発表に合わせるかのように、ワインバーグ氏は「Quality Software Management（邦訳＝ソフトウェア文化を創る）」というタイトルで順次執筆していきましたが、この中でプロセスは組織の文化に根差していて簡単には変わらないことを指摘しています．おそらく、そこにＣＭＭの危うさを感じたのでしょう．そして、それらの文化は、そこにいる人たちの思考パターンとなって根付いていて、その思考パターンを変えないかぎり、プロセスを変えることは困難であるという．つまり、プロセスを変えるための一般的な取り組みのほかに、組織の文化を意識した取り組み方が必要だということです．
これら「非人間的」という誤解は、ＣＭＭやプロセスの改善に対する認識不足が原因していると云えます．この認識を変え、思考パターンを変えることで、ＣＭＭなどのプロセス改善の取り組みに、人間的な温かさを取り戻すことが出来ると考えています．ボーイングの中の開発組織をレベル５に導いたジョージ・ヤマウラ氏は．日本での講演の中で、「プロセスのレベルが上がっていくにつれて、そこに居るソフトウェア技術者たちは、もっと楽しく仕事をするようになった」と云っています．本当に、自分たちのプロセス、自分たちのスケジュールを考えているなら、それを上手く実行することは楽しくないはずはないのです．