要件レビューの次に、タスク管理のM3を実装し始めた

タスク管理アプリの要件を何度か読み直していました。

最初は、指摘を直して仕様書が整えば、ひとまず次へ進めると思っていました。

実際には、仕様書の矛盾が減ったあとに、実装側で確認したいことが増えました。

要件レビューで残ったもの

v0.4では、前回までに見つけた大きな指摘は一通り解消できました。

組織とユーザーの所属、ゲストの扱い、アクセス失効、ジョブのリース、サブタスクの深さ、ガントの性能条件などが少しずつ揃っています。

それでも、組織から人を外した時にプロジェクト側の所属をどうするか、通知の重複排除キーに受信者を含めるか、期限を朝9時以降に変えた時の扱いなど、細かい論点は残りました。

重大な矛盾ではありません。

ただ、こういう細かいところは、あとで実装すると確実に出てきます。

実装では、まずM2の残りを進めました。

メンバー管理、変更履歴、エラーバウンダリ、カンバン列の仮想スクロール、カスタム項目のCSVと検索、行のドラッグ＆ドロップなどです。

ひとつひとつは別機能に見えます。

でも、タスクが増えた時に一覧が重くならないこと、誰が変更したか分かること、失敗した時に画面全体が壊れないことは、どれも運用に入ると必要になりそうな部分です。

「作成・編集ができる」だけでは足りないところが見えてきました。

M3では、FS依存関係のAPI、サブタスクと期間のロールアップ、ガントのスナップショット、リアルタイム更新、ベンチマークまで進めています。

依存関係は、画面上で線を引ければ終わりではありません。

循環を許してはいけないし、移動した時にどこまで検証するかも決める必要があります。

サブタスクの期間も、親タスクに表示する値をどこで計算するかで、APIと画面の責務が変わります。

仕様書を読んでいる時は簡単そうでしたが、実装してみると状態が増えます。

ガントは、少ないデータなら普通に表示できます。

問題は、タスク数が増えた時です。

そこで、機能を作ってから最後に速さを見るのではなく、スナップショットやベンチマークを一緒に置くことにしました。

何件までをどのくらいで表示したいのかが曖昧なままだと、「動いたけれど遅い」という話になりやすいからです。

まだ最終的な性能評価が終わったわけではありません。

ただ、計測の入口があるだけでも、後から感覚だけで判断しなくて済みます。

要件レビューは、実装前に正解を作る作業ではありませんでした。

実装して初めて、仕様書の中に書かれていない状態や境界が見えてきます。

なので、レビューを終えたら仕様書を閉じるのではなく、実装で出た論点をまた戻していくのが良さそうです。

M3はまだ途中ですが、単純なタスク一覧から、依存関係や履歴、性能まで考える段階に来ました。

作るものが増えたというより、見る場所が増えた感じです。