はじめに
一年前の自分へ。
今はうまく意思決定できてるぞ。なんでかって？ちゃんと型を持ったからだ。
当時の私は、タスクをもらった瞬間に実装イメージが浮かんでそのまま手を動かし始めていた。「たぶんこういうことだろう」で進めて、終盤に根本的な認識のズレが判明する。先輩にレビューをもらえば「そもそもなぜこのアプローチ？」と聞かれて答えられない。それを何度も繰り返していた。
さすがに「自分、何やってんだ」と思って、なんでこんなに手戻りが起きるのか原因をめちゃくちゃ考えた。先輩にも「どうやって進めてるんですか？」って聞きまくった。そこで見えてきたのが、うまくやっている人は実装前に必ず思考を整理するステップを踏んでいるということだった。
この記事では、私が1年かけて見つけた「意思決定の型」を書く。同じように先走って手戻りを繰り返している人に読んでほしい。花粉
どんなタスクで使ったか？
少し前に、あるプロダクトでこんなタスクがありました。
人材の配置変更を行うプロダクトがある。配置を変更したとき、「変更前と変更後の差分」をCSVとして出力したい。
一見シンプルです。が、実装を始める前に大きな分岐点がありました。
「CSVをフロントエンドで生成するか、バックエンドで生成するか？」
どちらでも実現は可能です。でも、この選択によって：
- 開発工数が3〜4日と8〜10日で大きく変わる
- ユーザー体験（ダウンロードの仕組み）が変わる
- 将来、数万件規模のデータに対応できるかどうかが変わる
1年前の私なら「パフォーマンス怖いからバックエンドで生成しよう」となんとなく決めて、さっさと実装に入っていたと思う。そして実装途中、最悪PRを出したタイミングで指摘されて手戻りが発生する、というオチを踏んでいたはず。
意思決定ドキュメントの雛形
まず、こんな構成のドキュメントを作ります。
## 何が問題？
## 決めたいこと
## 前提
## 検討
## 調査メモ
## 決定
正直に言うと、正直に言うと、めちゃくちゃ面倒くさいです。さっさと決めて楽しい実装に入りたいと何百回も思いました。ただ、小さいタスクは別として、このドキュメントはマストで作ったほうがいいです。
なぜドキュメントを作るのか？
-
言語化することで、構造立てた思考ができる
頭の中だけで考えると、どこかに「なんとなく」が紛れ込みます。文字に起こすことで、思考の抜け漏れが見えてきます。 -
将来見返すコストを下げる
数週間後、「なぜこの実装にしたんだっけ？」と思ったとき、ドキュメントがあれば即座に思い出せます。口頭で決めたことは必ず忘れます。 -
先輩への相談が格段に楽になる
「こう整理しているのですが、どう思いますか？」と聞けるようになります。これは本当に大きくて、相談の質が全然変わります。
実際の思考の流れ
Step 1：「前提」を徹底的に書く（最重要）
最初にやることは、問題・決めたいこと・前提の3セクションを書き尽くすことです。
ここが一番重要です。なぜなら、前提を踏み外すと、どれだけ丁寧に検討しても大きな手戻りになるからです。
さらに、前提をドキュメントに書くことで、嫌でも何度も読み返すことになります。それが「前提の誤りに自分で気づく」きっかけになります。先輩に指摘される前に自分で気づければ、最短で軌道修正できます。
今回のタスクでは、こんな前提を書きました（抽象化しています）：
- 差分を計算するロジックは、すでにフロントエンドに存在する
- 既存の類似機能（別のCSV）はバックエンドで生成している
- フロントエンドでCSVを生成する場合、ページリロードで処理が途切れる
- 要求では最大3000行のデータを生成したい。将来的に5000件規模のデータに対応する可能性がある
- 実装期日は○月まで
一点だけ注意しておくと、このセクションを「完璧に埋めてから次に進む」必要はありません。書きながら気づいて追記する、でいいです。完璧主義になって前提セクションで止まるのは本末転倒なので。
Step 2：案を全て書き出す
前提が固まったら、検討セクションに考えられる案を全て書きます。
- フロントエンドで生成する案
- バックエンドで生成する案
- まずフロントで作り、後でバックエンドに移行する段階的アプローチ
質より量。まず全部出す。
この段階では「これは無理だろう」という案も捨てずに書きます。後で比較するときに、捨て案が実は最善だったりすることがあります。
正直、「段階的アプローチ」は最初に思い浮かばなくて、「FEかBEかどちらかしかない」と思い込んでいました。案を書き出す作業をしているうちに、第三の選択肢が見えてきたという経緯があります。
Step 3：情報不足に気づき、調査する
「他に案はないか？」と考えると、前提知識の穴に気づきます。
今回はこれ以上案が出てこなかったので、このステップはやや省きました。
このとき、調査メモには雑然と書いていいです。後で見返すメモなので、きれいに書く必要はありません。むしろ「調査中の生の思考」を書いておくと、後でなぜその結論に至ったかが分かります。
「調査メモは汚くていい」と明示的に許可されたのが、個人的には一番楽になった瞬間でした。きれいにまとめないといけないと思っていたので、書くハードルが下がりました。
Step 4：観点を決めて比較する
複数の案が出そろったら、重要な観点を決めて比較します。
今回の観点はこうでした
| 観点 | フロントエンド生成 | バックエンド生成 |
|---|---|---|
| パフォーマンス（大量データ時） | △ リロードで処理途切れ | ○ サーバー側で処理 |
| 開発工数 | ○ 3〜4日 | △ 8〜10日 |
| UX | ○ 直接ダウンロード | △ 別ページ遷移あり |
| 仕様の複雑さ | ○ 既存ロジック再利用 | △ API設計が必要 |
ただ、この比較表はあくまで机上の整理です。最終的な判断は 「パフォーマンス懸念をどう解決するか」 にかかっていました。将来的なことを考えると、3000~5000人規模のデータに耐えられるかどうかが方式選択の分岐点になりそうだと考えました。
そこで「FE生成で3000~5000人のデータに耐えられるか？」という問いに絞って、解決方針をさらに比較しました。
| 解決方針 | メリット | 懸念 |
|---|---|---|
| 既存プロダクトでFEのCSV生成を探して確認 | すぐ確認できる | ほぼなし |
| POCで負荷試験 | 実際の挙動を確認できる | 自分のPC依存になる。実装→検証→リファクタのループで時間がかかる |
| データサイズを試算して推測 | 検証が容易 | 試算が間違えていたら本末転倒。あくまで推測 |
| バックエンドで実装する | どのユーザー環境でも確実に耐えられる | 実装工数が高い。最終手段的な立ち位置 |
ここでどの方針が最短かを考えました。①既存プロダクトを見る → ②POCで負荷試験 → ③データサイズ試算、の順で試す方針にしました。
運よく既存プロダクトにFEでCSVを生成している箇所があり、4000人程度・今回と同程度の列数で出力してみると約200KBだとわかりました。これで「FEで十分いける」という根拠が取れたので、この時点で方針が固まりました。
ちなみに並列でAIにPOCも作らせていました。どうせFEで実装するなら使い回せるし、大した手間でもないので。
Step 5：決定を書く
比較が終わったら、決定セクションにサマリ1行と理由を書きます。
今回の決定：
まずフロントエンドで実装し、将来的に大規模データの問題が顕在化したらバックエンドへ移行する。
- 差分件数は通常数百件程度であり、フロントエンドで処理しても問題ない
- 開発工数が3〜4日と短く、期日に間に合う
- 差分計算ロジックがすでにフロントエンドに存在するため、追加実装が最小限
「決定」セクションは最後に書きます。検討より前に書こうとすると、無意識に「自分が選びたい案」に誘導した検討になりがちなので。
まとめ
この型を使い始めてから、先輩に「なぜこの方針？」と聞かれる前に、自分で答えを持てるようになりました。ただ、型を使っても前提を覆されることはあります。それは型の問題ではなく知識不足なので、修正スピードが上がっていれば十分だと思っています。
この型は自分で一から考えたものではなく、色んな先輩のやり方を観察して真似して、自分に合う形にアレンジしたものです。結局、うまくいっている人の行動をよく見て素直に真似することが、1年目に一番大事なことな気がします。
焦らず基本を積み上げることが、最終的に一番速い。
ぜひ、次のタスクでこの型を試してみてください。