ヘンリーの kohii です。この記事は株式会社ヘンリー Advent Calendar 2024の8日目の記事です。前回は 小山さん の「出社回帰のニュースを見て思うこと」でした。

プロダクト開発（というかあらゆる仕事）で最もありがちで最もやっかいな問題の一つに、理解の不足を想像で埋めてしまうみたいなやつがあると思います。

• こんな感じだろうと思って作ったものが、顧客の業務にフィットせず使われない

• 分業で開発して、いざ結合しようとしたらお互いの想定が違った

• プラットフォームチームが作った最強の基盤が現場の欲しいものと違った

経験不足だと想像を膨らませすぎてこれにハマるし、経験豊富だと逆に既知に引き寄せて理解しようとして罠にハマります。現実の解釈や予測には多かれ少なかれ願望や先入観が混ざるというのもあります。
人間なんてそんなもんです。

理解不足とモノづくり

私は昔、人間中心デザインを学んでいたことがあります。初回の授業で投げかけられた問いは「人はなぜ使えないシステムを作ってしまうのか」ということでした。いくつかの事例が紹介されましたが、根本にあるのは「利用文脈（=製品が利用される状況や利用者の自身のこと）をよく知らずに想像で作っている」ということでした。

私は身に覚えがありすぎて辛くなりましたが、誰しも思い当たる経験があるのではないでしょうか。
（ちなみにヘンリーでは、業務の専門家や元顧客がチームに居て、このような不理解を補いやすくなっていてます。）

面倒だもの

ではなんで想像で埋めちゃうのかというと、一番は面倒だからだと思います。

顧客業務の理解度が低い自覚がうっすらあっても、多くの開発者にとって顧客のもとにインタビューや観察に行くのは心理的ハードルが高いですし、社内であっても相手との関係性や距離感によっては躊躇ってしまいます。時間的余裕がない状況下であればなおさら面倒です。

面倒という理由の他に、見通しの甘さや過信もありますが、こっちはいろいろ経験して痛い目にあえばだいたい解決するはずです。

処方箋

理解不足を補ったり認識をすり合わせたりするための具体的な方法はここでは書きません。その前段として理解不足を埋める行動をとれるかどうかの方がずっと大事です。

「面倒くさがるともっと面倒になる」可能性を直視する

一番辛いやつですが、これが一番だと思います。想像力は、理解の不足を埋めるためではなく、面倒くさがった場合に起こり得るもっと面倒なことを想定するために使いましょう。

想定されるダメージが許容できそうなら、そのまま進めばOKです。

面倒くさくならない環境を作る

チームや社内のことであれば、わからないことを素直に聞ける関係性を構築するのが大事だと思います。

「発言・質問しても変に思われたり馬鹿にされたりしない確信度」みたいなのことを心理的安全性と言いますが、元からこの心理的安全性を感じやすい人は、そうでない人がいるということを心に留めておくのも大事です。
また、安直ですが「なんでも聞いてね」宣言をしておくのは効果的です。私は新メンバーを迎えるときに「10分考えてわからなかったら聞いてください」という声かけをすることがあります。「こういう理解でいいですか」という確認は、その理解が間違っていたときこそありがたいものです。

また、定期的な Sync-up ミーティングや朝会などの場を設けて、疑問点の確認や相談をしやすい状況を用意するのも良いと思います。

早く、小さく失敗する

理解不足を埋める作業に時間を費やすより、まずアウトプットを作って、それを元に認識がズレている部分を明らかにした方が早いことはあります。

動くプロダクトは最も効果的なコミュニケーションツールであり、枝葉や仔細を削ぎ落として最短で動くものをチームやユーザーに見せられるように作るのはとても大事なことです。

生成AIのパワーによって今後この手段を取れる状況が増えていくと思います。

おわりに

いろいろ書きましたが、これを書いている自分もまた同じ失敗をしてしまうんだろうなあと思います。ただ、経験を重ねてちょっとずつ賢くなっていきたいものです。