heyのSTORESでECの開発をしている @morihirok です。
STORES EC（旧STORES.jp）では、heyグループとなった2018年ごろより開発手法にスクラムを採用し始めました。
現在では多くの開発プロジェクトでスクラムが採用されるようになっています。 おかげさまでプロジェクトを横断して多くのスクラムの知見を得られるようになってきました。
今回はその中から、私が昨年携わったプロジェクトの反省について紹介したいと思います。
どんなプロジェクトだったか
私が昨年携わっていたプロジェクトは、ECの機能というよりはSTORES ECのバックオフィスに関わる機能を開発するプロジェクトで、半年以上をかけて多くのステークホルダーとの調整を行いながら開発を進めるような比較的大きいプロジェクトでした。
このプロジェクトでもスクラムを採用しました。 毎スプリントごとにスプリントバックログを作成し、そのスプリントにおける成果物のレビューを実施する。レビューにはプロダクトマネージャーだけでなく実際にこのシステムを使うSTORESの問い合わせ対応チーム*1にも参加してもらってフィードバックをもらう。その意見を元に次のスプリントバックログを作成する。 スクラムの手法に従い、開発は順調に進んでいきました。おかげさまで最後まで大きな認識のズレを発生させずにプロジェクトは完了しています。
しかし、主に分析・設計の不足が原因と考えられる失敗がありました。
スクラムにおける分析・設計
前提として、私たちは「スクラムにおいても分析・設計は必要」という認識を持っていました。
Martin Fowlerが Is Design Dead?の冒頭で述べていたように、スクラムやアジャイル開発に対するよくある誤解として、「設計は不要」というものがあると思います。
For many that come briefly into contact with Extreme Programming, it seems that XP calls for the death of software design.
（エクストリームプログラミングに簡単に触れた多くの人にとって、XPは「ソフトウェア設計は死んだ」と言っているように思えるようです。）（訳は引用者による）
「要求の分析・設計などに必要以上の時間をかけること」がスクラムやアジャイル開発では不要なだけで、チームが開発を進める中で設計が必要だと感じたときは積極的に設計を行うべきです。 もちろん、ここで言っている分析・設計とは形式的なドキュメントを用意することではなく、チームが開発をするに先立って必要だと感じたことを議論し、チームに適した形で共有することです。
今回のプロジェクトでは分析の段階から多くの状態遷移が発生する機能だということがわかっていたので、プロジェクトの序盤で状態遷移に関するフローチャート図を作成し、チームに共有していました。 これはとても効果があり、関わる人々がこれを参照しながら実装したり議論することで、必要なソフトウェアの形をより深く理解することができたと感じています。
発生した問題
ではどのような問題が発生したのでしょうか。
プロジェクトが進行していく中で、いくつかのフェーズに分けてリリースを行う計画となりました。 半年以上に及ぶ開発となることはプロジェクト序盤から見えており、全てが完成したタイミングでリリースするより完成したところから順次出していく方がユーザー*2の利益になるし、スクラムとも相性が良いと判断したためです。
そしてひとつ目のリリースを終え次のリリースに向かって開発をする中で問題が発覚しました。 それは「最初のリリースで提供される一部の機能において、ユーザーが使用したタイミングをタイムスタンプとしてデータベースに保持していないと以降の要件を満たすことができない」というものです。
この問題を解消するため、アクセスログを解析しデータベースの修正作業を行う判断をしました。 ユーザーへの直接的な影響はありませんでしたが、本番で稼働しているデータベースの修正は慎重を期すため、これに多くの工数がかかってしまい、結果としてプロジェクトの遅延が発生してしまいました。
反省
今回の反省として、リリースをいくつかのフェーズに分ける計画にしたことで、直近のリリース物に焦点を当てすぎてしまったということがあります。 アジャイルサムライにおいて、分析・設計について以下のように述べられています。
アジャイルな分析には2つの重要な柱がある。一言でまとめると「必要な分だけを、必要なときに」だ。まず、「必要な分だけ」とは、実際に作業を進めていくうえで必要な分だけを分析するということだ。分析しすぎてもだめだし、分析しなさすぎてもだめだ。
私たちはスプリントごとに目の前の課題に真剣に取り組み続けるあまり、「実際に作業を進めていくうえで必要な分」を見誤ってしまいました。 多くの状態遷移が発生することはすぐに見えたので分析・設計を行えましたが、データベースについては考える時間が少なかったと感じています。 連続するスプリントの中でも、一度立ち止まって冷静に全体を分析する機会を設けるべきだったと考えます。
また、Barry BoehmはMaking Softwareにてアジャイル開発と設計について以下のように言及しています。
アーキテクティング活動をリファクタリングという形でライフサイクル全体に渡って行うこともできますが、「最も簡単なものからやる」形で、スケーラビリティのない COTS やセキュリティ的に問題のあるデータ構造・制御構造にコミットしてしまうなど、アーキテクチャに関するコミットメントを行ってしまい、それが後から容易には直せなくなるという事態に注意する必要があります。
特にデータベースは、アプリケーションコード以上にアーキテクチャに関するコミットメントになりやすいと考えます。 データベースに関してはリファクタリングによって修正していくアプローチより、ある程度しっかりと分析・設計を行ったうえで実装に取り掛かるのが良いことを改めて強く実感しました。
この反省を生かし、以後のフェーズに取り掛かる前にステークホルダーへのヒアリングを通じて細かいユースケースとそれに必要なデータの洗い出しを行い、以前より時間をかけてデータベースの設計を行いました。 これにより以降のリリースではデータベースの大きな修正を行うことなくスムーズにプロジェクトを進められることができました。
おわりに
この間、私たちのチームのプロダクトマネージャーが「すべての解はグラデーションとバランスの中にしかない」と言っていて、ふとこの反省のことを思い出していました。 「分析しすぎてもだめだし、分析しなさすぎてもだめだ。」という問いの答えは、ユーザーの状況と私たちの状況と作りたいものを真剣に考え、考え抜いた末に見えてくるんだと思います。 反省と分析を繰り返しながら、少しでも正しい解にたどり着けるようこれからもやっていきを見せていこうと思います。
STORESではこのような反省を他のスクラムチームと共有しながら、よりよいチームになるよう日々改善を続けています。 heyやSTORESに興味がある方、最近リモートでのオープンオフィスをはじめましたのでよかったらのぞいてみてください！
