3年目の失敗。メール配信機能の要件定義で「なぜもっと踏み込めなかったのか」を言語化して見えた学びと教訓

はじめに

こんにちは！アソビュー株式会社でエンジニアをやっている加藤です。
ところでみなさん、最近食で感動した経験はありますか？私はスーパーで買った春キャベツが美味しすぎて感動しました。「一旦、春キャベツがうますぎて感動した話でもします？」と飲み会での箸休めトークで乱用しているのでそろそろ鬱陶しがられていそうです。やはり季節の食材は最高ですね。
というアイスブレイクはさておき、今回は私が入社3年目にして経験した、要件定義から実装までを1人で完結させたプロジェクトについて振り返り、その中で経験した失敗、そこから得た学びを共有したいと思います。
要件定義を初めて行うんやけど、不安やな〜...というそこのあなた！ぜひこの記事を参考にしてみてください！

開発した機能の概要

まず、私が開発した機能の概要を簡単に説明します。今回開発した機能は、緊急連絡が必要な際、ダッシュボード画面から契約者様（＝パートナー）がアソビューユーザー（＝ゲスト）へメール配信を行える機能です。
そして、メール配信実行後はslackへ通知を飛ばすことで、CS担当者がメール配信の実行や配信内容を確認できるようになっています。

元々、緊急連絡が必要な場合には、以下の手順でゲストへ連絡をしていました。

パートナーから弊社の営業担当者へ連絡
営業担当者からCS担当者へ連絡
CS担当者からゲストへ連絡

上記手順を踏む必要があったため、パートナーがゲストへ連絡をするまでに2~3時間がかかってしまうことや、営業担当者やCS担当者の工数が発生してしまうことが課題となっていました。

したがって、メール配信機能のリリースにより以下のメリットが見込まれました。

パートナー: 即座にゲストへ連絡できるようになる
ゲスト: すぐに連絡をもらうことで安心する、無駄足を防ぐ
社内: メール配信工数が大幅に削減となる

初めての要件定義と、今振り返る「違和感」

3年目の夏、メール配信機能の開発を任されました。要件定義から実装までの全工程を1人で完結させました。当時は「初めての要件定義！よっしゃーやり切った！」という達成感がありました。
しかし、いざパートナーがこの機能を使いはじめたとき、「意図しない使われ方」をされていたり、要件定義時には想定していなかったケースについて、本機能が利用できないかというお問い合わせがパートナーからいただくことが増えてきました。

意図しない使われ方をされていたケース

「5月1日〜5月5日に来場するゲストに向けて配信」のように、特定の期間（利用日）を指定して一括配信できる機能を実装した。しかし、実際には「5月1日分を配信、次に5月2日分を配信…」と、単日指定を繰り返して配信作業を行っているパートナー様がいた。
CS担当者へチケットのキャンセル依頼を選択できる機能があるが、パートナー様が自身でキャンセル依頼をしたい場合、「CS担当者へのキャンセル依頼」ではないため、パートナー様はキャンセル依頼なしを選択してメール配信を行っていた。そのため、slackの通知内容が「チケットのキャンセルを進める旨の文言なのに、キャンセル依頼がなし」となっており、CS担当者によるパートナー様への確認が発生した。

要件定義時に想定していなかったケース

今回リリースしたメール配信機能は「未使用のチケットを持っているゲストを配信対象」としていたが、あるパートナー様からは「当日、天候不良だった場合は使用済のチケットを持っているゲストもメール配信対象にしたいが、そういったことはできないか」というお問い合わせがあった。

システムとしては動いていても、「エンジニアとしてのバリュー」を最大化し、本質的な課題解決ができていたかという点に大きな反省が残ったと思います。
なぜリリース前にこれらを予見し、一歩踏み込んだ議論ができなかったのか。その背景には、以下の3つの要因があったと考えています。

なぜ私は「提案」ができなかったのか：3つの「ない」

一次情報を取りに行けていない
提示された要望をそのまま「完成形」として受け取ってしまい、その裏側にある現場の振る舞いまで想像が及んでいませんでした。
実際に使うユーザーが、どの画面から、どんな心理状態で、前後にどんな操作を行うのか。事業部と協力し、できるだけユーザーの生の声に近いものを拾いにいく、という努力が足りていなかったことで、「意図しない使われ方」を招く一因となりました。
実装解像度の不足：提案の「切り口」を整理できていない
初めてのメール配信機能の要件定義ということで、ドメイン知識が不足していたことはもちろんあります。しかし、単なる知識不足以上に、「何を明確にすれば、事業部へ建設的な提案ができるか」 という論点の整理ができていませんでした。
メール配信というドメインにおける懸念点や、仕様の分岐点となる要素を事前にインプットし、議論の土俵を自分で作ることができておらず、エンジニアの視点から「より良いプロダクトにするための問い」を立てられなかったのです。
当時の私は、複雑な条件分岐をそのままUIに落とし込んでしまったことで、特に 「仕様の複雑さ」と「UIのシンプルさ」のバランスを事業部と議論できていなかったと思います。実装前に「このUIだとシンプルですが、特定のケースでUXが損なわれます」といったトレードオフを複数の案として可視化して臨むことで、より使いやすい機能作りを事業部側とすり合わせながらリードできるはずです。
能動的に動けていない
メール配信という領域についての理解が浅かったために、POやマネージャーから提示された仕様を「そういうものか」と鵜呑みにするしかありませんでした。
自分の中に判断基準となる知識がないため、提示された内容に対して代替案を出す余地がなく、結果として 「言われたものをどう作るか」という受け身の姿勢に終始してしまいました。
ビジネス側との要件を詰めていくうえで、メール配信で発生しうるリスクの指摘や、要望に内包されている実現したい機能の意図を提案できず、ただ要件をこなすだけの受動的な開発になってしまったと感じています。

まとめ・学び

今回の要件定義の経験から学んだこと、それは「エンジニアが要望の背景にあるユーザーの想いや真の課題を理解しようと、能動的に一次情報を取りに行く姿勢は、『余計なこと』ではなく『歓迎されること』である」ということです。一次情報は磨けばダイヤになる原石がたくさん眠っている宝の山です。
この教訓を活かし、現在は経理チームをステークホルダーとしたプロジェクトで、「自ら現場に飛び込む」ことを実践しています。具体的には、経理メンバーの隣に座って業務を見学したり、時には自分でも実際の業務を行ってみたりしています。その中で生じた不明点や、「ここは本来どうしたいのか」「こういうレアケースはどう扱うか」といった疑問を、その場ですぐにヒアリングするようにしています。
現場の一次情報に触れたことで、開発の認識齟齬が減ったのはもちろんのことですが、現場の手作業の大変さを痛感でき、解決への強いモチベーションに繋がっていると感じています。
技術解像度を武器に、一次情報を取りに行くことで要望の裏側を掴み、議論の場に立つ。要望通りに作るという安心感から一歩踏み出すことが大切で、その「問い」がプロダクトだけでなく、自分も強くします。
これから初めての要件定義に挑む上で、不安を抱えているエンジニアの皆さんにとって、この記事が少しでも参考になれば嬉しいです！

さいごに

アソビューでは、「生きるに、遊びを。」を実現するための良いプロダクトを世の中に届けられるよう共に挑戦していく様々なエンジニアを募集しています。
カジュアル面談のご希望も随時お受けしておりますので、お気軽にエントリーください！
お待ちしております！
https://www.asoview.co.jp/career/engineer