PROFILE
田制 成章 東京開発統括部 フロントエンド開発課 課長
宮城 周 開発推進部 AI開発課 課長
【導入】計画と現実の狭間で。向き合うべき「顧客の声」
計画（ロードマップ）を着実に進めることは、プロダクトを継続的に成長させるうえで欠かせない。一方で、顧客が直面する課題は、導入環境や業務プロセス、周辺ツールの変化などによって日々変わり得る。そうした変化が重なったとき、当初の計画に加えて、緊急度の高い要望へ向き合う判断が必要になることがある。
本記事では、顧客の声を起点に開発計画を見直し、結果として価値提供につながった2つの事例を紹介する。いずれも「場当たり的な変更」ではなく、背景の理解、影響範囲の見立て、関係者との合意形成を経て、納得感のある意思決定へ至ったプロセスだ。個別の顧客情報や内部仕様の詳細は伏せつつ、開発者の視点から、計画変更の裏側にあった葛藤と判断のポイントをまとめる。
【第1章：優先順位の見直しで価値提供を早めた】フロントエンド開発課『領収書プレビュー機能』
【ビジネスの課題】
提案・導入の現場から、「この機能があると安心して使える」「確認負荷を下げられる」といった声が継続的に挙がっていたのが、領収書プレビュー機能だった。ユーザーが日々扱う領収書の情報は、確認のしやすさが業務効率や心理的負担に直結する。
そのため、当初計画していた提供時期のままでよいのか、ビジネスサイド・開発サイド双方で再検討が始まった。
【開発の決断】フロントエンド開発課・田制さん
「現場からの声を受けて、まずは“どこまでを、どれくらいの期間で提供できるか”を冷静に見立てました。やみくもに前倒しするのではなく、価値の単位を分解して、実現可能性と影響範囲を確認するところから始めました」
検討の中で大きかったのは、「フロントエンドの実装だけでも、一定の価値を先に届けられる」という見通しが立ったことだった。バックエンドの大きな改修を伴わず、影響範囲を限定しやすい。これにより、チーム内でコントロール可能な形で優先順位の見直しを進められた。
「最初の段階で簡易なプロトタイプを作り、関係者と“目指す体験”の認識を揃えました。そのうえで、短いサイクルで画面を共有し、フィードバックを受けながら仕様と実装を並行で進めました。結果として、手戻りを抑えつつ、価値提供のタイミングを早めることができました」
この経験は、開発の優先順位を考えるうえでの学びにもつながったという。
「“ビジネス上のインパクト”と“技術的にどこまで分割して提供できるか”をセットで考えると、計画の見直しが建設的になります。品質を守りながらスピードを上げるには、関係者と早い段階で合意形成することが重要だと実感しました」
【第2章：厳しい指摘を起点に、業務の安定運用につなげた】AI開発課『領収書OCR』
【ビジネスの課題】
あるお客様から、領収書OCRの結果について改善要望が寄せられた。
具体的には、読み取り内容が期待どおりにならないケースが発生し、申請・確認の手間が増え、業務が滞る可能性があるというものだった。
OCRの読み取り結果は、その後続の申請・承認プロセスに影響する。特に「意図しない内容で読み取られてしまう」ことは、差し戻しや再申請などの手戻りを生み、現場の負担につながる。顧客影響を抑えるため、早期の改善が求められた。
【開発の判断】AI開発課・宮城さん
「最初にやったのは、“何が起きているのか”を落ち着いて整理することでした。現場の声は切実なので、まずは事実を集め、影響範囲や再現条件を把握するところから始めました」
今回の対応では、プロダクト全体を大きく変えるのではなく、比較的独立した領域で改善できる余地があることが分かった。そこで、顧客影響を抑える観点から、短いサイクルで改善を届けられる範囲に焦点を当てて進める方針を選んだ。
「次に大事にしたのは、“お客様が本当に困っているのは何か”を解像度高く捉えることでした。読み取りの話に見えても、実際の痛みは“業務が止まる”“確認や手戻りが増える”といった運用面に現れます。どこで困りごとが増幅しているのかを、ビジネスサイドと一緒に整理しました」
そのうえで、改善の方向性は「読み取り結果そのもの」だけではなく、後工程の業務が安定して回ることを重視して定めた。要件整理はPdMが素早くまとめ、関係者間の認識を揃えながら実装・検証を進めたことで、一定の期間の中で改善を届けることができた。
「具体的な実装はチーム内のノウハウも含むので詳細は控えますが、ポイントは“お客様の業務が安全に回る状態”を目標に置いたことです。技術としての正しさだけでなく、実運用の負荷や手戻りがどう減るかを軸に判断しました。結果として、現場の混乱を抑える助けになったと感じています」
【提言】計画変更を“前向きな学び”に変えるために
今回の2事例に共通していたのは、単に要望を受けて計画を変えたのではなく、
・背景（なぜ困っているのか）の理解
・影響範囲とリスクの見立て
・価値を分割して、早く届ける工夫
・関係者との合意形成と期待値調整
を丁寧に行っていた点だ。
そのうえで、開発とビジネスの連携をさらに前に進めるためのヒントとして、2人は次のように語る。
田制さん（フロントエンド開発課）
「要求の背景にある“なぜ”が分かると、価値の分解や代替案の検討がしやすくなります。開発側も、制約や可能性を早めに共有し、よりよい落としどころを一緒に探していきたいです」
宮城さん（AI開発課）
「要望をそのまま実装するのではなく、困りごとの構造を一緒に捉えるパートナーでありたいです。そのためには、一次情報の共有が本当に大事で、小さな違和感でも早めに知れると助かります」
【まとめ】コードの先に、顧客がいる。
計画は重要だ。しかし、計画に固執するあまり、目の前の顧客の痛みから目を背けてはならない。
開発とビジネスは、プロダクトを前に進めるための車の両輪だ。顧客という目的地を見据え、必要ならルートを見直しながら、価値提供を続けていく。
今回紹介した2つの事例は、開発チームが顧客と真摯に向き合い、状況を正しく理解し、リスクを見立てたうえで意思決定を積み重ねた結果だ。
私たちの書く一行のコードの先に顧客がいる。その喜びと責任を胸に、これからも顧客志向の開発を追求していきたい。
