「抽象的な仕事を進めるスキル」に着目したプロダクト開発組織の目標設定とスキル評価について

※この記事はプロダクト開発組織の目標設定や評価について考察したエッセイです。
プロダクトの会社の新規事業責任者が書いたというバイアスがあります。
逆にいうと我々の業界的には、職能トップやプロダクトトップが書いていないという点でユニークです。あくまでも事業責任者の事業を成功させるにはという視点での文章です。

BASE株式会社執行役員の柳川です。金融事業の事業責任者をしています。
私はエンジニア→PdM→事業責任者というキャリアを歩んできました。
現在は事業戦略、プロダクト戦略、組織戦略全ての責任を持ちながら、事業責任者を務めさせていただいています。

序文

世の中で「優秀」と言われている人は以下のように分類できるのではないかという仮定から論を進めてみる。

• 抽象的なものを抽象的なまま処理できる人

• 抽象的なものを具体に分解して処理できる人

抽象的なものを抽象的なまま処理できる人も、具体に分解して処理できる人も、どちらも優秀な人材といえる。

どちらのアプローチでも良いのだが、抽象的なことを何らかの形で処理できないと仕事ができないとされる。
これは特にエンジニアやデザイナーやプロダクトマネージャーやBizDevも含む企画系の職種で顕著だ。
抽象的なことを何らかの形で処理するのが仕事なのだ。

仕事とはなんなのか

私は定型化された仕事をこなすのではなく、不定型の課題を解決することを生業にしてきた。なのでここではこれを仕事と定義したい。
この仕事の本質は、抽象的な課題を見つけ出し解くことだと考えている。その連続なのである。
解く方法はさまざまにあって、それが職種ごとのスキルなどで覆い隠されたりして、複雑になったりするのだけれど、あくまでも抽象的な課題を見つけ出し解くことが仕事だ。
おそらく我々のような仕事における優秀さは、いかに抽象を解決するのか、それにレバレッジをかけれるのかと言うことなのだと思う。

抽象を処理する力

抽象を処理する力は後天的に身につく。ただし、習得には時間がかかり、人によって習得時間も異なる。
そのため、仕事でこのスキルを身につけられるかには運の要素がある。

新卒は比較的恵まれており、抽象を処理する後天的なスキルを育成してもらえる環境にあることが多い。(今思うとコストを割いていただいていた)
エンジニアは、抽象を具体に落とさないと動くものが作れないため、鍛えられる機会が多い。抽象をコンピューターに翻訳する仕事なので。

分解して処理するスキルを身につける初期段階で、器用な人ほど「簡単すぎるからこんな過程は不要」と考えて鍛錬を怠りがちだ。
「考える技術・書く技術」とかを読んだ後に「この過程いらないなー」とか思ったり。
これが器用貧乏の始まりで、いずれ越えられない壁に直面する。
このタイプは後で苦労することになる。血反吐を吐かないと越えられない壁にぶち当たって初めて工夫しだす。乗り越えられないこともしばしば。ここで生存バイアスが生まれる（私自身の経験だ）。

具体化して分解する能力

具体化して分解する能力は、より正確には以下のレベルに分けられる。

• 自分の仕事を進めるために分解できる

• 自分の仕事の状況を説明するために分解できる

• 人に動いてもらえる単位で分解できる

抽象で処理している人も、自分が理解できる範囲では具体化しているはずだ。しかし人に説明できるレベルまで具体化できるかは別の課題だ。

抽象的なものを具体に分解して処理できる人は後々楽になる

抽象的なことを人に動いてもらえるレベルまで分解できるスキルを得るには、主に二つのルートがある

• 抽象を分解して処理するスキルを身につける過程で自然と習得するルート

• 抽象を抽象のまま処理していた人が、人に仕事を依頼する場面になって苦労しながら習得するルート

人に理解できるまで分解することには、スキルとコストの両面で課題がある。分解作業には時間も脳のリソースも多く必要となる。

そのため、役割分担が重要になるのだ。ゼロイチの抽象的なアイデアを思いつけなくても、誰かが考えた抽象を翻訳できるスキルがあれば、それも立派な仕事といえる。得意分野を活かせばよく、優劣の問題ではない。要はバランスだ。

企画推進者やマネージャーの必須スキル

企画推進者やマネージャーには、抽象的なものを人に伝わるように具体化できる能力が不可欠だ。これは適性の問題というより、必須のスキルである。このスキルがないと人を巻き込めないからだ。

仕事は人を巻き込んでなんぼ。調整してなんぼ。
課題が難しければ難しいほど

•  一人では解決できない

•  一発では解決できない

ので人を巻き込めない人は能力として足りていないと言う判断になる。

抽象を抽象のまま理解して仕事をこなせてしまうと、なぜメンバーが自分の言うことを理解できないのかが分からず、対処法も見出せなくなる。これは優秀なプレイヤーがマネージャーになる際の最大の躓きの原因だと考えられる。

「マネージャーや企画推進者のようなリーダーにはならないから抽象的なものを人に伝わるように具体化できる能力はいらない」

？？？

そんなことはないのよ。
会社組織などで働く以上は、一人では仕事は完結しない。たとえ作業は一人だったとしても、その作業は何か組織の目的があっての作業だ。
その作業を手伝ってもらうためにも、作業の意図や結果に対する説明責任を全うするためにも、抽象的なものを人に伝わるように具体化できる能力は皆が身につけるべきだと考える。

そもそもプロダクト開発自体が抽象的なものを人に伝わるように具体化することそのものなんだ

どのような人材を求めるのか

抽象をそのまま理解して動ける人材を求める気持ちは分かる。また、抽象を理解できない人へのいらだちも理解できる。具体化して伝えるのは確かに労力がかかるからだ。
でも抽象から抽象で全てが進む前提でいると、思わぬ落とし穴がくるかも。なんで伝わらないんだって言うことに過剰反応してしまう。
また別の視点では抽象を具体化する過程で新たな気づきが得られ、最終的なアウトプットの質が向上することもよくある。

抽象を抽象のまま理解してくれる人を外に求めるのも良いのだが、自分が抽象を具体にして伝えるスキルをつけることを諦めてはいけない。サボってはいけない。

フェーズによっては、まず抽象をそのまま理解できる人とディスカッションを進めるのが効果的な場合もある。確かに具体化が必要な人ばかりのチームでは進捗が遅くなりがちだ。

それでも、人に理解できるレベルまで分解するスキルは必要不可欠だ。
できるけど状況を踏まえてあえてやらないのと、やれないからやらないのでは大きな差がある。雲泥ってやつだ。

「抽象的なものを人が理解できる形に分解するスキル」を向上させるには

自分でできること

基本は理解しやすい単位への分解から始める。
まずは箇条書きでいいから分解してみる。それに時系列がついてくるとなお良い。
一発でいい分解はできない。一発でいい分解をしようと気負わない方がいい。完璧でなくてもいいから分解して早く見せれる人が結局一番早くできるようになる。プライドは捨てよ、イテレーションを回そう。

分解した後はいかに伝えるかなのだけれど、分解後の伝え方には個性が表れるし、個性が表れるべき。
文章だけでなく、図示や口頭での補足、デザインで伝える、モックアップを作ってみるなど様々な手法を試す。

伝わり方を試行錯誤しながら表現の引き出しを増やすことが大切だ。
世の中に数多ある既存のフレームワークはこう言う時に活用できるだろう。

周囲ができること

人に理解できる形に分解できるようになるにあたって、周囲はどのようなサポートができるだろうか。
答えは問いを投げ込むことであり、問いを投げ込みやすい仕組みを作ることだと思う。
それは結局のところ目標設定とその進捗の確認だと思う。
時にアホらしかったり、苛立ったり、マイクロマネジメントではと思うこともあると思う。
そうではなくて機会を作っているんだ。
自分でPDCA回すのは本当にしんどい。できてる人は人ほとんどいないと思う。出来てるつもりのケースが多い。
それゆえに仕組みにしてしまうことが大事。
仕組みとしての「目標設定と進捗の確認」を真剣にやることで言語化する機会とPDCAを回す機会が断然増える。そうすると人に説明できるようになる。
「プライドは捨てよ、イテレーションを回そう。」をできる環境を目標設定と進捗の管理で作る。
仕組みにすることで、心の負担を少しでも減らす。

「抽象的なものを処理する」と言う切り口でのスキルレベルの評価について

ここまで論じてきたことのまとめであり本題。
スキルの評価について、抽象的なもの処理すると言う観点から以下のようにレベル分けできるのではないかと考えた。
グレード表とかラダーというのは複雑なものになりがちだけど、本来これくらいシンプルでいいような気もする。
全てのビジネスパーソンがLv4までは目指したいところ。

• Lv1:具体的に分解されたタスクを遂行できる

• Lv2:分解されきっていないやや抽象度の高いタスクを遂行できる

• Lv3:抽象的課題の進行過程を開示しながら遂行できる

• Lv4:抽象的課題を具体に分解してタスクとして渡し完遂できる

• Lv5:事業にとって有用な抽象的課題を発見し設定できる

• Lv6:事業を作ることができる

上記のレベルがそれぞれバラバラのメンバーが集まってチームを作ることになる。
となると、どのバランスでスキルレベルがミックスされているとチームがうまく進むか考えるのも大事。
例えば同じLv4にいる人でも、Lv2の人にはタスクを渡してうまくワークできるけど、Lv1の人にタスクを渡すのは苦労するみたいなことが差ができうる。

実感としてはLv2あたりで燻っている人が多い印象。
実際にはLv2なのに自己認知がLv4くらいにずれているパターンもある。
ある文脈においてはLv4ができたけど、その後応用は効かないパターン。
Lv4がどんな場面でもコンスタントにできる人は体感相当希少。

抽象的課題の粒度は、事業責任者視点で「これやりたいけどどうやるか考えるのは骨が折れるな、何パターンか考えられるし」と思うもののイメージ。

このレベル分けにはビジョンは実現してなんぼだよねというバイアスがかかっています。ここで定義したレベルについては一つずつ上がってくものという前提で書いてます。つまり基礎的な実行力からの積み上げを評価する考え方です。ここも宗派がありそう。

抽象的でレベルの高い課題を人に伝わる形にせずとも一人で解決できる人もいるよね？

「抽象的でレベルの高い課題を人に伝わる形にせずとも一人で解決できる人もいるよね？」これを特別に評価するかどうかは論が分かれるのかなと思う。
課題を解く際に用いるスキルの希少性とかも加味しながら考えることになるような気はする。

ただ個人的には特別な評価はしないかなと思う。
仕事のスタイルとして「抽象的でレベルの高い課題を人に伝わる形にせず一人で解決した方がパフォーマンスが出る」ケースはあると思うし、そのスタイルは尊重すべきだと思う。全体最適としてそのスタイルをお願いする局面もあると思う。

ただスキル評価の観点では、コストをかけた場合にどのレベル相当のことができるのかでみるべきなのかなと考えている。
レバレッジをかけるべき時にかけれるかどうかを重要視している。

できるけど状況を踏まえてあえてやらないのと、やれないからやらないのでは大きな差がある。雲泥ってやつだ。
と言う理論。

そもそもの課題の難易度によると言うのはある

抽象を具体に分解して理解できる形にしているように見える人。言い換えると言ってることがわかりやすい人には以下の分類があることも注意。

• 抽象を具体に分解するのが得意な優秀な人

• 取り組んでいる課題への知識や慣れがある人

• ただ単に取り組んでいる課題がシンプルで簡単なだけな人

これを踏まえ、「あなたの言っていることはわからない」と言われても落ち込まないこと。スキル不足なわけではなく難しいことに取り組んでいるだけかもしれない。取り組んでいる課題の抽象度や複雑度を見抜こう。

人を管理する組織ではなくビジョンを実現するための組織を作りたい

マネージャーになって、評価をしたり評価制度を作ったり工数の管理に近いことをしていると、いつのまにか人を管理することに思考が寄る。でも本当にやるべきことは人を管理することなのだろうか。

組織は何のためにあるか、チームは何のためにあるのか。みんなで協力して物事を成すためだと思う。
もちろんそれをする過程で管理するに近いことが必要なのかもしれない。厳密な評価も必要なのかもしれない。でもそれって本当なのかな。

職能組織のマネージャーになると、どうしても人を管理する発想に寄る構造的な問題があると考えている。局所最適に走りがちというか。

限られたリソースで物事を実現することを考えた時に、人を管理するなんて悠長である。
評価とか管理とか烏滸がましくて、「こういう戦術でやってみながらみんなでよくなっていこう」くらいしか言えないなという気持ち。
仕事のための仕事にならない上手いやり方を今後も考えていきたい。

抽象的な話を具体化しなくていい人は選ばれた人

抽象的な話を抽象的なまま扱える人は以下のような特徴がある。

• その人の言葉を具体化することが人類の利益になると認められている超才能の持ち主

• 最終的なアウトプットまで一人で完結できる人（この場合、アウトプット自体が具体的）

生成AIの登場により、一人でアウトプットまで完結できる人は増えるかもしれない。しかし、分解して説明できるスキルを身につければ、より幅広い活躍が期待できるだろう。
と言うか諦めて分解するスキルと人に伝えるスキルを身につけよう。

まとめ

• 自分が仕事ができていると思っていても、実は分解された仕事をこなしているだけかもしれないという視点を持つことが重要

• 抽象的な課題をどの程度、他者に伝わるレベルまで具体化できるかが、自身のレベルを測る良い指標となる

• 抽象的な仕事を進められても、他者が理解できる形にできなければ、いずれ限界に突き当たる

• 他者の抽象的なアイデアを理解可能な形に変換して伝えられることは、非常に価値の高い価値のあるスキルだ

• 抽象を具体に落とすことで自身の事象に対する解像度が上がり、アウトプットの質も向上する

• プロダクト開発組織は、特殊なようでいて特殊ではない

あとがき

最近育成とか役割分担について考えることが多い中でのアウトプット。
これで運用してますとかではなくて、あくまで現時点の思考のまとめです。
終始どっかの本に書いてありそうなことではあるが、自分の考えをまとめてみた。自分で考えてアウトプットしたと言うのが大事だと思う。

要するにこの文章がいいたいことは
抽象を抽象のまま処理できて、それで頭良い気になっている人はそこ止まりなんだ。仕事なんだから周りを説得して動かせるようになろう。
と言うことを周り口説く言っているだけなんだ。
要するに「なんで伝わらないんだ」と言う苦悩が人を成長させるんだ。変に達観して諦めるな。

と同時に
ロジカルシンキングなんてもんは道具なんだ。まやかしなんだ。中身がないと意味がないんだ。
と言うことも言いたいのであるが、それは文章にうまく表現できていないのであった。

これも結局過去の自分への手紙なんだよな。

どこかのタイミングで発表資料に使おうと思う。良いパーツになりそう。