SRE／インフラエンジニアとして働いていると、「インフラ側でこれを用意してほしい」という依頼がよく来ます。今回、ある依頼で取り込み基盤を作り、開発環境で検証するところまで進めたあとで、その要件が実は利用者の要望ではなかったと分かりました。
本番に出す前に止められたのは幸いでした。ただ、もっと早く気付けたはずだという反省もあります。自分への戒めを込めて、経緯と学びを残しておきます。
依頼の内容
サービスの会員基盤として、外部のロイヤリティ系 SaaS を使っています。その SaaS 側でも KPI ダッシュボードの提供が予定されていましたが、アプリのリリースには間に合いません。そこで「それまでの間、会員登録数やクーポンの利用率を AWS 上で見られるようにしたい」という依頼を受けました。
半年ほどの「つなぎ」で、SaaS 側のダッシュボードが出たら捨てる前提です。そのため、軽く・安く・捨てやすい構成を目指しました。
EventBridge Scheduler（早朝に毎時起動）
→ Lambda（SaaS のエクスポート API から日次ファイルを取得）
→ S3（生データ。個人情報の列は取り込む前に除去）
→ Glue Data Catalog（パーティション射影）
→ Athena（最新状態を出すビュー）
→ （ダッシュボードは次の段階で構築）
技術的には面白い点がいくつかありました。
- エクスポートは差分出力だった：前日から変わったレコードしか出てきません。そのため、キーごとに最新の行を採る
*_latestビューを必須にしました。 - SaaS 側のファイルは一定期間で消える：初回の全件取得もできないので、取りこぼした日は二度と復元できません。欠損日の検知とバックフィルを最初から組み込みました。
- 会員データに個人情報が含まれていた：Lambda で許可した列だけに絞り、氏名や連絡先を AWS 上に持ち込まない設計にしました。
ここまでを IaC で開発環境に反映し、数日動かして問題がないことを確認しました。
発覚
ダッシュボードの指標を決めるため、要件の細部を確認する打ち合わせを開きました。「この指標は何の判断に使いますか」「誰がどのくらいの頻度で見ますか」と質問したところ、利用者側から出た要望ではなく、部内で「あったら良い」と判断して追加された項目だったと分かりました。
利用者側も戸惑っていて、必要かどうかを持ち帰って検討してもらうことになりました。
「データを見せて決めてもらおう」という案について
その場で、「取り込んだデータの一覧を出して、どんなダッシュボードが必要か利用者に決めてもらおう」という案が出ました。
作ったものを活かしたい気持ちはよく分かります。それでも、私は反対しました。
- 業務上の課題がないところに、作る側からツールを提案する形になる：「何が見たいですか」と聞けば何かしら答えは返ってきます。でも、課題から生まれたものでなければ使われません。
- 利用者に余計な負担がかかる：必要かどうかを検討してもらっている最中に、画面の要件まで考えてもらうことになります。
- 会員データを外に出すことになる：目的が決まらないまま、データを外部に見せるべきではありません。
ただ、データを見せること自体が悪いわけではありません。課題はあるのに、何を見ればよいか言葉にできない場合は、取れるデータを示すことが判断の助けになります。問題は順番です。
課題 → 指標 → データ → 画面
この順番を逆にして、データから課題を探しにいかないようにしています。
止め方
作業は「保留」にして、次のことを記録に残しました。
- 設計書の冒頭に現状を書く：「保留（利用者の要否確認待ち）」というステータスと、開発環境は構築済みで本番は未展開であることを書きました。
- issue に経緯と、回答後の対応を書く：必要なら本番に展開し、不要なら開発環境のリソースを削除してクローズする、と両方の道筋を示しました。
- 判断の期限を明記する：ここが一番大事でした。データの仕様上、会員登録が始まってから必要と分かっても、それより前のデータは取れません。そこで「いつまでに回答が必要か」を、技術的な理由と一緒に書きました。
保留は、期限がないと忘れられてしまいます。技術的な制約から決まる判断期限を伝えるのはインフラ側の役目だと考えています。
学び
1. 依頼を受けたら、まず「要望元」を確認する
「誰の、どの業務課題から出た要望か」を最初に確認します。今回は設計までは確認せずに進めてしまい、詳細を詰める段階になってようやく気付きました。今後は依頼を受ける時点で、次の4点を揃えてもらうようにします。
- 要望元（利用者か、社内か）
- 目的（何の判断や報告に使うのか）
- 期限
- 優先度
2. 詳細を質問するのは失礼ではない
「何に使いますか」と聞くのは、相手を疑うことではありません。今回も、質問したからこそ本番構築の前に止められました。
3. 作ったものに引っ張られない
開発環境まで作ってしまうと、「せっかくだから使いたい」という気持ちが生まれます。作った分は「検証の成果」として記録に残せば十分です。使い道を無理に探す必要はありません。
4. 捨てやすく作っておいてよかった
最初から「半年で捨てる」前提で、サーバーレス構成と IaC 管理にしていたので、止めるのも消すのも簡単です。要件が揺らぎそうな案件ほど、撤退しやすい設計の価値が高いと実感しました。
おわりに
まだ利用者の回答は出ていません。結論がどちらになっても、「誰のために作るのか」を確認するという基本を、改めて意識するきっかけになりました。
依頼を「作る」ことで応えるのがエンジニアの仕事ですが、ときには「本当に必要か」を問い返すのも同じくらい大事な仕事だと思います。
