人は常に本末転倒している ~私のPM論~

この記事は freee Developers Advent Calendar の 7日目です。

ご覧いただきありがとうございます、私、谷豪紀（tani goki）と申します。

現在freee会計のProductManager（以下PM）をしていて、2021年のAdvent Calendarを執筆させていただくことになりました。

タイトルが少し過激ですが、これは私がいつも頭の片隅に置いている言葉です。

今日はこの考え方について、僭越ながらお話しさせていただきます。

実は難しい本末転倒防止

本末転倒のわかりやすい例として、こんなものがあります。

近くのスーパーより安い商品を買いに、遠くのスーパーに電車に乗って出かけた

これを見た多くの人は「自分はそんな無駄なことはしない」こう考えます。

たしかに組織で働いている以上、現実にはこんなにわかりやすい本末転倒はそうそう存在しません。存在しても誰かが必ず早い段階で指摘しています。

ただし、プロダクト開発に関わる人間としては、一見わからないけど知らず知らずのうちに本末転倒していた。というケースこそが問題で、これについては認知が難しいため、かなり強めに意識しています。

それがこの記事のタイトルでもある「人は常に本末転倒している」です。

そもそもPMの役割って？

ここからの内容は、私がプロダクト開発の現場で起きる本末転倒の例と、その対策について話します。

しかし、本記事は普段プロダクト開発に携わらない人にも読んでいただき、共感・応用いただきたいと思っています。そのため、目線をあわせるためにざっくりとfreeeの開発現場におけるPMの役割をお話しします。

まず、PMには「戦略、企画、開発」の3つの役割があります。

「戦略」は、自社のミッション・ビジョンに沿った長期中期のプロダクトの開発計画を作成します。 freeeでは、「スモールビジネスを、世界の主役に。」というミッションと、「だれもが自由に経営できる統合型経営プラットフォーム。」というビジョンを持っていますので、これを達成するために今足りてないことを考えたり、市場の課題をリサーチしたりして検討します。

「企画」は、戦略を具体的に実現するための開発内容を企画します。例えば「経費精算業務を効率化する」という戦略に対して「経費精算のための領収書提出を簡単にする、そのために〇〇の機能を作る」といった企画を練ったりします。企画は作って終わりではなく、それが本当に戦略に効果があるのか等を社内外の意見をもらってブラッシュアップしていきます。

「開発」は、実施すると決まった企画に対して、開発を開始します。freeeでは優秀なエンジニアがたくさんいるので、企画の内容と、その裏側にどういう戦略があるかなどを開発チームに伝えることで、細かい点は基本お任せです。ただしリリーススケジュールの管理だったり、他の開発チームや社内外の関係者に影響がある時にはその調整を行なったりします。プロジェクトマネジメント（PJM）と言われたりもします。

開発組織の体制などによっても変わりますが、PMはざっくりこのような役割を持っています。

本末転倒の罠はこの各所にひそんでおり、今日は3つ紹介します。

まず初めは「開発」段階で起きる本末転倒についてです。

①枝葉の議論にリソースを割きすぎちゃう問題

開発を行う元になる企画には、「絶対に外せない機能」「あったら嬉しい機能」「できれば欲しいけど、なくてもいい機能」が定義されています。この「できれば欲しいけど、なくてもいい機能」に議論の時間をとってしまって、大事な「絶対に外せない機能」の詰めが甘くなってしまう現象について話します。

例えばカレー屋さんとかで例えるといいでしょうか。

「絶対に外せない機能」・・・カレー
「あったら嬉しい機能」・・・サラダ・ラッシー
「できれば欲しいけど、なくてもいい機能」・・・ライスを白米か玄米か選べるオプション

みたいなときに、ライスは玄米だけでなく五穀米も選べるようにするか...みたいな議論が白熱して、結局どんなカレーを作るかが議論しきれなかったみたいなケースを想像すると分かりやすいと思います。

もちろん、開発チーム内でそもそも議論が生まれないのはもっとよくないので、PMは場を盛り上げて全員が意見を言えるように活性化させることも必要です。

ただし、うまく勢いづいたチームほどチーム内で枝葉の議論に（悪い意味で）楽しくなっちゃって時間を浪費するリスクも高まるので要注意です。

開発チームが8人だったとして、油断していて1つの機能について議論してたら1時間経ってしまうと、すごくもったいないです。終わった後に冷静になって考えてみると、

一ヶ月のリソースを20日*8時間って考えると、そのうち1/160をそこについやす価値があるか、と言われたら、そうではない
ましてやチームで全員集まれる時間は週に3時間とかだったら1/12をそこについやす価値があるか、と言われたら、もっとない

なんてことは、できたら避けたいですよね。

本末転倒の類義語で釈根灌枝（しゃくこんかんし）という言葉があり、それがより近いかもしれません。木の根に水をやらないで、枝にばかり水を注ぎかけてしまう、という意味です。

PMはチームの誰よりも場をよく見て、アクセルとブレーキを使いこなす必要があります。

では、次はPMの役割における「企画」段階で起きる本末転倒についてお話しします。

②本末転倒かどうか絶妙にわからない問題

「〇〇というページを使っているとストレスが溜まるという声が多いので、改善する」という企画があったとします。

ストレスの原因を調査した結果「表示速度が遅く、既存のとある機能を廃止すると速度を上げることができる」という案が出たとします。

一見よさそうですが、どうも一部のユーザーは使えなくなった機能が原因で余計にストレスが溜まってしまうようです。

さて、この案は本末転倒しているか？と聞かれると、とても難しい問題です。

極端にデメリットが少ない（影響するのは0.01％のユーザーだけ）とかであれば意思決定はしやすいのですが

「80%のユーザーが小さなストレスがなくなり、20%のユーザーに中くらいのストレスが増える」みたいな仮説があるときはとても悩みます。

コツは「あきらめるなっ！」

本末転倒しているかもしれない、わからない....

そんなときの私の思う正解は、「あきらめるなっ！」です。

例えば、今回のケースの「20%のユーザーに中くらいのストレス」の「中くらい」いうのはもっと言語化できます。

回避する代替案はあるのか、そこに誘導することは現実的なのか、説明されれば納得できる正当なものなのか。などなど

また、「20%」という方も、その数値の根拠の見直しなどをすることで、「実は1%だった」とかに気がつけるかもしれません。

この調査の過程を経る中で、本末転倒なのでやめましょうとか、みんなが幸せになれる折衷案が見つかりました、となることが多いです。

根性論ではなく、研鑽が大事

諦めない、それだけだと根性の問題にも聞こえますが、そうではないと確信しています。

これらの検討を素早く行うためには、前提として「ユーザー（＝お客様の思考）」「ビジネス（＝事業への影響）」「プロダクト（＝既存仕様や利用状況）」の3要素をどれも知っている必要があるからです。

そしてそのためには、日頃から自分の担当する領域についての愚直な研鑽をする以外の道はありません。

では、最後はPMの役割における「戦略」で起きる本末転倒についてお話しします。

③主目的がブレブレ問題

これが私がPMをやってみて一番学んだことです。

まず、本末転倒にもタイプがあります。これまで話した問題は、最初に話したPMの仕事のうち「企画」とか「開発」段階で起きるものです。

このレベルでは本末転倒の”本”に該当する主目的は比較的明確です。（「〇〇の機能のストレスを減らす」「△△の機能の利用率を向上させる」とかですね。）そして、主目的が蔑ろにされないように注意しましょう、ということをここまで話しました。

でも「戦略」の話になると、その主目的自体がブレることがあります。

戦略の主目的は、ミッション・ビジョンの実現

戦略を立てる目的は、掲げているミッション・ビジョンの実現のため、その一点です。

しかし、ミッション・ビジョンは抽象的なものなので、同じ言葉でも解釈が人によってずれていたりします。

他者と自身のずれならまだしも、PM自身の中でその解釈が定まっていないと、作る戦略には一貫性がなくなります。結果その先に作られる企画の数々を並べて眺めると、全体として筋が通っておらず違和感のあるものになってしまいます。これが主目的がブレブレ問題です。

この問題のポイントは「PMのミッション・ビジョンの解釈ブレ」であり、これが簡単に見えてとても難しいところです。（私にとっては特にそうでした）

どうしても「この解釈で合ってるだろうか、、自分の意志を込めて独り善がりになったりしないだろうか...」というモヤモヤが生まれてきます。

その心配や遠慮こそが最大の敵ということを知らずに....

Will（意思）を持て！！

結論から言うと、「ミッションビジョンの意図を理解して、ユーザーに対する責任感を忘れなければ、自分の解釈に自信をもって突き進んで良い」と思います。

自身の中でブレないことが何より重要で、他の人と解釈が違うことを恐れてはいけません。

というのも、PMはたびたび重要な意思決定を行いますが、それは経営陣が行った場合と同じ判断ができるコピーを求められているのか？というと答えは否です。

判断が組織全体で画一化されてしまうと、筋が悪い方針であっても誰からもフィードバックを得ることがなく、それを盲信して継続するリスクが生まれます。

ミッションビジョンの解釈にレパートリーがあるからこそ、組織全体として健全なチャレンジができる。多様性は義務ではなく武器なのだ。そう考えると、自分の「ミッションビジョン達成のためにこうあるべきだ」というwillに自信を持って良いと思います。

それでも心配な方へ

抽象的な表現だと「本当にぃ？」ってなる人もいると思います（というか私がそう）

そういう人のために、実際にあったワーストケースを紹介します。

あなたはPMをやっていて、自分の開発領域について偉い人Aさんと話をする機会があった。 「◎が大事だよね」と言われて、よく考えてなかった事なので「そうっすね」ととりあえず答えた。

後日、違う偉い人Bさんと話をする機会があった。「×を重視したいね」と言われて、これもよく考えてなかったことなので「ですねー」と答えておいた。

後から自分で振り返ってみると「あれ？重視する◎と×は排反して整合性とれないじゃん」となって、その不整合を埋めるためのロジックなんかを考え始めた。

こうなったらもう最悪、前述した「企画の数々を並べてみると、全体として筋が通っておらず違和感のあるものになってしまった」状態の道に進んでしまった。

自分で書いていてもちょっとだけ背筋が寒くなりました。

これは一体どうすればよかったのでしょうか？

違う意見を言うAさん、Bさんは各々ビジョンに対する解釈が違うだけで、別に悪気があるわけではありません。

となると、酷な言い方になりますが、問題はその場の雰囲気に流されてしまったPMにあるなと思います。