2つのパネルディスカッション―Innovate2010レポート

2010/10/7（木）、8（金）の両日、IBM主催のイベントIBM Rational Innovate2010が開催されました。昨年までは「Rational Software Conference」と呼ばれていたものです。

両日とも午前中が基調講演、午後はテーマ別トラックに分かれたセッションという構成で、10/7は経営層・管理者向けに7トラック27セッション、10/8は開発者向けに5トラック18セッション。講演あり、パネルディスカッションあり、体験セミナーあり、といった盛り沢山なプログラムでした。

今回はまとめとして、その中からアジャイルをテーマにした2つのパネルディスカッションをレポートします。

パネルディスカッション（1）これからのアジャイル

10/7のパネルのタイトルは「これからのアジャイル」というシンプルなもの。アジャイル推進派、アジャイル実践者、アジャイルに慎重な方がそろい、5つテーマについてディスカッションが行われました。ここではテーマごとに印象に残った意見を書き出してみます。

■テーマ1：マネージャやリーダの立場からアジャイル開発はどう見えるか

• 魅力的
• 仕様のオーナーのチャレンジが必要
• やったことがない技術に対してはOKだが、仕様が巨大だと危険
• 決められた仕様通りに作るという今までのやり方ではエンジニアの創造性が生かせない
• 世間はアジャイルの悪いイメージを強調しすぎ。アジャイルはドキュメントレスでもカオスでもない

■テーマ2：アジャイル開発についてどう評価するか

• 必要なのはいいシステムを作ることでありメソドロジにはこだわらないこと。プラクティスが大切
• アジャイルの良さは、早く動くものを作ってフィードバックをもらう機会を増やす点
• リスクヘッジの点で効果が大きい
• ビジネスサイドと開発サイドのディスカッションが自然と増えることが良い方向へつながる
• チームビルディングに効果あり

■テーマ3：アジャイル開発で現場が自律的に動くとき、管理職の仕事や組織はどう変わるか

• 組織としてファシリテータが必要かつ重要になる
• 管理職は人材育成に徹する。指示を与えるのではなく気付きを得られるように。
  ただし気付きを得られるようにすることはアドバイスを与えることではない
• 従来型の進捗等の報告を求めない。どうしても必要ならアジャイルはやらない

■テーマ4：アジャイル開発へと転換するときにかかる時間、ROIをどう考えるか

• ROIで測るものではない
• 今問題があるということは沈没しそうな船に乗っているのと同じ。その瀬戸際ではROIなど無意味
• アジャイルのコンセプトは未来永劫（えいごう）β版を作ることとも言える。
  単発プロジェクトで考えるのではなく派生開発まで含めればレンジは長く、ROIは十分と言える

■テーマ5：アジャイル開発に取り組もうとしている人に、経験を踏まえてアドバイスを

• 小さく始めること
• ITバカにならないこと。ビジネス側の気持ちをくみ取る
• 顧客側と開発者側との間に不信感があることが問題。だから契約で事細かく防衛しようとする。
  これはお互いの顔が見えないことが問題で、これを崩して信頼を得るには動くものを見せることが一番
• ユーザーとの間で新3Kを共有する。新3Kとは、感謝、感激、感動

パネルディスカッション（2）ウォータフォールエンジニアが語る「アジャイル経験談」

10/8のパネルのタイトルは「ウォータフォールエンジニアが語る「アジャイル経験談」」。初めにパネリストの方々の共通点と称して、次の宣言がありました。

• アジャイル開発を実際に始めたのは最近
  ―必ずしもアジャイル開発の達人ではありません
• 開発に対する高い意識を持っている
  ―受託開発など、それぞれの条件下で最大限にいいものを作ろうとしている

この宣言に加えて、前日に比べてパネリストが若い方が多いこともあって、聴講した人にとってアジャイルが身近に感じられたのではないかと思います。ディスカッションのテーマは3つ。こちらも印象に残ったことを書き出してみます。

■テーマ1：チームとアジャイルについて

• チームの雰囲気が良くなったきっかけは、ふりかえりの実施から
• 朝会など毎日のコミュニケーションを通して本心を正直に語れるようになった。→言える化
• 工場見学で現場の人と話すことができたことでチームの意識が変わった。→現場の見える化
• モチベーションは伝染する。→良い方向にも、悪い方向にも

■テーマ2：アジャイルの壁とは

• トップに理解してもらうこと
• 顧客に理解してもらうこと
• 自分の中に壁がある。→どうやっていいのかわからない
• 自分が作る壁がある。→本当にやりたいなら崩せるはず

■テーマ3：実際のところどうアジャイル開発をやっているのか

• 見積もり。→ウォータフォールと同じ
• 品質。→フィードバックが多いこととコミュニケーションロスが少ないことが品質向上につながる

アジャイルの啓発でよく言えわれることが多かったのですが、実際にアジャイルでうまくいった人の言葉なので、達成感が伝わり、説得力がありました。

最後に「アジャイルがやりにくいプロジェクトはどのようなものか」という質問が会場からあり、パネリストからは「大規模」、「官公庁」、「仕様が確立しているもの」といった意見が出ていました。

自分ならどう答えるかと自問してみて、「アジャイル」の定義次第かなと思いました。アジャイルの定義は「アジャイルマニフェスト」にある4つの価値の重視が原点でしょう。あるいは数あるプラクティスを実践すること、すなわち「習慣」かも知れません。

アジャイルは価値観であり、習慣であり、哲学でもある。そう考えるなら、アジャイルが適用できないプロジェクトなどないと言える。

そんなことを考えさせてくれたパネルディスカッションでした。

次回からは、スクラムベースのプロジェクトでRational Team Concertをどのように活用できるか、ご紹介していきます。