はじめに
サポーターズで7月にCTOになりました、あらたです。 今回は、「1dayスピード選考会」（1日で複数の企業と面接できるイベント）のシステム化という、およそ半年間のプロジェクトで実践した「開発プロセス」と「その裏側の試行錯誤」についてお話しします。
今回のプロジェクトでは、チームでスクラム開発に取り組みました。ただし、教科書通りに遂行するのではなく、チームの状況に合わせてプラクティスを取捨選択し、より良い形を模索しながら進めていきました。
その過程を共有することで、「そんなやり方もありなのか」「自分たちももっと崩していいんだ」といった、前向きな発見をしていただければ嬉しいです。
背景： チームにプロジェクト管理を行う人がいない
現在、サポーターズのエンジニアは6名ですが、以前はさらに少なく、大規模なプロジェクトであってもチームを分割することはありませんでした。 結果として、これまでは私がおおむねのスケジュールや開発優先度を決め、プロジェクト管理も担っていました。
しかし、エンジニアが増え、小さなチームを増やしていこうとする中で、私一人ですべてを管理する体制ではボトルネックとなり、組織がスケールしなくなってしまいます。 そこで、「他のメンバーにもプロジェクト管理の経験を積んでもらい、自分以外でも回せる土壌を作りたい」と考えたのが、今回の取り組みの背景です。
解決手法： まずは「共通言語」をインストールする
とはいえ、いきなり「任せた！やってみて！」と丸投げするのは乱暴ですし、属人的で再現性がありません。 そこで、まずはチーム全員に共通の知識が必要だと考え、『SCRUM BOOT CAMP THE BOOK』の読書会を実施しました。
この本は、スクラムマスターの「ボクくん」と、その同期で営業の「キミちゃん」がプロダクトオーナーとなり、開発チームやステークホルダーと連携しながらシステム開発を進めるというマンガ形式の物語です。 ストーリーの中でスクラムの要素が解説されており、非常に読みやすく、「チームでとりあえず読んでみる」ための入門書として最適だと感じました。
実践： 手元のツールと教科書のルールで走り出す
1. ツール選定：まずは手元にあるもので
読書会を経て共通言語ができました。「じゃあやってみましょう」という段階になります。 具体的に「何を使って」「どういうリズムで」進めるか、最初のセットアップを行いました。
世の中には便利なスクラム管理ツールがたくさんありますが、スクラム自体の肌感もわからない中で、いきなり新しいツールに手を伸ばすのは得策ではないと考えました。ツールの使い方を覚えることにコストを払うより、まずは手元にある使い慣れたツールを使って、スクラムというプロセスの「肌感」を理解することが大事だと思ったからです。
最初に取り入れたスクラムのプラクティスは2つです。
- プロダクトバックログ: やりたいことリスト
- スプリントバックログ: 技術仕様に落とし込んだ開発タスク
具体的には、以下のような構成でスタートしました。
| practice | ツール | 理由 |
|---|---|---|
| プロダクトバックログ | Google Docs | プロダクトオーナーやステークホルダーと会話する場所です。エンジニア以外も編集しやすく、コメントで議論もしやすいドキュメントツールが最適だと判断しました。 |
| スプリントバックログ | GitHub Projects | 技術的なタスクを分解して載せる場所です。開発の実装に近い場所が良いと考え、GitHub Projectsを選びました。 |
スプリントバックログの設定はクラスメソッドさんの記事（GitHub Projectsでスクラムのバックログ管理をする）を参考に設定を行いました。
実際のスプリントバックログの画面は以下の通りです。
2. 運用の方向性：1週間スプリントとプランニングポーカー
道具は揃いました。次は「どう動くか」のルールです。 『SCRUM BOOT CAMP THE BOOK』を参考に、私たちは基本的なスクラムのイベントを一通りやってみることにしました。
ここでスクラムのプラクティスを3つ追加します。
- スプリント: 1〜4週間で行われる開発サイクルのこと
- スプリントレビュー: 成果物の確認
- スプリントレトロスペクティブ: チームだけのふりかえり
まず、開発の期間を区切る「スプリント」。 これは金曜日から金曜日までの1週間に設定しました。経験の浅いチームなので、短いサイクルでフィードバックを回し、軌道修正しやすくするためです。
特に金曜日は、スプリントの区切りとして1時間の枠を確保し、以下のように運用していました。
- 前半30分： 次回スプリントと後半に向けたスプリントレビューの準備 と スプリントレトロスペクティブ
- 後半30分： プロダクトオーナーを含めたスプリントレビュー
準備・振り返り・レビューを1時間に凝縮して行うことで、会議漬けになるのを防ぎつつ、毎週必ず改善のサイクルが回る状態を作りました。
また、タスクの重さを測る手法として「プランニングポーカー」も導入しました。 フィボナッチ数が書かれたカードをメンバー全員で同時に出す優先度決めに用いられるプラクティスです。数字は1時間の作業を表します。
フィボナッチ数を使う理由は以下ブログを参照してください。
今回は専用ツールは使わず、Google Docs上のタスクごとに「フィボナッチ数」を書き込む形でスタート。全員で数字を出し合い、認識を揃えることを狙ったのですが……この運用が、後の「取捨選択」の大きなポイントになります。
まずは教科書通りにスタートしてみた私たちですが、すぐに ”現場ならでは” の壁にぶつかることになります。
悩みと改善：教科書通りにいかない現実
実際にスプリントを回し始めると、すぐに「教科書通りにはいかないな」という壁や「もっと楽にやりたい」という欲求が出てきました。 大掛かりな取捨選択をしたというよりは、日々の運用の中で「めんどくさい」「チームに合わない」と感じた部分を少しずつチューニングしていった感じです。
1. プランニングポーカーは続かなかった
最初のスプリントでは、Google Docs上のタスクリストにフィボナッチ数を書き込む簡易版でやってみました。しかし、これはすぐにやらなくなりました。
これを継続しなかった正直な理由は、「全員で集まってやる余裕がなくなったから」です。
しかし、当時の私たちは「見積もりの精度を合わせるための議論」に、そこまでのコストをかける価値を見出せなくなっていました。
「見積もりに関して議論する時間があるなら、まずは手を動かして実装を進めたい」という意識が強く、見積もりのすり合わせに時間を割くことへの納得感が薄れてしまったため、自然とフェードアウトしていきました。
ただ、結果的にこれがなくてもプロジェクトは回りました。 今振り返ってみると、破綻しなかった理由は「チームの相互補完力」にあったのだと思います。
- メンバーのスキルセット： 開発メンバーがバックエンド・フロントエンドの両方を一定レベルで触れるため、誰かが詰まっても別の誰かが手伝える状態だった。
- リカバリーの速さ： 1週間という短いスプリントの中でも密にコミュニケーションを取っていたこともあり、見積もりが甘くて溢れそうなタスクがあっても、すぐに検知してカバーし合うことができた。
「余裕がなくてやめた」というのが実情ですが、結果論として、このチームにおいては「厳密な見積もり」よりも「密な対話」、そしてそれを支える開発の手数でカバーするスタイルが合っていたのだと思います。
2. GitHub Projectsの「使い倒し」と試行錯誤
一方で、GitHub Projectsの方は運用しながらどんどんカスタマイズが進みました。 最初は「Draft Issue」を使ってスプリントバックログをただ並べるだけでしたが、より実態に即した形に変えていきました。
「手間」を減らすための工夫
また、ふりかえり(スプリントレトロスペクティブ)の際に「どんなコードを書いたか（Pull Request: PR）」も見えた方が良いよね、という話になりました。
最初は手動でPRをGitHub Projectsに追加していたのですが、これが正直「めんどくさいな」となりました。
そこで運用を変えました。
- 大きめなタスクはIssueを立てる
- 1スプリント内のPRを管理する「スプリント 10」みたいなGitHub Issueを立てる
- PRを作ったら、それらに紐付ける
こうすることで、自動的にProjects上でPRの状態も追えるようにしました。
便利な機能への「気づき」
さらに、最初は手動でスプリントの区切りを管理していましたが、途中でGitHub ProjectsのCustom Fieldsに「Iteration」というField Typeがあることを知りました。
「これ使えるじゃん」となり、途中からIteration機能を使って「スプリントN」を管理するように変更しました。
結果：書籍を武器に、現場のリアルと向き合う
こうして半年間の開発を経て、システム開発に「終わり」はないものの、「1dayスピード選考会」というイベントをこのシステム上で無事に開催できる状態まで持っていくことができました。まだまだ課題が残ってはいますが、しっかりと価値をユーザーに届けることができた、という点では胸を張れる結果です。
また、チームの変化として大きかったのが、スプリントレトロスペクティブ（ふりかえり）における「議論の質」です。 全員で『SCRUM BOOT CAMP THE BOOK』を読んでいたおかげで、共通言語をベースにした建設的な議論ができました。
「本だとこうだけど、自分たちの場合はこっちの方が良くない？」
というように、単なる感情論ではなく、「型（守）」を理解した上での「崩し（破）」の議論を、若手も含めて全員でできたこと。 自分たちで納得してプロセスを選び取る経験ができたことこそが、今回得られた一番の資産だと感じています。
これにより、課題としていた「自分以外のメンバーがプロジェクトを回す土壌」も、少しずつ整ってきました。
とはいえ、マネジメントの勘所は一朝一夕で身につくものではありません。今回の開発で一定の方向性は掴めたと思いますが、ここからが本当のスタートです。 これからも恐れずに打席に立ち続け、成功も失敗も糧にしながら、チーム全体で「自走する力」を養っていってほしいと思います。
さいごに
今回の開発を通して、教科書通りのスクラムではなく、自分たちの現状に合わせた「サポーターズ流」の開発スタイルが少し見えてきました。
もちろん、これは完成形ではありません。チームの状況が変われば、最適解も変わります。これからも私たちは、その時々のベストを模索し、変化し続けていくはずです。
冒頭でも触れましたが、私たちのこうした「型を知り、悩みながら崩していく」という泥臭い試行錯誤の過程が、読んでくださった方にとって「自分たちも、もっと自由にやっていいんだ」「こういうアプローチもありなんだ」という、前向きな発見に繋がっていれば嬉しく思います。
