こんにちは！2025年1月にアンドパッド入社したやっはー (@yahharo) と申します 🤗
こちらは ANDPAD Advent Calendar 2025 の22日目の記事です。
前職でもテックリードとして機能開発の設計・開発・運用をしてきましたが、アンドパッドでも期中からはテックリードとしてさまざまな経験をしてきました。
しかしながら、新しい環境では、コードベースもチームの文化も異なります。
その中でも手探りしながら、この一年でいくつかの大切な判断をしてきました。
この記事では、今年やってきた判断をいくつか振り返りながら、当時、自分は何を大事にしていたのか、そして 今なら何を見て判断したいか を整理してみます。
プロダクト開発チームで技術的な判断を任されることが増えてきたエンジニアやテックリードの方の参考になれば幸いです。
なお、文中の判断の是非は、当時のチーム状況の中で
自分がどこに目を向けて判断していたか を振り返ったものです。
Case1: あるフラグを追加したい時
既存テーブルに追加 or 別テーブルを新規で作る
- 件数の非常に多い大規模なテーブル(RDBMS)に対して、 ユーザー側で表示・非表示を切り替えられるよう、 booleanのフラグを追加したい
🤔 悩みポイント
- 単純に考えるとそのテーブルにフラグを追加すれば完了
- しかし当該テーブルでのDDLは影響範囲が大きい
- その適用を考えると、リリーススケジュールを崩さずに進められるか
- 別テーブルに分けると、余計なクエリを発行して切り替えることになる
- その開発コストやパフォーマンスへの影響をどう考えるか
フラグ自体は小さな変更ですが、既存機能への影響を考えると、DB周りはどうしても慎重になります。
✅ 選んだ方
別テーブルを新規で作る
💡 当時の判断理由
- 当該機能は全ユーザーが使うわけではなく、非表示にしたいケースがその時点の想定でも多くはない
- 他チームからのヒアリングやユースケースを踏まえると、 このフラグを利用するユーザーは全体から見て限定的だった
- 一方で、既存テーブルへの追加は大規模テーブルであるがゆえに、 変更適用時のリスクが高く、安全に実行するには 適用タイミングを慎重に選ぶ必要があった
🔍 振り返って思うこと
この判断では 「大規模テーブルへの変更リスクをどう抑えるか」 を最優先に考えていました。
ユースケースを考慮した設計自体は間違っていなかったと思いますが、
影響範囲を抑えるという制約の中で、選択肢が自然と絞られていった面もあったと感じています。
また、今回はそのフラグ専用のテーブルとしましたが、別のフラグ群をもつテーブル設計でも良かったかもしれないとは思っています。
（実際に他のモデルにはそのような実装がされているケースもあった）
短期的には安全かつ、確実に進められたので、当時の判断としては悪くなかったと思います。
一方で、中長期で見たときの設計の扱いやすさについては、もう一段考えられた余地があったかもしれません。
▶️ 次に活かしたいこと
「その機能を成立させられるか」だけで判断せず、「数年後にこの設計をどう扱うことになるか」まで含め、中長期的な視野で考えられる状態にしたい。
Case2: 不確実性の高い連携機能を作る時
汎用的に作る or 使われ方に寄せる
- 既存の客先の業務システムと連携する機能を、APIとして提供したい
🤔 悩みポイント
- ユースケースとして、具体的な呼び出し方の想定がまだ固まりきっていない
- データ単体同士を連携する部分は決まっているが、先方システムの具体的な呼び出しケースは決まっていない
- 一方で、リリーススケジュールが迫っている
- 利用者への追加ヒアリングや要件の深掘りに十分な時間が取れない
- 今ここで使われ方を決め切るべきか
- それとも、あとから広げられる余地を残すべきか
✅ 選んだ方
汎用的に作る
結果として、データ構造を軸とした設計にしました。
💡 当時の判断理由
- 当時は、リリースまでのスケジュールがかなりタイトで、
この期間で成立させられる仕様はどこまでか を強く意識していた
- 今ここで利用シーンを限定してしまうより拡張しやすい構造にしておいたほうが良い
- APIを利用するエンジニアであれば、 汎用的に使える仕組みのほうが それぞれの状況に合わせてカスタマイズできるのではないか
🔍 振り返って思うこと
この判断では、「まず期日までに成立させる」ことを最優先に置いたことで、無事にリリースはできました。
一方で、振り返ってみると、このケースは「誰が使うのか」という前提の置き方をより深く考えるべき場面だったと感じています。
実際の利用者は、ITのプロというより、業務やドメインのプロであることが多いです。 その前提に立つと、「汎用的であること」「あとから拡張できること」よりも、以下の観点のほうが重要だったかもしれません。
- この場面では、こう使えばいいと直感的に分かること
- 迷わず使えること
そう観点を決め切ってしまったほうが、価値を届けやすかったと思います。
結果として、柔軟な設計にはなりましたが、使う側にとっては少し「考えながら使う」必要のあるAPIになった面もあります。
▶️ 次に活かしたいこと
やはりまずは適切なユースケースをしっかり拾い上げたうえで、設計を仮提案し、少しずつ決めていきたい。
時間や制約がある中でも、以下の観点を一度言語化してから判断したい。
- 業界のドメインを理解して社内システムを組んでいるエンジニアへの理解
- そのシステムがアンドパッドとどのように接するのか
当時の判断としては、必要な要件を満たした汎用的なものを期日通りに完成できた点は良かったです。
ただ、もう一歩ユーザーの懐に深く踏み込んだ上で「届けたい体験」を考慮した判断をしていきたい。
Case3: 他チームに変更を共有するタイミング
ある程度できてから共有 or 途中からでも巻き込む
- 他のチームも関係してくるデータに対して、 一部の設定を追加できるようにした機能改修についての共有
🤔 悩みポイント
- 他チームにも影響がありそうだが、どこまで関係しているか完全には把握できていない
- どのタイミングで共有するのが適切か判断がつかない
✅ 選んだ方
ある程度できてから共有
まずは自チーム内で設計・実装を進め、「私たちのチームは、この変更をします」という形で完成形に近い状態を共有する進め方を取りました。
💡 当時の判断理由
当時は、まずは自チームの開発を止めず前に進めることを強く意識していました。
- まだ設計や実装が固まりきっていない段階で共有すると、余計な混乱や手戻りを生んでしまうのではないか
- まずは自チームで整理してから共有したほうが、全体としてスムーズに進むのではないか
こうした考えから、ある程度形にしてから共有する判断をしました。
🔍 振り返って思うこと
自チームのスピードを守ることを優先しすぎて、判断を一緒に作るフェーズを飛ばしてしまっていた のかもしれません。
当該データについて、他の機能でどう使われているか、他チームがどんな前提で設計しているかを十分に理解しきれないまま進めていました。
結果として、以下のようなことが起きました。
- 他チームでの機能提供は間に合わないので、切り分けて提供する
- ユーザーへの機能ごとの説明が多くなってしまう
早く進めるために選んだ判断が、全体のデリバリーを遅らせてしまった面もありました。
とはいえ、自チームの範囲開発自体は無事に完了し、試験提供させていただいたユーザーからは好評をいただいています。
▶️ 次に活かしたいこと
その実装の影響範囲を含めて、設計中に先んじて以下を共有しておきたい。
- なぜその変更が必要なのか
- その変更の実装計画
その上で、どこまで影響がありそうかを確認するプロセスを含める。
共有は、進捗を伝えるためのものではなく、判断を一緒に作るためのもの。
途中からでも関係するチームを巻き込み、前提をすり合わせながら進めることで、結果的に全体としてスムーズにデリバリーできるような進め方を目指していきたい。
おわりに：判断するとき、何を見ているか
ここまで、いくつかの判断を振り返ってきました。
どれも当時の制約や状況を踏まえると、間違いだったと言い切れるものはなかったとは思っています。
一方で振り返ると、判断そのものよりも、何を大事にしていたか が選択肢を大きく左右していたケースも多かったと感じています。
- 安全に進めることと、扱いやすさをどう天秤にかけるのか
- 本当にしっかりとユースケースを確認できていたのか
- どこまでを自分たちで決めて、どこから巻き込んでいくのか
これらの判断に迷ったポイントは違っても、今と将来とで自分たちは何を大事にしているのかを一度言語化できれば、判断の精度は確実に上がっていくと感じています。
その大事にしていることが本当に今のチームやユーザーに合っているのか。
もしかしたら、それ自体を少し動かすことで、別の選択肢が見えてくるかもしれません。
完璧な判断を目指すというより、判断し続けられる状態をチームで作っていく。
そんな向き合い方を、これからも大事にしていきたいです。
アンドパッドでは "難しい判断" を何を大事にするか考えたうえで、決断できるシニアなエンジニアを大歓迎しています。私と一緒にカジュアル面談や面接で話しましょう！
