1. プログラミングだけで勝負しない

—— DMMに新卒入社するまで、本格的なプログラミング経験がなかったそうですね。なのになぜ、エンジニアになろうと？

大学で学んでいたのは情報社会学で、いわゆる文系学部だったので、おっしゃる通りプログラミングを学ぶ機会はありませんでした。

でも、就活の時期を迎えて将来を考えた時に、「サービスとか事業を作る仕事が楽しそうだな」と思ったんですね。

加えて、何かしらの事業を作るなら、自分で手を動かしながら作らないと意味がないなと。事業づくりの土台を支える部分から携わりたかったんです。

それで、未経験ながらエンジニアを目指すことにしました。

—— どうやってDMMから内定を得たのですか？

エンジニアは、就職や転職の時にポートフォリオ（過去に手掛けたプロダクト集）をアピール材料にすると聞きまして。

そこで就活前にPHP（プログラミング言語の中でも初心者向きと言われる言語）の勉強本を読み、1カ月くらいかけて「ECサイトもどき」を作ってみたんです。

まずはGitHubでアカウントを作り、​​商品を選んで購入するまでの流れをざっと自作して。就活の面接では、これを見せながら開発コンセプトなどを伝えました。

技術力よりも、課題解決力みたいな部分をアピールした形です。

—— とはいえ未経験ということで、入社後は苦労したのでは？

確かに最初の数カ月は残業続きでしたね。

今も所属しているプラットフォーム事業本部は、DMMが展開するサービス全般の会員基盤を担う部門です。トラフィックの規模面でも、認証技術のようなテクノロジー面でも難易度が高かったので、与えられた開発のタスクをこなすだけでも精いっぱいでした。

でも、本気で勉強すれば何とかなると思っていましたし、実際、1つ1つのタスクをこなすのにかかる時間はどんどん短くなっていきました。

最初は8時間くらいかかっていたタスクが、6時間で終わるようになる。それで、余った2時間で「チーム全体の成果はどうなっているのか？」や「他のエンジニアが困っていることは何か？」を探って、解決するようにしたんです。

こうやってチーム全体の課題を拾いに行く動きが認められたのか、入社2年目から会員基盤のバックエンド領域のプロジェクトマネジメントも任されるようになりました。

—— 一般的に、若いエンジニアはマネジメント職への昇進やジョブチェンジを嫌がると聞きます。石垣さんは、気持ちの面で抵抗はなかったのですか？

事業づくりがやりたくて就職したので、なかったですね。

プログラミングは楽しいし、仕事に不可欠なスキルでもありますが、僕はキャリアを始めた頃から「プログラミングスキルで勝負する」という考えを捨てていたというか。

事業部長になった今も、必要なら自分でコードを書きますが、プログラミングは事業づくりの手段だという考えに変わりありません。

僕が1人で何人分もの役割をこなせる凄腕エンジニアだったら、話は違ったかもしれません。でも、DMMの中だけ見ても、僕よりコードを書けるエンジニアはたくさんいます。

であれば、チームが気持ちよく開発できる体制を作るのをリードするほうがいいと思っていました。これなら、エンジニア歴や社歴が短くてもできますし。

DMMに入社した時から「裁量と権限が欲しい」と言い続けていたので、むしろ自分に合っているとすら思っていました。

2. いつも「2つ上の役割」を

—— プロジェクトマネージャー（以下、PM）の仕事では、自分よりも経験豊富なエンジニアを束ねる力が問われます。入社2年目でもやれるものでしたか？

すぐに「良いPM」になれたかどうかは分かりませんし、周りから見ればつたない部分もあったかもしれません。でも、個人的にそこまで苦労したという記憶はないです。

理由はいくつかあって、1つはシステムのアーキテクチャ（仕組み）や技術選定について、きちんと勉強したというのがあると思っています。

エンジニアとしての開発経験は少なくても、「こういうアーキテクチャがいいんじゃないか」などと会話できれば、開発現場で信頼を得ることができます。

それともう1つ、いちエンジニアだった頃から、チーム全体の課題を見つけて解決に取り組むことを意識的にやるようにもしていました。危機察知力を磨いていたというか。

—— 具体的にはどんなことを？

よく今のチームメンバーにも話すのですが、「常に自分のポジションより1つ、2つ上の視座で現状を見渡す」というのを心掛けていました。

例えば開発メンバーの立場だと、担当する事業のPL（Profit and Loss statementの略で、損益計算書のこと）はあまり見ませんよね？

でも、本来は自分たちが作っている機能がどういう事業数字に結び付いているのか分かっていないと、次は何に注力すればいいのかが見えてきません。

こういう視点で、新卒の頃から「僕が上司だったら」と考えながら情報を取りに行って、やるべき仕事を考えるようにしていました。

—— 石垣さんがJobPicksに投稿している経験談の中では、チーム運営に関する言及も多く見受けられます。これも「上の視座」を意識していたからですか？

そうですね。新卒で入った会社がスタートアップだったら、チーム運営について考えるより「まずコードを書いてサービスを磨き込もう」となっていたかもしれませんが、DMMは僕のいるプラットフォーム事業本部だけでも150人以上のメンバーがいます。

こういう組織で事業を大きくしていくには、僕1人が残業してコードを書くより、チームで素早く機能開発をして、ユーザーの反応も見ながら改善を繰り返していくほうがいい。

だから、先ほど話した「1つ、2つ上の視座」で言うと、よくチームリーダーは何を考えて僕にこのタスクを任せているのか？などと考えていました。

なぜ今これをやらなきゃいけないのかを理解して、納得していれば、動き方が変わるじゃないですか。

そうすると、例えば「開発のタスクをこなすだけでなく、きちんとデータを分析しながら改善プランを立てられる体制にしなければ」などと、どういう手を打つべきかが見えてくる。

これも、年齢や経験値に関係なくできることだと思うんですね。

3. チームを束ねず「チームを頼る」

—— その後、エンジニア組織のマネジメントや、「DMMポイントクラブ」のプロダクトマネージャー（以下、PdM）も兼務していたそうですが、若手マネジャーとして壁を感じたことはありませんでしたか？

石垣 雅人

具体的なチーム運営のやり方に悩んだことはたくさんあります。

今でも課題の1つだと思っているのは、根回しが苦手なこと（苦笑）。特にマネージャーになりたての頃は、「成果を出してさえいればどんどん任せてもらえるんだ！」という傲慢さがあったと反省しています。

PdMをやらせてもらっている「DMMポイントクラブ」で新しい取り組みを始める時など、先に会長やマーケティング部門に根回ししておけばもっと早くスタートできたのに......というケースが何度かありました。

それと、メンバーにお願いするタスクの最適化にも悩みました。

最初は、メンバーの状況や気持ちをきちんと把握せずにタスクを任せまくる癖があって。僕自身が、新しいタスクをどんどんこなしていくのを楽しいと感じるタイプなので、他のメンバーも同じだろうと考えていたんです。

でも、それではみんなの生産性が上がらなくて。

また、エンジニアはある意味で職人気質な人が多いので、中には口調がキツい人もいたりします。誰か1人の物言いの問題で、会議で意見が出づらくなったりと、チーム全体の雰囲気が悪くなってしまうこともあるんです。

1人1人のモチベーションというか、感情の機微ともうまく向き合いながら、チーム全体で生産性を高めていくやり方を見つけるまで、少し時間がかかりました。

—— そのような「壁」を、どう乗り越えたんですか？

最も気を付けるようにしたのは、1on1の頻度とやり方です。

今は直属のメンバーがたくさんいるので、全員と頻繁にはやれなくなっていますが、1〜2週間に1度は必ず話す時間を取るようにしています。

それと、最初の頃は「なぜこの仕事をやるのか？」という説明をあまりせず、「今これが必要だからやってほしい」というふうにお願いしていたんですね。

それだと人がついてこないと感じたので、OKR（Objectives and Key Resultsの略で、目標と主要な結果を示すフレームワーク）で決めたチーム目標や個人のキャリア目標から話すように接し方を変えました。

こういう戦略があって、●●さんのキャリア的にもこういうタスクにチャレンジするのは良さそうですよね、と話すようにしたんです。

チームメンバーは僕より年上の方が多いので、自分から悩みや失敗をさらけ出すのも意識するようにしています。

大上段に構えて事業戦略や技術の話をしても、エンジニアとして僕より経験豊富な方からすると「それは分かってるよ」となってしまいます。なので、例えば

「僕はこう考えているんですけど、●●さんはどう思いますか？」

「今これについて悩んでいるんですけど、■■さんはこういう経験ってあったりしますか？」

などと、「僕が」チームを頼るというスタンスに変えました。すると、徐々にですがボトムアップで意見が出てくることが増えたんです。

4. マネジメント＝管理ではない

—— 例えばどんな意見ですか？

プラットフォーム事業本部内で始めた「ピアボーナス」制度などは、メンバーから出てきたアイデアがベースになっています。

ピアボーナスとは、何かしらチームに貢献したメンバーを、メンバー同士で称え合って報酬を送り合う仕組みのことです。僕のチームでは2018年ごろから採用していて、徐々に事業部全体に広めていきました。

誰かに感謝したい時は、Slackで指定のスタンプを押すと、そのスタンプが押してある投稿がまとめて見られるようにしたんです。

その数を基に月間MVPを選んで、賞金を出すような取り組みも行っていますが、それ以上に「仲間に褒められ、認められる」風土を可視化できたのが良かったと感じています。

称賛し合う文化が、モチベーションを上げるきっかけになっているという声が増えたので。

こういう仕組みに加えて、メンバーに権限委譲する機会を増やしていくと、能動的に課題を見つけて動く人が増えました。

—— 石垣さん自身が若いこともあってか、上から物事を押し付けないと。

これはその時々の上司やCTO（最高技術責任者）など、いろんな先輩方から学んできたことなのですが、そもそもマネジメントって「管理」することじゃないと思うんですね。

僕なりに言語化すると、マネジメントとは「課題を見つけて何とかする」こと。もっと言えば、それができるメンバーが多いチームを作ることだと思っています。

事業運営で直面する課題とは、技術がネックになっているものもあれば、生産性や人間関係が原因のものまで、さまざまです。

だから、それぞれの課題を解決していくためにも、いろんな志向・得意分野を持っている人が活躍できる環境が必要になります。

そして僕自身が「いろんな得意分野を持つチームの構成員」でしかないと考えれば、僕から何かを押し付けることもなくなります。

こう考えて仕事をしていたら、マネージャーの役割も何とかこなせるようになった。そんな感覚です。

5. 技術力「プラスアルファ」を探す

—— 20代で事業部長になった石垣さんの、次のキャリアプランは？

シンプルに、もっと世の中にインパクトのある事業を作ることができる人になりたいと思っています。

そのためには、エンジニアとしての基本的なスキルの上に、プラスアルファを積み重ねていかなければならない。新卒の頃からずっとそう考えてきました。

今は事業部長としてマネジメントの仕事を任せてもらっていますが、これも僕の中ではプラスアルファの1つなんです。

そもそも、これだけ多くのクラウドサービスやOSS（Open Source Softwareの略で、一定のルール内で誰でも無料で利用でき、自由に改変・再配布もできるソフトウェアのこと）がある時代、コードを書く能力だけでキャリアを築いていける「スーパーエンジニア」になるのは難しいと思っていて。

開発がしやすくなっているからこそ、今は1人のエンジニアを年収1000万円で雇うより、「AWSのこの機能を使えば年間100万円ぐらいのコストで自動化できるね」となるからです。

もちろん、エンジニアの中には、こうした“開発の武器”になるテクノロジーそのものを生み出せる人や、ネットワークからアプリケーションまで全レイヤーの開発・運用を1人で担当できるような人もいます。

でも、僕の感覚だと、そういうスーパーなエンジニアになれるのは、全エンジニアの上位5％くらいだと思うんですね。

となると、残る95％のエンジニアは、プログラミング以外の強みを磨いていかなければなりません。

僕の場合、それが「チーム運営」や「マネジメント」についての知識だったわけです。

最初に「新卒の頃からプログラミングスキルで勝負するという考えを捨てていた」と話したのも、この考え方がベースにあったからです。だから今後についても、マネジメントだけを極めようと思ってはいません。

実際、他社でやっている副業では、プログラマー兼技術顧問的な仕事をしたり、アナリストとしてデータサイエンスの仕事に携わったりもしています。

これも全て、何かしらの事業を作っていく上で出てくる「課題を何とか解決する」力を身に付けたいからです。

これからも、この考え方で新しい経験を積んでいけたらと思っています。

> 石垣さん自身が投稿した「経験談」ページはこちら

合わせて読む：ソフトウェア開発の最重要スキルとは？グーグルのエンジニアに聞く

取材・文：伊藤健吾、デザイン：石丸恵理、撮影：遠藤素子