SCRUM BOOT CAMP THE BOOKの感想
まとめ
今回の感想は、まずまとめからやっていこうと思います。本書に出てくる主人公の気付きが末尾にまとまっていたので、主人公の気付きを中心に各章の感想は下記に記載します。
本書を読んで感じたのは、SCRUMを組むことは「不確実性」をチームで取り除く作業なんだと思いました。例えば、Aという機能（サービス）を作りって欲しいと言われた際に、その機能には複雑なビジネスロジックがあったり、データがバッチ後のデータを使わないといけない制約があったりと作ってと依頼されてから要件定義だけでは気がつかない要素がたくさんあります。開発後半になって、開発初期の頃は気がつかなかった要素が実は他機能に影響するため、追加改修が必要。。。でも、時間がないとなってしまうケースは良くあります。
その解決策（傷口が小さいうちに対処する）として、事前に気がつけなかった要素に一番最初に気がつき、カイゼンできるのは実際に開発しているメンバーであり、現場の気付きをチームやステークホルダーに伝えるための仕組み（手段）がSCRUMだと思いました。
つまりSCRUMがうまくいっているチームというのは、チームメンバーがプロダクトの発展を望み、それが阻害されるような不確実性に立ち向かっていくことができているチームの状態を「うまくいっている」というのだと気がつきました。そのため、開発スピードが速いとか最新の技術を使っているなどはチームの本質を示すのではなく、チームメンバーがプロダクトの発展を望むからこそ生まれる副産物なのだとわかりました。
ソフトウェア開発は開発者こそ主役だからこそ、開発者の気付きとプロダクトオーナーの思いを結びつける方法として、SCRUMを後いた開発手法を極めようと思いました。
＊本書を読んで、現在プロジェクトのリーダーとしてSCRUMで開発をしているプロジェクトの成果をどこかで発表したいと考えるようになりました。
ロールは単なる目印
アジャイルな開発に慣れている人だけで、チームを組んで開発することでメンバーが各のロールを理解して作業をしてくれると思う。だが、実際問題それは理想であって、チーム発足時や初めてのアジャイルな開発では、ロールを理解して作業などはできないと思います。だからこそ、ロールを理解してくれる人にはしっかり役割を与えるようにはするが、できない部分はチーム全体で補うことがSCRUMでの開発の一歩。
＊プロダクトオーナーとスクラムマスターは分けた方がいい。
お互いに思っている方向性が異なるため。
プロジェクトを進めるうえで大切だと思うことはなんでも話し合っておく
自分が開発しているものが、ユーザにどう使われるのかを分かっていないと開発していてもモチベーションを上げられないし、開発に対する責任を持つことができません。開発メンバーに自発的に開発してもらうためにもプロジェクトの悩みや決まり事をしっかりと共有することが大切。
まずは、チーム全体の方向性やゴールを大枠から共有していくことが必要であり、そのために、インセプションデッキなどは有効的である。基本的に下記のテンプレートを用いてインセプションデッキは作っています。
スクラムチーム全員がプロダクトバックログについて知っておく
開発メンバーが自主的に開発するためには、何をしないといけないのかをチームとして共有する必要がある。そこで重要になってくるのがプロダクトバックログです。インセプションデッキなどで全体のゴールイメージは共有できていても、作り方。。。つまり、実際の実装方法（詳細）は明確になっていません。だからこそ、常にチームとして作業は抽象的でもバックログとして書き出し、それを細かく分解していくことが必要なのです。バックログはそのきっかけになります。
抽象部分の分解をチームメンバーで行い、細かな作業にすることやバックログに優先順位をつけることもチームの責務として行うことで、開発の見通しをつけることができます。上記を開発メンバー抜きで行うと必ず、計画と実態の解離が生じる。そのためにも日頃の作業や開発要件などをチームで共有するためにもプロダクトバックログ管理と共有は必須です。
私はJIRAを用いて、バックログを管理しています。また、朝会を行い全体での共有やメンバーにバックログの作業から何をするかを決めてもらっています。現在はバックログのより詳細な共有（中身やバックログの内容ができる背景）を行う方法を模索中です。
見積りは推測
スプリント計画時に厳密な見積りを出すことがゴールではなく、スプリントを通じて開発状況の共有、共に解決することをゴールとするために、不確実なこと（正確な見積り）に対しプライオリティを高くするのでなく、全体としてある作業に対しての目安をつけることこそ必要なんだなと思いました。
開発に対して絶対はないからこそ、チーム開発として何がゴールなのかを見極める必要があると思いました。ゴールは見積りでないのは明らかです。
自分たちの作業は自分たちで見積もる
見積りをすることがゴールではなく、チーム全体で対話をするためのツールなんだと思いました。例えばプランニングポーカーを行った場合に、チームのメンバー間で数字が合わない場合は、話し合いのサインで、もしかしたら依存関係が多くて開発より影響調査やテストが大変とか。。。。実はそこで利用するコード（一部のメソッドなど）がスパゲティコードなのでそもそも理解するのが大変とか。。。一部の人しか知らない情報だったりするかもしれないため、全員で見積もりを行うことは、チーム内でコミュニケーションを活発にするツールであり、最終的にチームとして見積りのゴールを決めれればいいのだなと思いました。
ベロシティがわかれば、プロジェクトの先が見える
チームとしての作業能力はベロシティで測る。不確実な未来（開発完了時期）に対して、比較的正確性が高い指標として間違いなくベロシティは存在するため、過去を見て未来を推測する最善の方法です。
スプリント計画ミーティングでは確実に終わらせられる計画をつくる
詳細を作っていくのが開発チームの役割であるからこそ、スプリント内の計画はより詳細でゴールを定義することができる。例えば、OOの機能を作ってCIでグリーンを出るようにして、プルリクエストを送るなど。バックログの作業をより分解して、分解した作業を確実に完了させる定義を作れる。だからこそ、確実に終わらせる計画をチームで決めていく必要がある。
スプリントのゴールは守るために毎日検査する
ベロシティで未来を測定するからこそ、スプリントを守る必要があります。スプリント期限が違うと、ベロシティから未来を予測することができなくなってしまう。だからこそ、スプリント期間内で、当初予定していた作業が完了できなくてもその結果をチームで話し合って今後の改善点を見つけていくことに使っていくことこそ、SCRUMの本質だと気がつきました。
完了の定義は、スクラムチームで合意する
ここは一番知りたいところでした。厳密にはレトロスペクティブのやり方とかを知りたかったのですが、スプリントのふりかえの際にスプリント計画でタスクにしていたことが何を持って完了したのかを、どうチーム間で共有するのかと思っていたのですが、結局開発したものでしか完了したのかを客観的に伝える方法はないとわかりました。
だからこそ、スプリント期間が終わるまでに毎回動くものでスプリントの計画が達成できたかを測り、それを行うために開発チームとしては、その達成をできるために何をしなければいけないのかと考えていくことで、チームとして完了を定義できるのだとわかりました。
もちろん、開発規約を作ることもmustで必要だと思いました。
問題になる前に見つけて対応する
問題になってからだと、問題の根本を解決するのって難しいなと思っていました。よく障害報告書などを読んでも、原因として書かれていることが本当の原因でなく、根本原因から生じた副産物である場合は多くありました。
だからこそ、「あれ」と気が付く仕組みと「なんかおかしい」を言える環境を作ることがSCRUMをうまくまわすには必要なことだと気がつきました。
現状はJIRAを用いてバーンダウンチャートを作っています。まだまだチームとして未完成ですが、朝会やインセプションデッキなどをもっちいて「あれ」と思った箇所は早急に、チームでMTGをするようにしてます。ますは問題の顕在化をすぐにできるような仕組みづくりを目指しています。
タイムボックスに入るようにしていくのが重要
ベロシティで未来を推測するためにも必要なことです。スプリントが計画通りできないかったこともチームとして受入、カイゼンすることがSCRUMの本質だからこそ、タイムボックスを守ることは必須です。
プロダクトバックログの順序は常に見直していく
バックログを書くことと優先順位をつけることは別のことであるからこそ、バックログ作成はできる限り多くの人にやってもらいたいです。バックログを書くつまり開発するものに期待をしている人たちなので、ここが多ければ多いほど開発側もモチベーションになります。ですが、そこから開発する際に順序立てられてないとただのカオスになってしまいます。
だからこそ、プロダクトバックログに対して順序を付けれる人はプロダクトオーナーだけにしておくことが必要です。さらに、実際に開発が進むにつれて要望が具体的になったりとするので、常にバックログに対してチームで意識することが必要です。急な計画変更にもチームとして対応ができるように。
自分たちの責務について理解しないとうまくいかない
開発をしていると、もっとこうした方がいいのにとか現状の構成に対して意義を唱えたくなる場面に出会います。その際に、改善案として更新後のアーキテクチャを用いて、エンジニア同士で話し合うことがあります。話し合ったところで、元々のアーキテクチャに関わっている人がその場にいないと机上の空論を話しているだけになってしまいます。つまり、チームとして何も改善できていない状態になってしまいます。だからこそ、チームメンバーがそれぞれの責務を認識して、
メンバーが解決できない問題はチームで
チームで解決できない問題はステークホルダーを交えて
のように、責務を担っている人とそれに関わる人を交えて、コミュニケーションを取っていくことが必要であると感じました。
ベロシティはあくまで目安
これは非常に難しいなと思いました。何が難しいかというと、ベロシティから未来を予測すると学びましたが、ベロシティはあくまでも過去のスプリントの事実をポイントとして示すだけであり、未来を100%示すことができるツールではないことを認識することでした。
チームはスプリントを通じ成長します。ベロシティだけを見ているとチームの成長は見えにくくなってしまうかもしれません。だからこそレトロスペクティブや不確実性に直面したときのメンバーの対応を見ていくことで、チームとしてうまくいっているのかをベロシティ以外の側面で感じ取る必要があるのだなと思いました。
ロールで担当する部分を分けているので、どこに問題があるかわかる
ロールはあくまでも目印だからこそ、ロール単位での問題はチームで解決していこう。その際に別のロールをになっているメンバーが支援をしても全く問題ないし、チームだからこそ積極的に問題をチームで解決していくことが必要。
頻繁に話し合って伝えていくのが一番大事
やってほしいこと（要望）を伝える人は多いけど、なぜそれをやるに至ったかの経緯を伝える人は少ないなと思います。だからこそまずはチーム間でも頻繁に話すことは必要だと思います。
また「なぜそれをやるに至ったかの経緯」を本書では「意図」とし、ユーザストーリーを通じて、チーム間で共有をしていた。ユーザストーリーのテンプレートは下記になります。実際に活用しようと思いました。
＜どういったユーザーや顧客＞として
＜どんな機能や性能＞がほしい
それは＜どんなことが達成したい＞ためだ
スクラムマスターがスクラムチームを良い状態に保つ
第三者の立場って非常に重要なんだと思いました。実際にプレーヤーとして参加していると目線が直近の部分しか見えなくなってしまいます。だからこそ、1つ上のレイヤーから下のレイヤーを俯瞰することで、問題を認識させることができるのだと思います。
だからこそ、スクラムマスターは問題を解決するのでなく、問題を解決をしていくメンバーが問題に気が付くように支援をしていく存在なんだと思いました。
妨害はリストにして、どれを優先的に解決するかを明らかにしておく
問題を忘却させないことがここでの教えだと思いました。もちろん、問題が解っても解決策が決まってないと、実際にアクションをすることができません。ですが、解決策がすぐに出るとも限りません。だからこそチームで解決策を模索する時間は必要だし、それ時間をスプリント中に組み込ませることは必須です。つまり、チームとして良い状態を作れない原因を管理し、その問題をタスクへとすることでチームとして、妨害を乗り越えていける。
妨害を忘れないように、カンバンボードに記載するという取り組みはいいなーと思ったので、現場でも取り入れようと思いました。
プロジェクトの進む先をいつも明確にするために整理し続ける
ここでの教えは、見積りは一度したら終わりではなく、できる限り見直すことでチームの進むべき道を定めようでした。そのために、プロダクトバックログの管理として下記に取り組もうと記載されていました。
重要なことを見逃さないために順序を見直す。
見積もりを最新にする。
プロジェクトの進む先を整理するために順序をもう一回見直す。
プロダクトをよくしていくためにカイゼンしてくのは、チームも同じでありそれは、日々のタスクにも通じるものだと感じました。
スプリントの準備はプロジェクトをうまく進めるうえで不可欠
スプリント中に次のスプリントのことを考え、準備するのって難しいですよね。でも難しいというのは多分、不確実な要素が非常に多くて、詳細に落とし込めていないために生じているのかなと思います。
ですが、まだここでのいいやり方を見つけてないため、今度の私の課題かなと思っていますが、まずはCI/CD、TDDの導入、ユビキタス言語の作成など開発（ビジネスロジック部分）以外で時間をかけないためにも周辺の準備は先に行い、開発（ビジネスロジック部分）とスプリントの準備に時間を使っていきたいです。
実現方法を工夫するのはスクラムチームにとってやりやすい調整の仕方
問題の解決策として本書では下記の2点を上げています。
スクラムチームが今よりうまく仕事を進める
何かを調整するしかない
どちらもすぐにゴールに近づけるわけではないとしている。そしてゴールに近づくためには、何かを諦める必要があるとも記載されています。
つまりプロジェクトとは、実現したいことと諦めの間で成り立っているのだなと思いました。全ての要望を含めることはできない。でも求める物を提供するために開発を進めるからこそ、この葛藤は永久になくらいが、それでもチームでカイゼンし、ゴールに向かっていくことこそチームとして仕事をしていくことなんだと思いました。
全員で様々な状況を克服できるようにしていく
SCRUMでの開発では、基本的に横断的に作業を行うため、得意分野のみやっていくことはないと思います。だからこそ、チームメンバーのスキルや経験をチームが把握している必要があると思います。できることをチームで共有し、できないことはできる人から教わったりたまには頼ったりしながら、個人のレベルアップが結果チームのレベルアップへとつながるのです。
チームで事前に話し合っておいた方がいいこととして、下記をあげています。
これまでどんなプロジェクトにいたか
自分が仕事をする上で大切にしていること
自分に期待されていることとはなんだと思うか
責任を持って取り組めるようにして、良いスクラムチームを少しずつ築き上げていく
実際に作業を行わない人の意見はあくまで参考に聞く。これは非常に納得しました。結局プロダクトに対して責任を持つのは、開発メンバーだからだ。
現場を知らない人の意見に左右されるのでなくチームとして、所属するメンバーが作業にコミットメントして、不確実な部分はチームで話し合うこれが鉄則。それで、失敗したら次は失敗しないようにチームでカイゼン（失敗を学びに）をしていけばいいこと。そのためにも、メンバーが責任を持って前向きに開発ができる状態を維持することは非常に重要なんだなと思いました。
何でもリリーススプリントに回すのは良くないこと
やっぱりアプリ開発なんかをしていると、動かすこと（機能開発）に集中してしまい、リリースに対して意識をしなくなる経験は多々あります。だからこそ、初期の段階でリリースの仕組みをチームに導入することを個人的には心がけています。若干Clean Architectureの考え方に反するかもしれませんが、テストがあれば一度CIの仕組みを確立しても、まだ別ツールへの移行は可能かと思っています。個人的にはCI部分はツールに依存する可能性が高いので詳細と認識しています。。。そのためClean Architectureの詳細の決定を遅らせる考えに反するかなと思っていますが、本質としてはテストできてリリースをいつでもできる状態のコードは手元にあって、それをどのツールでも少し設定をいじれば設定できるのあれば、開発初期の段階でCI/CDを導入してしまうのも現状のベストを行っているだけで、必要があればすぐに変更できる状態は維持できるはずです。よって、私は開発の初期段階で CI/CDはしっかり取り決めよう派です。
Scrumは体験して学んでいくための仕組み
少しレトロスペクティブについて触れていたので、そちらのことを記載します。ここで驚いたのは、下記の部分です。
スプリントレトロスペクティブは問題解決のイベントじゃないんだ
つまり、チームのメンバーが自ら仕事の進め方をいつも良くしていけるように頭を使っていく場らしい。その結果として、問題解決をしているのはいいと思うが、問題解決が上位に来て、それのみを行うことはレトロスペクティブの本来の姿とは違う。これを知れて本当によかったです。個人的にSCRUMの一番のポイントは、振り返りと問題点の共有にあると思っているためです。
この記事が気に入ったらサポートをしてみませんか？