アドベントカレンダー22日目を担当します。ソリューションアーキテクトの sataro です。
前職ではホスティング専門のインフラエンジニアとして、穴蔵に籠って運用保守をやっていました。
それはそれで楽しかったのですが、自社プロダクトへの興味が膨らみ転職、心機一転aptpodではSAとして働いています💪
さて、本稿ではスクラムについてちょっとお話ししてみたいと思います。
aptpodでは自社プロダクト開発の一部にスクラムを取り入れています。私はその中でも スケーラビリティ をテーマに掲げたチームで、プロダクトオーナー(PO)として活動しています。 とはいっても、タイトルの通りスクラムに取り組んでようやく半年になろうかというところです。何か驚きのテクニックをご紹介！というわけにもいきませんが、これからスクラム始めてみようという方や、POってなんぞ？という方の参考になれば幸いです。
はじめに
スケーラビリティ と書きましたが、まずは簡単にプロダクトの背景説明を。
チームのミッションは、自社プラットフォームのスケール向けたインフラアーキテクチャの実現です。 弊社の基幹プロダクトの１つである intdash ですが、大変有り難いことに研究開発分野において多方面で活用頂いています。 そして当然、研究開発の先には、どこかのタイミングで 製品化＆大規模運用というフェーズが待っています。
クライアントが大規模運用に打って出ようとした時に、弊社のプラットフォームが足を引っ張っては元も子もありません。 そこで、intdashのスケーラビリティは急務である。というわけです。
まずは予習してみた
半年前、スクラムを実施するにあたり、いくつか書籍をあたりました。
SCRUM BOOT CAMP THE BOOK（西村 直人 永瀬 美穂 吉羽 龍太郎）｜翔泳社の本
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで（市谷 聡啓 新井 剛）｜翔泳社の本
どちらも言わずと知れた名著です。 基礎知識から実践のイメージまで、はじめるために必要なことは全て書いてあります。 迷うなら読んだ方が良いです。
スクラムの基礎についてはこちらのブログなどでも学べます。
ある程度概要が掴めたら、とにかくやってみるのが良いと思いました。 説明を読んでもなかなか頭に残らないので・・・
で、POってなに？
一度原点であるスクラムガイドに立ち返りたいと思います。 スクラムガイドによると、プロダクトオーナーは開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。とされています。 実務的な動きとしては以下のようなものです。
- プロダクトバックログアイテムを明確に表現する。
- ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。
- 開発チームが行う作業の価値を最適化する。
- プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す。
- 必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう。
プロダクトオーナーがこれらを実践できればスクラムは回ります。ですが、実際に取り組んでみると、開発チームが行う作業の価値を最適化するがものすごく深い。一筋縄ではいかないので、あれこれ考えてみました。
実践してみたこと
価値を最適化するについて考え始めると沼にはまりそうだったので、少々乱暴ではありますが一度自分の中で単純化してみました。 5,6個くらいの指針なら意識して行動できるのでは？と思い、いわゆる5W1Hを意識すると良いんじゃないかと考えています。
ビジネスや受験勉強などでもよく聞くワードですし、スクラムにおいてはユーザーストーリーを考える際にも登場します。 価値の最適化を見失わないために、ここでも活躍してもらいましょう。
Who
ここでの「誰」はチーム外にいるステークホルダーの明確化です。
チーム内で開発アイテムに対するステークホルダーは基本的にPOになると思います。 受け入れ条件を定義して各アイテムを検査する、というのはチーム内で行われます。
一方で、プロダクトの大枠においてのステークホルダーというのも別にいるかと思います。
今回の場合、「○○という案件が来年度以降で同時接続デバイス数XX台になる見込みがある」という具体的な数値目標がありましたので、機能要件のステークホルダーはその案件を担当するソリューションアーキテクトとなりました。
プラットフォームがスケールしていく中で満たすべきセキュリティやコストバランスなどの非機能要件は、経営層や管理部門に別のステークホルダーが存在するはずです。
各側面で「誰」と要件を握っていけば良いのか意識すると、無駄なものを生み出す危険が減ると感じています。
Why
ここでの「何故」はゴール設定における目的意識です。
本プロダクトの場合、スケールするアーキテクチャの実現という大テーマはゆらぎませんが、一方で具体的な数値目標はふわふわしているとも言えます。 前述の通り「同時接続デバイス数XX台」という目標があり、まずはそこをゴールとして走り始めました。 ただ、案件の状況も会社の状況も随時変化しますので、ゴールが状況と合わなくなることもあります。
スクラムはゴールが変化することを前提としたフレームワークですので、ゴール設定を再確認する向き直りの機会さえ持てれば、プロダクトを継続して開発することはできるはずです。私たちのチームも一度スプリントを止めて向き直るタイミングがありました。
そのタイミングを見誤らないために、自分たちは「何故」それを作っているのか、という視点は常に持っている方が良いと感じています。
What
ここでの「何」は開発アイテムへの理解です。 次々にチームから生み出される開発アイテムについて、POはチーム外へ正しく説明できる必要があると思います。
チーム内では開発アイテムの優先度について合意をとった上で進めていきます。しかし、チーム外からは、優先度の高いアイテムの意義が見えにくいこともあるかもしれません。 何となく停滞しているんじゃないか、など要らぬ心配や横槍が発生しないようにしたいところです。
外部のステークホルダーにはどういった目的で「何」を開発しているのか、情報共有していくことが必要だと感じています。
When
ここでの「何時」は期限です。 最終的に開発アイテムは求められるリリース時期にアジャストしていく必要があります。
ここでは案件との兼ね合い以外にも、製品のリリースサイクルも絡んできます。せっかく作ったものを世に出すタイミングを逃しては大変です。
「何時」リリースに乗せるか、というのもプロダクトの大事な要素です。
Where
ここでの「何処」は・・・5W1Hとか言ってしまいましたが、あまり関係ありませんでした😅
強いて言えば、チームとの会話の機会は「何処」でもつか。 face to face でもった方が良い。ということです。
極端な話POはスプリントの最初と最後、プランニングと振り返りさえ顔を出していればスクラムは回ります。 あとはタスクボードで会話すればいいじゃん。となってしまってはもったいないと思っています。
POは自分で実装はしません。だからこそ、開発チームがどんな考えで、どんなこだわりをもって開発を進めているか。肌で感じて進めていくのが、その熱量をチーム外に伝える助けになると感じています。
How
最後に「どうやって」です。スクラムにおいて、実現方法はPOではなく開発チームに委ねられます。 もちろん私たちのプロダクトも同様です。
弊社にはアプリケーションからハードウェアまで、イカしたエンジニアが揃っていますので、ここでのPOの役目は信じて任せるだけです。 常時各レイヤーで仲間を求めていますので、興味があれば是非こちらをご覧ください。ダイレクトマーケティング🤣
まとめ
PO視点で、チームがうまく機能するためにはどうしたら良いか・・・この半年考えていたことを語ってみました。もちろんこれで正解というものではないので、常にカイゼンを目指していきたいと思います。
何か参考になれば嬉しいです。ありがとうございました。
