Jonathan Rasmusson さんインタビュー ( 後編 )

前編を公開してから9ケ月も経過してしまいましたが、ようやく「アジャイルサムライ」の著者であるRasmusson さんインタビューの後編の原稿をまとめることができました。

インタビュー後編では、以下について伺った内容を紹介します。
1. 「アジャイルサムライ」の内容について
2. モチベーションとコーチング
3. 日常生活
4. 「アジャイルサムライ」の執筆
5. 今後の夢

1. 「アジャイルサムライ」の内容について

-- 次の質問は、Jonathanさんの著書である「アジャイルサムライ」についてのものです。私は「アジャイルサムライ」を読んで少し混乱しました。アジャイル開発フレームワーク「スクラム」ではプロダクトオーナーとスクラムマスターという2つの役割を設定しますが、「アジャイルサムライ」ではアジャイルコーチ、プロジェクト管理者、顧客が登場します。なぜスクラムと異なる役割を推奨されているのでしょうか？

少し歴史について説明します。私がアジャイルを初めて知った時に私の拠り所になったのはXPでした。スクラムは非常に普及しており、北米でも普及しています。私が書籍の中で意図的に使った言葉で、反復はスプリントの意味であり、顧客はプロダクトオーナーの意味です。スクラムは近年急速に広まったために、XPが提唱した技術的なプラクティスなど本当に良いことを忘れてしまうことを懸念しています。そのために、「アジャイルサムライ」の4つの章を割いて「単体テスティング」、「継続的なインテグレーション」、「テスト駆動開発」、「リファクタリング」を説明しています。

スクラムの難しさとしてもう１つ発見したのは、スクラムには仰ったように2つの役割がありますが、プロジェクトには（それ以外の）予め決まった役割がないとしていることです。開発チームという役割はシンプルなので、何を行えばよいかを考え出せます。自己組織化です。私が何をやり、あなたが何をやればよいということですが、スクラムを導入するためのガイダンスが不足しているので企業によってはスクラムの導入に苦労します。

「5年間に渡り、私は分析者でした」という人が突然自己組織化で行こうと言われても、プロジェクトで自分が何を行ったらよいか分からないのです。開発者が機嫌よく、直接顧客と話をするようになれば、「私は必要とされていない」ということになりますよね。自分の立場が危ういわけです。ということであれば、スクラムに対する興味はなくなりますよね。自分の仕事が危うくなるからです。 QA担当者が以前書いていた単体テストを、開発者が書くようになれば、QA担当者もプロジェクトにおいて自分の役割が見つからなくなります。単に自己組織化して、XPを実行し、開発者が顧客と直接話をする中で締め出されて惨めな気持ちになるのです。

私はそのようにアジャイルプロジェクトの役割を示したくありません。ちなみに、スクラムにおいて私が同意するのはアジャイルプロジェクトでは役割が非常にあいまいであるという点です。別の言い方をすれば、品質は明らかにチームの責任になります。サイクルの最後にプロダクトのテスティング時の品質について1人の人や１つのグループを責めるというのは全然意味がありません。品質が1人の人や1つのグループに帰属するという考え方を止めないといけません。品質がチームの責任ということは何を意味するでしょうか。開発者、分析者が品質の一部に責任を持ち、プロジェクト管理者も品質の一部に責任を持ちます。プロジェクト管理者が責任を持つのは優先順位をつけ、何を先に作るかという点です。

私は、従来の開発コミュニティの人たち全員が安心できるようにアジャイルプロジェクトの役割を提示したいと考えています。「ここに自分たちの役割があるぞ！」、「分析をまだ行う必要がある」、「テスティングをまだ行う必要がある」、もちろん「プログラミングをまだ行う必要がある」、「プロジェクト管理もまだ行う必要がある」というようにです。１人の人が１つの役割だけを果たす必要はありません。アジャイル開発においてユーザビリティも検討します。専任のユーザビリティの専門家が必要なプロジェクトがどれほどあるでしょうか。ほとんどないですよね。ではユーザビリティは検討しないのでしょうか。いえ、検討します。開発者、分析者、プロジェクト管理者などのプロジェクトの誰かが検討するのです。

このような理由で「アジャイルサムライ」では従来の開発コミュニティの人たちが安心してアジャイルを受け入れられるように、アジャイルコーチ、プロジェクト管理者、顧客などの形で役割を示したのです。アジャイルプロジェクトでも分析者として仕事をすることができるのです。少しあいまいなところはあります。言いかえれば、恐れる気持ちを抱かせるべきではないのです。 QA担当者であれば、分析結果からテストを書けばよいのです。ということで、私はスクラムのプロダクトオーナーやスクラムマスターという役割をあまり取り入れず、従来の開発上の役割を示したのです。その形で、企業への導入に成功して来ました。従来の開発の役割を受け止め、それらの役割がアジャイルプロジェクトでどのように変わるかを示したのです。

-- 「アジャイルサムライ」では「アジャイル分析者」という役割を示しておられますが、同時に「要求という言葉が嫌いだ」とも書かれています。

-- でも「アジャイル分析者」という言葉からは、要求の抽出や分析を行い、膨大ではないドキュメントを作成する役割ではないかと推測しました。この推測は正しいのでしょうか？

言いたいことが2点あります。1点目は、私は「要求」という言葉が嫌いだということです。ひどい言葉だからです。御希望があればどうしてひどいのかを説明します。 2点目は、要求という言葉がこの業界で非常に長い期間使われてきたので、私もコミュニケーションのために要求という言葉を使う時があります。「要求」と言えば、ほとんど人がその言葉のソフトウェアプロジェクトでの意味を理解できるからです。そのように、コミュニケーションのために「要求」という言葉を使う時があります。

しかし、プロジェクトで腰を落ち着けて仕事をする時には「要求」という言葉を使わないようにします。「顧客がソフトウェアにどのようなフィーチャーを見たいのか」ということであり、「要求」ではないからです。私たちはおそらく80%のシステム機能をたった20%のソフトウェアで作り、納品できることを知っています。別の言い方をすれば、この業界は想像できるだけのありったけの機能をプロジェクトに飲ませ、時間や予算内にそれらすべてを作れなければ、「要求」と呼んだものを納品できていないではないかと責める訓練を長く行ってきたのです。 50%しかできていなければ、残りの50%はどうしたんだと言われるわけです。これが「要求～♪」です。(笑）

でも、本当はそれらすべてが「要求」ではないのです。実際には必要がないからです。大半の価値を10%のもので提供されるかもしれません。 20%が必要だったとしても、80%はほとんど使われないかもしれません。これが私が「要求」という言葉が嫌いな理由です。

「分析者」の役割についての話に戻ると、「分析者」はこれらの10-20%の本当に価値がある機能を特定する役割を担います。さらに、開発中ではこれらの機能を深く分析し、開発者が開発できるようにそれらのフィーチャーを具体化します。

-- 類似した質問として、アーキテクチャと設計に関するものがあります。ハイレベルのアーキテクチャ設計はインセプションデッキに含まれると思うのですが、それを開発者はもっと洗練していくべきなのでしょうか？

私は、その人が適切だと考えることはどんなことでもお薦めします。インセプションデッキのレベルでアーキテクチャの図あるいはソリューションの姿を作成するのは、実際には開発チームの残りのメンバーの期待を設定する練習です。期待を設定するのは、解決策がどのような姿かについてのアイデアがあることをチームに知って欲しいからであり、それに問題があれば懸念をその時点で聴きたいからです。

C#の経験があってJavaの経験がなければ、それは大きな問題ですよね。どのような技術を使おうとしているのか、それはオープンソースのフレームワークなのか、企業でオープンソースソフトウェアを使うことが許されるか、ということが問題なのです。それらが問題ならば、なるべく早く知りたいですよね。そのため、可能な限り解決策の姿を描いてみせ、チームがそれに乗っかり、企業側で予算に責任を持つ人たち全員がそれに好感を抱き、確実に全員の足並みが揃っていることを確認しなければならないのです。

iPhoneのアプリならばObjective-CとiOS上のアプリケーションを知っていなければなりません。AndroidならばJavaです。ということで全体として適切なチームであるかを確認するのに役立ちます。解決策について議論を持つことで、全員が技術、チーム、スキルセットについて足並みがそろっているかを確認できるのです。インセプションデッキを終え、プロジェクトが開始するところでどのように進めるかはプロジェクト次第です。

ハイレベルなアーキテクチャでは単にWebアプリだとか、.NETプロジェクトだとか、ブラウザとIISサーバでバックエンドはオラクルだというレベルで十分であり、とてもシンプルです。データベースからデータを取り出し、スクリーンに表示するだけです。トレーディング会社のメインフレームのレガシーアプリだと、TIBCOのサーバがここにあり、IBMのサーバと通信し、テスティング環境がなく、高いリスクを伴い、メインフレームとの通信は全然行えず、そこにまったく新しいRESTfulなAPIの設計を行い、iPhoneのエクスペリエンスを提供する場合、それを図示してそのリスクをすべてのメンバーに知らせたいと思います。

誰も経験したことがないリスクで問題が起きるかもしれず、データを所有しているのは別のグループなのでデータを取り扱う前にそのグループへの橋渡しを行い、プロジェクト管理の観点ではプロジェクトを成功させるために必要なことを図にしようということになるわけです。これらのことがもたらすかもしれない痛みと懸念を検討するためにある程度の時間と手間が必要になります。さらに、メインフレームのデータを管理している責任者にも橋渡しをするのです。

チームがプロジェクトを実行し始める時点では、その図を外してもよくなるかもしれません。プロジェクト次第です。アプリケーションサーバがWebLogicでサーバサイドJavaだったものが他のものになれば、図を更新してもよいかもしれません。チームが健やかで堅牢なアーキテクチャを作るために必要なものを作ればよいのです。

-- 書籍でレガシーコードをリファクタリングする話が記されているのですが、それはご自身の経験に基づくものでしょうか？お客様と話をすると、割と良く「アジャイルソフトウェア開発はレガシーコードの保守や拡張に適用にできるのか」という質問を頂きます。

テストの自動化によりバックアップされており、リファクタリングができて、よく設計されたものであれば、レガシーコードの保守はより容易になります。そのような場合には、確かにアジャイル開発が活躍する余地があります。テストが自動化されていないシステムを受け継いだ場合には、..。

大量のドキュメントとともに、そうですね。私はドキュメントを信じません。ドキュメントになっていません。

現状を表していないドキュメントです。私だったら、実際のところを調べるためにコードを見ます。コードはドキュメントのようにうそをつきません。アジャイル開発を適用できますが、そのような単体テストが自動化されていないレガシーシステムでのリファクタリングは明らかに新たにコードを書くプロジェクトよりもはるか慎重に行う必要があります。

そのため、レガシーシステムに対する変更は慎重に行う必要があります。システムに精通した人とともにもっとしっかりピアレビューを行い、さらに変更を加える箇所の周辺の単体テストの自動化を行います。システム全体ではありません。変更を加える箇所の周辺だけです。費用はかかりますが、同じ原則を適用できます。

-- たぶんJonathanさんが仰っているレガシーシステムは2000年頃に開発されたものですよね。

-- 日本にはCOBOLのレガシーシステムを所有している会社が多いのです。

COBOL? COBOLを相手にしなくてはいけない人は大変ですね。私はよく分かりません。

-- 日本にはCOBOLのレガシーシステムがいっぱいあるのですよ。

こちらでもCOBOLのシステムがあり、バージョン管理がされていないものすらあります。

私は、そのように年季の入ったCOBOLのシステムを相手にした経験はありません。ただ、原則は適用できるのではないかと思います。 COBOLも知りませんし、COBOLの単体テストフレームワークがあるかも知りませんが。ただ、とっても慎重に行う必要がありそう...

誰かがテストを行う必要があるのでしょう。最近、私はiOS上でのiPhoneのアプリケーションの作り方を学びました。技術的には80年代のものです。 80年代の終盤から90年代の初頭に開発されたNextStepです。アップル社がその技術を買収したのです。 Objective-Cを使ってストリームやinterflowなどの基本的なデータ構造をNextStepStreamやNextStepInterflowなどとしてNextStep上で作ったのです。そんな昔に作られたものが今でも使われているのです。

単体テストを行う前に、その言語の基本を理解しなければなりません。そこで私もまずObjective-Cを十分に理解することに努力しました。最初は、おそらくひどいコードを書いていたと思います。しかし、それをやり続けて行くうちにこの部分の単体テストが書けるようになったことに気づくのです。ただ、単体テストのやり方が分からない部分も残ります。非常に中核の部分で、ジェスチャーなど携帯電話で行えることでかつて見たことがないことの単体テストのやり方が分からないからです。

実験をし、技術に慣れて、より良くなる方法を新たに探すのです。常に学び、より良い方法を探すのに努力をするということです。

-- アジャイルサムライに関する最後の質問は「振り返り」についてです。インタビューアーの１人は最近までアジャイル開発プロジェクトに従事していたのですが、そこで振り返りを行った際に改善策が出てこないという状況を良く経験したようです。この問題はどのように解決できるでしょうか？

参加者に対するメリットが提供できるように振り返りの枠組みを作るようにかなり努力しなければなりません。「どうやったら改善できるか」や「より良く開発するためには」とかの言葉だけだとつまらないですよね。わくわくしませんよね。非常に難しいと思います。

私の本では、2種類の振り返りの方法に言及しています。 1つは、「より大きな振り返り」というものでまる1日あるいは2日間かけて行うものです。１年間のプロジェクトであれば、過去6ケ月まで遡り、この時点ではどう感じていたか、ここでは何が起きたかなどを振り返るものです。私は通常このような振り返りを行いません。振り返りを行う時点では手遅れになっているからです。

私の本では、通常10-15分程度の時間で行うものとして振り返りを説明しています。反復計画ミーティングの最後に行うのです。ミーティングでは私が話をします。「みんな、とっても良かったことはなんだろう」、「タクの仕事は素晴らしかった。グループに話をしてデータベースの移行に対応してくれるようにしてくれたのだよね」等々です。

そうすると、彼（タク）はシンゴと話を始めて一緒に来週のデータベース移行に備えようということになるのです。私は、チームの誰かの気分を良くし、その人を他の人たちへのお手本にするのです。誰かを褒めることで、その人が自分の努力を認めてくれたのだと感じ、主導権を取ってくれるようになるのです。そのようなことをできるだけ多くの人に対して行うのです。

話を聞いていれば、常に1つ、2つは褒めるネタは見つかるものです。それをみんなに話をするだけです。「ヨウジはレガシーコードのリファクタリングを頑張った。非常に高度なレベルでやり続けてくれたよね」という感じです。単体テストの自動化を行っていればさらにそれを褒めます。建設的なフィードバックを提供し、批判も良い形で行うように努力するのです。

リファクタリングを行っていることを褒め、単体テストの自動化ができればさらに良いと言うのです。単に単体テストの自動化を行った方がよいとは言いません。肯定的で楽しいやり方でチームのエネルギーレベルを高め、皆が改善できることを分かってもらい、改善することが気持ちの良いことだと感じるようにするのです。完全に黙ってしまい、誰も改善案を出さない状態になり、不平を言う人が出てくる場合は、「どうして不平を言うのですか？不平があるんだったら、なぜ金曜日の振り返りで改善策を出してくれなかったのですか。改善するためのアイデアを出さなければ、不平を言う権利はありません」と言います。

同じことを他のメンバーにも言います。それは、各メンバーが孤立し、みんなが異なる方法を用いている状態です。不平を言うよりも、改善策を考えるべきであり、通常はそれに応えてくれます。

2. モチベーションとコーチング

-- メンバーのモチベーションを管理するために推奨するのはどんな方法でしょうか？

私は他の人のモチベーションを気にしません。その人自身がモチベーションを高めれることを良しとしています。チームにはすでにモチベーションが高い人もいて、私も楽しく、エネルギーの高い形で関わることでチームに命を吹き込むことができます。それでもモチベーションが高まらず、仲間にならない人については、助けるように努力をしますが、ただその人には「あなたのモチベーションを高めるのが自分の仕事ではない」と言います。

プロジェクトのメンバーとして作業をすることでモチベーションを得られるはずなのに、それが得られないのです。「高いモチベーションを持つかどうかはあなたが決めることであり、次のプロジェクトで一緒に仕事をすることはないでしょう」と言います。他人のモチベーションを高める簡単な方法はありません。

ただ、1つできることがあります。プロジェクトのリーダーがメンバーのモチベーションを高められない場合、メンバーの行っていることを誠実に感謝することです。モチベーションが低いのではなく、自分の仕事ぶりを会社から感謝されていないという思いがあることがあるからです。

「タクは、このプロジェクトに１年従事している。ずっと良い仕事をしてくれ、COBOLに対応してくれて、そのお陰で魅力のあるプロジェクトになっていることに本当に感謝している」とその人に言い、気持ちを良くします。それで状況が変わります。「タク、COBOLのシステムでよい仕事をしたね」と言うのではなく、努力に対して非常に誠実に「あなたは本当にかけがえがない」と感謝をするのです。

そのメンバーの上司を知り、その上司にそのような貢献を認識してもらうとさらによいかもしれません。メンバーに「COBOLのシステムだが、コーポレートサーバは毎年130トランザクションをソフトウェアで処理し、毎日膨大な回数そのソフトウェアが実行される。彼が対応しているこのソフトウェアが壊れると、みんなは給料をもらえなくなる。これはとても重要なことだ」ということに気づいてもらうのです。

どんな大切な仕事をしているかに気づいてもらい、それをクリエイティブに行う方法を考えるということです。 COBOLシステムからの情報をiPadに送り、ユーザの事務作業をリアルタイムでバックエンドシステムにつなげてユーザが喜ぶようなシステムを実現することもできますよね。

だから、時としてクリエイティブに行う方法を考える必要があるのです。ということで、回答は2つあります。まず、私は他人のモチベーションを気にしないということです。私が何かできそうであれば、それを試みます。でも、他人のモチベーションを高めることが自分の個人的な責任だとは思いません。このチームで開発できることでまずモチベーションが高まり、ワクワクすべきなのです。仕事があることに感謝すべきなのです。

毎日、仕事をする場所があるだけ幸運なのです。世の中、特に北米には仕事がない人がいっぱいいるのです。そんな人にはなりたくないですよね。そうだったら、ワクワクして仕事をしましょう。

-- アジャイルコーチについてもう1つ質問があります。アジャイルコーチとしてもっとも楽しいことはなんでしょうか？

私は、シニアなチームがソフトウェアを納品することに燃えるのがとっても楽しいのです。様々な理由でソフトウェアを納品することに燃えるチームは多いです。私は前職で納期に間に合うように価値あるソフトウェアを納品しただけで、そんなに素晴らしい仕事をしたとは思っていませんでした。ところがメンバーの1人に「あなたが会社にもたらした大きな変化に気づいていますか」と言われたのです。「いいえ」と答えると、「昨年の状態と比べると非常に良くなった」と言われました。

私が「行ったことは素晴らしいが、まだまだ多くの点で改善の余地がある。バグも多すぎるし、もっと素晴らしいソフトウェアを作れるはずだ」と言ったところ、その人からは「でも昨年の状態と比べると非常に良くなったんだ。気持がいいんだ」と言われました。その人はそのやり方で仕事をすることにワクワクしたのです。会社も確かによくなりつつありました。人々が改善し、会社がより良い方向に向かうというような改善を見るのが楽しいのです。

大変ですが、長期間行うとそれが完全に常識になるのです。それ以外の働き方を想像できなくすらなります。コーチが組織に来た際には、「ここの考え方に慣れてはいけない」ということを忘れないようにします。当り前なことと思ってはいけないし、初心者の気持ちを持ち続けないといけないのです。ウォーターフォールでとっても品質を重視している組織の場合は、重視している品質を失わないことと本当にお客様が欲しいもの提供することを両立できるように努力することで抵抗を減らすことができます。

そう、そう、そうです。アジャイルサムライで私が好きな話の1つに、非常に規制が厳しいカナダ政府の施設で如何にアジャイル開発を適用したのかというものがあります。ほとんどがウォーターフォールで開発しているという状況です。プロジェクトの資金は政府が税金を使う形で提供され、すべての要求をまず文書化する必要があり、10社程度の会社に対して公開入札を行い、お金は最後に支払われるというものでした。完璧なプロジェクトでしたが、アジャイルをやりたいということでした。これじゃ、うまくいきませんよね。というのは、固定期間、固定金額、固定スコープ、品質も固定、すべてが固定だったからです。

私には固定ではなく、変化すること、納品すれば何かが変わるだろうことは分かっていました。そのため、変化に管理するために創造的にならなければいけないのです。１年間のプロジェクトの2週間目で要求が変わりました。変えられないだろうって、でも変えたのですよ。その部分はいらないということでしたが、どうすればよいでしょうか。

私たちは、変更を追跡するシステムを作ったのです。「これが１年前の元々の要求です。これが変更された後の新たな要求です」とお客様に示し、「これで監査を行う上で問題ないでしょうか」と聞くと「おそらく大丈夫だろう」ということでした。これで固定期間、固定金額、固定スコープ、品質も固定のプロジェクトで変更に対応しました。

どのようにスコープが変化しているかをお客様に見せたのです。「これがこうなり、あれがああなった」というようにです。プロジェクトを適応できるようにしたのです。システムを反復的に作り、フィードバックを得たのです。ということで、創造的でなければなりません。非常に重要な点です。

3. 日常生活

以前、香港に行く途中で東京に着陸したことがありましたが、空港を離れて歩き回り、あなた方のような素晴らしい人たちと会い、角谷さんが他にも素晴らしい人たちに会わせてくれるというのは初めてです。

1,2日間は時間があるので、観光できそうです。とてもワクワクしています。

はい、日本文化や宗教にとても魅力を感じています。私はとっても歴史が好きなんです。歴史の勉強がとっても好きです。日本の歴史は興味深そうですね。

でもサムライは好きですよ。私はサムライの規律が好きです。厳しい武士道も好きです。私の理解が正しければ、サムライは遊びで剣を抜きませんよね。剣を抜くためにはそれなりの理由が必要です。戦っている時も無駄に剣を振り回しませんよね。剣を最小限の回数振り、相手を倒すのです。

一緒に踊るのではありません。シュキーン^※だけです。そんな姿勢が好きです。なぜか個人的にとても共感します。そのようなところが好きな点です。
※シュキーン：おそらく無駄に刀を振り回さずに居合のようにシンプルに戦うことを表現したかったと思われる

-- 五輪の書という書籍のことを聞かれたことがありますか？宮本武蔵の書いた本です。

聞いたことがありますが、読んだことはありません。私が楽しめそうな本ですか？

なるほど見てみます。いつも面白そうな本を探しているので。

-- この本には戦う方法の真髄が書かれています。最強の戦士、サムライになる方法が書いてあるのです。

-- 本に書いてあることを使って、アジャイルサムライをさらに面白くできるかもしれませんよ。

やってみたいです。いつもよいネタを探してますので。ありがとう。

いっぱいありすぎます。3人の子供の父であり、そのうち息子2人はアイスホッケーを行っています。その子たちのコーチをし、アイスホッケーのやり方を指導することもあります。

昔はやっていましたが、今はやっていません。子供たちを手伝っているだけです。もう１つの趣味は、バイクに乗ることです。仕事にもバイクで通勤しますし、冬にも乗ります。楽しいですよ。

防寒はしなくてはなりませんね。タイヤに大きなスタッドを刺して氷で滑らないようにすることもあります。

運動は好きです。いっぱいご飯が食べられるからです。食べることは好きです。運動をしなければいっぱいご飯を食べられませんよね。太っちゃいますから。

食べることが好きで、運動がそれを可能にするし、楽しいのです。そして私と息子でコンピュータゲームを一緒にすることもあります最近はiPhoneも使っていますが、コンピュータをネットワークでつなげて遊んでいます。ロード・オブ・ザ・リングの大ファンで、中つ国、トロンも大ファンです。トロンを遊ぶこともあります。

ロード・オブ・ザ・リングの大ファン、ピクサーの映画のインクレディブルやトイストーリーも好きです。とても素晴らしい映画です。オリジナルのスターウォーズも好きです。新しいやつではありません。トロンも大ファンです。1982年の作品で、トロンレガシーが2007年に作られましたよね。それらの大ファンです。

（しばしジェダイとサムライについてのやりとりが続くが割愛）

ファンタジーとSFが好きです。昔はビジネス書をたくさん読んでいましたが、今はあまり読んでいません。ビジネス書は読み飽きました。今は実際にビジネスをやってますしね。歴史に関する本や伝記も好きです。スティーブ・ジョブズの伝記はとてもよかったですね。ウォルト・ディズニーの伝記も最近読みましたが、非常に興味深かったです。伝記、歴史書、ファンタジーは好きですね。

音楽ですか。80年代の音楽です。80年代に10代を過ごしたので。プログレッシブロックというジャンルで、好きなバンドとしてはYES、

RUSH。Van Halenは昔好きだったけど、今は好きではありません。ほとんどYESとRUSHですね。トロンの昔のサウンドトラック、Death Punk。昔、私はギターを弾いていました。クラシックのギター器楽曲も好きです。Joe Satriani、Steve Morseのような感じのものです。

ギリシア料理、インド料理、時としてステーキとじゃがいも、シーザーサラダ、ガーリックブレッド、クリスマスの七面鳥ディナー ―七面鳥、マッシュポテト、グレービーソースでできているやつ― が好きです。だいたい何でも食べます。ただ、フライが多いのは嫌です。

-- 挑みがいがある日本料理に挑戦されたことはありますか？納豆のような。

角谷さん、この前お寿司屋さんで食べたのは挑みがいのあるものだったでしょうか？

そうか、私が食べたものはまだ挑みがいがあるものではなかったんだ。「いくら」を食べ、...。

-- 次の質問に移ります。Jonathanさんのモットーはなんでしょうか？

私のモットーは、「共有し(Share)、学び(Learn)、成長する(Grow)」ということでしょうか。学んでいる時はたいてい楽しいですし、学んでいるだけでワクワクするんです。利己的に、可能な限り学び、様々なことを学びます。子供がコンピュータゲームに夢中になるように、私は学ぶことに夢中なのです。だから、私はコンピュータゲームをあまりやらずに学んでいます。

私が見出したもっと良く学ぶ方法は、「自分が学んだことを他の人たちに教え、共有する」というものです。そのために、ブログをいっぱい書きます。 iPhoneアプリ開発について新しいことを学んだら、それをブログに書きます。誰か他の人に説明することで、自分の理解を確実にし、参考情報を探すのです。共有し、学ぶことで成長するのです。

成長すると、気分がよくなります。他の人達のモチベーションを高め、その人たちがワクワクして来て、成長の機会を与えられれば、それは有能な人達を留め、引き付けるための優れた方法になります。引き付け、継続的に学ぶ機会を与え、「常に学ぶ」という旅路を楽しむのです。

我々はソフトウェア業界にいてとても幸運です。というのは、我々の業界の学びには決して終わりがないからです。決して、決して、決して終わりません。でも、全員がこの速度で学びたい訳ではありません。全員がこの速度で常に学ぶことが好きな訳ではなく、疲れ果てることもありえます。

一度高い能力が得られてもそれを完全にやり直さねばならないのは、私が知る限りこの職業だけです。 Javaが非常に得意だ、でも.NETは完全な初心者だ。.NETが非常に得意だ、でもiOSは完全な初心者だ。Ruby On Railsは完全な初心者だ。常に立場が悪くなり、自分自身を常にリセットしなければならないのです。様々な言語を学ぶ過程で、共通なことも確かにあると思います。それでも、常に立場が悪くなり、完全に分かったという状態にはならないのです。完全に分かったと思った瞬間に、悪い状況に陥っているのです。というのが、何かが追いついてきているからです。

我々はこのソフトウェア業界のとても心躍る時代にいるのです。もっとも心躍る場所なので私は他のことを行う気にはなれません。そう、そう、そう。

4. 「アジャイルサムライ」の執筆

-- アジャイルサムライについてもう1つ質問があります。私はアジャイルサムライの文章に非常に感銘を受けました。とても読んでいて楽しいし、すごく分かりやすく書かれていると思いました。

ありがとう。それは翻訳者の方々に負うところも大きいと思います。とても素晴らしい仕事を行ったと思います。

-- 私も翻訳者の方々の仕事は素晴らしいと思います。ただ、図もすべてとっても素晴らしいです。

翌週の土曜日に開催されるアジャイルサムライ道場に来た方がよいかもしれませんね。そこでは、アジャイルサムライを書いた動機とアジャイルサムライをどのように執筆したかについてお話をする予定です。

その大きな部分は楽しみということです。この本を如何に読者が夢中になり、楽しんでもらうようにできるかということです。というのは、単にソフトウェアプロジェクト管理に関する本を書き、プロジェクトを開始する前に行うべきチェックリストはこれだとか、アジャイルなプロジェクト計画はこのように行い、適応的であり、これが見積もりの方法であり、相対的でポイントに基づくということを説明することもできたでしょう。これではみんな寝てしまいます。誰も面白いとは思わないですよね。

多くの時間を割いて、これを読者にとって面白いものにするためにはどうしたらよいかということを考えました。夢中になり、楽しんでもらう様になるということです。図は素晴らしい方法であり、私は図でアジャイルがとてもシンプルであることだけを説明したいと思いました。必要以上に複雑になりません。計画について1冊まるごと割く必要はありません。5ページ、1ページでよいのです。計画で行うことはこれだけだということを示すのです。自分達はすでに結構アジャイルだということをこの本で理解して欲しかったのです。

3人の子供たちと誕生会に行ったり、アイスホッケーを行ったり、ベービーシッターを探したり、洗濯をしたり、芝生を刈ったり、スーパーに行ったりと忙しい週末を過ごしていれば、やることが多すぎて時間が全然取れませんよね。誰もがこんな週末をいつも過ごしているのです。じゃあ、どうすればよいのか？スコープを絞りますか？優先順位付けをしますか？見積もりをしてその計画に対する期待を設定しますか？

同じことはソフトウェアプロジェクトでも見てきています。アジャイルなやり方です。だから結局同じことだということに気づいて欲しいのです。同じなんです。ソフトウェアだとどうして魔法のようなことが起きると思うのでしょうか？これだけのことをこれだけの時間に行うのです。違いますか。書籍を通じて、このようにシンプルになるように力を尽くしたのです。ユーモアが時として難しいということは分かっているのですが、ユーモアを盛り込みました。

ユーモアが好まれる場合と好まれない場合があります。でもほとんどの人はユーモアによい反応をしてくれ、ジョークに感謝されたりしました。全員ではありませんが、それらの人達にこの本は合わなかったのでしょう。この本は、私自身がアジャイルを始める時にあればよかったものになるようにと書いたものです。それがこの本を執筆した際の気持ちです。コメントとフィードバックに感謝します。

-- よりシンプルなものにするために原稿の推敲にはかなりの時間を使われたのでしょうか？

本を書いていた時のことですか？はい、時間を使いました。本を書くのに2年間費やしました。出版された本は書き直しをしたものです。最初の本は2006年オーストラリアにいた時代に書きました。でも、その本は捨てました。その本は先ほど述べたような、とてもつまらない方法で書いたのです。（笑）

インセプションデッキや計画については書いていました。でもとてもつまらないものでした。その本を捨てて、新たに書き始めたのですが、うまくいかず、仕事に戻ってお金を稼がなくてはなりませんでした。営業やマーケティングの本を読んで、どうしたら本が面白くなるかを学びました。

もう1回挑戦してみようと思い立ち、それから日々1-2時間をスターバックスで費やし、2年後に本を書きあげたのです。 Pragmatic Programmerシリーズの編集者がついて、多くの支援をしてくれました。とても助けになりました。最初のバージョンでは、インセプションデッキの部分が100ページもあったのです。編集者は、「アジャイルインセプションと本の題名を変えるか、60ページ削らなければならないわね」と言いました。「なんだって！」（笑）

「60ページ書くのに6か月もかかったのに」。でも、100ページの内容を40ページに削ることは私が行ったことの中でも最善のことだったのです。無茶苦茶良くなりました。とても簡潔になり、とても焦点がはっきりしました。短い方が良いのですが、短いものを書くのに多くの時間を要します。

5. 今後の夢

-- 最後の質問です。今後成し遂げたいと思っていらっしゃる夢はあるでしょうか？

本を書いて思ったことの1つは、学校を卒業し、会社に勤めると「創造的になる方法」を忘れるということです。学校を卒業し、会社に勤めるとやるべきことを指示されます。これをして、あれをしてという感じです。それを行うと、例えばプログラムを書き、ソフトウェアをビルドし、システムを作っても創造的に自分自身でものづくりをした訳ではないのです。本を書くことで、再び創造的になることを強いられました。そのことでワクワクしました。

久々に創造的になったのです。図の書き方ももう1度学ばねばなりませんでした。図やイラストはすべて自分で描いたんですよ。図も長いこと書いていませんでしたので、1から思い出さねばなりませんでした。でも楽しかったのですよ。これと同じぐらいのエネルギーと時間でなんらかのプロダクトを作りたいと思っています。どんなプロダクトであるかはまだ決まっていません。

iPhoneのアプリかもしれませんし、ゲームかもしれませんし、会社かもしれません。同じぐらいの情熱をこの新たなことに投じて、可能な限りの楽しむを作りだしたいと考えています。次のプロジェクトを探しているのですが、それはまだ決まっていません。それに1-2年間程度の期間を費やして完成したら、次に何を行おうかとまた考えるかもしれません。家族ともっと過ごしたいというのははっきりしていますが。次のプロジェクトにとても期待しているのです。

長期的なものではありませんが、これが短期的に目指していることです。

ありがとうございました。素晴らしい質問で、本当に楽しいインタビューでした。

インタビューを終えて

今回のインタビューを通じて、まず印象的だったのはJonathanさんの誠実なお人柄と創造的であることへのこだわりです。前者はどのような質問にも全力投球で回答して下さったことで感じました。後者は従来手法に慣れた開発者の方々がアジャイル開発を取り入れる際の様々な工夫をお聞きし、それらの工夫が「創造的に問題に取り組む」という気持ちで生まれたものだということをお聞きして感じました。

最後に、今回のインタビューの実現にご協力下さいました永和システムマネジメントの角谷さんと西村さんにこの場を借りて感謝と、記事の公開が大幅に遅れたことのお詫びを致します。

アジャイルサムライ読者プレゼント

今回特別に『アジャイルサムライ』（Jonathanさんのサイン入り）を抽選で 1 名の方に読者プレゼントいたします。

締め切りは、2013年 2 月 28 日（木）です。当選者の発表はご本人宛にメールにてお知らせいたします。

【個人情報の取り扱いについて】
ご応募で頂いた個人情報につきましては、本件「アジャイルサムライ」プレゼントのご連絡のみに使用いたします。お客様の個人情報は、当社の個人情報保護方針に基づき、適切にお取り扱いいたします。また、ご本人の承諾なしに、第三者機関へ提供することはありません。

プレゼントの応募は締め切らせていただきました。
たくさんのご応募ありがとうございました。
抽選の結果、当選された方には 3/15 までに案内メールをお送りいたします。
(2013/03/01)

Jonathan Rasmusson さん突撃インタビュー( 後編 )