Date : 2015/02/28 (Sat)

ビスケットの日ですが、スクラム祭りに行って来ました。

具体的な内容が多く実践してみたいものが多くありました。

1A-1アジャイルRCA アジャイルに無駄とその原因を見つける

RCA ( Root Cause Analysis

• 要因分析
• 5WHYS
• 市場で大問題が起こったときの再発防止策を考える時に使う
• 品質改善に有効な情報を与えるツール

これまでは、なぜなぜ分析を使っていた

• 問題点
  • 時間がかかる
    • 資料準備
    • 分析のテンプレートレビュー
    • 1度では終わらない
    • トータル8hかかる
  • 責められる
    • ストレスを感じる分析
    • 何故は最強の質問
    • 過ちを犯した人を攻撃してしまう
    • 心理的に感じる責められてる順番
      1. Why
      2. How What
      3. Where Which When Who
      4. Closed-ended(yes/no)
    • ソフトウェアはバグが欠陥で、対象はエンジニア
    • バグをどう思っているか
      • バグは憎むべき物か
    • 詰問に対する反応
      • 防御モードが起こる
      • 深層を探ることよりも自分の答えを正当化しようとする
      • 本当は真の要因が知りたいのに、見かけの要因にいってしまう
      • 強力なしりとりで隠し、違う所へ行ってしまう
      • 強力な質問から適切な質問をするのが大切
  • スキルが上がらない
    • 時間がかかる⇒分析の回数が減り、分析スキルが向上しない
    • 適切な質問を考えだすことができない
    • 真の要因に辿り着かない
• 改善
  • イテレーティブRCA
    • RCAミーティング15~30分
    • 準備資料は求めない
    • 毎日同じ時間に
    • ミーティング後次の質問を考える
      • 質問策定に時間がかけられる
    • イテレーティブRCAループをひたすら繰り返す
      • 適切な質問
      • 適切な回答
      • 回答の議論
      • 適切な方向、方針
  • イテレーティブRCAの問題
    • 質問がうまくだせない
      
    • 欠陥や要因以外の因子が多くある
    • 欠陥モデルの必要性
      • 誘発因子
        • その過ちを誘発させるもの
        • 誘発因子が存在すれば、開発者の能力・経験・技術力関係無しに過失が起こされやすくなる
      • 過失因子
        • バグを生み出した人間の過ち
        • 人間の思考や判断の誤りそのもの
        • 欠陥は過失因子の集合として生まれる
      • 増幅因子
        • 過失連鎖を情調し、欠陥の混入確率を増幅させる要素
        • 環境などによる過ちを増幅させる原因(休出で誰にも聞けなかったなど
      • 欠陥
        • 不具合、障害等の現象を発生させる
        • どこでおきたか
      • 表現現出
        • 欠陥によって起こされる不具合、障害
        • 何がおきたか
  • 分析チーム
    • モデレータ
      • アジャイルRCAを理解しプロセスをドライブする人
      • 欠陥モデルを作成する
      • 質問、戦略を作成する
        
    • レビューア
      • モデレータのファシリテーションをサポートする
  • インシデント分析ループ(イテレ1日目15分|RCA1日目
    • 障害で何が起こったかを分析
    • 事実、背景、状況、起きた事だけを聞く
    • 分析は我慢する
    • パラフレージングが有効（自分の言葉で言い換えて聞く
  • 探索的ループ(イテレ2日目15分|RCA2日目
    • インシデントで質問を考えておく
    • 推論をかけながら引き出していく
    • 長くても30分まで
    • 探査クループ後のモデリング
      • 探索ループから戦略を考える
      • モデリングをもとに次のイテレの質問を策定
  • 欠陥モデルで質問する(イテレ3日目|RCA3日目
    • 欠陥モデルをチームで合意する
    • 策定した質問をベースに探索的分析ループを回す
  • 例(仕様チーム側のみ
    • 1日目：ある実装が無い
    • 2日目：
      • 欠陥因子⇒ドキュメントに書かれていない
      • 過失因子⇒当たり前だと思って仕様書に書かなかった
      • 仕様書を直さない⇒チームが同意しているのなら正しい
      • 過失になるなら他に書かなければいけない事が多すぎる
      • 設計と仕様担当が離れると価値判断が変わり共有がしにくい
        • 暗黙知のコミュニケーション
        • 暗黙知の齟齬=想定外
        • 組織がでかくなると当たり前がずれてくる
    • 3日目：
      • 過失因子⇒価値観が違う事に気付いていない
      • 最終日
        • 過失因子⇒振る舞いのポリシーがない
        • 暗黙知の齟齬=想定外
        • ポリシーを作り暗黙知をサポートする
        • 離れて行く暗黙知を一つにする
        • 振る舞いの判断基準のドキュメントを作成
  • アジャイルRCAの効果
    • 2チームで6ヶ月以上継続
    • 分析スピードが4倍以上改善
    • チームとの信頼関係
      • バグは貴重な情報
    • ファシリテーションの向上、品質改善のモチベーションアップ
    • 客観的に見る事が出来るようになる
      • ソフトウェアはバグが欠陥で、対象はエンジニア
      • 　↓
      • ソフトウェアはバグが欠陥で、対象は欠陥モデル　　　　　
  • ファシリテーションのこつ
    • 欠陥に突っ込まない⇒何故と言いたくなる
    • 因子を探る
      • 条件、状況、言い訳、愚痴をどんどん出す
      • 言った事はその場でモデルに書き込む

KPT

• 7つのステップ
  1. 活動を思い出す
  2. うまく行った行動を確認
  3. 問題洗い出し
  4. 原因を検討
  5. 改善策
  6. 試したい事を考える
  7. 試す事を選択する
• Agile RCAが貢献するところ
  • 3.問題洗い出し
  • 4.原因検討
  • 5.改善策

アジャイルRCAは、欠陥モデルを使い複数のイテレをループさせて継続的に要因分析を改善している

• 欠陥モデルがイテレごとに進化する
• 欠陥モデルを毎回評価し合意して改善して行く

RCAの課題

• モデレータが最初必要だが段々自分たちで出来るようになる
• 知見をため情報を流通させ、未然防止活動をする
• モデリングのデータベース化

感想

チーム内の雰囲気を壊さないためにも、この手法はとても面白いと思いました。

人ではなく原因を追求し、その環境やその人の経験から生まれた考えを洗い出す。

継続していくことでチームを作り、思考を整理できたりと少しずつでもやってみたいなぁと思いました。

発生源のパターンをイテレ時にチーム内で認知しているので、お互いにフォローが出来るのかなとも思います。

知見の扱いは膨大な量になり人によっては当てはまらないものもあり、ただ時間がかかるだけになりかねないので どう有効に扱うか考えどころだなぁ、、と思いました。

1C-2開発モデルの作り方

守破離とは

• 守：基本
  • ルールに従え
  • 息をするようにルールを行う
• 破：応用
  • 自分なりに工夫してみる
  • ルールに従った上でアレンジ
• 離：独自性
  • ルールを忘れろ
  • 独創的なオリジナル個性を発揮する
• 語源
  • 兵法用語

試行錯誤を辿り着いた破

• 例：オフショアとの開発
  • 1度のやり取りで期待通りアウトプットが出て来ない
    • 1度での完成をあきらめ初回ざっくり開発
  • 見積もりの精度が低い
    • ざっくり開発工数を見積もる、完了係数を使って算出
  • 95%完了から先が長い
    • 最後の5%は日本側で完成
  • RFCモデル
    • ベースはかんばん
    • Todo,Doing,Done
    • DoingをR,F,Cで更に細分化
    • Rough(Doing|Review
      • ざっくり開発フェーズ
      • 7割程度の完成を目指す
      • バックログの時点で着手可能・仕様記載済みのストーリ
      • ストーリのタスク分割時にオフショア側に工数を見積もってもらう
      • レビューフェーズでは完成までに必要な仕様を詳細に伝える
    • Fill(Doing|Review
      • 9割以上の完成度を目指す
    • Closing
      • 完成フェーズ
      • 日本側のエンジニアが対応
• 型破り開発モデルを編み出す
• 守フェーズを終えて開発モデルを編み出す
• まずは型を学ぶ
• 型を身に付けた上で、現場の改善に取り組む
• 取り組んだ内容を体系化し、開発モデルとしてアウトプットする
• 試守破離がおすすめ
  • 痛い目にあってから学
  • 試す＝会社に属すメリットはチャレンジができること
• Trelloでかんばんをオフショアと共有、見える化

感想

試守破離の考え方や、開発モデルの編み出し方にとてもしっくり来ました。

手法は過去に色々な人の考えが積み重なっていて、自分が知る頃には気にする必要がないものばかりです。

過去の手法を具体的に見て自分なりに解釈すると、現在の問題に当てはまるような物もあったりと、 守を習得しそれを組み合わせたり自分なりの考えも合わせて行けば 問題解決の大きな一歩となり新しい手法になるんだと感じました。

守破離からまた守まで移り変わったとしてどこまで知ればいいんだって感じにはなりそうですが、、

肉付けを外した根本的なものを見いだしていければと思います。

1B-3大きな組織にスクラムの輪を広げて行くために

• 作業をいかに効率化するかが中心
• 改善は内省ベース
• プロセス改善は会社間レベルの活動になる

コミュニケーションの距離が遠い

• 離れた所で見ているのではなく良い物作りに携わる
• 遠隔地からスクラムをどう広げるのか
  • 答えは無いけどあるあるネタはある

パターンランゲージを作成

• 辺境で立ち上げる
  • エヴァンジェリストになり立ち上げ始める
• 離れたチームと恊働する
  • 失敗していただく
    • 全国にスクラム10チーム
    • 現場に任せる
    • 日々の調整などで意見交換
    • 口を出さずにチームの決断を尊重する
    • 実際にトラブルが発生する瞬間を捉え振り返る機会を用意する
    • トラブルが発生する事を見越して関係各所と事前にねごっておく
  • まあまあ業
    • 早めに割って入り双方を代弁する
    • チャットの導入で言葉が足りず誤解が生まれた
  • フリーキッカー
    • 貴重なスペシャリストには思いっきり自由に動いてもらう
    • 全てのチームの全ての課題に関われるよう合意を取る
    • フリーキッカーがチーム感の潤滑油になる
    • 良いコード、デザインが複数のチームに広がる
  • ガス抜き提案
    • スクラムチームの判断で自由にリリースできるバックロググループを定義する

1-A4自己組織的なScrumチームの目指し方

自己組織的

• わくわく出来ることを探す
• 会社の規模が大きくなると多様な意識の人が増え、方向性の共通認識を作れず組織としての課題が多い

事例：エンジニアコミュニティ

• 社内勉強会 金曜夜に開催、その後懇親会(テーマ無し
• 目的
  • 社員がアウトプットする練習の場を作る
  • 社員が業務以外で集まる場を作る
• プログラミングコンテスト
  • 目的
    • 社員の技術スキルのポートフォリオをGithubに作る
    • 問題解決のプログラムの問題を提示し、一ヶ月弱の間に各々Githubにあげる
  • 効果
    • 高速化やアルゴリズムに興味が沸く
• AdventCalendarなどアウトプットを促す
• MBB - Management by Belief
  • 会社として期待する内容と個人の希望をすり合わせる ### 目的はなにか
• 自己組織化プロセス - 個人
  • なにもできない
  • 思いを持つ
  • 入力可能
  • 出力可能
  • 自律
    • 自分と他者で入出力
• 自己組織化プロセス - チーム
  • カオス
    • 存在
  • トップダウン
    • リーダに従う
  • 主体的
    • 責任共有
  • 共同体
    • ゴールの共有
  • 自己組織的チーム
• 自分の位置を確認する
• チームと自分のためにできることの指標
• 現在の状態と目標の状態を設定するとやるべき事の可能性が見えてくる
• 自己組織プロセスを辿るプラクティス

感想

仕事の中でわくわくできること探し⇒自分自身の充実、チームへの貢献

チーム内で今できることを見つける指標⇒自己組織化プロセス

twitterで見つけた一言で、別の部屋のセッションだと思いますが、少しリンクしたので↓

「立ち上げメンバーのようなプロダクトオーナーシップを持つ事が重要」

LEADERSのドラマを見た時にも感じた事。改めて意識できたのでよかった

1C-5大規模システムのスクラム実践効果と課題

PF Scrum Team

• PF Scrum 現場レポート
  • アプリ自動ビルド配信チーム
  • WHY
    • 大規模になるにつれてリソース、専門スキルが必要になって来た
  • Changed
    • 脱属人化のためにやったこと
      • やる事やらない事を明確にした
      • メンバーで合意する形式にした
      • ストーリー完了のために、作業が開発チームで共通認識し誰でもタスクアサインできるようになった
    • 職種を横断したスキルUPのためにやったこと
      • 1ストーリーに誰でも手を出せるタスクを造り誰でも担当できるようにルール化した
    • プロジェクトに対する意識の向上
      • SprintPlanning、リファイメントに全員で参加
      • プロジェクトの将来や現状、方向性が共有できた
  • Unchanged
    • ウォータフォールなPBL
      • プロジェクトのKGIを決めKPIを意識しPBI作成、リファイメントする
      • 決まった仮説、アイデアはとことんアジャイル、小さく早く

Swtich Scrum

• スクラムマスターを他のチームと入れ替える
  • 他のチームのスクラムを体験し良い所を知る
• タスクボードルール
  • 色を分けて見積もりのズレを可視化する
• SMファシリテーション
  • ルールを守れていたら削除して増えすぎないように工夫をする

まとめ

5つのセッションを聞いて来ました。

レポートとしては、感想書いてなかったり内容書ききれて無く申し訳ない感がありますが、、(講演者名など一応出してませんが出した方がいいんでしょうか…

自分の位置から何ができるのか、どういったやり方があるのかなど事例・例など聞けてこれを今後どう生かして行くか考えられるとても良い経験となりました。