ObjectSquare [2011 年 4 月号]

[レポート]


Developers Summit 2011  参加レポート

株式会社オージス総研
技術部 アジャイル開発センター
張嵐

2011年2月17日(木)〜18日(金)の2日間にかけて、目黒雅叙園にて翔泳社主催による「 Developers Summit 2011 」が開催されました。筆者は9テーマ61セッションの中から「開発プロセス」テーマのいくつかのセッションに参加しました。この記事では、主に筆者が参加したセッションの内容をレポートします。

Developers Summit(通称「デブサミ」)は2003年から継続的に開催され、今回は9回目です。今回のデブサミを含む各回のスローガンは以下の通りです。

筆者は昨年末まで長く海外で勤務していましたが、この歴史あるカンファレンスのスローガンに惹かれ、東京勤務に変わった今回を機に初めて参加しました。 Twitterでの参加者と主催者のつぶやき、Facebookの利用、配布資料なし、いかにIT通なカンファレンスであることが分かります。

筆者は二日連続、会場に足を運びましたが、連日多数の参加者で賑わっていました。会場は5つがあり、ひとつあたり300人位は入れるスペースです。会場外の廊下では、テーブルを並んで、コミュニティ活動のアピールの場もありました。筆者が参加している各セッションはほぼ満員で、人気のセッションでは立ち見も出るほどでした。

講演資料は事前に配布なし、公開なしというスタイルで、セミナー後にSlideshareから講演資料をダウンロードできるようになっています。

以下、筆者が参加させていただいたセッションをご紹介します。

目次

総論

先に述べたとおり、今回筆者が選択したテーマは「開発プロセス」です。日本のソフトウエア開発現場から離れてしばらくたっていたので、現在の開発者がどのような開発プロセスに関心を寄せているのかが気になっていました。また、最近再び注目集めつつある「アジャイル開発」についても、今度の波は「本物」なのかどうか、確認したいとの思いもありました。

4つのセッションを通じて、以下の事を自分なりに理解できました。

1 日目(17日)

[17-B-2]Agility@Scale(アジャイル開発のスケールアップ)実戦編

畑 秀明(日本IBM)

今回のデブサミで、「開発プロセス」のテーマ下で、セッションのタイトルに「アジャイル」という言葉を使っているのが目立ちます。日本でもアジャイル開発は実践段階へシフトして来たと感じさせています。IBMは積極的にアジャイル開発を推進しています。

講演者の分析によりますと、日本では、アジャイル開発に対する認知度は徐々に上昇し、さまざまな会社で導入が始まっています。小規模開発にはアジャイル開発の適用例が沢山ありますが、大規模開発になると、話はあまり聞きません。規模の拡大を阻害する主な要因は、カルチャーや価値観の変更、既存ルールの変更及びルール運用の変更、過去の管理成果物の再利用ができなくなると講演者は指摘しています。

これらの阻害要因を取り除くためには、中間管理職の協力は欠かせません。「中間管理職」をアジャイル開発の推進派にするため、理解の促進、同調、体系化によって、安心させる必要があります。講演者は中間管理職が感じている以下の課題を分析し、彼らの積極的な支持を受けるためのそれぞれの作戦策を挙げました。

よくある中間管理職のアジャイル開発の捉え方及び作戦:

セッションのタイトルに「実戦編」と書かれていますが、話の中心は、いかに現状の問題点と戦い、中間管理職を説得し、そして中間管理職のリードやサポートを受けるか、についてでした。こうした問題を解決することでアジャイル開発を大規模案件に適用できる可能性が高くなるというストーリーでした。

中間管理職本人が来て、この話を聞いてほしいというのが素朴な感想です。

会場では、アジャイル開発時に品質プロセスの確立及びリスクについての質問があり、講演者からは以下のアドバイスが提示されました。

[17-B-3]チケット駆動開発〜タスクマネジメントからAgile 開発へ

小川明彦(NRIネットワークコミュニケーションズXPUG@関西)・阪井誠(株式会社SRA・SEA関西世話人)

「○○○○駆動開発」という言葉が多いので、最近はあまり気にしないようにしています。「チケット駆動開発(TiDD)」は日本の現場でのTracのチケット管理から生まれ、Redmineと言うツールの利用によって2007年から形になったことは本セッションで初めて知りました。

このセッションは阪井氏のパート1と小川氏のパート2からなります。

パート1では、阪井氏はまず、ソフトウエア開発が楽しいか、苦しいかという二つの質問を会場に投げて、チケット駆動開発は作業漏れをなくすと共に、プロジェクトを活性化することができるとアピールしていました。それから、従来型の開発プロセスに存在する重い管理プロセス、Excel文書によるコミュニケーション不足、障害の発見に注力できない、などの課題を解決するために、TiDDを用いて、チケットの運用&管理方法、チケットとコード修正履歴の関連づけの考えとやり方、などの紹介がありました。

パート2では、小川氏がアジャイル開発の課題、Redmineを利用するTiDDの利便性と有効性、チケット駆動開発の4カ条等を紹介しました。

アジャイル開発特有の課題として次の3つが紹介されました。1つ目は「頻繁に変わるタスクの管理」、2つ目は「継続的な修正と頻繁なリリースを管理すること」、3つ目は「並行開発(本番運用と開発中の2本のコードラインを持つこと)」です。

上記の3つの課題について、Redmineのチケット管理、集計、バージョン管理などの機能を利用し、TiDDの運用ルールを決め、これらの課題を解決できることを示しました。また、TiDDによって、以下の利便性と有効性がもたらされるとアピールしていました。

チケット駆動開発の4カ条を以下のようにまとめていました。

さらに、以下のような話があり、ツールの導入やチームのあり方について、考えさせられました。

私は以前参加した案件でも、Tracやチケット管理を利用しています。確かに、システム改修案件や、小規模かつ顧客の要求が安定してない案件では、TiDDは有効だと感じています。

[17-B-5]今そこにあるScrum

西村直人(永和システムマネジメント)

このセッションのスライドのタイトルの下に、「アジャイルコーチをして見えてきたこと」とう副タイトルがあります。その名の通り、西村氏は永和システムマネジメントにて、アジャイルコーチに従事していて、その経験から、現場でScrumを導入する際の、やり方や注意点について、アドバイスをされました。

VersionOneの調査結果について、先日筆者も目を通しました。西村氏はこのレポートの調査結果の数字を利用し、アジャイル開発は海外で広がりつつあること、そしてもっとも広く利用されている手法はScrumであることを示しました。このような流れの中で、日本の会社でもある日に急にトップダウンで「アジャイルをやろう」と言われるかもしれませんので、明日に備え、Scrumの超入門、導入時の注意点や、プラクティスのdailyScrum、振り返りなどを紹介しました。

Scrumを導入し、開発が楽しく感じられるようになるケースが沢山あるとのことですが、以下のポイントについて注意が必要です。

  1. いまのチームとScrumチームのギャップ
  2. dailyScrumを正しく行っているかどうか
  3. プラクティスはやればいいという考え方は楽観的すぎる
  4. スクラムマスタがいろいろなことで意思決定

また、Scrum導入にあたって、以下のヒントを提示しました。

  1. 皆が力を貸す:隣の人のやっていることに関心を払い、必要であれば力を貸す
  2. 自己組織化:プラクティスを一つずつ導入し、チェックポイントを入れながら、やりやすさを改善し、「ちゃんとやれる」を支援

Scrumは枠だけを提供するので、うまくいくためには自分たちなりの工夫が必要です。そして、自分たちのやり方を自分たちでデザインする事がもっとも重要です。筆者はこれが今回の結論だと理解しました。

また、会場では、多数の質問が出ました。もしかしたら、日本の会社でも、Scrumを導入したところは少なからずあるかもしれません。以下簡単にQ&Aの内容をまとめます。

  1. Scrumプロジェクトについて、どうなったら成功ですか。
     →  うまくいかない場合がありますが、みながやっていて楽しいと感じたら、成功だと思います。
     
  2. なぜXPではなくて、Scrumなのですか。日本人はどちらに向いていますか
     →  スクラムはシンプル、XPはエンジニアリング寄りです。
        最初に実践するにはXPがよいかもしれません。しかし、私はXPかScrumか特に気にしていません。
     
  3. Scrumを支援するツールは何かありますか
     →  ポストイットです。初めはアナログ方式がよいです。
     
  4. Scrumを導入した場合、どのくらいの期間で結果が出ますか。
     →  チームは見積りの段階で、そして、お客様は1カ月後に結果が見えます。
     
  5. Scrumのアンチパターンについて、何かありますか。
     →  スクラムマスタがリードすることです。
     
  6. 成功事例に関しては、日本のSIerではありますか。
     →  永和は成功事例です。中小企業を中心に、成功しているケースが多数あります。
     
  7. チームの人間関係について、チームになじまない人はチームから外したほうがよいですか。
     →  みな大人なので、まず態度が変わることを期待しましょう。どうしてもだめの場合、チームから外すしかないです。
     
  8. Scrum導入する時に、プラクティスを部分的に導入するか、あるいは一気に導入した方がよいでしょうか。
     →  ケースバイケース。プラクティス毎に導入もOK。最初から最低限のプラクティスを導入するのでもよいです。

2日目(18日)

[18-B-3]これからの「アジャイル」の話をしよう-今を生き延びるための開発手法とスキル

木下史彦(永和システムマネジメント)

このセッションの講演者の木下氏は、自称第二次ベビーブーム(永和ベビー?)の一人で、会社内では、「アジャイルコンサルタント」、「アジャイルコーチ」、「PM」、「ラインマネージャ」という4つの帽子を被っています。今回のセッションでは、中間管理職の立場から「アジャイル」開発の話をし、そして、去年年末に話題になった永和システムマネジメントの新契約形態の紹介をされました。

下記は自分が聞いて理解した木下氏の話の概要です。家を売買する契約書を見せ、腹をくくって頑張るお話、カナダのアジャイルカンファレンスで発表されたお話、会社社員の写真を掲示し「これは誰」という問いかけ、ストーリーを述べているのか、ドラマを見せているのか、人を次から次へ興味を引きます。筆者は、木下氏の人間味あふれるプレゼンに感心させられました。

  1. 離職率0%

    永和システムマネジメントは2002年に東京支社を開設しましたが、メンバーは息つく暇もなく次々とプロジェクトに投入され、また客先常駐が多いので、やりたい仕事ができない、一体感が感じないという理由で、多数の退職者が出ました。2005年以降、会社は方針転換をし、現場もRuby×アジャイルをやり始め、その結果、現在、顧客数も売上も伸び、離職率0%を達成しました。

  2. アジャイルは魔法ではない

    アジャイル開発を導入すれば、何もかもうまくいくということはありません。開発者にとってはいいことかもしれませんがが、単に開発が楽しいだけで、売上などの事業責任を取れないようでは無責任です。木下氏は自分が体験したアジャイル開発が受託開発でうまくいかない理由----「伝わらなさ」の紹介をされました。

    アジャイルは魔法ではなく、マネージャの仕事は障害を取り除くことです。

  3. 価値創造契約

    永和システムマネジメント社内の「売上」と「コスト」が比例しない新規ビジネス創生事業募集で、木下氏の提案による新しい契約方式が生み出されました。この発案の前提は「システムの価値は長く使われること」にあります。人月ビジネスが当たり前のSI業界において、今まで

    という契約形態をやってきました。新しい提案では

    になり、お客様の立場はソフトウエアの所有者から、サービスの利用者に変わります。 このモデルでの案件がようやく1件受注できました。以前から言われてきたことに対し、ようやく最初の一歩を踏み出したと感じます。

以上がこのセッションの概要です。非常にエネルギーを感じ、心が熱くなるお話でした。




記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。


© 2011 OGIS-RI Co., Ltd.
HOME TOP
HOME TOP