ログラスのよしだです。最近戸建てに住み始めました。巨大な自作PCをいじっている感覚に陥ってしまい、日々どうカスタマイズするか？動線は？配線は？と考えるのが楽しい反面、課題も次々に現れています。洗濯機が階段の手すりで搬入できなかったり、カーテンレールがないのでまだカーテンが取り付けられなかったりと、試行錯誤の連続です。
楽しさと課題が隣り合わせなのは、戸建て生活だけでなく、チームの立ち上げでも同じだと痛感しています。直近では複数のチームの立ち上げにEMとして携わり、そこで得た学びと反省をもとに、この記事では成功例や失敗例を赤裸々に共有したいと思います。
想定読者
- チーム立ち上げを任されたけれど、進め方がわからない方、不安を感じている方
- チーム立ち上げを失敗して、落ち込んでいる方
エピソード1
チーム立ち上げの最初の例として、フロントエンドチームのケースを紹介します。このチームは、今後の事業成長を踏まえてメインプロダクトのフロントエンドアーキテクト領域やデザインエンジニアリング領域を担うもので、新規プロダクトの基盤整備や開発体験の向上を目的に組織化していきました。こうした背景の中で、「チームの存在理由を明確化する」 ことが初期フェーズでの課題でした。
進行
元々、このフロントエンド領域には有志のメンバーがコミットしており、熱い思いを抱いておりました。しかし一方で、ビジネス全体へのインパクトや、チームとしての明確な存在意義が十分に整理されていませんでした。そこでEMとして、次のような問いを投げかけながら議論を進め、これらをドキュメントにまとめました。
- 「課題ベースになりすぎていないか？」
- 「ビジネスインパクトはどの程度あるのか？」
- 「逆に、どの条件で撤退すべきか？」
- 「そのチームの未来どうなっていくか？」
問いかけの中で、メンバーの視点・意識を、今からより未来へと時間軸を変えることを特に意識していました。どうしても、今ある課題に意識が集中してしまうことと、チームが組織化されていくことでレバレッジを効かせられるのはより未来への課題と考えていたためです。
有志メンバーが非常に優れたスキルを発揮してくれたおかげで、私自身は上記のような問いかけに徹することにしました。何度か問いかけを繰り返した結果、チームのミッションと存在理由が明確化され、独立したチームとしての活動がスタートしました。
チーム独立後、私はメンバー間の信頼関係をさらに高めるために、チームビルディング活動を始めました。そこで実施したドラッカー風エクササイズの際、驚いたことに、メンバー全員が2年以上一緒に働いてきた人ということに気づきました。ログラス創業5年目の中で、2年以上一緒に働いたメンバーが揃うのは稀でした。
この高い関係値を強みとして活かすため、
- 「このメンバーたちの弱みが最も顕在化するのはどのような状況か？」
- 「その弱みを防ぐためには、どのようなサポートが必要か？」
これらの視点をもとに、チームを効果的に支援していきました。
学び
-
関係値が高いメンバー構成は大きな強み
- 当たり前なところですが高い関係値が、メンバー同士のスムーズなコミュニケーションに繋がりました。
- その関係性を活かし、チームの強みを一番発揮出来るように支援できた。
-
チームの存在理由明確化から関与できたことでマネジメントがスムーズに
- 立ち上がりの初期であったため、独立後は様々な期待をチーム外からもらいました。そこから、並列にタスクをアプローチしたりタスクの優先順位を迷う時も多々ありました。ただ、ドキュメント化されたものから「今チームとして最優先なのは何ですか？」と問える羅針盤もあったのが良かったと今振り返ると思います。
エピソード2
次のエピソードはEMとして失敗したと感じているエピソードになります。紹介するチームはエピソード1のチームよりも先に進んでおり、チームの存在理由が明確化されておりメンバーが増える状況で私が引き継ぐ状況でした。したがってチームをドライブさせてより中長期のことを見据えて自分がいなくても自律して動けるようなチームを目指してEMとしては働きかけていました。
進行
まずはチームメンバーの関係値を構築し、チームの文化や行動指針を定めチームのアウトプットを増やすことを模索しました。そのために、ドラッカー風エクササイズを行ったり、システムコーチングを受けたりしました。
また、中長期を見据えると自分がボトルネックになると考え、メンバーとの期待値合わせで「自分がいなくても成果が出せる状態」が実現できるように特定のメンバーに次のEMとしての期待値をかけて他のメンバーにもその支えをしてほしいと会話していきました。
その結果、チームとして計画していた成果は大きく出せませんでした。当初にあったチームのあるべき姿や責務が現状に即した形で更新できておらず、アウトプットの方向性が曖昧な状態だったことが要因の一つと思っています。今振り返るとタックマンモデルの機能期に到達できていない状態であり、チームに対してアプローチが必要だったと思います。加えて、次期EMに期待をかけたメンバーには困難な状況に直面させてしまいました。
学び
今振り返るとEMとして以下の点は特に失敗であり、反省点だと考えています。
-
関係値が少ない中でのすれ違い
メンバーとはより関係を築いた上で、こちらからの期待をもっと明確にしつつも、助けを簡単に求められる状態にしておけばよかったと考えています。 -
自分自身の業務量のマネジメント不足
Mgrとしての業務は多々あり、実は掛け持ちで他チームのマネジメント+採用業務もアクセル全開でおこなっていました。そのため、メンバーが困っているタイミングでフォローが出来なかったと考えています。最近行ったチームでの「象、死んだ魚、嘔吐」の振り返りの場でもメンバーからコメントもあるので、メンバーには本当に負担をかけてしまったと痛感しています。
こちらに関しては、チームのイベントは余程のことがない限り参加するようにしました。またチームの未来を描くこと、チームの今に対してのアプローチを準備する時間を確保するようにしています。 -
マネジメントを引き継ぐ上でポジティブなバイアスがあった
エピソード1のチームと比べて、既にチームの存在理由が明確化されていたこととチームとして長く活動していたことから私の中で無意識にポジティブな印象を抱いていました。それにより、チームの存在理由更新の必要性やチーム外からの期待値の把握は遅れての着手になってしまいました。そこから、前任のMgrに対してのチームメンバーのこと、そしてチームの課題などのヒアリングが不充分だったと今は反省しています。
まとめとエール
今回は赤裸々に事例をまとめてみました。失敗というのはどうしても起きるものですし、失敗した後はどうしても落ち込んでしまいます。ただ、落ち込んでいても状況は変わらないですし、やはり困っているメンバーがいるので改善に対して行動を起こしていくしかないと思っています。今回の記事を執筆するにあたって各チームメンバーにもレビューを依頼し、共通の認識を得ることで個人的には禊落としにも繋がり感謝しています。最後に、本記事が今課題や問題に直面している方への応援になれば幸いです。
株式会社ログラスは「良い景気を作ろう。」をミッションに、企業経営を推進する次世代型経営管理クラウド「Loglass 経営管理」を開発し提供しています。
Discussion