XP祭り関西2012に行ってきました
XP祭り関西2012〜技術指向で行こう！〜に行ってきました。
XP祭り関西2012 - XPJUG関西wiki
参加したセッションは次の通りです。
- 【基調講演】「アジャイル開発の計画と管理」~アジャイルのプロジェクトマネジメント~
- 【1-2】TDD サイクルを加速する技術たち
- 【2-2（前半）】大規模なゲーム開発をスクラムで
- 【2-2（後半）】継続的インテグレーション環境を作れ!(Jenkins編)
まずは基調講演の前に司会の[twitter:@kami_teru]さんのノリにのせられて、
「いくぞ!!」
「XP!!」
「技術指向で!!」
「がんばろう!!」
と、みんなでかけ声に合わせてポーズを決める。
少し照れくさかったけど、関西ならではのノリと自分を納得させてやりきりましたw
【基調講演】「アジャイル開発の計画と管理」~アジャイルのプロジェクトマネジメント~
「ERP パッケージを開発するのが趣味な社長」である、株式会社システムインテグレータ 代表取締役社長 梅田 弘之さん[twitter:@umedano]による基調講演。
ソフトウェア開発者の目的
サッカーの目的は試合に勝つことだけれど、我々の目的は何なのか。
ソフトウェア開発では「良いものを作ること」が目的です。そのための手段や方法がアジャイルやプロジェクト管理です。
大事なことは、アジャイルの開発手法を導入することを目的にしてはいけないということです。
つまり、型どおりにアジャイルを導入するのではなくて、良いものを作るためにどうすればいいかを常に考える必要があります。
アジャイルとウォーターフォール
ウォーターフォールを敵視してはいけません。
例えば、大規模システムにおける要件定義やシステム試験ではウォーターフォール型のプロセスが有効であったりします。
ウォーターフォールでもアジャイルでも効果的なアプローチを取り入れることが重要です。
品質/コスト/納期/スコープ
アジャイルではスコープをコントロールするが、請負契約によるプロダクト開発ではスコープを犠牲にはできない。
その結果、請負契約によるプロダクト開発ではコストが犠牲になっています。
この点についてはまさにその通りと同意する人も多いことと思います。
プロジェクト管理の基礎
プロジェクト管理ではPMBOKやCMMIが取り上げられる。
PMBOKはプロジェクト管理を9つの知識エリアと5つのプロセスに整理したもので、CMMIは組織のプロセス成熟度です。
ここからはPMBOKの9つの知識エリアの概要を、現場視点と経営者視点の違いを交えて解説されました。
現場サイドでは個々の知識エリアとアジャイルとの親和性が高いのですが、経営者から見た場合は必ずしもそうではないようです。
というのも、アジャイルは開発者を性善説で捉えています。
しかし、経営者からすると、アジャイルを導入したからといって俄に開発者が善人になるなどということを受け入れられないというのがその理由でした。
言われてみれば全くその通りで、そこには何らかの工夫が必要であるように思いました。
特に、進捗報告などは「開発者とリーダー」「リーダーとマネージャ（マネージャと経営者）」とではその内容や方法を変える必要があります。
他にも興味深かったのは、コストの計画において機能ベースの見積もりとリソースベースの見積もりの比較が重要であるということです。
勉強不足なだけかもしれませんが、アジャイルでは後者の見積もりについてあまり言及されていません。
しかし、経営者視点のコスト管理ではこれらの比較が非常に重要になってくるということでした。
所感
これまでアジャイルを開発者視点でしか考えたことがなかったのですが、経営者視点で見た場合にここまで見えているものが変わるのかという気づきを得ることができました。
【1-2】TDD サイクルを加速する技術たち
[twitter:@irof]さんによるセッション。
テーブルごとにグループを作ってTDDに対する理解を確認しました。
どの程度TDDに取り組んでいるかという質問では、常にTDDで開発しているという人はほとんどいませんでした。
その後は「動作するきれいなコードとは」「変化に耐えられるものとは」といったテーマでディスカッションしました。
このセッションに参加して感じたことは、みんなTDDの有用性を認めてはいるのだけれどそれがなかなか実践にまでいっていないということです。
ただ、原理主義的にすべてのコードをTDDで開発する必要はないということが共通認識としてはできあがっていたように思います。
そのあたりに、今後TDDが現場で使われていくためのヒントがあるのかもしれません。
【2-2（前半）】大規模なゲーム開発をスクラムで
株式会社ディンプス 田口 昌宏さん[twitter:@masahirotaguchi]によるセッション。
ゲーム開発の基本的な流れを説明した後に、どのようにScrumを導入していったかの事例紹介です。
ゲーム開発には変化する要素が多いためScrumと相性がいいということでScrumの導入に至ったそうです。
初めはいくつかある役割のうち、エンジニアのチームにだけ導入して成功しています。
その後、徐々に導入の範囲を拡大したようです。
この、「徐々に」導入していくというのは実感としてもあります。
手を付けやすいところから始めてふりかえりでカイゼンしていくというのは、どこも同じように思います。
また、他にも興味深かったのは、デジタルからアナログに移行していった点です。
私も最初はITSを導入してチケットによる管理から始めたのですが、気が付くと事務所の壁に付箋をペタペタしていました。
あとはScrumに固執しないということ。
どうやら最終的には、僕も含めてみなさん共通してこのあたりに落ち着いてくるようです。
【2-2（後半）】継続的インテグレーション環境を作れ!(Jenkins編)
株式会社ブレイン 神谷 厚輝さん[twitter:@kami_teru]によるJenkins導入の事例紹介でした。
時間が短かったこともありかけ足での発表だったので、詳しくはDeveloper's Test 勉強会 (XPJUG関西 分科会)の勉強会などに参加するといいかもしれません。
