QCon Tokyo に行ってきた。

インプットが多すぎて消化するのに時間がかかってしまいましたが、印象に残ったことを記録します。内容を知りたい人は、リンク先などを参照してください。（そもそもいちびって同時通訳使わずに英語で聞いていたので、誤解もいっぱいしている気がしますが。。）

大きなテーマはやはりDDD。印象的だったのは以下の点。

モデルは複数存在し、利用目的により異なる

モデルは最初に完璧なものなどできない。継続して改善していく。

モデル、コードだけでなく、シナリオも継続して改善していく。そして、シナリオも開発していくもの

また、「なぜDDDを適用するのか」という問いに「それがビジネスを本当のゴールに一番速くたどり着く方法だから！」と言い切ってました。ただ、設計やリファクタリング、きれいなコードって、追加開発や不具合修正の段階になって、はじめて効いてきますね。SIでシステム売り切り、という商売をしている場合、SIer（の上の方の方々）には「きれいな設計」っていいことないから関心もてないのかなあ、と悶々としてました。
　ただシステムを利用する企業や、うちみたいなサービスを提供していて、そのサービスの付加価値をどう高めていくかが重要な商売の場合、やっぱりきれいな設計は死活問題。実はお客さん企業こそ、DDDというような手法で取り組んでくれるSIerを選んだ方がいいんじゃないのー、と思ってました（人ごと）
　私はもう少し自社のビジネス領域について勉強しないとなあ。。あと、最初から完璧なモデルをつくろう、とするところや、最初のモデルに固執してしまうところはやめよう、と思っています。といいつつも、いくら分離して設計しても、モデルの変更はインフラの変更を伴う可能性が高いし、なかなか継続して改善したり、作り替えたりできないよなあ、現実問題どうするんだろう？？と思いながら聞いていたんですけどね。

　また、レガシーシステムに追加開発する場合のデザインパターンの話も。「一からつくりなおすのじゃ時間がかかりすぎる。だけどいくらリファクタリングしていっても全く新しい思想はシステムに追加できない。」という話。いかにも陥りそうなバッドパターンですよね。いや、作り直したくなるし、「生まれ変わらないとできません」っていいたいエンジニアの気持ちをぐさりとつかれました。「レガシーのいいところをみつけて活かそうよ！」って、そうしよ。

もう一つ、よかったのがマイクロソフト萩原さんのセッション。HadoopのMap/Reduceのような設計の勘所を説明してました。

現代のデータ設計は、分散処理できるデータ構造とその処理方法の設計も含まれる

のようなことをおっしゃてて、また勉強すること増えたぜ！と思ったものの、自分で試行錯誤せずとも先駆者の成果にいろいろあっててに入りそうな感触を得たので、これからどっぷりアルゴリズムなどを学んでいこうと思っています。「並列数を増やすのは最後、その前に処理の方式を変更することによりもっと速くできる」みたいです。

他にも、Twitterの若いおにいさんが、Ruby　ガベージコレクタを自作した話とかしてましたが、かっこよかったがついていけなかった。。精進し直します。。

そして、ここ４、５年、17:00くらいまでしか仕事してないので、18:00すぎると頭わいてきて、最後のパネルディスカッション全然きけてなかった。そんな湧いた頭にも飛び込んでくる、エリックさんの言葉。

そう、プログラマは圧倒的にビジネスの話をしたりないんだと思うんですよね。でも実装するのに必要だから、細かいことききたい、よなあああああ

日帰り東京久しぶりだったけど、子連れじゃないとこんなに新幹線って快適空間なのかあ、と思いましたよ。家族に感謝。今年の東京遠征はこれで終わりにします。