要求開発アライアンス5月定例会に参加してきた

勉強会 要求開発 Scrum

先日(といっても2日前)の『DevLOVE HangarFlight - Spring Bomb -』にて、牛尾剛さんのスクラム関連セッションを聞き、これは興味深い！と非常に感銘を受け、MLに登録のみ行っていた状態であった『要求開発アライアンス』で定期的に開催されている定例会に参加してきました。

場所は日本総合システム株式会社大会議室＠東新宿。

そして今回の定例会テーマは『要求開発×スクラム』。
スクラムからの興味の繋がりでここに来たのもあるし、しかも内容的にも基礎の部分の解説。ちょうど良いテーマでした。

アジャイルの概要とスクラムの基礎

冒頭、アジャイルについての解説を牛尾さんから。今日はスーツと言うことで、先日行われたシャウトは無しの方向でした。(^_^;)

内容としては、以下のスライド内『アジャイルの概要』の部分がベースとなっていました。

  • 開発プロセスの歴史
    • 最初は試行錯誤で(カオス型・スクラップビルド)→やり易いが、品質・生産性はイマイチ
    • 計画主導・先行型設計…計画を立てて設計しよう
    • 要求を決める→設計・製造・テストで要求に合致しているか検証
      • 最初から全てを予想出来ないし、変更も多い。動かして見ないと分からない。
      • スクラム方式は、建築業界等では上手く行っている。上手く行っていないのは日本のソフトウェア業界だけ。
      • 変更のない/少ない場面では有効。ソフト開発には向いてない？
  • 適用型／進化型設計
    • 計画重要だけど、変化があったら適用させるほうに注力しよう
    • 大きな計画をたてる
    • 反復サイクル（2週間毎）
      • ※WFを2週間繰り替えす、ではない。→サイクル内でも作業を行き来している。（進化型）
  • アジャイルは、適応型の開発プロセス。
    • ソフトウェア開発に向いている
    • 試行錯誤と生産性／品質確保の両立
    • 短期の確実な計画と計測（意外と厳密）
  • アジャイル開発とは
    • 迅速且つ適応的にソフトウェア開発を行う軽量な開発手法の総称
    • 次の価値を共有する
      • プロセスやツールより、人と人同士の相互作用を重視
      • 包括的なドキュメントより動作するアプリを重視
      • 契約上の交渉よりも顧客との協調を重視
      • 計画に従うよりも変化に対応する事を重視
    • 代表的な開発手法
      • eXtreme Programing
      • Scrum
      • FDD
      • Crystal Family
      • DSDM

  • 変更に対するコストカーブ
    • 通常はフェーズが進むにつれ変更のコストが大きくなる
    • 先のフェーズでも変更ノコストガあまり掛からない様に出来ないか？
    • アジャイルだと、後の方でもあんまりコストは掛からない
  • アジャイル開発の実施イメージ
    • １〜４週間毎に、動作するアプリケーションを作る
    • １〜４週間毎に、計画・実施・評価し、改善する


ここでセッショントーカーは牛尾さんから林さんにバトンタッチ。

まずは林さんの自己紹介。最近ご結婚されたそうです。おめでとうございます！

また、すくすくスクラムについての簡単な紹介も少々。

Scrumについては、林さん自身『140文字で何とか言えないかな』と考えておられたようで、今現在のつぶやきはこちら。


この文章に関しては今後もブラッシュアップを重ねて行くそうです。

  • ツールとスキル
    • 広義の『道具』：どうやって使うか。
    • どんなに良い道具でも、カラダで理解しないと得られない領域がある。
      • ツール
      • スキル
      • 技

あたりを話したところで、集まった方々達5〜6人ずつでグループになり、ワークショップの始まりです。まずは自己紹介＆参加目的を各自トーク。

ここで林さんのグループ内席位置指示により、グループリーダーを任命。幸か不幸か私もそのリーダーとなってしまいました。初めての参加なのにここで一気にハードル上がった(>_<;)(笑)

グループでのトークの後はスクラム基礎についての解説。スクラムとは元々日本の製造業で行われていたもの(『カイゼン』)をパターン化したもの(日本由来)であったりとか、それらの歴史を遡るために第2次大戦の頃まで遡ってみるなど、歴史的な側面としてこういう流れがあったのか！と驚きました。つか何で日本由来のパターンなのに日本(のIT業界)で浸透してないんだ…ってツッコミは入れたくなりますが。(^^;)

以降、スライドでスクラムの基礎的な部分について図解・文章を交えて解説。詳細については後日スライドがアップされる事を期待し、自分が書き留められた主な部分のみメモ。

  • スクラムの基礎となる価値
  • 3つの柱
    • 透明性(毎日状況が分かるようにする、プロセスの見える化)
    • 検査
    • 適応
  • スクラムのプロセス概要
    • 実測駆動管理
    • ROI
    • 振り返りと調整
    • 2〜4週間毎の納品(＝納品可能な品質のものを仕上げていく)
    • 管理しない管理
    • チームの責任と権限


  • スクラムマスターについて
    • 管理者ではない
    • 権限は無い
    • 指示型では無い→促進型
    • 組織変革の主役
  • プロダクトオーナーについて
    • スプリント毎に権限と優先順位を変える権限を持つ
    • 優先順位リストをメンテナンスする人
  • ミーティングフロー
  • プロダクトバックログ
    • プロダクトオーナーが決める
    • チームが規模を見積もってスプリントの範囲を決める
  • ユーザーストーリー
    • ユーザー視点で機能を短くしたもの
    • 共通の言葉で書く。
    • 良いユーザストーリー：『INVEST』。
  • デイリースクラム(朝食)
    • 毎日15分だけ状況報告
  • スプリントレビュー
    • ユーザにスプリントで作ったものをデモする
  • スプリントレトロペクティブ(反省会)
  • ミーティング体系
    • 人によって、出席／欠席、会話に口を挟むべきかの有無についての分類が異なる。
    • スクラムマスターは全てに何らかの形で参加
  • プランニングオニオン
    • 必要な期間を必要な精度で見積もり続ける。
  • 要求の基本
    • ビジネス・システム／戦略・オペレーションのマトリクスにおいて、経営層・プロダクトオーナー／業務担当・開発チームはそれぞれに責任部分を持つ。
    • スクラムマスターは、それら責任範囲のマトリクスの外に位置している。
  • 色々な問題
    • POはどうやって優先順位を決めるのか。
    • ストーリーや背景等をどうやって伝えるか。
    • プロジェクトスコープを超えた範囲ではチームでPDCAを回せない。
    • 指示型のマネージャーがスクラムマスタをやるのはダメなのではないか？
    • WBSタスク指向の人も…(以後略)

…と、ここで『色々な問題』について投げ掛けた後に次のトーカー、高橋さんにバトンタッチ。

スクラム事例紹介

スクラム概要を学んだ後は、実際に現場でアジャイルを実践しておられる高橋様から
スクラムの事例についてお話をいただきます。

と言うわけで、実際にスクラムの現場での様々な経験談を聞くことが出来ました。

『このやり方が正解ではない。参考程度に…』と前置きした上でのセッションスタート。

  • スプリントバックログ
    • 付箋を使う＆印刷した紙をボードに貼り付ける
    • 作業タスクに細かく分割：強粘着のポストイット最強。落ちちゃう(無くしちゃう)と深刻な問題になるので。
    • 付箋に、作業の残り時間を書き入れて更新。
  • デイリースクラム
    • ボードの前で話していこう(机の傍だと会話に集中しない場合あり)
    • スクラムマスターに話し掛けるのではない(ついついそうなってしまう)。あくまで話すのはチームに対して。
    • 『完了の定義』(何を成したら完了なのか)をリスト化して掲げておく
  • 作業風景
    • 壁一面の巨大なホワイトボード(数チーム分のスクラム関連情報を一挙に掲載)
  • バグ管理
    • デザイナのセンスで、一風変わった(ユーモアのある)バグ管理表(手書きイラスト)に→終盤はバグが増え、結局はRedmineに移行していった
  • スプリントレビュー
    • 繰り返していると段々飽きてくる→時にはビールを飲みながら(at 恵比寿ガーデンプレイス / 金曜夕方が実施時間帯だったのでそれなら…って事で)
  • ふりかえり
    • 皆の感情を共有
    • みんなが気持ち良く仕事を進められないと捗らない
    • 飽きた時には趣向を変えて
    • 改善のアクション
  • 結末/振り返って
    • 会社は買収されてしまった(会社背景等については後日スライドがアップされた際にご確認を…)
    • 最初の1年は書籍やWebを参考に進めていたが上手く行かず。アジャイル・スクラムコーチを雇うことで改善が進んだ。
  • スクラムマスターとして感じたこと
    • 多様性を認める→『仕事だから』が通用しない。
      • 今回の経験談で語られたプロジェクトには多種多様な海外からの技術者・職種が参画。(国名は失念したが、4大陸に跨がる多様さ！それらの人々が日本で開発に携わっていた)
    • 議論から逃げないこと。仲良く議論
    • 一番頼りになるのは『論理性』。
    • ファシリテーション：プロセスをコントロール
    • ポジティブで居続ける事。スクラムマスターをやっていると結構凹む・突き落とされる事がある。諦めないこと。
    • 英語は余り発音関係ない。英語圏の人は結構真剣に聞いてくれる。

…という感じで、実際の作業風景の写真を多数交えてのお話でした。聞いていて何だか夢の様な現場・環境だな〜としみじみ。大変さは想像に難くないですが、それ以上にやり甲斐や楽しさもあったのだろうなぁ〜。会話での背景にアナログツールが多々出て来ており(紙とか付箋とか)、デジタルツールがそんなに単語が出てこなかったのが新鮮でもありました(実際は使ってたのだろうけど)。

アジャイルワークショップ

林さんのセッションで(高橋さんに)バトンを渡したところからワークショップとして再開。問題に対する回答をそれぞれ展開していきました。

最後に、グループ毎にワークショップで出た意見のまとめ報告を実施。グループリーダーになってしまった私ですが、今回が定例会初参加、スクラムも要求開発も初心者だった身としては大して綺麗なまとめも出来ず、しょーもない総括で終わってしまいました…(汗)

通常講義とワークショップが時間的にほぼ半々？位の今回の定例会。PCでメモ＋手書きでもメモ、ワークショップで頭も使い…のフル回転でしたが、内容は濃く、有意義な時間でした。

スクラムについては、2011/05/27(金)に『第23回すくすくスクラム 〜ゲームで学ぶ"Scrum の概要"〜』。
こちらは震災の影響で延期となっていたイベントですね。

また、次回定例会は2011/06/20(月)を予定しているらしいです。

Scrumに関しては『Scrum Boot Camp』等も熱を帯びている昨今ですが、このように実際に現場の経験を聞き、実践を行う事で得られる知識や経験を考えてみるとその人気も分かる気がします。

幸いな事に『すくすくスクラム』『Scrum Boot Camp(横浜)』共に参加申込に間に合ったので、これを機にスクラム経験値も上げていきたいと思います！


…つか、4日で3つの勉強会・イベント参加(5/20(金)第3回Jenkins勉強会→5/21(土)DevLOVE Hanger Flight→5/23(月)要求開発アライアンス定例会)はさすがに出過ぎだな(笑)出過ぎだと思いつつも、魅力的な勉強会・イベントがどんどん出てくるから悩ましいところだ…(つД`)