小規模スタートアップのマネジメント

27 January, 2022

組織

マネジメントについて学ぶために「急成長を導くマネージャーの型～地位・権力が通用しない時代の“イーブン”なマネジメント」を読んだ。

会社の状況としては、業務委託も含めると10人以上に関わってもらっていて、徐々に組織の体制作りが求められている段階である。
業務の進め方としてはプロジェクト制を導入している。
会議体としては、次のものが定例化している。

月曜に一週間分の大枠を定めるチェックイン（プロジェクト単位）
毎朝15分の朝会（プロジェクト単位）
金曜日に週の稼働を称え合うWin Session（会社全体）
上長とメンバーの1on1

無駄な会議は無くせとよく言うけれど、組織やチームとしてのリズムが作れるので、定例は大事だなと最近思う。

チームをマネジメントする

メンバーの力を最大限発揮させ、チームを成功に導くのがマネージャーの役割だと思っている。
メンバーの力を引き出すためにはどのようなことが必要なのだろうか。

本書によると、そもそもメンバーが仕事に求める意義は3つある。

社会軸：自分達の貢献対象（ユーザー、顧客、その先の社会）に貢献したい
市場軸：競争相手や関連事業社ともに所属しているその市場において、存在感を示したい
自社軸：日々の業務を通じて、存在感を示したい

人によってこれら3つの刺さる軸が異なるため、マネージャーはチームの意義を社会軸・市場軸・自社軸で言い換えられる必要がある。
自社軸は個人軸と捉えても良さそうな気がする。
まとめると、要は誰かに誇れる仕事をしたいという話かなと思う。

現状把握の具体的手法

メンバーと接する際に重要な点として、一次情報に触れているかどうかがある。

①一次情報に触れていない示唆は、机上の空論であり、成果につながらない
②一次情報に触れていない人からの指示を、メンバーは聞く気にならない

もちろんすべての一次情報に触れていては身体がいくつあっても足りないので取捨選択は必要だが、出来る限り一次情報には触れた方が良い。

メンバーについて把握する場合は次の3つを知っておく。

現状：メンバーやチームの把握に役立つ
Will：メンバーのアサインメント・動機付けに役立つ
Can：メンバーのアサインメント・能力開発に役立つ

現状やWillについては定期的に1on1等で確認すると良さそうだ。

目標設定のための分析・検討に時間をかけすぎない

よくやってしまいがちだが、目標設定や施策が効いているかの分析に時間をかけすぎてしまうことがある。
もちろん両方とも大事で、本来ちゃんとやるべきものだと思う。
ただし、それに何週間も費やしてしまい、結局何も施策が進まなかったというのが最悪のケースである。

仕事におけるアクションというのは、目標と現状のＧＡＰを埋めるためにおこなうものなので、目標が決まっていないということは、何もアクションがおこなわれていないということです。どれだけ目標として妥当なものを考えようが、その設定のための時間が長ければ長いほど、チームのアクションは減ります。さらに、ベンチャーであれば、妥当なラインなど検討を続けても、どこかでその検討による意味がなくなるラインがあります。考えても、わからないものはわからないのです。目標設定のための分析・検討はほどほどにし、野心を根拠に設定します。「このラインが妥当だ」ではなく、「ここを目指したい」という意思をもって目標を決めます。そのようにして早く目標を決め、早く動いて早く失敗して早く学んで、その目標を到達できる方法を探すのです。野心をもとに早く決めて早くチャレンジしたほうが、最終的な成果にはつながります。

変化に耐えられるチーム作り

スタートアップは状況が目まぐるしく変化するため、会社全体でやるぞ！と決めたことが1ヶ月後にガラッと方向転換したりする。
それ自体は悪いことではなく、どちらかと言えば良いことだと思うのだが、あまりにやることがコロコロ変わってしまうとメンバーも疲弊するし、経営陣への信頼も下がってしまう。

方向転換をする理由はだいたい以下の2つとなる。

チームの役割や目標が変わったなど、方針よりも上位概念が変わった
上位概念は変わらないが、今の方針だと目標が達成できないことがわかった

変える際は都度、「なぜ変えるのか」を丁寧に説明することが大事。
その説明を怠らなければ、変化による混乱は起こらない。
（そもそも全員が同じ方向を向いている必要はあると思う。）

強い体制作り

チーム体制は、「体制パターン × アサインメント × 権限設計」の３つをかけ合わせて構築する。

状況に応じた構造を選択する
メンバーの特性を見極め、アサインする
チームの中でだれが何を決めるのか、権限を設計する

体制パターン

チームの体制パターンには、文鎮型、構造型、プロジェクト型の３つがある。

文鎮型

1人のマネージャーに、チームメンバーが直接ぶらさがっているパターン。

メリット
マネージャーがすべてのメンバーと直接コミュニケーションを取ることができるため、意思決定～実行～振り返りが高速に回ること。

デメリット
マネージャーがすべてのメンバーと接点を持つ必要があるため、マネージャーがキャパオーバーになる可能性があること。

構造型

マネージャーとメンバーの間に中間リーダーがいるパターン。
マネージャーがすべてのメンバーを見るのではなく、マネージャーはおもに中間リーダーとコミュニケーションを取りながら、中間リーダーを通じてメンバーを見ていく。

メリット
中間リーダーがいるのでメンバーが増えても機能しやすい。

デメリット
中間リーダーを挟んだマネジメントになるので、意思決定～実行～振り返りのスピードが落ちる。

プロジェクト型

マネージャー、シニアスタッフ、ジュニアスタッフと階層を分け、シニアスタッフとジュニアスタッフで、機能ではなくプロジェクトごとにチームを形成するパターン。

メリット
構造型のように中間リーダーとメンバーを固定化しないので、プロジェクトごとに柔軟にチームを動かせること。
チームとして成功するための施策を探索し、実験を繰り返している期間や、クライアントワークや開発案件など案件ごとに規模や納期が違う中で柔軟にチームを作るような組織に向いている。

デメリット
プロジェクトが起こっては消えを繰り返し、その中でメンバーのアサインも都度変わることから、リソース管理の難易度が高く、それを怠ると十分稼働していないメンバーが発生したり、逆に業務過多になるメンバーが発生する。
メンバーに特定のマネージャーや中間リーダーがついているわけではないので、メンバーの育成や評価などのピープルマネジメントが疎かになる可能性がある。

microCMS社はプロジェクト型を採用している。
Product Led Growthで進めているため、全てのプロジェクトがプロダクト開発に紐づいており、エンジニアリソースの圧迫が激しいのが今の悩み。
PLGで行くからには仕方ないとも思うので、そこは人材採用で解決するところだと思う。

メンバーが増えてきたら構造型の組織図がありつつ、縦割りでプロジェクトを複数編成していく形を想定している。

状況ごとの使い分け

こちらの図が紹介されていた。
今は立ち上げと急拡大の狭間という感じがするので、まさしくプロジェクト型から構造型に変えていくタイミングだと思っている。

アサインメント

アサインメントに活かせるメンバーのタイプの分け方。

パートナー

マネージャーの後任として最適な人財。
自分で自分のことを客観的に評価できるので、メンバーを評価することにも長けており、他人にも依存しない。
マネージャー候補。

甘えん坊

チームの施策に協力的で、チームに対しての提言もおこなってくれるが、自信が持ち切れず、マネージャーに対して第三者的なアドバイザーに終始しがちなタイプ。
パートナータイプのように強くはないが、逆に弱い人の気持ちがわかるため、チームメンバーの悩みや相談には親身に乗れることが強み。
チーム運営業務の中でも、メンバーケアなどピープルマネジメントの業務が向いている。

一匹狼

自分の強み・弱みをよく理解したうえで、その特徴をしっかりと活かせる業務をすることを仕事の目的と置いているタイプ。
チームの施策に協力的なわけではないが、特定の領域について異常に詳しかったり、のめり込んだりする。
自分の強みの発揮しどころもズレていないため、特定の領域で高い成果を残す。
チームプレイには向いていないので、集団の調和が求められる仕事より、個で大きな成果を残せる仕事にアサインする。

傭兵

他人評価を得ることで自己実現を図るタイプで、キャリア・報酬などの自己メリットを強く求める。
評価基準を細かく気にし、その結果得られるものを確認しながら、その基準を達成しようとする。
評価基準とリターンが明確な仕事にアサインすることで、だれよりも目標に執着してがんばってくれる。

どのタイプが良くて、どのタイプが良くないというわけではなく、どのタイプも活かすべき特徴を兼ね備えている。
メンバーを理解してアサインメントを考える必要がある。

採用チームを推進する5つの仕組み

①進捗の可視化（チームの主要な活動がどのように進んでいるのか、常に見えるようにする）
②情報共有（チームメンバーの業務効率や意思決定の質を引き上げる情報を共有する）
③報告（知るべき人に知るべきことが、適切なタイミングで伝えられるようにする）
④議論（１人では生めない解を、複数人の議論により生めるようにする）
⑤意思決定（決めるべきことが決められるようにする）

現状では、①〜③については毎日の朝会で行っている。
④については必要に応じて議題を持つ人がミーティングをセットする。
⑤は基本的にはPM（Project Manager）、プロダクトに大きく影響がある場合はPO（Product Owner）に相談。

個人目標設定と評価こそがメンバーのエネルギーの源泉

チーム目標で目標設定をすると、どうしても目標が自分ごとに感じられなかったり、振り返りをする際に自分の成長余地が見つかりにくかったりする。

目標は「個人」のレベルまで落とし込んで設定することで、自分の成長余地が発見でき、自己成長につながる。
個人に対し目標設定をし、その結果に対して評価をするというこの一連の「評価活動」は、メンバーにとって最大の成長機会であり、クオーター（四半期）や半期に一度訪れる「成長のボーナスタイム」です。
この機会を逃さず、しっかりと評価活動をおこない、メンバーを最大限成長させ、チームの戦力を高めることがマネージャーには求められます。

評価は納得解

完全に正確な答えのような評価ができない以上、評価は「納得解」。
メンバーがその評価に「納得」し、受け止め、そこから成長課題を設定し、モチベーションを向上させることができれば、評価は成功となる。
せっかくの武器も、言語化しないと、必要な時に自分の武器庫から取り出せない。
その言語化を支援し、メンバーの学びを自らの武器に変えてもらう。

「うまくいったこと、いかなったこと、それぞれどのようなことがあったか？」

「目標達成に活かせる学びはどのようなものがあったか？」

そう問い、メンバー自身に言語化を促す。

達成度の認識について擦り合わせる

評価期間が終わり評価に入る前に、まずはメンバーと達成度の認識についてすり合わせる。
目標設定と同様、メンバーの自己評価とそう考える理由を聞いたうえで、マネージャーからフィードバックをおこなう。
最終的な評価ではないものの、マネージャーがメンバーの達成度についてどう考えているかについてコメントをする。
メンバーの自己評価について、「この点は認める」「この点は認識が違う」とはっきりコメントをする。

3つの評価軸

成果（定量あるいは定性で、評価期間の目標が達成できたかどうか）
能力（どういう能力を身に付けたか）
バリュー（自社で定めるバリューをどう体現したのか）

ベンチャーの場合、プロジェクトの新規性が高く、成果の予測が立て辛い。
その中で「成果」だけを評価軸にしてしまうと、社員が野心的な目標設定をおこなわず、保守的で予測可能な範囲の手堅い目標しか持たないということが起こりうる。

成果であれば、普段特に観察していなくても、期末の成果を見ればわりと明確に評価がわかる。

しかし、能力やバリューは、普段観察しておかなければ何もフィードバックができない。
メンバーの自己評価に何か意見があったとしても、メンバーとしては受け入れられない。

観察した事実を元にフィードバックする必要がある。

「その期間、野心的な目標に向かい、がんばった結果はどう見えているのか？」
「その結果としての客観的な評価はどうだったのか？」

これが、メンバーの一番の関心事。
メンバーの一番の関心事に全力で答えられないマネージャーなど、どれほど良い戦略、組織を作ったところで、実際そこで働く人は動かせない。
逆に、メンバーの一番の関心事に全力で向き合うならば、メンバーはマネージャーのことを強く信頼し、その他のことが多少及ばなくても、しっかりと動いてくれる。

ピープルマネジメント

シニアなスタッフには背景と業務目標だけ伝え、あとは本人のやり方に任せれば良い。
逆にジュニアなスタッフには、要件、参考情報まで伝えて業務に臨んでもらう。

メンバーのタイプに応じて適した関わり方をする。

「メンバーのスキルが不十分で、かつ重要度が低い」という業務です。人はここで育成をします。共同ワークゾーンでは、業務の重要度が高いので途中でメンバーの仕事を奪ってしまうことになり、計画的に育成できません。育成目標をもって計画的にメンバーを育てようとする時は、このゾーンで業務を任せます。

フィードバックのプロセス

相手が感情的な反応を示したら、一度時間を置くことが重要です。
そこでロジカルに事実を説明し、相手の逃げ場がないほどに理路整然と伝えても、相手は受け止め切れません。
感情的な反応を示した時点で、冷静な話し合いはできないと考えてください。

これは文章に書くのは簡単だが、実際に行うのがかなり難しい・・・。
相手のためを思ってのことだということを真摯に伝え続けるか、はたまた心を無にするか・・・。

普段の信頼関係もかなり大事だなと思う。

毎週の1on1でしっかり認識の擦り合わせができていれば、フィードバックの際にいきなりどんでん返しは起きないはずだ。
逆にそれを怠ると悲惨なことになりそうだ。