スクラムマスダーの日記

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

アジャイルの良さを伝えるのって、どうしたらよいのだろう?

久しぶりのブログです。
気がつけば、2017年の1月も下旬と、日が経つのは早いです。

さて、この数ヶ月間、社内において、論文の作成と発表に色々と時間を使いました。そのため、ブログの更新頻度下がった感は否めませんが…。

論文のテーマは、「アジャイル開発」で、アジャイルを会社に広めるために、色々と試行錯誤しながら、取り組んだと思います思います。

単に社内有志の勉強会ではなく、最終的には、社長をはじめ、幹部の方々に自分の企画や思いを伝えることができる機会であるため、非常に良いものだと個人的に思っています。発表や質疑応答を含めて、30分間、会社の幹部が20代の若手の話を真剣に聞くって、なかなかないと思います。

内容はブログに書くことはできませんが、「熱い想いは伝わった」とは、講評でいただいたので、多少なりとも頑張った甲斐はあったと思います。

アジャイルの良さを伝えることは、なかなか難しいです。

それでも、アジャイルの成功率を少しでも上げるための努力を今回の論文で、できたと思います。
一般社団法人 PMI日本支部 アジャイルプロジェクトマネジメント研究会の「アジャイル プロジェクト マネジメント 意識調査報告 2015」では、アジャイルソフトウェア開発宣言を知っているかどうかが、アジャイル導入と成功の鍵だとあります。
論文発表では、アジャイルソフトウェア開発宣言を会社の幹部の方々に知っていただきました。

これからも、社内外問わず、地道に活動していきたいと思います。

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時が過ぎた頃、解散しました。

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

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