separator line

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

 Jonathan さん

永和システムマネジメントさんのご厚意により、去る 3 月に Agile Japan 2012 での基調講演を提供するために来日された Jonathan Rasmusson さんに対するインタビューを実施させて頂きました。 Jonathan さんは、「アジャイルサムライ」というアジャイル開発の入門書の著者です。 「アジャイルサムライ」は日本で空前のブームを巻き起こしており、現在日本の各地で勉強会(道場)が開催されています。

インタビューでは、以下の 4 つの分野に渡り、Jonathan さんに質問をしました。
1. Jonathanさんのこれまでの経歴
2. アジャイル開発一般
3. アジャイルサムライ
4. プライベートな生活

今月と来月の 2 回に渡り、Jonathan さんへの突撃インタビューの結果をお届けします。


1. Jonathanさんのこれまでの経歴について

-- 今日は、インタビューの機会を下さいましてありがとうございます。それでは、早速インタビューを始めさせて頂きたいと思います。 Jonathanさんのこれまでのご経歴、どうしてアジャイルコーチになられたか等について簡単に説明して頂けませんでしょうか。

大学では電気工学を専攻しました。 卒業後、コンピュータソフトウェア業界に入り、Java のコンサルティングを始めました。 1999 年頃のことです。 その頃に IEEE の学会誌で Kent Beck 氏が書いた XP の記事を読んだのです。 その記事に大きな影響を受けました。開発者がソフトウェアを書く際に実践できる 13 個のプラクティスが紹介されており、それが私が XP に出会ったきっかけでした。 そこで、それらのプラクティスのいくつかを自分がソフトウェアを書く際に適用してみました。 同じぐらいの時期に Martin Fowler さんの Refactoring も出版され、この本にも大きな影響を受けました。

私は、カルガリーのコンサルタント会社に勤めていましたが、その会社がその後シカゴに本社を置くThoughtWorks 社という会社に買収されたのです。 ThoughtWorks 社のオフィスでその後 6 年間に渡り勤めて、世界中でアジャイル開発のプラクティスの普及を行いました。 アジャイル開発を導入するお手伝いをしました。 その経験が自分の出発点になっています。

ThoughtWorks 社を辞めてから気づいた大きな課題の一つは、新たな会社にアジャイル開発を導入する際に多くの書籍を読まなければならないというものでした。 私は 7 冊の書籍をまず読んでから話をすることにしていました。 でもそのようにアジャイル開発を取り入れるのは大変です。 インタビューで後ほどお話しますが、これが「アジャイルサムライ」を執筆した動機の一つです。 「如何にして 7 冊の書籍の内容を 1 冊のシンプルで読みやすい本に凝縮できるか」ということです。 私は、「ユーザーストーリー」を語るのに 1 冊の本を読む必要はないと感じていました。 厚すぎます。 10 ページ程度で「ユーザーストーリー」の基本を網羅することができます。 同様なことが見積もりと計画についても言えます。

これが本を書こうと思ったことの発端です。シンプルにし、簡単に理解できるようにするということです。

-- アジャイル開発にそもそも興味持った発端は Kent Beck の論文だったわけですね。 アジャイル開発のコーチングに興味を持たれた動機はなんだったのでしょうか?

私は、常にコーチングすることを楽しんできました。 最初に勤めた会社の時代からコーチングを行ってきました。 私たちは昼食勉強会(Lunch and Learns)という活動を行っていました。 会社の全メンバーを昼食時に集めて、自分たちが行っている仕事に関係する興味深いなんらかのことについて話をするのです。 例えば、単体テストだったり、スケーラブルなアーキテクチャを構築することだったり、EJB だったりするかもしれません。

どんな話題であろうと私は皆の前に立ち、コーチングすることが好きだったのです。 その当時、私は会社の中で比較的シニアな開発者だったので、若手の開発者を参加させて教育を支援することを楽しみました。 それ以来、コーチングをずっと続けているのです。

-- 通常、若いエンジニアは技術的なことに興味を持つことが多いような気がしますが、でも Jonathan さんは人間系に興味を持たれたということでしょうか?

その通りです。 また、私は肩書を与えられるのを拒み続けてきました。 私は、単に「プログラマー」と呼ばれるのは嫌です。 「プログラマー」というラベルを貼られると、「プログラミング」に重要な他のことを追求できなくなります。 例えば、「期待を設定する」ということです。 あることを行うのにどの程度の期間を要するかに関する期待です。 これは、プロジェクト管理の分野だと分類されます。 あとは、本当に優れた開発者になるためにはテストをより良く行えるようになることが必要です。 そのため、テスティングに関する多くのマテリアルを勉強し、ソフトウェアをどのようにテストするかを学びました。 自分が書いているソフトウェアの品質を確かめたかったからです。

そのように開発以外のことにも興味を持つことで、「期待を設定する」というプロジェクト管理や「テストをより良く行える」という品質管理の側面や、さらにはより良い画面を作り、ユーザビリティを検討すること、それらの UX デザインというような様々な分野に魅力を感じてきました。 単に技術的な開発という分野だけに留まりませんでしたが、もちろん技術的な開発はそれらの中でとても大切な分野であり、技術的に熟達する必要があります。

-- メンタリングとコーチングは異なるという人もいます。 私は Jonathan さんがメンタリングの側にいるのではないかと思いますが、私の見立ては正しいでしょうか?

両方です。 若い人に対してメンタリングを行うこともできます。 新入社員によいソフトウェアを書くための方法をペアを組んでメンタリングをし、ソフトウェアを効果的に書くために自分が行う細々したことをすべて見せることができます。 IDE やツールを使うときのショートカット、パターンやアイデアの使い方などを見せることは確かにメンタリングです。

コーチングも大事です。 ソフトウェアを書くことに支援が必要な会社も多いからです。 ソフトウェアが必要悪だという会社もあります。 そのような会社は買えるもんだったらソフトウェアを買うでしょう。 リスクが無くなりますし、店に赴き、必要なソフトウェアを買い、インストールすればよいだけですから。 そんな会社がカスタムソフトウェアを書くことに伴うリスクを軽減するためにコーチングを求めるのです。 予算を超過しない、納期に遅れないなどコーチング側の「期待を設定する」ということも大事になります。 そのような生業の会社に入ったこともあり、お客様のチームに対してソフトウェア開発に関するコーチングも沢山実施してきました。

-- コーチングをして下さいという依頼を受けた場合に、お客さんの会社の若いコーチを育成することを求められることもあったのでしょうか?

何回かありました。 ThoughtWorks 社において受けた仕事には常に二つの相反する要素がありました。 お客さんがアジャイル開発でのソフトウェアの作り方を見せて下さいというトレーニングの要素です。 そのために、私たちの分析者がお客様の分析者と、私たちの品質管理担当者がお客様の品質管理担当者と、私たちの開発者がお客さんの開発者と、私たちのプロジェクト管理者がお客様のプロジェクト管理者とペアを組んだりしました。 受けた仕事にはこのようなお客さんに対するトレーニングの要素が含まれていました。

しかし、その一方で私たちに納品してほしいという要素に対する要望がもっと強かったのです。 特定の納期で、プロジェクトを実行し、ソフトウェアを作り、出荷して欲しいということです。 一方の要素と他方の要素ととが対立するのです。 速く開発することを優先するのであれば、現状のままで開発して納期を守ることができます。 トレーニングして欲しいのであればトレーニングを行うこともできます。 トレーニングを行うためには、トレーニングを受けている人たちが確実に理解し、吸収できるように開発スピードを少し落とす必要があります。 ということで、健全な対立がある場合があったのです。

お客さんから仕事を受ける場合には、常に何が一番大切なのかを確かめる必要がありました。 特定の納期でソフトウェアを納品することなのか、トレーニングなのかです。多くの場合、トレーニングの優先順位は 2 番目になりました。

-- Jonathan さんはもっぱらアジャイルコーチとしての役割を果たされたと思うのですが、開発もされたのでしょうか?

ThoughtWorks 社ではもっぱらコーチングを行いました。 ThoughtWorks 社を辞めてからは開発者としての役割が増えました。

-- そうなんですか。

コーチングは私のいまやっていることの一部ではあるのですが、自分自身が開発チームの欠かせないメンバーであるときにもっと効果的にコーチングできることに気づいたのです。 私は自ら例を示してリードすることが好きです。 チームに入り、作業を分担し、チームの一部となるのが好きなのです。

-- アジャイルコーチの代わりに、お客さんに自分たちの会社に転職して下さいと言われたことはなかったのでしょうか?

確かにありました。

-- そんな誘いをどのように断ったのでしょうか?

自分たちのチームに入って下さいというお誘いには感謝しましたが、今私がやっていることを続けるためにはそのようなお誘いに正社員になるという形で応えることはできませんでした。 正社員になってしまっていたら、今自分が行っているようなワクワクすることができなかったでしょう。 会社に帰属しない身分ゆえの柔軟性があり、それをとても楽しんでいます。

会社では面白いことができないという訳ではなく、面白いことを行っていて入社したいという会社に行き当らかったということにすぎません。

-- なるほど。 カンファレンスでアジャイルコーチの人が「自分たちの役割はアジャイルなマインドに向けた企業文化の変革である」と述べていたのを聞いたことがあるのですが、そのような経験はお持ちでしょうか?

経験しました。 企業文化やマインドを変えるということはとても難しいことです。 オーストラリアである仕事をしていた際に、そのような経験をたくさんしました。 私はシドニーで何年か仕事をしていましたが、その際に組織の変革をしましたが、とても大変でした。 というのは、会社には既存の慣習や文化があり、それはトップダウンでもたらされることが多いです。 CEO からもたらされ、会社の上層部が行うことに部下達は大きな影響を受けるのです。 それとアジャイルの方向が揃っていたら、申し分ありません。

会社の上層部がアジャイル、反復や適応型を行うことをしているのであれば、方向が揃っていることになり、組織の変革に成功するチャンスが高まります。 そうではない会社も多く、アジャイルのやり方をボトムアップで取り入れることになります。 二つの方向の綱引きが生じます。 それを変えるのは困難です。 会社の上層部の方向性が異なると大変です。 チームを超えたレベルや組織横断的にアジャイルを行うとすると、仕事の割り当てなどが大きく影響されることになります。

非常にややこしい問題であり、私自身は自分がチェンジエージェントであるとか、企業文化を変えようとは思わないのですが、お客様が支援を必要としており、特定のプロジェクトやグループのためになるのであればあれば、それをお手伝いしてもよいと考えています。

2. アジャイル開発一般

 Jonathan さん

-- 欧米ではアジャイル開発が主流になりつつあり、日本とは異なる状況だと聞いていますが、なぜ欧米ではアジャイル開発の導入が進んだのでしょうか?

北米ではアジャイル開発がなぜ普及したかということでしょうか?

-- そうです。

「常識」

-- 一同:「常識?」

「常識」という日本語を先日学びました。 自分がソフトウェア開発を行ったことがない場合、どのようにプロジェクトを管理するでしょうか。 過去 40 年間に渡って全然理にかなっていませんでした。 そのことを信じられませんでした。 なぜ、ウォーターフォールやステージゲート型の開発プロセスを実践し、フィードバックも変更もなく、反復もないのでしょうか。 常識的に考えて、アイデアを受けてそれをソフトウェアに変えるのに要する期間は昔は年というオーダーだったのが、今や月というオーダーになったのです。

ソフトウェアを出荷するまでの時間は、昔要求を収集し、分析するために要した時間よりも短くなっているのです。 だから、ウォーターフォールは使い物にならなくなってきているのです。 技術はすばやく変化しますし、業界もすばやく変化しています。 そのため、大幅に速度を上げる必要があるのです。

さらに Kent Beck がかつて XP で述べたような変更コストの曲線です。 従来の時間とともに変更コストが指数関数的に増えるという話はもはや正しくなくなってきています。 それは 60 年代には正しかったかもしれませんし、60 年代、70 年代にソフトウェアをそのように作ってきた人たちを非難する気もありません。 今や、その時代のメインフレームよりも携帯の計算能力が高いという時代です。 Just In Time コンパイラー、リレーショナルデータベースがシステムに使われ、バージョン管理で分散して開発したコードを共有し、単体テスト、リファクタリング、TDD などのプラクティスにより、変更コストはそれほど増えなくなったのです。 そのことで変更に合わせて開発することが可能になったのです。

北米で普及したのは、そのように開発したいという形で開発が行えるようになったからです。 お客さんは開発を完了することを望まなくなり、ソフトウェアを作り上げる過程でプロジェクトのかじ取りを行い、リアルタイムのフィードバックを行うようになったのです。 より良いプロダクトが得られるからです。 そのため、ビジネス側の人はアジャイル開発を好みます。 これが 1 番目の理由です。

さらに米国の大きなコンサルティング会社がアジャイルコーチを雇い始めたのです。 それらの会社のお客さんが求めたからです。 6 ケ月もの期間をかけて要求を収集しなくなったからです。 その代わりに、6 ケ月でプロジェクトを完了するようになったのです。 そのために、反復的に開発せざるを得なくなったのです。 それは、ある意味で「常識」的な開発方法が普及したのだと思います。

日本では、ご質問にあったように導入が進みつつあるようですが、北米ほどまだ普及していないという印象を受けています。

-- 日本と北米の違いは、両者の IT 産業の構造の違いに起因していると考えています。 日本では、IT 産業がユーザ企業と、IT ベンダーあるいは SI 会社に分かれています。 開発の多くは、契約を介して行われます。 そのため、契約の対象となる機能、品質、納期を決めないといけないのです。

私たちの業界は、どのように期待を管理するかということだけにこれまで注力してきたのではないかと最近感じています。 如何にして素晴らしいプロダクトを作るかということを考えるのを止めてきたのです。 別の言い方をすれば、予算を守り、納期を守り、契約と条文を守り、後でもめないようしようということに気を使いすぎ、時間とエネルギーを消費しすぎてきたのです。 その結果、如何にして素晴らしいプロダクトを作るかということを考えなくなったのです。 大きなレベルで信頼がなく、契約交渉や対立があったからです。

北米では、自社で開発チームを擁して開発することが多いです。 大きな保険会社や大きな石油やガス会社は開発チームを自社で擁しており、外部の SI 会社に開発を委託しません。 そのために、契約を介した利害の対立がないのです。 「年間の予算がこれだけなのでこれで開発してください」というだけです。 日本がそのような状況だというのは興味深いですね。

-- さらに品質だけに過度に注目してしまうという点も異なるかもしれません。 特に大会社はその傾向が強く、多くのレビューにより早い段階で欠陥を除くことで品質が確保されると信じています。 文書のレビューとコードレビューです。 そのようなプロセスで達成されているような高い品質がアジャイル開発では実現できないだろうと考えているのです。 これがアジャイル開発の普及を阻むもう一つの障害です。

興味深いですね。 要求収集から分析、設計までのプロセスで厳格なレビューを多く行うことで高い品質が達成できると信じているのですね。

-- QA 部門が開発の各段階のモデルを設定します。 例えば、ドキュメント(ページ)に XX.X 個の欠陥があるはずだというようなモデルを設定する訳です。 プロジェクトのメンバーはそれらの欠陥をすべて見つけて目標を達成しようとします。

「測定すればそれが手に入る(You get what you measure)」という言葉がありますよね。 欠陥密度を測定すれば、数字は素晴らしいものになるでしょう。 ただ、その機能がお客さんが望むものではなければどうなるでしょうか。 適切なものを作っているということはどうやって分かるのでしょうか。 バグフリーだけど誰も使いたがらないシステムができるかもしれません。

-- それは問題ですよね(笑)

そうですね(笑)

-- 北米でアジャイル開発が組み込みソフトウェアや金融系のソフトウェア開発に適用されたという事例をご存知でしょうか?

はい、金融系のソフトウェアへの適用事例は知っています。 組み込みソフトウェアには普及しつつあるところだと思います。 James Grenning さんが Pragmatic Programmer シリーズで Embedded C での TDD や単体テストの本を書いていますよね。 プロジェクトや業界毎の事情の違いはありますが、アジャイル開発を適合させることができます。 原則は一緒ですが、事情に合わせて異なる使い方が求められます。

例えば、医療関係の会社で高い品質が求められ、人命に関わるような場合は、電子書店よりも厳格な品質管理プロセスが必要になります。 ということで固有の事情に応じて異なりますが、金融系であれ組み込みソフトウエアであれ原則は適用できます。 反復開発は自然な仕事のやり方です。 子供の時から何かを作る時には、反復しますよね。 試みたことがうまくいかなければ、やり方を変えます。 1回でうまくいく、完璧な人なんていないですよね。 ということで自然な仕事のやり方だと思っています。

学生時代に、カナダで住んでいる地域の電力会社で特定のグリッドでの伝送線での電力損失を計算する仕事をしたことがあります。 送電網でどれくらいの電力損失が生じるかをシミュレーションを行うプログラムがあったのです。 そこで負荷のモデルを作ってシミュレーションを走らせて電力損失を求め、さらに負荷を変えたり、キャパシタンスを調整したりしてシミュレーションを何回も繰り返したのです。 なかなか良い仕事ができたと思ってました。 月末に上司が来て、「ジョナサン君、とても忙しく仕事をしたようだね」と言いました。 私が「どうして分かったのですか」と尋ねると、上司は「君がプログラムを走らせたメインフレームのレポートから分かったよ。これが今月の請求書だ」と答えました。 通常の請求金額が 10-20ドルのところが、200ドルだったのです。

-- 一同:(笑)

一生懸命に反復的に働いたために、メインフレームの利用額が 200 ドルになってしまったのです。 でもメインフレームがあることすら気づいていませんでした。 私にとって自然な仕事のやり方だったからです。 デスクトップでコンパイルするたびに課金する状況を想像できますか。 これが従来の開発方法とアジャイル開発の考え方の違いの一つです。 反復的な開発は自然な仕事のやり方であり、私はそれをやらないなんてことは想像できません。

ダイヤモンドのカットのように反復的なやり方ができない業界もあります。 大きなダイヤモンドを指輪に合わせてカットすることを反復的に行うことはできません。

-- 一同:(笑)

1 回でカットするしかないですよね。 これが反復開発がうまく適用できないと思われる状況です。 ソフトウェアの場合は、変更したり、あちこち動かしたり、赤くしたり、青にしたり、ハイライトしたりするなどいろいろなことを行うことができます。 反復的に仕事を行うためにまたとないものです。

-- アジャイル開発を開発者 100 名の規模にスケールアップすることを可能だと思われますか?

大規模プロジェクトはアジャイル開発であろうとなかろうと、あるいは開発手法に関わらず難しいと思います。 10 名を超えるチームのコミュニケーションの問題をアジャイルが魔法のように解決することはありません。 それでも原則は適用できると思います。 まず問いかけるべきことは、100 名のメンバーを 10 名以下のチームに分割できないかということです。 とても大きなものを小さなものに分割できないかということです。

100 名の開発者、1 年間で新しいデジタル交換機を開発した場合に Scrum of Scrums を適用できますが、複数のスクラムチームを連携させる方法を見つけ出す必要があります。 でも、それは難しいプロジェクトになるでしょう。 スケールアップに付随する問題をアジャイルが魔法のように解決することはないと思います。

-- 次の質問はこれまでの質問とかなり毛色が異なります。エンタープライズアーキテクチャってご存知でしょうか?

 Jonathan さん

もちろん知っていますよ。

-- エンタープライズアーキテクチャは IT ガバナンスの一つの表れだと思うのですが、一つの会社でアジャイル開発とエンタープライズアーキテクチャを両立できると思われますか?

(大きなため息)難しい質問ですね。エンタープライズアーキテクチャの仕事って大変だなぁと思います。

-- 一同:(笑)

とても大変な仕事です。 システム横断的にアーキテクチャに対する共通のビジョンを守ることを求めたり、支援したり、すべての開発プロジェクトに一定のルールやプラクティスを守ってもらうということをトップダウンに行うということが期待される訳です。 ほとんど不可能に近い仕事だと思いますが、だれかがそれを見ていく必要があるのです。 ただ、自分たちが管理したり話をするソフトウェア開発者に対して日々敬意を払うのが難しくなったりもします。 その中でトレードオフを考えていかないといけないので、二つのグループの間で対立が生まれます。 技術の変化はとても速いですから。 プラクティスがとても速く変わることもあります。

アプリケーション開発を日々行っていないと、それらの変化を理解するのが難しくなったりします。 さらに、アジャイルでは自己組織化、自律性、「ゴールを設定するが実現方法の選択は任せる」ことを重視するですが、「実現方法の選択は任せる」ところで企業全体のルールと対立したりします。 例えば、「 Web サービスの使用は禁止」というようなルールです。

プラクティスは適用できますが、会社として何を犠牲にし、犠牲にしないかをプロジェクトやその上のレベルで決める必要があります。 組織横断的に一貫性を持つことは大事です。 一貫性がないと、同じことがてんでバラバラの方法で実現されてしまいます。 それを誰かが見ていく必要はありますが、大変な仕事だと思います。 真に外交的なスキルが求められます。

-- アジャイル開発を成功させるためには、上の人たちが描くビジネスゴールや戦略と方向が揃っている必要があるのですよね?

そのとおりです。

-- エンタープライズアーキテクチャはそれを実現するよい方法ではないのでしょうか?

そこで対立が生まれるのです。 ビジネスゴールや戦略が目指す方向と、エンタープライズアーキテクチャが目指す方向が同じでなければどうでしょうか? ビジネス側が業界で普及している財務系の Java で書かれたアプリケーションを求めている時に、企業の標準が .NET だったらどうしますか? ビジネスは Java を求めているのだけど、企業の標準が .NET なので「.NET のツールを使って下さい」と言っても「そのツールは使い物にならないので使いたくない。 トレーダーが求めているのは Java だ」等という論争が起きます。

これがプロジェクトの最初で絶対に行うべきことの一つであるアジャイルサムライのインセプションデッキを使うべき状況であり、関係者を部屋に集めて議論を行うべきなのです。 どうすればよいかを一緒に考えるのです。 お互いに目指している方向がバラバラなのです。 進むべき一つの道を選択しなければなりません。 だれが道を決めるのでしょうか? スポンサーでしょうか。 利害関係者でしょうか。 これが決定できなければ、始まる前にプロジェクトが失敗することになるのです。 ということで関係者をまず集めて議論を持ち、チームの進むべき道を決めるべきなのです。

-- アジャイル開発は SOX 法、ISO9000、CMMIと両立できるでしょうか?

(深いため息)SOX...。

-- 一同:(笑)

SOX は、時間のムダ、ひどいものだ。 ひどい。

-- 米国の会社は SOX で規制されていると聞いています。

膨大な時間とエネルギーが SOX の統制で無駄になっている。 コンサルティング社によっては SOX をネタにして、仕事を得て SOX のコーチやメンターを送り込むなどをしています。 かなり儲けている会社もあります。 それは、アジャイル開発チームとともにあるというのとは逆の立場です。 人々は、トンデモナイことを行う道具として SOX を使います。

例えば、自分で作ったソフトウェアを開発者がテストしなくなります。 SOX にはそんなことは書いてありません。 でもそのように解釈されることもあります。 1 か所に集まってチームでうまく開発しているところに、SOX の人が来てチームを分割しろということもあります。 お互いに話をすることができなくなります。 どのようにソフトウェアをリリースするかをすべて文書化することを求めたりします。 私は大嫌いです。 関わりたくありません。 SOX なんて無くなればよいと思っています。

-- 一同:(笑)

でも存在しているということは理解しています。 ただ、SOX が求めることをどの程度盛り込むかは自分の視点ではなく、常に会社の判断だと考えています。 CIO が刑務所に行かないで済むようにするとか、財務状況などによります。 我々はこのことについて賢明で現実的であるべきだと思います。 存在することには理由があるので、それに準拠するために我々ができることを考えていこうということです。(それで我々が死ぬわけではないですし、)

-- 10 年前にアジャイル宣言が登場した時には、開発者は戦う相手がいるという熱狂があったと思っています。 アジャイル開発が一般化した今、かつての熱狂は失われたのでしょうか?

新しいものが登場するとワクワクするものです。 アジャイル宣言が登場した際もときの声があがったようなものでした。 プログラマー、エンジニアはついに私たちがずっと感じてきたことをまさに理解し、言いたかったこと表わしてくれるものが登場したと思いました。 プロセスよりも人々、価値のない包括的なドキュメントよりも動くソフトウェアと述べるアジャイル宣言に皆が本当に共鳴し、興奮したのです。

12 年経った今、そのような興奮がなにがしか少し冷めてしまうのは当たり前です。 数多く語られるからです。私がアジャイル開発を教える時には、アジャイル宣言を取り上げません。 見せもしません。 それは当たり前なこと、「常識」だからです。

-- 一同:(笑)

プロセスよりも人々、ドキュメントよりも動くソフトウェア、なんて分かっているよという感じです。 だから今さら教えることではなく、常識なのです。 みんな、支援が必要な次の段階に向かっているのです。 ということをまとめると、12 年後に世の中に出たプログラマーたちは新世代(Gen. Y)なのです。 私は旧世代(Gen. X)です。 新世代は贅沢なことにウォーターフォールをまったく知らないのです。

-- 一同:(笑)

誰も教えません。これがソフトウェア開発のやり方だと。 会社やチームに入るとすぐに反復的な開発を始めるのです。 それが自然な仕事のやり方なのです。 もはや戦いません。戦ったことがないからです。 数週間で動くソフトウェアを作り、反復するというのが当たり前なのです。



以上が前半の内容です。次回、後半もご期待下さい。


謝辞:Jonathanさんへのインタビューを実施したいという願いを快く承諾し、Jonathanさんのスケジュールを調整し、インタビューの場所まで提供して下さった永和システムマネジメントの角谷さんと西村さんにこの場を借りて感謝の意を表したいと思います。

separator line
記事の内容を 5 点満点で評価してください。
1 点 2 点 3 点 4 点 5 点
記事に関するコメントがあれば併せてご記入ください。

©2012 OGIS-RI Co., Ltd.
Index Next
Index Next