今回も、ふと思いついたことをつらつらと書いています。

マネージャはとにかく忙しくなりやすい
全ての情報を集約し、全ての意思決定が集まる

やらないことを決め、仕事を減らすことが必要

• 重要な課題を見つける時間を作るため

• 課題の解き方を考える時間を作るため

• 新しく生まれる課題に負けず、今やっていることをやり切るため

逆を言えば、これら全てが出来ていなかった。

• 日々のタスクの意思決定フローに入ってしまって忙しくしてしまった

• 状況変化に対して、効果的な課題を見つける時間を十分に作れていなかった

• 重要な課題を見つけても解き方を考える時間を作ることが出来ず、目の前のすぐ出来る必要な雑事の実行に時間を取られていた

• 新しく生まれる重大な課題に対処するため、中長期に向けた施策の優先度が下がってしまっていた

こうなってしまった１つの原因はミドルマネージャの動きを出来ていなかったからだと考えています。マネジメントのカテゴリは広いため、基本スキルを磨き込むことと応用スキルを身につけることが必要でした。

時間を減らす具体的な動きの例を上げると、重要なチームのミーティングに参加することが可能であっても、自分にとって優先順が別の仕事があるならば、一時的に参加しないことを宣言する必要があります。普通のチームマネージャであれば、チームの近くに出来るだけいる方が良いことが多いですが、ミドルマネージャの優先順位はもっと複雑になります。

この意思決定をするためには、自分にとって何が一番解決すべき事なのかを明確に持っている必要がありますが、このときの自分は感覚的に動いてしまっていました。

目の前に振ってくる課題を順番に対応するだけではダメで、自分で価値を意味づけする根拠を探り、優先順位を明確に定義しておく必要があります。

その中で、急速な変化への対応が難しい要素があり、予測が難しいも難しい要素をもつものが、開発組織の課題になります。その気付きの幾つかを紹介したいと思います。

経験の元になっている組織変化の多い状態とは？

まずは前提の状況です。

関わった期間はおよそ３年間。
メインとなる組織は開発組織は5人から30人規模になり、事業部としては80人までの変化です。

３年の間に組織にあった大きな変化は以下のとおりです。
１．メインチームの立ち上げ ( 採用や開発プロセスの導入等から)
２．メイン組織の事業を実現するためのサブラインを実現するための別組織の立ち上げ(後に横断組織のチーム)
３．M&Aによる会社の受け入れ。開発部門のマネジメントの追加と連携 (EM不在の会社)
４．メイン組織の人数増加による３チームへの分割 (職能別分割)
５．メイン事業を前提にした次の大きな事業を実現するための新規事業を並行した立ち上げ
６．メイン組織の人数増加とナレッジの変化によるチームの全面変更 (フィーチャー別チームへの再編成)

自分が直接関係する組織の大きな変化はこの６つになります。

このチームの変化と連携して、会社全体組織との連携、横断組織との連携などの会議体の調整なども変化しながら対応する必要がありました。

ここでは組織的な大きなものしかピックアップしていませんが、機能開発の予定の大きな変化も何度もありました。リリース前α版、β版、リリース、PMF模索、PMFからグロースへの変化、などの開発変化も起きています。

メイン以外の組織の変化を自分が担当することになったのは、メインの事業と深い連携が必要な組織だったからです。そのため、周辺の組織変化に合わせて、常にメインで担当するチームへの連携期待の変化がありました。
つまり、依存性の薄いチームが別で出来るのではなく、常にメインチームへ大きな影響を与える組織変更に繋がっていました。

３年の間に６回の変化があったということは、少なくとも半年に１回のペースで組織への期待が大きく変化し、組織の設計が必要になり、メンバーの動きにも大きなチューニングが必要な状態が発生していました。開発を継続する延長の目標設定ではなく、常に変革の理想設定が必要だったと感じます。

常に新しい組織を受け入れ立ち上げしているため、常に採用が課題になっていました。つまり、既存の開発の推進、採用の課題の推進、新しい組織変化の推進、この３つが常に動いている状態だった上に、採用や立ち上げをするなかで掌握範囲が自然と広くなりました。

拡大する組織を深く意識できないままに自分の経験の範囲のマネジメントを進めていました。
そのような状態で組織が進んでいくときに何が必要だったのか？を振り返っています。

将来の組織状態に向けた取り組みを実行すること

半期の事業目標からのブレイクダウンでは目の前の開発物に集中しがちです。しかし、組織を変えるには半期の事業の目標から起きることがない組織の変化を意図的に起こす必要があります。

通常の組織変化のスピードであれば、課題が顕著化してから対処するのでも間に合いますが、スピードがある成長期のスタートアップでは、組織の変化が大きいため課題の発生スピードが早く、対応の難易度が高まります。

私はこの経験が足りず、全て課題が顕著化してから対処していたため、組織的な大きな課題が常に発生している状態になり、日々の活動で苦労する期間が長くなってしまいました。

耐える期間を越えて、対処に十分な人や仕組みを整えることができましたが、その時に気がついたポイントを幾つか紹介していきます。

中長期的な開発の目標を事業の目標とは別で持つこと

事業の目標とは別に開発の目標を持つ必要があり、変えていく必要があります。事業の目標を達成するための短期的な開発の目標を達成するだけでなく、中長期の開発チームの目標が別で必要です。

中長期と言っても、中長期的な機能開発の目標ではありません。中長期的に開発の中で起きている課題を個別に変えていくための組織変化の目標を入れる必要があります。

事業の目標は事業の将来の状態を逆算して立てています。同様に開発チームの状態も想定する状態から逆算して立てる必要があります。組織を設計する時に、目の前の課題に対して組織設計しているだけでは次の課題に対処する組織は出来ていません。

自分の役割を引き継ぐ人を育成や採用すること

小規模のチームのときには組織に足りないケイパビリティを持つ人を採用します。しかし、チームが大きくなってきたときには、自分の役割の一部を引き渡せる人を採用し、次の組織変化に備える必要があります。

私の場合、開発メンバーには開発に集中してもらい、私は採用やプロセス改善などを行うことをしていました。短期的なマイルストーンのゴールを達成する必要があり、役割分担をすることが早いと考えていたからです。

しかし、スタートアップの事業変化により、ある時点から中長期的な事業成長に向けた対応が必要になります。この変化に組織が対応する必要がありました。

役割分担を強くしていたチームのため、また、目の前の開発に集中した採用をしていたため、自分の役割の一部を上手く引き継げる人を作ることが出来ていませんでした。

気づいた後に少しずつ採用などは移管していましたが、新しいことを進めるための時間を取るには時間が掛かってしまいました。

今の課題に対処する人を採用するのではなく、組織の将来を任せる人を採用する

一つ前の対応と重なる部分もあります。しかし、あえてこれを別で書きたいです。課題に対処するにはスキルで採用しがちです。しかし、組織の将来を任せられる人は現時点のスキルだけを見る必要があります。

これは大きく２つのポイントがあります
１つめは、ポテンシャルです。現時点のスキルに不足部分があったとしても、概ねの土台のスキルがあり、将来時点でスキルの合致が見えるのであれば、それは組織にプラスになることが多いと感じています。

２つめはカルチャーフィットです。スタートアップでの採用の言葉には何度も登場しますが、誰か１人でも合わないと感じた人は採用するべきではないです。それはパーソナリティの相性もあるかと思いますが、私は客観的な判断のポイントに「その人にチームの将来を任せられる人なのか？」で判断する基準が良いのではないかと考えました。
チームの全てを任せる訳ではなく、特定領域の何かをまるっと任せても信頼できる人だと良いと思います。それはスキルも必要ですが、それ以外の感性で感じる要素も必要になると思います。

まとめると、現時点の課題で人を採用するのではなく、不確定な未来の状態を任せる人を採用するべきだと考えています。

そのためには、チームレベルのマネージャは頭数のチーム設計だけではなく、詳細なペルソナも含めた開発組織の未来を描く必要があります。

採用と開発の両方を深く見ることは難しい

採用が急速に必要な場合、どちらかは浅くならざるを得ません。採用の負荷が高い状態が一時的であればよいですが、そうでない場合は採用軸と開発軸の両方にチームを変えるキーマンになる人を配置したいです。抽象的な考え方だけで変わることは難しく、抽象を具体に落とし込める人を3-5人に1人を置くことを意識できるとよいです。

時にテックリードと呼ぶこともありますが、組織を変える人はテックリードではないと思います。チェンジエージェントと呼ばれるスキルの持ち主が、決して技術のスキルが一番な訳ではないこともあります。

採用が活発でない状態であれば、マネージャはチームの中の組織改善に集中できますが、採用が活発な時には想像以上に多くの時間を採用に使う必要があります。

周りの協力を得るサブ組織を作る

採用や組織連携などの取り組みはメイン業務として100%取り組むことは難しい。しかし、マネージャがボールを持って進めるようになってしまうと、それに掛かりきりになり、次の改善の取り組みができなくなってしまう。
なので、マネージャは１人でサブラインの役割を引き取ってはいけない。
開発の多少の負担になったとしても、メンバーを巻き込んで進める必要がある。

一番ベーシックな方法としては特定の課題を解決するワークグループなどを作ることが良いと考えています。

常にマネージャが居なくなっても施策が進む状態をゴールに描いて、組織とプロセスを作る必要がある。スピードの早い組織では立ち上げて動かしてからではなく、動かす時に役割を引き継ぐ形を描いた方が良いです。

小さな意思決定を自由にできる範囲を作っていく

チームもそうですが、ワーキンググループ、プロセス、規約、ワーキングアグリーメントなど、自由に決められる範囲を作っていく。

テックリードであればこの範囲を自分で決めることが出来るが、テックリードが居ない中では相談や合議になってしまう。これらの決め方は納得感は高くてもスピードは遅いので、小さな単位にして小さな範囲の変更権限などを個別に持ってもらう方が良い。

つまり、最も気をつけるのはチームの大型化。チームを小さく保つには、チームの中でリーダー的な動きが出来る人を常に育成や採用する必要がある。この数が合わなくなると、チームを分けたくても分けることが難しくなったり、分けた時に大きな問題が発生して対処に追われることがある。

肩書きやタスクを渡すのではなくミッションを渡す

チームなどの分かりやすい単位で任せるのであれば肩書きは分かりやすいが、組織が大きくなってくるとチームの単位ではない期待が多く出てくる。一部の課題にフォーカスしたり、一部の強みにフォーカスした役割が期待されることがある。

その時にタスク単位では変化に耐えきれず、肩書きではフォーカスが曖昧になってしまうことがあると感じます。渡した時に期待のすり合わせを行っても、変化に対応した変化が擦り合わせ出来ていない場合、期待の齟齬が発生して、コンフリクトに繋がることもあります。 (実際に多数のコンフリクトを発生させてしまったと感じています)

期待を明確にするにはミッションを定義し、言語化して渡すことで齟齬なく期待が達成が出来るタッグを組めるようにする必要があります。

全ての事象を言語化をする

一気に抽象度が上がりましたが、結局これです。最初はこれが出来ておらず、感覚で動いていました。判断軸が緩くなったり、行動の根拠がうまく説明出来ませんでした。感覚的には正しいと思っているが、自分の領域でないメンバーにどう伝えるかが全てです。

チームを推進していた当初は事業で必要な開発にフォーカスしすぎていたため、中長期に組織で必要になることを直感的に行動していましたが、言語化が出来ておらず、他のメンバーに十分に説明ができないことがありました。

言語化するには深堀りが必要で、ある程度の型が必要になるためロジック組み立てたり、未来の理想像や仮説が必要になります。採用も組織も人への期待も、全て言語化の土台が必要だと感じました。

気がついた時には大変な状態になっていた反省

組織の変化を起こしても期待する成果はすぐには得られない

組織の課題が起きたとき、気がついたときには自分の予定もいっぱいで、毎日の仕事は採用や組織運営などの緊急性の高いタスクが中心で溢れている状態でした。

組織を変えるには、採用の活動を押さえて深くチームに入るか、採用でチームを一緒に変えてくれる人を採用するかの２つの方針を考え、組織の次のアクションも想定して、後者の採用の方へ力を入れることにしました。

未来の組織を想定して組織の形を変えることは出来ても、取り組み方を変えるには時間が必要でした。組織に大きな変化を起こした場合、その方法が馴染むまでに３−６ヶ月くらい掛かります。小さく変わることがベストですが、環境変化のスピードが大きい場合は大きく変えなければならないことも多くあります。

チームのメンバーは安定的に開発のアウトプットを出してもらっていたため、変わる理由が弱くなっていたことが、逆にチームが大きくなる中で効率の良いやり方が変わっていったことに追従する変化を起こせていませんでした。つまり、組織の進め方も変える必要があったが、明確に変えるタイミングが遅れて、やりづらさの多い状態が続いてしまったと感じています。

組織を変える時に新しいやり方を入れると反発があります。なぜなら、一時的に新しいやり方になれるまでにパフォーマンスが下がるため、進めている人には新しい方法をやる理由を感じないからです。そのパフォーマンス低下の谷を超えて理想状態のパフォーマンスを作るには、明確な理想像の定義と理想に向けた推進です。

自分に必要だったのは、理想を定義し、共有し、全員でそこへ向かうことだった。
事業のための機能の開発を進めるだけの組織だけではダメだということです。

自分にはマネージャとして必要なチェンジエージェントの知識が不足していました。

１チームマネジメントと複数チームマネジメントの違いを理解できていなかった

ロワーマネジメントとミドルマネジメントの違いを理解しておらず、パンクした。ミドルマネジメントの知識不足の観点は、今回の記事のほとんどをカバーする課題ですが、マネジメントの期待の階層の知識が足らず、理解が出来ていなかったことは大きいです。

マネジメント という言葉の解像度が低いと普通に起こってしまうのかなと感じます。それらは組織の不協和音に繋がり、メンバーのコンフリクトを多く発生する原因の１つとなります。

当時の自分では組織構造による影響を与え合う関係の理解力が足りず言語化ができませんでした。その結果、自分の状況を上手く伝えられていなかったと感じます。それが原因で自分の状況を根本的に理解してもらえていた人を作ることが出来ず、また仕事の範囲も広くなっていたために伴走して全体の構成を考えてもらえる人も作れていなかったと感じます。

自分には言語化するスキルや理想像を描くコンセプトを立てるスキルが不足していました。タスクマネジメントやエンジニアが持ちがちな技術的なマネジメントをベースに、人に寄り添うマネジメントを体系的な知識や目的石工無くやっていたと思います。

しかし、ミドルマネジメントに必要なことはガラッと変わり、更にはスタートアップ特有の環境はコンセプチュアルスキルをクリアに理解すること求められました。

カッツモデルと呼ばれる概念はコンセプチュアルスキルはハイレイヤーのマネージャに必要な概念でした。しかし、新しく考えられたドラッカーモデルでは、コンセプチュアルスキルは全員に求められています。スタートアップなどの理念駆動での開発推進をするときにはテクニカルスキル中心の知識だけでは難しくなってきています。

下記のドラッカーモデルです。

このコンセプチュアルスキルを実現するために重要な１つが言語化スキルと考えています。

そもそも、自分はマネジメントにこの階層があることを知りませんでした。
失敗と反省をする中で、このような考えがあることを知り、自分の動きをどのレイヤーのマネジメントに期待されているかを理解し、行動ができるようになってきたと感じます。

成果ではなく頑張ったことを認められようとしていた

事業を進めるときに顕著化する課題に対してリアクティブ(反応的)に対応していた。状態の理想像を描いてプロアクティブ(能動的)に変化を起こしていく必要があった。

ミドルマネジメントの能力の１つかもしれないが、こちらは自分の感情面でのフォローが足りなかったこととして、別で書きたいと考えました。

成果の定義は組織の理想像であるべきだった。しかし、成果の定義を「顕著化した課題への対処」が自分のミッションだと考えてしまっていた。事業の課題になっている原因は、顕著化した課題だけに対処しても解決しないことが多い。原因を解決して事業を実現する組織を作るには仮説と逆算思考が必要になります。

それを明確にするのが理想像の定義だ。理想像を明確化することで未来への解像度を上げ、途中に現れる課題を洗い出し、根本的に解決すべき原因を見極めることが出来る。
やった方が良いことが無限にある中で、やる必要があることが線引される。

次から次に現れる課題をモグラ叩きのように全力で課題に対処していたことを評価してもらおうと考えていた時もあったが、本来扱うべきはもっと潜在的で抽象度や不確実性の高い状態の課題に対処することでの成果だと理解しました。

つまり、理想像を描くのに必要なことは組織に必要な問いを立てることです。問いは整理だけでなく、知識も必要だと感じます。特に開発組織は技術的な面が表に見えにくいため、複雑度が高まっていると感じます。感覚的な早さと実際の早さのズレが発生することも多くあります。

どうすればこの状況を脱することが出来たのか、というのが今回の自分の書いているこの記事そのものに詰まっているかなと思います。１つのスキルでは越えられない、マネジメントの総合力が求められると感じます。

反省を活かした組織づくりに必要なこと

つらつらと書いていましたが、やった方がいいと思うことをピックアップすると

• チームの意思決定の目線を合わせるために理想状態をすり合わせること

• 目の前の課題を解決と開発タスクを捌くだけの組織にならないこと

• 採用したいペルソナを強く持ち、ペルソナがいる場所に発信すること

• 失敗を経験に昇華するための時間を作ること

こんな感じのことかなと思います。

とにかく変化が多く、反省だらけの失敗が多くありました。上手く出来たこともありますが、失敗があったからこそ得た経験が多いと感じます。次への対処を考察できたことで、今だから出来ることは確実に増えていると感じています。

謝辞

色々な失敗で迷惑をかけながらも一緒に開発をしてくれたチームメンバ、沢山の課題を相談させてもらった上司、一緒に組織をリードしてくれた事業マネージャ、かなりの勢いで採用を一緒に進めてくれた採用人事、色々足りないことがあり迷惑かけました。色々な人に感謝しています！！

ありがとうございました！！！

これを読んだ人が少しでも開発組織の改善に役立ててもらえると嬉しいです。