お疲れ様です！ プロダクトエンジニアの石倉です。
実は今回が初のブログ投稿となります、お手柔らかにお願いしますw
はじめに
私はエンジニアとして「単に仕様通りに作る（How）だけでなく、それが本当にユーザー価値・事業価値につながるのか（What/Why）を問い続けるべきだ」というこだわりを持っています。
（AIの台頭なども含め）これからの時代、技術力だけで価値を出し続けるのは難しく、ビジネスの課題解決にどれだけ深くコミットできるかが、エンジニアの市場価値を決めると考えているからです。
しかし、ニーリーに入社した当初は、そのこだわりが空回りしていました。 「プロダクト志向」を自負していましたが、ある評価面談でのフィードバックをきっかけに、自分のスタンスが独りよがりなこだわりでしかなかったことに気づかされました。
「#ニーリー開発組織の野望」第10弾の今回は、私の「こだわり」が、いかにして本質的な「価値創出」へと変わっていったのか、その実践例についてお話しします。
「プロダクト志向」の落とし穴
以前の私は「この機能はユーザーのためになってるはずだ」「自分のコードがビジネスに貢献してる」と信じつつも、こだわりが先行して表層的な開発に終始していました。ユーザーのことを考えているつもりで、実はHow（どう実現するか）ばかりに目が行っていたのです。
そんな中、入社後初の評価面談で、以下のようなフィードバックをもらいました。
顧客要望を素直に受け入れすぎ
業務・オペレーションに対するDeep Diveが足りない
振り返ってみると、まさにその通りでした 。 What/Whyを問うというこだわりを持っていたはずが、実際には顧客の要求の背景にある業務やオペレーションへの理解が全く足りていなかったのです。
もう一歩先の価値を出すために意識したこと
この反省を踏まえ、自分のこだわりを本質的な価値貢献に変えるため、次の2点を強く意識するようにしました。
1. Who / What / Why を意識したコミュニケーション
「誰の」「何を」解決するもので、「なぜ」それを今やるべきなのかを徹底的に整理します。疑問点や不足情報があれば、その時点ですぐにヒアリングを行うようにしました 。
2. リリース後の運用まで関心を持つ
こだわりが空回りしていた最大の原因 ＝ 業務理解の不足を解消するためです。機能はリリースして終わりではなく、運用に乗って初めて評価されます。運用に乗らない機能は評価すらされません。そのため、既存の業務・オペレーションを深く理解し、新機能をどう組み込めばユーザーにとって使いやすくなるか、より価値を感じてもらえるのかを模索するようにしました。
実践エピソード：申込者の審査自動化機能
実際にこれらの意識をどう開発に落とし込んだか、Park Directの「申込者の審査自動化機能」の実装を例にご紹介します。
要求の背景
当初の要求は、「申込者情報が特定条件に抵触するかを自動判定し、抵触したものは担当者が目検でチェック、抵触しないものは自動で審査通過としたい」というものでした。
Who / What / Why の深掘り
私はまず、現状（As-Is）とあるべき姿（To-Be）の把握に努めました。
Who / What（誰の、何を）
一部の申込者に対して担当者が目検で審査を行っており、これに多大な工数がかかっている状況でした。目指すのは、担当者が本来やるべきコア業務にリソースを集中できる状態です。
Why（なぜ）
新規申込の増加に伴い審査対象も増え、工数が逼迫していました。情報の特性上、業務分散も難しいため、システムによる自動化で省力化を図る必要がありました。
こうして期待する効果の具体を知り、抑えるべきポイントを明確にすることで、期待値とのギャップを小さくしました。
実際には、上記の他にも審査オペレーションに関する詳細（例：審査方法や審査ロジックについて）の整理・確認ももちろん行なっていますが、長くなってしまうので割愛します。
運用・オペレーションの全体像把握
次に、局所最適ではなく全体最適を図るため、申込から審査、契約締結に至るフロー全体を把握し、どこをどう改善すべきか具体的に特定しました。
具体情報による仮説検証
要件が固まりきるのを待つのではなく、ワイヤーフレームやプロトタイプを素早く作成しました。言葉だけの要求解釈では、期待ギャップが生まれてしまいます。顧客が言語化できていない暗黙知を引き出すためにも、仮定ではなく、具体的なユースケースやプロトタイプを用いて議論し、早期にフィードバックを得ることが重要です。
これらアプローチの結果、受入テスト段階で関係者から「操作体験が非常に良い」「別事業でも売り込みたい」といった嬉しい声をいただくことができました。
意識を変えて得られた3つの成果
意識を変えたことで、以下の成果が得られました。
1. 致命的な手戻りの削減
細部まで認識をすり合わせることで、開発側と要望側のギャップが埋まり、大きな手戻りがなくなりました。ビジネスサイドからの信頼度も上がったと感じています。
2. オーナーシップの向上
解像度が粗い状態での開発ではなく、細部まで考え抜いて開発することで、結果を「自分ごと」として捉えられるようになりました。その積み重ねが自信と強いオーナーシップにつながっています。
3. フロー効率を重視した段階的リリース
「今本当に必要なこと」が明確になるため、最初から100点を目指さず、必要な価値を最速で届ける意識が持てるようになりました。
実際に上記のエピソードにおいても、当初実装を予定していた機能について一部意図的にスコープアウトしたものもございます。その判断も、その機能が実業務にどれだけのインパクトが出るものなのかを事前に運用者・開発者間で認識が擦りあっているからこそ実現できたことでもあります。
このように、結果として「やりすぎ」な開発を避けることにもつながります。
まとめ
顧客要求をそのまま実現してしまっていた私ですが、以上のような経験を経て、それが必ずしも正しくないことを学びました。
より一歩先の価値を創出するためには、まずは「顧客にとって一番の理解者」となり、課題の本質が何なのかを互いに理解を深め、認識を合わせることが重要です。
このWhyを問い、「顧客の課題を深く理解する」姿勢こそが、私のエンジニアとしての新しいこだわりです。
プロダクトエンジニアが価値を出すために意識すべきことはシンプルです。
わからないことをわからないままにしない
業務や課題を知らないままでは良いものは作れません。可能な限り現場と課題の解像度を上げることが、確度の高い価値創出につながります。
なるべく具体情報を用いて関係者と頻繁にコミュニケーションする
「エンジニアが考える最強の機能」は、得てして独りよがりになりがちです。期待ギャップを生まないよう、仮定の話ではなく、具体的なユースケースやプロトタイプ等を用いて語りましょう。
おわりに
今回は、私の表層的な「こだわり」が本質的な「価値貢献」に変わるまでの一例をご紹介しました。
ニーリーでは、今まさにマルチプロダクト化を推し進める動きが活発化しています。事業が複雑化・多角化していくフェーズだからこそ、エンジニアがHowだけに閉じこもらず、Whyを問い、事業の解像度を高く持つことが不可欠です。
このこだわりを活かしてこれからのニーリーの事業成長をさらに加速させていくこと、これが私の野望です。
ニーリーでは「今、”いいもの”を作る」というバリューのもと、プロダクトや事業に自分ごととして向き合える環境があります。
エンジニアリングの先にある事業成長や顧客の感動を体感したい方にとって魅力的な環境だと断言できます！
興味が湧いた方はぜひカジュアル面談でお話しできればと思います！
▼カジュアル面談はこちらから！ nealle.notion.site
