機能を足す前に、何を整理するか。ある担当者がガントチャート開発でやっていたこと

はじめに

「追加したい機能はある。でも、何が論点なのか、どこから決めればいいのかまでは整理しきれていない」

開発の相談では、こうした状態から話が始まることが少なくありません。見えているのはひとつの機能追加でも、その裏には既存仕様との整合、運用上の制約、優先順位の迷いが重なっていることがあります。

今回は、春秋で複数の案件を担当してきたエンジニアの新垣に、ある BtoB プロダクトのガントチャート開発について聞きました。約1年かけて GraphQL API を導入しながら機能を組み立てていった案件で、印象に残っているのは「どう実装するか」より前に、「何を整理し直すか」に時間を使っていたことでした。

「以前は要望対応に集中していた。いまは見えないズレを先に整える」と語る新垣

最初は、論点の置き方を取り違えていました

この案件では、外部の仕組みに頼っていたガントチャート機能を自前で持てるようにしながら、フロントエンドが使う GraphQL API も整えていく必要がありました。方向性は決まっていたのですが、最初から要件がきれいに揃っていたわけではありません。どこまでを今回の対象にするのか、どのデータをどう持つのか、まずは何を最小構成として出すのか。そういう前提を、実装と並行しながら固めていく進め方でした。

その中でも、自分の中で大きかったのが、既存タスクの取り込みと除去の仕様を詰めていたときです。最初の自分は、「ガントチャートを新しく作るときに、どのタスクを取り込むか」という前提で考えていました。取り込み方の選択肢をいくつか並べて、どの UI がよいかを比較する形です。

ただ、クライアント様と話す中で、その前提自体がずれていると分かりました。求められていたのは、作成時に一度だけ取り込めればよい機能ではなく、ガントチャートを作った後もタイムライン上で必要なタスクを足したり外したりできることでした。そこで、「どう取り込むか」ではなく、「運用中のガントチャートをどう扱えるようにするか」に論点を置き直しました。

フィードバックを受けたあと、仕様書の前提そのものを組み替えました。新規作成時だけを想定した比較から離れて、「誰が、いつ、どの画面で、何のために操作するのか」を見直し、作成後の継続運用まで含めて整理し直していったんです。

整理し直すと、先に見るべき制約が見えてきました

前提を置き直していく中で、次に見えてきたのがシステム側の制約でした。タスクの親子関係（「大タスクの下に小タスクがぶら下がる」というフォルダのような構造）は、ガントチャートだけで使われている情報ではなく、カンバンなど他の画面とも共有されていました。つまり、ガントチャート側でタスクを外すと、別の画面で見えているツリー構造まで壊してしまう可能性があったんです。

一方で、タスク同士の依存関係（「Aが終わらないとBを始められない」という順番のルール）はガントチャートの中だけで使うデータでした。同じ「タスク同士のつながり」でも、影響が届く範囲がまったく違う。そこを切り分けたうえで、親子関係のあるタスクはバラバラにせず階層ごとセットで扱う方針を基本ルールとして提案しました。依存関係については、取り込み時は気にしなくてよく、外すときだけそのガントチャート内のものを整理すればいい。こう分けると、どこに慎重さが必要で、どこはシンプルに扱えるのかがはっきりしてきます。

このときも、案をひとつ押し通す形では進めていません。複数の選択肢を並べて、それぞれのメリットとリスクを比較しながら、まずはどこまでを第1段階として実装し、どこから先を第2段階に回すかまで含めて提案しました。要件を広げるのではなく、今の制約の中でどこまで合意できるかを決めていく感覚でした。

リリース前の山場もありましたが、設計は崩さずに着地させました

ここまで整理できても、リリース前の実装は簡単ではありませんでした。複数の要素が絡み合う機能だけに、ひとつの変更が画面全体に波及する。テスト環境だけでは確認しきれない場面もあり、最後まで気を使うポイントでした。

実装に入ってからも、同じような整理が続きました。当初は、既存の仕組みの中にガントチャート用の情報を足そうとしていました。しかし、情報の所属先が曖昧になり、後から見たときに「何がどこに属しているのか」が分かりにくくなる構造でした。そこで方針を変え、ガントチャート専用の仕組みを新しく作ることにしました。ガントチャート固有の情報はその中で完結させ、既存の仕組みには手を加えない。クライアント様にも「なぜ分ける必要があるのか」を説明し、合意を得てから着手しています。

処理の受け持ちについても同じでした。既存の仕組みに条件分岐を足していけば一旦は動く。でも、それをやると後から見る人がしんどくなるし、次の改修でもまた同じところが重くなる。なので、ガントチャートの処理は専用の受け持ちとして独立させ、それぞれの責任範囲を明確に分けるほうを選びました。こうして、設計上の仕切りと処理上の仕切りの両方を整えました。

結果：その場しのぎにしなかったことで、最後まで崩れませんでした

最終的に残ったのは、機能を追加できたこと以上に、後から崩れにくい形にできたことでした。途中でユースケースの置き方を見直して、共有されているデータとその画面だけで閉じるデータを分けて、型や責務の持ち方も必要に応じて組み直したことで、危ない分岐を先に避けながら進められたと思っています。

リリース前は正直しんどかったですけど、大きく作り直すことなく最後まで着地できたのは、その都度整理し直していたからでした。振り返ると、この案件で掴めたのは、難しい機能を実装すること以上に、曖昧な要件の中でも前に進めるための整理の仕方だったのかなと思います。

さいごに

要件が固まりきっていない段階でも、相談できる余地はあります。何を作るかだけでなく、どこに論点があるのか、何を先に整理すべきか、今はどこまで決めれば前に進めるのか。そうしたところから一緒に考えたいときに、春秋へ相談してもらえたらうれしいです。

まずは今ある課題から、お気軽にご相談ください。