運用業務とスクラムは組み合わせにくい、相性が悪いという話をよく耳にします。
しかし、プロダクト開発をするうえで運用業務は切り離せません。

このセッションでは、プロダクトを継続的にユーザーに届けるためには切っても切り離せない運用業務をスクラムでどう扱うとよいのか、ところどころで必要な判断をどう考えて行ったのか、わたしたちの試行錯誤にプロダクトオーナーの視点を交えて紹介します。

また、タイトル内にある問い「運用業務とスクラムは組み合わせにくいのか？」に対するわたしなりの回答である「そんなことはなく、うまく組み合わせることはできる」に至った理由についてもお話します。

ーーー
プロダクトにはライフサイクルがあります。これにはいくつかのフェーズがありますが、後半のフェーズになればなるほどいわゆる運用業務が増えていく事が多いです。

このセッション内では下記のような、システム運用・保守業務や業務運用をまとめて運用業務と呼びます。
身に覚えがある業務も多いのではないでしょうか。

• 定期的におこなう証明書更新
• 定期的におこなうソフトウェアのアップデート
• 需要に応じたキャパシティの拡張やライフサイクルへの対応
• 負荷が高くなるイベントへの事前準備と対策
• ユーザーからの問い合わせへの対応
• 突発的に発生する障害やインシデントへの対応とその対策

私は2年間、新旧2つのヤフーを支えるプラットフォームのプロダクトを担当しているチームのプロダクトオーナーをしています。
それぞれのプロダクトは2年間の中でプロダクトとしてのフェーズが変わり、その中でやりたいことや求められていることも変わっていきました。

• 新プロダクトは導入期〜成長期
  • まだ足りていない機能もあるのでもっと開発を進めたい
  • 多くのユーザーに使ってもらうため、機能要件の拡充を求められる
  • 成長期に入ると、これからユーザーが増えていくということで安定稼働も求められる
• 旧プロダクトは成熟期〜衰退期
  • 成熟期の間はまだより便利に使ってもらうための機能追加などを行いたい
  • ユーザーの課題を解決するために、プロダクトとして開発を行うことも求められる
  • プロダクトが衰退期に入っても、まだまだ利用者は多いため安定稼働を求められる
  • 同時に、衰退していくプロダクトにはコストを掛けたくないため、コスト削減も求められる
  • プロダクトの規模が大きく運用業務や障害も多いため、対策をしたい

新プロダクトでも約4割、旧プロダクトにおいては8割以上が運用業務。決して少なくない（むしろ多い）量の運用業務をおこないながら、それぞれのプロダクトで求められることにも応えていかなければなりません。

このような状況の中で、プロダクトが置かれている状況を見極め、開発チームと一緒に運用業務への取り組み方を検討したり、プロダクトオーナーとして判断をしたりを繰り返してきました。

プロダクトの状況ごとに、その運用業務とどう向き合ってきたのか。

• 運用業務をバックログ内でどのように扱っているのか
• プロダクトオーナーとして運用業務と開発業務のバックログの優先順をどのように決めているか
• スクラムチーム内の運用業務（運用フェーズのプロダクト）と開発業務（開発フェーズのプロダクト）の割合をどのように決めているのか

などの試行錯誤の一部と今後やっていきたいことについて、うまくいったこととそうでないことの両面からお話しようと思います。

また、タイトル内の問いへの私なりの回答についてもお話します。

運用業務とスクラムは組み合わせにくいのか。

試行錯誤を経た私なりの回答は、「そんなことはない。運用業務とスクラムはうまく組み合わせることができるのではないか、むしろその方がメリットがあるのではないか」です。

試行錯誤のなかでは下記のような気づきを得ました。

• ただの運用業務に見えるものも、視点を変えればインクリメントのある開発業務にできる場合がある
• スケジュールありきの運用業務は、無理にバックログで扱わないでスプリントを固定するとうまくいきそう
• 運用業務と開発業務の優先順を判断するためには、単純なインクリメント以外の軸をつくるのがよさそう
• ステークホルダーからのプロダクトに対する期待に応えるためには、運用業務と開発業務の量をある程度コントロールする必要がある

そして同時に、これらは運用業務とスクラムは組み合わせにくい、相性が悪いと言われる要因（課題）を取り除くヒントにもなっているのではないかということに気がつきました。課題を解決できるならうまく組み合わせられるだろうし、スクラムのメリットもより活かすことができそう、と思い回答に至りました。

そんなに単純ではないかもしれないですし、課題がすべて解決したわけでもないですが、運用業務とはまだまだこれからも長く付き合っていかないといけないので、よりよくしていくための挑戦はこれからも続きます。

同じ課題を持った人にとって、なにかの参考になったり、自分たちもチャレンジしてみようと思ってもらえたら嬉しいです。

ある日突然、プロダクトオーナーになる。そんな経験をされている方も少なくないと思います。

プロダクトオーナーは、スクラムチームに一人しかいないプロダクトに対する責任を持つ、とてもたいせつな役割です。
ですがその分、役割についた人は不安もたくさん。何をしたら良いのか、何が正解かもわからない。

プロダクトオーナーはスクラムチームの一員なので、チームがいい状態でいられるためには、プロダクトオーナーの言動はとても大切です。
でもそう思うとなかなか行動に移せない、なんてこともあると思います。

本セッションでは、私自身がプロダクトオーナーとして他のスクラムチームメンバーと一緒に、いいプロダクトやチームを作っていくために普段「とりあえず」おこなっていることをお話します。完璧でもなんでもない、でも少しだけ人間味がある（かなと私自身は思っている）ような行動です。

また、そんなプロダクトオーナーの行動は他のメンバーからどのように見えているのか、どう感じられているのかを、同じスクラムチームのメンバーからの生の声としてお届けします。

プロダクトオーナーなりたて当時の自分含め、不安でいっぱいのプロダクトオーナーや、プロダクトオーナーをやっているけれどなんかうまくいかないな、という方にとって、自分でもできそう。やってみようかな。と思ってもらえたらうれしいです。

ヤフーにはたくさんの社内プラットフォームがあります。
私もそのうちの1つを担当していましたが、そのプロダクトはある別のプロダクトの後継となることが決まっていました。

後継であるということは、旧プロダクトで求められていたことを新プロダクトでも求められますし、逆に旧プロダクトでの課題が新プロダクトで解決されていることも望まれています。この期待に応えられるプロダクト開発をおこなうため、新旧プロダクトを担当していた2つのチームは、戦略として1つのLeSSチームで2つのプロダクトを担当することを選択しました。

新プロダクトを作りはじめたチームと、旧プロダクトを運用しているチームは、それぞれにスクラムをおこなっていましたが、その雰囲気は対照的でした。

• 一方は、かろうじてスクラムの枠組みには沿っているが、完成の定義なども決める前段階の緩くインクリメンタルな開発を行おうとするチーム
• もう一方は、3チームによる LeSS をおこない、プロダクトを安定運用するための様々なルールに沿って開発運用を行うチーム

2つの異なるスクラムチームが一つになることは、簡単ではありませんでした。
特にそれぞれが対照的な雰囲気のチームだったことや、それぞれが今までと変わらずなプロダクト運用も求められる中でのチームの合体だったため、課題も多かったからです。

いざ一緒になることが決まり、プロダクトオーナーになることが決まった私は、旧プロダクトの LeSS を見て複数の違和感を持ちました。

• ルールに縛られた軍隊チックなチーム体制
• プロダクトについての議論がされ、ルールばかりが追加される振り返り
• 誰に何を届けたいのかがわからないスプリントレビュー
• プロダクトオーナー以外、誰も優先順を認識していないバックログ
• 判断がプロダクトオーナーに一任されるコミュニケーション

一方で新プロダクトのチームには別の課題がありました。

• 全員がスクラム経験者ではあるものの、人数が増えて LeSS をおこなうことへの漠然とした抵抗感
• 完成の定義などの決めごとがほとんどなく、チームの変化に弱いプロダクト品質
• チームの人数が少ないことで担保されていた共通認識や前提知識が成り立たなくなる課題

私自身にとっても LeSS ははじめてだったため、旧プロダクトの現状を見て単純に LeSS についての知識が足りていないから違和感を持つのではないか？と思ったり、新プロダクトのメンバー同様に漠然とした不安をもったりしていましたが、その違和感や課題、不安を整理していくと、そこに見えてきたのは「スクラム」でした。

LeSS も スクラム である。

「スクラム」であるならばと、スクラムマスターとの会話を重ね、それぞれのチームが元々抱えていた課題や目指したいスクラム像のすり合わせをおこないながら、1年半かけてチームに対してアプローチをおこなってきました。

まだまだ荒削りで道半ばではありますが、双方のチームが壁を感じながら合体しただけの状態から、1つのスクラムチームとして融合し次のステップに進めるようになるまでの LeSS の歩みを、実際におこなったアプローチや私自身が感じたこととともに紹介します。

「うちも LeSS やっているけれど、なかなかうまくいかなくて・・・」
「LeSS って人数も多いし、なんだか難しくて大変＞＜」
「同じ LeSS チームなのに、チーム内で対立構造ができてしまって困っている」

などの悩みを抱える方にとって、それぞれのチームが抱える課題は違っていても、よくしていくための一歩を踏み出せるきっかけになれば、と思っています。