読者です 読者をやめる 読者になる 読者になる
おもに Groovy やアジャイル開発について勉強していることを書き散らしてます。
わたしのひとりごとが、だれかのお役に立てればと…

デブサミ関西2012に行ってきた

行ってきた

デブサミ関西(http://codezine.jp/devsumi/2012/kansai/)に行ってきました。

いま自分が興味をもっている領域についてのセッションが多かったので、迷わず参加を決めました。期待通りでした。スピーカーのみなさん、スタッフのみなさん、ありがとうざいました。

無線LANがあってよかったです。

とりあえず、アウトプットしてみました。
所々箇条書きみたいになっていますが、眠さに負けたということで。
まずはリリースするのが重要、その後イテレーションするかは…(^_^;)

【S-1】Chromeのプロジェクトに学ぶAgileでScaleするソフトウェア開発手法

プロジェクトメンバーをプロジェクトの市民とみなす。

この考え方はとてもとても共感できました。これ、今日の一番の収穫かと。
自己組織化と同じ考えだと思いますが、「市民」という言葉は理解しやすいと思います。

プロジェクトのために貢献するよき市民。
プロジェクトを健全に発展させる市民。

大規模開発、いかにしてマネジメントするか。
重要なのは、テーマを決めること。
ブレないようにする。状況に左右されないようにする。
チームを分割したときには、テーマ・コンセプト・方向性を共有すること。
単純にして、だれでも覚えるようにする。

Chromeのテーマ、Simple/Speed/Security/Stability(堅牢性)。
Sではじまって、忘れない。この4つはブレない。
Principle を理解してから参加する。徹底させる。

もはやチェックインやブランチの管理を人が行うことには限界がある。
徹底した自動化が必要。自動化しても、きちんと可視化する。
Stability を維持するためには徹底した自動化。

クラウドの特徴
Agility サイクルの迅速さ。Launch&Iterate。ローンチ
 完成度=ユーザの要望に合致する。フィードバックを取り入れる。仮説と実証を繰り返す。
Evolution 製品の進化。
 製品のアップデートはユーザには意識していない。非常に小さい階段の段差の繰り返し。

【A-1】Continuous Value Delivery to the NEXT DECADE

TFSUG で長沢さんの講演を聞いたことがあったのと「継続的◯◯」は大好きなテーマなので、迷わずこのセッションを選択しました。

開発しているとき、どこまで意識しているか?
(チーム、関係者、エンドユーザ、エンドユーザのビジネス)
価値の流れ、フィードバックの流れを意識する必要がある。
開発の流れだけではなく、価値の流れを意識しなければならない。

ビジネスにおけるITテクノロジーの変遷
便利→有効→不可欠

要求は変化するものだという前提のもと、継続的に提供する。
アジャイル(継続的デリバリー)は最初から最後までクライマックス。だから、方法論やツールが不可欠。
短いスパンで提供し続けるのはタフな作業。根性論では太刀打ちできない。

ツールやプラクティスの適用は Point Solution から Flow Solution へ。
ポイントごとに個別にツールを適用するのではなく、開発全体の流れを統合できるようにする。

あと、講演資料を直前にUPされていたのがとてもよかったです。
聞き手の理解に合わせて、資料を参照できたので助かりました。
なにも隠す必要はないですし、直前ならネタバレ感も少ないので、直前配布というのはありかなと思いました。

【A-2】エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方

セッション全体と通して、「そうだそうだ」と共感、納得する内容が多かったです。

アジャイルは、イテレーションでタイムボックス(リソースと時間を優先する)
ウォーターフォールは、スコープ最優先

アジャイルは、わからないことはわからないこととして置いておける。

作業の管理とコミュニケーションの管理を区別する。
作業の定義(なにをするか)は作業管理
作業の明確化はコミュニケーション管理

マネジメントする対象やフェーズに応じて、プロセスを選択する。
最適なプロセスを求めて、頭を使わなければならない。
ソフトウェア開発は未熟な領域で、結局は人間次第。

コラボレーション管理(コミュニケーション管理のプラクティス)
利害関係者が増加&分散して、窓口型コミュニケーションが機能しない
多対多のコラボレーション。イシューを中心に人が関わる、タイミングは非同期。

透明なマネジメント
信頼こそ最大のコスト削減、不透明はウソ
窓口型の併用、定期的な棚卸は必要

作るものが明確なのであれば、Excel WBS を使った方がいい。
作業管理とコミュニケーション管理を混同しない。チケット駆動で作業管理すると混乱する。
WBSで拾えないタスクをチケット駆動で拾う。

登壇して Excel をネタにする人はちゃんと使い分けてたり、高レベルで使い込んでたりするので
それはそれでなんだか参考になります。

【A-3】テスト駆動開発の進化

スピーカーの和智さんが翻訳された『ドメイン駆動設計』も『継続的デリバリー』も持ってたりします。鈍器系書籍…

TDDのバイブルとも言える『テスト駆動開発入門』(2002年原書出版)から
今回の『実践テスト駆動開発』(2007年原書出版)までの5年間の進化を解説するというのがテーマでした。

なるほど、モックとかの話は書籍ではなかなか見かけないですもんね。
テスト駆動開発入門』がユニットテストの話なら、『実践テスト駆動開発』は受け入れテストの話っぽいです。

でも、2007年原書出版から日本語翻訳まで5年経ってるぞ!?
大丈夫か、日本!?…とか思いました。

TDDループ(Red/Green/Refactor)の外側に受け入れテストのループをまわすという「二重ループ」の話は興味深かったです。今後、詳細を研究していきたいと思います。

あと、エンティティ主体のドメイン、ロール主体のドメインの比較はわかりやすかったです。
うちの会社はSQL大好きだからエンティティ主体から抜け出せない。やっぱりと再認識。

セッション終了後、会場で『実践テスト駆動開発』を買ってしまいました。(早晩買うつもりでしたけれど)
10%OFFと和智さんサインもらえるという押しには勝てませんでした。和智さん、サインありがとうざいました。

『実践テスト駆動開発』はじっくり読みたいと思います。

【A-4】Struts の時代から、標準 Java EE で実現する効率的な Web サイト構築の時代へ*

セッション内容をあまり見ずに、「Struts」という文言だけで選んでました…
ということで、JSF の話が始まって「おぉ、JSF か…」と。

結論から言いますと、JSF に対する見方が大分変わりました。いい方に転がりました。
5年ほど前、JSF 1.0 のときに開発で使用してしんどい思いをしたのでトラウマで避けていました。
直近でも JSF を使うという話が出たりしても…拒否反応が。

スピーカー寺田さんのセッションを通して、かなり JSF 2.0 が有効で使いやすいということを感じました。

ただ、JSF 2.0 についての日本語書籍がまだないという状態は障壁になりそうですね。

【A-5】あの人の自分戦略を聞きたい!-デブサミ関西編*

登壇されていた4名の方は、関西の勉強会などでお話聞いたり、Twitter フォローしてたりと…"一方的に"存じ上げていた方々でした。
そういう事前知識があるなかで、今回みなさんの「ねっこ」の部分を知ることができました。
(ねっこ、中村さんは「源泉」とおっしゃってました)

自分戦略というテーマでしたが、関西でも有数の技術者の方の背景や心情をうかがい知ることができたのが個人的には大きな収穫でした。

自分自身の「ねっこ」を人前で話すことができるか、その価値があるかという問いに答えられるようにしないとダメですね。

実践するまでが◯◯

せっかく得た知識もやる気も実践しないと、しぼんでしまいます。

(がんばって絵を書いてみました)

実践ということで、直近でやることリスト。

・なにかしらアウトプットする(ブログ書いたぞ!)
・『実践テスト駆動開発』を読む
・今の開発案件で、CI環境をちゃんと構築する(受け入れテストの自動化はやりたい)

まとめ

大きなカンファレンスとは違って、こういう開発者中心のイベントは自分たちのレベルを引き上げてくれたり、問題解決のお手本になったりするので非常に有益と思います。

大きなカンファレンスは世の中のトレンドをキャッチできるので、それはそれでありがたいです。
でも、自分とのつながりという面では接点が少ないですよね。

こういったイベントがあるということを知るためにはある程度アンテナを張ってないと
実は気づかなかったりするわけで。(私もアンテナがちゃんと動きだして、1年たったか立たないか)

そういう意味で言うと…
うちのチームから後輩2人を連れてこれたことが、今回の私にとっていちばんの成果かな。
ちゃんとは聞いてはないですが、満足してもらえたはず。