スクラムの基礎理論~経験主義による最適化プロセス~
こんにちは、株式会社レキサスの新卒入社のまこつです。
スクラムで新規サービスの開発を行うレキラボについて週一でnoteを更新し始めて、一ヶ月以上が経ちました。早いものです。
新規サービスの幹となる機能もほとんどそろってきました。理解不足からローカルで動いていた機能が開発環境で動かない等はありますが、サービスが形になってきて、嬉しいです。
特に、試行錯誤して遂に動いた時は自然とガッツポーズをしてしまいます。いずれ、このnoteでもサービスの紹介をさせてください。
先週は、同期のアベルの方がDockerで構築したローカル環境の削除方法について記事にしました。
レキラボではLaradockで環境構築をしています。開発が進む中で、dockerの設定内容を変更した際に、そこで意図しない挙動が起きることがありました。
一つ一つ、設定を見直しながら修正する方法もあるのですが、一度ローカル環境を作り直した方が早いこともありました。こうしたDockerのローカル環境の削除方法を知りたい方の参考になれば嬉しいです。
そして今回は、技術的なことというよりもスクラムの開発手法についてです。特に、スクラムの中心的な理論を『スクラムガイド』や実際にレキラボでの取り組みで感じたこと、考えたことを元にまとめていきます。
経験的プロセス制御の理論
スクラムの原典である『スクラムガイド』においてはスクラムは経験主義を基本としていると書いてます。
スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。
経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。
『スクラムガイド：スクラム公式ガイド ゲームのルール』
経験主義とはなんでしょうか。体感としては、「実際の経験と既知に基づく判断によって知識が獲得できる」という文言がしっくりきます。
スクラムでは、最初から完成した知識やノウハウを正確に運用することは厳格には求められていないと感じます。
それよりも、自分たちの取り組みについて定期的なチェックや振り返りを繰り返す中で、少しずつ全体像をクリアにして、課題があれば改善し、良い取り組みであれば仕組み化して開発を進めます。
そして、経験とその振り返りにより開発チームが自発的に学習し成長するというのがスクラムにおいて最も基礎的な価値観(信念?)なのかなと思ってます。
例えば、僕自身も、このnoteを書き始めた一ヶ月前は、開発技術、スクラム等の開発手法、仕事の進め方等など何もかも知識もスキルも不足していました。
でも、二週間に一度のレキラボの全体の定例MTGで、その二週間の振り返りを行う中で、スクラムマスターの小林さんや先輩から、仕事の進め方や技術的なアドバイスをもらっています。
それを次の二週間の開発に反映させる中で、一つ一つ取り入れて改善していくことで、チームとしても個人としても成長を感じています。
このような経験から得た知識や学習による作業効率の向上を定期的に次の開発計画に反映させること、そして新しい情報が出てくれば認識をアップデートすること、それがスクラムにおいて非常に重要なことだと思います。
透明性・検査・適応の3本柱
次に、スクラムの三つの柱について紹介します。
『スクラムガイド』によれば、上記のスクラムの経験的プロセス制御の実現は、透明性・検査・適応の三つの柱によって実現されます。
透明性：経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。
検査：スクラムのユーザーは、スクラムの作成物やスプリントゴールの進捗を頻繁に検査し、好ましくない変化を検知する。ただし、頻繁にやりすぎて作業の妨げになってはいけない。スキルの高い検査担当者が念入りに行えば、検査は最大の効果をもたらす。
適応：プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断した場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
『スクラムガイド：スクラム公式ガイド ゲームのルール』
透明性、検査、適応は、言葉だけ見ると少し硬い印象を受けるかもしれません。
ただ実際の開発プロセスに落とし込んだ場合は、透明性は、プロダクトやチームに関する情報を必要な人がアクセスできるようにオープンすること、ドキュメントの形式で情報や意思決定プロセスを残すこと、プロダクトバックログで残すこと、全体に発表すること、などの活動のことなのかなと思いました。
このnoteも、先輩方やレキサスを応援してくれている方、全く初めての方にレキラボの活動をできるだけ知ってもらいたいという想いから始まったのですが、透明性に少し貢献できているのかもしれません。
次に、検査です。
検査は、定期的なプロダクトのビューや振り返り会でやっています。また、個人のレベルでは日報の中で振り返っています。
ある一定期間の開発の進捗や、チームや個人としての進め方をKPTで振り返り、それに対して、チームメンバーや先輩方、スクラムマスターからアドバイスをもらっています。
また、開発の途中でも、このままではやばいと感じたら、アラートを投げ、どうすれば改善できるかを話し合います。
検査は、ある程度の時間がかかるので、一旦は開発スピードが落ちるように感じますが、その分だけの改善があるので本当に大事です。
最後に適応です。
実は、適応は、現状に適応するという意味である種ポジティブに考えていました。
でも、『スクラムガイド』の「プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断した場合」という言葉、そしてスクラムマスターの方に「計画の見直しは最後の手段」と諭してもらったことなどにより自分の認識を改めました。
最初の見積もりの精度が低いと、計画と実績の解離がおき、計画の見直しが必要だと感じることが多々あります。
ただ、その場合でも、なんとかこのタスクを消化することができないか、周りの知識を借りられないかなどして、どうにか消化することを第一に目指します。
そうしないと、全体のスケジュールがどんどん先延ばしになり、また自分たちのマインドも、リスケができる前提になってしまいます。
そういう意味でも、適応は環境に適応する意味ではポジティブなのですが、自分たちのマインドや限界をそこで止めてしまわないように注意が必要です。
書ききれなかった内容と後書き
以上が、『スクラムガイド』とレキラボでの経験から学習したスクラムの基礎理論についての自分なりのまとめです。
今回書ききれなかった内容として、確約(commitment)・勇気(courage)・集中(focus)・公開(openness)・尊敬(respect)などのスクラムの価値基準があるのですが、また機会があればまとめていきます。
後少しでレキラボの活動も一区切りつくのですが、もっともっと学びの角度を高められるようがんばります。
今後とも、レキサス、レキラボをよろしくお願いします。
参考：
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf