- 2022年1月から VP of Engineering (VPoE) になる @konifar のREADME (説明書) です
- このドキュメントは、自分と一緒に働く皆さんに次の2点を知ってもらうことを目的としています
- VPoE としてのミッション、ビジョン
- @konifar が大切にしたい価値観、働き方
- VPoE と聞いて、何をやる人なのか具体的にイメージがわく人は少ないと思います
- 実は自分も同じです。VPoE の最初にやるべきことは、何をミッションにして何をやっていくかを定義し、周囲に理解してもらうことだと考えています。その一環として、このドキュメントを書いています
- VPは、経営陣が描いた事業の成長を達成するための『実行』に責任を持ちます
- VPoE は、その中で『Techチームの関わるプロダクトデリバリー全体』に責任を持ちます
- たとえばプロダクトの開発プロセスを改善したり品質を向上させたり、あるいはメンバーが楽しく働けるような環境を整備したり、さまざまな期待があるとは思いますが、すべてユーザーに価値を届けるプロダクトデリバリーを目的として取り組んでいきます
- 要するに、『事業目標を達成しユーザーに価値を届けられるプロダクトを作るための仕組みを作る』ということです
- 『知り合いを誘いたくなるようなチャレンジングなTechチームを作る』を目標として取り組んでいきたいと考えています
- 自分の経験上、所属する組織に誇りを持てる状態ができると、プロダクトや事業にも必ずよい影響を与えます
- そのためにはプロダクトや事業をよくしなければならないという相互の依存関係ももちろんありますが、目標地点は「自信を持って自分の知り合いを誘えるくらいの状態を作る」というところに置いてやっていきます
- 今も知り合いを誘えるよと言ってくれるメンバーもいるかもしれませんが、 頂点志向 でより誘いやすい状態を作っていきたいです
- メンバーがKyashに所属していたことが、今後の人生で転職や独立などのタイミングでプラスに働くような組織になるとよいなと考えています
@konifar が仕事をする上でのスタンスです。あくまで自分はこうという話で、他のメンバーに同じスタンスを強要するものではないという点だけ注意してください。
- 上下関係ではなく、あくまでロール (役割) だと認識しています
- 自分よりも能力や経験のあるメンバーはKyashにはたくさんいます。逆に自分が他のメンバーより得意な領域もあります。それを VPoE という役割に最大限活かしたいと考えています
- 余談ですが、自分より秀でた分野を持つメンバーが多くいることは VPoE という役割を担う上でかなりプレッシャーを感じる要因になっていると同時に、自分がKyashという組織を好きな理由にもなっています
- CXOやEM、他チームのマネージャーと連携して横断で解決しなければならないような、大きな課題に取り組んでいく役割だと考えています
- なので、「課題を感じているけれどどう解決していったらいいかわからない」といったモヤモヤを感じたら、いつでも気軽に相談してくれると嬉しいです
- 課題を正しく把握することも、自分の役割のひとつだと考えています。もし「なんだか相談しにくいな」と感じたとしたら、それは VPoE としての役割を果たせていないことになるので教えてほしいです
- メンバー、プロダクト、事業の順に大切に考えます
- HARD THINGSの中でベン・ホロウィッツが述べた「人、製品、利益を大切にする──この順番で」という言葉に影響を受けています
- 事業目標の達成を意識したミッションと逆行する考えであることは理解していますが、メンバーが楽しくイキイキと働けていることが自分にとっては何より重要で、大切にしたいと考えています
- これは「自分のまわりにいる人には笑って幸せでいてほしい」という自分の思想が根っこにあります
- メンバー、プロダクト、事業の3つは相互に依存しており、プロダクトや事業がよくなることで組織がよくなることも当然あります。なのですべてを満たせるように考えますが、自分の一番の優先順位はメンバーです
- 自分が本来フォーカスするべき役割に集中するために、それ以外のことはなるべく他のメンバーを頼って委譲していきたいと考えています
- 情報の透明度を上げたり、チームやメンバーのミッション・役割を明確化したり、委譲のために必要な仕組みづくりは自分の役割として取り組みます
- たとえば、プロダクトデリバリーに責任を持ちますが、基本的にプロダクト開発はEMやチームメンバーに任せます
- 自分はKyashで一番技術力のある人ではありません。Go言語やマイクロサービスについては毎日コードを書いているサーバーサイドメンバーの方が詳しいでしょうし、AWSなどのインフラについてはSREメンバーの方が詳しいです。Mobileもデザインも同様です
- なので、プロダクトをどうやって作るかについては、皆さんの判断を尊重して頼りたいと考えています
- 一方で、プロフェッショナルのメンバー同士が One Team で高いパフォーマンスを生み出せる環境や体制を作ることは、自分の役割として取り組んでいきます
- 「採用で成果を出したい」「オンボーディングプロセスを改善したい」といったTechチームに関わる開発以外の課題についても、少しずつ委譲する体制を作り、皆でチームをよくしていけるようにしていきたいです
- もちろん、それを支える評価のインセンティブ設計なども考えていきます
- 逆に、自分にお願いしたいことがあれば気軽に頼ってほしいです。自分は信じて頼られる方が嬉しくて力を発揮できるタイプです
- VPoE として大小さまざまな意思決定をしていくことになると思いますが、決定に対する納得感を重視します
- 学習する組織の中の「人は変化に抵抗するのではない。変化させられることに抵抗するのだ」という言葉に影響を受けています
- 納得感で重要なのは決定前のプロセスに関わることだと考えているので、メンバーとの対話を重視しています
- 一方で、ある程度トップダウンで方針を決めて進まなければいけない場面もあると思っています。その際には、できるかぎり納得のいく説明をします
- 時には、完全に納得しきれなくとも決めて進むこともあると思います。決まった後には、 動いて風を知りながら 選んだ道を皆で正解にするというマインドに切り替えて力を貸していただけるとありがたいです
- 何か起きた時には、関係者とすぐに直接話して解決したいと考えています
- 「違う人間なのだから直接話さないとわからないことは多いし、同じ人間なのだから話せばわかることしかない」という思想に基づいています
- また、「大抵のことは時間を空けずにすぐ話した方が問題が小さいうちに解決できる」という自分自身の経験も影響しています
- たとえば何かの方針に納得がいかない場合は決定した人と直接話しますし、発言に棘を感じて嫌な気持ちになった時にも相手とすぐに話します
- 自分に対しても、何かあればすぐに直接フィードバックをしてもらえるととても嬉しいです
- 自分の性格上フィードバックを感情で拒絶するようなことは絶対にありませんし、Kyashのメンバーはコミュニケーションが上手い人が多いので率直に思ったことを伝えてもらっても問題ありません
- もちろんポジティブなフィードバックがあればそれも伝えてもらえるとありがたいです
- Techチームにまつわる課題を洗い出してカテゴライズし、根っこを見極めた上で皆さんに協力してもらいながら解決していくというプロセスをひたすらやり続けることになると思います
- 課題の洗い出しは最初の起点になるので、少しでも課題だと感じたらZoomでもSlackでも気軽に声かけてもらえると非常に助かります
- 1on1もちょいちょいお願いすると思うので、ぜひ色々と教えてください。プライベートの話なんかも話せるといいなと思っています
- このドキュメントを読んでいただいてありがとうございました！
- VPoE という役割自体が自分にとってはチャレンジで、おそらく今後うまくいかないことも多いと思います
- 日々アップデートしていかなければいけないので、そのためのフィードバックをいただけるととてもありがたいです
- 「こうしてほしい」「これは嫌だ」「しっかりしろ」みたいな率直な意見を歓迎します。言ってもらわないと気づけないことも多いですしね
- 自分はKyashのプロダクトもチームメンバーもわりと好きなので、より楽しくよいものを作っていける環境を整えたいと考えています
- 皆さんの助けをかなりもらうことになると思うので、何卒よろしくお願いします！