スタートアップにおけるスクラム導入の一年を振り返る

この記事はHolmesアドベントカレンダー23日目の記事です。

記事の概要

はじめまして！
株式会社Holmesでサーバサイドエンジニアをしているseiと申します。
よろしくおねがいします。

今日は、僕が今最も熱中している筋トレについて語ろうと思いましたが、語り始めると収集がつかなくなることが容易に想像できましたので、それよりも重要なスクラムを導入して感じたことや、開発ついて振り返っていこうと思います。

スクラムについてはかの有名なスクラムガイドを御覧ください。
以下の弊社記事もスクラムに関連して参考になります。

カンバン観察日記（11月からスクラムマスターとして加わってくださった守屋さんの記事）

はじまり

それは突然やってきました。
ちょうど１年前の１２月、弊社CTOから開発会議で提案がありました。
「スクラムを取り入れてみようと思います。」
お恥ずかしながらスクラムのスの字程度しか知らなかった自分は、この時開発手法が変わるくらいにしか捉えていませんでした。
また、前提として、スクラムを採用するまでは機能単位で個人が見積もり、実装する体制を採用していました。
一見シンプルに見えるそれは実は深く、そして次の年の1Qから早速威力を発揮しました。

1Q -プランニング

思えば新年早々、忙しい日々が始まりました。
オフィスの移転に始まり、スクラム運用の本格的な開始。
（テスト運用として、年末までの二週間をSPRINT-1としました。）
以下、1Qの主な実績です。（詳細は割愛します。）

開発メンバー：７人
実装機能：カスタム検索項目、カスタム締結フロー、承認フローリニューアル、横断検索、メンション、ProjectCloud

このうち、特に厳しかったのが最後のProjectCloud（リリース予定が４月頭）でした。実装期間は大体１ヶ月半くらいでしたでしょうか。
月次社内発表で実装することを大々的に宣言したのでやるしかない！
大切なのは、その意思決定をチームで正解に導こうとすることです。
この時に気をつけた点はプランニング。個人に依存したときと比べ、チームプランニングでは異なる視点からの意見や判断もプランニングに取り入れることができるため、精度が増します。これまでの経験を元にチームとしてスプリントごとの受け入れ可能なポイント（相対見積もり）は把握していました。そのため、プランニング時に実装予定機能の総ポイントを算出し、オーバーする場合は収まるように機能を調整・精査し、新しくストーリーが加わる場合は、既存のストーリと入れ替えることで、総ポイント数が変化しないように注意しました。
上記により大幅に遅れることなく無事実装が完了しました。

2Q -レビュー

春を感じ始める４月に３名の方が開発チームにジョインしてくれました！
また、桜の満開と入れ替わるようにさらに２名の方がジョイン！
ジョイン祭りですね！
以下、2Qの主な実績です。（詳細は割愛します。）

開発メンバー：１２人
実装機能：グループ化機能、SAML認証、書類閲覧制限、承認フローの複数可、条項単位コメント、新Myテンプレート、テスト自動化

スクラムのいいところは改善のサイクルを回せることですよね。
全QでProjectCloudの実装はなんとか終わりましたが、レビューを通して他部署やユーザーさんの声を聞き、見えてきたのは機能増加によるQA業務の圧迫、品質の低下でした。
ということで、機能実装に加えて、groovyを用いたサーバのテスト自動化を行いました。
これによって品質の向上・担保が同時に実現できました。

3Q -デイリー

2Qで加入してくれた方々が活躍する中で、社内でのKotlinの普及活動を行っていただきまして、KotlinでAPI実装することとなりました。
（もともとメインのアプリケーションはJavaで実装されていまして、そこまで学習コストも高くないだろうという判断です。）

また3Qで実装となったKnowledgeCloudもマイクロサービスの形をとり、Kotlinでの実装を行いました。
以下、3Qの主な実績です。（詳細は割愛します。）

開発メンバー：１３人
実装機能：フロントのモダン化、文書管理番号の自動採番、API開発、KnowledgeCloud

2Qの話でも出てきたと思いますが、大事なことなのでもう一度いいます。
スクラムのいいところは改善のサイクルを回せることなんです。
ということでそのいい機会を与えてくれるデイリースクラムを活用しましょう。

デイリースクラム・・・開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの進捗を検査する。
デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。
（スクラムガイドから抜粋）

学習コストは低いとはいえ、初めてのマイクロサービス開発やAPIの開発ということで、日々の進捗確認やお互いのサポートは欠かせませんでした。
デイリーを行うことで、改善や問題解決の機会を増やしました。
ただ、毎日成長できるため非常に刺激的ですね！

（個人的なんですが、Kotlinは多機能だし、null制約もかけられますし本当に生産性が上がるのでおすすめです。）

4Q -レトロスペクティブ

4Qではチーム体制の変更がありました。
スクラムマスターの新規加入もあり、これまで1４名体制でおこなっていたスクラムを5名、9名のチームに分割することとなったのです。。。！
以下、4Qの主な実績です。（詳細は割愛します。）

開発メンバー：１５人（５名、９名）
実装機能：メンバー選択グループ化、アーキテクチャバージョン更新（予定）、一斉締結（予定）

ここで疑問に思われた方もいらっしゃるでしょう。そうです。
スクラム上はスクラムチームのメンバー数は３〜９人となっていますので、オーバーしていたことになります！笑
分割してみると、コミュニケーションが煩雑になってしまっていたことに気づけました。これは人が増えるごとにコミュニケーション量が必然的に増えていくためです。

チームが分割されたことでそれぞれの特色が出始めます。
レトロスペクティブも同様ですね。進行方向を変えてみたり、進行役をかえてみたり様々な工夫が見受けられました。

自分の場合、進行役をしたことで、進行の難しさやゴールを全員で共通認識することの難しさを痛感しました。また、それぞれ各イベントの司会をやってみると本当によく分かるんですが、わりとそのイベントの意味を正確に理解していなかったり、自分の中で落とし込めていなかったりすることにも気づけました。

まとめ

こうして振り返ってみるとみなさん気づいたことがあると思います。
実はこの一年、スクラムにおける４つのイベントをシンプルに行っているだけであり、特別なことはほとんど何もしていないんです。（むしろ正確にできていない箇所もあります。）しかしチームに完璧は訪れません。現状に満足せず、常にボトルネックに真摯に向き合い、改善していく必要があるのです。

スクラムを実践するとは、簡単なようで実はめちゃめちゃ奥が深いです。
語れる方は一緒に語りましょう！DMください！

最後に

Holmesでは、アジャイルチームで活躍していただけるデザイナ、エンジニア、Product Managerを募集しています！
話を聞いてみたい、なんか面白そうと感じた方は僕へDM、もしくは下記から連絡いただけますと幸いです。

About 株式会社Holmes - Wantedly