オブジェクトの広場の４月号で予告してから、随分日数が経ってしまいましたが、ようやくスコット・アンブラー（Scott Ambler）さんに対するインタビューの前半部分を原稿に落とすことができました。
スコット・アンブラーさんは、カナダのトロント在住のコンサルタントでRonin Internationalというコンサルティング会社の経営者です。同時に、Javaプログラミング, EJB, オブジェクト指向方法論、オブジェクト指向開発プロセス等の分野でのコンサルティングや書籍の執筆を行ったりするなど広範な活動を展開している人です。最近は、アジャル 1) ・モデリング (Agile Modeling)という書籍[1]を世に出して、モデリング技術の新たな方向性を提案しようとしています。
ObjectDayの講演収録後、スコット・アンブラーさんに経歴、アジャルな方法論全般、アジャル・モデリング等について伺いました。
注) 2002年当時、Agile は日本に広く知れ渡っていませんでした。弊社では Agile を現在広まっている「アジャイル」ではなく、「アジャル」と日本語表記していました。アジャイルの歴史的な歩みを残すことも大事であると考え、アジャルという表記をアジャイルに変更しないまま公開しています。(2015年7月, オブジェクトの広場)
これまでの経歴
– これまでソフトウエア業界でどのようなお仕事をされてきたのでしょうか？
私のソフトウエア開発経歴は、高校でFORTRANを学んだことからスタートしました。大学時代はアートとサイエンスを専攻し、学業の傍ら友達とコンサルティングの仕事を行っていました。大学を卒業後、銀行に就職し、２年間勤務しました。その当時、チームリーダとして数名の学生とともにメインフレーム向けのソフトウエア開発を行っており、毎週ソフトウエアをリリースするインクリメンタルな反復型開発を行っていました。私達のチームは、１０－１５人のCOBOLの開発チームと競争して開発を行っていたのですが、常により短期間により多くの機能を提供できていました。結果的には、COBOLのチームの開発方法を変えるのは難しいと上司が判断し、私達の開発チームが解散させられました。
その後大学の修士課程に戻り、情報科学を専攻しました。８０年代中旬には、dBASEのアプリケーションなどを作っていました。銀行向けのコンサルティングを行いながら、"これからはオブジェクト指向の時代だ"と確信してオブジェクト指向の勉強を行いました。当時、オブジェクト指向技術の将来性を説いても他の人は信じてくれませんでした。インターネットの将来性についても確信していました。
やがて、C++とSmalltalkの大きな波が来ました。私自身は、Smalltalkを選択し、通信、顧客サービス等の実用システムをいくつも開発しました。そのようなオブジェクト指向開発の経験を経て、'９５年Javaに移りました。’９５年のOOPSLAからJavaが注目され始めたのですが、タイミング良くJavaで開発を行いたいというお客様にもめぐり合い、Javaの経験を積むことができました。その当時モデリングもいろいろ行っており、構造化手法も使っていましたが、それでは十分ではないと気がつきました。また、オブジェクトーリレーショナルマッピング 2) についても興味を抱きました。データモデリングの経験があったので、ごく自然にオブジェクト指向技術との対応に興味を抱いたのです。
2) Javaのようなオブジェクト指向言語で関係データベースのデータを操作するための実装メカニズムのこと。オブジェクトーリレーショナルマッピングについては、[2],[3]の書籍で言及されている。
最近は、EJBによる開発[4]と開発プロセスに力を注いでいます。当初は規定的なプロセスに力を注いでいた 3) のですが、その後アジャルなプロセスにも取り組んでいます。現在は、プロジェクトの性格に応じて、UP、XPやAMなどから自分に適したプロセスを選べば良いと考えています。
3) Process Patterns[5]、及び、More Process Patterns[6]という著作で、OOSP(Object Oriented Software Process)というオブジェクト指向開発プロセスを独自提案している他、UPの独自拡張であるEUP(Enterprise Unified Process)というプロセスフレームワークも提案している。
– 学生時代からコンサルティングを行うのは、良くあることなのでしょうか？
私はとがった学生だったと思いますが、８０年代にトロントはカナダの金融業の中心地であり、すごく景気が良かったという事情があります。開発者が不足していたこともあり、２０代の学生がコンサルタントとして働き、dBASEのアプリケーション等を開発していました。
– 近年、開発プロセスに力を注いでいるのはどうしてですか？いろいろ、Java言語、EJB、モデリングなど様々な方面で仕事をされてきたと思うのですが、開発プロセスはちょっと違いますよね。
どのようにソフトウエア開発を行ったら良いかという点については常に関心をもっていました。技術の移り変わりとともに過去dBASE, C, COBOLなども使いましたが、本質的な問題はかわりません。オブジェクト指向の世界ではパラダイムシフトも必要ですが、プロジェクト管理、どのようにテストを行うか、リスクへの対処などハイレベルなことも大事です。技術は移り変わっても、これらのハイレベルのことについての基本は変わっていないと思います。
また、過去Smalltalkで開発を行ったプロジェクトにコンサルタントして加わり、非常に悲惨な失敗を経験しました。それまで、自分自身が直接の当事者として開発を行ってきたのですが、そのプロジェクトが初めて自分自身が直接の当事者ではないプロジェクトだったのです。そのプロジェクトの失敗に直面し、改めて過去の開発の進め方を振り返ると、開発中に行った様々な判断を合理的に説明できないことに気がつきました。だから、自分自身が当事者でない開発チームに開発の進め方をはっきり示せなかったのです。
その失敗したプロジェクトのお客様からも失敗の原因を究明するように依頼されました。その時の結論は、経験的には開発の進め方を理解していたに関わらず、プロセスを具体的に定義していなかったことが失敗の原因であると考えました。そこで、数ヶ月間でプロセスについて改めて考えてみました。その考えが後のプロセスパターンの本([5], [6])へと発展したのです。
私が書いた最初２冊の本([2], [3])は、"オブジェクト指向のソフトウエアをどのように開発すればよいか"という質問を開発者の観点で解説したものですが、プロセスパターンの本([5], [6])は同様な質問に対する管理者の観点で解説したものになっています。
アジャルな開発アプローチに関する質問
– アジャルな開発アプローチが盛りあがっていますが、アジャルな開発アプローチは従来のアプローチとどこが違うのでしょうか？従来のアプローチはどこが問題だったのでしょうか？
アジャルなアプローチは、"人々"を重視している点で従来のアプローチと異なります。従来のアプローチの最大の問題点は、料理本的な考え方に基づいていた点だと思います。すなわち、ソフトウエア開発を何が何でも予測できるようにしたいと思った結果、プロセスをソフトウエア工学的な立場で料理本のように定義し、それに従って開発を行えばよいというアプローチに至ったのです。それは、フランス料理の本を頼りに、マクドナルドのハンバーガーを作れというようなものです。また、このようなアプローチは、プロジェクトの成功に寄与するスキルなどの因子を無視しています。
それに対して、アジャルなアプローチでは、ソフトウエア開発は人々やチームの協同作業であり、コミュニケーションを重視し、完璧であることを求めませんが、各開発者が一定のスキルを備え、他のメンバーと積極的に連携し、常に新たな事を学ぶような開発組織を目指しています。これは、"ソフトウエア開発は、理論に従えば決まった結果が得られる科学ではない"という立場です。
ソフトウエア業界は、過去１、２世代に渡り、ソフトウエア開発を一生懸命工学や科学の立場で説明しようとしましたが、そのような試みは成功していないと思います。結局、ソフトウエア開発は科学ではなく、また作業を定型化できるものではないのです。これは多くの組織が直面している問題です。アジャルなコミュニティは、ソフトウエア開発に対する考え方を原点に戻し、成功を収めるための新たな方法を探求したのです。
アジャルなコミュニティで主導的な立場の人々には、Smalltalkを使う開発者やかつて使っていた人々が多数います。Smalltalkで開発を行うと、迅速に開発を行えますし、小さなチームで非常に高い生産性が実現できたのです。それに対して、C++派の人々は比較的少数派です。Smalltalkコミュニティは、C++のコミュニティほどハードウエアや技術を重視していなかったため、コミュニケーション、チーム開発の問題などに注目したのだと思います。また、ソフトウエア開発に集中し、現実にユーザが直面している問題の解決を目指している点がアジャルなコミュニティの特徴となっています。
アジャルなアプローチは、開発者がジェネラリストであることを求めている点が既存の開発者の一部には脅威だと受け取られています。正確に言うと、いくつかの専門性を備えたジェネラリストを指向している点は、これまで１つの分野だけの専門家であった人々には大きな脅威です。例えば、プログラミングだけという専門家には受け入れがたいと思います。また、チーム作業を効率化するためにコミュニケーションスキルが重要になってくる点においても、より一般的なスキルが重要になっているということができます。
– いろいろな開発組織を訪問して、特定の方法論、開発プロセスを使わない組織が結構多いことに気がついたのですが、そのような人々にアジャルな方法論は影響を及ぼすでしょうか？
そうですね。いくつかの異なった面での影響が考えられます。まずは、マーケティング的な影響です。XP(eXtreme Programming)を考えてみてください。XPがもしUnified Programmingという名称だったら、まるっきり同じような内容を主張しても今のように流行らなかったと思います。ScrumやDSDM 4) は、XPと違う点もありますが、類似点が多かったにも関わらず流行りませんでした。
4) ScrumやDSDM(Dynamic System Development Method)は、長い歴史を持つアジャルな方法論です。
XPは、その命名がカッコよかった(cool)のが、流行った一つの要因だと思います。このようなカッコ良さの度合いが、非常に重要だと思います。"XPって、カッコ良さそう。やってみよう！"というような具合です。また、ケント・ベックはXPによりテストを行うこともカッコ良くしました。これは、画期的なことです。テストの専門家が、今まで頑張ってもできなかったことが実現されたわけです。XP以降、みんながテストファーストデザインについて話をするようになりました。
アジャルな方法論は、簡単そうに見えますが、実際のところ今まで方法論を使わなかった組織で実践するのが簡単なわけではありません。ただ、まだ実践可能なレベルだと思います。
– アジャルな方法論の普及を阻むものとしては、どのようなものが考えられるでしょうか？
XPという名称は、開発者にとっては魅力的ですが、マネジャーにとっては必ずしもそうではありません。すでに現状行っていることがXPであり、もうこれ以上のXPはいらないと（理解しないで）拒否するマネジャーがいます。このような誤解がアジャルな方法論の普及を阻む１つの要因です。
また、チームで開発をするということを求める点を難しいと感じる開発者もいるでしょう。アジャルな方法論では、開発者に一定のコミュニケーションスキルや人間関係のスキル、他の人と一緒に作業を行い、互いに尊敬することなどが求められますが、人によってはこれらが苦手だという人もいます。これらのスキルを向上させるためには、ある程度経験が必要です。その点で、若手の人はこのようなスキルにおいて弱い傾向があります。また、若手の人は粋がって個人主義に走る傾向もあります。
一方で、開発組織の文化、風土にも阻害要因があります。XPのように大部屋に開発チームのメンバーが一堂に会して開発を行うスタイルは、キュービクル5)や個室を各開発者に与える階層的な開発組織で実行するのは困難です。私は、「ソフトウエア開発は、壊れ物」という言葉好きですが、ソフトウエア開発では、たった一つの誤った判断が死を招くのです。プロジェクトの初日に、キュービクルや個室のままで開発を進めるように決断したことが、命取りになることもあります。キュービクルや個室の文化は、コミュニケーションを著しく阻害しますが、そのことについて理解を得るのは困難です。
5) 開発者に割り当てられるパーティションで区切られた四角いスペース。北米では、個室よりも一般的に見られる。
– 日本では、大部屋オフィスは当たり前でめずらしくありません。キュービクルも、贅沢だと思われています。そういう意味でXPではもてはやされている大部屋での開発というのは、日本の開発者にとっては新鮮味がないような気がします。また、往々にしてプロジェクトが危機に瀕している場合に、会議室に缶詰になっての開発を強いられたりすることも多く、大部屋での開発についてそれほど良くないイメージを持っています。
北米の開発組織では、一緒に作業をするということを受け入れるのは大変ですし、大部屋で開発することも大変なことです。ただ、アジャルな方法論はそれだけではありません。ユーザの要求を抽出したり、具体化したりする点もアジャルな方法論の特徴です。ソフトウエア開発においては、品質、リソース、スコープ（＝開発範囲）の３角形のトレードオフが常に問題になりますが、アジャルなソフトウエア開発手法及びAMでは品質において妥協しません。その結果として、リソース、スコープの２点が開発を進める上でのパラメータになります。
また、共通の理解を持ち、各メンバーが基本的なことを理解することも大事です。日本では、基本が理解されているかもしれませんが、米国ではそうではありません。先週、品質、リソース、スコープの３角形の話をあるお客様にしたところ、そのような基本的なことですら感心される始末です。
– 日本では、オンサイトカスタマーがXP導入の一番大きな壁になるという意見があります。また、AMでも積極的な利害関係者の参加を推奨しているので同様な壁に直面すると思いますが、北米ではそのようなことはないのでしょうか？
それは、北米でも同様に大きな壁です。システムの要求を決定するのが主業務という人は、まずおりません。そのような人は、本業を持ち、業務の中心となる人が多く、忙しく、上司も関わるのを許しません。
これまで２世代の間、開発者はプロジェクトの最初の数週間でインタビューを行い、６ヶ月から１、２年の期間に渡って開発を行い、受け入れテストを行う方式に慣れ親しんできたわけです。そこに、アジャルなコミュニティが登場して、６ヶ月間ずっと開発チームの疑問を調査してくれ、決断してくれ、間違った憶測を正してくれる人を割り当てて下さいと主張しているわけです。そのような役目の人を確保するには、非常に困難ですし、これは大きな壁です。
そのためにいろいろな代替手段を考えますが、フルタイムの協力者が得られないからといって要求内容を勝手に作り上げるというのは大きな間違いです。何年か前、私自身コンサルタントとしてお客様の代わりに要求を定義することを依頼されたことがあります。私は、依頼された会社の業務にも通じておりませんし、結果としてプロジェクトは失敗しました。
一方で、開発者がプロセスに従って機械的に要求を書き留め、モデリングを行い、開発を進めることもよく行われています。開発者は、どうしてこのような要求に至ったかという背景を理解せずに開発を進めるわけです。このような開発は間違っています。開発者としては効率的に開発を進められますが、結果として提供されるシステムがお客様のビジネスにどのように貢献するか考えられていないからです。
AM（アジャル・モデリング）に関する質問
– AMが解決しようといているのはどのようなことでしょうか？
２点あります。モデリングを効果的に行う方法、ドキュメンテーションを効果的に行う方法の２点です。XPがテストをカッコ良いものにしたように、私はモデリングをカッコ良いものにしたいのです。モデリングは、手書きで行えば十分だと思います。"何年間も手書きでモデリングを行っていたけど、モデリングツールを使わねばモデリングを行っていたことにはならないと思っていました"というような発言に出くわしますが、モデリングを行うためにモデリングツールは必ずしも必要ありません。白板で十分です。
また、モデリングを効果的に行うという観点では、この成果物を作り、次にこの成果物を作り、１件落着というような機械的な方法論とは１線を画します。AMでは、モデリング手法として、いろいろな手法を身につけ、必要に応じて適切な手法を選ぶことを推奨しています。
ドキュメンテーションを効果的に行うという観点では、ドキュメントを一切書かなかったり、電話帳のように分厚いドキュメントを作るというのは間違いです。その両者の中間に、望ましいポイントがあるのです。AMでは、そのような望ましいポイントを提案していきたいと考えています。
– AMは、すべての開発者を対象としたものなのでしょうか。現実的に考えると、ある程度のモデリングスキルが前提になると思うのですが、いかがでしょう？
それがAMの最大の弱点です。私自身は、AMを実践するために広範なモデリング手法が必要であることは包み隠さず説明しているつもりです。UMLは、そのようなモデリング手法の一つですが、UMLだけでは不十分です。UML以外に、データモデリング、 ユーザインターフェイスモデリング、ビジネスルールモデリング、代替案(change case)等いくつものモデリング技術を併用した方がよいでしょう。このような広範なモデリング技術を身に付けることは結構大変です。XPの場合でも、プログラミング、テスト、設計、コミュニケーション等の複数のスキルを求めています。XPもAMの場合も、少しずついろいろなスキルを身につけていく気持ちがあれば誰でも修得できると思います。
UMLには、良い点と悪い点があります。UMLは、標準だというのは良い点です。その一方で、UMLだけですべて事足りるというのは間違いです。例えば、データベースの設計やユーザインターフェイスデザインに全然言及せずに、UMLだけでシステム開発を説明しようという本や方法論には大きな疑問を感じます。現実には、データベースの設計やユーザインターフェイスデザインを必要としているプロジェクトも多いのです。その分野では、いろいろな方法論者が独自のやり方を提案しているのが現状です。だから、UMLだけでは完全ではないのです。同様なことはWebサービスについても言えます。Webサービスは、機能を抽象化したものであり、UMLではうまく表現できません。
結局、自分自身で適切な成果物を選ばなくてはいけないのです。そのために、AMの本では３０のモデリング手法を挙げています。モデリング手法の修得は、簡単ではありません。私は、ハードルを高くしているのです。UMLを修得するだけでもかなり苦労する開発者が多い中、それ以上のものを求めているという意味でハードルを高くしていると言えると思います。
– AMは、XPほど実装中心の開発を行いたくないが、同じことの繰り返しに飽きた経験を積んだ開発者に受けるような気がしますが、どうでしょうか？
AMは、XPよりもベテランの開発者向けだという意見を述べる人は多いです。AMは、モデリングやドキュメンテーションを全面に出しているというのが良いという人もいます。但し、AMは開発すべて網羅する方法論ではありませんので、ベースとなる何らかの方法論が必要です。
– AMの原則やプラクティスは、まだきれいに整理されていないような気がします。それは、モデリング作業を行う上で発生する問題や落とし穴を全面に出して説明していないことにも起因していると思うのですが、如何でしょうか？
AM本では、XPやUPへの適用例だけではなく、要求、設計などの開発ステップ毎にAMをどのように実践するかという点を説明した例を当初用意するつもりでしたが、時間が足りませんでした。AMのプラクティスを実践した事例については、他の人が本を執筆する予定です。私が、AMの唯一の情報発信源というのはよくありませんからね。
– （前の質問が十分伝わっていなかったので再度同じ質問）"開発当初にモデリングに時間を費やしすぎる"等モデリング作業を行う上で発生する典型的な問題点を先に説明した方が、AMの原則やプラクティスの位置付けが理解しやすくなるのではないかと私は思いますが、如何でしょうか？
そのような観点では、私はモデリングアンチパターンというエッセイを書きました。そのエッセイでは、過剰なモデリング、モデリングを一切しない、過剰なドキュメンテーション、単一のモデルしか使わない等上位１０位のアンチパターンをリストアップしています。
– そのような典型的な問題点を説明した方がAMのプラクティスや原則の意図が理解しやすいと思います。
– AMには、XPの４つの価値に加えて"謙虚さ"が価値として加えられていますが、なぜAMに"謙虚さ"が価値として加えられているのでしょうか？
ＸＰには、何かが欠けていると感じたからです。数年前に参加したプロジェクトで、アーキテクトの一人がお客様の要望に全然耳を傾けなかったことがあります。そのアーキテクトには、本当は要求を勝手に作り上げるのではなく、要求を理解し、アーキテクチャの観点で交渉することが求められたのだろうと思います。そのように、自分が一番分かっていると思い込んで、他人の意見を軽視する開発者は多いのではないでしょう。
また、自分がヒーローだと思いたがる開発者もいます。そのような例として、毎週末に他の開発者が開発したコードを変更して回るような開発者に出くわしたこともあります。その開発者は、４６時中働き尽くめでした。自分の人生にとっても、プロジェクトにとってもそんなことは効率的ではないと気がつくためには謙虚さが必要ではないでしょうか。北米では、このような謙虚さが欠けています。特に、大きな開発組織でアーキテクチャに責任を持つ人において、他の開発者に対して謙虚さが欠けていると思います。AMのコミュニティでは、このような状況を防ぎたかったのです。
今後の予定
以上が、スコット・アンブラーさんとのインタビューの前半（3/5）です。後半の部分では、技術的ではない質問も行っていますので乞うご期待を。根性と時間が確保できたら、来月号にインタビューの後半を掲載します。
スコット・アンブラーさんの主な著作リスト
- Ambler, Scott: Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, John Wiley & Sons, 2002
- Ambler, Scott: The Object Primer (2nd Edition), Cambridge University Press, 2001
- Ambler, Scott: Building Object Applications That Work, Cambridge University Press, 1998
- Roman, Ed, Ambler, Scott, and Jewell, Tyler: Mastering Enterprise Java Beans (2nd Edition), John Wiley & Sons, 2001
- Ambler, Scott, and Hanscome, Barbara: Process Patterns, Cambridge University Press, 1998
- Ambler, Scott: More Process Patterns -Delivering Large-Scale Systems Using Object Technology (Managing Object Technology Series, 19), Cambridge University Press, 1998