スクラムマスダーの日記

アジャイル、スクラムに関連した内容が多めです。

2016年をふりかえってみた

2016年もあと一週間ということで、この1年をふりかえってみたいと思います。

ゲーム系の勉強会

今年は、勉強会をかなり頑張りました。きっかけは、ゲーム系の勉強会でした。

参加ブログ書いたりもしてます。

scrummasudar.hatenablog.com

scrummasudar.hatenablog.com

私自身は、ゲーム系開発に携わっていませんが、同じエンジニアとして学ぶべきことは多かったです。
会場側のスタッフとして、色々と参加させていただき、色々な方とお会い出来たことも、非常によかったです。

IDDD読書会

色々な勉強会に参加したする中で、「自分たちで勉強会を開催しよう!」ということになり、IDDD読書会をはじめました。

iddd.connpass.com

IDDD読書会では、『実践ドメイン駆動設計』を読み進めており、現在13章の途中まで読み進めました。あと、2回くらいで、一冊おわりそうです。

DDDは難しく、なかなか理解が深まらないですね・・・。

今後、『エリック・エヴァンスのドメイン駆動設計』をきちんと読み直したいと思います。

アジャイルラジオ

2015年からはじまったアジャイルラジオは、配信されたらすぐ聞きました。
Twitterのハッシュダグ #agileradioをつけて、たくさんツイートしていると、スクラム道関西のみなさんにヘビーリスナー認定していただき、ラジオにもゲストとして出演させていただきました。

認定スクラムマスター

会社の支援もしていただき、認定スクラムマスターの資格を取得しました。
アジャイルラジオ、カンバン仕事術読書会への参加なども含め、普段からのスクラムの活動をしていたことも、色々な点でポイントだったように思います。

研修内容は、

にまとめていますので、認定スクラムマスター研修に興味のある方は、読んでみていただけると嬉しく思います。

Scala関西Summit

今年は、Scala関西Summitで、初めて多くの方の前でお話させていただく機会をいただきました。

きっかけは、Scalaもくもく会で、気軽に「初心者向けで、話しますよ〜」って言ったことでした。
資料作成は、会社の方にもお手伝いいただき、なんとか成功したように、個人的には思っています。

f:id:scrummasudar:20161225153117j:plain

WEB+DB PRESS Vol.96に、Scala関西Summitの様子が掲載されており、「僕、コレに登壇したんだなぁ〜。」って、2ヶ月たった今も、感慨深く思います。

そのた資格

2016年は、

  • LPIC レベル1
  • AWS認定ソリューションアーキテクト アソシエイト

の2つの資格も取得しました。例年に比べると、少ない気もしますが、LPICは、試験が2つあるので、そんなもんかなぁと思ったりもしています。

どんな勉強したかは、

scrummasudar.hatenablog.com

に、書いていますので、同じ資格取得を目指す方の参考になればと思います。

おわりに

今年は、技術者として、色々なことにチャレンジできた一年でした。
助けてくださったみなさまには、感謝しかありません。

2017年に向けても、既に色々と準備しており、1月から3月上旬くらいまでは、忙しい日々になりそうです。

それでは、2017年もよろしくお願いします!
年末までに、またブログを書きそうな気もしていますが!

認定スクラムマスター取得しました!〜研修3日目〜

前回のブログ

scrummasudar.hatenablog.com

の続きです。
今回で、認定スクラムマスター研修のブログは最終回です。

プロダクトオーナー

3日目は、座学から始まりました。2日目は、スクラムマスターについて、江端さんから教えていただきましたので、3日目は、スクラムの他の役割について、教えていただきました。

プロダクトオーナーの役割

プロダクトオーナー(以下、PO)の一番の役割は、スクラムチームのROIを最大化することです。ビジネスでの成功が役割ではありません。

ROIを最大化するには、コスト削減を徹底してから、リターンを考えることです。Valueも考えますが、中心となるのはコスト削減です。 コスト削減とは、人を減らすことではありません。時間、お金、手間、複雑性など、色々な観点があります。
具体例として、「セレモニーでの確認回数(PBLの確認など)を減らす」があります。
要求や要件を変えない限り、コストは大きくなります。POは、アイデアで勝負しなければなりません。

プロダクトオーナーの能力

POに求められる能力は、大きく2つあります。

  • 戦略に基づいた決断力
  • 決断するために必要な情報収集能力

です。

チーム

チームがやるべきこと。

  • スプリントで計画したことを実施する責任
  • 生産性を向上する責任…慣れたやり方を捨てる勇気を持つ
  • できないことを、できないということ

Doneの定義

Doneの定義とは、開発するときにすることすべてになります。

など、色々あります。
理想としては、Doneすることがリリースすることと直結していることです。スプリント終わりに必ずリリース可能な状態を目指します。
しかし、現実は、なかなかできないので、スプリント中でできることの"done"とできないことの"undone"に分類します。
チームの生産性向上は、ベロシティを安定させるとともに、undoneを減らすことです。

POはdoneを減らして、機能を増やす、つまりベロシティをあげようとしてくる可能性があるので、気をつける必要があります。
目に見える機能だけでプロジェクトが成功するとは限りません。リリース時に、いかに何が出来ているかが重要です。

undoeが1つ減れば、46%生産性が上がると言われています。undoneを減らすことは、生産性向上に直結します。

プロジェクトの進捗の把握

プロジェクトが遅れているのか、予定通りなのかを把握することは重要です。

リリースポイント ≦ (期待or実績)ベロシティ ✕ 残スプリント数

上記の計算式で簡単に求めることができます。実績のベロシティがわかっているチームであれば、あとどれだけでできるかすぐにわかります。そのために、チームの固定化が非常に重要です。

POが要求、要件を増やすのであれば、残スプリントを数を増やすか、チーム数(単にメンバーを増やすのではない)を増やすかをステークホルダーと調整する必要があります。

逆に、チームのミスで消化ポイントが減ったのであれば、残スプリント数で終わらせることができるように取り組む必要があります。典型的なミスは、バグです。バグの対応はundoneになり、リリースポイントを増加させます。

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

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

このあたりの詳しい話は、アジャイルな見積りと計画づくりに書いています。

マシュマロチャレンジ

チームでの作業を経験するために、マシュマロチャレンジをしました。ちなみに、私自身が、マシュマロチャレンジを実施したのは、人生で2回目です。

www.ted.com

ここでは、いかにマシュマロのことを考え、反復したチャレンジが必要であるかを気が付きます。
動画にもありますが、素晴らしい大学を出た人より、幼稚園児の方が優秀です!

セレモニー

スプリントプランニング

セレモニーでいちばん重要なスプリントプランニングです。
スプリントプランニングの流れは以下の通りです。

  1. POが実現したいことをチームに問う
  2. チームと合意する
  3. 事実に基づいて実施するため、実物を確認する。わからなければ調査をする。
  4. どのようなものを作るかデザイン、設計する。実現可能性がわかっている状態にする。
  5. 作業の分割をする。

スプリントは、陸上のスプリントと同じく走り抜けるということです。プランニングの途中で調整することがないように、スプリントプランニングで決めてしまえるようなチームが理想です。

スプリントプランニングで技術調査を基本的に終わらせたいですが、時間的に難しいときもあります。その場合は、プロダクトバックログでスパイクとしてプロダクトバックログアイテムを設けます。

プロダクトバックログリファインメント

プロダクトバックログリファインメントでは、中長期のスパンで再計画を行います。
undoneのリスク、現在のベロシティ、残スプリント数を確認します。このような情報をもとに、将来のことを考えるのです。

新たなプロダクトバックログアイテムが追加されているのであれば、見積りを行ったります。

スプリントレビュー

そのスプリントの成果物の確認をします。また、プロダクト全体を触り、新たなアイデアをだします。
プロダクトをもとに、将来のことを考えます。

POは、プロダクト自体を、スプリント中、いつ確認しても問題ありません。

スプリントレトロスペクティブ

スプリントレトロスペクティブの目的は、チームが生産性を向上するために、次のスプリントで行わければならない具体的なアクションを1つ以上決めることです。
このアクションは、スクラムチーム全員が把握できる必要があります。また、チームの実行したアクションについて検査する必要もあります。

スクラムマスターのスキル

スクラムマスターに必要なスキルは、5つあります。

  • Teaching
  • Facilitating
  • Mentoring
  • Coaching
  • Situationaling

研修では、これらのスキルを実践的な形式で学習するということで、研修参加者同士でグループを組んで、色々と実践しました。

Teaching

Teachingは相手に伝えて終わるのではなく、相手の記憶に残し、行動してもらう必要があります。
そのための色々な手法があります。

  • インパクトがあること
  • 抑揚があること
  • 勝負ポイントのあるストーリーがあること
  • 相手からの返事があること
  • 相手が覚えやすいリズムがあること
  • 質問があること
  • 相手の五感を使っていること
  • 相手を承認してあげること

などなどです。

ちなみに、二日酔いのときには、ブドウ糖がよいので、森永のラムネを食べるとよいと、教えていただきました!

Facilitating

Facilitatingは、議論のスタートからゴールまでを一直線で進むようにすることが求められる力です。

  • 相手の五感を活用する
  • 相手の言葉を聞き直す
  • 相手の話を止める
  • 話題を変える
  • 集団の思考性を利用する
  • いけにえを用いる

など、様々なテクニックがあります。

真にFacilitatingが上手い人は、ビリヤードのように、1人に話しかけると、次々に参加者が話し出すといった連鎖を引き起こすことができます。

Coaching

Coachingを練習するための3つの役割があります。

  • コーチ
  • シェーカー
  • オブザーバー

です。
コーチは、シェーカーの悩みを聞く役です。ゴールを相手に定めさせ、導いてあげます。ちなみに、メモを取ってはいけません。
また、シェカーの悩みを鵜呑みにして聞いてはいけません。悩んでいることが、本当に達成したいことがわからないからです。
「やせたい!」という悩みがあった場合、裏には「モテたい!」、「血糖値が悪くて・・・。」といった真の悩みを抱えている場合があるからです。そのために、最初の一言が重要です。「やせて、どうしたのか?」ということです。

さらに、コーチーはシェーカーに、自主性を損なわずに、達成できるイメージを持ってもらう必要があります。

Mentoring

Mentoringでは、相手からメンターと思ってもらわなければ、始まりません。相手から相談を受ければ、Mentoring開始の合図です。

相手に示唆や色々な選択肢を与えます。あくま判断するのは、相手です。

Situationaling

Situationalingは、今まで紹介した4つをいつ使うのかを判断するために必要な能力です。

相手の状況を常に判断する必要がありますが、集団の中の個人と個人の中の個人は違うということを意識する必要があります。

スクラムマスターの評価

スクラムマスターを評価するには、スクラムマスターチェックリストがあるので、使うとよいと言われています。
ただ、IT・システム系によった内容のため、会社ごとに合わせる必要があります。

スクラムでの見積り

見積りには、2種類あります。

絶対見積り

時間、長さなど他の人から与えられた基準をもとに、見積ります。全員が知っているからこそ早く話が進みますが、見積りとしては狂いやすいです。

相対見積り

自分たちで物差しを決めます。コンテキストを揃える必要がありますが、自分たちの基準で測るので、正確な見積りを出すことが出来ます。

プロダクトバックログの見積り

プロダクトバックログの見積りをするときには、相対見積りで行うことが一般的です。
初めて見積る場合、プロダクトバックログの中から、一番小さいプロダクトバックログアイテムを選択します。そのアイテムを2とします。
そのあと、4倍の大きさのプロダクトバックログアイテムを選択し、8とします。
この2つのプロダクトバックログアイテムをもとに、見積りを行っていきます。

ここで、よく使う手法がプランニングポーカーです。
プランニングポーカーは、1、2、3、5、8、13といった数字が書かれたカードを用いて見積る手法です。

プロダクトバックログアイテムの要件をPOから聞き、チームのそれぞれがタスク量を見積ります。
異なった数字が出た場合、

  1. 最も大きい数字を出した人が、意見を出す
  2. 最も小さな数字を出した人が、大きい数字の人との認識の違いを言う
  3. POに、どうしたいかを聞いて、プロダクトバックログアイテムの要件を明確にする

を行います。

よいプロダクトバックログは、INVESTと言われています。

  • I...依存しない(少ない)
  • N...交渉可能
  • V...価値がある
  • E...見積りが可能
  • S...手頃なサイズ
  • T...検証可能

ただ、依存は基本的にするので、依存の多さよりも、サイズの小ささを最初のうちは、意識した方がよいです。

ユーザーストーリーであらなければならない?

プロダクトバックログアイテムは、ユーザーストーリーである必要があるというのが、よく言われていますが、それより重要なのが、受け入れ基準(Acceptance Criteria)がきちんとあることが重要です。

まとめ

研修3日目は、スクラムマスターのスキルを高めるためのトレーニングや、最後は質問タイムがあるなど、非常に濃厚な1日だったように感じました。
ブログの長さが、どんどん長くなっていることが、学びの多さの結果のように思います。

最後に、スクラムは99.9%つらいと江端さんはおしゃっていました。まさに、私も同じように思います。
ウォーターフォールだと、最初の方は、まだまだ余裕があると思って、楽しがちですが、スクラムだと最初のスプリントから、製品並みの品質があるか、生産性はどうかなど、考えることが多すぎます。
ただ、スクラムマスターは、そのつらさを乗り越えるような、想像を超えるチームの成長を作り上げる必要があります。

研修の最後は、研修参加者とペアを組んで、秘密の握手をしました。どんな握手かは、秘密にしておきます。

研修終了後

研修が終わってから10日後くらいに、研修の合格メールが来ました。なかなかメールが来なかったため、心配症の私は、毎日ドキドキでした。話によると、やはり不合格の方もいらっしゃるようです。
過去の研修では、研修期間でスクラムマスターの素養があるかの判断をすることはなかったため、研修3日目の夜には、メールが来ていたようです。

研修に合格すると、ScrumAllianceで、テストを受験することができます。メールが届いてから90日間有効で、2回まで無料で受験可能です。2回落ちても、2500円程、支払えば、再受験可能です。
私は、なんとか1回で合格できました。

研修とテストの両方に合格することで、認定スクラムマスターになります。

おまけ

懇親会のお店

金曜日だったので、なかなかお店を確保することができず、桜坂へ。
普通のチェーン店です。

二次会は、大阪ばあるへ。
サングリアを、かなり飲んでた記憶あります。夜中の2時が過ぎた頃、解散しました。

懇親会は、江端さんとじっくりお話できる機会だったので、非常に有意義でした!

ということで、認定スクラムマスター研修編終わりです!!

認定スクラムマスター取得しました!〜研修2日目〜

前回のブログ

scrummasudar.hatenablog.com

の続きです。

今回は、認定スクラムマスター研修の2日目で学習した内容です。

研修で学習するアジェンダを決める

研修2日目の午前中は、研修参加者が学びたいかを洗い出し、学習するアジェンダを決めることに時間を使いました。

方法としては、

  1. 全員で学習したい項目を付箋に書き出す
  2. 付箋をグループ分けする
  3. グループごとの優先順位をつける

でした。
しかし、3に至るまで、4時間くらいは使っていたように思います。

時間通りに物事が進まなかったことは、決して悪いことではありません。 「想定した見積もりが悪かったのか?」、「単に時間がかかっていたのか?」など、理由は色々と考えられます。
それらの理由を考えるためにも、計測することが重要です。

議論がうまく進まなかった理由

アジェンダを決めるための議論がうまく進まなかった理由は、参加者の役割があいまいだったことが最大の理由だったように感じました。
議論においては役割は3種類あり、ファシリテーター、議事録、その他になります。
研修2日目午前において、ファシリテーターっぽい人と、議事録っぽい人はいましたが、それぞれの役割に期待していた内容が、参加者によって異なっていたと思います。
またその他の参加者も、とりあえず自分の思ったことを発言していました。もちろん、私もそのうちの1人でした。

果たすべき役割

ファシリテーター

ファシリテーターとは、議論のおけるゴールの明確化と確認を行います。現在地点の認識を持ち、参加者全員のすべき事を明らかにすることに責任を持つ。

議事録

発言内容を漏らさず、かつ内容を要約して、参加者全員が内容を理解し易くする責任を持つ。

その他

ゴールの実現に協力し、ファシリテーターが示す、すべき事に注力する。すべき事を実現、実行する為に最善を尽く責任を持つ。

f:id:scrummasudar:20161211213552p:plain

視覚化の重要性

人はパニックなると9割以上能力が下がると言われています。
そのため、いまパニック状態であるかどうかを確認、認識できるようにする事が大切です。議論ができていなければ、ほぼパニック状態といってよいでしょう。
パニック状態にならず、議論をうまくすすめるためには、視覚化が重要です。

視覚化という観点で、SYSTEM THINKINGという考え方があります。

www.youtube.com

SYSTEM THINKINGのくわしい内容は、上記の動画を見ていただければと思います。研修でも同じ動画を見ました。
人は、付箋やカードを使うと、論理的、明確に考えるようになります。
また、グループで一緒に作ることで、過程を理解し、グループ内での共通理解を得ることが出来ます。

「あれ」、「それ」など代名詞で話せるチームになれば、パニック状態になりづらくなります。

スクラムについて

最初に学習するアジェンダは、スクラムの基本についてでした。この段階にくるまで、1日半かかってました・・・。

スクラムは把握したいことをほぼ把握できる

プロジェクト把握したいことは、数多くあります。

  • 人・モノのリソース不足
  • プロジェクトの複雑性
  • プロダクト
  • 製品品質
  • 実現可能性
  • マーケット
  • テクニカル品質

など、例を挙げればキリがありません。
スクラムは、プロジェクトで把握したい98%のことを把握できると言われています。
残りの2%は、マーケットのような問題を解決してはじめて分かることです。スクラムは、問題を解決する手段ではないため、問題を解決して分かることは対象としていません。

アジャイルスクラム

アジャイルは、2001年11月に誕生しました。
アジャイルの一種と言われているスクラムは、1993年7月、新薬開発で利用され、論文で発表されています。
スクラムの方がアジャイルより歴史があるのです。
スクラムを知るには、Core Scrum 2014を読むことが大事です。

アジャイルスクラムへの誤解(ドキュメントがいらない、ウォーターフォールより低コスト・短納期で開発できるなど)を、拭うことは、できないと江端さんはおっしゃっていました。
2016年11月10日時点で、スクラムを教えることができるスクラムトレーナーは世界で182人しかいません。
一方、アジャイルスクラムについて、ブログや本を書いている人は、私も含めて、何人いるかわからないほど、数多くいるためです。

最近、DeNAなどのキュレーションサイトが話題になっていますが、問題の本質は同じだと思います。

スクラムの弱点

スクラムは常に万能ということはありません。もちろん、弱点もあります。

弱点1:チームの生存期間が3ヶ月未満の場合

期間が短いと、チームの文化を作ることが出来ません。チームでの知識や技術が活用されないためです。

弱点2:プロダクトが単純であること

プロダクトの複雑性が低い場合、スクラムでは有効ではありません。

f:id:scrummasudar:20161211231406p:plain

ただ、プロダクトが単純であることは、基本的にありません。リリース後のバグは、プロダクトの複雑性の象徴です。

弱点に当てはまる場合のするべきこと

スクラムの弱点に当てはまる場合は、カンバンを採用するのがよいと、江端さんはおっしゃっていました。
ただ、スクラムを続けるのか否かを決定するのは、スクラムチームです。
他の方法があることをスクラムマスターは提案する必要はあります。そのため、スクラムマスターは、ウォーターフォールも含め、色々な方法論を知っている必要があるのです。

スクラムが流行った理由

スクラムが流行った理由の2位は、「みんながやっているから」です。
他の人がやっているからやらなければならないという集団心理です。

そして、流行った理由の1位は、「売れるものを作る必要があるから」です。
昔は、とにかく作れば売れる時代がありました。日本でも、高度経済成長期やバブル時代は、まさに当てはまると思います。
しかし、今の時代は、マーケットを考慮し、売れるものを作る必要があります。
ROIのRもIも変動する要素ではありますが、Iはコントロールしやすいものです。 ウォーターフォールでは、鉄のトライアングルのスコープを固定し、納期と費用を変動させてきました。スクラムでは、納期と費用を固定化し、スコープを変動させ、マーケットと勝負する方法です。

一流のスクラムマスター

スクラムマスターについては、以下の言葉がよく言われます。

1つのチームを回せないのは、三流のスクラムマスター
複数のチームを回すのは、二流のスクラムマスター
1つのチームを回せるのは、一流のスクラムマスター

通常であれば、1つのチームより複数のチームを回せる方が優秀なように思えますが、スクラムでは、スクラムマスターは各チームに1人置くということが鉄則です。
複数のチームを持っているということは、スクラムの原則に反しているのです。1つのチームを回しているということは、他のチームにスクラムマスターがいるように組織に対して、きちんとアプローチしたスクラムマスターであるという証拠なのです。

自律的なチームであるということ

スクラムでは、自律的なチームになることが重要とされています。
プロダクトオーナーやチームが、「自律的なチームを目指すぞ!」と感じる必要はありません。スクラムマスターが、自律的なチームの状態にさせる必要があるだけです。
ただし、3ヶ月経過しても、自律的なチームにならなければ、スクラムマスターはもちろん、プロダクトオーナー、チームともに、責任があります。

自律的なチームになるには、チームメンバーが固定化されていることが重要です。自律的なチームに人を追加すると、文化が壊れてしまうからです。
プロジェクトのメンバーを増やしたい場合は、既にあるチームではなく、新たなチームを作ることがポイントです。

自律的なチームの要素

自律的なチームである要素は3つあります。

  • (チームの)ゴールが明確であること
  • (個人が)ゴールを達成するために、何をすべきか、すぐに判断し、行動していること
  • (チームの)バウンダリーが明確であること

の3つです。

この中で一番重要なことは、「バウンダリーが明確であること」です。
バウンダリーとは、法律、会社のルールといった静的なモノと、他の人の作業をやらないこと、チームで決めたルールなどの動的なモノの2種類あります。
明確であるとは、チーム内での認識が同じであるということです。ただ明文化されていることではありません。

"Say its done"を許さない

人は出来ていないことでも、出来ている、"Say its done"と言います。
プロジェクトの進捗で、進捗が80%までは順調に進んでいるにも関わらず、最後の方になると、なかなか100%にならないことがありますが、まさに"Say its done"の典型です。

もちろん必ず嘘をついているというわけではありませんが、スクラムでは動くものを確認することで、"Say its done"という状況を許容しないです。言葉ではなく、モノで確認するのが、スクラムです。

おわりに

研修2日目は、議論の進め方を学習したこともあり、後半はかなりスムーズに議論をすすめることができたように思います。
その結果、スクラムについて、江端さんから色々と教えていただき、理解を深めることが出来ました。

おまけ

懇親会のお店

研修2日目の懇親会のお店は、播鳥 西中島店でした。
4,000円のコースで、大満足でした。 [

私より年齢の若いスクラムマスター経験ありの参加者の方と、色々とお話しました。
東京は、20代でもスクラムマスターとして活躍されている方が、たくさんいるようです。
大阪では、全然見かけないので、頑張って増やそうと思います。増やしている間に、私が30歳になってしまいそうですが!

二次会は、串のきっしゃんでした。こちらは、参加してないですが、1日目に大阪ではじめて串かつを食べた方も多く、好評でした。