自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話｜JoanOfArc を読みました。
著者はハードスキル不足と表現しています、ソフトスキル不足に見えました。
ここでは、この記事をモデルとした架空の組織ボウケンカンパニーを例にしてソフトスキル「自発的な提案」を説明してみます。
架空の組織の設定
メガベンチャーということなので、著者の上のレポートラインは3人いることにします。それぞれ組織の急拡大にあわせて役割になったばかりで、役割に不慣れな設定とします。
- 著者
- リーダー
- 実装能力を買われてリーダーになった
- リーダーとして部下の面倒見がよいかは確認されていない
- 部下を持つのははじめて
- マネージャー
- 組織拡大する上でマネージャーが必要で、その時点でリーダーだったのでマネージャーになった
- マネージャーの適性は確認されていない
- マネージャー教育の座学を受けた。マネージャー業務をやりはじめたばかり
- 役員
- メガベンチャーがメガになる前からいる古参
- 著者の最終面談の相手
自分に期待する働きを確認する
この組織では、言葉では「自発的な提案」を求められていますが、必要なのは「自発的なヒアリング」です。具体的にはレポートライン上のマネージャーの役割ができる人物を探索し
- 自分に期待する働きは？
- 自分の今の動きは期待している働きになっているか？
を繰り返し確認します。
なぜかといいますと「直した方がいいもの」「やった方がいいこと」はハードスキルで見つけられますが、「直す価値」は見つけられないからです。やろうとしている作業がビジネスに寄与するかは新参者にはわかりません。例えば「メンテナンスしづらいコードでなんで動いているかわからないプロダクト」があったとして、半年以内のサービス終了を検討しているかもしれません。もしそうならリファクタリングの優先度は低いでしょう。
成熟した組織であれば、このような「組織の重視する価値」はマネージャーが整理し、OKRのようなツールをつかって発信していきます。「組織の重視する価値」に関する情報に十分にアクセスできる環境があると「自発的な提案」が可能です。ですが、ボウケンカンパニーは急拡大したためOKRはツールとして導入していますが、「組織の重視する価値」を発信するツールとしては使いこなせていません。
マネージャーさんは頻出する次のような組織の問題の対応に追われています。
- 採用者の受け入れ
- 担当する複数プロジェクトのケア
- 退職者の処理
- 組織のルール整理
OKRに不慣れにも関わらず、習熟する時間が取れません。組織の目標を聞いても、自分の部門用に整理し直す時間が取れず、上手く部下に伝えることができていません。
このようやマネージャーさんの下で情報を待っているのは下策です。また、情報が不足した状態で「自発的な提案」をするのはさらに下策です。マネージャーさんの目には「やりたいことはわかるんだけど、組織の価値と合っていない」と写ります。前述のようにこれはマネージャーさん自身の能力不足が生んでいる状況です。このような提案がされればされるほど自身が攻められているように感じます。攻撃が続くとマネージャーさんの中で、自身を守るために「提案者は勤勉な無能である」という認知の歪みが発生します。
レポートラインの探索
「自発的な提案」をするまえに、まず自分からマネージャーさんに情報を取りに行く必要があります。「何をしたらいいですか？」と聞くと求められている「自発的な提案」と矛盾してしまいます。質問の形式を変えます。「自分に期待する働きは？」を聞きます。転職して半年以内の人間が「自分に期待する働き」を問うのは自然です。組織に馴染もうと努力しているように見えます。
しかし、このマネージャーさんはまだ不慣れなため「自分に期待する働きは？」に対して、うまく答えられません。たとえば「筆者さんのスキルでバっとアウトプット出して、売上をドカンとあげてくれればいいっすよ！」と返ってくるとします。そのときはマネージャーさんのマネージャーに聞いてみましょう。今回は採用面談で会った、役員さんに聞いてみましょう。採用面談して合格を出しているので「自分に期待する働きは？」に答えられないはずがありません。
直接話しかけられればベターですが、slackのダイレクトメッセージでもいいと思います。 入社直後はボーナス期間です。社内のことは知らないことが普通なので質問し放題です。 採用面談を通した役員としては「合格を出した採用者が組織に定着するか」は自分の評価に関わる問題です。何かしら役に立つ情報がもらえるはずです。
突然えらい人に話しかけるのは怖いです。杞憂です。開発経歴が二年目の著者さんは、おそらく「経験年数のわりに技術があって、ビジネス面にも興味がある、生きの良さそうなやつ」という評価を受けると思います。
自発的な提案
たとえば「我が社は、新規案件では、立ち上げが早いリーダーさん頼りなところがあります。これをなんとか分散したい。理想的にはリーダーさんのような働きをしてほしいですが、そうではなくて、リーダーさんが一度作ったプロダクトのメンテナンスを引き継いでリーダーさんの手をあけてくれれば十分最高です。３ヶ月くらいだとうれしいです。1、2ヶ月後からリーダーさんが半分抜けて、３ヶ月後には完全に抜けても大丈夫くらいを目指してほしいです。」という期待を得たとします。
これにマッチした提案を３つ考えます。
たとえば
- ソースコードを読んでプロダクトの構成を理解するためにシーケンス図をつくる
- リーダーさんにプロダクトについてレクチャーを受ける
- 簡単な機能追加を実装する
このうち最も労力が少ない作業をマネージャーさんに提案します。
今回は一番目を選択します。リーダーさんとのスケジュール調整が不要で、独力でアウトプットが作成可能だからです。 マネージャーさんに提案します。 このとき、役員さんから聞いた期待に沿っていると考えていることも伝えます。 するとマネージャーさんは、上司の意向にそっていることも確認できますし、著者さんが役員さんとコミュニケーションが取れている点にも安心します。承認しやすくなるでしょう。
承認をうけたらアウトプットを作成します。 入社日かその翌日、遅くともその週のうちにアウトプットを出します。 なんと「自発的な提案」をしかつ成果を出せました！やったね。
期待に添えているか確認する
作成物はマネージャーさんまたはリーダーさんにレビューを受けます。 ここで「自発的な提案」が期待に沿っているか確認できます。 事前に承認を取っているので、大きくはズレていないはずです。 一方、細部は間違っているはずです。 その中で既存プロダクトの理解するために知っておいた方がよさそうな情報が見つかると思います。 その情報を元に次の提案を考えます。
まとめ
「自発的な提案」なので、めちゃくちゃチープで簡単で絶対に達成できる提案になるようにコントロールします。マネージャーさんは、口では「自発的な提案」を求めても、はじめて一緒に仕事をする人の提案を承認するのは怖いです。小さな提案であればそれほど怖くないです。一度、小さな提案-承認-実行のサイクルをまわしてしまえば、次からは恐怖感がなくなります。「フット・イン・ザ・ドア・テクニック」です。めちゃくちゃソフトスキルです。
感想
ここまでしないといけない組織に若いテック志向のエンジニアが参加する意味ってあるのでしょうか？ あ、架空組織ボウケンカンパニーの話です。
元記事の方もお互いの期待がミスマッチだったのかなあ？なんて想像します。
