アジャイルモデリング(AM)の序文がスゴい

結構昔のAM本の序文がスゴいので紹介します。

アジャイルモデリング―XPと統一プロセスを補完するプラクティス (OOP Foundationsシリーズ)

作者: スコット・W・アンブラー,株式会社オージス総研
出版社/メーカー: 翔泳社
発売日: 2003/08/06
メディア: 単行本（ソフトカバー）
購入: 1人クリック: 66回
この商品を含むブログ (32件) を見る

モデリングをプロセスの中でどのようにアジャイルに進めていくかについて書かれた本。第一章「導入」にある序文が、スゴく納得感ある文章なので紹介します(改行や副題は加工しています)。

ファットなプロセスによる開発の暗黒面

きっちりと定められた開発プロセスで興味深いのは、そのようなプロセスは管理者には魅力的ですが、大多数の開発者にとっては魅力的ではないということです。

きっちりと定められた開発プロセスは、通常ものごとを管理下に置く、あるいは少なくともものごとを管理下に置いているように見せるという、中央集権的な考えに基づいています。また、そのような開発プロセスでは、数回の短時間の要求セッションに招待すれば、後は受け入れテストで必要になるまで利害関係書を無視すればよいというように、管理者はソフトウェア開発における利害関係者の役割を最小化できると考える傾向があります。

それ以外の問題として上げられるのは、プロジェクトの状況が厳しくなると、開発者はすぐに開発プロセスを捨て──不幸なことに良いことも悪いことも一緒くたに捨ててしまい、前よりもいっそう状況が悪化することが多いということです。近道は救済ではなく、デスマーチに拍車をかけて泥沼に導くものだというのが、私の経験上言えることです。

若手開発者が陥る表面的な技術習得

私は、開発者が自分たちの職業を習得する方法についてもいくつか際立った問題点があると思っています。大半の総合大学や専科大学は、初級レベルの仕事に対応できるように開発者を適切に教育しています。しかしながら、学校の教育が完全で全員が卒業証書や学位を取得したとしても、ソフトウェア開発者という職業につきものの問題は残ると思います。

ソフトウェア開発者が10代あるいは20代前半の若い時期は、技術を習得し、使うことに注力します。そのような若い年代は自分達を、Perl プログラマ、Linuxエキスパート、EJB開発者、.net開発者などと形容したりします。若者には技術だけが大事なのです。

しかし技術は移り変わるため、若手の開発者は技術を表面的に学ぶ傾向があり、学んだ技術を1つか2つのプロジェクトに適用すると、新たな技術や以前使った技術の焼き直しをさらに学びます。
結局それは、手を変え品を変え同じ低レベルの基本的なスキルを繰り返し学び続けているに過ぎません。

中堅開発者の学び

幸いなことにほとんどの開発者は、技術を何ラウンドか学んだ後にこのことに気づきます。
COBOL、 Java、C#でトランザクション制御のコードを書いたら、基本は変わっていないことに気付くでしょう。様々な環境でのデータベースアクセス、ユーザインターフェースデザイン、その他についても同様なことが言えます。

ほどなくして、開発者は学校で教わったものであろうとなかろうと、基本的な多くのことは技術の違いに関わらず変わっていないことに気付きます。

大抵の開発者は、20代後半もしくは30代前半──身を落ち着けて結婚し、家を買ったりするような年頃に至って、このような認識を得るのです。そのような認識は、環境の変化などにより新技術を学ぶのに膨大な時間を費やすことが許されなくなった開発者にとっては幸いなことかもしれません。

新技術を学ぶ代わりに、家族と一緒の時間を過ごすことを望むでしょう。そのような開発者には、新技術を学ぶためにたゆまず一生懸命努力することを求められないプロジェクトリーダー、プロジェクト管理者、モデラーのような上級の役割が、ふいに魅力的に思えます。

そのため、開発者は開発者としての役割を終える段階まで至って初めて、本当の技能を学び始めるのです。

幸いなことに、新たに若者が入ってきて、そのサイクルを繰り返すことになります。結局、ソフトウェア開発の中心を担う人たちの大半は、得てして職務に関して熟練しておらず、自分達が未熟であることすら気付いていません。

関与しない顧客と、それを受け入れる開発者

ビジネス側の状況も大差ありません。顧客はどのようにソフトウェアが開発されているのかを理解していませんが、落ち着いて考えると、そのこと自体は至極最もなことです。

私はソフトウェア開発とは途方もなく難しものであるがゆえに、ソフトウェア開発に際するいろんな選択肢の得失について十分理解していると思われる開発者はほとんどいないと思います。さらに、顧客は一般的に自分たちが良く理解していない複雑なプロセスに参加することに、あまり興味を持ちません。そのため、そのようなプロセスでは自分達の本来の業務に戻れるように詳細には立ち入ろうとしません。

顧客は、プロジェクト最初の要求ワークショップに1、2回参加し、開発途中に主な文章をレビューし、開発の進捗とともに良いことづくめの(たとえ時として偽りがあっても)ステータス報告を受け取り、納品の直前に受け入れテストに立ち会い、大抵の場合予算も期間も超過してやっとシステムを受け取るというような、限定的な関与を受け入れています。

これが当たり前の姿であり、ITプロフェッショナルは顧客にこのようにしなければならないと説明し、顧客は何が起こっているのか質問しようとすら思わないのです。

このような状況に甘んじている顧客も奇妙です。顧客が私達に依頼しているのは自分達のニーズに効果的に合致するソフトウェアであるにも関わらず、開発者がお客様に提供するのはレビューのための膨大な文章、いくつかのステータスレポート、いくつかのテストであり、順調にいけば最後に何らかのソフトウェアが納品されます。言い換えれば、現在のやり方は私達開発者が提供したいものを提供しているのであり、顧客が私達に望んでいるものを提供しているのではありません。

本書で後述するように、プロジェクトの利害関係者がもっと積極的にプロジェクトに関わることは可能ですし、必要です。私達開発者は、自分たちの開発プロセスを顧客に受け入れられるものいにするように心がけるべきです。