Agile Conference Tokyo 2013 のまとめ

Agile Conference Tokyo 2013 のまとめ

7⁄17 に開催された Agile Conference tokyo 2013 に参加してきました。10時から18時までひたすら座学で激しく消耗しましたが、得るものも多かったです。

全体を通して思ったことは下記の通り。

  • アジャイルを正しく導入できた企業は、プロセスを回すことで、プロセス自体が進化している。
  • 既存のプロセスから移行するためには、組織全体へのアジャイルプロセスの教育と、トップダウンの号令が必要。
    • ボトムアップだけでは、部署間の壁を超えられない、企業ルールを変えられない。結局変革しきれない！
    • 間違ったアジャイル知識は害。
  • アジャイルプロセスは、とっくに開発者だけのものではない。ビジネス全体がターゲットになっている。
  • テスト自動化、CI すらやっていない企業は勝ち目がない。

以下、各セッション毎に重要だと感じたことをまとめます。

オープニング

Mihn Le 氏 (株式会社テクノロジックアート 取締役副社長)

  • 「この中で、会社でアジャイルプロセス使ってる人は？」
    • 結果を見て「去年の2倍程度」
  • アジャイルの効果
    • アジャイルによってリスクが減らせ、コミュニケーションリスクも軽減できる。
    • 必要とするドキュメンテーションも自動化した。エンジニアは自分の開発に集中できる。
  • 顧客はほとんど日本企業で、アジャイルを導入したいと考えている。でも昔の環境からなかなか脱却できない。ペーパーワークが4割。すべてをガラッと変えず、徐々に歩み寄るべき。従来のモデルとアジャイルを融合させていくところから始める。イテレーション、TDD、ペアプロ、CIなど。
  • 日本の比較的大きなSIerからの質問「アメリカと日本のクライアントの大きな違いはなにか？」
    • アメリカの方がデザインステップが細かい。
    • アメリカの方がドキュメンテーションプロセスを変更することに抵抗する。
    • 日本の方がむしろざっくりしているので、アジャイルには向いていると提案した。
  • アジャイルをやることになったら、_トップボトムで_全員が正しくアジャイルのことを学習しなければならない。また、なにをやっているのか見えるようにしなければならない。

基調講演: 戦略としてのカンバン：ビジネスイノベーションのために

Kraig T.Parkinsons 氏 (ThoughtWorks Inc. Principal Consultant)

かなりのボリュームでした。簡単にまとめます。

  • 多くの会社はこれまでの習慣を捨てられないでいる。
  • フォード、マッキンジー、FedExは今ではITソリューションとシステムを売っている。これまでのビジネスを引きずっていてはおいて行かれる。IT部門をビジネス部門と分けているともう勝てない。それでうまくいく時代は終わっている。
  • 多くの製品は寿命が短くなっている。製造ラインの寿命は劇的に短くなり、常に移行状態にある。一昔前は何年もかけて製品を社会に出していたが、もはやそれでは遅すぎる。勝てる会社は、短期間で何世代ものバージョンアップを重ね、たちまち自分たちの勝てる業界を作る。しかしそこで成功しても、イノベーションを止めればすぐに陳腐化してしまう。
  • どうすれば企業が常にイノベーションを起こせるのか？それには_イノベーションをルーチン化しなければならない_。一度ヒットをとばしても、それをイノベートし続けなければすぐに陳腐化してしまう。ThoughWorks ではカンバンを使ってこれを実現している。

カンバンの理念

  • 原則1: 「ストーリーを知っている」と仮定しない
    • 多くの PM はバックログをマネージメントしようとしがち。
    • 過去のユーザーストーリーはあくまで過去であり、将来的に何が可能かはそこには結局書いていない。
  • 原則2: 必要になる人を正しく選ぶ
    • ビジネスオーナー: 代理ではダメ！危機感の無い人ではダメ。必死に利益を欲しているだけ人と対面する。
    • UXデザイナー
    • 技術者: 何が実現でき、何ができないかを教えてくれる。
    • ユーザーと顧客:「こうあってほしい」という世界を教えてくれる。
  • 原則3: できるだけ頻繁に現場に行って見る
    • 現場意識を持つ。
    • 実際にそこで何が起きているのかをしっかり見る。
    • 役員室やプロジェクトルームで伝達されているだけでは伝わらない。自分の目で見て体感すること。
    • 「百聞は一見に如かず」は本当。

実際にTWが始めたこと

  • ダイバージェント（発散的）な思考プロセス → 収束的な思考プロセス
    • 支離滅裂に見える発散的プロセスを行わないと、可能性が広がらない。
  • 5つのステップ: 機会を捉える→アイディアを生み出す→実現後の予想図を描く→テストと検証→解決策を収穫する
    • すべてのステージで学習できる。「継続的学習」
    • 学習を通じてカイゼンが起きるように努力する。
  • デリバリーチームがより発散的なアイディアを出せるようにサポートする。

どうすればこれができるようになるか？

  • 誰でも参加できる社風を作る。
  • イノベーションの様々なやり方を知る。
  • WIPを制限し、フォーカスを絞り、アウトプットを引き出す。
  • 複雑な問題に対処するため、サービスのクラス分けと優先順位づけも有効。
    • すべてのサービスが等価値ではない。
  • 仕事とマネージのペースを知る。
  • やりがいのあるミッションが人々を奮い立たせる。
    • コスト削減の追求ばかりでは萎える。
  • 継続的デリバリーを持つ。
    • これがパイプラインとなる。
  • ピボット可能にデザインする。
    • いつでも最適な道に移れるようにしておく。
    • 巨大な（モノリシックな）デザインだと切り替えが不可能。
  • 可視的にマネージする。
    • いつどこで何が動いているのかを、誰にでも見えるようにする。
  • 協業する。
    • ビジネスは_チームスポーツ_である。

セッション1: アジャイルな企業のTo Beモデルを提示するScaled Agile Framework (SAFe)

藤井 拓氏 (オージス総研 技術部アジャイル開発センター センター長)

SAFe とは、企業規模でリーンとアジャイルのプラクティスを実現するためのフレームワーク。Scaled Agile Framework で公開されている。

細かいことはホームページに書いてあるので省略。一言で言うと、複数の Scrum チームを束ねて定期的なリリースを可能にするルールと、経営層の意思決定をリリースに繋げる流れを示したフレームワーク。

特に気になったアジャイルリリース列車 (ART) の説明は下記。

  • 50-100名のメンバーを5-12のチームにし、8-12週間ごとにリリースをする。
  • プロダクト毎に「プロダクト管理者」が1人いて、その下に各チーム毎にPOが割り振られている。
  • チームレベルではScrumを実践。
  • チームは2週間ごとにインクリメントを納品する。
  • 技術的プラクティスはXP。

セッション2: スクラムと品質 （日本マイクロソフト提供セッションー日本のアジャイル実践の現場から）

細谷 泰夫氏 （三菱電機株式会社 通信機製作所、TFSUG立ち上げスタッフ）

  • なぜプロダクトの品質が悪くなるのか？
    • オーバーコミットメント
    • 階層的な組織構造
    • 上の2つが組み合わさると、激しく品質が下がる。しかも持続して負のスパイラルを生む。
    • Scrum は、こうした状況を避けやすい。
  • Scrum 実践に必要なこと: 型、プロセスの習熟
    • 適切に運営されたフレームワーク
    • プロセスの理解とチームでの実行の繰り返し
    • 頭ではなく体に型をなじませる、習慣化
  • 三菱電機での工夫
    • 新人をチームに入れる時は、ベテランと組ませて、スキルの伝播を行う。
    • TDDが簡単にできなさそうな時は、すぐスパイクソリューションかチームレビューに移る。

特別講演: エンタープライズ規模におけるカンバンの運用

  • 高木 徹 氏（株式会社豊田マネジメント研究所　副社長）
  • 三井 伸行氏（株式会社戦略スタッフ・サービス　取締役）

日本のIT業界の現状

90% 以上が質が不足と回答。特にプロジェクトマネジメントが 62.5% 不足。

なぜマネジメントが低下した？

  • 統制型マネジメントの崩壊
  • 自律的に動ける人材が育っていない

アジャイル開発の土壌を醸成する

「上司が変わると仕事のやり方が変わる」のはダメ。

エンタープライズにおけるカンバンの進化

  • カンバンに貼り出すことで、個々人が持っている暗黙知が可視化され、議論可能になる。
  • 議論によって形式知を取り出し、改善アイディアを実践する。
  • 新たに溜まった暗黙知を、またカンバンに貼り出す。

自分やチームの仕事を写像→カンバンに見える化→暗黙知が形式知に置き換えられる→カイゼンのための会話が生まれる→修正した形式知に従ってやってみる→ツールを見て仕事をする（暗黙化）→カイゼンのアイディアを写像→…

アジャイルプロセス適用のステップ

  • ステージ１: 「自分たちがまずどうなりたいのか」を自分たちで見える化する。
    • カンバンに貼り出すと効果的。
    • 「思っていることを出して」と言っても出ないなら、それ自体が大問題。
    • KPT は問題を炙り出す道具として使える。
    • ボード一つ作るのにも3ヶ月はかかる。
    • いつか芽が出ることを感じられれば続けられる。
  • ステージ2: 事業方針に展開する。

適用のポイント

  • 経営幹部が組織を変えたいのかどうか確かめ、それをどう落とし込んでいくのか考える。
  • トップダウンのほうが手戻りが少ない。手戻り工数は膨大。
  • パイロット運用だけだと、他部署まで変えていくことができないことが多い。
  • 複数部署にカイゼン風土があれば、連携して組織の壁を越えられる。でも2年はかかる。
  • カンバンを作る時は、「運用を始めて、不具合が出てきたらカイゼンする」というやり方でOK。
    • カンバンはどんどん進化する！

セッション3: 大規模分散アジャイルを支えるプラットフォーム

上村 務氏(日本アイ・ビー・エム株式会社)

IBM が使っている大規模分散開発用のアジャイルフレームワークの説明。ほとんど Rational 製品の解説だけで終わっていました。

セッション4: コンパクトなチームでのアジャイル開発とその実践

  • 及川 喜之氏(株式会社セールスフォース・ドットコム)
  • 堀 譲治氏(株式会社シャノン)

SalesForce のスクラムチーム

  • 100以上のスクラムチームがある。
  • 「Salesforce Agile」でググればスライドがいっぱい出てくるよ！

シャノンで使っているツール

基本的にOSSや無料パッケージの組み合わせ。

  • Pivotal Tracker, Google Docs, Cacoo
  • Github Enterprise , Jenkins, Bugzilla
  • Heroku, AWS
  • Google talk, IRC, Skype

Pivotal Tracker

Googleスプレッドシートでストーリー管理していたが、以下の理由で限界を迎えたので使い始めた。

  • イテレーションがわかりづらい
  • 並び替えしづらい
  • 依存性の管理ができない
  • 「いつ終わるのか」の未来管理ができない（致命的）

Pivotal Tracker のいいところ

  • Bugzilla、GitHub と連携が可能 → トラッキングが簡単に！
  • 複数のストーリーをまとめて「エピック」として束ねられる
    • エピック毎に企画し、予算を出すようにしている。
    • エピック単位の進捗管理が可能になる。いつ終わるかすぐわかる。
  • ベロシティと、リリースまでに必要なイテレーション数を自動で算出 → 精神論に拠らないリリースプラン
  • アナログに近い使い勝手
  • ほかのツールとの統合が容易

GitHub Enterprise

  • 外部ツールとのインテグレーションが充実
  • 標準の機能で、Web上で簡単にコードレビューができる
  • 統計ツール、グラフが充実 → ふりかえりに数値的裏付けが使えるようになった

Jenkinsを使ったCI

  • 自動テスト、コードカバレッジ監視、デプロイ、Seleniumのキックで利用
  • 自動で重くないスレーブノードにテストを分散できるプラグイン
  • Test Failed 時は IRC に連絡
  • Pull Request と同時に Unit Testing 実行 → 壊れたビルドをマージしない！
  • コードレビュー時にGitHubレビューに「Jenkins, test this please」と書き込むと、UTが走る

透明化、自動化ができた。

Heroku

AWS を使いたくても、エンタープライズ向けの必須要件 (セキュリティ、パフォーマンス、SLA、…) をクリアさせることができない。

人数が少なく専任のインフラエンジニアを割り振れないので、それらを吸収してくれる PaaS の Heroku を使い始めた。

  • サーバーを意識しなくて良い。
  • Git コマンドだけでデプロイ可能。git commit & push だけ。
  • パフォーマンスアップも WebUI から簡単にできる。
    • 業種上、キャンペーン日だけアクセスが激増することが多いが、簡単に負荷に対応できる。
  • New Relic プラグインで簡単にサーバー監視が可能。
  • 無料でパフォーマンス分析まで可能。
  • 運用をかなり簡素化できる。高度なインフラ知識が無くても十分運用できる。

セッション5: 事例から見るアジャイルの失敗と成功 （二度とアジャイルはやりたくなかった人が語るアジャイルの成功ポイント）

  • 平岡 嗣晃氏（株式会社　日立ソリューションズ）
  • 奈加 健次氏（株式会社　日立ソリューションズ）

日立ソリューションズの失敗事例と成功事例。

プロセス

  • プレーンなアジャイル
  • ハイブリッドアジャイル
    • 要件定義、基本設計、リリーステスト: ウォーターフォール
    • 詳細設計、開発: アジャイル
  • ウォーターフォール

2007年の失敗

  • 本のとおりにやってみようとした。
    • 「ドキュメントを作らない」
  • →「優秀なプログラマを集めればアジャイルができる」と勘違いしたまま、100人集めた
  • →結合テストで全く繋がらずボロボロ
  • →結局24時間体制でフォロー、全ドキュメントレビューも実施。

2度とアジャイルやりたくないと思った。

2012年の成功

  • なぜアジャイル開発を行うのか？目的を明確化した。
    • 「仕様変更に対するコストをアジャイルで削減すること」
  • 顧客を含め、プロジェクトメンバーへの教育を徹底した。
  • プロジェクト管理（進捗、コスト、品質、変更）を明確化した。
  • チケットの粒度は必ず8時間以下。大きければ分割する。
  • 朝会で必ずバーンダウンチャートを確認。
  • 変更を受け入れるための進捗には「ゆとり」を持たせて計画する。バッファ。

ポイント

  • TDD はいきなりやれと言われても絶対できない。
    • レッド・グリーン・リファクタリングのリズムを徹底的に教育。
    • 教育にはペアプロが最適。アマチュアとベテランを組ませて、技術の伝播と平準化をはかる。
  • 常時結合（CI）も教育した。
    • 夜10時から朝5時に毎日走らせ、朝会で確認するようにした。→いい加減なコミットがなくなった。
  • 仕様の確認方法と受け入れ方法をルール化しておく→スピードアップ
    • スプリントレビューのタイミングが基本
    • 仕様決定者全員が合意する時間を作る
    • 約4時間で用件説明、レビュー、操作確認を行う。
  • 「アジャイルプロセスの適用」が目的ではない！
  • アジャイルは楽ではない。
    • 残業を認めず、時間内にやり遂げることが必要。
    • 「3ヶ月は続けられない」というアンケート結果が多かった。ずっとアジャイルは無理という印象。