こんにちは。アプリケーションエンジニアの池田 (@yukung) です。
今年の NBA Finals 🏀は Toronto Raptors の優勝で幕を閉じましたね！ Golden State Warriors の 3 peat (3連覇) への挑戦も夢には届かず… Warriors ファンにとっては怪我人が多発して不運な形で終わってしまい残念な結果になってしまいましたが、カナダに初めてのチャンピオンリングがもたらされたことからも、ここ数年のウォリアーズの黄金時代から NBA の時代が変わろうとしていることに未だ興奮冷めやらない池田が、今回のブログ記事をお届け致します！
さて、今回は私が関わっているあるプロダクトにおける開発フローについてご紹介したいと思います。
アスタミューゼにおける開発フロー
アスタミューゼには、既に運用に入ってるもの、新規構築中のものを含めて複数のプロダクトがありますが、どういった開発フローを採用するかについては、プロダクトごとに判断は委ねられており、採用されている開発フローは様々です。Redmine や GitLab の issue/ticket ベースで進めているものもあれば、カンバン方式で進めているものもあります。
そんな中で、私が現在関わっているプロダクトではスクラムを採用して開発を進めています。具体的な開発フローをご紹介する前に、なぜスクラムを採用しているのか、という点についてご説明したいと思います。
（チーム加入当初）私が感じていた課題感
私が現在関わっているプロダクトでは、元々ある特定の決まった開発フローは採用されておらず、要件から洗い出された機能ベースのタスクが人にアサインされている状態で開発が進められていました。また、抱えているアプリケーションも複数存在しており、それぞれ必要とされる機能が各アプリケーションで実装されている状況でした。
その後、私が入社してしばらく経った頃、開発の推進主体が私に引き継がれる形となりました。
推進主体が引き継がれるまで、私は入社してしばらく開発の進む様子を眺めながら作業を続ける中で、次第に以下の課題感を感じるようになりました。
- 機能ベースで洗い出されたタスクごとに、人にアサインされ、またそれらが複数のアプリケーションで実装されている形のため、自身が担当しているものとは別の機能や他のアプリケーションの仕様が存在・発生している経緯が分からない
- 経緯が分からないので使うユーザーの状況が想定できず、その必要性や仕様の良し悪しが判断できない
- 各人が機能ベースで関連するタスクを集中的に行っていたため、チームメンバーが得意な領域がアプリケーションごとに分断され、それぞれ他の領域のことについては全く関与できていない
- ドメイン知識が各個人の中で閉じ込められてしまい、チームとして知見が溜まっていかない
- 誰が今何をやっているのかよく分からない
- 開発を進めるに当たって議論して結論を出した際に判断基準となったものや議論の経過など判断の根拠となった情報を文章やメモとして残す習慣が根付いておらず、どうしてそうなっているのかについて社内のドキュメントを検索しても見つからず、人に聞かないと分からない
- 非同期的にではなく同期的にしか情報を得ることができないため、確認を取るために設計・実装作業が都度スタックしてしまい、進めるスピードが上がっていかない
もちろん上記にはその当時のいろいろな制約があり、物事を前に進めるためにある程度妥協しながら進めていた結果であり、それ自体は尊重すべきことです。しかしながら我々はベンチャーで、これからどんどん仕掛けていかなければならない挑戦者の立場でもあります。今後開発の速度や生産性を非連続な形で促進していかなければ、今関わっているプロダクトの成功確率を上昇することは難しいのではないか、という危機感がありました。
ではそれを達成するには何が必要だろうと考えると、少なくとも上記の課題意識は解消していくべき課題だろうと捉えていました。
チームメンバーの課題感
推進主体が私に切り替わったタイミングで、開発を進めるにあたっての課題意識を共有する場を開き、チームメンバーにヒアリングを行ってみました。すると、以下のような課題意識があることがわかりました。
- 関わっているアプリケーション以外不明な部分が多い
- デプロイフローがよく分からない
- いつ何がどの環境に上がっているのかが聞かないと分からない
- 特定の人が大変そう
- タスクの優先度・アサイン先・タスクの状態がチーム全体で共有・可視化できていない
- フロントエンド - サーバサイド - インフラという分かれ方ではなく、アプリケーション A / アプリケーション B / アプリケーション C といった分かれ方になっていて、ロールではなくシステムでチームが分かれている
- ドメイン知識が各人に偏りがち
- タスクが専任制
- 誰が何やっているのかはわかるが、どうしてそうなっているのかが不明なので、引き継げない
- 他の人の持っているタスクの優先順位がわからないのでいつのタイミングで頼めば良いのか分からない
- DB のどれが何なのかが分からない、合間に入った改修で何が変わったのか把握していない
- 仕様変更やコード修正後のフローを決めて品質安定（デグレ避け）に努めた方がいいと思う
- 仕様がふわふわしている
- 指示系統や開発を行う上でフローが確立されていないので混乱が生じる場面があった
上記の項目は複数のチームメンバーにヒアリングをした結果、挙げられた意見ほぼそのままの引用です。いずれも以下のような要因に起因する課題のように見受けられました。
- コミュニケーション・情報の流れの不透明さ
- 開発フローの不透明さ
- 現状の可視化の不足
- 知識・ノウハウの偏り
また、上記から私がプロダクトチームに加入した際に感じた課題感と、チームメンバーの課題感が大きくズレがないことも感触として得ることができました。
私は前職以前で経験したプロダクトにおいて、スクラム開発の経験があったためスクラムがチーム開発においてどういった効果をもたらすものかを体感として理解していました。
またスクラムの3本柱として透明性・検査・適応という概念がありますが、上記の課題を解決するためにスクラムの透明性という概念がチームが抱える課題の解決に寄与するのではないか、という感触を私が持ったため、開発フローとしてスクラムの導入をチームに提案1し、スクラムの採用が決まりました。
私のスクラムの始め方
現チームメンバーは 1 人スクラム開発の経験者が居ましたが、チーム全体としてスクラムの経験値が高かったわけではなくほぼみなが初心者という状況でした。そのためスクラムって何？というところからのスタートです。当然プロダクトオーナーやスクラムマスターといったスクラムの登場人物（ロール）、各種スクラムセレモニーの種類やその意義、概念、用語なども知らない状態です。
そういったところからスクラムを始めると決めた当初、私が気をつけたことは、教科書的にスクラムというフレームワークの概念やプラクティスを勉強会などで伝えるのではなく、日々の作業を通して体感しながら理解してもらえるようなアプローチを取りました。具体的には、導入提案時にはスクラムの登場人物・役割の説明と、スクラムイベントの種類と概要説明、プロダクトバックログ・スプリントバックログの運用方法の説明に留めました。（これだけでも結構説明項目は多いんですけどね…スクラムガイドにも習得は困難と予め記載されているのはスクラムガイドを一度でも読んだことがある方ならばご存知の通りです）
その後粗い Done の定義と、 PO に 0 スプリント目のプロダクトバックログ優先順位付けをお願いし、1 スプリントの周期をどの程度にするか（結果的には 2 週間を 1 スプリントと定めました）をチームメンバーで議論して決めて、後はえいやでスタートしました。
このアプローチはある意味邪道かもしれません。これは過去のスクラム導入2の経験において、理念や概念を大上段から話をしてスクラムを進めた結果、各人がイメージした効果や結果の通りにならずにスクラムに対して幻滅・期待値の齟齬といったことが原因で途中でスクラムを辞めてしまったチームを見た経験を持っていたことによります。スクラムに対して前提知識のないチームメンバーに対して、スクラムがなんだか凄いもの・怖いもの・大変なもの、というイメージを持ってほしくなく、チームメンバーの納得感を大事にしたかったのです。（なので上手く行かないと思ったらそこで止めてもいいよ、ということもメンバーにはその時伝えました）
私にとってラッキーだったのは、同時期に入社した Product Manager の Gyopi もスクラム開発の経験者であったことです。 PO に対してスクラムの概念や用語について事前にインプットすることなしに、ある程度の暗黙の了解でスクラムを開始することができたことは大きい要素でした。
スクラム開始後
スクラム開始後は、まずはやってみせ、言って聞かせて、させてみせ、の精神で私自身がスクラムマスター兼開発者兼スクラムセレモニーの MC を兼任する形で進めていきました。3その中で徐々にプランニングポーカーによる見積もりやプロダクトバックログリファインメントでの次スプリントへ ready にするための調整、スプリントごとの振り返りの実施、など徐々に取り入れていくようにしました。
現在 8 スプリントを終了した状況で、取り入れられていないプラクティスもまだまだたくさんありますが、チームメンバーとの対話や振り返りの中で必要と決めたものを徐々に取り入れられればと考えています。4
以降、具体的にスクラムをどう運営しているのかについて、いくつか実例を交えながらご紹介したいと思います。
プロダクトバックログ／スプリントバックログの管理
私個人は以前スクラム開発では JIRA を利用していましたが、現在のプロジェクトはまだ立ち上がったばかりで潤沢な予算があるわけではないため、 JIRA が現実的な選択肢ではありませんでした。そのためいくつかのツールを検討した結果、現在 Asana で管理しています。
プロダクトバックログ
スプリントボード
Asana はリスト形式とボード形式をプロジェクトごとに使い分けることができ、またタスクを複数のプロジェクトに紐付けることができます。そのため、現在アクティブなスプリント内のタスクをボード形式のプロジェクトにも紐づけてあげることによって、プロダクトバックログ／スプリントバックログはリスト形式で管理しつつ、進捗状況をボード形式で管理する、ということができます。これによって JIRA でできていたことがある程度同じようにできるだろう、という算段が立ったため、 Asana を使うことに決めました。5
現在では、私が関わっているプロダクトだけではなく社内の他のプロダクトでも Asana が浸透しつつあります。また、振り返りの実施時にも、 Asana のボードを使って振り返りを行っています。
ストーリーポイント見積もり
アスタミューゼでは、お子さんをお持ちの開発者の方もたくさん在籍しています。そのためご家庭の事情であったりなどで状況に応じてリモートワークで勤務されている方もいらっしゃいます。そんな中でスクラムを円滑に進めていくには、リモートワークで働いている人を基準にして情報のやり取りのスムーズさや透明度を高めていく必要がありました。
社内コミュニケーションは主に Slack を利用していますが、適宜チャットや音声通話、ビデオ通話を利用しながらなるべくリモートワークの方に不便な状況が生まれないように配慮しつつ開発を進めるようにしています。
同様に、プロダクトバックログアイテムのストーリーポイントを見積もる際、リモートワークの方も同じように議論に参加できる必要がありました。ストーリーポイントの見積もりにはプランニングポーカーを用いるのが定番の方法だと思いますが、リモートワークの方に物理的なポーカーを送付して使っていただくのも大変です。
そのような課題を解決するため、私はリモートからでも仮想的にプランニングポーカーを実施できるようなアプリを実装して運用しています。
プランニングポーカーアプリ
（GIF アニメがやや雑でわかりずらくごめんなさい 🙇♀️）スクラムマスターが場を設定（画面左側）し、その場に対して開発メンバーがスマホのブラウザ（画面右側）から WebSocket で接続してリアルタイムにカードを選択しながら議論ができるようにするようなアプリです。6
本音のところは単に私が仕事に追われずに息抜き的にコードを書きたかった、というのもあるのですが 😜 、このアプリを Play Framework と Akka Streams で実装したものを、実際のプランニング時に利用しています。データベースやファイルなども使っていないので情報は何も保存していないため、パブリックな場所にデプロイしてあっても支障はないだろうと判断し Heroku にデプロイしています。
これによってリモートワークのメンバーでもオフィスに居るメンバーと同じようにプランニングポーカーを実施することが現在できています。
モブプログラミング
あるスプリントの振り返りを分析しているうち、チーム内で設計やクラス分割、コードのイディオムなどについて共通理解がまだあまり醸成できていない状態があることが浮き彫りになりました。
また、弊社は主に Scala で開発を行っていますが、チームメンバーの中にはまだ Scala に充分に習熟できていない人ももちろん居るため、チーム内で Scala のノウハウの共有に課題感を持っていました。
そこで、あるスプリントのプロダクトバックログアイテムとして比較的小規模なリファクタリングのタスクがあったため、それを題材にチームメンバー全員でモブプログラミングに取り組んでみました。
この取組みは非常に好評で、学びが多かった、楽しかった、もう一回やりたい、などポジティブなフィードバックをたくさんいただきました。以下モブプログラミングを実施したスプリントの振り返りで挙がった項目の一部をご紹介します。
- 【まとめ】きっつい！！！！(のでたのしい
- scala力に差がありすぎて突っ込めないのが申し訳ない
ツッコミがあってんのかどうか全くわからないのでまさかりがほしい
自分だけ（？）windowsなので、ドライバーになったときが不安
- flatMapの連続しているコードがfor-yieldで書ける事に気づかなかった（書いていなので身についていない
- 最後の方にでたn+1問題、ormが上手いこと解消しているものだと思いこんでいた（以前現場で使っていたものだと気にしなくてよかったような・・・
- 他の人の設計や実装についての考え方が聞けてよかった
モブプロ2回目があると嬉しいです！
Scalaで覚えたことの復習になって良かった＆また新たな学びがあった！
- 結構うるさかったんじゃないかと心配してる
- リモートのみなさんのプログラミングも見たい
- 構成についていろいろな考え方があると知れた
- 構成についてどういうのが最適なのか皆さんの意見をもっと聞きたい
アーキテクチャの話とか共通化の話とかみんな意見があって長く話せそうなので別の機会に話したい
他のプロダクトの話をきけるのがよかった
- Scalaの勉強になったようなので役に立ててよかった
モブプログラミングの取り組みはまだ頻繁にできるほどチーム内で浸透できていないので、やり方やテーマの選定など、今後もっと頻繁に取り組めるように前向きに取り組もうとしているところです。
まとめ
ここまで、主に私が関わっているプロダクトにおける開発フローやその取組みについてご紹介させていただきました。
アスタミューゼには、こういった開発を進めるための取り組みも開発者が気軽に提案してメンバーで自由に議論しながらみんなで開発を進めていく雰囲気があります。
チームメンバーと議論を深め合いながら成長していきたいエンジニア、デザイナー、PM の方を絶賛大募集中です！ ご興味のある方は下記バナーの採用サイトからご応募いただくか、カジュアルにランチなどでお話させていただくこともできますので、お気軽に @yukung までご連絡いただければ嬉しいです。お待ちしています。
-
余談ですが、この時の提案資料についてはチームメンバー全員がアクセスできる wiki のプロジェクトトップページから「スクラムで運用することになった経緯について」という内容でいつでも参照できるようになっており、後から加入したメンバーに向けても経緯が把握できるようになっています。↩
-
当時のチームでスクラムを導入したのは私主導ではなく、当時のスクラムマスターで、私の役割はいち開発メンバーでした。↩
-
これはこれで超大変だったのは言うまでもありません。現在では、チームメンバーの chotaro が MC を巻き取ってくれて、スクラムマスター業に専念することができ超助かっています！ありがとう！ 🙏↩
-
バーンダウンチャートやインセプションデッキ、ユーザーストーリーマッピング、スキルマップなどなど。インセプションデッキなどはむしろ本当は終わらせておかないといけないはずで、ここはただただ私の力不足…。↩
-
stormcat24 さんのブログ記事を参考にさせていただきました。感謝 🙇♀️ https://blog.stormcat.io/post/entry/asana-sprint-board/↩
-
カードアイコンは redbooth/scrum-poker-cards を利用させていただきました。ありがとうございます。↩
