はじめに
匠技研工業でプロダクトエンジニアをしている小森です。データとAIで最先端の工場経営を実現する『匠フォース』の開発をしつつ、お客様へのヒアリングやエンジニア採用をしています。
いよいよ弊社でもテックブログを始めます。記念すべき第一回目は『「なぜ作るか」を迷わない開発 - 全てのコード一行から顧客の声に辿れる仕組み』と題し、私が入社して最も感動したプロダクト開発の仕組みに焦点を当てます。
🔥 こんな方に読んでほしい
- 「この機能、本当に必要なの？」と思いながらも、背景がわからないまま手を動かしているエンジニア
- 背景知識の共有をより効率的に行いたいPdM
- 開発プロセスを効率化して、本当に価値のある仕事に集中したいマネージャー
💡 この記事から分かること
- 顧客の課題を正しく理解し、最大の価値を最速で届ける仕組み
- コードから顧客の声まで辿れる、プロダクト開発のトレーサビリティ設計
- エンジニアが自信と納得感を持って開発していく方法
顧客の課題を正しく理解し、最大の価値を最速で届ける
匠技研工業は「フェアで持続可能な、誇れるものづくりを。」をミッションに掲げ、製造業サプライヤー企業に圧倒的なDXを届けることを目指しています。この目標を達成するためには「顧客の課題を正しく理解し、最大の価値を最速で届ける仕組み」が必要です。
匠技研工業では、以下のようなステップでこれを実現します。
-
顧客の生の声を集める（🗣️ VoC、👤 顧客DB、🗒️ 議事録DB）
-
課題を正しく理解し、確実な価値に落とし込む（📝 PRD）
-
最も重要な価値を最速で届ける（📁 バックログ）
顧客の生の声を集める（🗣️ VoC、👤 顧客DB、🗒️ 議事録DB）
プロダクト開発は一次情報を集めることから始まります。お客様から寄せられた声や社内から出た声は「🗣️VoC（Voice of Customer）」としてNotion のデータベースに集約されます。
- 例）
-
OCR検索した部分を色を変えて欲しい- お客様から寄せられた声（要望） -
図面差分表示めっちゃいいね！感動する！- お客様から寄せられた声（喜び） -
今のステータス管理だと分業がしづらそう- 社内から出た声
-
これらは「👤 顧客DB」「🗒️ 議事録DB」と関連づいており、どのような特徴を持つお客様が、どのような会話の流れでその声を発したかまでが記録として残っています。
担当者のメモ、会議の録画、AI文字起こし、AI要約が残っているため、前後の文脈や温度感、表情まで知ることができます。（Bizチームの運用の徹底ぶりに感謝です🙏）
👤 顧客DB
🗒️ 議事録DB
ところで、匠技研では顧客の声を「そのまま載せる」ことにこだわっています。なぜでしょうか？
顧客の言葉を編集すると、重要なニュアンスが失われることがあります。顧客が本当に困っていることや感じている不便さ、その温度感こそが重要です。これをダイレクトに伝えることで、エンジニアが自ら顧客の気持ちに寄り添い、課題解決の意欲を強く持つことができます。
さらに、課題や要望だけでなく「助かった！」「これは便利だね！」という生の喜びの声も直接届くため、エンジニアのモチベーション向上にも繋がります。
「🗣️ VoC」にはそのまま声を載せますが、同時にそのまま鵜呑みにしてはならないというのも重要なポイントです。ある顧客がある機能を熱望していたが、よくよく話を聞いてみたら既存機能の使い方を工夫するだけで解決したというケースはよくあります。
「🗣️ VoC」はあくまでファクトとして捉え、それを解釈して打ち手を考えるのが「📝 PRD」です。
課題を正しく理解し、確実な価値に落とし込む（📝 PRD）
VoC を受けて「どういう機能を、なぜ、どのように作っていくのか」を定義するドキュメントを PRD（Product Requirements Document）と言います。「📝 PRD」という Notion のデータベースに集約され、プロダクトチームが仮説検証します。
- 例）
-
多軸マスタの管理工数を削減する- 実装中の機能 -
過去見積検索- リリース後検証中の機能
-
エンジニアであれば「この機能、本当に必要なの？」と思いながらも、背景がわからないまま手を動かしてしまった経験があるのではないでしょうか。
またはマネージャーから説明を受けた初日は腑に落ちていたけれど、実装を進めるうちに目的が曖昧になり、『顧客が本当に必要だったもの』とは全く別物になってしまったというのもよくあると思います。
このような事態を避けるために「誰が、どんな課題を抱えていて、それをどのような方法で解決するのか」を明確に定義し、チーム全体で共有するための仕組みが「📝 PRD」です。
「📝 PRD」には単に機能の仕様を並べるのではなく、
- 背景（誰がどのような課題を抱えているのか、なぜこのタイミングで作るのか）
- ターゲット（具体的にどの顧客のどんな業務上の課題を解決するのか）
- 機能要求（どういった体験が実現できるべきか、どういった体験は実現できなくても良いか）
- 検証方法（提供した機能が適切だったかをどうやって確認するのか）
といった項目を必ず記載します。
「📝 PRD」を記載したら、プロダクトチーム全体で定期的に優先順位を検討し、優先順位の高いものから「📁 バックログ」に落とし込んで対応していきます。
最も重要な価値を最速で届ける（📁 バックログ）
「📝 PRD」という大きな機能を踏まえた上で、それを実装・調査可能な粒度に分解してタスク化したものが「📁 バックログ」に積まれていきます。
- 例）
-
ユーザーはセットの並び順を変更したい。なぜならよく使うものを上に表示したいからだ。- ユーザーストーリー -
QuotationAttributeSetエンティティにpriorityを追加する- タスク -
図面を回転するとOCRが大きくズレるバグの修正- バグ
-
「📁 バックログ」は優先順位が高い順に並んでおり、ステータス・実装担当者・レビュワー・ストーリーポイント（工数）が一目でわかるようになっています。
これによって、エンジニアが自分の担当タスクだけでなく、チーム全体のタスクの優先順位やステータスを確認し、進捗に応じて柔軟にタスクを再配分することが可能になります。
「📁 バックログ」の中で特に優先順位の高いものはスプリント（1週間単位の開発サイクル）に入れられ、スプリント終了時に全て完了になることを目標にします。
あとは一般的な開発現場と同様に、実装が完了したら Pull Request を作成します。このとき、Pull Request のタイトルにタスクID（例：TF-3350）を付けることで、Pull Request と「📁 バックログ」を紐付けることができます。
実例
では、上記の仕組みは開発現場でどのように活用できるのでしょうか？「案件一覧ページにフリーワード検索を実装する」という実際のタスクを例に見ていきましょう。
エンジニアは「📁 バックログ」に記載の要件を確認した上で、技術的可否を検討し、必要であれば提案しつつ、設計から実装までを担当します。
「📁 バックログ」を確認すると、ざっくりと以下のような要件が記載されていました。
フリーワード検索のBE実装
- AND検索（半角・全角スペースをセパレータに語句を分割する）
- OR検索（半角・全角スペースをセパレータに語句を分割する）
- 部分一致検索（全ての語句が、いずれかの検索対象に部分一致すればヒットする）
- 曖昧検索（大文字・小文字、全角・半角は区別しない）
ここで次のような疑問が生じたとします。
「そもそもなぜフリーワード検索が必要なんだろう？既存の絞り込み検索ではダメなの？」
「AND検索とOR検索の両立はかなり工数が増えるけど、本当に必要なの？」
このような疑問が生じたら「📝 PRD」や「🗣️ VoC」を確認します。
「📝 PRD」を確認すると、以下のような記載がありました。
検索結果にヒットしやすくする（フリーワード検索・曖昧検索など）
- 案件一覧ページの絞り込み検索には以下の課題がある
- 単一項目においてAND検索はできないため、目視確認の手間が大きい
- 例）案件名で「パンチング チューブ」のAND検索をしたいときは、「パンチング」と調べた後に目視で「チューブ」を確認する必要がある
- 複数項目で絞り込むためには、必要な工程が多く手間が大きい
- 「絞り込みを追加」→「項目を選択」→「絞り込み内容を入力」という手順が複数回必要になる
- 競合サービスではフリーワード検索が存在するため、劣位にあたる
これを見ると、確かに既存の絞り込み検索の工夫したり拡張したりするのではなく、フリーワード検索を実装した方が良さそうです。
「🗣️ VoC」まで遡ると、以下のような声が紐づいていました。
案件一覧の検索で2単語以上で部分一致検索できるようにしてほしい（〇〇工業様）
ユースケースとしては、案件名に「工事番号 工事名称」を入れるため、工事番号と工事名称どちらも部分一致検索するというもの。
以上を踏まえると、「2単語以上で部分一致検索したい」というニーズはあるようですが、今回必須となるのはAND検索のみで、OR検索は必須ではなさそうです。
よって「OR検索がなくても顧客の課題を解決することは可能である」ことをマネージャーに伝え、顧客に価値を提供できる最小限の機能として以下のように「📁 バックログ」を再定義することができます。
フリーワード検索のBE実装
- AND検索（半角・全角スペースをセパレータに語句を分割する）
OR検索（半角・全角スペースをセパレータに語句を分割する）
- OR検索がなくても顧客の課題を解決することは可能である
- 部分一致検索（全ての語句が、いずれかの検索対象に部分一致すればヒットする）
- 曖昧検索（大文字・小文字、全角・半角は区別しない）
では、実装から数年後に「フリーワード検索でOR検索をしたい」という「🗣️ VoC」が上がり、別のエンジニアが実装を担当することになった場合はどうでしょうか？
以下がフリーワード検索の関連コードと思われますが、一見してどのような条件で検索されているのか分かりづらいです。
if (searchWords.length > 0) {
const multiMatchQueries = searchWords.map((word) =>
ProjectIndex.fields.name.multiMatch(searchFields, word)
);
andConditions.push(...multiMatchQueries);
}
そこで Git Blame や GitLens（VSCode拡張）を使えば、そのコードが実装された commit や Pull Request を特定することができます。Pull Request は「📁 バックログ」に、「📁 バックログ」は 「📝 PRD」 に、「📝 PRD」 は 「🗣️ VoC」 に紐付いています。
結果として、コード一行から背景にある仕様・要件・顧客の課題、さらには元となった生の声まで遡ることができ、的確な実装判断が可能になります。
まとめ
以上のように、匠技研工業のプロダクト開発では、顧客の声からコードまでが一貫して繋がっており、全ての判断に明確な根拠が持てる状態になっています。
この仕組みによって、エンジニアは「なぜこの実装をするのか？」を自ら辿ることができ、納得した上で開発に向き合うことができます。また、仕様を確認したり、改善を加えたりするときにも、過去の意思決定や顧客の声に基づいて行えるため、伝達ミスや属人化といった課題も起こりにくくなります。
最後に、エンジニアが自信と納得感を持って開発していくためには、その機能が課題解決に直結すると信じられることが重要だと考えています。そうして開発した機能がユーザーに受け入れられていると実感できることで、さらなる自信に繋がります。
「技術を駆使して顧客課題を解決したい」――そんな思いを持つエンジニアの方と、一緒にプロダクトをつくっていけたら嬉しいです。
Discussion