アルプの開発チームがどのように開発手法を試行錯誤しているかを残しておく。振り返ることでこれまでどのようなことを、どのようなチームで、どのようなアイデアで解決してきた*1のかを整理できる。
改めて振り返ってみると「開発手法に銀の弾丸などない」という一言に尽きるくらい、変化が激しい。それでもやってこれたのは、より良い開発にこだわり続ける情熱を持ちつつ、変化に寛容なチームだからだろう。
なお、これは古いドキュメントを辿った断片的な情報の集約であり正確ではないため、チームからのレビューなどでアップデートされる可能性が高い。 「誰かのために〜」とは考えていないが、あえて言うならば、これから入る未来の仲間へ向けていると言えるかもしれない。歴史は文化として残るか、文章になる。文化は僕らが行動で示していくが、理由を知りたい人もいると思う。そんな人はこのブログを読むのをお勧めする。 これを読まなくても困らないように、必要な文化を残しているので、読まなくても大丈夫。
黎明期 - v0.1 (2018/12 - 2019/1)
- 開発メンバー: エンジニア1人 + 業務委託数名
開発チームへの第一歩。以下のようなことをしていた。
- Notionの利用開始
- 2018/12: 原初開発ドキュメント「概念図で議論したいこと」が作成される
- 概念図駆動モデリング？
- 不定期な開発MTG: 主にインフラまで含めたサービス設計、client - server間の通信手段、使用技術の選定、マイクロサービスにするかといったアプリケーション設計などを議論していた
- プロダクトをtoB向け？toC向け？どちらにするかを議論していた
これからわかるように現在のようなツールや手法を用いたものは何もなく、参考プロダクトのAPIリファレンスをもとに、僕らが今後どのようなものを作るか？を「概念図」を用いて共有し始めた。この当時からCacooを使った概念図作成を行っている。どんな概念図を作っていたかはドメインモデリングの苦労で紹介している。当時のアプリケーションアーキテクチャの大部分は大きく変わらずに今も活きている。
概念図からユースケースへ - v1.0 (2019/02 - 2019/08)
- 開発メンバー: エンジニア5人 + 業務委託
あえてユースケース駆動開発と書いていないのは、本などで紹介されているような厳密なプロセスを用いたものではないためである。2019/01の月末頃に共有されていた開発フロー図のようなものが以下。
これをもとにまずは大量のユースケースを完成させないと開発に入れないということで、毎日のように概念図を整理し、モデリング、ユースケース化を進めていた。上の図を見て面白いのは、現在はプロダクトオーナーと呼ばれるビジネス側のメンバーが要件定義とユースケースまで記述していたのだ。とても大変なことだと思う。
そのほかにはこんなことが起きていた。
- 開発MTGを定例で実施するようになった
- バックエンドチームでモブプログラミングをするようになった
- ドメインモデルについてドキュメントを書き始めた
- 開発メンバーの経験を踏まえてモノリスで開始することにした(重大な決断だった)
- CRCモデルによるクラス設計を始めた
- ユースケースドキュメントの記述方法を整理し始めた
僕個人としてはユースケース駆動開発の本を読んだり、DDD本の必要な部分を読み直すことで、以降全社的にDDDを実践していると言えるようになるために必要な道具を揃えていった。この頃から社内でユビキタス言語を定義して用いましょうということを開発チームが推し進めていった。 チームとしては、初めてマイルストーンを意識して、ユーザーストリーマッピングを用意していた。この当時からユースケースドキュメントのメンテナンスが大変という問題は解決できていない。
スクラム黎明期 - v2.0 (2019/08 - 2019/11)
- 開発メンバー: エンジニア6人 + デザイナー1人 + 業務委託数名
人数も増え、いよいよ開発チームらしくなってきた。以下のようなことをしていた。
- Notionのボードを使ってバックログ管理
- 顧客が本当に欲しかったバックログを求めて試行錯誤
- フロントエンドチームが誕生する
- Scalebaseクローズドβ版のリリース
(リリース頃の詳細は 入社して半年が経って、リリースした。に書いている)
このあたりでは明確に職能としてフロントエンドチームを分け始めたが、バックエンドと比較してタスクの差し戻しやデザイン相談などが増え開発が混乱してきた。
そこでフロントエンドチームでは以下のような工夫を始めた。
- タイムボックスを決めてスプリントを意識する
- 定期的に成果物のPOレビューをする
これにより、タスク整理のタイミングを意図的に増やし、要件の認識合わせられ、開発後半での手戻りを減らした。これがアルプ開発チームがスクラム開発を始めるきっかけとなった。その後スクラムのエッセンスを取り入れつつ見積精度をあげていくように進めた。
- 「Sprintを回すには」と呼ばれる僕らのスクラム開発の原点が作成される
- タスクの種別を決めてBacklog管理をする
- FP法*2による大まかな見積、プランニングポーカーによる細かな見積を行う
チーム全体でスクラムを取り入れたことで、開発サイクルのリズムを作るという点で成功した。しかし、進めるうちに以下のような問題が上がってきた
- フロントエンドとバックエンドが明確に分かれたので、タイミングよく着手できる方が在庫に手を出し、仕掛かりタスクが増えた
- タイムボックスはあるが適切なタスク分割ができておらず目標未達が増えた
- バックログ管理が大変
まだまだスクラムを改善する余地がありそうだとなってきた。
僕個人の感覚としては、この頃はとにかくあれもこれもと目まぐるしく動き回っていたと思う。チームでも「コンテキストスイッチが大変」がホットワードになっていた。今も動き回っているのは変わらないが、当時は今ほど機能をリリースできてなかったように感じた。
スクラム開発期 - v2.1 (2019/11 - 2020/08)
- 開発メンバー: エンジニア9人 + デザイナー1人 + 業務委託数名
これまでの時期に比べると業務委託比率も減ってきた頃。誰が何をやるかちゃんと決めてハンドリングできるようになってきたタイミング。しかし、上であげたように、仕掛かりタスクが増え、スプリントを達成できないことが増えた結果、チームの開発への考え方がフロー効率ではなくリソース効率に寄っていたとわかってきた。
そこで、改めて僕らのスクラムを見直していき、「Sprintを回すには 第二版」と呼ばれるターニングポイントとなるドキュメントが作成された。大きく変わったのは以下。
- より一般的なスクラムガイドに載っていることを素直に実践した
- より厳密にバックログステータスを管理した
- 要件定義書からPRD(Product Requirements Document)を書くようになった
- フロー効率を優先し、自タスクが終わったら他の人のタスクをサポートした
- 要件定義・デザイン設計が開発ボトルネックにならないように調整した
この頃から、これまで分かれていた職能ごとのチームを超えて手が開いたらフロントエンド・バックエンドの開発に入るという体制へとシフトしていった。今も常に行っているわけではないが、必要に応じて積極的に全てのプロダクトを触れるようになっている。
この頃はみんな口々に「経験上、ここまでスクラムが綺麗に回っているプロジェクトは見たことがない」と言っていたし、僕もそう感じていた。ディレクターやスクラムマスターが疲弊している、なんちゃってスクラムは世に溢れているし、自分1人ではうまく回らない経験をしてきた人は多いはずだ。アルプに集まっているメンバーもそういう経験を持つ人が多かったし、スクラムに対して批判的な人もいた。そんな中でもやってこれたのはメンバーの相性が良かったからかもしれないけど、みんなの小さな積み重ねがあったからだと思う。しかし、このままうまくいくかと思っていたが社内のポエム投稿用esaに以下が投下された。
以下は引用。
このまま少しずつ改善を重ねていけば、ベロシティは向上するだろうし、Scalebaseの品質と機能性も順調に成長していくと思う。ただしそれは、Alpという会社が無くならなければの話。築き上げてきた安定を捨ててでもスピードに執着しなければならない状況では、スクラムの固い足場が却って阻害要因になるかもしれない。
スクラムを取り入れた僕らはある程度安定した開発を行えていたが、つまるところ開発スピードは上がらなかったのだ。スクラムのせいというわけではないが、スクラムは安定したベロシティを目指し見積精度を上げるのには効果が高いけれど、取り入れたからと言って開発スピードを上げてくれるわけではなかった。もちろん、今後続けて行くことでスピードが上がることはイメージできたが、今求めている状態に至るには時間がかかるだろうとわかった。
そして現在やっているカンバン方式へと移行していくことになった。それ以外には以下のようなことが起こっていた。
- ドメインモデル勉強会が開催される
（様子はドメインモデル勉強会に書いている）
- ホラクラシー組織の考え方を参考に、役割の帽子化、分担の見直しを進めた
（LAPRASのHiroki Shimadaさんのブログは参考になりました。ありがとうございます。）
- 本格的にマイクロサービスを検討する前段階としてモジュラモノリスへの移行をした
(モジュラモノリスについては弊社竹尾の発表に詳しい)
- エンジニアチームを2つに分けて、それぞれの活動をチーム任せにした
- 要件定義の精度を上げるべくICONIXを取り入れようと試みた
エンジニアチームを分けたのはすごく良かった。two-pizza teamsよりは少ない人数だが、今の時期はとにかく開発に関わることは全員で共有するみたいなことが多く、意識的に分割していかないと全員の時間を無駄にしてしまう。知らないことはあってもいい、知るための道具があれば大丈夫。現実はそれほど単純ではないけれど
カンバン開発期 - v3.0 (2020/09 - 現在)
- 開発メンバー: エンジニア11人 + デザイナー1人 + 業務委託数名
かくして、いろいろな開発手法を参考にしつつ、タスク管理はスクラムとは大きく変えずに、見積フェーズをある程度緩くしてカンバンでタスクのステータス管理をする現在に至る。三ヶ月ほど経ったが日々取り組みを改善している。
- 「Sprintは回さない」というカンバン開発へチャレンジするドキュメントができる
- バックログをJIRAの次世代プロジェクトを用いたカンバンへ移行
- QAがボトルネックとなるのでテスト自動化を目指しAutifyへの移行を進める
- 割れ窓を修正する割れ窓デーを毎月開催
- 外部の有識者と設計論などを話し合う会を定期開催
現在までにバックログのJIRA移植を完了しているがまだまだやりたいこと・改善したいことがたくさんある
- タスク状況が明確になったので、フロー化して定量的に分析する(手法なども知りたい)
- タスクの依存関係や進捗を把握する方法の改善(ロードマップやガントチャートなど)
- カンバンにしてどう改善されたのか？ということを明らかにしていく
- ユースケース駆動開発(ICONIXとか)やRDRAを取り入れて、手戻りのない要件定義へ
- 開発メンバーオンボーディング改善
- 影響範囲の大きい開発要件プロジェクトをうまく進めたい
などなどだ。2020年アルプの開発現場からは以上。一緒にやってみたい人は面談からでもいいので是非！
