スクラム開発でお客さんとチームを組む上で意識したいこと
こんにちは、CX事業本部 IoT事業部の若槻です。
今回は、スクラム開発でお客さんとチームを組む上で意識したいことについてです。
前提
- 筆者の役割はエンジニア。スクラムマスターの経験なし
- スクラムの体系的な勉強をしたこともなし
- ここで書くのは、私が今までスクラム開発に参加し、お客さんとチームを組む上で意識したいなと思ったことです
先にまとめ
- メンバーに接する時は、チームの外での関係ではなく、チーム内での役割を意識する
- エンジニアから非技術者メンバーへのプロダクトの説明や見せ方を意識する
意識したいこと
プロジェクト外での関係によってひとの呼び方を変えない
自社のメンバーや部下だからといって○○（呼び捨て）と呼ばない。○○さんとさん付け呼ぶ。
同じチームの中ではメンバーはあくまで対等な関係です。プロジェクトの外の関係を持ち込む必要はありません。
（そもそもスクラム関係なく、公な場ではさん付け呼びが常識になりつつあるとは思いますが）
所属でなく役割、ひと
タスクの依頼時に、
（NGな例）
このタスクは○○（会社名、部署名など）側でやって頂きたいです。
という呼びかけは避けるべきです。チーム開発を行っているのは、会社や部署ではなく各自が役割を持った個々のひとです。
所属（例：クラスメソッド）ではなく、役割（例：エンジニア）やひと（例：若槻さん）を主語にして呼びかけを行います。
（OKな例）
このタスクはエンジニアの方にやって頂きたいです。
便宜的に所属で呼ばざるを得ない場面もありますが、意識したいことではあります。
PBIの優先順位は必ず決める
スクラム開発では、プロダクトの開発はアジャイル的に行うため、PBIに積んだことがすべて達成できるとは限りません。よってすべてのPBIに優先順位を付けて、エンジニアは順位の高いものから対応をしていきます。
しかしスクラム開発に慣れていないプロダクトオーナー（お客さん）の場合は「ここからここまでのPBIはマスト要件なので優先順位は付けられない」と優先順位付けに何色を示される場合もあります。マスト要件としたい範囲がスケジュールに収まりきらない場合に取捨選択をするのなら分かるが、明らかに収まる範囲なのにあえて優先順位を付ける意味が分からないためです。
この場合は、優先順位を決める議論をすることにより、おのずとMVPが明確になり不要または過剰な機能が洗い出せるなどの副次的なメリットがあることも合わせて伝えて、粘り強く必要性を説いていくしかないです。
技術的な説明はチームメンバー全員が分かるように抽象化する
プロダクトオーナー（お客さん）は基本的には非技術者です。よってスクラムイベントのようなチームの全員がやり取りを行う場では、エンジニアはプロダクトについての説明や会話をする際に技術的な具体化をどこまでするべきかを意識するべきです。
しかしお客さんによっては、「この機能ではバックエンド側ではAPI Gatewayで受信したデータがLambdaで処理されます」なレベルの話が通用しその方が伝わりやすい場合もありますし、逆に「バックエンドって何？」なレベルの場合もあります。ここで大事なのは「チームメンバー全員に通用すること」ですので、メンバーの技術的背景を図りつつ臨機応変に対応します。
目に見えるものを早く作る
画面を伴うアプリケーションを実装する場合に、非技術者であるプロダクトオーナーがプロダクトの価値が上がったかどうかの判断基準とするのは主に目に見える部分の実装です。
よってPBIである機能をアプリケーションに追加する場合に、画面と内部処理の両方の修正が必要な場合は、画面の修正を優先して行いPBIの最中にでもプロダクトオーナーに画面を確認してもらった方が、PBIを達成した際のイメージをしてもらいやすくなり、軌道修正も早い段階で行えるようになります。
おわりに
スクラム開発でお客さんとチームを組む上で意識したいことについてでした。
実際に実行に移せているか、またチームメンバーへの働きかけが出来ているか、というと必ずしもそうではないですが、スクラム開発を行う上で心に留めるようにはしています。
参考
以上
