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