はんなりと、ゆるやかに

アジャイル、スクラムが好きなITエンジニアが日々から学んだことをアウトプット

スクラムのDoingとBeing

先日の勉強会(1on1のやり方とあり方)で1on1をDoing(やり方)とBeing(あり方)に分けて説明がありわかりやすかったです。

なるほどなるほどとおもったので、スクラムをDoingとBeingに整理してみました。

Don't just do agile. Be agile. です。Beingが大事とよく言いますが、BeingだけじゃなくてDoingも大事ですよ!

Being

経験主義

スクラムの基礎となる考え方です。プロジェクトの開始時は分かっていないことが多いので、計画を立ててもその通りに行きません。予想外のトラブルでスケジュールが遅れたり、サービスを開始してから製品にニーズがないということもあり得ます。

特にスクラムは複雑で変化の激しい問題に対応するためのフレームワークです。世の中わからないことだらけなので小さく早く試して経験を積んで軌道修正しながら進んでいきましょう。ということですね。

スクラムの3本柱

透明性

情報の透明性
ゴールだったり、問題だったり、現状だったりあらゆることをすべての人が把握できるような状態を保つことが大切です。経験を積むためにも情報の透明性が必要です。

関係の透明性
人の関係にも透明性は重要です。責任を明確にしたり、お互いの得意不得意が明確になっていると助け合いが生まれます。

それぞれの透明性が高くなると自己組織化されたチームになっていきます。

検査

やりっぱなしにせず、検査をして経験したことを今に活かしましょう。

適応

検査で見つかった異常や良い兆候を改善します。


高い透明性のもと検査→適応を繰り返して経験主義を活かしましょう。

価値基準

確約(commitment)

スプリントで合意して決めたことは確約された認識で取り組む。ただ、状況も変わって約束を守れないこともあるので、ニュアンス的には献身のほうが近いです。決めたことには最善を尽くしましょう。

勇気(courage

問題を報告したり、この期間ではできないと言ったり、リスクを取ったコミュニケーションをする勇気が透明性を担保するためには必要です。

集中(focus)

近くのことに集中しましょう。遠い先の計画は変わることが前提なので不確実性の低い直近のスプリントに集中しましょう。

公開(openness)

良いも悪いも含めて透明性を高めるために公開する習慣を持つこと。簡単そうで難しい。

ティール組織で言われる全体性(Wholeness)も近い価値観だと思います。自分本来の姿を公開することでチーム力アップに繋がります。

尊敬(respect)

開発に関わらず日常でも尊敬は大切ですよね。お互い尊敬しあうことで、馴れ合いもなく、いがみ合いもないコミュニケーションが取れます。

自己組織化

スクラムで目指すチームです。一人ひとりが誰かの指示ではなく自分の判断で動ける状態を目指します。

自己組織化を機能させるには、明確なゴール、自分の活躍する場の把握、現状の把握が大切です。

自己組織化が進むと無秩序になります(みんなが思い思い動きますしね)。メンバーをコントロールしたいマネージャーから見るとまとまりのないチームに見えるかも知れませんね。

けしてマネージャーの思い通りに動いてくれることが自己組織化ではありません。

機能横断的

製品を作るために必要な技術がそのチームで揃っている状態です。オールマイティが揃ってるチームじゃなく、得意分野がバラバラでもみんなの力で製品が作れればそれでOKです。

Doing

ロール(役割)

役割ごとに責任を明確にして責任の透明性を向上させています。

プロダクトオーナー

製品の価値を最大化するために作るものを明確にする役割です。

スクラムマスター

開発における障害物を除外する役割です。ティーチングやメンタリング、コーチング、ファシリテーションを使い分けながらチームが価値を出せるようにする役割です。

開発チーム

製品を継続的に作り続けて進化させる役割です。スプリント中のスケジュールは自分たちで管理します。プロダクトオーナーやスクラムマスターは管理しません。

作成物

ゴールと現状を明確にして透明性を向上させます。
野球のスコアボードのようにパッと見て状況が把握できるレベルがいいです。

プロダクトバックログ

製品に必要だと把握しているものの一覧。優先順に並べて作るべきものを明確にします。
一覧の一つひとつのものはプロダクトバックログアイテムと呼ばれます。

スプリントバックログ

今回のスプリントで達成すべきプロダクトバックログアイテムを詳細にした作業一覧です。

インクリメント

作っている製品そのもの。少しずつ増やしながら作るからインクリメントと呼ばれる。と僕は思ってる。

インペディメントリスト(障害リスト)

スクラムガイドには書かれてないが重要なリスト。開発の障害になることをまとめます。

イベント

検査、適応を繰り返してチームに学習を促す仕組みになっています。

スプリント

開発するための1週間や2週間などの固定期間です。この単位で以下のイベントをしながら、製品を作ります。

スプリントプランニング

今回のスプリントで何を作るか、どう作るかを決めます。具体的にはプロダクトバックログの上からどこまで作れるかを決めます。

その後、どう作るかを決めてスプリントバックログを作成します。

デイリースクラム

毎日決まった時間に集まってスプリントが正しく進んでいるか検査します。問題が見つかったらただちに適応します。

スプリントレビュー

スプリントの最後に完成した製品を検査し、次に作ることに適応します。

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

プロダクトバックログの見積もりをしたり、並び替えたり更新して最新の状態を保ちます。

レトロスペクティブ

人・関係・プロセス・ツールの観点から今回のスプリントのふりかえりを行います。

さいごに

スクラムをBeingとDoingにわけてみました。BeingのもとにDoingしていくと自分たちにあったスクラムになるんじゃないかなって思います!

本記事はスクラムガイドを参考にしました。https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf