【メモ】チーム・ジャーニー第7話本読み会
情報の透明性
「透明性が高い」とはチーム活動の中で何が起きているのか、プロダクトはどのような状態になっているのかという把握が容易になっている状態のこと
重要なことは「外に対する透明性を高める」を意識的に実施すること
外に対しては意識的に実施しないと分断が起きやすい。開発チーム内よりもコミュニケーション頻度が少ないため分断が起きやすい。
「線表」による共通理解
調べるとガントチャートが出てくる。意図と異なるようだ。項目の大きさに注意が必要。
補足いただきました。
重要なことはA4サイズ 1枚に納まること。プロダクトバックログの粒度では細かすぎる。もっと大きい単位で書くことだそうだ。
誰が何をやるか、順序依存などは記載しないもっと大きな単位と思う。
私はチーム内外の双方に対して有効と思います。
線表は「計画を作り守るもの」解釈が暗黙で入りそうだ。ウォーターフォール型開発があるほどそうかもしれない。
計画を作るためのものではない、意思の見える化である。
「こうするつもり」「こうしたい」「いつまでに終わる」などの意思表示。
スクラムでは、スプリントプランニングによるタイムボックスごとの計画がある。スクラムガイドに記載がないがリリースプランニングも実施するケースが多いのではないかと思う。これに加えて別口でもう一つ計画つくるの？！と思うかもしれない。そうではない。
意思表示・表明をチーム内外で見える化する。
線表はスプリントプランニングに同期しよう。
私の経験（前職）
これまでの経験で類似ケースがなかったかふりかえってみた。
すると前職のリリースプランニングの一部で同じようなものがあったことを思い出した。（スクラム開発ではない。ソフトウェア開発チームだけで完結する場合はアジャイルっぽかったが、機械メーカーだったため、機械、電気、ソフトチームがいて、内容によって順序依存があるため全体で見るとウォーターフォール型っぽい開発になっていたような気がする）
プロジェクト開始するための稟議申請の項目。
いつまでに何が終わる計画か程度の図。
EXCELで簡単につくったものだ。（X軸に時系列、Y軸に項目)
こんな感じだったと思う。
これにより関係者（上層部や品質保証部門などの横の部門）がいつごろまでに何が終わるかを把握できるというもの。
当時、書類を作成した際に「こんなにざっくりでいいのか」と先輩に相談したが、上や横の人たちは細かすぎると分からないから「これくらいでちょうどいい」と助言いただいたのを思い出した。
「遅延したらどうするんですか？」と聞いたら、「一定期間ごとに更新する」と話していたような気がする。（そもそも予算が足りなくなるため継続するには上と話し合って延長申請したはず。その時点で同期するタイミングがあったはず。）
「機能Bを先につくってもいいの？」とアホっぽい質問をしたところ、実際に「やり始めて分かることは多い。現場の判断で変えていい」と言われたことを思い出した。経験主義的な発想だったことに何年も経過して今更気づいた。対外的に影響しない範囲であれば変えてよかった。
紹介書籍
ご紹介いただいた書籍。読んでみようと思う。
この記事が気に入ったらサポートをしてみませんか？