前置きしておくと、エンジニアリングとか仕事関係の話です。

何気ないやりとりから

つい先日、長年の親友とこんなやり取りをしました。

彼はエンジニア上がりで、現在事業会社でプロダクトマネージャーぽい業務に携わっています。最近人が増えて組織をどうまとめていこうか、トップとしての業務はどういったことをしていくのが最適なのだろうかと悩んでいたらしく、上記の様なやりとりで「CTOの業務内容ってどう思う？」という質問を受けました。
※ vopeと言ってるがこれはVPoEのこと。

質問を受けたのは良いのですが、自分はまだペーペーのエンジニアなので、CTO業務とやらをやった経験もなく、「CTOとは」と大それたことを語る資格を持ち合わせていません。しかし、困っている親友に自分が知る範囲で、何かしらの良いアドバイスができたらいいなと思い、アドバイスしてみました。

そうした後に、意外と似た内容で困ってたりする人が多いのでは？と思い。今回の親友とのやりとりを交えながら、似た内容で困っている方の参考になりそうなナレッジをここでも紹介することにしました。

模範回答としてのCTO・VPoE・VPoP

先の質問である「CTOの業務内容ってどう思う？」への自分なりの簡潔な回答としては、

「技術で経営をドライブ(推進)させるための業務責任を持つのがCTO」

だと、思っています。

はい。CTO完全に理解した

これは、Gunosy社でCTOを務め、現在はDMM.com社でCTOとして腕を振るっている松本さん(@y_matsuwitter)が説いていた定義で、自分はこの話がとても印象に残っています。
上記の定義に対する詳細な内容は、Gunosy Tech Blogの記事で簡潔かつ丁寧にまとめてあるので、こちらを参考に。

記事中では、開発組織の中での主要なロールをCTO・VPoE・VPoPに分けてそれぞれに責務を分割し、かつそれぞれが取り組むことについて紹介されています。

また、松本さんがこれまでCTOを務めてきた中で得られた知見が凝縮されています。

今現在自分が担当するCTOという役割の中で重視しているのは下記の2点です。
①経営面での技術的意思決定
②組織の技術的に可能なラインを拡げる

記事の内容はさらっと簡潔に書いてありますが、この形態で業務が上手く回る様になるには、それ相応の時間とナレッジが必要で、とても難易度が高いです。なので、これが絶対的なものではなく、あくまで模範回答みたいな感じだと思っています。

なるほどすぎて首もげる親友

ちなみに、Gunosyではこの3者3役の構造が本当に良い感じに回っていて。それを中から目の当たりにしていたので、すごいなぁという風に思っていました。(小並感)

プロダクトマネージャーと良いイシュー

最近ではプロダクトマネージャーという役職や仕事もメジャーになりつつありますね。ネットでも「プロダクトマネージャー論」みたいな形で有益なナレッジが共有され始めてきて、よく目にしています。
そんなナレッジの中でも、個人的に特に有益だなぁと思った記事があります。

それが、SmartNews社でPOを務める前田さんのインタビュー記事。

記事中では、以下の様なプロダクトマネージャーとして大事にしている考え方が話されています。

最も大きな責任は、「問題を定義できるかどうか」にあると思っていて。逆に「問題を解くこと」がPMの仕事だとは、僕はあまり思っていないんです。

正しく問題を定義して、チームのみんなが「それを解くことが素晴らしいことだ」と信じられる状態さえ作れれば、良いスパイラルが回っていくんですね。

我々は、「インパクトはそこそこだけど、解くのは比較的簡単な10個の問題」を解くのではなく、「すごく難しいが解いたら大きな意味がある1個の問題」を解いて、ビジネスを大きくしています。

このような志向を持っていると、優秀なエンジニアが平凡なエンジニアの10倍、100倍の成果を出せる環境が実現できます。

これを最初に読んだ時、思わず「うわぁ...」という声が漏れてしまいました。

短いインタビューながら、プロダクトマネージャーとしてのあるべき考え方が語られていてとても学びがあります。有益！！！

『良いイシューを見つけること』

もう、ぐうの音も出ません。

開発組織の"文化と責務"

なんかエンジニアの本職って、やはりコードが基軸にあるから、コーディングを任せてる自分がサボってるんじゃないかって自責してしまうことがたまにある

それこそイシューを見つけることよりも解決に向かう方が正しいのではないかと葛藤するというか

わかる。めちゃわかる。と即答で相槌を打ってしまいましたが。自分も過去に全く似た境遇を経験しており、"自分はエンジニアだ" という気持ちを抱きながらも業務ではコードを書かない課題解決に取り組んでいた時に、同様の感情を抱いたことがあります。恐らく、開発をメインに携わっていた方が、コードを書くこと以外で業務を進めることが多くなった時に、似た感情を抱いたことがあるのではないかなと思います。

この、開発業務に対する葛藤への解決策は、組織の"文化と責務"にあると思っています。

文化として「課題解決をゴールとしており、その手段としてエンジニアリングを用いる」という風にしたとします。そうすると組織的に「コーディング以外の業務でも、解決される課題がクリティカルであれば、それはとても重要で、評価に値することだよ」という認識になります。
こうすることで、解決手段に対する許容範囲が広がり、エンジニアリング以外での課題解決に柔軟に取り組みやすくなります。

さらに、責務として先ほども紹介した"プロダクトマネージャー"などといった明確な役職とその責任範囲を設けることで、課題解決において最重要な業務である「イシューの定義」という仕事への価値が高くなります。仕事の責務とその価値が明確になれば、それに対する評価も変わるため、葛藤も減っていくと思います。

天才だと思い、震えながらフニオチまくる親友

ちなみに、自分は個人のキャリアや経験、そして組織内へのナレッジの観点から、手段の目的化も多少は良いと思っている派です。

こういった開発組織の文化形成という文脈においても、Gunosyの開発組織はよくできていて、とても参考になります。Gunosyではエンジニアリングによる課題解決が第一だというのを組織文化として作ってきていました。

2015年と少し古めの記事ですが、この時期に「技術を課題解決のために用いましょう」という風になったと語られています。

「変わったものといえば、開発組織の定義と採用ですね。以前は"テックカンパニー”として、『新しい技術をガンガン使って面白いことができるエンジニア集団』みたいな定義をしていたんです。でも社内でいろんなディスカッションや1on1をやってみると、それが一番問題で変えるべきことでした。結論、僕らは『事業課題解決チーム』であるべきだと。手段として技術を持って数字を見て、改善を回していくチームではあったんですけど、技術自体は目的ではなかった。

これをしておくことで、「それって課題解決になってるの？」って問えることが強い

本当にその通りで、この問いがあることで迷いなくコトに向かえるようになります。

自分の業務に迷いが生じ、コトに向かえなくなってきたら「それ、課題解決に繋がってる？」と自問自答してみると良いかもしれません。

最後に

親友とのやり取りを紹介しながら、いくつかの学びを紹介してきました。
こう書き終えてみると 、なんかGunosyめちゃいいぞ的な記事になってしまいましたが、まだそこしか知らない自分の知識をベースにしているのでかなり偏った見方かもしれません。なので、あくまで参考程度にとどめていただければなと。

何気ない会話のやり取りの中から、いつも何かしらの気づきや学びを与えてくれる親友に感謝しています。

この記事に対する反応

noteの記事は自サイトに移行しています。

https://www.yamarkz.com/blog/conversation-with-best-friend