日々精進
異世界転生してもすぐに昇進するのがスタートアップ
スタートアップは常に人手不足でコードも書けるEMみたいなポジショニングをしていると任せられる範囲が次第に増えていくことがあります。何度案件が変わっても、最初は単なるエンジニアとして参画しても割合すぐに任せられる範囲が増えるので天職なのでしょう。
時にはフロントエンド、バックエンド、モバイルアプリ、インフラ、機械学習の各チームに対して技術顧問しながらマネジメントして欲しい(意訳)みたいな超人級の要求をされることをあります。
残念ながら技術部分については全てのジャンルについて一流の域にはまだ到達できてはいないんですが、マネジメント部分については再現性や汎用性が高いところもあり自分なりにこうするといいのでは？というアイディアをまとめておきます。
マネジメントの半分(以上)は可視化
どの専門性においてもポジションが上がるほど不確実性が高いぼやっとした要求が増えていく傾向にあります。タスクを分解してとある専門性の職種に投げられる状態になっていれば仕事の半分は終わった状態です。
そういう意味でマネジメントの半分(以上)は可視化であり、任意のマネジメントにおいて偉ぶるだけで確実性を上げてくれないマネージャーがいたらその人がいるバリューは少ないでしょう。
管理職を分解した事例が増えている
ポジションが上に上がるにつれまず最初にした方がいいのは期待値調整でしょう。100日プランについては以前記事を書きました。
例えば部長のロールを一人の人間が担うのは限界があると定義した企業があります。
- 部長
- CDM(キャリアデベロップメントマネージャー)
- PCM(プロジェクトコーディネーションマネージャー)
のロールがあります。
リクルートでは2023年から順次管理職をヒトマネとコトマネに分業しているそうです。
日本において平均勤続年数は12年であり、(それはある種日本的弱さだとも思っていますが)転職においては管理職はなくメンバーレベルでしか認めていないという企業もあり、管理職ほど企業間のばらつきが大きい認識です。
とりわけ職位が上がるほど周囲の期待値を合算すると超人になってしまう傾向にあります。
ジョブディスクリプションポーカーでロールを可視化する
そいうった場面で有効なのがデリゲーション・ポーカー、ジョブディスクリプション・ポーカーです。
メンバー <=> 課長間、課長 <=> 部長間のような階級間のデリゲーションやエンジニア、デザイナー、PMのロール間のボールの可視化をするとチーム間のばらつきが減り配属ガチャを減らせます。
企業によってはさらにエンジニアのキャリアラダーを専門性やリードエンジニア/テックリードに分解してもいいかもしれないですね。それぞれ論点を各記事にまとめています。
ミッションビジョンバリューのアセスメントへの落とし込み
ロールの分解が終わったら次に必要なのはアセスメントへの落とし込みです。
一般にミッションビジョンバリューがあり浸透している企業の方が従業員のコミット感が高く離職率も低く仕事のアウトプットもいい傾向にあります。一方でミッションビジョンバリューがあるものの評価制度への落とし込みが上手くいっていない企業はたまにみます。
経済的な報酬はもちろん良いほうがいいのですが、自分自身の仕事が評価されている感も重要でそこが上手くいっていない企業もしばしば見ます。
割合技術面を自分は任されることが多いので、人事よりの関与は少なめですが、時折考えを求められることがあるので他社の事例を交えつつ、評価制度の設計や自分がどういう人を評価しているかをお伝えすることはあります。
マネジメント、合意形成の仕組み化
こういうロールや評価の明文化をしていっても、オペレーションとの乖離はあります。病んでしまう人や喧嘩が起きることを減らすためには定期的にマネージャーによる1on1によるガス抜きが必要な認識です。
メンバー自体の専門性の研修と比べてマネージャー自体の研修はそこまで確立していない傾向にあります。残念ながら日々の業務に忙殺されてできてはいないんですが、ここは一般的な資格をベースに勉強会をするといいのでは？というアイディアはあります。
教育のやり方なんかもある程度ガイドラインがあってもいいかもしれないですね。
定期的に全体の会議を開催したりご意見募集を募れる仕組みの構築も重要です。Manager of ManagerとManagerの差分として求められることがチーム間の配属ガチャの最小化で休みの取りやすさ、ドキュメントの書き方、仕事の進め方、実装方針だったりの(少なくともマイナスの)差分を極力減らすことにあると思っています。
ご意見募集はなんでもいいですが、GitHub Discussionsのような機能があると要件を満たせそうです。
技術的負債の状況の可視化
プロダクトの新規開発と技術的負債の解消どちらを優先するかは1チームでもしばしばエンジニア比率の低いエンジニアの立場の弱い組織ではプロダクトの新規開発に技術的負債の解消が負けることはあります。
一方でGoogleの論文によればコード品質は開発生産性に最も影響するファクターであり、技術的負債のある状態はある部分の開発速度を下げます。該当部分の将来的な開発予定 x 技術的負債の面積が多ければ本来は先に技術的負債を解消した方が投資効率で勝つ部分もあるわけで、技術的負債の解消の優先順位を上げてもらえない場合、その部分の可視化がうまくできていないことも多いです。
これが複数チームになるとよりマトリックスが複雑になり全体のチームの中でどこに投資するといいかを可視化する難易度が上がります。ラベルのルールや議題上げの仕組みづくりをしていくと全体の技術的負債がどこにあり何に投資すると効率がいいかを可視化することができます。
マネージャーの割合とルールの割合の最適化
ここまで可視化や仕組み化についてまとめてきましたが、一方でルールを徹底するのもマネジメントコストがかかることは認識する必要があります。
人間が覚え切れるルールは一つにつきせいぜい3つくらいに思ったほうが良くてどんなにドキュメント化しても集団を同じ方向に向かせるためには労力がかかります。とりわけマネージャー自体の採用に上手くいっていない場合、細かすぎるルールを作っても運用に乗りません。ルールを徹底する人とルールの量のバランスは常に気にしてルールは極力最小化する必要があります。
プログラマーの能力はばらつきがあり人が違えば最大10倍差があると言われます。言ってしまえば低パフォーマーを3人雇うより1人の高パフォーマーを高待遇で雇った方が効率がいい可能性はあります。
スタートアップの組織設計の論文によれば全て一流が全てのフェーズで高パフォーマンスであるわけではないんですが、ルール化は全員を高パフォーマーを揃えられない場合の苦肉の策である面も認識する必要はあります。
感情労働で疲弊しないための切り替え作り
結構気を使って上手くまわるための仕組みを作っていっているつもりですが、それでも不満のあるメンバーは出てくる時はあります。時には感情労働を要求され疲れてしまう時もあります。
正攻法で言えば新規のメンバーをサイバーエージェント流に素直でいいやつで揃えていくのは大事ですが、既存メンバーはそうそう入れ替わりません。
人により寝る、誰かと話す、趣味に没頭するなどガス抜きのやり方は色々ですが、職位があがると自分に1on1してくれる人がいないみたいな時も起こりがちで、メンタルを病まないための対策は自己防衛としてより持っておいて損はないです。
