はじめに
お久しぶりです。尾上です。 気づけば、前に書いた記事から２年経過してしまいましたｗ さて今回は、私の所属しているチームが開発手法にスクラムを採用したので、採用までにやったこと、採用後どうなったかをお話します。 スクラムの採用しようと思っている方には、導入する際に決めることやつまづきポイントが参考になるかもしれません。 また、すでにスクラムを採用している方には、「同じ苦労したわ～」とか、「もっとこうすればいいじゃない？」等、突っ込みながら読んでいただければ幸いです。
あなたの業務は？
私が所属しているアプリチームは、ecbeingと連携するスマホアプリ（OMOアプリ＋）を開発しています。 このアプリは、ecbeingと同様に、お客様毎にパッケージをベースにしたカスタマイズが可能です。 www.ecbeing.net
アプリ開発の役割分担変更
アプリ開発の役割分担は、当社がパッケージ開発を担当し、お客様向けのカスタマイズは外部ベンダに依頼するという形でした。
この方針転換に合わせてスクラムの採用を検討しはじめました。
スクラム開始前に抱えていた課題感
方針転換前、パッケージの開発のみを担当していた頃、アプリチームはウォーターフォールで開発していました。 ウォーターフォールは、予めすべての作業を洗い出し各作業の工数を見積もることで、いつまでに作業が終わるのかが明確になる利点があります。 逆に当初想定していないタスクが発生した場合は、都度、計画を立て直します。 方針転換前は、作業範囲がパッケージにとどまるため、開発する機能やスピードをコントロールでき、ある程度計画どおりに進められました。 方針転換後は、カスタマイズ部分も引き受けるため、お客様との仕様調整や、OS（Android、iOS）都合による改修等、想定外のタスクの発生頻度が高くなります。 このままウォーターフォールで開発を進めると、計画を見直す頻度が増加して対応できない課題感がありました。
スクラム採用で期待したこと
スクラムはスプリントという決まった期間（通常２週間から１ヶ月）でチームでタスクの重さを見積もって進めるため、想定外のタスクにも柔軟に対応できる利点があります。 また、アプリはiOSやAndroidの知識に加え、連携するサーバサイド側の知識も必要となります。 そのため、開発チームには「アプリが得意」「サーバが得意」など得意分野が異なるメンバーが在籍しています。 スクラムの計画立て（スプリントプランニング）では、開発チームと会話をしながらタスク進行の計画や見積もりを行うので、各メンバーの知見を持ち寄ることで最適な計画が立てられることを期待しました。 これらの点が先に挙げた方針転換後の問題を解消できると考え、最終的にスクラムを採用することにしました。
スクラムを始めるまでにやったこと
スクラムを開始するには、まず色々と準備が必要です。ここでは準備した内容を挙げていきます。
スクラム知識の平準化
スクラム経験があるメンバーとないメンバーが混在しているため、まずはチーム内のスクラムに関する知識を平準化します。 ScrumBootCampをチーム内で回し読んだり、同じ部署にいる認定スクラムマスターや、認定プロダクトオーナーがスクラム勉強会を開催してくれたので、それに参加する等しました。 同じ教材、勉強会を通じて、スクラムチームの役割の理解、タスク管理方法、イベントでやることの認識を揃えました。
チーム方針の決定
次に、これからどういう方針でチームが動いていくのかを定義しました。
アプリチームでは、アジャイルソフトウェア開発宣言から引用し、自己組織化されたチームを目指す方針を定めました。
自己組織化されたチームになることで、変化の激しいアプリ開発のトレンドに対応することとアプリを通じてお客様のビジネスをブーストさせることを指針にしました。
タスク管理ツール
タスク管理ツールにはJiraを採用しました。
Jira | 課題 & プロジェクト管理ソフトウェア | Atlassian
スクラムはスプリントのタスクにフォーカスしがちです。
そのため、長期目線でのスケジュール感を意識しづらいデメリットがあります。
Jiraではバックログとは別にロードマップを切り替えて表示できるため、短期、長期の両軸でタスクを確認できます。
バックログは１スプリント内のタスクを表示し、ロードマップはエピック（タスクを束ねたもの）での予定を表示できます。
アプリチームでは、バックログは開発チームで、ロードマップはステークホルダーにそれぞれ見せることで、それぞれが見たい視点でのタスクを掲示して使い分けています。
個人的にはJiraの方が直感的でわかりやすくて使いやすいです。
イベント設定
イベントは以下のように定義しました。
役割の決定
役割分担はこんな感じにしてみました。
スクラム運用開始後
そんな感じで、最低限のことは決まったのでスクラム運用を開始して行くことにしました。 スクラムの経験主義に則って、あとは走りながら改善していくことにします。
さっそく、良い効果がではじめた！
運用開始直後は、探り探りなこともあり、プランニング等のイベントに時間がかかりましたが、徐々に慣れて改善していきました。
慣れてきたころには、最初に掲げた自己組織化を目指す方針も浸透し始め、レトロスペクティブでもメンバーから前向きな意見が出てきました！
忍び寄る問題たち
しかし、運用を初めてしばらくして、問題はやはり出てくるものですね。。 ここからは主だった問題とその対策を３つ共有します。
問題１：プロダクトオーナーによる独裁政権
概要
プロダクトオーナーはタスクを積んでじゃんじゃん消化（推進）して欲しい人です。 一方、スクラムマスターは、プロダクトオーナーと開発チームの間を取り持って調整する人です。 これらを同じ人が兼務するのはアンチパターンとされています。 なぜなら、POが開発チームに過剰な要求をしても誰も止められないからです。 自分で自分に歯止めをかける形になりますが、ステークホルダーなど声の大きい人達の要求をのんで開発チームに無理をさせてしまったり。。。 いわゆる、独裁政権状態になりがちです。 自分なりに現実的に消化可能なタスク量に落とし込んでいるつもりでしたが、やはりPOとしての自分が勝ってしまい、多めにタスクを積んでしまいがちでした。
解決策
幸いなことに、他のチームのスクラムマスターに兼任で入ってもらうことができました。
結果
独裁政権が崩壊し、開発チームに平和が訪れました（笑）
また、第三者目線で今のスクラムチームの状態を見てもらえたり、他のチームでの経験を輸入できたり等、副次的に良い効果もありました。
問題２：プランニング、リファインメント時間かかりすぎ問題
概要
メンバー間にスキル差異があるため、プランニングポーカーで各自が出すポイントに乖離が生じることが多々ありました。 この場合、メンバー間で完全一致するまで議論してポイントをつけていたため、議論に時間がかかりプランニングがタイムボックスに収まりませんでした。
解決策
プランニングポーカー時、全員のポイントの平均値を取るようにしました。
これにより、ポイントを一致させるための議論をする時間がカットでき、機械的に見積もりができるようになりました。
ただ、あまりにも乖離している場合（例：1pt、1pt、5pt）は、議論して乖離の幅を減らします。
なぜなら、その人しか把握してない懸念点があるかもしれないからです。
結果
機械的にプランニングポーカーを進められ、タイムボックスに収まるようになりました。
また、議論すべきことだけにフォーカスできるので、1度に見積もれるタスク数も増加し、良い効果があったと思います。
問題３：会議の時間がもったいない問題
背景
方針転換の数カ月後、開発メンバーの増員を行いました。
パッケージ開発とカスタムを両軸で進めていくための体制強化となります。
概要
パッケージ、カスタムとで開発チーム内でタスクの線引が明確になり、Aさんはパッケージ、Bさんはカスタムといったように、各人で取るタスクも固定化されてきました。 パッケージ、カスタムの担当にかかわらず、プランニングやリファインメントは全員で参加していたため、 各イベントで自分には直接関係のないタスクの話が長く続くようになり、 その間、出席しているだけでなにもできない時間発生。この時間がもったいない！と思うようになりました。
解決策
一部のイベントをパッケージとカスタムで分割しました。
- 分割：プランニング、リファインメント、スプリントレビュー
- 合同：デイリースクラム、レトロスペクティブ
結果
参加するイベント時間が削減されたため、タスクに時間を避けるようになりました。 また、議題もパッケージとカスタムで明確に分離できるので、イベントそのものの進行もスムーズになる副次的効果もありました。 レトロスペクティブは合同で実施することで、カスタム側で困っていることをパッケージに吸い上げるといういい流れもできてきています。
ふりかえり
今考えると、思ったよりすんなりスクラムに移行できた気がします。
主な要因は、最初にチーム方針を定めて自己組織化したチームを目指すと打ち出したことだと思います。
この方針がチーム全体に自発的に問題を解決していく流れを作ってくれたことが良かったのかなと思っています。
また、同じ部署のスクラム経験者から助言をもらいながら進められたことも大きかったと思います。
自分たちだけだと気づかないことも多々あるので、チームの外から客観的な意見を貰える環境はありがたいです。
おわりに
いかがでしたか？
少しでもスクラムを開始する際にやること、ぶつかる壁と突破の仕方をなんとなくイメージしてもらえると嬉しいです。
また、スクラム経験者の方からのツッコミやご意見も募集しております。
私は、アジャイル、スクラムの一番の利点は、実践して振り返って改善するサイクルを同じリズムで繰り返すことで、少しずつ確実にチームで成長できるところだと感じました。
かつて、イチロー氏が
「小さいことを積み重ねる事が、とんでもないところへ行くただひとつの道だと思っています。」
という名言を残していますが、まさにチーム全体で小さいこと（＝スプリント）を積み重ねることで、いつか、とんでもないところに行けるといいなと思います！
ecbeing では、アジャイルな開発を通じて、とんでもないところへ行きたい仲間を募集しています!
careers.ecbeing.tech
