プロダクトオーナーの煩悩: スクラムの価値基準

| 3 min read
Author: kazuya-nakamura kazuya-nakamuraの画像

はじめに

#

中村です。社内開発でプロダクトオーナーやってます。
開発現場での悩みや気づきなど、わりと赤裸々に書いていきます。

まず前提として宣言します。当案件、あまりスクラムとして円滑に回っていません。故にナレッジ、事例としての公開に二の足を踏んでいた(だってカッコつけたいじゃん)のですが、それも含めて透明性かな?と腹をくくり公開に踏み切りました。同様の悩みを抱えるチームの人体実験先例になれば幸いです。

ちなみにチームの現状です。

  • プロダクト
    • 社内利用ツールを内製開発(2020年~継続中)
    • 基本機能は開発完了、運用・保守開発フェーズ
    • 基盤はEKSを利用したマイクロサービスアーキテクチャ
  • チーム構成
    • Dev:常任2名+スポット数名(新卒・中途採用社員などのトレーニング道場)
    • PO(私):開発部門からのProxy PO。各利用部門の要求をとりまとめる。顧客案件アジャイルコーチとの兼務
    • SM:不在。離任した先代SMが週一コーチ

…まぁまぁ不吉なワードが点在してますね;

それでは、今回のテーマは『スクラムの価値基準』です。

スクラムの価値基準…ってなんだっけ?

#

スクラム理論の3本柱に比べてチョット存在感が薄い気もするスクラムの価値基準、みなさん暗唱できますでしょうか。私はできません――ので、スクラムガイドから引用してみましょう。

確約(Commitment)、集中(Focus)、公開(Openness)、尊敬(Respect)、勇気(Courage)

言葉としては簡単だけれど、どこか崇高。実践するには敷居が高く、背中がかゆくなる感じ。特に、尊敬・勇気あたり。言うは易く行うは難し、といったところでしょうか。私自身、これをスローガンのように捉えていて、日々の開発で強く意識していませんでした。

停滞…うまく回らない

#

当案件、2023年は不穏なスタートを切り、停滞期に落ち込みました。主なきっかけはミドルウェアの更新対応。EKS(k8s)関連でいくつか破壊的な変更が含まれており、対応作業で本来の開発が全く行えない状態が続きました。1年先まで利用可能なバージョンに上げたものの、またトラブルや変更が出ないか不安はぬぐえません。スポットの開発者兼スクラムマスターとして活躍してくれた教育グループの 高さん が離任し、実質スクラムマスター不在となったタイミングでもありました。

目に見えてプロダクトやスケジュールに悪影響は出ていないけれど、閉塞感と不安が常に付きまとう。ならばあるべき状態、ベンチマークはないかと頭を抱えながらスクラムガイドを見直したとき、本節が目に留まった次第です。

スクラムガイドをよみなおす

#

スクラムガイド(2020年版) を読み返すと、「スクラムの価値基準」の項は以下のように始まっていました。

スクラムが成功するかどうかは、次の5つの価値基準を実践できるかどうかにかかっている。

…スローガンなんてとんでもない。逆に言えば「実践できなければ失敗する」ってことです。つまり必ず整えるべき、前提条件です。これらの価値基準に照らし合わせることでチームの現状を検査できるのでは?と考えました。

価値 内容
確約 スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する
集中 スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する
公開 スクラムチームとステークホルダーは、作業や課題を公開する
尊敬 スクラムチームのメンバーは、お互いに能⼒のある独⽴した個⼈として尊敬し、⼀緒に働く⼈たちからも同じように尊敬される
勇気 スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ

ふりかえりで見返す

#

週一でふりかえりを見てもらっている社内コーチに相談したところ、こんなフレームを作成してくれました。5つの価値基準に対して、できていると思う/できていないと思う、をエピソード付きで記入するスタイルです。

ふりかえりテンプレート

当チームではふりかえりにPOは参加しない(プロジェクトメンバーの評価者でもあるので、心理的安全性から)ので詳細はコーチからの伝聞になりますが、ひとまず一定の効果はありました。個人名や具体的なプロダクト内容の記述もあるので低解像度での紹介となりますが、価値基準に照らすことでチームの状態が見える化されました。

主な課題認識と議論の焦点は「勇気」でした。EKSの保守(現状維持)による人手不足が課題としてフォーカスされたことは予想どおりです。しかし、そこからの掘り下げ「保守が追いつかなくなればシステム停止影響もあり得る。予算の制約は理解しつつ、リスクはビジネス側へ共有した上でQCDS優先度を再定義する必要がある」はまさに「勇気」であり、私の想定を超えた議論でした。そしてこれは同時に「公開」に紐づく課題とも取れます。

見逃せないのは、ほとんどの価値基準では「できていると思う」が優勢…つまり「わりと良い」チームであるという点です。それでも保守負担のような外因や、ステークホルダーとのコンフリクトによって一部の価値基準が損なわれていました。つまり5つの価値観はスクラムチーム内の精神的な指標だけでなく、生産性と創発性を維持するためのマネジメント上の指標でもあることがわかります。

これらの価値基準は、スクラムチームの作業・⾏動・振る舞いの⽅向性を⽰している。下される意思決定、実⾏される⼿順、スクラムの使⽤⽅法は、これらの価値基準を減少や弱体化させるものではなく、強化させるものでなければならない。スクラムチームのメンバーは、スクラムのイベントや作成物を⽤いながら、これらの価値基準を学習および探求する。これらの価値基準がスクラムチームや⼀緒に働く⼈たちによって具現化されるとき、経験主義のスクラムの三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築される。

「一緒に働く人たち」には、ビジネス側やスクラムチームの上長も当然含まれます。

(おまけ)調達――チーム編成のガイドラインとして

#

本稿ではスクラムの価値基準と、実践し続けることの難しさについて触れました。元々実践できていたチームですら、ときに困難な状況下では逸脱することもあるという実例です。これはチーム編成の上でも重要な要素です。マインドセット――人間の気質や価値観を変えることは簡単ではありません。これら価値基準に賛同し実践できるメンバーか、見極めてアサインする必要があります。

次回に続く

#

プロダクトオーナーの~と銘打ちながら、ちょっとPOぽくない話から始まってしまいました。
次回はPO関連の話題をしたいと思います。

豆蔵では共に高め合う仲間を募集しています!

recruit

具体的な採用情報はこちらからご覧いただけます。