プロダクトのユーザー体験を守る最後の砦というマインド

0→1のプロダクト開発をやっていて、「顧客に刺さるはずだと思ったことが外れる」ことは度々ある。 仮説や見立てが甘くて、顧客の「めっちゃ欲しいもの」ではなく、「あったら良さそう」をそのまま真に受けてしまうケースだ。このギャップは思っているよりずっと深い。

「売れる」と「使われ続ける」は、必ずしも一致しない

営業、事業サイド、代表、CTOたちとプロダクトを作っていると、それぞれが鋭い視点を持っている。「こうすれば売れるのでは」「この機能があれば決裁が通るのでは」・・・そういう議論が活発に起こること自体は、本当に有難いことだ。

ただ、自分がPdMとして最近意識していることがある。

「売れるためにすること」のすべてが、「ユーザーのためになること」とは限らない。

この二つが一致する場面もある。でも一致しない場面も、思っているよりずっと多い。そういう場面で、敢えてブレーキを踏む役割が必要だ。それがPdMだと思っている。

「決裁者」と「ユーザー」が別な人

今開発しているのはBtoBのプロダクトで、登場人物として大きく2人いる

• 決裁者：予算を持ち、契約を判断するマネージャーやリーダー
• エンドユーザー：日々、実際にそのプロダクトを使う現場の人

この二者は別人であることがほとんどだ。そして0→1でプロダクトを作り、「より売っていこう」とすればするほど、プロダクトは「決裁者が頷くもの」へと引っ張られていく力学が自然と生まれる。そして営業ドリブンで動いた結果、エンドユーザーにとって使いにくいプロダクトが出来上がる。

現場への影響を想像する

少し雑で極端な例えだが、こういうイメージ

「チームの誰がどこでつまずいているかを追いたいはずだ。成果が伸び悩んでいるメンバーが人目でわかる状態にすれば良いのではないか。」

ビジネス観点でいえば、一定の論理がある。マネージャーはチームのボトルネックを把握したいし、そのニーズを解決するプロダクトは恐らく「決裁が通りやすい」。

ただ、実際にそのプロダクトを使う現場のメンバーはどう感じるのだろうか？

自分のパフォーマンスが社内で可視化・ランキングされる環境で、人は安心してツールを使い続けるだろうか。むしろ、ツール自体を「監視装置」として敬遠するようにならないか。ツールへの信頼が失われると、良い機能であったとしても使われなくなるだろう。

最後の砦というマインドセット

社内の様々な立場の人が各自の視点で「ああすれば良い、こうすれば良い」と言ってくれることは、とっても有難いことだ。ただそこで、PdMとして意識したいことは

• 「これは誰のためのプロダクトなんだっけ？」
• 「使い続けてくれる人は誰なんだっけ？」

かなと思っている。事業とプロダクトの間に立ってバランスを保ち、プロダクトのユーザー体験を守ることもPdMの大事な役割だと考えている。

ユーザー体験を守ることは、長期的には事業を守ることでもある

誤解されたくないのは、「ユーザー体験を守る」と「事業を伸ばす」が対立するものでもなく、トレードオフでもないということだ。そして、とにもかくにも「事業・売上を伸ばす」ことが重要な場面も当然ある。

短期的には「決裁者が喜ぶ機能」を優先すると受注率が上がるかもしれない。でも、エンドユーザーが使わないプロダクトは、契約更新時に必ず離脱される。「契約したけど現場が使ってくれない」と「費用対効果が見込めない」という事態になるからだ。だから、ユーザー体験を守ることは、長期的なLTVを守ることでもある。

砦としての在り方

事業サイドへ何でもかんでも「ちょっと待った」と噛みついているという印象になったかもしれないが、別に反対することが目的ではない。ただ、問い直してより良い意思決定にすることが目的である。

恐らくPdMである自分自身もGoを出したらそのまま開発チームが開発をしてくれてリリースすることになる。 だからこそ「この判断は事業のためになっているか、プロダクトのためになっているか、そして顧客のためになっているか」を、Goを出す前に熟考するのだ。事業やプロダクトの様々な事情を考慮した上で、それでも「これで良いのか」と一度立ち止まれるかどうかがPdMとしての誠実さであり、重要な役割の一つだと思っている。

考え方・フレームワークを「後出し」で使う

プロダクトマネジメントに関するフレームワークは溢れている。プロダクト戦略、ユーザーリサーチ、優先順位づけ、ロードマップ。何かを考えようとするたびに「こういうフレームワークがあるよ」と誰かが教えてくれる。本で読んで「なるほどなー」と思ったものも多いし、実際に仕事で使ってみたものもある。

でも正直、フレームワークを先に知った状態で使うと、どこか「穴埋め作業」になりがちだった。用意された枠に情報をはめ込んでいく。一応まとまるし、それっぽい成果物にはなる。でも「自分で考えた」という実感が薄い。なんとなく借り物の思考で走っている感覚があった。結局、何故そのまとめ方をするのが良いのかが腹落ちしていない状態だったから。

最近、このやり方を変えてみた。

■まず自分で考え切る

先にフレームワークを当てはめるのではなく、まず自分なりに情報を出し切って、自分なりに整理しきる。 何も見ないで、自分の頭にあるものを全部出す。雑でもいいから構造化してみる。「これが論点だと思う」「ここが分かっていない」「この辺が優先度高いはず」と、自分なりの地図を描く。

正直、きれいにまとまらない。抜け漏れもあるし、軸がブレたりもする。

その後にフレームワークを見る。すると「あー、こうやってまとめればよかったのか」とか「この切り口は自分にはなかった」という気づきが、本で読んだときとは比べものにならないくらい刺さる。

たとえば、自分なりに整理したときには「ユーザーの課題」と「ビジネスの制約」を別々に並べていたのが、あるフレームワークではそれを一つの軸の上で対比させていたりする。「なるほど、分けるんじゃなくて、ぶつけるのか」と。この発見はフレームワークを最初から使っていたら絶対に得られない。自分で一度整理に苦しんだからこそ、他人の整理の巧さに感心できる。

「知ってる」と「わかる」は全然違う 本やブログでフレームワークを学んだとき、「知ってる」状態にはなる。人に説明もできるし、スライドに書くこともできる。でもそれは表面的な理解であって、自分の仕事に当てはめて使いこなせるかというと別の話だ。

自分で考え切った後にフレームワークを見ると、「知ってる」が「わかる」に変わる。以前に本で読んでなんとなく知っていた概念が、自分の試行錯誤を経た後だと全く違う解像度で入ってくる。「あの本に書いてあったのはこういうことだったのか」と、過去の知識が改めて立ち上がる感覚がある。

この差は大きい。マジでデカい。「知ってる」は再現できないけど、「わかる」は再現できる。次に似た場面に出くわしたとき、自分の判断軸として機能する。

■同じ内容を別のフレームワークで書いてみる

もう一つ良かったのが、同じ内容を別のフレームワークで書き直してみること。

たとえば、あるプロダクトの課題を整理するとき、フレームワークAで書いたものをフレームワークBでも書いてみる。扱っている情報は同じなのに、切り口が変わると見える景色が変わる。Aでは「ユーザーセグメント」が主語になっていたものが、Bでは「ビジネスモデル上のボトルネック」が主語になったりする。

これをやると、各フレームワークが何を照らすのが得意なのかが体感でわかるようになる。「この種の問題にはこっちのフレームワークが向いてるな」という選球眼が育つ。フレームワークの「使い方」ではなく「選び方」がわかるようになる感覚。

そしてその理解は、誰かの解説を読んで得たものではなく、自分で書き比べて掴んだものだから、自分の言葉で語れる。これが一番の収穫だったかもしれない。

■フレームワークは穴埋めシートではない

フレームワークは思考の型であって、穴埋めシートではない。枠を先に見てしまうと、枠に入る情報だけを集めてしまう。本当は枠の外にある情報こそが大事だったりするのに。 先に自分で考えて、答え合わせとしてフレームワークを使う。もし自分の整理とフレームワークが大きくズレていたら、そのズレこそが学びになる。逆にほぼ一致していたら、自分の思考が筋の通ったものだったと自信になる。

どちらにしても、先に自分で汗をかいた分だけ、フレームワークから得られるものが増える。急がば回れ、ということなのかもしれない。普通っちゃ普通なことだよな

”確からしさ”集めて、より良い意思決定を

新規プロダクトの立ち上げでの気付き。

現場にヒアリングしに行ったら、自分が見えていなかったものがたくさん見えて、意思決定の質がかなり変わった。その体験を少し。

前提：自分の立場

社内の新規プロダクト立ち上げを担当している。「何を作るか」の意思決定そのものを任されている。

何を解決するために何を作るか、全部決めていかなきゃいけない。

まず仮説を立てた

課題を定義して、解決策を考えて、それが数字に効くはずだという仮説を立てた。定量データも見たし、市場の情報も調べた。ロジックとしてはまぁそれっぽい。技術的にも実現できそう。

ただ、このプロダクトを使うであろう現場の人たちが本当にこれを必要としているのかは、自分の中で確信が持てなかった。頭の中だけで組み立てたロジックかもしれない、という感覚があった。

モックを持って、現場に聞きに行った

高速でモックを作って、ユーザーになり得る4名に見せに行った。画面を一緒に触りながら率直な感想をもらう。

返ってきたのは、想定していなかった声だった。

「いきなりアプローチするのはキモいですよ。関係性がすべてなんで。」

自分のロジックでは「効率よくアプローチできる仕組み」が価値だと思っていた。でも現場の感覚では、効率化どころか信頼関係を壊すリスクだった。「キモい」という一言の中に、数字では見えない現場の感情が詰まっていた。

「KPIのためにこの機能は喉から手が出るほど欲しい。でも、実際に使える場面は25%もない。」

欲しいけど使えない。事業の論理（KPIに効く）とユーザーの現実（でも使える場面がない）が噛み合っていなかった。

「そもそもこの機能以前に、もっと手前に本当の課題がありますよ。」

自分が解こうとしていた課題より、もっと根本的なところにボトルネックがあった。

解像度がめちゃくちゃ上がった

ヒアリングで一番大きかったのは、仮説が合っているかどうかの答え合わせではなく、課題に対する解像度が一気に上がったこと。

• 自分が想定していなかった感情が現場にはあった
• 業務の細かいディテールが、ロジック上の前提を覆していた
• 現場は自分の想定を超える方法で、すでに課題を回避していた

特に、「この課題を解決するプロダクトを作ろう」と思っていたものを、現場はプロダクトなしで独自の運用で乗り越えていた、というのは面白い発見だった。

ロジック上は正しくても、定性的・感情的に受け入れられるかどうかは全く別の話だということも分かった。今のプロダクト開発でも、ユーザーの立場で感情的に自然か、納得感があるかという観点で考えるようになっている。

仮説を納得して捨てられた

ヒアリングの結果、当初の仮説はやめて次の仮説検証に進んだ。

これがスムーズにできたのは、「なぜダメか」の解像度が高かったからだと思う。現場の声という裏付けがあるので、納得感を持って捨てられたし、次に何を検証すべきかも見えていた。

もし3ヶ月作り込んでから「なんか違う」と気づいていたら、手がかりもなく途方に暮れていたと思う。早い段階で確かめに行けたのは正解だった。

意思決定の「強度」が変わった

ヒアリング前は、頭の中でロジックを組んで定例で説明していた。筋は通っているけど、現場を知らない自分が会議室で考えたロジックに、周囲が全幅の信頼を置けるかというと、まあ難しい。

ヒアリング後は、「こういう場面で、現場はこういう感情を持っていて、だからこうすべき」と語れるようになった。ロジックの骨格は同じでも、そこに現場のリアルが乗っているかどうかで、相手の受け止め方がまるで違った。

定例で「当初の仮説は現場では受け入れられない」と伝えた上で別の方向性を提案した時、ロジックだけの提案とは説得力が全然違ったし、自分自身も「なぜこう判断したか」を自信を持って語れた。

自分は知らないことが多い

ヒアリングで一番の気づきは、結局これだった。

自分は知らないことが多い。当たり前のことだけど、プロダクトの意思決定を握っていると、自分のロジックで全部カバーできると思い込みそうになる。

でも実際は、そのドメインで毎日深く仕事をしている人たちだからこそ持っている情報がある。経営層ですら、現場のディテールは知らないことがある。エンジニアの想定を超える感情を持っていたり、想像を超える方法で課題を回避していたりする。

だからこそ確かめに行って得た情報は、自分個人のためだけじゃなく、チーム全体の意思決定を支える武器になった。実際にヒアリングをきっかけに現場との関係性も変わって、別の施策の相談をもらえるようにもなった。

確からしさの集め方

ヒアリングの「正解のやり方」はまだ分かっていない。4名に聞いたけど、最適な人数はプロダクトの性質やフェーズによって変わるだろう。聞いた情報を鵜呑みにするリスクもある。

ただ、誰に・何人に聞くかは超重要だということは確信を持って言える。確からしさは量と質で担保するしかない。聞いた内容は「裏付け」として使うのであって、「答え」として使うのではない。

白紙の地図にピンを刺すな

会議室で組み上げたロジックだけでプロダクトの行き先を決めるのは、白紙の地図にピンを刺すようなものだと思う。

現場の声を聞いて、定量データを重ねて、確からしいものを一つずつ地図に描き込んでいく。その上で「ここに行く」と決める。定量を定性で、定性を定量で語れるように。

確からしさを1つずつ集めながらプロダクトを創っていく。自分がこの立ち上げで学んだ、大きなことだった。

「役割」に安心を求めるうちは、たぶん何もできない

「PMじゃない自分」を責めていた

正直に言うと、しばらくの間ずっとモヤモヤしていました。

PMではあるが、気づけば開発をしている。コードを書いたり、社内ツールを設計したりしている自分を見て、「なんでこれしてるんだろう」と思っていました。

プロダクトの方向性を決めて、ロードマップを引いて、チームをまとめて——みたいなイメージが自分の中にあって。キラキラしている仕事、というか。それに憧れていました。

でも最近、その「憧れ」自体がちょっとズレていたんじゃないかと思い始めています。

PM不要論を読んで、認識がひっくり返った

きっかけはログラスの二宮さんが書いた「PM不要論」という記事でした。

note.com

営業資料を作り、CMディレクションをして、導入事例の取材に行く。そういうことを全部やって初めて事業に成果が出た、という話が書いてあって、「あ、自分が思い描いていたPMと全然違う」と感じました。

PMとは「役割」ではなく、「事業を勝たせるために何でもやる人」なんじゃないか。そういう視点が、自分には欠けていたとなと痛感しました。

売れない、という無力感

今の職場は0→1のフェーズで、プロダクトはあります。でも正直、それだけでは売れない。営業やBiz側の動きがないと、まだ使ってもらえない。

過剰な言い方ですが、最初はそれを「Biz側の課題」だと思っていました。自分はプロダクトを作る人だから、売れるかどうかは自分の仕事じゃない、みたいな感覚です。

でもこれって、かなり他責だったなと今は思っています。

「なぜ単体で売れないのか」「何が刺さっていないのか」——それはPMにとって最重要課題のはずです。それを切り離して「Biz側がなんとかしてくれるだろう」と思っていた。GTM戦略を上長が決めて、自分はそれに乗っかっているだけだった。仮説を立てて、自分で検証を主導するということを、していなかった。

途中参加だから、とか、自分の領域じゃないから、という言い訳で、意思決定に踏み込まない選択をしていました。でも「水を差す」のがPMの仕事のひとつだったりしますよね。。。

マインドを変えていかないといけないこと

他責に気づいたうえで、じゃあ自分はどう変わるのかを整理してみました。

1. プロダクトを軸に、事業を成功させるために何でもする

何でも屋とPMの違いって、軸があるかどうかだと思っています。営業資料を作るにしても、開発をするにしても、「なぜこれがプロダクト・事業の成功につながるのか」を自分で説明できること。それがないまま動くのは、ただの便利屋です。

2. 事業の成功やユーザー体験を語れる

恥ずかしい話ですが、「なぜユーザーは使ってくれているのか」「どこに価値を感じてくれているのか」を聞かれたとき、ちゃんと答えられないことがありました。ユーザーがどこに価値を感じているのかも、自分の言葉で持っておかないといけない。

3. 提案で終わらず、決断と実行に責任を負う

Marty Caganの言葉を借りると、Empowered PMはoutcomeに責任を持ちます。「こうしたらいいと思います」で終わるのは提案屋で、PMじゃない。仮説を立てて、検証して、結果に向き合うところまでが自分の仕事だと思っています。

0→1フェーズでPMがやるべきこと、整理

上の定義から逆算すると、今の自分がやるべきことが少し見えてきました。

価値仮説を自分の言葉で持つ。 「なぜユーザーがこのプロダクトを使うのか」を言語化して、それを自分で検証しに行く。0から仮説を建てることも、それをどういう方法でどういう観点で検証して、どう評価するのかを決めることからしなければならないです。

顧客と直接話す。 なぜ買わないのか、何が刺さらないのかを、自分の耳で聞く。Biz側からの伝聞ではなく。より良い仮説を持ち、より良い検証が出来るように、信頼できる情報としての一次情報はとても大切です。

Product以外の3Pにも首を突っ込む。 PMF前は、Productだけ見ていても足りないです。Price, Place, Promotionにも関与しないと、「プロダクトはあるけど売れない」の原因が分からない。市場や顧客の課題を深く理解しないと、プロダクトが何を解決するのか、どう解決するのかを伝えられない。

コンサル部分を構造化する。 0→1スタートアップだと、プロダクトと人的サービスが混在しがちです。個別対応の中にパターンを見出して、「どこまでプロダクトで解決できるか」を設計するのもPMの仕事だと思っています。

内側の納得と外側の評価

最後に、まだ解決できていない悩みも書いておきます。

「PMとして市場で認められるか」という不安が、ずっとあります。開発したり、営業資料作ったり、Biz側の穴を埋めたりしていると、「一般的なPMスキル」がつかないんじゃないか、という怖さです。

でも今の自分の暫定的な答えは、「何をやるかは問わないけど、なぜやるかはプロダクトの視点で説明できる自分でいる」ことです。盲目的に何でも屋になるのは違う。ただ、プロダクトを軸にしたうえで、事業に必要なことに手を伸ばすのは正しいと思っています。

PMに憧れていた自分は、「役割という箱」に安心を求めていたのかもしれません。箱の外に出るのは怖いけど、事業を勝たせるためにはどんどん出ましょうという振り返りでした。

趣味で解く数学が楽しい

2026年になって、今年は資格を通して、今の仕事と関係ない知識をつけたいな〜って思って、数検2級の教材を買って、毎晩寝る前に眠くなるまで解いている。

ゴリゴリの文系で（関係あるのか？）英語とか世界史B、日本史Bが好きだったけど、テストとかではなく、趣味でする分には、数学の方が好きだな〜って気付いた。 因みに文系だから数検2級の範囲（数ⅡB）までしか学校で習ってない。

テストじゃないから楽しい

高校時代、数学は嫌いではなかったけど、そんなに自信があったわけでもない。 でも今、趣味で解いている分には楽しい。 この違いはプレッシャーがないからだと思う。間違えてもいいし、時間をかけてもいい。むしろ、時間をかけて色々試すことが許されている。思考が数学にしか向かなくなる感じが好きなんだろうな〜と思う。

数学そのものが好きかは分からない笑。でも、試行錯誤を重ねて自分の解き方の仮説を検証していくのは好き。「なんかこうやったら楽に出来そうだな」とか「いや、こっちのアプローチの方が早いかも」みたいに色々試して、答えに辿り着く。その過程が気持ち良い。

答えが合っていたときの達成感もあるけど、それ以上に「この解き方で合ってた」という確認が取れる瞬間が好きなのかもしれない。

フロー状態になる

数学を解いているとき、かなり集中していて直ぐにフロー状態っぽくなる。時間を忘れるし、音も聞こえなくなるような感覚。気づいたら1時間経っていたりする。 色々な仮説検証の繰り返し感が好きなんだろうな〜とか思ったりする。

数学も公式とか一定は覚えてないと始まらないんだけど、数学って創意工夫というか、試行錯誤で乗り越えられるというか、自分なりに色々試して答えに辿り着く感じがある。 歴史とか英語も好きだったけど、数学の「試行錯誤で乗り越える」感覚とはちょっと違う。

因みに、微積とか、数列とかが好きで、図形問題が苦手（普通に図形周辺の公式を特に忘れてる）

手書きの効用

あと、iPadに手書きで解いてて、思考が手書きの速度と同じになるというか、タイピングよりも敢えてゆっくり思考することが出来る。 タイピングだと、どんどん先に思考が進んでしまうけど、手書きだと今書いている文字・文章についてゆっくり頭に落とし込んでいる感覚になる。過剰な速さじゃない感覚。 書きながら「あ、ここ間違えてるな」とか「この式、もっと簡単にできるんじゃないか」とか、考える余白が生まれる。タイピングだとその余白が生まれる前に次の行に進んでしまう。

脳が休んでいるような感覚すらある（？）。休んでいるというか、適切な速度で動いている感じ。急がされていない。自分のペースで思考できている。 普段の仕事では、タイピングでガーッと書いて、ガーッと考えて、ガーッと進めることが多い。それはそれで必要なんだけど、手書きで数学を解いている時間は、そういう「速さ」から解放されている気がする。

仕事との共通点

この数学の体験と、普段の仕事での考え方が似ているなと思った。

「試行錯誤を重ねて仮説を検証する」 のは、プロダクト開発でのMVPやFail Fastと同じ構造だ。一つずつ検証して、答えに近づいていく。 数学も同じだなと思う。複雑な問題を前にしたとき、いきなり完璧な解法を目指すんじゃなくて、まずは一番シンプルなアプローチを試してみる。そこから学んで、次の一歩を考える。 数学の問題を解くときも、「こうすれば楽に解けるかも」と思っても、実際にやってみると上手くいかないことがある。でも、その「上手くいかなかった」という情報が次の手がかりになる。「じゃあこっちのアプローチは?」と次の仮説を立てる。

これって、仕事でも全く同じだと思う。 「手書きでゆっくり思考する」 のは、複雑化させずにシンプルな形で考えることに似ている。タイピングで一気に思考を走らせるんじゃなくて、一歩ずつ確かめながら進む感じ。 決断にはカロリーがかかる。疲れる。だからこそ、思考の速度を適切に保つことが大事なんだと思う。

数学を解いているときの「手書きの速度」は、思考を適切にコントロールできている感覚がある。急ぎすぎず、でも止まりすぎず。そういう速度で仕事でも考えられたら、もっと良い決断ができるんじゃないかと思う。

ってことで、仕事でもメモは敢えて手書きでしてみるってのをやってみようかな

より良い判断のためのシンプルさ

一つずつ検証する

文字通り、正に検証フェーズにいると、つい考えることが増える。増えるのは良いとして、仮説に仮説を重ねすぎて、勝手に複雑化させてしまう。

無限に広がるifルートを考慮しながら、次の一歩を考えすぎてしまう。不安で自信がないときは色々考えすぎてしまうんだと思う....

先輩からのアドバイスが刺さった。

仮説があるなら、まずはそれを一番シンプルな形でやってみたらいい。 その仮説自体を尖らせることができれば、それは十分MVPになり得る。

MVPに最初から完成度を求めるものではない

その話を聞いて、MVPに対する自分の捉え方が少し変わった。

MVPは「最低限の機能を揃えたプロダクト」ではなく、「仮説を最も鋭く検証できる形」そのものなのだと思う。

まずは仮説を極限までシンプルにする。スプレッドシートでも、手作業でも構わない。 それで試してみて、

• 足りなかった
• 想定と違った
• 思ったより価値があった

そうした結果が出てから、「じゃあ、次に改善するための仮説は何だろう？」と考えていけばいい。

MVPは一度作って終わりではなく、仮説を検証するたびに更新されていくものなのだと腹落ちした。。。

勿論、いつかはスプレッドシートでは無理なタイミングが来る。そもそもスタート時点でスプレッドシートでは無理な可能性すらある。

その時は、「失敗」ではなくて、次の仮説検証に進む準備が整ってきたということだと思う。手探りな状態ならば、尚更、一歩一歩を大切にするというか、自分の中にある仮説を検証できる状態にして、検証をして進むことが大切だなと感じた。

Fail Fast

早く学び、次の一歩へと進むために
自分にとってのFail Fastは、失敗そのものを増やすことではなく、より良い判断をするために、早く検証できる形に落として試すことだと思っている。

仮説を抱えたまま考え続ける時間が長いほど、判断は遅れ、選択肢は勝手に複雑になっていく。 だからこそ、まずシンプルな形で試し、「この仮説は続けるべきか／捨てるべきか」を早く決める。

だから行動が速ければ良い、という話ではない。 大切なのは、仮説を検証できる形にきちんと落とすことだと思う。

慣れや練度によって、この一歩の歩幅は変わっていくのだろうと思うが、 今の自分には、今の自分の歩幅でしか歩けないので、下手に走ってコケるよりも、目の前の一歩を大事にし、その一歩から何を学ぶかを早く決めていきたい。

Fail Fastするために

早く学び次の一歩へと進むために、早く検証できる形にして検証をすること。

自分がユーザーとなって使ってみる、ユーザーになりうる人と一緒に業務をする・見せてもらうみたいなことが大切な気がする。解決したい課題に対する解像度と、解決したい課題を持つユーザーの解像度が低い状態で、良い仮説は思いつかない気がする。少なくとも自信を持って語れる状態だなと思えないうちは、丁稚奉公も悪くないような気がする（丁稚奉公の使い方として正しいのか分からない）

ツール（生成AI系とか）に投資して「検証の時間」を買い、浮いた時間で現場の解像度を上げる。みたいなバランス感覚を大事にしていきたい。

「社内啓蒙」みたいな言葉を辞める

「社内啓蒙」という言葉に、少しだけ違和感を覚えることがある。

この言葉を使うとき、無意識のうちに 「分かっていない相手に、分かっている自分が教える」 という構図を前提にしてしまっていないだろうか。

もちろん、悪意があるわけではない。 DXやセキュリティ、データ活用など、組織として重要なテーマを前にすると、「まずは理解してもらわないと始まらない」という焦りが生まれるのも自然だと思う。

ただ、その焦りが「啓蒙」という言葉に乗った瞬間、スタンスが少しだけズレる気がしている。

「伝わらない相手にどう伝えるか」という前提

新しいチームや部署が立ち上がり、 「全社にDXを広めよう」「セキュリティ意識を高めよう」 という場面は、どの会社でもよくある。

そのときによく聞くのが 「現場に理解されない」 「どうやって啓蒙していくか」 という言葉だ。

でも、「伝わらない相手に、どうやって伝えるか」という前提そのものが、少しズレているのではないかと思うことがある。

本当に「伝わっていない」のだろうか。 それとも、「自分たちの言葉で語られていない」だけなのではないか。

ゴールは本来、共有されているはず

多くの場合、ゴールは実は共通している。

• 会社としてリスクを減らしたい
• 事業をスケールさせたい
• 無駄な作業を減らしたい
• お客さんにより良い価値を届けたい

DXもセキュリティも、それ自体が目的ではなく、こうしたゴールのための手段のはずだ。

一方で、相手には相手の立場・役割から見える「重要なもの」がある。 納期、売上、顧客対応、チームの安定、評価指標.....

それは決して軽視されるべきものではないし、「分かっていないから優先していない」わけでもない。

同様に、自分には自分の視点から見える重要なものがある。 リスク、構造、将来の負債、全体最適。

どちらかが正しくて、どちらかが間違っている、という話ではない。

啓蒙ではなく、翻訳や接続に近い

もし本当に必要なのだとしたら、それは「啓蒙」ではなく、

• ゴールの再確認
• 立場ごとの関心事の言語化
• それらをどう接続するかの翻訳

に近い行為だと思う。

「分からせる」のではなく、 「同じゴールを、違う言葉で結び直す」。

上から目線な態度を前提にした瞬間、相手は防御的になるし、自分も孤立していく。 その状態で望ましい結末を迎えられることは、あまり多くない。

言葉がスタンスを作る

「社内啓蒙」という言葉を使うこと自体が悪いわけではない。 ただ、その言葉が内包しているスタンスには、少しだけ注意したい。

言葉は、思考を作り、態度を作る。

同じ目的に向かう仲間に対して、 自分は今、どんな前提でこの言葉を使っているのか。

そう問い直すところから始めたほうが、 結果的に、物事はうまく進む気がしている。