デブサミに参加。目黒雅叙園に初めて行ったが、無駄に豪華。中国的な感じもする。
さて、今年はアジャイルディベロップメントを中心にみることに。
日本のエバンジェンリストである平鍋さんを皮切りに、既に実践されている方のお話や、トヨタのチームリーダーの観点から、お話があるなど、なかなか充実した内容だった。
残念というか、やや限界を感じたのは、成功事例の二例が組み込み系と、パッケージ開発であったこと。やはり、受託してお客様のシステムを開発するというSIは難しいのだろうか？二つが共通していたのは、計画ゲームとよばれる短期的な反復をうまくシステムの開発に取り込んでいたこと。また、あまりすべてのプラクティスの実現にこだわらず、できることからはじめていることを感じた。
私がXPで好きなのは、ペアプロとテストファーストだ。逆に計画ゲームは難しい。ただ、保守の段階などシステムをより改善していくフェーズになれば、使えるように思う。つまり、まずはメインの機能部分をウォーターフォールで開発した後に、早めにプレリリースし、それからのフィードバックを短期的な反復で行い、アジャイルに開発する。このフィードバックは非常に細かいタスクで構成されることが多く、お客さんにとっても優先度もつけやすい*1。ただし、改善版を早く提供するためには、自動テストは不可欠だろうから、はじめのウォーターフォールの段階で自動テストの作り込みはやっておかねばならない。こっちの方が、私はかなり合うと思う。問題は予算やコストの関係から、初回のウォーターフォールの開発がある程度の要件をみたしていなければ、改善部分に負担がかかりすぎて、失敗する。また、受注の段階で予算を絞り込まれすぎると、のりしろがなくなってしまうため、改善ができなくなってしまう。
「あらかじめ予見できる変更は、変更と呼ばない」とは関さんの発言だが、その通りであり、むしろ予見をしすぎて複雑な設計は厳禁だ。人間はそれほど賢くないと常に謙遜する姿勢がひつようなのだ。だから、はじめはシンプルに、そのあと類似の要件が出てきたところで、リファクタリングをかけ、抽象化を行えばよい。しかし、私はこの罠に結構はまってしまう。
また、「見える化をおこなっただけではだめで、そこから改善を行わないと意味がない」という指摘も納得した。なにかXPのプラクティスを実現するだけでなにかすべてが解決するように思ってしまう気持ちもよーくわかる。当たり前のことだけれども、それは問題を発見するきっかけにすぎず、実際はそこからアクションを起こしてフィードバックする必要があるということを忘れてしまうのだ。
うらやましかったのは、成功しているプロジェクトのメンバーの皆さんがみんな楽しそうなこと。そして、当然ながら、エンドユーザーに好評なこと。いいことづくめに思える。
とりあえず、元気をもらった。明日も楽しみ。
*1:ただ、これらは普通仕様漏れによる故障と扱われてしまうことが多い
