７月号にインタビュー前編を掲載してから、何やかのと忙しくインタビュー後編をテキストに落とせないでいました。お待たせしましたが、ようやくインタビュー後編をお届けいたします。なお、本記事の最後にささやかな読者プレゼントも用意しておりますので、そちらにも奮ってご応募ください。
（前編を読まれていない方々のための補足）スコット・アンブラーさんは、カナダのトロント在住のコンサルタントでRonin Internationalというコンサルティング会社の経営者です。同時に、Javaプログラミング, EJB, オブジェクト指向方法論、オブジェクト指向開発プロセス等の分野でのコンサルティングや書籍の執筆を行ったりするなど広範な活動を展開している人です。最近は、アジャル 1) ・モデリング (Agile Modeling)という書籍[1]を世に出して、モデリング技術の新たな方向性を提案しようとしています。
前編では、スコット・アンブラーさんに経歴、アジャルな方法論全般、アジャル・モデリング等について伺いました。後編では、引き続いてアジャルな方法論全般、アジャル・モデリングの話、UMLについて伺い、さらに趣味やカナダでの生活について伺いました。
注) 2002年当時、Agile は日本に広く知れ渡っていませんでした。弊社では Agile を現在広まっている「アジャイル」ではなく、「アジャル」と日本語表記していました。アジャイルの歴史的な歩みを残すことも大事であると考え、アジャルという表記をアジャイルに変更しないまま公開しています。(2015年7月, オブジェクトの広場)
アジャルモデリングとアジャルな方法論について
– アジャルモデリング（以降AMと略）では、複数の専門性を備えたジェネラリストであることを推奨しています。しかし、日本での現実を考えた場合、大半の開発者がジェネラリストだと思います。その点について、北米では状況は異なるのでしょうか?
北米でも、小さな会社ではジェネラリストが多いですが、大きな組織（銀行、保険、政府等）ではスペシャリストが多くいます。そのため、 大きな組織ではスペシャリストを含む開発チームが編成されますが、そのような開発チームにおいてスペシャリストがコミュニケーションを阻害する要因になります。それは、作業に関する情報の伝達が膨大なドキュメントに頼ることになるからです。
また、スペシャリストで構成されるチームにおいて設計のレビューを行っても、専門的な知識の範囲が狭いため有効なフィードバックを行うことは困難です。同様な状況において、いくつかの専門性を備えたジェネラリストのチームであれば、広範なフィードバックを期待することができます。根底にあるのは、ソフトウエア開発は科学だという考え方です。科学であれば、理論どおりに決まったことをやればよいのですが、現実は違います。
あまり良い喩えではありませんが、ソフトウエア業界を建設業界と対比してみましょう。建設業界では、のこぎりやかなづちのスペシャリストはいませんが、ソフトウエア業界では専門性だけで仕事をしている人たちがいます。例えば、データモデリングのスペシャリストです。データモデリングのスペシャリストは、のこぎりのスペシャリストのような存在です。普通の大工さんは、のこぎり、かなづち、ドリルなど複数の道具を使いこなす技能を備えています。それは、ひとつの道具のスペシャリストであるだけでは効果的ではないからです。
一方、ソフトウエア業界ではスペシャリストとして身を立てていくことができます。EJB, Oracle, データモデリング, 要求のスペシャリストなどです。このようなスペシャリストが必要になるのは、ソフトウエアが技術的に複雑化してきているからでもあります。その反面、スペシャリストになれば素晴らしいキャリアが保証され、開発者として優秀でなくても許されます。また、キャリアを通じて同じことを繰り返せばよいのですし、効果的であることも求められません。このような状況に疑問を投げかける人は少数です。
– ジェネラリストは、勉強に対して消極的になる傾向があるのではないでしょうか？私自身は、ジェネラリストは概して新技術に対して消極な姿勢を取ることが多いように感じます。それは、新しい技術を習得したからといって、給料が上がったり、昇進できるわけでもないので無理がないことかもしれませんが。
一般な知識を備え、いくつかの専門分野を持つところにスイートスポットがあります。１つか２つの専門分野を持てば、その分野について継続的に勉強する意欲が湧いてくるでしょう。
– そのようなスイートスポットに達するのは、個人の努力に負うのでしょうか企業の支援が必要なのでしょうか？
両方です。すべての人は、自分自身のキャリアや責任を考えなければなりませんし、会社も従業員に能力開発を促すことが大切です。この両者がともに努力する必要があるわけです。
３年間のOracleの使用経験がある開発者がいる場合、データベースの仕事がある間はその開発者が必要になりますが、仕事がなくなればJavaなどを修得するように促したら良いのではないでしょうか。その開発者をお払い箱にする代わりに、２つの専門分野を修得してより効果的な人材を得ることが可能です。そのような能力開発を促すことは、会社にとっても十分なメリットがあることだと思いますし、開発者の側も転職の機会を得ることができます。開発者が転職する最大の理由は、所属している開発組織で自分自身を生かす機会がないからだと思います。
このように能力開発には、開発者個人と企業の双方の努力が必要だと思います。私は、良いスキルを持ち、学習する意欲を持ち、学習する機会を重視する同僚がいるような開発組織の一員でありたいと思います。そのような開発組織は、非常に生産性が高いですし、非常に楽しく仕事ができるでしょう。
– アジャルな方法論の中で、日本の製造業の生産方式に大きな影響を受けているというものも多いですよね。
リーン・プロダクション2)などを参考にしていることですよね。
2) "リーン・プロダクション"とは、無駄を排除し、現場の創意工夫を重視するトヨタ自動車の生産システムを支える基本思想。流れ作業に基づく大量生産システムに変わる新たな生産システムのあり方として、８０年代から９０年代初期に海外にも紹介された。
– 上司からのおおざっぱな指示を、部下が細かいレベルで何をすればよいか考えて実行するというような組織形態が取り上げられていますよね。また、大部屋で仕事をする日本の組織は、コミュニケーションという観点ではアジャルな方法論のイメージに近いわけですよね。さらに、チーム内の調和や謙虚さも重視しています。それでも、日本は北米とくらべて競争力のあるソフトウエア開発が行えていないという現実があります。それは、どうしてなのでしょう。私自身としては、議論や競争を重視し、個性や能力の多様性を重視する北米の開発組織との出発点の違いが結果や効果の違いとして現れてきているように思いますが、いかがでしょうか？
北米は個人主義に行き過ぎているため、日本のチームやコミュニケーションを重視した文化について学ばなければならないと思います。その反対に、日本は、もう少し個人主義的で意見の違いを恐れない方向に進まないといけないのかもしれません。
私は数年間空手の道場に通っているのですが、北米でも空手の道場は企業と全然違います。AMの価値の一つである謙虚さは、空手の道場で学んだことでもあります。空手の道場では、人によって上達する速度はまちまちですし、帯の色も違いますが、ともに練習し、相互に学ぶような風土があります。
そのような風土は、北米の開発組織ではまず見られません。様々な開発組織で教えると、年齢や経歴などがバラバラな場合が多いですが、共通の目標に取り組んでいるに関わらず、ソフトウエア開発についてのコミュニケーションや学習がうまく行えていないように思います。結局、コンピュータ産業ではスキルを相互に学ぶことができていないのではないでしょうか。空手の道場では、スキルを相互に学ぶこと、すなわち学ぶ文化がちゃんと生きているのです。
また、アジャルなコミュニティでは"自分自身の視野を広げる"とか、"コンピュータ業界以外の業界も見なさい"と言われています。私自身も銀行で数年前に仕事をした際にはお客さんのフォーチュンやエコノミストなどの雑誌を読み、ビジネスについて勉強するようにアドバイスされたことがあります。結局、コンピュータ業界も他の業界から学ぶことが多いですし、米国と日本の間でもまだまだ相互に学ぶことが多いと思います。
– 日本がアメリカと異なる点は、CRCモデリングセッションのようにチームで意見を出しながら共同作業することが苦手だということにも見ることができます。遠慮しすぎたり、恥ずかしがったり、馬鹿な意見を述べなかったりします。
それは北米でも常に直面する問題です。良いファシリテータ3)は、参加者にいくつか質問をしたりして、気安い雰囲気を作ったりするでしょう。どのような開発においても言えることですが、特にアジャルなソフトウエア開発では、常に正しくあろうとしたり、間違いを非難しないように気をつけた方が良いと思います。間違いは当たり前であり、変化を受け入れたら良いでしょう。そのようなことを皆が理解し、全員が気兼ねなく意見を発言できるように開発メンバーの心を開く必要があります。
3) "ファシリテータ”とは、会議の司会や進行役を意味する。CRCモデリングセッションなどのグループワークでは、少数の参加者に発言が偏らず、なるべく幅広い意見や発想が得られるようにファシリテータが会議を運営することが望ましい。
また、アメリカの強さを支えているのはリスクを取る文化であり、そのようなリスクを恐れない精神が資本主義で世界一の競争力の源になっていると思います。リスクを恐れずに、ファシリテータとして成功すれば見返りも大きいと思います。
– インドや中国の開発組織と競合するというプレッシャーが、アジャルな方法論の普及を促進する大きな要因ではないでしょうか？
北米でコンサルティングを行う人々にとっては、海外の会社の高いコスト競争力は大きなプレッシャーかもしれません。でも、これは最近始まった新しいゲームではありません。昔からIBMがコスト削減のためシステムをアウトソース4)することを勧めていましたが、海外への開発の委託にも類似した点があります。このアウトソーシングするという方式には大きな弱点があります。費用の点で有利ですが、非常に大きなコミュニケーションのバリアがありますし、ドキュメンテーションも重視されることになります。
4) ”アウトソース”は、通常システムの運用を委託する意味に用いられると思われるが、ここでは受託開発と運用委託の両方の意味を”アウトソース”という言葉で表していると思われる。
現在、北米ではそのように海外へのアウトソーシングが非常に大きな脅威だと受け取られています。しかしながら、私自身はそのような海外の会社が脅威だと思いません。アウトソーシングは、一般的にコミュニケーションの障壁がありますし、共同で作業をするのも困難ですし、お互いを理解し、効果的に仕事を進めるのが困難です。結局、技術や安いリソースだけの問題ではないのです。成功するためには、お客様との緊密な関係が必要だし、その内容を開発チームに伝える必要があります。そのようなニーズに対応しようとしたら、結局コストの上昇を招くのではないでしょうか。
また、そのような開発を委託する会社は、開発当初２週間ほどで要求をまとめ、一定の期間を経たら、魔法のように希望どおりのソフトウエアを納品されると信じています。しかし、現実はそれほど単純ではありません。開発を委託する側の会社も、ソフトウエア開発の厳しい現実に気がついたら、アウトソーシングは失敗を安くしているのに過ぎないことに気づくでしょう。
ビジネスにとってソフトウエアが非常に重要であれば、アウトソースというのは正しい解決策ではないと思います。IBMにアウトソースにするのも、インドにアウトソースするのも一緒です。
アジャルな方法論が誕生した背景は、ケント・ベックのようなシニアな開発者が従来の方法論が使い物にならないと考えたからです。そのような従来の方法論の問題点を突き止めるために、アリスター・コーバーンは広範な開発組織において開発の成功に貢献した要因を調べました。その結果、人とコミュニケーションの問題に行き着いたわけです。７０年代にフレッド・ブルックや他の人の考えたことに再び立ち戻った訳です。
その一方で、アジャルな開発を求めるマーケットもあります。すなわち、アジャルな開発でお金もうけを狙う人々もいます。そのような人々にとっては、クールな方法論や（UPやJavaのコンサルティング会社と）差別化できるものが必要です。そのような点もアジャルな方法論が誕生する背景となっています。
– AM本の発売が遅れたのは、なぜでしょうか？
執筆に時間を要したからです。（笑い）
AMについては２０００年の秋から活動していたのですが、AM本の執筆は去年（２００１年）の４月から開始しました。私自身が書いた本としては、AM本は執筆期間が短い方です。本の執筆と同時期に空手の黒帯も見えてきたので、去年の夏は本の執筆と道場通いに専念しました。
また、AM本の執筆が遅れたもう一つの原因はWebサイトを通じて様々なフィードバックを得たためです。フィードバックに対応するように努力したために、本の内容はよくなったと思いますが、結果的に執筆スケジュールが遅れました。
– AMのプラクティスとして、「次への備えが２番目のゴール」が入っているのはなぜでしょうか？
アリスター・コバーンの本[3]から取り入れました。コバーンは、開発しただけでは不十分であり、ドキュメンテーションや納品作業について考えましょうということを述べていたのです。私自身も、EUPの製造フェーズの後に運用やサポートを行うフェーズを定義していますが、それは優秀な開発者は運用やサポートのことを考えてプログラムを開発すると考えたからです。そのような運用やサポートのことを忘れないように強調したかったのでプラクティスとしました。
UMLについて
– UMLは今後さらに普及するでしょうか、それとも既に学ぶべき人は学んでしまい普及が頭打ちになるでしょうか？
XPがテストをカッコ良くしたように、私自身はAMでモデリングを行うことをカッコ良くしたいと思っています。ただ、UMLを知らない開発者はまだ多いのが大きな障害です。まだまだ、UMLを学ぶべき人々は多数います。大学の教育にUMLがなかなか取り入れられないですし、JavaやC#の入門書を見ても数１００ページのソースコードだけでモデルがない本が多く販売されています。そのような本は、詳細な技術にばかり拘わり、ソフトウエア開発を大局的に考えることを促さない点で問題があります。それでも、そのようなソースコードだらけの本が開発者に一番良く読まれています。UMLの本よりも、JXTAやWebサービスの細かい技術の本の方が人気が高いのです。残念ながら、 UMLを用いたWebサービスのアプリケーション開発などの本はまだ出版されていません。
– 「UMLを用いたWebサービスの開発」なんて、いかにもラショナルソフトウエアの人が書きそうですね。
そうかもしれません。（笑い）UMLによるWebサービス云々というタイトルの本は、じきに誰かが本を出版するでしょうね。
数週間前に、JavaOneでいくつかJavaの本を手にとる機会があり、カップリング、カプセル化、凝集度などの基本的な用語が索引に載っているか調べてみました。これらの用語を各々１章もかけて説明しろとはいいませんが、これらの言葉を説明しなければ、プログラミングのなんたるかを理解しないままに留まってしまうと思います。Javaの本はまだましな方ですが、VisualBasicの本はもっと悲惨な状況です。
AMの本でも、これらの用語が索引に載っていないのですが、設計に関する本ではないということで許してください。私の最初の本[2]には、これらの用語についての説明があります。
– 社内で技術的な話題に関するメーリングリストがあり、アスペクト指向等について議論したりしています。その中で、組み込みシステムのアーキテクチャを網羅的に表現するのに大きなレベルの機能表現が必要なのに関わらず、UMLはオブジェクトモデル中心のために詳細なレベルでのモデルにどうしても陥りがちだという議論がありました。
UMLを使ったアーキテクチャの表現については、最近いくつか本が出版されています。UMLは方法論を意図して生み出されたものではないので、そのような問題は個別の方法論で解決すべきだと思います。 私自身の著作を考えた場合, Object Primer[2]ではアーキテクチャモデリングについて言及していませんが、Process Pattern[4]では言及しています。ただ、Process Patternでの取り上げ方も非常に大雑把なものであったかもしれません。アーキテクチャモデリングについてより詳しい参考書としては、"ビジネスコンポーネントファクトリ”[5]という書籍が参考になります。いずれにせよ、方法論者はそのような問題に立ち戻り、解決策を提案すべきでしょう。
また、UML2.0ではアーキテクチャを表現するのに、パッケージ図の代わりにコンポーネント図を使うように変わってきていますよね。私自身も何年に渡りコンポーネント図を用いてアーキテクチャを表現してきました。その一方で、UMLユーザガイドではコンポーネント図は個別のDLLの構成を示すのに使われたり, UMLモデリングのエッセンスでも数ページ分の説明しか提供されていません。コンポーネント図は、軽視されてきたと思います。
– 例えば、システムの大局的な機能を表現するためにロバストネス図を使っても良いわけですよね。
厳密に言うと、ロバストネス図はUMLの一部ではありません。
プライベートについて
– Amblerさんの趣味はなんでしょうか？
いくつか趣味があり、空手も趣味の一つです。風景写真を撮影するのも趣味であり、仕事柄出張も多いので、その際にいろいろな場所を訪問し、写真を撮影しています。また、バケーションには長期の旅行にでます。昨年は、エジプトを旅行しました。今年は、まだ決めていないのですがアフリカのサハリか南アフリカか中国に行きたいと考えています。写真も旅行もこよなく愛しています。
– 非常に感銘を受けた本はなんでしょう。
うーーん。何回も読み返した本は、フランク・ハーバードのデューンシリーズかな。
– 砂漠の惑星の本ですよね。
そうです。砂漠の惑星を舞台にしたSFです。２番目の映画は、良かったですよ。
– 好きな映画はなんでしょうか。
ブレードランナーです。１０回以上見たと思います。非常に複雑な映画で、見直すたびに新たな側面を発見できます。内容の濃い映画だと思います。特にディレクターカットバージョンが好きですが、誰も理解できないくらい複雑でした。
– フィリップ・Ｋ・ディックの原作に近いイメージなのでしょうか？
そうですね。
– 空手は何年間ぐらい続けていらっしゃるのでしょうか？
９６年９月から５．５年間です。９６年に交通事故を遭い、人生についてもう一度考え直したのです。それが空手を始めたきっかけです。
– 空手の師範ですか？
黒帯びは持っていますが、師範になるためにはまだ修行を積まなくてはなりません。空手の練習を非常に楽しんでいます。
– 好きな言葉はなんでしょうか？
ソフトウエア開発について言えば、「ソフトウエア開発は、もろい(Software development is fragile)」です。たった一つの誤った判断がプロジェクトを窮地に追い込むということです。空手について言えば、「言葉は少なく、空手を多く(Talk little, karate more)」です。空手の練習に来る子供達に言い聞かせています。
– お住まいのあるカナダやトロントの良いところは、どんなところでしょうか？
カナダはクリーンで巨大な国です。アウトドアには最適な国でしょうね。トロントは、国際的な都市できれいです。たぶん、世界中でもっとも魅力的な都市だと思います。ジャパニーズタウンや中華街もありますし、イタリア人やポルトガル人の子孫の町もあり、ワールドカップサッカーが開催できるほど国際色豊かです。
大学の修士課程でアメリカ人の女性が指導教官でした。その教官は、トロントのダウンタウンで暮らしていたのですが、午後１１時に女性が単独で行動できるほど安全だったそうです。その教官が言うには、カナダの治安の良さを知ったら米国の女性の半分はカナダに移住するとのことでした。レストラン、劇場もすばらしい、ウォータフロントも楽しめます。
カナダでは米国ほど軍隊にお金を使わないため、米国よりも社会保障が充実しています。教育制度も良いでしょう。非常に住みやすい国です。
カナダに来られる際に、第１にお勧めしたいのがバンクーバーです。山岳地帯と海岸が非常にきれいです。ケベックでは、１８世紀の建築を楽しむことができます。
トロントには、大きな国際空港があるので、世界のどこに旅行するのも便利です。
– カナダ人気質と米国人気質に違いはあるのでしょうか？
例えば、銃や銃と自由の関係に対する考えが全然違います。米国では銃を持って自分を守る自由がありますが、カナダでは他人の銃を気にせず生活できる自由があると思います。どちらが本当に自由なのでしょう。カナダでは銃の所持がライセンスにより許可される方式になっており、私自身も所有しようと思えば銃を所持できます。
もう１点違うのは、社会保障制度です。何年か前に米国で一緒に仕事をした女性が、１００度5)の熱が出ても子供を病院に連れて行かないことがあって随分びっくりしました。米国では、数万円の医療費か、子供の健康かを選択しなければならないのです。そのような点では、カナダと米国は大きく異なります。
5)華氏１００度は、摂氏に換算すると３８度弱なので生死に関わるほどの熱ではないかもしれません。
– IBMのデベロッパーワークスサイトに定期的に記事を投稿されていますね。あの記事は、日本語にも翻訳されていますよ。
そうだったのですか。知りませんでした。
– あの記事の末尾に載っている写真のポーズには、何か意味があるのでしょうか？
ひどい写真ですね。あれは、古典的な思慮深いポーズです。私の姉妹が取った写真ですが、自慢できるような写真ではありません。
– 長時間に渡るインタビュー、ありがとうございました。
読者の方々へのプレゼント
本記事に挿入されていたデジカメのイメージでお気づきのように、本インタビューの終了後Scott Amblerさんに”アジャルでごじゃる”と色紙に書いて頂きました。今回は、この色紙とScott Amblerさんの著書「Agile Modeling」（サイン入り）を読者の方々へのプレゼントとして用意しました。奮ってご応募ください。
参考文献
- 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
- Cockburn, Alistair: Agile Software Development, Addison Wesley, 2001
- Ambler, Scott, and Hanscome, Barbara: Process Patterns, Cambridge University Press, 1998
- ピーター・ヘルムツ, オリバー・シムズ: ”ビジネスコンポーネントファクトリ”, 翔泳社, 2001