開発者によるユーザー業務の直接体験

Willoopのエンゲージメントサーベイで「理解・納得」のスコアが低いとき、組織では「自分の仕事が何に向かっているのかわからない」という感覚が広がっています。目の前のタスクをこなしてはいるものの、それがどんな価値を生んでいるのかが実感できていない状態です。この施策は、その課題に直接アプローチします。

こんな悩みを解決できます

開発者やデザイナーがユーザーの業務実態を表面的にしか理解できておらず、「この機能、本当に役に立っているのか？」という確信を持てないまま開発を進めてしまっている。提案や設計の根拠が薄く、チームの説得力にも欠ける。

こんなサーベイ結果の時に効果的です

Willoopのサーベイにおいて、以下の設問のスコアが低い組織に特に推奨されます。

• 「自分の仕事の目的や内容を十分に理解し、その意義に納得している」（理解・納得）
• 「業務について自分の意思で『やりたい』という気持ちの方が、役割として『やるべき』という感情より強い」（自分事化）

開発者やデザイナーがユーザーの実態を知らないまま仕事をしている組織は、こうした設問のスコアが下がりやすい傾向があります。「なんのために作っているのか」が見えにくいからです。

具体的な実行施策

• 開発者自身がユーザーとして業務を一通り体験する — 実際の業務ソフトを使って入社手続き・勤怠管理・給与計算などを一周する。完璧にこなす必要はなく、「何から始めればいいかわからない」という戸惑いそのものが改善ヒントになる
• 社内のユーザー部門の業務現場に直接出向き、作業を観察する — オンラインインタビューでは見えない"作業の流れ"や"無意識の操作"を現場で発見できる
• 観察後すぐにプロトタイプを作り、ユーザーの目の前で価値検証を行う — 観察から数日以内に動くものを見せることで、仮説の精度を素早く上げられる

施策の優先順位の目安

期待できる効果

開発者が「知識として知っている業務」と「実際に手を動かして感じる業務」の間にある大きなギャップに気づきます。freeeのデザイナーが書店の労務業務を実際にやってみたところ、最初の壁は「何から始めればいいかわからない」ことでした。入社手続きだけで50以上のタスクがあり、「これが本当に必要な作業なのか」「いつまでにやるべきか」の判断から難しかったといいます。

この体験を通じてチームには「あの画面の動線、使う人には当然わからないよね」という共通の土台が生まれます。仕様議論のスタート地点が変わり、より本質的な課題解決につながる提案が自然とできるようになります。

セルフチェックリスト

自組織に当てはまるものがあれば、この施策を検討してみてください。

• 開発メンバーがユーザーの実際の業務フローを体験したことがない
• 「なぜこの機能を作るのか」をチームで共有する場がない
• ユーザーインタビューはしているが、改善のアイデアが表面的になりがち
• 設計や提案の場で「本当にユーザーはそう感じるの？」という議論が繰り返される

参考リンク

• 業務理解をより深める：観察、体験によるアプローチ（freee・note）