ＯＯエンジニアの輪！

■ 始めに

--- 前回インタビュイーの arton さんから makotan さんをご紹介いただきました。arton さんとはどのようなつながりですか？

あの、宴会です。(笑)

20世紀ギリギリくらいの頃ですね。Seasar ( の開発 ) が始まる前後に飲み会があって、そのときに arton さんに初めて会いました。この人が arton さんなんだ、あの Ruby 邪道編を書いた人なんだ、というところから入りつつも、技術の話は一切してなかったですね。

--- じゃあ、Seasar 本関連とか Seasar プロジェクト関連とかとはちょっと違う。プライベート的な面が大きいっていう感じですか?

そうですね。飲み会の席で arton さんを発見したみたいな。まぁ、一方的に名前知ってたんで。

■ パソコン、プログラムとの出会い

--- プログラムとかソフトウェアとか、パソコンとかやり始めたのは?

高校生になったぐらいですね。MSX とか。まだパソコンに色々な種類があった頃なんで、隣の人はFM_TOWNS持ってたりとか、学校には MZ-2200 があったりとか、ベーマガ（マイコン BASIC マガジン）のプログラムをずっと打ち込んでいました。授業中に(笑)

--- 今でいう写経みたいな、そういう世界ですよね。

オープンソースどころか、ソースコードが紙になっている状態なんで、バイナリ打ち込むのがきつかったです。

--- 当時のみなさん、すごい根性ありますよね。今だったら絶対コピペしますよね。

今はインターネットに実行環境としてあるのが普通じゃないですか。(実行環境の)ソースコードだけあっても、どうしようって。

--- 何か、自分でゲーム作ったりとか?

一番最初に作ったのが、カップラーメンの時間をポンってはかるプログラムですね。ずーっと 3 分間ループ回して、3 分たったらループから抜けるっていう。モノ的には簡単ですね。

■ オブジェクト指向との出会い

--- ではオブジェクト指向との関わりについてお聞きします。

えーっと、C++ を初めて使おうとした時です。一応、C++ はオブジェクト指向言語だって言われていたんで。高校卒業したくらいですね。

--- かなり初期ですよね。

そうです。まだテンプレートが入ってない頃なんで。

--- いわゆる入門書もほとんどなかった時代ですよね。

なかったですね。オブジェクト指向っていう本も少なかった頃なんで。ちょうど、就職前かな、デザパタの本が出ました*1。デザパタは結構大きかったですね。個人的には。なるほどこうやってやればいいんだみたいな。

--- デザパタ本で読んで、これすごいなって当時思ったパターンはありますか？

Factory っていうのはよかった。あれは今でも気に入っているんで。

前から使っていたよっていうパターンもありましたけれど、名前が付いているというのはいいですね。ただ、近くに会話できる人なんていなかったんですけどね。だから雑誌とか買ってきて読むくらいですね。

--- 当時は、DDJ とかですか?

DDJ を読んでいました。ちょっと脱線するんですけど、社会人になって Nifty の FPROG *2とかに行き始めると、DDJ の著者たちがいっぱいいるんですよね。すげーって思いました。すごく濃い議論が延々と交わされていた。面白かったですね。

■ 最初の仕事

--- お仕事関連の話をお聞きします。最初の仕事はどういうものでしたか？

最初の一社目の会社、アルバイトで半年前から行っていたんですね。計器管理システムみたいなものです。

--- いきなりヘビーですね

さらにヘビーなのがですね。仕様書がない。(仕様を)わかっている人がいない。ソースコードだけがある。変更依頼が口頭でくる。(周りの人は)バージョン管理ってなんですか？ っていう感じでしたね。

その仕事ですごいのが、二人で担当していたんですけど一人は私でまだ学生の新人アルバイト。システム開発なんで納品するじゃないですか。アルバイトなのに出張でお客様先まで連れて行かれて。「ソフトウェア業界ってこういうとこなんだ」みたいに思いました。そこで納品に行くと元請けの会社から、仕様が違うって言われまして。「仕様はあったんだ！」みたいな。聞いてないし（笑)

納品はどうしましょうっていう話になります。結局その場で作り変えるってことになりました。Access の開発だったのでコンパイルも必要ないし、とりあえず動けばいいし、その場でぶわーって作り変える。3,4 時間でつくり変えてその場でOKをもらった。

--- ある意味、オンサイトカスタマーですね。

逆ですけどね。(そのあと稼働環境に)リリースしに行くじゃないですか。警備がすごかったですよ。当時はノート PC とか持っていく時代じゃなかったので、CD を持って行って。入管で紙貰うんですけど、コレなくしたら絶対出られないんですよ。この紙失くしたら絶対出られなくなるから失くすなよって言われて渡されるんですよ。入退出の数を完全一致させるため。超アナログだけど確かにそうだよな、みたいな。

結局、現地に行ったらまたちょっと違うって言われたんですけどね。「直していい？」って聞いたらいいよって言われたので。じゃあ直しちゃおうかなと。またそれを CD に焼いて・・・。

それを 2 回やりました。それが本当に最初でしたね。辛かったですね。

--- 2 人案件なんで、デスマっていう言い方は変かなと思うんですけど、それに近いような気がします。

近いですね。

■ 開発プロセスが今へと導いた！？

--- 技術的なコアになったことはそのあと就職してからですか？

技術的コアになったのは、どっちかっていうとたぶん Nifty で勉強した方が大きかったですね。

--- 夜は Niftiy の FPROG に出入りしていたんですか？

ほとんど FPROGPRO ですね。現在でも有名な人がいっぱい出入りしていた感じです。たぶん、羽生さんもそこで会っているんですよ。当時は羽生さんは Delphi のところで色々やっていて、オブジェクト指向っていうキーワードでこっちに連れてこられてました。

そこではなんか長文バトルをしていました。うわーっ、ここ大変そうだなって。

--- 今のインターネットなんて全然大したことないレベルのバトルですか？

ブログでトラックバックでやっているのをはるかに密度濃くした感じ。しかも行数が足りないから 2 通目って、どんだけ書くんだよ(笑)。あの仕事じゃないところがすごい面白かったですね。

--- そこでオブジェクト指向に興味を持ったんですか？

そこで開発プロセスって面白いよって言ってもらえたんですよ。実は FPROG の会議室は上の方と下の方で大きく分かれていたんですよ。上の方がオブジェクト指向系なんですよ。6 番、7 番、8 番って。上下の壁のちょい上くらいに 16 番っていうのがあって、そこにいつも行っていました。でも最初は見てないふりをしていたんですよ。でも意外と行ってみたら面白かったですね。で、16 番でまったりして。

--- 16 のメインの話題は?

えっと「ソフトウェア工学(仮称)」ですね。カッコ仮称が大事だったんですよね。ノンジャンルだったんで開発プロセスの話もあれば、設計、あとは個人的な愚痴とかも含めつつ。

--- 楽しそうなところですね。

今あっても楽しいと思いますよ。そこで開発プロセスって面白いですよって話を聞いて。

当時、ISO9000*3とかCMM*4とか、PSP*5とかその辺がちょこちょこ出始めて、ISO9000 取ったっていう会社が現れる頃ですよね。で、ISO9000 の資料見て、こりゃ大変だろう、どう考えてもヘビィウェイトにしかなんないじゃん、と思って。で他の開発プロセスとか見てて、そういうところをいろいろやっているうちに CMM って面白いじゃんって。

--- 意外ですね。

すっごい CMM 好きですよ。CMM って恐ろしく勘違いされているものなんです。

XP と CMM は共存可能だっていう基本路線があるんです。CMM はいわゆるモデルなんですね。ただ CMM には(例が)いろいろ付いているだけなのに、それに対してあれもこれも駄目だって言われている状態なんです。モデルそのものに関する話とはちょっと違う。

コアの発想はすごく面白いんですよ。こういう状況がレベル 1 ですよって言っているだけですよね。ということは CMM のインスタンスが何であろうと関係ないんですよ。

アジャイルでレベル 5 ってありうるんですよ。付属物を全部落としちゃえば、これはすごい考え方じゃないっていう。ただ当時の ISO9000 はどうかと思うけどね。

その辺からですね。プロセスっていう名のつくものに関わり始めたのは。開発プロセスから CMM に興味を持っていう関わり方をしてる中で、いわゆる開発プロセスっていうものは、開発している人たちにとっての業務プロセスに過ぎないっていうところから、業務プロセスってありじゃん、みたいに思えてきました。

--- あまり分けて考えなくていいってことですか?

ソフトウェアの開発プロセスを業務プロセスとして表現したら、その段階で CMM だったら「定義されている」状態になるわけですよ。あるところでは CMM という形で開発プロセスを定義していて、業務プロセスもプロセスのイメージをモデルとして定義している。

本当にそこからですね。どうやってプロセスを表現するかっていうのを覚えたのは。

--- それでは結構 UML とかもやられていましたか？

これがですね。UML 嫌いでして。UML って後からじゃないですか。言っていた話が最初と違うじゃないですか。

--- 例えば、UML 以前の Booch とか OOSE とかもチェックしていましたか？

元々はそっちをチェックしていましたね。UML になって表記法だけになったじゃないですか。手法としてはどうなのみたいな。

--- 分離されちゃいましたね。

そう。事実上、手法がないっていう状態です。「そこはよくないだろう？」「どう落とし込むんだ？」と思います。手法が抜けているんで、UML はあんまり好きじゃないですね。

--- (笑) その頃って、開発の話題の空間が広すぎずプロセスの話もプログラミングの話もみんな共有していていましたね。

そうですね。結構、狭い範囲に全部収まっていたので結構よかったです。

それが今のコアになっています。それがないと、今のわけのわからないプロダクトが作れないんです。

■ Buri

Buri を作った背景「悪魔のテスト」

--- では要素技術関連の質問をします。興味を持ったきっかけはさっきの開発プロセスからですね。

開発プロセスっていう見方があるんだっていうところからです。普通の業務アプリって流れで管理できるじゃんってとこからずっとですね。

--- 一番拠り所にしているものって何ですか? この本がよかったとか。

なんだろう。当時、一番見ていたのはシステムクリエイツ清水さんのページですね*6。

--- DFD を開発プロセス向けに改良したプロセスフローダイアログを書いていた人ですね。

そうです。PFD は開発プロセスのことを言っているんですけど、普通の業務システムを理解する上にもそのまま使える。

ということは、CMM とかでいろいろ覚えたプロセスはそのままゴロンと転がせるんじゃないかと思いました。その頃から業務システムを見るときにも、その(業務の)流れで見ていたんですよ。

そうするとバグるポイントってそこに出てくるんですよ。大体、業務と業務の間のプログラムって別の人が作るんです。すると、そこの中間でバグが出るんですよ。そこで業務の流れを追いかけてバグりそうなポイントをここ、ここってチェックして、一枚のテスト仕様書を書いたんですよ。A4 一枚しかない。そして、これクリアしてね、って言ったんですよ。本当にそこでバグが出るんです。面白いように全部ひっかかっていって、だよねー、みたいな。昔はそういう応用をやっていたんですね。

その A4 用紙が、そのうち「悪魔のテスト」言われるようになるんです。みんながこれ普通の流れじゃん、これでバグるわけないじゃんって言っちゃって、バグが出ちゃったんで、悪魔のテストって言われました。

--- テストエンジニア系の人にも興味深い話ですね?

だから一時期、そっち系の人たちのオフ会とかに行っていたんですよ。

テスト系の本とかも読んでましたが、テスト系の本って意外とハードに密着している感じのやつが多いんですよね。あと、パッケージソフトを作るときに、バグを起こさないためにいろいろなソフトウェア、OS で確認してとか。でも、普通の業務システムってそんなものはパサっと切るじゃないですか。そうなると、残る部分って少ないんですよね。

--- それが業務間のインターフェースですか？

そうそう。あと人のつながり、会社の間の境目とかそこを狙えばいいんだと。会社の境目は結構、大きかったです。あと技術の境目とかなんでもいいから境目を突いていくんですね。「データの連携はこの辺とこの辺」みたいな。ほとんどの場合、単独の人のバグって少ないんですよ。でも、人をまたいだ瞬間にバグが出るようになったり。そういうところをずっとテストしていたんですね。

そうすると、面白いことが 1 つ分かりました。みんなデータの流れと業務の流れを切って考えるんです。画面単位とか、サブシステムとか。でも、つながっている場合があるんですよね。だから、人の間をまたいでいるテストに重点を置こうかと考えた時に、それを楽にすればいいんだと気付きました。

Buri の狙い、if とフラグの排除

--- Buri*7を考えたのはこの時期ですか?

実際バグが起きる箇所の前後で何をやっているかというと、if を書いているんですね。分岐があるとバグが出る、これが事実だったわけです。前段からきたデータをもとに分岐してこっちに処理を流していうところがバグるんですね。前から来たデータが違うよみたいな。ひとつのプログラムの中で複雑なフローになっていたら、訳分からないっていうのがあったので、最初 if をなくそうと思いました。それで( Buri の前に) hamachi っていうのを作ったんです。

--- hamachi はルールエンジン的な感じなんですか?

そうです。どっちかっていうとルールエンジンっぽかったですね。Flow4J *8ってあったんですけど、そっちに近いですね。ただ実際に使ってみると、フロー単独をどうこうしてもダメで、データベースにくっついているいろんなフラグが邪魔なんだって気づいたんですね。if 文って全部、フラグを見てんじゃん。じゃ、フラグなくそうってところから今の Buri が誕生するんですけど。

--- そこら辺と羽生さんのABD(Activity Based DataModel)の考え方が合体したみたいな感じですか?

これがですね、無関係なんですよ！でも、 羽生さんの ERD レッスンに書いてある内容って、数年前から羽生さんが Nifty とかで羽生式ってずーとやっていたんですよ。あの渡辺幸三さんと、羽生さんのあの延々としたクソ長いやりとりがまたあったんですよ。16 番で。

--- 良くも悪くも、渡辺さんは羽生さんと逆な感じしますね。モデリングのアプローチが

アプローチが全く違う。羽生さんは実装できなきゃ駄目だ。渡辺さんは実装を考えちゃ駄目だ。羽生さんは主キーはアイデンティファイア一個じゃないといけない。渡辺さんは複合主キー。もうまったく真逆のことをいう二人なんですね。これでまた長文でやりとりするんでなげーよみたいな。

--- 実装側の観点で言うと。

実装側の観点で言うと羽生さんのほうが分かりやすいし、だって俺でもできそうだし。結構、渡辺さんの方は渡辺さんスペシャルだったりするわけですよ、考え方の一部が。渡辺さんがホワイトボードにこう書け、こうやるんだよっていうんだけどそれじゃ一般的に俺ができるかっていうとそりゃ無理かなっていうのに対して、羽生さんのほうはまぁ分かりやすいと。T 字形 ER 手法*9みたいだよ。

--- でも T 字形 ER 手法そのものでは無いんですね。

羽生式だよね。で、そこから数年して、ERD レッスンて形で本が出たんで、あーなるほどねぇ、でもフラグどうなっとんねんと。

--- なるほど ERD レッスンはまだフラグ排除とは言っていないですね。

言ってない。まったく言ってないです。フラグしか残ってないじゃん。排除しなきゃっていうところへ行ったんですね。

フラグさえ追い出すことができれば DB 設計ってすごく簡単なんですね。だって業務の中身考えなくていいんだから。仕事の流れを考えずに DB 設計すると、すごく簡単に設計できるんですよ。だって見た目通りだし。

--- Buri の場合は実際 SQL でみても(状態管理のテーブルを)みやすい構成になっているみたいですね？

SQL で叩くことを前提に作っています。ワークフローエンジンって、基本、SQLを直接叩けない方が多いんですよ。普通のワークフローエンジンでは API から呼んでくださいみたいなノリですが、Buri は思いっきり SQL でどうぞみたいなノリです。検索は全部 SQL でどうぞ。ビューが準備されているんでそいつと(業務のデータを)ジョインすれば、あとはもうポンッといけます。それ使って S2JDBC と組み合わせたり DBFlute と組み合わせたり普通に出来ます。ビューが get 用の API になっている。

--- 業務系の DB と同じところに乗っかっていることが前提ですよね。(業務データとワークフローのデータの)ジョインができないといけないので。

そうです。前提です。ジョインとかできないと死んじゃいますから。

--- その割り切りのおかげでいろいろ機能があるという感じですね。

うん、テーブルもそんな数ないし。

--- プロダクト系のワークフローエンジンはそういうデータは離せっていう発想で作られているものが多いですよね。SOAP 経由で呼び出させるようにするとか。

多いと思います。今度 Web サービス化すると Web サービスとトランザクションをどうやって対応させればいいんだよとか(困難が生じる)。

( ビュー を API 代わりに使っていると)フローが変わっても条件式は変わらず同じ条件でずっと検索できるんで、そこの検索画面って作り直す必要がないしテストする必要がないんですよ。だからフローにアクティビティが一個二個追加されようが、変わんないんですよ。あと更新画面も変わらないんです。全部 toNextStatus（メソッドを呼ぶ）。

--- 状態が増えても別に。

検索条件は変わらないし、次に進めるっていうのも、「(ある特定の)状態に行け」じゃなくて、「次の状態に行け」なんですね。すべての命令が。条件が変更されようが、何をしようが「 toNextStatus 」しかない。

--- それって画面設計とかにも影響するんですか？ たとえば、ある画面に対する次のアクション(「承認」「却下」とか)が増えると、画面のボタンが増えたりはしませんか。

ボタンとかは増えると思います。でもそこだけですよね。ボタンが増えても、ボタンのところで action ってのが引数にポコっと入れればいいんです。

--- で、サーバ側で判断して分岐するわけですね。

結構、プログラムの面倒くさいところを、何気にうまくまとめている感じで。

--- 今の話だけでも、普通にベタに作っていたらで Action が増えて、DB のフラグをどうしてー。みたいな話になっちゃいますね。

そうしたら全部テストし直しですよね。

条件分岐を徹底的になくそうとするとフラグが邪魔だったんでフラグを全部別の形に置き換えた。そうするといろんな意味で簡単になるんです。普通はフラグが増えると条件式が変わるから、フラグを使った集計とかも条件式を変えないといけないんですけど、そこも全部そのままでいいよと。その辺が最大のメリットですね。

■ ギョイゾー！の開発

--- それでは今のメインの仕事は？

今の仕事*10は、ですね。ギョイゾー*11の中の人です。ギョイゾーの中身のツールとかライブラリとかを主にやっています。それに伴ってそれを使っているメンバーのサポートとかも基本的に全部やっています。

--- 羽生さんがいってたファクトリ*12と呼ばれるところですか？

ほとんどをやっています。ファクトリの全体の構造を決めるところから、作るところから、あと人に任せるところとか。

--- オフレコになってしまうかもしれないんですけど、ファクトリって何人くらいで作業しているのですか?

本当に少ないですね。画面の色々をやっている松田さんがいたり、もう、本当に数人ですね。(それ以外の)ほとんどの人は、普通に案件やっています。

--- 基本的にファクトリに合わないような案件は受けてない？

いや、逆です。ファクトリに合わないような案件はない。あれは超汎用型なんですよ。一般的な業務システムだったら 100% 作れるんですよ。ほとんどを自動生成で持って行けるんで、あとは手作業でどこ、どこまでやるのっていう話しか残らないんですよ。

そもそものベースラインのコードははっきりと書けるんで、あとはここを埋めてねっていう世界でしかないんですよ。だからびっくりするくらい業務システムを簡単に作れるんですよ。完璧な業務システムだったらファクトリに流すだけで 8 割くらいコードとしては完成。あとの残りも手と書くのと同じくらいのスピードで普通に書けるんです。

--- おお。残りの部分っていうのは業務的なカスタマイズってことですか。本当に独創的な何かが欲しいっていうのがない限り。

それはもう画面を作りこまなきゃ無理だよね、とか(の場合ですね)。

サーバ側はそんなに変わらないってことですね。今、実際にスタロジ*13で基幹系システムを納品しているところなんですけど、かなりの部分をファクトリでやっていますね。手作業はバグがあるから嫌なので、ファクトリでできる部分は全部ファクトリでやっちゃえって。

--- ギョイゾーのバージョンアップを過去の作ったものに対して適用することはできるんですか？

できます。データは全部 DB にあるじゃないですか。そうするとスキーマの差分だけなんですよ。マイグレーションの話でしかない。アプリ自体のバージョンは、ジェネレートし直して差分を当てれば終わりですよね。

--- ギョイゾーの話は衝撃的でしたね。正直、何百倍っていう生産性の差が出るんじゃないですか?

普通の SIer も生産性上げれるはずなんですよね。

単独で見ればわけかわらないレベルですよ。1 回ブリ祭りってスタロジでやったことがあるんです。

そのブリ祭りで、その場でギョイゾーのブリスタってやつでバーッと作って。今、作ったやつをその場で 10 分かそこらで動くようにして、実際動かしたんですよ。もちろん、ワークフロー部分を含めてです。今のやつを、何日でできますかって質問したんですよ。一番早い人が 3 日。2 週間とか 1 か月っていう人もいるんですよ。

--- そうですね。大きな企業になればなるほど 1 画面にかかる工数は増えていきますね。

ま、ほとんどの人が 1 週間〜 2 週間なんですね。それを 30 分くらいでやっちゃうんで。ま、それくらいの差だよね。

■ 技術的興味

--- ちなみに、プロセス関連以外の技術的な興味でこれはビビッときたものはありますか？

それがですね、この間 Delphi もどきを見つけて、オープンソースなんですよ。マルチプラットフォームなんですよ。Lazarus*14っやつで。

--- へー、それって既存の言語例えばアクションスクリプトにコンパイルするみたいな感じですか？

違います。画面から何から何まで本当にオブジェクト Pascal なんですよ。完コピ、ここまで完コピでマルチプラットフォームかよ、みたいな。

--- VM とかは全部自前のものですか

VM はないんで全部ネイティブ。Delphi 言語を使っていてほぼオブジェクト Pascal なんで、オブジェクト Pascal のフリーのコンパイラがあるんですよ。それを使って、あの Delphi の画面を作っちゃいましたみたいな。コンポーネントもすごいあって、え、これ Professional 版みたいだなと。

--- DB グリッド的なものもありそうですね。

普通にデータベース用のコンポーネントが付いているんですよ。でもネイティブでちゃんと動く、しかもマルチプラットフォーム可能って。これはすごいなあって思いながら、昨日ちょっといじってました。

好きなプログラミング言語 - SQL, C++... Javaは？

--- ちなみに好きなプログラミング言語ってなんですか？

SQL なんですよ。

--- おー。そういえば、そういえば今のプロダクトは DB に依存していない形で作っているんですか？

今は PostgreSQL ですね。もっともどこでも動くし、軽いし、ちゃんと安定しているし。どこでもノートパソコン入れてちょこちょこっていうのもできるし。そう、Oracle だとライセンスがうんぬんって言われるし、SQLServer って Windows いるじゃん。あと他に使いたい DB ってないですよね。

--- じゃあ今の製品は PostgreSQL 依存ですか?

SQL が少し依存している感じなだけです。もう 「SQL の移植が必要だったらする、 Oracle (への移植は) は大丈夫だよ」みたいな程度です。多少、PostgreSQL 特有の機能は使っているけど、それも別の形で置き換えられるレベル。

本当は Oracle が好きなんですよね。データベースの動きとしては。パフォーマンスの出方がちゃんとしているんで。やっぱり現場でガンガン叩かれているから、distinct は遅くなるけど GROUP BY は OK みたいなことはないじゃないですか。素直にできていてバッドノウハウが少ないよね。まあ PostgreSQL も結構いいと思うんですけど。

業務システムっていう枠では、もし何かパフォーマンス出ないっていったら、SQL に頼らなきゃいけないじゃないですか、この更新処理遅いんだけどどうにかなんない？っていったときに、じゃあ SQL 書いちゃえばって。それがある程度保障される必要がある。

そこをただブン回せばいいよっていうノリはちょっと困るんで、その点で大丈夫なデータベースが好きですね。

--- MySQL はあんまり使わないんですね。

使わないですね。なぜか気に入らない。まあ、一回入れたときに環境がおかしくなったからだと(笑)

--- ちなみに SQL 以外の普通のプログラミング言語だと何ですか？

ほんとは C++ が大好きです。あのー、訳の分からないポインタとか。バッドノウハウの固まりのあのポインタの扱いとかって、あんな慎重にやらなければいけないプログラミング言語を今使ったら大変ですよ。結構、気にしなければいけないところがあっちこっちにあって、ちょっとコード書くにもポインタ大丈夫かなぁみたいな。あのドキドキ感は、いやーな感じが。

--- (笑)でもそれが好きなんですね。

言語としては、あの遠慮のない取り込み方が大好きです。

--- マルチパラダイム言語ですからね。Java はまぁ、三番手ぐらいですか。

Java は、そんなもんですね。全面的に嫌いってわけでもなく。まぁ、唯一この 3 つの中ではリフレクションがあるからいいかな。C++ にリフレクションついた D 言語とか面白そうなんですけどね。

--- そんなに Java は好きじゃないんですね。

Java は本当に、仕事の言語って感じですね。結局仕事じゃないかと思いますよ。本当に Java が好きな人って、そんなにいないんじゃないかな。Java はなんか真面目な言語なんだなぁー。

好きなソフトウェアパターン

--- 好きなソフトウェアパターンはなんですか?

AbstractFactory パターンで。

依存関係を解消できるじゃないですか、Factory があると。もともとデザパタを読んでいても依存関係をどうするかっていうところに悩みました。結局(相手のオブジェクトの) new を書くじゃんみたいな。意味ないんじゃんみたいな。で、(デザパタを)読んでいくと、Factory ってあるんだ、みたいな。

--- そうですね。他のデザインパターンを機能させるには Factory パターンがないと意味がない。

そうそう、意味がない。最終的には Factory がないとだめ

--- Strategy とか Observer とか、依存対象を new してたらもう全然だめですね

「どこで渡すんだそれ」みたいな。ずっと謎だったのが、AbstractFactory があることで分かった。

それが DI コンテナにつながるんですけどね。依存性を切るってことで IOC パターン*15(を知って)、あーなるほどね、と。

--- ちなみに、現在のギョイゾー関連のプロダクトの DI コンテナ自体は Seasar2 なんですか？

そうです。

--- 別に独自コンテナ化している訳ではないんですか？

独自コンテナ化は(案を)考えているくらいで、別に(現状に不満はありません)。なんだったら中間レイヤを一個置いちゃえば終わりです。

--- コンテナ単体だとどこもそんなに差は無いということですね。

あまり差はありません。トランザクション関係とコンテナの登録方法くらいで後は全然変わらないですね。

--- 例えばホットデプロイ機能とかは？

まったく使ってないです。結局、手でプログラム書くことが少ないんで、全部最初に dicon ファイルも生成しちゃうんです。むしろホットデプロイ禁止にしているくらいです。

--- ちなみにコード生成をするときに GeneraionGap とかは使うのですか?

仕方がないパターンという感じですよね。ジェネレートするから、GenerationGap パターンが必要なんだよね。

--- ジェネレーターは多用するけど、GenerationGap はあまり好きではないということろが面白いですね。

ほんとは 100% (自動生成できるの)が基本なんですけど、100% はコストがかかりすぎじゃないですか。ジェネレータは綺麗なコードをはいて、直接手入れてもらいましょうと。

--- そっちの方が現実的なんですね。

世の中には100% ソースコードが生成可能ですっていうやつがあるんですよね。でも、それ相当定義しないと無理だろ！そこまで定義するんだったら普通の開発言語に書けるんじゃない、と。

--- 結構難しいですね。生成する部分と記述する部分のバランスはセンスがいりそうですね。

今の状態に落ち着くまでがやっぱり大変でした。

--- ちょっと過剰に自動生成する場合もあるんですか？

過剰にやるとみんなが使わなくなっちゃう。開発者に無視されるんです。過剰な自動生成機能を開発者が無視できるような仕組みがあるんです。「じゃあそこ手で書くよ」みたいな。

--- 面白いですね。新しい自動生成にまつわるパターンなような気がします。

新人の頃から自動生成してるんで。ここ面倒くさい、Excel で書いちゃおうみたいな(風にやっていました)。だから Excel 好きなんですよ。

2000 年問題に対応するためホストからクラサバにデータ連携するって案件で、あるデータから別のデータへ変換してくれって仕様が来ました。もうそれ自動生成しろって言っているようなもんじゃんって(笑)。ホントに自動生成しちゃったんですよ。そのおかげで、自社の人たちと何人かは、毎日定時に帰っていました。ほとんどのコードが自動でできるんで後はテストするだけなんですね。

--- もう Excel すごい。自動生成のために生まれてきたようなものですね。

何みんなこれを表計算かワープロ代わりにしちゃうんだよな。もったいないよ。

--- VBS 書くのがどうしても苦手になってしまって最近やっていないです。

結構、式だけでやってます。式をびーっとコピペして、式を書くじゃないですか、結果のところだけコピペしてテキストエディタにコピペして終わりみたいな。ほんと式だけですよ。

それで好きなツールは Excel なんですね。

■ makotan の日記

--- それでは本業以外のことを聞きます。まこたん(makotan)の日記は、どこからニュースネタをとってくるんですか？

RSS ですね。GoogleReader で Ctrl キーを小指で押さえてカチンとやるとページを裏で開くんで、それで「J」「K」押しながら、ページを見てぺたぺたぺたとブックマークしていく。

--- オンラインブックマークは使っているんですか？

使ってますよ。はてブ*16も使ってますよ。はてブはですね、GoogleReader と用途を分けていて、本当にブックマークなんですよ。

本来の使い方をしているだけなんだけど、なんか(普通の使い方と)違うらしい。

--- じゃ、あんまり増えないんですね。

月に何個かぐらいしか増えない。正しい使い方をしているはずなんだけど、どうも増えない。ライブラリとかツールだとかのリストとかになっちゃんですよ。どうしても。

--- オレンジニュース*17を仮想ライバルにしてるという話を聞きましたけど。

オレンジニュースはやっぱりすごいですね。あのタイトルの付け方。釣り系のタイトルのつけかた。本体のタイトルと違う時あるんですよね。うまいな〜とか思って。

■ 趣味とか

--- ちなみに趣味は何ですか？

DVD 見ているか、本読んでるか、寝ているか。映画とかはバンバン見ています。コーディングしながらだったら映画観れるんですよ。

--- ほんとうですか！

テレビとかニュース番組だったらコーディングしながら見れるんですよ。コーディングだけですよ。設計とかだめです。作るものが決まっていれば何にも考えていないからテレビを見られるんですよ。で、見るだけだったら 2 倍で見れるんですよ(笑)。ハードディスクレコーダーって倍速再生が 1.3 倍までなんですが、標準で流しているのと同じように見えるんです。2 倍ぐらいになると多少普通に見れるんです。オカシイっていつも言われるんだけど、すごい得ですよ。日記のニュースネタを集めている時は、横でテレビ流してめざましテレビを見ながらやっている。

あの、ケロロ軍曹をずっと 2 倍で見てたんですよね。羽生さんがケロロ軍曹、ケロロ軍曹っていうから、(一時期)録画して渡していたんですよ。一応録画しているから見るじゃないですか。見るときは必ず 2 倍で見るんですよ。ケロロ軍曹のオープニングとエンディングは 2 倍で覚えているんですよ。

--- (笑)

ある時、普通のテレビ番組でケロロ軍曹のエンディングを歌っている二人が出て来た時に「あれ！ 遅いよこれ！」って。頭の中で流れてくるケロロ軍曹の歌の半分のスピードでこの 2 人が歌っているという。このすごい違和感がたまんなく嫌でした。

--- ちょっと、いや、かなり意外ですね、そんなにテレビを見る人だったなんて。

すごいテレビ見てますよ。めざましテレビが大好きです。

■ 若いソフトウェアエンジニアに一言

--- ちょうど新人が配属される頃ですが、若いエンジニアに一言

じゃあ「疑問を持ち続ける」って言う事かな。

結局、会社のやり方って誰かが決めたものなんですよね。ドキュメントにしても開発プロセスにしても。その中で何かおかしいことが起きるのって、ある意味当たり前なんですよね。現実と合わないとか。それが一番分かるのが新人なんですよ。外から入ってきたり、新たに入ってきた人なんです。一番新人が強い。逆にそこで会社のやり方に慣れちゃって疑問を持たなくなると、おかしいことがおかしいって分からなくなる。それはやめた方がいいよと。

--- 疑問を持たないまま慣れてしまうと。

もう、そのままずるずるっと。泥の中にうじゃーっと。みんなと一緒に泥の中へ。

--- そうですね。ある意味新人のうちの特権ですね。

まだいろいろ聞けるじゃないですか。5 年も経ってしまうと「5 年経ってその話はおかしいだろ」っていうことになるじゃないですか。

--- 疑問を持ち続けていると新しいものが作れそうですね。

テレビ倍速よりいいことを言いました(笑)。ほんとは字幕だったら 3.5 倍まで行けるんですよ。集中しないとだめなんで、普段使えないんですが。

--- スーパーサイヤ人というか

そういうモードに入って見ないとだめなんで、(3.5 倍は)ちょっと使えないんですけど。

--- 本日はありがとうございました!!

---