読者です 読者をやめる 読者になる 読者になる

亀岡的プログラマ日記

京都のベッドタウン、亀岡よりだらだらとお送りいたします。

デブサミ関西2012(#kansumi )に行って来ました。

行って来ました!

たのしかったー!!全セッション外れなしだったなー。

全体見た感想

関西面白くなってきた!楽天、Yahoo!、GREE、CyberAgentといった企業が続々関西に開発拠点を持ってきてる様子がいろんな人の話からきいて分かってきて、そこに関西地場の組み込み系が混じると、とても素敵なことになるんじゃないかなぁ、とか妄想したり。(いや、何が起こるかはよくわかっていないんだけれど。)

そんなかで何か個人としても、コミュニティ(#京アジャ)としても価値を届けられるようになって行きたいですねー。ホントに。

んではざっくり各セッションの感想と書いたマインドマップを。

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

f:id:posaunehm:20120915112036j:plain
Google及川さんのお話。クラウドの開発手法のメリット(リリース、デプロイのしやすさ、リリース後の修正コストの低さ)などをクライアントアプリ開発に以下に取り込むのか、という話だと聞いていきなり興味津々。

まず、従来型の(所謂WFっぽい)開発でも「計画→開発→安定化→リリース」というサイクルを回しているのには変わらないよね?という話はかなり納得。このサイクルを縮めていくのがアジャイル的なものの見方でしょう、ということ。

それから大規模な開発プロジェクトでは、全員が「何を作るのか?」というテーマを合わせることが重要という話もあった。この話は別のセッションでも何度か聞いた気がしていて、アジャイルサムライの「インセプションデッキ」の考え方がアジャイルのプラクティスとしてもっと広まっていけば、こういうところにこそアジャイルは重きをおくことが伝わるとおもうのだけれど。頑張ろう。

そしてクラウド開発のメリットをクライアント開発で享受するには、というはなしだけれど、まずChromeの自動アップデートのような機構が重要になるんだな、と認識。ただこれはすべてのソフトウェアが取れる対策ではないし難しい所。ただ、これくらいの頻度で安定したプロダクトを届けることは恐らく超重要で、それはやっぱ継続的デリバリ(CD)ですよね。というかテストかけテストを、という話になっていて、例えばパッチを当てるときはパッチとそれに対するテストも当然セット。それをBuild Botが継続的にビルドし続けるわけですね。教科書的なCD!

で、テストの種類もいろいろあって、面白いなとおもったのがレイアウトテスト。これは現状のUIのレイアウトをテストするだけのもので、インタフェースを作ったり変更したりした時点で作成する。これが崩れるということは、誰かが知ってか知らずかマズイことをしたってことなので、かなり良いリグレッションテストになるわけですね。特にUIをが崩れたり変わっちゃったりするのはエンドユーザーさんが一番バグっぽく思うところだし、結構方法論としても単純なので機会があれば入れてみたい。

このあたりの細かいテストのルール付けは、Chromeでは多くのOSSを使っているから、ということなんですが、これをオフショア使うソフトウェア開発に当てはめると、OSSと状況は似たようなもの(遠隔地で同じコードベースを触って結合する)だよね?という及川さんの指摘には目からうろこがボロボロと。そか、オープンソースの考え方って、少なくとも仕事では遠いものとして考えがちだったけれど、そういう見方をすればかなり近い存在に見えてきましたね。
(無論技術者のレベルのまちまちさとか、色々違う点もあるのでそのまま使えはしないですけれど。)

関西から世界に通用するスマートフォンサービスの開発

f:id:posaunehm:20120915112039j:plain

CyberAgentの@ku_suke さんのお話。CyberAgentの中の雰囲気がよくわかった!・・・てなんか会社見学の就活生みたいな感想だな・・・。

素敵だと思ったことは

  • 上司と一緒にAgileの勉強会(できてねぇなぁ僕・・・)
  • 社員のアイディアを吸い出すいろんな取り組み
    • 某掲示板だとなんかブラック臭すると買って叩かれそうだけれど
  • UXの検討・改善の妥協の無さ。デイリーリリースでどんどん初期は改善していくという姿勢。スマホアプリとしては当然のことなんだろうけれど。
  • 勉強する意味 = スキルセットのup2dateという言葉。カッコイイ!!

終わりに@moririringさんと一緒に話させていただいて、いろいろ関西の勉強会事情を情報交換。楽しくなって来ましたよ、やっぱり。

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

f:id:posaunehm:20120915112056j:plain
これがなんとなくで受けたセションなかでは大当たり。JIRAの話かと思えばそんなことはなくて、プロジェクト管理というものの捉え方を勉強させてもらいました。

とにかく心に残ったのは「我々は何をマネジメントしたいのか」ということを徹底的に考えろ、というメッセージ。プロセスを銀の弾丸にせず、常に考えに考え抜かなければいけないという言葉はまさにその通りだと思うし、ちゃんと刻みつけておこないとなー。

それから「作業の管理」と「コミュニケーションの管理」をごっちゃにしてはいけない、というのは僕の中で消化しきれていないテーマなのでちょっと考えておきます。

というのも、話の流れは「期間・作業者が決まりきっているプロジェクトは作業の管理だから、コミュニケーション管理のツールであるITSを使っても機能しにくい」という話があったかとおもうのですが、うまくITSを使えば、「コミュニケーションの管理」と「作業の管理」を矛盾無く同時にやってくれそうな気がするから。

ただこれはなんとなくで、例えばいまの職場で形だけRedmineを入れてもそんなにうまくいっていないように思うのは、まだまだ運用の努力がたりないのかと思っているんですが、もしかすると本質的にやりたいことと合っていないのかもれないなーと。そういう事も思えてしまうわけです。

とにかく色々考える切っ掛けになった素晴らしいセッションでしたJIRAも使ってみたい!

テスト駆動開発の進化

f:id:posaunehm:20120915112101j:plain
今回の主目的といってもいいのがこのセッションでした。GOOS本こと「Growing Object Oriented Software Guided by Test」の翻訳者、和智さんのセッションです。会場で本は勿論購入!

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

内容はGOOS本のダイジェストといった感じ。TDDのサイクルをさらに外側から見るサイクルの話(RSpecに対するCucumberみたいなもの)や、モックの使い方、機能を薄い縦割りでいかに作るのか、というあたりは、最近RSpec本やThe Art of Unit Testingを読んでみた身としては完全に僕得。今読んでますが、こんなに技術書でワクワクして読むのは久しぶりかもw

The Art of Unit Testing: With Examples in .net

The Art of Unit Testing: With Examples in .net


The RSpec Book (Professional Ruby Series)

The RSpec Book (Professional Ruby Series)

あとエンタープライズアプリケーション系の知識が相変わらず少なすぎて泣きそうになるので、無理でもちょっとずつPoEAAとかを読んでかないといけないなぁ、と思ったり・・・

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)


第5部はだいたい身内ネタだし、まあ省略!
うーん、全然サクッとしてませんね。そんなこんなでとても楽しかった!スタッフの皆様、お疲れ様でした!