これは勤務先の Advent Calendar なのだけど、何を書こうか考えてみたところ、今年は私的なふりかえりにしようと思ったので個人ブログに書いている。
何故そうしたかと言うと、一年を振り返ってみて、今年は —— 正確に言うとこの二年ぐらいなのだが —— 自分の中で大きな思考転換があったから。年始から Japan Marketing Week・日本 CTO 協会のイベント・開発生産性カンファレンス などいくつかのイベントに登壇し、一貫して「プロダクト開発組織のあり方」や「CTO の役割」について話してきたが、どれも自分自身の失敗談と、そこからの思考転換や取り組みについて話してきた。このポエムでは、そんな失敗談の裏側 —— 個人的な気持ちの変化について、筆の進むままに徒然なく書いてみようと思う。
エンジニアの仕事は、コードを書くだけではない
新卒で入ったのは金融のトレーディングシステムをつくる会社だったが、「エンジニアとして一流なだけでは、ビジネスパーソンとしては三流である」という考えが浸透していた。いわく、お客様の要望をはるかに超えるプロダクトをつくるには、エンジニアはお客様と同等以上に金融業務に詳しくあるべきである。実際に自分の上司は疑う余地なくスーパーハッカーだったが、誰よりも金融業務に詳しかった。そんな人が沢山働いている会社で育ったので、僕自身もコードを書くのは大好きだったが、それだけやっているのは違うなと思って色んな仕事に手を出していた。
そんなわけで転職してからも、コードを書くだけでなく「何をやるか」を考える、決めることには多大な関心を持っていた。入社当時の NewsPicks はまだ小さく、エンジニアが何をやるかを考えていたし、お問い合わせ対応もしていたし、場合によってはマーケを担当したり営業にも行っていた。慣れない Sketch でデザインをしていた時期もある。つまりエンジニアがなんでもやる組織で、これは僕自身の志向にマッチしていた。当時の僕は BizDev も PdM も要らないと思っていたし、なんなら入社初期に BizDev 組織の廃止を提案したことさえある。そうじゃなくて、エンジニアが全部やればいいと思っていた。プログラマとして一流の技術力を持ち、データを分析し、何をつくるかを考え、お客様のお問い合わせに応え、営業に行く。これがあるべきエンジニア像だと、純粋に考えていた。
ところが組織が大きくなってくると、この状態を維持するのは少しずつ難しくなる。弊社の場合も事業やプロジェクトが増えた結果、一部エンジニアの負担が大きくなり過ぎ、業務が分解されていった。PdM が採用され、デザイン組織が強化され、今では専任のデータアナリストやリサーチャーすらいる。今となってはこの組織にして良かったと思っているけど、実は内心では全部反対だった。なんだか仕事がせせこましくなる感じがしてワクワクしないし、エンジニアがただの作業者になってしまう —— つまり三流のビジネスパーソンになるのではと懸念したからだ。
割り切れない想いがあったのは実際の態度に出ていたようだ。いま PdM のリーダーをしてくれているメンバーがいるのだが、面接時の僕の態度はなかなか酷かったらしい。本当にごめんよ、たぶん採用したくなかったんだ。
さて、じゃあどうなったかと言うと、結果としては杞憂だった。当たり前だが、どの仕事にも専門性がある。自分には想像もできないようなクリエイティビティを発揮する専門家たちのアウトプットを見て、少しずつ「専門家同士が、背中を預け合うのも良いんじゃないか」と思うようになっていった。背中を預けながら、お互いが思うことを率直に話し合い、タッグを組んで価値あるプロダクトをつくれば良いじゃないか ——。
頭ではそう思ったりもするのだが、それでもエンジニアの仕事が小さくなっている感覚は拭いきれず、本当に腹落ちするまでは何年もかかったと思う。今では多様性の力を信じられていると思うし、エンジニアの創造性が発揮できる組織になっていると思っているけど、かなり長いあいだ葛藤を抱えていたのは事実だ。組織を引き継いだ身としても、ずっと「これで良いのか」と自問していた。
今ふりかえるとなかなか恥ずかしい。行動原理が自分のエゴでしかなく、独善的で、敬意に欠ける。たぶんユーザーや会社の目標よりも「自分が楽しく働く」ことに関心が向いていたのだと思う。
プロダクト開発を、専門職にしない
そんな人間が執行役員になって、プロダクト組織を管掌するとどうなるか。エンジニア・PdM・デザイナーなど様々な職能のメンバーがいたが、役員になった時点ではマネジメントに対する関心が欠片もなかった（本当に！）ので、最初は自分でも驚くほど失敗を踏み抜いた。社会人になってから、こんなに失敗した経験はないぐらい。
スタートダッシュで見事に躓いたし、当時は社内でも大炎上中のプロジェクトがあったので、自分自身はずっとその執行に専念していた。ちゃんとマネジメントをやり始めたのは、役員になって一年ぐらい経った頃。当時のプロダクト組織には様々な問題が噴出していた。開発者体験が悪くてエンジニアが定着しないし、組織全体に不協和音があり、中にはいくつか崩壊しているチームもあった。そんな中でリーダーシップチームをつくり、少しずつ改善を進めていった。今ではすっかり違う組織になったと思う。
余談だが、自分がようやくマネージャーの端くれになれたと感じたのは、いくばくかの成果が出てきたのと、メンバーの成功を一切の留保なく喜べたとき だった気がする。なんだか自分の新しい一面を見れた気がした。結局のところ、仕事とは、人生とは、「何を愛するか」を能動的に選択する行為の連続である。目の前のコードであれ、プロダクトや事業であれ、組織であれ、対象を愛せれば楽しいし、愛せなければつまらないのだ。愛の対象を広げよ。
閑話休題。
ただ、そうやって組織の状況が好転し、エンジニアの開発生産性が高まっても、事業全体の状況はあまり好転しなかったし、チームにもどこか名状し難い閉塞感があった。当時の僕はその理由を「色々な事業やプロジェクトが乱立していて、フォーカスを定められないからだ」と考え、事業部ごとに分かれていた開発プロセスを、プロダクト組織が中央集権的に管理するかたちに戻そうとした。「開発が事業部最適になり過ぎているから、会社全体を見ている CEO とプロダクト組織がトップダウンで優先度をつけていこう」というのが主な考えだったが、これは数ヶ月やってみてすぐに取り下げた。それぞれの事業責任者にだって立場があり責任がある。そこにトップダウンの意思をぶつけても、多少フォーカスは定まるものの、調整コストが爆増してしまったのだ。
じゃあどうすれば良いのだろうと悩んでいたのだが、結論として昨年夏に全社組織を大きく変えた。大量にあった事業部やプロジェクトを統廃合して二つの事業部に再編し、そのうちの一つを自分が管掌することにした。つまり「事業部」と「プロダクト組織」という構造ではなく、自分自身が事業部を持ち、意思決定する構造になった。
組織を変えてからは、三ヶ月もしないうちに自分の了見の狭さに気付かされた。当たり前だが、組織を外から見るのと中から見るのは違う。責任者になれば数字に対する強度も変わるし、強制的に視野が広がり、何より関わる人が増え、新たな価値観に出会うことになる。そんな中で、試行錯誤しながらみんなが向かう北極星となるようなミッションもできた。実は以前、プロダクト組織内でもプロダクトビジョンの策定を試みたのだが、そのとき感じていた「議論が組織内に閉じこもっている」感が解消され、様々なメンバーと議論することができた。実際の開発においても、それまでならプロダクト組織内で閉じていた議論が、事業部やコンテンツクリエイターと一緒になされるようになり、新たなユーザー価値が生み出されていった。本当に、みんなすごいのだ。
この過程で印象深かったのが UX リサーチ専門の組織をつくったこと。組織再編によってさまざまな職能のメンバーが集まるようになり、リサーチを通じてユーザーを主語にした会話が増えた。「いやいや僕らはいつもユーザーを主語にしていたじゃないか」と思うかもしれないけど、リサーチが定常化している組織とそうでない組織には、大きな文化的資本の差があると思う。こんな取り組みを力強く進めてくれたメンバーには頭が上がらない。
僕自身は、ここに至ってはじめて出不精で人見知りな自分の弱みを改めて認識したのだった。つまり「エンジニアが全部やればいい」「プロダクト組織が中央集権的にやればいい」は全て、自己防衛的な反応だったのではないか と気付いたのだった。あるいは、前職での経験から「自分はビジネスが（多少なりとも）分かるエンジニアだ」と無意識の驕りがあったのかもしれない。考えているつもりで、もしくは行動しているつもりで、だけど実際は一歩踏み込みのを避けていた。
経営陣の一人としては大失格である。今では CTO の大事な役割の一つは「エンジニアと、それを取り巻くメンバーとの融和を図り、共通のゴールに向かう組織をつくること」だと思っている。
プロダクト開発を専門職にしてはいけない。
大きな問題から、目を背けない
そんな経験を経て、課題に対するアプローチも変わった。ある事業や組織が上手くいっていなければチームメンバーを送り込む場合もあるし、自分自身が責任者になることもある。もはやエンジニアの仕事からはずいぶん離れてきているけれど、そもそも CTO はエンジニアではなくて経営陣の一人である。たまたま経営陣の中で、ちょっと技術に詳しいぐらいの人でしかない。ある先輩が「エンジニアと CTO は全く違う仕事だよ」と言っていた理由が、今なら少し分かる。自分がその役割に相応しいかは一旦脇に置いておいて、全社の問題を把握し、マネジメントの一員としてリスクをとった意思決定と行動を取る責任があるんだと思う。
この経験から僕が思い出すのは、一休 CTO naoya さんの過去の発表 だ。
そう、自分たちが解決できる規模や難易度を超えると、誰もその解決に向かって動かなくなってしまう。
実際は、色々なところで声は上がっているのだ。だけど、じゃあどうやって解決するかというと、これは誰かがリスクを取り、覚悟を決めて責任を背負いに行くしかない。
責任を持ちに行くのは痛みを伴う。しかるべき順番もあるだろう。僕自身、足元の仕事に責任を持ちながら、範囲外の領域に踏み出すのを躊躇していた面があるけれど、今となっては一歩踏み出す大事さを痛感しているし、少しは踏み出せるようになった。まだ悪い癖がでるところはあるけど、そういうときは周りのメンバーが助けてくれるし、こうやって言葉にすることで、自分の中で行動指針にできる気がする。
つまり僕が言いたいのはこうだ。
あなたは無意識のうちにシマを作っていないだろうか。あるいは、自分がやれることだけに閉じて考えてしまっていないだろうか。
こんな自問に少しだけ自信をもって答えられるようになったのが、最近の僕のささやかな成長である。
宣伝コーナー
この記事は NewsPicks Advent Calendar 2023 の 20 日目になります。昨日はデザイナー川崎さんによる『デザイナーがStorybookの開発環境を手に入れて、エンジニアとの連携を強めるために奮闘する話』でした。
そしてなんと、NewsPicks プロダクトチームが『Software Design』で連載を開始します！
これまでの僕らの軌跡をお届けしていくので、プロダクト組織の改善にお悩みの皆さまに読んでいただけると嬉しいです。かしこ。