ソフトウェア開発の先駆けとなった開発手法。集まりに小井土さんに連れて行ってもらったのが初めてでしたね。ついて語っていて、それに賛同したというか。平鍋さんの話を聞いて、こんなロックな人がいるのかと思った。コミュニティに集まってくる人って、会社ではとんがっている人たちなのではないかと思いました。年目で、大きなプロジェクトが終わって時間ができたのでオブジェクト指向の研修に行ったら一人だけ若い講師の人がいて、それが平鍋さんだった。それでアジャイルのコミュニティというものを知って。当時アジャイルのコミュニティは僕にとってなんだか行きやすい雰囲気でした。アジャイルって、それまでと違ってソフトウェア開発の新しい視点に立っているんですね。登場して、これはソフトウェア開発にとって衝撃的な考え方だと思いました。いうのも、普段あたりまえのように本音としてはやっていたことだったんですね。結局リリース直前になるとユーザーと詰めながら開発しながらやっている、という実態があって、速く作るにはそれしかない。最初からそれをやればいいじゃないか、というのがアジャイルの考え方ですよね。explained”。アマゾンで洋書を買って読んだこと。それで興奮して、これは訳さなきゃと出版社に電話したら「もうやってます」と言われて。サイトを作ったりしました。ついての最新情報をアップデートするサイト。現在でも残っています。みんなアジャイルに出会って衝撃を受けたところは同じで面白いですね。ソフトウェア開発に対して一応工学的なアプローチなんだけど、でもその中に「リリースが終わったら、お客さんといちばん高いシャンパンを抜いてお祝いをしなさい」なんて書いてあったこと。なんでいままで誰もこれを言わなかったんだろうと思った。リファクタリングの本を読んで、コードの足し引きができるというのが衝撃的でした。いままでコードって積み重ねていくものだと思っていたのが、引いてもいいのかと。ファーストはかなり衝撃的でしたね。作る、必要十分で作る、という点は人に教える点でも外せないですね。ファーストと合わせて教えることが多いです。普通ライブラリを作るときには仕様ばかり見て作るんだけど、テストを先に書くと、使う人の視点に立って書くことになります。その視点の移動というのはすごく大事。プログラミングでもそうだけど、使う人とプログラムを書く人の視点の変わり方は面白いですね。よかったと思うのは、プロジェクトの終了時にスタッフみんなで振り返りをするときに、「次もアジャイル開発を採用するか?」と聞くと、みんなイエスと答えてくれるんですね、それは嬉しかった。採用したりすると、最初はやっぱりみんな戸惑っていて。最初のうちは反復ごとのミーティングなどで、僕だけが意見を言うような、僕だけのプロジェクトみたいな感じだったのが、繰り返していくと徐々にみんな意見を言い出すようになるんですね。それでみんなの自分のプロジェクトになっていく。今までオブジェクト指向の利点として「再利用性が高いです」っていうけれど、どのプロジェクトでも実はたいしてオブジェクトの再利用なんかしてないんですよ。標準的に用意されているライブラリやフレームワークが使いやすいですね、というくらい。ツールがあって、だからオブジェクト指向を使うのだと。変化に対応するために、シンプルに設計してかつテストをしやすくする。そのためにオブジェクト指向を使うんだという、アジャイル開発が登場したおかげで実用性の面で初めてオブジェクト指向を使う理由が説明できたんです。ここまでは工学的な面での利点なんですが、一方で人間系の面でいうと、反復ごとに「ふりかえり」というミーティングがあって、チームで気付きを共有したり、「うまくいってない」と報告できるとか「じゃあどうしたらできるだろう」と議論するといった、人間が持っている、やりながら学んで、それを自分たちのものにしていく、ということをプロセスの中に組み込んでいる。これはアジャイルが初めて明示したことじゃないかと思います。本来、自分たちのためにプロセスがあるはずなのに、いままではどこかの外部から持ってきすぎたな、という反省がありますね。その気付きを与えてくれるのはアジャイルの大きな利点です。自分たちのものだから自分たちでプロセスを作ればいいと、最近そのことをすごく思いますね。週間など反復ごとのミーティングで共有して、それを自分たちのやり方を作り出して解決していこう、というのはまったく健全で、それが本当の近道なんですよね。いえアジャイルの普及には障害がたくさんありますね。ソフトウェア業界のよくないところがあって、例えば利益構造が人月で計算されていると、ゆっくり作った方が儲かるとか、バグ管理ツールが導入されているので、バグをちゃんと出せとか、そういう点が普及の障害になっている点はありますね。大きな会社だと品質保証部というのがあって、リリース前にソフトウェアをそこでチェックしてもらうと「バグがないのはおかしい」って言われることもあります。ファーストで作っているとバグは出ないんです。考え方が違うんですよね。どんなプロジェクトでも、アジャイルが利用できる切り口はたくさんあると思います。つの足がかりとして自分たちになじむところから使っていけばいいと思います。現場をよくしようと考えたとき、今までの幻想として、「ソフトウェアは工業製品だから、何か問題があるならそれは設計に時間をかけて取り組まないのが悪い、とか、最初の計画がおかしいのではとか」って考えがち。現場にいる人は分かっていて、いくら計画や設計のマニュアルを事前に作ったってうまくいかないものはいかなくて、それより顧客を連れてきて一緒に対話しながら動くソフトウェアを作っていったほうが絶対にうまくいくって知っている。ソフトウェアは工業製品だという幻想があまりにも強くて、いままで変化が起こらなかったんです。それでも客先に常駐などして経験値を積んだ人は、何となく顧客の感覚や要望が分かるようになってくるんです。それには何年もかかる。カ月で持って行こうとしているんです。実は以前にパートナー企業さんも含めたプロジェクトをしていて、全員で反復ごとにミーティングをして意見などを定期的に聞いていたんです。したらある日パートナーに呼ばれて「僕たちにはそこまで考えさせないでくれ、計画通りに言われたことはやるから」と言われて衝撃を受けたことがありました。誰もがアジャイルを導入したいわけじゃないんだなと。アジャイルだと、エンジニアが自由に作れる一方で責任も伴ってくるから、そのバランスは難しいですね。業界の中心みたいなところがあって、それだとソフトウェアをうまく作ってもそれほど評価されない。一方で海外だと自社製品やパッケージソフトを作っている人が多くて、それだといかに短期間で品質の高いソフトウェアを作れるか、というところが会社の強みになる。日本でも産業構造が変わらないとだめかもしれないと思っています。いう問題になって、結局それは数字で見えるところで判断するしかないんです。すると、“ちゃんと”やっているかどうかは、例えば“ちゃんと”ハンコをもらって仕事しているかどうかが品質の高いソフトウェアを作ることよりも優先されるかとか、そういう風になっちゃう。大きい会社でモチベーション高くやるには、そのあたりの評価方法を変えていかないと無理じゃないかと思う。エンドユーザー企業の情報システム部門なら、うまくソフトウェアが作れれば社内のエンドユーザーが喜んでくれたり企業の直接の利益になったりするから、開発に対するモチベーションはずいぶん違ってくるでしょうね。いい品質とかいい機能を追求しよう、という気持ちがないといけないですよね。そこがすごく大事なところです。そのためにはソフトウェアの価値をビジネスに転化できるようにしなければ。仕様どおりに作るのがよいのではなくて、本当にいいソフトウェア、本当にビジネスで価値を生み出すソフトウェアを作ろう、という気にならないといけないですよね。業界を持って行かなければなりませんね。研究やコンサルティングも行っている。ソフトウェア開発手法の第一人者。オブジェクト指向技術、アジャイル開発、ファシリテーションなどのコンサルタント。理事)一貫してソフトウェアの開発を生業としテストによる設計とリファクタリングを日課とする実践者。年目でアジャイル開発手法に出会い、いくつものシステム構築案件をアジャイルによって開発してきた事例を持つ。