![]() |
2009年 11月号 |
[OOエンジニアの輪!]
今回のゲストは、和田卓人 さんです。テスト駆動開発の紹介など様々な活動で知られています。
![]() |
|
--- まこたんさんとのつながりは
たぶん arton さんがまこたんを紹介した絡みに似てるかもしれないんですけど、以前「Seasar のからさわぎ」とか、 Seasar*1 のコミュニティが、よく飲み会やってたんですね。初めて会ったのもたぶんこの辺りだったと思う。
--- 2005 年ぐらいですか…
ヨーロッパ選手権が 2004 年だから…… 2004 年、 2005 年ぐらいですね。
僕はサッカーが好きなんですが、サッカーファンというものは 2 年単位で年を覚えていられるんです。 4 年単位でワールドカップがあって、さらにそこから 2 年ずれて 4 年単位でヨーロッパ選手権があるので、大体あの時に何やってたってのは 2 年刻みで大体収まります。
--- なるほど
「 Seasar のからさわぎ」に行くきっかけは、今の名前で言うところの JavaEE 勉強会*2です。角田*3さんが主催してる勉強会で、当時の名前は J2EE without EJB とかかな。
さらに、そこに行くきっかけは(後述する)「チームかくたに」ですね。「チームかくたに」の特にその初期、一番最初期のメンバーの 4 人ってのが、角谷さん、私、芦沢さん、本間さん。その 4 人はなんか異様なチーム、サッカー的に言うと黄金のカルテットみたいな・・・
本間さんに誘われて読書会に行ったんじゃないかなと思います。で、そこから芋づる式にいろんなコミュニティに行くようになって、 Seasar のコミュニティにもつながりができる。まぁその当時、 Java 界でいろいろオープンソースでもりもりやってると大体 Seasar に出会う構図になっていました。
--- プログラミングやソフトウェアとの出会いは?
これに関しては、僕自身は他の人をちょっとコンプレックスに思ったり、うらやましいと思ったりしています。いろんなすごい人の話を聞くと、幼少期から触ってた人が結構多いじゃないですか。僕は全然なんですよ。大学からですね。
大学の 1 年ぐらいの時ですかね、ちょっと短期留学したんです。アメリカの大学の、バークレーじゃないとこに。でもバークレーは行ってみたかったな・・(笑)。で、その大学で短い期間、勉強してたんですけど、そこでは普通にみんなコンピュータを使っていました。コンピュータルーム、ラボがあって、これは面白いな、かっこいいなと思いました。
日本に帰ってきて、俺もコンピュータが欲しいなと思ったのが、たぶん主体的にコンピュータを見る最初のきっかけになりました。それ以前には、親父がずーっとコンピュータの仕事やってるので、家にコンピュータとかあったんですけど、そんなに興味は惹かれなかったんです。
---その後、プログラミング自体に興味を持ったのは?
その当時は親父が既に独立してソフトウェア開発の会社(タワーズ・クエスト株式会社)をやっていて。プログラミングを始める(直接の)きっかけは親父の仕事を手伝ったことです。
例えば夏休みの間とか、仕事の手伝いとかをしてるうちにプログラミングとか自体が面白くなってきたという感じですね。最初はプログラミングからやったんじゃなくて、データベース設計の手伝いから入りました。
自分でもりもりプログラムを書き出すのはそのちょっと後です。親父はデータベースの鬼みたいな人間で、最初は親父のアシスタントというか手伝いみたいなのをやってたんですね。必然的にデータベース設計の補佐みたいな仕事が一番最初の仕事になって、そこから主体的にプログラミングに関わり出すきっかけが始まったのだと思います。そのうち、自分でもプログラムを書き出すようになったという感じですね。
--- その後、情報系に進んだんですね。
そうですね。3 年次以降、好きなところ選べっていうような大学だったので、情報系に進みました。卒論はですね、パワータイプの永続化について(笑)。
大学の最後のほうはコミュニティ活動とか勉強会とかにいろいろ行ったりしていたので、アナリシスパターンとかに出会ったのも大学の 4 年かな?そこでオージスさんのアナパタ勉強会*4にも顔出していました。最終的に卒論としてやったのがオープンソースソフトウェアを使った、アナリシスパターンにおけるパワータイプの永続化についてみたいな、なんか OO 厨ど真ん中みたいなそういう研究です(笑)
--- 具体的には?
具体的にはもうあんまり思い出せないんですけど、結局パワータイプって 1 階層メタな階層なんですね。そのメタ階層、要するに知識レベル、操作レベル(の分類)で言うところの、知識レベルの構造化、階層化、永続化をおこなって、それを(操作レベルの)インスタンスにも作用させるようなものです。要するに卒論でオレオレ O/R マッパーを作ったということですね。
--- つまり動的にスキーマを変更できる O/R マッパーですね?
たぶん今の僕の興味にもつながってくるんですけど、もともと動的にシステムを構築して動的に作り変えることに興味があるので、メタレベルの知識をシステムに持たせるのが好きだってことですね。

--- そもそもオブジェクト指向に興味を持ったきっかけは?
大学時代にオブジェクト指向に興味を持ったきっかけは、たぶんデータベース設計に端を発してデータベース設計とプログラミングのふたつを見たという経験に端を発してるんじゃないかなとは思います。
データベース設計の方はデータ中心の DOA の世界で、親父の仕事の手伝いで DOA の設計を白紙の状態から叩き込まれたわけですね。それに対して、自分でプログラム書き出して、世界がそれだけじゃないっていうことをなんとなく分かってくるんです。
例えばプログラミングの雑誌とかを読み出すとオブジェクト指向のこととかいろいろ書いてあるわけです。オブジェクト指向という言葉や概念に興味を持ち出したのは、たぶんその辺りなんじゃないかなと思います。
何を読んでたかな。 C MAGAZINE 、 DDJ 、あと 技評*5系。最初の頃の JAVA PRESS とか、後は IDG の JavaWorld もあったかな。なんかかなり時系列的に怪しいですけど。
オブジェクト指向自体が分かったというか、なるほどこういうものかって思うきっかけになったのは(大城さんが書かれた) C MAGAZINE のデザインパターンの連載です。
デザインパターンの構造面からの理解についての入門記事でした。ただ(珍しいのは)、ヴォルフガング・プリーのメタパターンと、 GoF 本*6の 2 つを土台にした説明だったんですね。メタパターンの本は今絶版になっちゃってるんですけど。*7
結局のところ、オブジェクト指向が「あ、分かった」って思うのは、ポリモーフィズムとかが分かるっていうことじゃないですか。で、それが分かるようになったきっかけをくれたのが、その C マガのデザインパターンの連載なので、本当に恩を感じています。雑誌だから本屋から無くなっちゃうじゃないですか。大学の図書館で無い号は取り寄せてもらって、全部集めて印刷して読んでました。
--- メタパターンって言葉自体、忘れてました。
メタパターンという言葉自体がその連載に出てきたかどうかは、ちょっと今は覚えてないんですけど。
--- 目指すところが似てたってことですか?
構造面から捉えるということ。なんかデザインパターンって数がいっぱいあって面食らっちゃうじゃないですか、 20 いくつありますみたいな感じになって。それらも結局デザインパターンの構造自体に還元すると 3 つか 4 つしかないよって言ったのがメタパターンの本です。そこからやっと理解の射程に入ってくるわけですね。数が 7 つ以下なら覚えられるぞ、みたいな。
--- 確かに。デザインパターンは実体験から収集したやつだから、きれいにまとまっているわけでは無いですね。
デザインパターン自体、用途からパターンという形に構造を持っていっているので、本当のクラスとかインスタンス同士の関係まで目を向けていくと、もっとバリエーションは少ない。
--- なるほど。大学生なのに社会人のエンタープライズ系やってる人の入り方ですね。仕事を手伝った縁が利いてますね。
うーん、そうなんかもしれません。アメリカに行って「あ、俺もコンピュータ欲しいな」と思ってから、なんか飛躍がありますよね。自分でもなんだろなと思う。
やっぱり仕事を手伝っていて、いきなりリアルなデータとかリアルなシステムに触れて向かい合ったおかげで、自分の中で意識が変わったというか、興味が持てて面白かったのかもしれません。
--- リアルなデータ。よくある入門書のような、犬がワン、猫がニャーって言うようなオブジェクト指向の説明から入っていないですね。
後はやっぱり図書館。大学の図書館がやっぱりうれしかったですね。高い技術書も読むことができた。そのとき確かまだ UML が出てきたばっかりぐらいのときで、なんだっけ、 Rational Unified Process でしたっけ。 RUP とかぜんぜんなくって。あれですよ、 OO 御三家の時代の最後の残党ですよ。
そうそう、ブーチ*10があって、ランボー*11 があって、ヤコブソン*12 がある。で、 OMT はなぜか親父が持ってたんですよ。一番データ中心に近いからかもしれないですね。
--- OMT にはもともと DFD*13 とかも入ってましたからね。
やっぱりそういう源流があるからですかね。だから、その御三家の本の中で一番最初に見たのは、親父が持っていた OMT ということになるんです。でもそれだけじゃないよというのは、その後オージスのオブジェクトの広場とか見ると分かってくるんですね。
--- Booch法などにも興味を持ちましたか?
Booch法と OOSE は大学の図書館で読みました。トッパン(の出版部)がそのころになくなったじゃないですか*14。 OOSE がトッパンから出てたんですね。 OOSE が手に入らなくなったので、一番最初に読んだのは洋書で読んだんです。その後、大学の時に中古市場というか、古本とか古レコードとかを買ってくるアルバイトみたいなのをときどきやっていたんですが、あるとき絶版になったトッパンの本が出回るよという情報が伝わってきて、じゃ「トッパン狩り」に行くかと思って、そのときに絶版になったトッパンの本を一気に買ってきたのが、たぶん大学の一番最後ぐらいの時です。
--- トッパン狩り(笑)
メタパターンの本と OOSE の本の邦訳をようやく手に入れたのがそのトッパン狩りのときです。
ヤコブソンの英語、難しかったですね(笑)
--- 興味が多岐に渡っていますね。
時系列で整理してみると、親父の仕事の手伝いから、プログラミングの勉強、さらに大学が後ろの年次になると情報系の授業が入ってきて、コンパイラや OS とか各種言語、当然プログラミングとかオブジェクト指向の授業を受けたりして、興味がずーっと膨らんでいった。
ただ、本当に勉強してありがたかったなぁと思うのは最近になってからなんです。オートマトン、あの時に習っといてよかったとか、ようやく分かってきた。先生ありがとう(笑)。
--- 確かに(笑)
当時は全然ちんぷんかんぷんでした。その数年前にコンピュータ初めて触ったぐらいの人間なもので。でもやりだすと凝り性なので、分からないなりに雑誌とか C マガとか DDJ とかでいろいろ勉強してました。あとインターネットを大学で使えたので、オブジェクト指向のこと調べてると、オージスのオブジェクトの広場のページに行くわけですよ。これは本当に嘘じゃなく。
そのオブジェクトの広場のページにパターン大集合のような、パターンのページ*15があって、そこの下に星取表があったんです。パターンの難しさとかマニアック度みたいなやつ、ありましたよね?
--- ありましたね
で、そのページを読んだときのことは今もはっきり覚えてるんですけど、 GoF 本*16があって、 POSA *17があって、そして星 5 つに『アナリシスパターン』があったんです。パターン本のなかで一番難しい、一番マニアック向けみたいな煽りが書かれていて、その星 5 つを見て、俺はじゃあこれをやってみようって思ったんです。煽られたんですね。
そのとき既にアナパタ読書会*18が始まってたんですよ。僕は途中から参加という形で、ちょっと 1 回行ってみようと思った。僕の勉強会初体験は間違いなくそれなんですよ。
親父以外のこの業界の人で僕が一番最初に会ってるのは伊藤さん、天野さん、あと児玉さん*19や、友野さん*20や、矢崎さんというアナパタ勉強会で会った人たちです。そして僕がこの業界の人って面白いなとか、オブジェクト指向関係の勉強会とか面白いなと思って引き込まれた一番のきっかけは藤野さん。アナパタ勉強会に藤野さん*21がいらっしゃって、これまで見た人の中で一番変な人だったんです。強烈な印象を受けました。
あぁこんな人がいる業界なんだと思って。この界隈に集まる人間は面白いぞと。だから、もっといろいろ行ってみようと思い、そういうところにも顔出していろいろ勉強しました。太田さんと最初に出会ったのも学生のときでした。
アナパタ本を知ったり勉強会を知ったきっかけは間違いなくオージスで、いま思うとインタビュー企画*22もその頃に既に始まってたと思うんですよね。だから、僕が今日ここでしゃべってるということは感無量なんです。一周して戻ってきたという形なんですよ。このサイトで育った人間が。
--- 大学を卒業してすぐにタワーズ・クエストですか?
大学を出る直前に親父の会社を手伝おうと思うきっかけがあって、大学出てすぐ入りました。でも在学中からすでに親父の仕事の手伝いを既にしていたので、学生をしつつ、勉強会にいろいろ行きっていました。
--- すでに半分社会人化してた?
そうですね。どちらかというと地続きで、学生プログラマから親父の会社のプログラマという肩書きに変わって、続きをやるみたいな、そういう感覚ですね。
--- 会社に入って、新入社員から研修やって、最初の案件に、という感じではまったくないってことですね。
ないですね。新人研修を受けたことがないです。受けたいです(笑)
大学出てから最初の仕事は。うーんと、そうですね、オレオレ認証局を立てたのが最初の仕事です。あのう、高木先生に怒られそうな仕事です。その仕事はピンのプログラマとして入った最初の仕事でもありました。要件定義以外全部やるみたいなイメージですね。
ああ、そのときは仕事を libretto *23でやってたんだ。 libretto って覚えてますか?
--- はい、あのちっこいやつですよね。
まだ自分自身で自由になるお金が少なかったので、パソコンを自分の金で最初に買ったのも遅かったんですよ。最初にコンピュータ欲しいと思った時は、情けないながら要するに親に買ってもらった形なんで。だから、自分でアルバイトしたりなんなり、その後、お金稼いで最初に買ったパソコンが libretto の 30 だったと思います。確か一番古いのから 2 番目ぐらいのモデルですね。
--- それで仕事は、、そこそこきついのでは。
きつい。いや、そこそこじゃなくきついです。でも卒論もその libretto で書いたんですよ。その libretto こそは誰かにもらったパソコンじゃなくて自分で買った最初のパソコンで、大好きだったんですね。買ったのはジャンク品で OS も入っていなかったものでした。そこに Plamo Linux *24を入れて使っていました。
私が今まであまり Windows を使ったことが無いのはなぜかというと、そのころに Linux を触ってるからなのかもしれません。大学の OS ってだいたい Unix じゃないですか。 Unix を家に持って帰って自分でも勉強したいなと思って、その中古の libretto を買ってきて。ちっこい画面とキーボードなんですけど、その代わり 1 日中好きに触れる Unix だったんでです。超幸せでした。
時間戻っちゃって申し訳ない。これは、大学最後の頃の話なんだけど・・・
--- ぜんぜん大丈夫です。
その頃の Linux 系の雑誌って、結構思想色が強かったっていうか、左っぽいというか、オープンソースアクティビティに対して、すごく強いメッセージを発してたようなところがあるじゃないですか。大学生で厨真っ只中なので、思想にがっつりやられるんですよ。オープンソースの精神みたいなものが雑誌にいっぱい書いてあるし。あともう一つ、当時から、 genpaku.org *25がもう既にあって、要するに、『伽藍とバザール』*26とか『ノウアスフィアの開墾』*27とかの翻訳が読める時代だったんですよ。 2001 年ぐらいって。
その辺に頭でっかちな大学生はがっつりやられるわけです。
--- (話を戻します)
で、この libretto で、しばらく仕事をしていました。自分の稼いだお金で自分の使うものを買おうと思っていたので、しばらく貧乏仕様のマシンでやってたんだと思います。「俺、この案件がうまくいけば新しいノート買うんだ」みたいな。
その仕事の後は、電子カルテのシステムの個人開業医版、みたいなものを作ったりしました。
--- それらの案件は Java ですか?
そうです。 Java です。大学のときから Java をやっていたので、全部 Java ですね。電子カルテは Apache の Cocoon *28で作って、一生分の XSLT を書きました、、ちょっと極端でしたね。
その後は、製造業のメーカーの部品調達システムなどをやっていました。その仕事が終わったのが確か 2002 年ですね。打ち上げの日が日韓ワールドカップの開幕の日だった。
その次は、がっつり一つのプロジェクトに入ります。公共系のプロジェクトです。これまでやった中で抜きん出て巨大なプロジェクトで、数百人規模でした。
--- 人月じゃなくて同時稼動で数百人ですか?
そうですね。「(プロジェクトのために)ビルを借ります」みたいな、そんな世界でした。元請けとして大手 SI ベンダーが取って、さらにその下にまたでっかい SI ベンダーが請けてみたいな巨大なピラミッドでした。
--- みんながイメージする IT 業界の感じですね
前の製造業のシステムをある程度成功させたので、プロジェクトが終わって紹介される形で入っていきました。
--- ウォーターフォール案件ですか?
ど真ん中。ウォーターフォールど真ん中です。「滝」を堪能しました。
そのプロジェクトに入る最初の日に面接がありました。面接に行くまで何のプロジェクトか知らされていないので、でかいビルに行きました。そこで SE としてやってくれという面接があった。
なんか雲行きが怪しいなと思って、エクセル仕事になりそうだったので、嫌ですって答えました。僕、コード書かないエクセルの仕事は嫌なので帰りますって、その場で言っちゃって。
そのとき、面接をしていた部屋のすぐ外にでっかいホワイトボードがあって、フレームワークチームみたいな人たちが仕事をしていました。なんていうんですかね、わりと異色の集団だからフロアの一番端っこにいたのだと思います。そのホワイトボードに描かれている図とか机の汚い様とか見て、あ、このチームにだったら残っても良いですと言いました。
面接に来たくせにひどいですね(笑)。そんな無茶を言ったら、「それでいいので、手伝ってください」という形でそちらのチームに。今でもなんてこと言ったんだろうって思います(笑)
--- すごい。一発で話が通ったんですか?
事前に僕のことを知ってたのかどうか分からないです。ただ前の仕事でやっていた事は、ひょっとしたら伝わっていたのかもしれないです。僕の面接をしたひとは結構若い、僕の 3 つ上ぐらいの人で、僕の想い自体は伝わったみたいです。そこまでやってきた仕事は書いてきたので、「こんなのはやりたくない、こういうのならやりたい」という話が伝わって、ポンと配置換えが通ったんでしょうか。
--- ちなみにフレームワークチームのメンバーの仕事は面白かったですか?
面白かったです。やっぱり、でっかい組織の中の異色集団みたいな感じじゃないですか。
そこに入ってコードを書いたりしてるうちに、プロパーの人がリーダーで、僕がサブリーダーという感じになっていきました。でっかい組織、でっかいプロジェクトで、技術的な決定に関わる権限をほとんどもらえて、いろいろできたという経験は、一番ありがたかったですね。自分のスキル、技術的な背景、鍛錬する時期、時間的なものとか環境的なものとか、そういったものを多く与えてもらった。
--- 全体としてはウォーターフォールだけど、チームに限って言えばアジャイル開発だったのですか。
思想的な背景としてアナパタとかデザインパターンとか、そういうのが設計の土台としてあったんですけど、時期がまさに 2002 年とかからなので、白本*29やピンクの本*30は当然出てて、黒い本*31、 XP のシグニチャシリーズはだいたい出てたぐらいの時期でした。
XP シリーズのエッセンスもチームに導入しました。思想的な背景と技術的な背景、ユニットテストも含めて。ウォーターフォールの滝の中で、フレームワークチームだけは略式のイテレーションをしていたと思います。
ユニットテスト自体はもっと前からやってたんですけど、ユニットテストの文化を他の人に伝える、教えるというのを広く始めるきっかけになったのもそのプロジェクトです。チームスキルとか、プロセスそのものであるとか、そういったものに興味を持ち出したのもこの時代。大変なプロジェクトだったんですけど、鍛えられたしすごく感謝してます。

--- じゃあ、「チームかくたに」との合流編にいきますか。
2 年ぐらいやってプロジェクトが一区切りついた感じがしたので、ちょっと別のところに行こうと思っていました。その頃から XP ユーザ会の集まりにいろいろ顔を出していたので、永和でやってみないかみたいなことを誰かに誘われる。誰かが僕を「チームかくたに」へと引き込んだらしいんですけど、誰かよくわからないんです。たぶん懸田さんなんじゃないかと思ってるんですけど。
--- コミュニティドリヴン
そうですね。ただ守秘義務がある世界なので、どういうチームに行くのかわからない。営業の人からコンタクトがあって面接に行く事になるんですが、その営業の人に誰が吹き込んだのかは結局わからない。
(当時の)品川のオフィスに面接に行くと、「チームかくたに」の他のメンバーが入ってきました。角谷さん、芦沢さん、本間さんが入ってきて、そこで初めて、僕が XP のコーチ役っていうことを言われたんですね。えー、なにそれって内心で思いました(笑)。
--- それもなんかすごい話ですね。
その頃 XP を本気でやりたいなぁと思っていて、そのことを誰かにしゃべったからなのかもしれませんね。大きなプロジェクトの中でリファクタリングとか、ユニットテスティングとか、プログラミングプラクティスとチームプラクティスの一部分をやっていたので、その経験を生かして XP のコーチをすることをイメージしました。
4 人のうち 2 人はアジャイル未経験。角谷さんも XP を実際にやるのは初めてで、でも XP の本はがっつり読んでますみたいな感じでしたね。で、よっしゃやるかっていう感じで始めたのが 2004 年 7 月 1 日です。
--- なんでそんな完璧に覚えてるんですか(笑)
僕がはてなダイアリーを始めた日*32でもあるからです。
最初のころのエントリはかなり青臭いですよ、 Eclipse 始めたんだけど Emacs キーバインドでいつもやってたから印刷ダイアログが出るみたいな、そんなしょうもないこと。そのとき他の人がみんな、角谷さんは角谷 HTML 化計画*33というウェブログで有名だったし、本間さんもはてなの日記で人気だったし、ふたつとも購読してたのですごいビビッた。芦沢さんも芦沢さんで、直前に WebSphere MAGAZINE という雑誌読んでたら、芦沢さんが普通に顔出し写真で載っていて、結局 3 人とも有名人ですごく驚きました。
--- しかもコーチとして入るんですね。
何で俺が教える側なんだろうみたいな。平鍋さんとか懸田さんが鳴り物入りで「すごいやつが来るぞ」みたいなことを言ってたらしいんです。後で角谷さんに聞いたら。「 XP のすげぇのが来るからお前ら驚くなよ」みたいなことを言われていたらしいです(笑) 。
2004 年 7 月 1 日に品川の永和のオフィスに行って挨拶をする、その 2 週間前ぐらいから芦沢さんと角谷さんは設計みたいなのを始めていました。実際に環境を作ってコードを書き始めるのが 7 月 1 日とか 2 日とかからだったんです。プロジェクトを回し出そうというときに本間さんと私が入ったという構図になるんです。
そこで、じゃあ、設計はあるからペアプロをしようか、みたいな感じで角谷さんとペアプロを始めました。最初にあるドメインクラスを実装しようとしたら、いきなりコンパイルエラーになったんです(笑)
(編注:javaのコアクラスと同じ名前のドメインクラスが存在してコンパイルできないという事態が起こった。オフレコなので詳細はカット)
角谷さんがよく思い出話でしゃべってるんですけど、それまで JUDE でがっつりと UML のクラス図を描いて、いざ、テスト書きはじめたら直後にコンパイルエラー(笑)UML で描いてきたものをテストファーストで一瞬のうちに粉砕されたわけです。それが角谷さんにはすごいショッキングというか、驚き、強いインパクトがあったと、よくしゃべってますね。
--- それからはもう完全に純粋 XP ですか? 2 週間でイテレーションするような。
実験室のような、理想的な環境に近い感じでしょうか。スキル的にも恵まれすぎだと思うんですけど、ピュア XP ですね。 お客さま自体も XP でやりたいからそういうチームを用意してくれっていうことを言って始まったプロジェクトだったんです。
自重せず、思いっきりやっていいというチームでした。プログラミングプラクティス自体はそれまでやってきたものがあるんだけど、ストーリーカードとかストーリープランニング、あとは短いイテレーションやスタンドアップミーティングとか、全部入りでやっちゃっていいよと。
じゃあ、全部やる。 KPT もそのときに始めたし、スタンドアップミーティングもそのときに始めたし、そのときの XP の全部をとにかくやってみようと思ってました。
--- 例えばメタファーみたいな、(未経験者には)ちょっとやりづらいプラクティスも含むのですか。
メタファーはそれなりにみたいな感じでした。実際、お客さんとやり取りでちょっと使いました。作るものが制御ソフトに近い側面を持っているので、メタファー自体も「ボールがこっちからこっちへ」っていう感じの、機械のメタファーでした。インターネット物理モデル*34みたいな。
--- ちなみに最終的にプロジェクト自体はうまくいきました?
金額的なものとかは僕は把握できないからあれなんですけど、プロジェクト自体は僕が抜けて納品されたあとも続いています。というのが、評価になるでしょうか。
--- 一応、和田さんがいた期間っていうのはどれくらい?
15 ヶ月ぐらい。イテレーションは 20 周以上はしましたね、おそらく。

--- XPでは、制御しきれなくなる瞬間が必ずあるといわれますが、このプロジェクトでは何回かありましたか?
ありました。
QCDS ってあるじゃないですか、クオリティ、コスト、デリバリー、スコープです。ハードワークになったときに、その中のスコープを取るかデリバリーを取るかという 2 択になりました。コストは変動要因としてチームからはだいたい制御不能なのでコストのレバーはいじれません。クオリティは落としてどうにかなるものではないので落としません(品質を下げると開発スピードが上がるというのは誤りで、むしろスピードは落ちます)。結局、機能を減らしてデリバリーを取るか、それとも機能を重視してデリバリーを遅らせるかという 2 択になります。
その 2 択というのが、 XP とかアジャイルプロセスにおける厳しい選択を迫られる瞬間。この瞬間はやっぱり何度かあったのですが、一番最初の時はロールとして僕が言いました。お客さまに対して「このイテレーション、バーンアップしている*35んですが、このイテレーションの機能を減らすか、もしくは納期、イテレーションの期間を延ばすか、その 2 択になります」と。「できないものはできません」ということを言ったんですね。怖かったですけど。それが一番厳しいときだったと思います。
--- たぶんXPの理想としてはスコープ(機能の多寡)でスケールさせるほうがいい。
そうですね。イテレーションの長さを変動させてしまうと、指標値として次のイテレーションに活かせるきれいな値が取れないし、そもそもイテレーションの期間を 1 回伸ばしちゃうといろいろタガが外れてしまうので。
結局最初のときは双方歩み寄るみたいな形になりました。 18 時とか 19 時には帰らないでかなり残業して、だけど機能(ストーリ)をいくつか落としてもらってという感じですね。その後も何回かそういう瞬間があって、シビアな決断をしました。
--- 20 以上のイテレーションの中で何回かってレベルで済んだんですか?
何回かですね。一番最初が一番緊張したので覚えています。 XP の本とかにたまにそういう瞬間の話って出てくるじゃないですか。「あ、本で読んだ瞬間が!」って。しかもロールモデル的にはコーチの俺が多分言わなきゃいけない(笑)。
--- 当時が XP ができるチームとしては最高峰のメンバーを集めても、やっぱりそういう瞬間は避けらんないんだなっていうことですね
技術的なリスクには想定外のものが結構あります。例えばマイナーな技術やサーバを使っていたりとか…。
技術的な問題は、はまったときに抜け出すまでの時間が分からなかったりしますね。
そもそもはまるかどうかもわからないし、はまったらはまったで際限なくみたいなことになっちゃうので、難しい。その検証も含めてスパイクソリューションとして本来やっていくべきなんですね。
--- そのプロジェクト自体はその後も続いた。
まだ続いていると聞いています。
永和システムマネジメントの中で最初の XP の火を灯す。最初にって言うとたぶん語弊があって、たぶん前にもやってたことがあるんですけど、いわゆる XP 的なるものをドンと文化として体現してみせた意味は結構大きいのかもしれないなと思っています。
--- その後、 2005 年以降は?
2005 年は群馬に行きます。
--- あ、そうだ。 PofEAA *36で群馬明けといってることが多かった気が。
群馬農協のシステムの刷新に関するプロジェクトに参加しました。スターロジック*37の羽生さんと一緒に行った案件です。羽生さんのアシスタントとして私がいて、 2 人から入るみたいな案件でした。
--- じゃあ、 DB 設計とか羽生流でやるとか?それを手伝うとか?
それも含めて。マジカ!*38を使ったりとか、 Seasar を使ったりとかです。 Seasar 、仕事で使ったのはそれが初めてですね。
--- 結構、案件としてはかなり気持ちの切り替えがありますね。
うん、まったく違いますね。そういうのもやってみようという気持ちも一つありました。どっちかというと超短期ウォーターフォールみたいな感じです。実装フェーズになるとくるくる回すことになるんですけど。
その案件のときはマジカ!とか要件定義をがっつりやったのが大きい経験でしたね。プログラミング以外のことでいろいろ学ぶことがあった。要件定義のところとか、お客さんとのやり取りであるとか、そういったところの学びはすごい大きかったです。
技術的には、 Seasar を自由に使って、好きにやれみたいな感じでした。技術的な決定権があったんですよ。責任も大きかったですけど、いろいろできたというところが大きいです。
--- ちなみに最近は何を?
自分たちの会社で独立してやっていこうと考えて、小規模 SI の仕事、受託案件をメインに、自社製品の開発もやっています。メインの言語がやや Ruby に寄る感じです。
--- 結構 Ruby 化されてるんですか?
キャリア的には Java の方が仕事で扱い易かったんですけど、 Ruby で仕事を受けてみたいというか、動的なシステムを作る足がかりなども含めていろいろやりたかったんです。あと Ruby 界隈に知り合いや面白い人が多かった。その辺の事情もあり Ruby やってみようと。
--- なるほど。直感にしたがった感じですね
そうですね。ドライな判断ではないです。売り上げ的にも、下世話な話でいうと価格的に Ruby 案件のほうが小さいですからね、 Java の案件よりは。
--- 小回りが利くっていうか。
まぁ小回りが利くといえばそのとおり。
--- ちなみにWeb 系ですか?
僕の今の仕事は Web 系です。
--- じゃ、いわゆる rails *39とか?
うん、今現在は rails 。とうとう rails に手を出したというか、いよいよ焼きが回ったっていうか。 rails やってます。 rails が「だんだんわかってきた」ところです。面白いです。
去年(2008 年)の JJUG *40で高井さんと角谷さんと私の 3 人で鼎談みたいなの*41をやったんですけど、そこで Ruby on Rails はそれまでの歴史の延長線上にあるという話をしました。
PofEAA があって、その前にデザインパターンがあって、あとは Pragmatic Programmer*42 のバージョン管理、自動化、ユニットテストの三本柱の概念があって……それまでの良い歴史をソフトウェアの形、フルスタックの形にまとめたものが Ruby on Rails の姿なので、自分と思想的に近い。 DHH *43はよく勉強してるなぁみたいな、そういう感じなのでよくなじみます。
ただ、 rails 自体は歴史が結構長いので、コードベースが巨大、しかもメタプログラミングだらけだし、把握しかねる感じでした。最近になって rails の熟練者と一緒に仕事やりだして、ようやく分かってきました。
それまでは自分の把握できる範囲で自分でフレームワーク書くという感じで Ruby をやってた。自分でフレームワーク書いたり、もっと小さい、アンチ rails の light weight なフレームワークの上でシステム作ったりですね。
--- Sinatra *44とかそういう?
そう、今で言うと Sinatra 。そのときは Ramaze *45でやっていました。

--- 和田さんというと TDD と REST のイメージがありますがお話を聞かせてください
TDD を僕に教えてくれたのはまさーる*46さんなんですよ。
--- 直接ですか? インターネットで?
僕は直接、何度かお会いしたことがあって、最初にお会いした日は日韓ワールドカップのアルゼンチン対イングランドの日なんです。
--- えーと。 2002 年ですね。
まさーるさんは、関西の人だったから、東京に来るのは何かの講演やイベントで壇上に立つときか、もしくは参加される時だったのではないかと思います。私がお会いしたのは、確か IBM 系の技術カンファレンスだったと思います。ソフトウェアテストのセッションで最前列にいたのがまさーるさん。僕も参加者として出席していて、その時 XP やテスティングに凄く興味があったので、そのセッションに出席していた人をつかまえていろいろ質問してたんです。
その時まさーるさんにも声をかけていろいろ質問していたら、話している間に(その人が)まさーるさんだと分かってすごくびっくりした。いろいろ教えてもらいました。「チームかくたに」のペアの回し方もまさーるさんがアイディアのもとなんですよ。さいころ(やグーパー)でペアを決めるとか。
--- TDD を深く追うようになったきっかけは何ですか?
やはりまさーるさんです。当時はメーリングリストの時代だったじゃないですか。日本には XP-jp とか OOSquare のメーリングリストがあって、オブジェクト指向の議論がメールベースで行われていました。(特にに海外の)アジャイルとか XP とかの議論は c2.com とメーリングリストの 2 つで行われていたんですね。 C2 の方は Wiki に書きこんでなんかそこで議論が発生するってタイプで、スレッド型の議論はメーリングリストで行われるスタイルでした。
その中で、ケントベックが書きすすめている書籍の生原稿みたいなものをどこかで公開していてるという話があって、まさーるさんが面白いからそれを読んでみるといいよと俺に教えてくれたんです。
当時の案件が結構大変だったので、家に帰る頃には終電がなくなって深夜バスで帰ってたんですね。その深夜バスの中でずっと写経(その原稿のコードを全部打ち込んで実行してみること)をしていたんですよ。バスの中って他にやることがなくって、周りの人なんか、酔っ払いとか死人風とかみたいな。 。そのような中で本を全部書き写しました、だからこそ、その本が何を云わんとしているかが分かったのかもしれません。
「言葉ではなく心で理解できた」んですよ。それがTDD の原体験です。本当にまさーるさんとケントベックのおかげです。
和田さんにとっての TDD とは
これはずっと言い続けているんですけど、設計を行うためのものです。 TDD はコードからのフィードバック、心からのフィードバック、フィードバックを受けて、システムの設計自体をもっと動的に動かしていく、変更させていく時の触媒の一つのようにとらえています。
--- 設計ツール?
そうですね。キャンバスみたい。なんていうか、粘土みたいなんですよ。
--- BDD っていう言葉ができる前から完全にその立場なんですね?
BDD という言葉が使われだしたのは、 XP のメーリングリスト*47で、テストという言葉が与える誤解が強いから、いっそのこと別の言葉にしようという議論が出てきたからです。
--- 確かに。単体テストって言っちゃうと、カバレッジがどうこうという話になってしまいますね
なりますね。そういう重力がある。
--- 名前を変えちゃった方が分かりやすいということですね
そうそう。でも、そのスレッドに対してケントベックが 「 "What evolved?"*48 何が進化したんだい?」、みたいなことをつっこんでました。命名変更みたいなやつはきっと大事なんだと思うんだけど、僕自身は同じことをやっているつもりなのでテスト駆動という言葉を使い続けている。それだけですね。

--- TDD について現在はどんな方向に興味を持っていますか?
テスト駆動や、テスト駆動と言わないまでも、自分が書くコードに対して自動テストを書くというプラクティスは、ほんとにここ 2 年くらいで多くの人がやるようになってきたと思っているんです。
僕自身は「チームかくたに」時代のころからテスト駆動のことを講演しているんですが、最近では「JUnit でコードを書いたことがありますか」って手を挙げてもらうと、ほとんどの人が手が挙がるという状況です。最近のコードを書いている人は、普通にテストを書くようになってきているんですよ。
ただ、そのテストのメンテナンス、テストを減らしたり、改善したり、そういう話はまだ多くないんですね。(例えば)テストが増えてくると、全部のテスト通すのに 3 時間かかったりとか、 テストの量自体が問題になってくる。またテストが実装に深く依存してて、リファクタリングしたらテストがばーっと真っ赤*49になっちゃうからやめようみたいな話とか。
テストをたくさん書けば良いってものじゃないんですよ。設計の改善を前後で担保するためのテストだったはずなのに、設計改善の邪魔をしてるんじゃないか? と。テストが変更のコストを一定にするという夢を俺たちは見てやってきたのに、テストが増えると変更コストが上がっていないかい? という問題に対してどう戦うか、それが今の TDD の主戦場だと思っています。
「設計の変更を後押しするテストと妨げるテストがある」「このテストの意図はこうで、価値はどのくらいで、どこまで自分を助けて、どこから自分を邪魔するの?」みたいなものは(自分の)感覚としては分かるんだけど、それを他の人に説明できるようにしたいと思います。相対値で、相対評価でいいので、何とか分かるようにしたいっていうのがある。
テストコード自体のリファクタリングとかトランジションとか、そういったことを伝えたり、研究したいっていうのが最近の思いです。
--- まだパターンにしてみたり、理論化する所には到達していないですか?
まだ生煮えというか、イディオムとかプラクティスみたいなものになっちゃうかもしれないですね。
--- さらにその先、 TDD の向こう側みたいなものを考えていますか
もっと動的でありたい。システムが動的ならテストも動的で、コードで書かれたテスト自体が石版に書かれたものみたいのではなくて、もっとテスト自身の意図を持って、プロダクトコードと一緒に形を変えるようなものであってほしいと僕は思っています。こんなこと言うとどんどん品質保証の考えから離れていっちゃうのかもしれないですけど。
今のテストって。自動的にテストを全部やって(テスト成功を表す)結果の点がボボボボと出ますとか、グリーンバーが出ますとか、それだけで、まだ静的すぎるというか。。(コーディングをしていた時に)自分の思っていたことをそのまま繰り返すだけじゃないですか。
テスト自身がもっと自分で考えて、もっと提案するっていうか、テスト自身が自分自身を書きかえてもいいし、もっと、なんて言うんですかね、驚きのあるものであって、変な、悪い意味じゃなく驚きのあるテストであってほしいと思う。
--- ちょっと。面白そうですね。まだ全然、まだ先がある分野だと思う。
自動テストや TDD はまだまだ歴史が浅いと思うんですよ。テスト用の Main 文を書いておいて、その Main をたたくと自分のテストが動きますという自己テストの時代から、 xUnit の概念をケントベックが編み出した。そこでようやくプログラミング言語間で自動テストの概念の交流がはじまるんですね。 SUnit があり JUnit があり NUnit があり、そうするとテストの考え方のスタンダードとして、言語をまたいでテストの設計論とか実践論の交流が始まって、そこで一気にテスティングの文化が花開いたみたいなところがあると思うんですよ。
そこよりも先に行きたい。
--- 現在の TDD や BDD とは違う概念ですか
もっと違ったものを見たいなとは思いますね。もうそこまでいくと電波の世界なんですけど、今まで積み上げてきたものをゼロにしても、「本当はどういうものを、どういうことをやりたいのか」っていう所からいつか考えてみたいなとは思っています。
今の TDD や振る舞い駆動、例えば Cucumber *50みたいな、「書いた通りに動きます」「動いたかどうか調べます」というのではなくて、自分の考えていることを補完するという、気づきを与えてくれたり、驚きを与えてくれる、生き物のようなテストを書きたいですね。
自然言語に近いとか仕様を写し取るとか、そういった方向も悪くない。でも私はもっとシステムに近くてもいいと思っています。そのかわり、もっと驚きに満ちたものがいいという思いがある。 RSpec *51とか Cucumber は素晴らしいと思うし、 BDD も TDD も素晴らしいと思うけど、もっと違うものも見たいっていうことなんですね。
--- なんとなく Smalltalker が環境と対話しながらどんどん書いていくイメージと似てますね
きっとそうなんじゃないかなと思っています。既に在った世界なのかも知れませんね。オーパーツみたいなものじゃないですか。 Lisp と Smalltalk って。
( Smalltalk や Lisp のような)動的システムに対する憧れが強くて、それは Ruby を今使っているきっかけの一つかもしれません。以前 Java で動的な Web システムを作ったきっかけも実はそうなんです。Java は基本的にはコンパイルしなきゃ何もできないんですけど、コンパイルしないで自分の動きを変わる Web システムを作りたいなと思って、後ろで動的なコンパイルを行う、その場でクラスを作っていろいろやったりする Web アプリを作ったりしました。
書き手の手を離れて進化する動的なシステムを作りたいという理想があります。その動的なものとは僕の今思っているコードとテストの関係に結局近いものなのかもしれません。
「書いた通りに動きます」というもの以上に、何か作りたいし、見てみたいという思いがあるんです。

--- REST や Resource Oriented Architecture に興味がありますね
はい。きっかけは、オライリーの REST 本の原書*52 を読んだこと。その頃、山本洋平*53さんのブログを読んでいたり、伊藤直也*54さんのブログで、はてなブックマークの実装周りの技術的な議論があって、一時のブログ界隈で REST 談義が深まった時期ですね。あとは Ruby 会議に DHH が来て、 Rails のアーキテクチャが RESTful な方向になるという講演を行ったというのもありますね。
順番的にどっちが先だろう?
--- そういえば和田さんは Web+DB PRESS で REST の特集をやっていましたね
Web+DB PRESS の特集で、羽生さんと私と山本洋平さんで鼎談を行いました。*55 その REST 特集は、鼎談の部と実装の部という構成になっていて、その実装の章を私が Java で書いたんですよ。山本洋平さんの名を冠した特集記事の実装の章を自分が書くというのは、これは責任重大だなと思ったので、やっぱりいろいろ調べるんですよね。いろんなプレッシャーもあるし。そこで REST についてがっつり調べて虜になったというところも大きいですね。
その時に下敷きにしたのが、 Restlet*56 という Java のフレームワークです。そして Restlet の設計が、まさに REST そのものだったんですよ。この体験も大きかったんですね、すごく。 Restlet の設計は Roy Fielding *57の論文を Java で実装しましたという趣きなんです。論文と同じ語彙を使っている。論文に出てくる概念と同じ名前をクラス名などに使っているんですよ。すごくダイレクトなんです。アーキテクチャスタイルの一つの具現化になっているんですね。
--- そこらへんのことを知らないで見ると、 Restlet は面倒にかんじますね。
たぶん、すごい異様な構造を持ったフレームワークだからだと思うんです。ページを表示したいから get とか、 form からリクエストを投げたいから post でとかそういう世界では無い。もっとアーキテクチャスタイルのレイヤから発想していて、「 Web の世界はこうやってできている」という言葉と意志に満ちた構造になっているんです。それが Roy の論文そのものの具現化でもあると考えています。
(自分に対する)影響としては、後付け REST の Rails よりも Restlet の影響の方がずっと強いです。
--- OO 厨(オブジェクト指向原理主義者。現役か否かは問わない)が REST に惹かれることが多いのは何か理由があるんですか?
えっと、理念的なものが大きい。要するに、プラグマティズムの世界とはちょっと違う。一種の意志に富んでいるんですよね。「 Web とはかくあるべし」、「 Web とはこういうものである」、ていう Opinionated なところが、すごく強い。
もちろん、今の Web がそれで動いている、つまり結果的には実践的でもあったという解釈もあるんですけど、その根底にあるのが、すごく、なんていうか、メッセージに富んでいるとうか。
--- 中心部にある理念みたいのがぶれないということですか。
そうですね。厨要素を持っている人って、大義に惹かれるというか、大きい構造自体を解き明かしたいとか、世界の意味を知りたいみたいな面があると思うんです。
特に OO 厨の原始的な欲望として、「世界をモデル化する」っていうのがあるじゃないですか。世の中の成り立ちを知るとか、世の中をまた小さなルールの集合とか組み合わせに還元して理解したいっていう、そういう欲望が強いんじゃないでしょうか。
--- シンプルで少数なルールを組み合わせることによって複雑なものを生み出す
XP もそうなんですよ。シンプルで、小さいプラクティスとか、考え方とか、そういう小さくて単純なものの相乗効果や組み合わせによってカオスを制御するという考え方なので。
世の中のことをもっと知りたいという欲求みたいなものが常にある。 REST に対して興味を持ったのも Web の成り立ちとか仕組みを知りたいというところが大きいと思います。この Web 自体(という仕組み)が、何故これまでうまくいっているのか問い直したい、考え直したい。それらから学ばないと、結局どこかでひずみが出て上手くいかないのではと思います。
あともう一つは、えーっと名詞の世界だからだと思います。
--- 名詞の世界?
REST の世界では動詞は基本的には GET 、 POST 、 PUT 、 DELETE しかない*58。あとはリソース(名詞)。そういう世界だったりするじゃないですか。名詞の世界ということは、つまり概念の発見と命名の世界ですよね。自分の見えていなかったものとか、考えていなかったものを見つけて名前を付けるっていうことじゃないですか。
OO の世界もそう。 OO の設計も結局のところ、責務を見いだしてそれに名前をつけるっていうことですよね。 REST の世界も一番大事なのは URL の設計です。 URL の設計自体も結局のところ、自分の理解とか、自分が表現しようと思っているもの、それらに対して名前と構造を与えるっていうことですよね。で、その名前を与えるということに、、、なんていうんですか、厨をひきつける要素がある。世界を再構築して、一つ一つの要素に対して自分で名前を与えるという行為に、たぶん原始的な想いとか快感とかがあるんだと思うんです。
--- ワード・カニンガムが言っていたような気がしますよね。名前重要と。なるほど、面白いですね。
僕もいましゃべりだしてから初めて理解しました。

--- それでは趣味を教えてください
趣味はコードを書くことなんですけど。
コードを書くのはやっぱり、単にプログラマとしてコードを書くのも好きだから、なんかあったら、時間があったら何か自分の思いを体現するコードを書いてみる。
--- ……ニコ動とかは?
あぁ、ニコ動も好きでした。
--- 好きでした?
いや、好きです。えっと、ニコニコ動画を見すぎて Macbook Pro を壊してしまったので……ニコ動が悪いんじゃなくて僕が悪いんですが(笑)。今は Linux に戻ってきて Ubuntu です。 FLOSS への僕の信仰心が揺らいだから、 Mac に行ったから Mac は壊れたんじゃないかって。自由の世界からちょっと商用 OS の世界に行ってしまったので、罰が下ったんじゃないかと(笑)。ニコニコ動画はいまも大好きですよ。やっぱり Web の世界が好きなんですね。
あとはサッカーを見るのが好きです。
--- サッカーファンって理論好きな人が多い気がしますね
あぁ、サッカーマニアまでいくと全員監督ですから。監督目線ですから(笑)。
サッカーでも統制の取れた軍隊的なサッカーとか、もしくはアドリブに満ちたラテン的サッカーとかいろいろあるんですけど、プロジェクトとか人に当てはめてみたりしても面白いんです。あとはサッカーファンがプロジェクトにいたりすると、今の俺のプロジェクトでのポジションはここだからみたいな話ができる
---あんまりサッカーは知らないですが、、「ジャイアントキリング*59」はちょっといいですね
あぁ、いいですね。実に。
時代が一回りして、サッカーを見ることの楽しみがわかってきた時代になってからの漫画ですね。今まではキャプ翼に代表されるプレイヤー視点、プレイヤーとしての主人公たちの成長を通して物語を描くっていう漫画が多かったんです。ジャイアントキリングとかの最近の漫画は、引いた目線、プレイヤーではなくってファンであったり監督であったりみたいな、ピッチに立たない人の視点があります。つまり読者と目線が近いんですね。
あとはいつどんな試合があったかをサッカーファンは 2 年単位でいろいろ覚えていられるので、いろいろ便利ですよ(笑)。
--- 業務経歴書とか書きやすい?
書きやすい。覚えておきやすいんですよ。「チームかくたに」に入ってすぐにヨーロッパ選手権の決勝があったとか。実はその決勝を恵比寿で生で見ていたので徹夜明けだったとか(笑)。
---最後に若いエンジニアに一言。
手を動かしましょう、手と目から学びましょう。
自分がやってみる、実際にコードを書いてみるとか、実際にホワイトボードに図を描いてみるとか、そういったことは本当に大事です。自分の手と目から受ける情報はすごい豊かだと思っていて、それを大事にしようということを言いたいです。本を読むだけじゃなくて、本読んだらそれを実行して、書いてみて、手と目で覚えましょう。
僕自身テスト駆動開発を本当に丸写経で覚えたということがあるし、今も自分が覚えたいと思うものに関しては本を写経します。 JavaScript を覚えたいと思ったら、『JavaScript The Good Parts』を丸写しして全部書いてみたりとか、 Rails 覚えたいなと思ったら arton さんの書いた本 *60 を丸写しして全部やってみるとか。広く浅くじゃなくって、これだと思った本をしゃぶりつくしてみるといい経験になると思います。
---本日はありがとうございました!!
*1: Seasar プロジェクト https://www.seasar.org/
*2: https://www.wikihouse.com/withoutEJB/
*3: https://secure.ddo.jp/~kaku/tdiary/
*4: https://www.ogis-ri.co.jp/otc/hiroba/others/AnaPatStudy/index.html
*5: 技術評論社
*6: Gang of Four 『デザインパターン』
*7: メタパターンはデザインパターンを構造の観点から抽象化したものであり、フレームワークにおけるホット/コールドスポットの概念やその実装方法を解説している
*8: Object-Oriented Software Engineering 『オブジェクト指向ソフトウェア工学 OOSE use-case によるアプローチ』
*9: Object Modeling Technique 『オブジェクト指向方法論 OMT モデル化と設計
*10: グラディ・ブーチ、『 Booch 法:オブジェクト指向分析と設計』
*11: ジェームズ・ランボー OMT と UML の開発
*12: イヴァー・ヤコブソン OOSE と UML の開発
*13: データフローダイアグラム。構造化システム分析設計手法のダイアグラムでOOな人からは少し古いとも思われていた。
*14: トッパン、出版事業から撤退。 (出版不況 - Wikipedia https://ja.wikipedia.org/wiki/%E5%87%BA%E7%89%88%E4%B8%8D%E6%B3%81)
*15: [オブジェクト本分野別ランキング] デザインパターン https://www.ogis-ri.co.jp/otc/hiroba/OoBook/BookRanking/patternBook/index.html
*16: Gang of Four 『デザインパターン』
*17: 『Pattern-Oriented Software Architecture』、邦訳『ソフトウェアアーキテクチャ』
*18: オブジェクトの広場で開催していた「アナリシスパターン」読書会
*19: 株式会社情報システム総研 児玉公信さん https://isken.co.jp/intro2.html
*20: [OOエンジニアの輪!] 第1回 友野晶夫さんの巻 https://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview01.html
*21: [OOエンジニアの輪!] 第2回 藤野晃延さんの巻 https://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview02.html
*22: https://www.ogis-ri.co.jp/otc/hiroba/others/OORing/index.html
*23: リブレット - Wikipedia https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%96%E3%83%AC%E3%83%83%E3%83%88
*24: https://www.linet.gr.jp/~kojima/Plamo/
*25: プロジェクト杉田玄白 https://www.genpaku.org/
*26: https://cruel.org/freeware/cathedral.html
*27: https://cruel.org/freeware/noosphere.html
*28: Web アプリケーションフレームワーク https://cocoon.apache.org/
*29: 『 XP エクストリーム・プログラミング入門』
*30: 『 XP エクストリーム・プログラミング導入編』
*31: 『 XP エクストリーム・プログラミング懐疑編』
*32: https://d.hatena.ne.jp/t-wada/20040701/
*34: https://www.miraikan.jst.go.jp/exhibition/ex3/
*35: バーンダウン・チャートの用語
*36: 『Patterns of Enterprise Application Architecture』、邦訳:『エンタープライズアプリケーションアーキテクチャパターン』読書会 https://capsctrl.que.jp/kdmsnr/wiki/PofEAA/
*37: 株式会社スターロジック https://www.starlogic.jp/、現:株式会社マジカジャパン https://www.magicajapan.com/
*38: 業務フローが簡単に書ける魔法のカード https://www.magicaland.org/
*39: Ruby on Rails https://rubyonrails.org/
*40: 日本 Java ユーザグループ https://www.java-users.jp/
*41: 『 Java から Ruby へ』・アンド・ナウ https://www.java-users.jp/contents/events/ccc2008fall/sessions.html#A3
*42: 邦訳:『達人プログラマ』 https://www.amazon.co.jp/dp/4894712741
*43: デビッド・ハイネマイヤ・ハンソン Ruby on Rails の作者
*44: Ruby の軽量 Web フレームワーク https://www.sinatrarb.com/
*45: Ruby の軽量 Web フレームワーク https://ramaze.net/
*46: 故石井勝氏 https://www.objectclub.jp/community/memorial/homepage3.nifty.com/masarl/
*47: Yahoo! Groups extremeprogramming https://tech.groups.yahoo.com/group/extremeprogramming/
*48: https://tech.groups.yahoo.com/group/extremeprogramming/message/113575
*49: 失敗すること
*53: https://yohei-y.blogspot.com/
*54: https://d.hatena.ne.jp/naoya/
*55: 動画で配信!「現場で使える REST 」鼎談 https://gihyo.jp/dev/serial/01/rest
*57: Web のアーキテクチャについて論じた論文で初めて REST の概念を明確にした
*58: 厳密には OPTIONS 、 HEAD、 TRACE、 CONNECT もありますが
*59: https://morningmanga.com/lineup/20
*60: 『10日でおぼえる Ruby on Rails入門教室』 https://www.amazon.co.jp/dp/4798114723/, 『かんたんRuby on RailsでWebアプリケーション開発』 https://www.amazon.co.jp/dp/4798111570/
| ©2009 OGIS-RI Co., Ltd. |
|