読者です 読者をやめる 読者になる 読者になる

ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

「Regional Scrum Gathering Tokyo 2015 Day1」レポート

2015/02/28に開催された、「Regional Scrum Gathering Tokyo 2015 Day1」レポートです。
Regional Scrum Gathering Tokyo 2015: Schedule

スライド資料に無い説明を中心にまとめています。ぜひスライド資料を併せてご覧ください。

【参考】としている個所は私が挿入しています(補足や参考資料など)。発表者の意図したものではありませんので、その旨ご了承ください。

[1A-1]アジャイルRCA(Root Cause Analysis) アジャイルに無駄とその原因を見つけてカイゼンしていこう

永田 敦(ソニー株式会社)

現時点で発表資料(スライド)は見当たらなかったのですが、ほぼ同じ資料がありましたので、ご紹介いたします。
http://www.jaspic.org/event/2014/SPIJapan/session1C/1C3_ID024.pdf

はじめに

レビューにアジャイルの手法を取り込みたい。

要因分析は英語でRCA(Root Cause Analysis)と呼ばれている。

リーンスタートアップでも、なぜなぜ分析が取り上げられている。

なぜなぜ分析をなるべく早いタイミング、できれば開発段階で実施したい。

なぜなぜ分析の問題点

1. 時間がかかる

説明資料を設計者に作らせる(2時間以上)
  ↓
分析ミーティング(2時間)
  ↓
ミーティングを踏まえて追加資料の依頼(最初に戻る)
トータルすると8時間以上かかる。

2. ストレスを感じる分析

なぜなぜ分析では個人を攻撃してはいけないというが、「なぜ」という言葉自体に人を攻撃する強い力がある。口調をどれだけ優しくしても人を責めてしまう感は回避できない(部長から「なぜ?」と言われてプレッシャーを感じずにいられますか?)。

なぜなぜ分析はTPS(トヨタ生産方式Toyota Production System)の製造ラインから生まれた。この時、欠陥は物理的な問題であり、「なぜ?」の対象は現場のモノだった。
だが、ソフトウェア開発現場で欠陥はバグであり、「なぜ?」の対象はそれを埋め込んだエンジニアとなってしまう。

「なぜ?」という詰問に対し、問われる側は防御モードに入ってしまう。
結果、自分の答えを正当化しようとし、真の要因ではなく、見かけの要因にたどり着いてしまう。
これを「なぜなぜしりとり」と呼んでいる。

見かけの要因にたどりつくと、もやもやしたり、あいまいな結論となる。
例えば、レビュー不足とかテストの問題とか。
この結論に対処しても結果は出ない(見かけの要因だから)。

イテレーティブRCA

改善策としてイテレーティブRCAに取り組んでみた。
短い時間で毎日やる。イテレーティブRCAループを回していく。

初日は何が起こったかをヒアリングする。
翌日までに質問を考え、問いかける。後はこの繰り返しとなる。

時々次の質問をうまく出せないことがある。
質問を出せないのは「なぜなぜテンプレート」がツリー構造になっているためではないか?と考えた。そこで、ネットワーク型の欠陥モデルを導入した。

【参考】
スライドで引用されている欠陥モデリングの資料です。
「過失に着目した欠陥のモデリング~バグ分析はなぜうまくいかないのか?~」
http://www.jasst.jp/symposium/jasst13tokyo/pdf/C4.pdf

欠陥モデリングの定義で誘発因子は周囲の環境のこと。

インシデント分析ループで15分。
探索的分析ループで15分。

分析チームの担当者とは情報を出してくれる方を指す。

インシデント分析では傾聴・パラフレージングが有効。
パラフレージングとは相手の話を自分の言葉で言い換えること。
言い換えることで、聞かれる側は傾聴してくれていると感じ、自分も理解が深まる。

探索的分析で1回にかける時間を短くする。そんなにテンポよく質問は出せない。
白熱しても30分を上限とする。

欠陥モデルを作成することで、以前の欠陥モデルとの類似性が見えてくる。
また、問題をモデル化することで共有できる。

作成した欠陥モデルをチーム内で合意する。
欠陥モデルと質問をベースに探索的分析ループを4回程度回す。

対策ループは開発者自身に考えさせる。
上からの押し付けでなく、自分で考えたことはコミットメントできる。

事例

QAがあるGUIの振る舞いを障害として報告した。
仕様策定者はこの振る舞いを当たり前と考え、仕様書に記載しなかった。
設計者(仕様策定者とは別)は仕様書に無かったため、機能を実装しなかった。

仕様策定者にとって、当たり前のことを書くモチベーションはない。
でも、設計者には伝わっていない。
⇒これで良いのか?

仕様策定者と設計者の間で当たり前が共有できているのであれば、仕様書に書かないことは過失ではない。
今回の場合、仕様策定者と設計者で判断基準を共有できていないことが問題。

アジャイル暗黙知によるコミュニケーション。
暗黙知からの差分しか話さない。だからミーティングが早い。
だが、暗黙知には齟齬が出る。これがアジャイルの危険性でもある。

今回の事例では以下の対策をとることになった。
・ポリシー(振る舞いの判断基準)のドキュメントを作成する
・仕様策定者が仕様書に理由や背景を記載する

品質保証が今回の事例についてなぜなぜ分析すると、仕様の細かいところを記載する、という結論にたどり着いてしまう。今回の結論にはたどり着けない。

ファシリテーションのコツ

振り返りは担当者だけで行ってよい。全員で行う必要はない。
全員への共有はKPTで行う。

欠陥因子を探る時は言い訳をじゃんじゃんさせる。
自分がコードを書いたのか、他人のコードの改修なのかを明確にする。

言ったことを欠陥モデルで見える化する。
欠陥モデルを作成することで、バグを作った本人も客観的に見れる。

スクラムで一番大切な事はチームのメンバーをヘルシーにすること。
休日出勤なんてもってのほか。

プロセス改善は担当者だけでなく、チームで取り組んでも良いかもしれない。

モデルの知見が集まると、モデリングがスピードアップする。

自分のチームで起きていることは他のチームでも起きている。
共有することで未然防止ができる。

Q&A

Q.
振り返り結果の共有はどのようにすれば良いか?
A.
欠陥モデルとその作成過程を説明する。

Q.
イテレーティブRCAで取り上げる課題はどのように選べばよい?
A.
やりたいものからやればよい。
最初はリーダーやマネージャが課題を取り上げ、チームメンバーから自発的に出るようになったら移譲するのも手。

参考

リーン・スタートアップ

リーン・スタートアップ

[1C-2]開発モデルの作り方~守破離の破!~

藤村 新(GMOインターネット株式会社)

自己紹介

言い続けていれば夢はかなう!
パリス・ヒルトンにだって会えるさ!(スライド2枚目の写真)
言い続けることが大切。

守破離とは

破での「原因と結果をつなげる実験」とは、少しだけ変えてみたらどうなるか?と試すこと。
スクラムは原則を守ることが大切。それは破の段階でも同じ。

俺の守破離

とりあえずやってみた(お試しフェーズ)

アジャイルサムライは読みやすい本なので、読むとわかった気になるが、実際にやってみると分かっていないことが分かった。

プラクティスを実践(プラクティス厨)するだけでもダメだった。

プロセスの理解とスキル取得は異なるもの。
野球のルールブックを読むだけで野球がプレイできるようになるわけではない。

本質を理解した上でプラクティスの実践を行うことが大切。

試行錯誤を重ね辿り着いた破の境地

オフショアチームの見積もり精度は低いが、ザックリ開発工数であれば見積もり精度が高かった。そこで、完了係数を導入することにした。
完了係数=サイクルタイム/ザックリ開発工数
現在、完了係数が2.5ぐらい。
つまり、ザックリ開発工数で1週間といわれたら、完成までに2.5週間かかると予測できる。

RFCモデル

リーン開発のカンバンをベースに、OngoingをRFCに分けた。
Rough(ザックリ開発フェーズ)
Fill(完成度を上げるフェーズ)
Closing(完成させるフェーズ)

開発モデルを作るということ

自己流と破との間には越えられない壁がある。
形を持つ人だけが形を破れる。

Q&A

Q.
守破離で触れたように試すには勇気が必要だと思うが、どうやって乗り越えたのか?
A.
会社員の身分なら失敗しても失うものは限られているし、やればいいじゃないか!

Q.
オフショアとのコミュニケーションはどうしている?
A.
現地の日本語をしゃべれる方を採用しているため、言葉の壁はあまり問題にならない。

参考

今回の公募セッションに応募したきっかけになったとして紹介された、おさかなさんのエントリです。
さかな前線 » 「アジャイルなオフショア開発」というお話を聞いてきた

以下、発表の中で取り上げられた本などです。

スクラムガイド(日本語版)

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

[1C-3]分散開発チームによるアジャイル開発実践~いろいろハマった!よかった~

井口 誠(Kii株式会社)

Kii Cloud

モバイルアプリ開発にはサーバ開発が必須(ユーザー管理やデータ管理など)。
Kii CloudではモバイルアプリにSDKを組み込むことで、用意されたサーバ機能を利用できる。

もやっとAgile期(スクラム導入前)

スクラム導入前でも開発は回っていたが、「もやっと」感があった。
⇒Scrumの考え方で色々解決するかも!!

スクラム導入期

スクラムで理想的なメンバー数は5~9人。それに対してメンバーは全体で30人以上いた。
⇒各チームから代表者を出し、スクラムすることにした(Scrum of Scrum)。

開発チームが世界各地に散らばっているため、デイリースタンドアップでは時差の問題が発生する。
⇒参加メンバーからアメリカを外すことで回避した。

スクラム+カンバン期

タスクボードが実作業工程とズレている。あるタスクが「Ongoing」だったとして、それは実装中なのか、テスト中なのか?
⇒カンバンを導入し、Ongoingを細かく分割した。

スプリントエンドで必ずリリース可能な状態に持っていくという制約は苦しい。
⇒この制約を外し、必要なものがそろった時点でリリースするようにした。結果としてお客様にも好評を得た。

内部ドキュメントをベースに外部ドキュメントを作成していた。これだと、外部ドキュメントの完成が遅れたり、仕様変更を反映されないケースがあった。
⇒実装者に外部ドキュメントのドラフトを執筆してもらい、これをベースに加筆修正及び翻訳することで対処した。実装者がドラフトを書くことで、仕様変更も反映されるようになった。

Tips

スクラム導入により仕事の区切りがあいまいになった、という意見が複数人から挙がった。
⇒リリース毎に社内で「お疲れ会」を開催することで、区切りを実感できるようになった。

Q&A

Q.
ベロシティは測定しているか?
A.
ベロシティは測定していない。今のところ、プランニングで問題は出ていない。

Q.
誰がプロセス改善を進めているのか?
A.
プロセス改善をスクラムマスターが提案したり、各チームリーダーからの提案を採用したりしている。

[1A-4]自己組織的なScrumチームの目指し方

土肥 拓生(株式会社レベルファイブ

ゲーム開発のあの会社(株式会社レベルファイブ)とは違うよ。妖怪ウオッチとか知らないよ。
所属はこっちです(株式会社レベルファイブ | インフラネットワーク構築・アウトソーシングならレベルファイブへ!)。

エンジニアが自社・顧客先・SIerと各社に分散しており、方向性もバラバラ。まったく自己組織的でない。

社内勉強会を開催した目的の一つが、各社に散らばったみんなを集める場とすること。
普段は30分×2発表だけど、LT5分にすると発表してくれる方もいたりする。
同僚から人に興味がないでしょ、と言われて、どうしたら興味を持てるかという話をした方もいる。

プログラミングコンテストのプレゼントは自腹を切っている。
その分、社内調整不要でユルユルとできる。

MBB(Management by Belief)はMBO(Management by Objectives)と両輪の関係。
目標だけでは疲弊してしまう。

【参考】
MBBとMBOの関係について解説しています。
ITレポート(キーワード3分間講座) - MBB:ITpro

自己組織化には個人とチームの成長が必要となる。

チームの主体的・共同体・自己組織的の間に明確な区別はないのかもしれない。

個人とチームの成熟度は関連しており、越えられない壁がある。
個人があるレベルに達していなければ、チームとしても行動できない。

【参考】
セッションの最後に「自己組織化プラン」と題し、各自のチームの現状と今後どうしたいかを4人程度で話し合う、という時間がありました。
そこで同じグループだった人材育成の部門にいる方のお話が中々面白かったので、紹介しておきます。

組織を変えるには危機感と安心感が大切と考えている。
危機感はこのままではいけない!という思い。
安心感は自分の思いを伝えても大丈夫な環境だ、という思い。

話をする場として飲み会は一つの手。
ただ、飲み会が苦手なメンバーもいるかもしれない。
そのような場合はチームメンバーで話し合ったり、ワールドカフェ形式にして4人程度で話し合っても良いかもしれない。

[1A-5]XP Never Dies ~あなたがXPを学ぶべき108つの理由~

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

XPはプロペラ帽子と密接な関係がある。「XP プロペラ帽子」で検索!

【参考】
検索結果がいまいちだったので、平鍋さんのブログを引用します。

プロペラ帽はハッカーの象徴です。XPではシンプルに朴訥なコードが逆によしとされるため、難しいトリッキーなコードを書いた人は、ハッカーの称号とともに、このプロペラ帽が与えられ、罰として、これをかぶっていないといけないのです。

XP 祭り X に参加して、XP白本読書会の前説やりました。:An Agile Way:ITmedia オルタナティブ・ブログ

スクラムは悩むことで道を見つけていく。
XPは決まったことを実践する。

スクラムはスプリント毎にリリースするというプレッシャーがある。
XPはイテレーション毎に決めればよい分、プレッシャーが少ないかも。

XPのペアプロを一人で実践していた。
15分はドライバーをし、次の15分はナビゲーターをする。これを一人で繰り返した。
タスクボードだって一人でやってもいい。

アジャイルコーチは重要。いれば心強いし、スピードも上がる。
でも、いなくても実践はできる。

XPを適用しない基準は明確で、XPの価値と企業の価値が異なる場合。

スクラムとXPにはバージョンアップにも違いがある。
スクラム:抽象的な項目が追加される。
XP:実践的な内容が取り込まれる。

Q&A

Q.
永和システムマネジメントに入社当時、XPを導入していたチームが楽しそうに見えたわけは?
A.
チームの活気と遊び心。
CIとパトランプを組み合わせたりしてた。

Q.
チームの活気を出すには?
A.
振り返りにドーナッツを差し入れる事。実践したチームに話を聞くと、これまで振り返りはちょっと嫌な時間だったが、楽しみになったとの事。
周りを巻き込むような楽しさ。

Q.
チームへのアジャイル導入はどう進めればよい?
A.
まずは一人から始めても、いきなりチームに導入しても良いと思う。

Q.
XPはどこから取り入れたらよい?
A.
できることから取り入れれば良い。一人で始めてもいい。
開発者ならペアプロやテストコードを書くことから始めてもいい。
マネージャなら1週間の計画から始めてもいい。

所感

 今回の参加を通して感じたことは、スクラムを導入したチームでは同じような悩みを乗り越えた経験があるという事でした。藤村さんと井口さんがOngoingを分割したり、井口さんと西村さんが「リリース可能な成果物」へのプレッシャーについて触れたり。これからスクラムを導入する方にとっても悩むポイントとなりそうです。
 今回のような、悩みの乗り越え方のヒントを共有できる場があるのはいいなと感じました。また、このエントリもその一助になれば幸いです。

発表資料(スライド)


と言った手前、まとめてみました。他にもご存知の方がいましたら、ぜひご一報ください!

[1A-1]アジャイルRCA(Root Cause Analysis) アジャイルに無駄とその原因を見つけてカイゼンしていこう

※今回の発表資料とは異なりますが、ほぼ同じ内容でしたので、ご紹介します。
http://www.jaspic.org/event/2014/SPIJapan/session1C/1C3_ID024.pdf

[1B-2]スクラムマスターはじめのいっぽ

[1C-2]開発モデルの作り方(守破離の破)

[1E-2]100円プロトタイプ(The $1 Prototype)

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

[1C-3]分散開発チームによるアジャイル開発実践~いろいろハマった!よかった~

[1A-4]自己組織的なScrumチームの目指し方