こんにちは、 freee の権限管理基盤チームでマネージャーをしていた sentokun と申します。
突然ですが、リーダーやマネージャーなど、新たな役割になった際に何をしたらいいか悩んでいる方はいませんか？
オーナーシップを持ってほしいと言われ、自分なりに頑張っているが何かしらのギャップを感じる。視座を上げるという話をよくされるが、ピンとこない。そんな心当たりはありませんか？私はそうでした。
こういった話題を取り扱った記事は世の中にたくさん出ていますが、思わぬ話が自分に刺さったりします。
ということで、私の考える「視座を上げる」ことについて、実体験を交えつつお伝えできればと思います。
1. 「視座を上げる」 = 「様々な人を主語に話せるようになる」
「視座を上げる」と言われるとかなり敷居が高いと感じる方は多いと思います。「経営者視点を持て」「リーダーとしてものごとを考えろ」など、抽象的で難しそうという印象。
ただ、「視座を上げる」というのはそこまで仰々しい話でもないのかもなと最近は思っています。
「視座」とは、様々な人(やその立場)が持っている視点のことです。
そして、私の思う「視座が高い」とは、異なる視点の解像度を高めることにより、広くものごとを見ることができるようになった状態です。
エンジニアに親しみのある言葉で「変数」と置き換えてもいいでしょう。ものごとに関わる変数に、自分・チーム・ステークホルダーなどどのくらいのものがあるか、そしてそれらの変数がどう関わりを持っているかの解像度を高める形です。
「視座」という単語に高さや上がるという表現がつくのは、視点が増えることでものごとが広く・遠く見渡せるようになるからだと思います。実際はものごとの解像度の話なので、広さ、深さ、構造、時間軸が広がるというものでしょう。(参考: 解像度を上げる )
また、今まで知らなかった視点というのは大抵先輩や上司、経営者といった自分よりも経験が長い立場の人が持っていることが多いです。このあたりも視座 = 上と感じてしまう要因かもしれません。
メンバー、リーダー、隣のチーム、各事業のマネージャー、経営者、ユーザーなど、様々な自分の仕事に関わる人の視点を理解すること。
そしてそれを自分の言葉で語れるようになること・腹落ちすることが大事だと思います。
「視座」を意識する際に使える物差しとして、「その人を主語にして状況を語れるようになること」があると思います。ものごとに対してどれくらいの主語で語れるかを持って、自分の持っている「視座」を意識するのです。
なぜ様々な人の視点を持つことが必要なのか？
「視座を上げろ」は様々な人の視点を解像度高く持つことだとした場合、この解像度をあげた視点はどのように使うのか？それは、「自分への期待値を乗りこなし、飛び越えるため」です。
例えば「経営者視点を持て」という言葉があると思いますが、それは大抵の場合は実際の経営上の意思決定を求められているわけではないです。
そうではなく、「経営者視点を理解し、自チームがどうすれば事業にとって価値がある成果を出せるか考え、行動する」ことが求められます。
そしてその行動はあらゆる場面で発生しうるものです。優先順位のあがったプロジェクトをいつ差し込むか、発見された技術的負債と機能開発のどちらを優先するか、あるいはこの PR のコード品質にどこまでこだわるべきかなど。
どれもこれが正解というものはなく、今置かれている状況によって変わります。そしてこういった判断を適切に行うには、やっていることの具体の解像度も周りの様々な人の視点に対する解像度も持っているのが理想です。
よりよい判断を自分で行い、自分で行動に対してこうあるべきを示すために、様々な視点の解像度が必要となっていくわけです。
2. 「視座を上げる」際に必要な 4つのステップ
色々話しましたが、実際に新しい視点を得て「視座を上げる」にはどうすればいいか？
納得感をもって実践するのは簡単ではないです。それは、視点を得て腹落ちするためにはいくつかのステップがあるからです。
- ステップ1. 新しい視点を持つ人に気づく（視点の認知）
- ステップ2. その視点の構造理解を深める（課題・意図の理解）
- ステップ3. その視点を自分の言葉で話せるようになる（当事者としての変換）
- ステップ4. その人の視点を自分の判断軸に加える（当事者としての行動）
まず新しい視点は自分の感覚の外にあるので、そもそもとして気づくことが難しいです。人との対話やインプットなどから入力する必要があります。また、この視点が自分にはないものであるというメタ認知も必要です。
ステップ1 を越えると次はその構造を理解する必要があります。この視点では何を意識しているのか、それはなぜか、どうすれば得られるかなど、その背景や課題、意図などを噛み砕いていきます。ステップ1 で視点が違うなと気付いても、その違いをうまく読み解けなければ「自分とは違う」で終わってしまいます。
ステップ2で視点についての理解が深まったら、それを自分のものにして使いこなす必要があります。まずは自分で説明できるようにすること。自分がその視点について語り、行動する必要があります。こういったステップを踏むことで、新しい視点が自分のものになり、「視座を上げる」ことができるわけです。その具体例として、実例により新たな視点を得るエピソードを次の章で紹介します。
この自分のものにするプロセスは自分自身が全て行動しなければいけないわけではないと思います。 AI や周りの人に実行は任せて、自分が当事者として実行することを決める。それも当事者として行動できている状態と言えるでしょう。
3. 「視座を上げる」4つの実体験エピソード
ここからは、私の実体験にフィクションを交えた実例を元に、いくつか新たな視点を得た場面を解説します。
【個人->チーム】 がむしゃらにチームに貢献できることを探し、チームを主語にタスクを進める
言われたことはできる作業者から、チームで必要なことを探し行動できる状態への変化の例です。
私が若い頃にある現場に入った際、ちょうど利用している OSS の脆弱性が見つかったが、担当者不在でどうするか困っている状況でした。 当時の私としては何をやるにも初めてだったので、必要ならと手をあげて手探りで対応を進めていました。そこから誰も知らない作業を深掘りすることで担当領域に対する理解が深まり、チームで担当している製品に対する解像度を上げることができました。
停滞していることに手をあげて突っ込んでいけば、自身の解像度もあがるしものごとも前に進む。その最初の一歩が綺麗なものじゃないにしても、誰もやらないよりは遥かに前進します。そのため、たたきを作る人は偉い！と私は常々心の中で思っています。
ぜひチームで必要なものごとに関わることで、視点を得ていきましょう。
【チームタスク->メンバー自身】チーム内の解像度を上げ、チームメンバーを主語にチームに向き合う
自分のものさしだけでやるべきことを考えるリーダーから、メンバーの状態をみた上でチームで動くリーダーへの変化の例です。
私が小さなチームのリーダーとなった時のことです。私は期待に応えたいと意気揚々と仕事に取り組みました。
とにかくガンガン新しいことに挑戦するのが正義だと考え、メンバーに対してもその動きを当たり前に要求していました。まだ経験が浅い人でも、やれば伸びるはず！自分で考えてとにかく動けと要求します。
その結果、メンバーがみるみる疲弊していきました。挑戦することが成長につながることはありますが、メンバーそれぞれの適性を見ずに、本人の能力や耐えられるキャパシティを越えた期待値をかけ続けてしまっていたのです。
結果、チームを去る人も現れ、チームは成果を出せずメンバーや役割を入れ替えてテコ入れすることとなりました。チームとしての理想や期待される仕事の振る舞いだけでなく、メンバーの状態や能力、モチベーションといった視点を持ち、チームに向き合うことが当時の自分には必要だったのです。
【チーム->担当領域】チームへの期待値の解像度を上げ、自領域を主語にめざす状態を描く
今あるチームを心地よくするリーダーから、チームがどうなればよりよい価値貢献ができるかをめざすリーダーへの変化です。
その後色々な経験を重ねマネージャーとなった私は、チームの中でリーダーが担う役割を定義し、メンバーが自分たちの開発に集中できる環境を作りました。チームも徐々に拡大し、チームが成果を出す状態を作る点においては一定の手応えを感じていました。
一方で、いわゆるチームが自己決定できるチームにはなりきれておらず、少しギクシャクしていた状態でした。その原因は私にありました。
周囲がチームに求める期待値を自分の言葉で語ることができておらず、ロードマップが変更になった時も言われたことをそのままメンバーに伝える状態になっていたのです。これではなぜ変更があったのかをメンバーが理解することが難しく、自己決定のしようがない状況でした。
この原因は私自身のロードマップ変更に対する背景や投資意図への解像度の低さと、その低さからくるメッセージングの弱さが大きな要因でした。それだけではなく、メンバーの居心地のよさを阻害するのを恐れ、フィードバックを躊躇するマネージャーとしての弱さも要因にありました。
その状態を解消するため、まずはメンバーに対して腹を割って現状や自分が困っていることを伝え、対話を重ねてチーム内の関係性を修復するところからはじめました。私に対して足りないと思われることは真摯に受け止め、改善に努めました。
また、周囲のマネージャーやステークホルダーとも対話を重ね、ロードマップや優先順位の背景に対するなぜ？の解像度を高めました。
【担当領域->会社】 全社ビジョンへの解像度を上げ、会社を主語に自領域が生み出す価値を示す
自領域の担当から、事業の中心領域をリードする立場への変化です。
担当領域全体のエンジニアリングマネージャーとなった頃のこと。担当領域のドメインやチームメンバー、プロダクトに対する解像度は持っておりプロダクト自体は前進するのですが、なかなか領域を越えて周囲のチームに刺さる成果が出ていませんでした。
なぜかというと、会社のミッション・ビジョンや事業に対する解像度が甘く、事業の中でなぜ我々のプロダクトが必要で、どのような価値を生み出していくことが必要かの接続が足りませんでした。
そうするとどうなるか、いくら自分の中でロードマップや優先順位、チーム体制を考えたところで、自分の見えている視点以上の成果が出る構造にはならない。例え社内の状況が変化し注力したい領域が現れたとしても、その変化を自領域に取り込み反映する感度が足りない。あるいはいくら開発を重ねようとしても、それがプロダクトを通してどうユーザーに利用されるのかの具体性が足りない。
こういった方向性には答えがなく、答えのない課題を解くには仮説を立てて検証を繰り返す必要があります。しかし、仮説を立てる段階で事業と接続するための視点がないと、いくら試行錯誤しても領域内で閉じた仮説しか出てこないのです。そのため、新たな視点を取り入れる必要があります。
欲しい視点になる羅針盤は何か。それは「この会社が出したい価値」そのものです。
その視野を得るために、私にとって一番刺さった取り組みの 1 つとして、会社のミッション・ビジョンを分解することを紹介します。
ここでいうミッション・ビジョンは、自領域のものではなく、会社全体のものです。 freee でいうところの「スモールビジネスを、世界の主役に。」というミッションから立ち返り、マインドマップを作り深掘りしました。
なぜスモールビジネスなのか？スモールビジネスのどんなペインを解消したいのか？なぜたくさんのプロダクトを提供しているのか？なぜ統合型というソリューションを選んだのか？などの問いをマインドマップで深掘り、社内にあるミッションについて語った資料を深掘りして自分なりに理解を深めました。
(やっている人にとっては当たり前なことだと思います)
また、 freee が SaaS の事業会社として売上を上げている仕組みについても解像度を深めました(書籍PLG プロダクト・レッド・グロース など)
そこまでミッションへの理解を自分の言葉で広げたら、その後はじめてなぜ自領域が重要なのかを、関係する要素を中心に深掘りしていきます。
そうやって改めて自領域の価値を考えてみると、例えばこのような形で自領域について語ることができるでしょう。
- スモールビジネスの人たちは、バックオフィスや経営にまつわる業務を freee に任せることにより、自分たちの専門性に向き合い活躍できる世界を作ることができる。
- そのような世界を広げていくと、自ずと事業も拡大しバックオフィス業務の範囲も広くなる。
- この規模の業務も freee を使えばなんでもできる世界にするためには、freee 上で幅広いバックオフィス業務が統合された体験を得られることが重要となる。
- => スモールビジネスの人たちが活躍できるバックオフィス業務の統合体験を実現するには、シームレスな業務データの「統合」が重要であり、その統合を安全に実現するための「認証認可」が統合されることが不可欠である。
上の話は認証認可基盤開発エンジニアについて - Speaker Deckで語っているチームのミッションと変わらないですが、なぜを突き詰めて事業と繋げるためには上位の世界から解像度を上げていくことが重要です。
4. まとめ: まずは周囲の解像度を上げ、語れる主語を増やそう
何か今期待値に苦しんでいる人に伝えられることないかなと考えた結果、自分が当時知りたかったことを詰め込みました。
まとめてみると「周囲に対する解像度をとにかく上げる」という行為に落ち着き、その行為を一言で表すのが「視座を上げる」という言葉だったんだろうなと自分なりに理解しています。
この記事が、あなたの中で何かしらの視点を得るヒントになれば幸いです。
