ドキュメントは（基本）スタンドアロンであれ

ドキュメントは、スタンドアロンであるべきだよなと最近よく思う。

MTGの場では伝わった気がしていたのに、あとから共有された人から全然違う解釈が返ってくる、みたいなことがある。そういうとき、たいてい悪いのはドキュメントの中身ではなくて、「自分が横にいて補足する」ことを暗黙の前提にして書いてしまっていたことなんだと思う（反省）

ドキュメントは、自分がいない場所で読まれる

そもそもドキュメントが読まれる場面はどんな場面か。ドキュメントではなくてもSlackメッセージだってそうだ。「MTGで画面共有をしながら」「コンテキストが十分に共有されている相手に渡す」などがぱっと思いつくし、書いてる時にはそこに重心を置いて、適宜省略したりしながら書いている。

が、本当にそうなのか。

確かにその場・その限りの相手の中で閉じたドキュメントも当然ある。が、意外と書いている自分がいない場面でもドキュメントは共有されることが普通に多い。ドキュメントは自分がいない場所でも読まれている。

• 口頭の説明を伴わない場面で参照される
• MTGの前に読まれるし、終わったあとに読み返される
• そのMTGに参加してなかった人にそのまま共有される

上記のような場面では、書いた人の補足なしで成立してもらわないと困る。後日聞かれても思い出すのも苦労する...

何を書いておくべきなのか

ストーリー・背景

なぜこの検討が始まったのか。何を解こうとしているのか。どんな文脈・前提があるのか。

ここがないと、本文が「誰かが決めた結論」しか見えない。読み手は賛成することも反対することもできない。行動しようにも、指針となる材料もない。判断材料がないので当然だと思う。

全体構成

このドキュメントに何が書いてあって、どこから読めばいいのか。

長いドキュメントほど、読み手は「自分が読むべき箇所」を選べないと、読むこと自体をやめてしまう。全部読んでもらえる前提で書いているのは、たぶん書き手の甘えだ。

生成AIが作成した「**」だらけの文章ベタ貼りなんて言語道断だ。

用語の説明

社内用語、プロジェクト固有の略語、同じ言葉を別の意味で使っている箇所。

ここが揃っていないと、読み手は議論の中身ではなく用語の解釈に時間を使うことになる。しかも本人はだいたい、解釈がズレていることに気づかない。

この3つを先にREADME的に整理しておけば、ドキュメントが単体で流通しても情報が正しく伝わって、読んだ人がすぐ動ける状態になる。

そもそも、読み手に何をしてほしいのか

ドキュメントの目的は、理解と納得をしてもらったうえで、何らかのアクションを取ってもらうことだと思っている。

だとすると、意識すべきは下記あたりだろう。

• 相手が理解するために必要な情報は何か
• 相手が納得できるストーリーになっているか
• 相手が読むべき箇所を選択できる構造になっているか
• 必要なアクションと期限は何か

「理解」と「納得」を分けているのは実は重要だ

何を言っているのか伝わらないと読まれることすらない。書いてある背景や変遷に「確かにそうだ」と納得をしてもらえないと、「必要なアクション」を促せない。

人と人のコミュニケーションだから

生成AI同士が代わりにやりとりしてくれる...時代ではまだなくて、人間がドキュメントを介して意思決定していくので、例え過程として生成AIでまとめるなりしようとも、人間に伝える時は相手に最大限配慮するというか、認知負荷とか、伝わりやすいのかとかを意識して用意してあげる方が良いのかなと思う。

「何が言いたいんだろう」とか「読みにくいなぁ」って人間もAIも思わないような整理整頓をしておくと、枝葉すぎる話とか、重要じゃないことに時間を使わくて良くなり、結果としてより良い時間の過ごし方が出来るのかなと思う（とは言えこれ毎回やるとコスト高すぎるけど）

余白が大事だと思う理由

僕がチームを持っていた時に大事にしていた「余白」について少し書いてみる。

まず大前提、僕は仕事が好きな人は（ルールの中で）好きなだけやれば良いと思うし、実は遅くまでやってるとか、休日もやってるとかも、身体を壊さないでくれよとか、進んでそれを選択してる限りは良いのかなとか思ったりする。僕自身も好きなだけ仕事をしていたいタイプではあるので、少なくとも気持ちは分かる側だと思う。

但し僕はその選択を選択肢として持っていて良いと思っているだけで、常にそうなっていたら止める。プロジェクトの設計段階で”余白”を意識しておくことは大事にしていた。

”余白がない”とどうなるか

課題解決の引き出しが増えないというか、いつまでも同じ手札で戦い続けることになるのだろうと思う。それ自体もあんまりよろしくないと思いつつ更に、一個人としての成長実感を感じにくくなりやすいことに問題意識がある。「忙殺されていて、振り返る暇もない」とか「やること多すぎて大変だけどそれはそれで楽しいッス」とか色々あると思うが、それで良いのかな〜と。

モノ作りを通して色々な制約の中でビジネスの要求を技術で実現していかないといけない。技術はどんどん進化し、新しい知識や知恵が求められる。（生成AI時代でそれが加速したのかどうかは分からんけど加速しているんだと思う。）普通に仕事していてもそうなのに、更に今までとは違う解決策を創らないといけなくなってくる。

プロダクトのスコープが広がり解決する課題の範囲も深さも変わってくる・使ってくれるユーザが増える・技術的負債が溜まってくる....

そういう中で、”余白”がないとどうなるのか。

「暇がなければ新しいことは学べない」。暇がなければ自分の中にある今はもう古い方法論が上書きできない。

振り返り・レトロスペクティブを確保するのは個人のためチーム・組織・プロダクトのためにも重要だと思っている。加えて、残業時間を減らすこと・休日に仕事をしないことも大事だと思っている。

めちゃくちゃ当たり前な話ではあるのだけど、

• 自分の興味関心を深める時間にしたり

• 興味のアンテナをメンテナンスする時間にしたり

• 健康を維持したり

そういう”余白があることで本来的に生まれるはずな選択肢”を相手にちゃんと認識してもらうことが大事なのかなーって。その上で仕事したいならしたら良いと思う。（けど、武器を磨くとか、新しい武器を手に入れる時間も超大事だぜ？とは伝えたい）

そんな訳で、僕は日々、学んでいる姿勢というか姿を見せるのも大事だと思っているし、分からないことや上手くいかなかったことに超Welcomeな姿勢を示したいと思っている。

が、他者をモチベートするのは圧倒的難易度高いので、モチベートすることが目的というよりかは、誰かが変わりたい！成長したい！と思ったタイミングを絶対に逃さないような自分の”余白”を作ること、相手がそう思える”余白”を作ること、そういう時に相談したい人と思ってもらえるような信頼関係を築くことを意識している。

脱線したが、相手がどこを目指したいか次第ではあるが、”豊か”になろうと思うのであれば、”余白”創りに執着した方が良いと思っている。新しい戦闘力を手に入れたいならば、それが第一歩になるはず....

Speaker DeckのスライドをObsidianに一発保存するChrome拡張を作った

きっかけ

obsidianのweb clipperはかなり優秀で最近はYoutubeの文字起こしも保存できるので超有難い代物なのだけど、speaker deckだけは上手く対応してなくて、メモを残すのが地味に面倒だった。

ということで、自分用に「スライドページを開いてボタンを押すだけでObsidianに保存されるやつ」が欲しくなり、Claude Code先生でサクッと作ってみた。本当に何でも作れちゃう、有難い

作ったもの

Chrome 拡張です。起動すると

1. タイトル・著者・投稿日・概要を自動で拾ってくる
2. PDFを取得してスライドの文章を抽出（画像だけのスライドでもOCRで拾う）
3. Obsidianにスライド埋め込み付きのMarkdownとして保存

というところまで一気にやってくれる。

Web Clipper を意識した UI

ポップアップの UIはObsidian公式のWeb Clipperに寄せて作った。保存先のVaultやノート名、フォルダ、フロントマターに入れるプロパティ（タイトル・著者・タグなど）をその場で確認・編集できて、生成された Markdownもプレビューしながら直接いじれる。

いつも使ってる Web Clipperと同じ感覚で使えるので、道具として馴染みがよくて自分でもかなり気に入っている。「解析」→ プレビューを軽く整えて → 「Obsidian に追加」の3ステップで終わるので、スライドを見つけてから保存するまでのハードルがほぼゼロになった。

ソースコードはここにあるので、使っても良いし、簡単なので自作しても良いと思います。

github.com

マネジメントに必要な「優秀さ」って何なんだろう（感想）

絶賛会議中の第4回「マネジメントは"優秀な人"がやるべきか？」を聴いた。その感想

www.youtube.com

番組の結論は「マネジメントはやりたい人がやるべき。ただし自信満々なやつには気をつけろ」だった。聴きながら考えたことを書いておく。

やりたい人がやるべき、には同意

安斎さんは最初から最後まで「マネージャーはやりたい人がやるべき」で一貫していた。これは自分もそう思う。

これはすごく分かる。仲間の成功を願えない状態で、仲間の成功を支援する仕事をするのは無理がある。前向きな感情を持てていない人がやるのは厳しいよね、というのはその通りだと思った。

番組では、マネージャーに自ら手を挙げた人よりも、くじ引きで決まったマネージャーの方が良い成績を上げたという研究も紹介されていた。手を挙げる人には自信過剰な人が混じるから、というのが理由らしい。実験室の3人1組のタスクなので実務にそのまま持ち込める話ではないけれど、「私やります」と言った人が空回るという光景に心当たりがない人はいないと思う。（じ、自分もそうだったような...）

ただ、この番組で扱われていたのは主に「誰にやってもらうか」という意欲の話だった。じゃあマネジメントに必要な優秀さって具体的に何なんだ、というところは、聴き終わってからも自分の中に残った。

組織の成果は結果でしかない

考えていて行き着いたのは、リフレクションを促して学習支援ができる人が大事なんじゃないか、ということだった。

マネジメントの目的として「組織の成果を上げること」とよく言われる。それはそう。ただ、成果というのは結果であって、直接手を突っ込んで動かせるものではない。動かせるのは、成果が生まれる仕組みと、その仕組みを構成する人の意思決定の方だ。

そう考えると、マネージャーの仕事の中でもかなり大きいのは、正しい意思決定ができる人を増やすことになるのかなと思った。自分が全部決めるのではなく、決められる人を増やす。組織が大きくなればなるほど、自分が関われる意思決定の数には限りが出てくるので、意思決定の質を上げるなら人を増やすしかない。（それを仕組み作りと言うのかもしれない）

そして、これができる人が”優秀”なのかなと思う。リフレクションを促すとか学習支援をするというのは、要するにこれをやっているということなんじゃないか。

「捌ける優秀さ」とは違う気がする

だから、落ちているボールを拾って穴を埋められるとか、処理が速いとか、マルチタスクが得意ですみたいな優秀さは、マネジメントに必要な優秀さとは違う気がしている。

そういう人が組織にいると確実に助かるし、実際その力で回っている現場もある。自分もそういうやり方をしたことがある。ただ、拾い続けている限り、拾われた側は決める経験をしないままになる。穴が埋まるので問題は表面化しないけれど、意思決定ができる人は増えない。成長していく糧となる失敗を奪っている。短期的には成果が出て、長期的には人が育たない。マネージャーの優秀さをここで測ると、たぶん間違える。

「任せる」だけだと足りない

マネージャーの仕事は任せることだ、という言い方もよくされる。これも半分そうだと思うけれど、任せるだけだと足りないと思っている。

大事なのは、任せた先で意思決定を失敗させて、そこからリフレクションを促して、経験から学んでもらって、さらに次の学習を支援していく、という一連の関わり方の方だ。任せるのはその入り口でしかない。

じゃあ人の意思決定をより良くするために何をするのか、と考えると、こんな感じになると思う。

適切な情報量を渡す。判断に必要な材料が揃っていない状態で決めさせても、それはただの当てずっぽうになる。逆に全部渡せばいいわけでもなくて、多すぎると論点が埋もれる。

適切な範囲で挑戦してもらう。失敗から学んでもらうには失敗させる必要があるけれど、取り返しがつかない失敗をさせるわけにはいかない。どこまでなら失敗していいのかというガードレールを引くのは、任せる側の仕事だと思う。

適切なフィードバックと対話をする。決めた後に何が起きたのかを一緒に見て、どこで何を考えて決めたのかを言葉にしてもらう。

そのうえでリフレクションをする。ここで目指すのは、同じ場面にもう一度遭遇したときに違う意思決定ができる状態になっていること。その時とは違う視点や角度・価値観で眺められるようになっているか。

あと、これをやろうとすると、その人がどういう価値観や信念で物事を決めているのかを理解している必要が出てくる。同じ情報を渡しても、何を重く見るかは人によって違う。価値観を揃えるというのはパーソナルな部分は難しいし揃えるっていうのはちょっと違うと思うが、会社や組織の大切にする価値観をベースにした考え方を伝えていくみたいなイメージ。価値観側は介入が難しいし難易度も高いしなので、基本的には適切な情報を渡すことに徹する方が良いのかなと思ったりする。

以上、ほぼ見直しせず走り書きしてみた回でした！

一生懸命やるから、こだわりが生まれる

久しぶりにブログを書く。今回は、キャリアの振り返り的なことを少し。

キャリアについては、ずっと川下り的なものだと思っていた。偶発的計画性理論みたいな考え方が好きで、目の前のことを真面目に積み上げていけばチャンスは来るし、実際に来た。掴んで、結果も出してきた。だから川下りも悪くないな〜と思っていた。

でも最近は、山登り的なキャリア観になってきている。プロダクトマネジメントを極めていくことに、強い関心がある。

ソフトウェアエンジニアの道を志して、いろんな開発をしてきた。言語やフレームワークの面白みもあるし、設計やアーキテクチャの面白みもある。やればやるほど知識や経験が増えていく感覚は、今でも普通に楽しい。

その中で、特にこだわりたいものに出会えたんだと思う。それがプロダクトマネジメントだった。

何ヶ月もかけて作ったのに、全然使われなかった

きっかけは、正直あまり気持ちのいい話ではない。

何ヶ月も取り組んでリリースしたものが、全然使われなかった。理由ははっきりしていて、作りたい側の意向が強すぎて、ユーザを軽視していたから。

怒りというか、もどかしさというか、やるせなさというか。うまく名前のつけられない感情が残った。

しばらくして、その感情の出どころを考えていて気づいた。僕はエンジニアリングが好きというより、モノ作りが好きなんだと。良いモノを作って、ちゃんと使ってもらうことにこだわりがあるんだと。

だからプロダクトマネジメントなんだと思う

どんなに優れた設計やアーキテクチャであろうとも、どんなに速く実装しようとも、ユーザに使われて事業に貢献できなければ意味がない。

人もモノも金も限られている。その中で、ユーザに使ってもらえて事業価値を生み出す意思決定を重ねていくことは、モノ作りにおいてとても重要な仕事だと思う。そして自分は、そこに強い興味関心があるらしい。

一生懸命やるから、こだわりが生まれる

タイトルの話をする。

こだわりって、たぶん最初から持っているものじゃない。一生懸命やった結果、あとから生まれてくるものなんだと思う。

適当にやっていたら、使われなかったことにあそこまでやるせなくならなかったはずで。何ヶ月も真剣に向き合ったからこそ、あの感情が出てきた。そしてその感情が、自分が何にこだわりたいのかを教えてくれた。

川下りで流されているうちに、登りたい山が見つかった、みたいなことなのかもしれない。だとしたら川下りも無駄ではなかったし、しばらくは登ってみようと思う。

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

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

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

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

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

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

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

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

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

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

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

現場への影響を想像する

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

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

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

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

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

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

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

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

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

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

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

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

砦としての在り方

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

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

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

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

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

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

■まず自分で考え切る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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