マネージャーとシニアエンジニアの両立
――現在の業務内容を教えてください。
弊社（リクルートテクノロジーズ社）の中ではAPソリューショングループのグループマネージャー、およびシニアソフトウェアエンジニアというエキスパート職のという２つのことをやっています。リクルートテクノロジーズではキャリアを開発する上でエキスパートになるコースと、マネジメントをやるコースの2つがあるんです。
僕は、たまたま両方やっています。エキスパートでやりつつマネジメントもやるキャリアはあまり多くないので、新しいキャリア設計をしていると自分では思っています。
マネジメント側面でいくとアプリケーションソリューショングループ内でやっているのはシングルページアプリケーションを作ったりとか、高難易度な開発の案件を担当することが多いですね。開発の中でも少し難しめの案件です。例えばリアルタイムのチャットを作るとか、普通のウェブアプリケーションではない少し難しい案件を扱うのがアプリケーションソリューショングループです。
マネージャーとして主にやっているのは、キャリアの管理だったりメンバーのリソース管理です。メンバー10数名を率いて、新しい案件が来たタイミングで、彼らのキャリアを考えながら「どの案件が誰に合いそうか」を決めてやっていくことが多いですね。主にやってるのはシングルページアプリケーションでリッチなウェブアプリケーションを作ることが多いんですけど、React や Redux、Node.jsを使ってアプリケーションを作るということをメンバーとやっている感じですね。
シニアソフトウェアエンジニアの側面だと、エキスパートとしてやっていることは新しいウェブアプリケーションのライブラリを作るとか、Node.jsに新しい機能が入ったからパフォーマンスにどう活かすかを考えたりとか。ReactとかRedux、Node.jsを使ったウェブアプリケーションのボイラープレートを作っています。わかりやすくいうとRuby on Railsというフレームワークなんですけど、フレームワークと呼ばれるものはウェブアプリケーションの作り方なんですよね。
それをもう少し進めて、「さらにオススメのものを入れるとこういう設計になるよ」と固めて作ったサンプルを提供するのがボイラープレートです。ウェブアプリケーションの作り方を定義しているものですね。オープンソースのredux plutoというものなんですけど、redux plutoを開発メンテするとか今後の方針を決めることもやっています。
最近はリクルートではウェブアプリケーションの性能チューニングもやっています。Googleもここ最近はSEOにおいて、パフォーマンスも重要視しているというメッセージが出ています。そのために実際のウェブアプリケーションをチューニングすることもやっています。また、R&Dとしては性能改善の方法やライブラリを調べて実際にチューニング時に使えないかを事前に調査する事もやっています。
グループマネージャとしての側面では、基本的にはリソース管理とキャリア管理の2つをやっています。メンバーのキャリアややりたいことを鑑みて開発案件にアサインするという事ですね。その上で、ただ開発をこなすだけではなく、メンバーには一人ひとりに何らかの目的意識を持った技術的なチャレンジをしてもらっています。最近ではGoの開発の標準化だったり、React/Reduxを使ったパフォーマンス向上だったり、PWAだったりといった活動をメンバーにチャレンジさせています。
――エキスパートとマネジメントを同時にこなすのは、相当負荷が高いのではないかと想像しますがいかがでしょう？
古川 実はそうでもないんです。グループマネージャーといっても、リソースの管理とキャリアの管理しかしてないので、他のグループマネージャーに比べると楽な方ですね。プロダクトマネジメントだったりプロジェクトマネジメントをしないといけない人もいますから。自分の担当している製品だったりサービスを管理するのが弊社のマネジメントには求められるんですけど、僕のグループは特定のプロジェクトやプロダクトを持たないので。
グループマネージャーによってはコスト管理とかもしないといけないんですけど、われわれはそこまで難しいコストの管理はしていません。管理の側面でいうと、他より若干楽ではあります。なので、そのぶん余裕を活かしてエキスパートもやらせてもらっている感じですね。
僕のイメージでは、エキスパート7:3マネジメントです。人が増えてくると違うでしょうが、今は正社員だと8人、パートナー含めて10数人ですから逼迫していて大変ということでもないですね。
パイオニアとしての意識で、キャリア選択しています
――エキスパートとマネジメントの両立は、ご自身で手を挙げられたんですか？
古川 いずれも「やってみないか」という打診が上司からあったんです。僕のやっていることはそもそもエキスパートのやっていることだったし、採用された経緯からして「エキスパートとしてエンジニア組織を作ること、新しいものを作ることの両方をやってほしい」とのことだったので快諾した形です。
グループマネージャーはやったことがなかったので、未経験のことをやるのも面白いなと思って。メンバーには、マネジメント職に抵抗を示す人もいます。でもマネジメントにはいろいろな形態がありますし、人にモノを教えること自体は嫌いではない人も多いです。僕も同じで、人に教えたりメンバーと一緒にワイワイやるのは嫌いじゃないです。
僕がやっている、キャリア管理やリソース管理をやりつつ新しいことに挑戦するというキャリアパスができるんだったら、今のメンバーからも「マネジメントやシニアをやってみたい」という人が増えるんじゃないかなと思っていて。パイオニア的な意味合いで、このキャリアを選んでいる部分はありますね。
エキスパートを目指したい人が、マネジメントに行かされそうになるのは嫌だという気持ちはわかるんです。ただ、プログラミングを書いて、新しいことをとことん突き詰めてやれる人って本当に全体でも何%しかいないと思うんですね。「こういう生き方もある」と見せられれば、「マネジメントをやってみよう」という人が増えてくれるのはないかなと。もちろん、コードも書けることを見せながらですけどね。
――エンジニアの方々をまとめる上で、「現役でコードを書いている」というのはすごく大事なことなんですか？
古川 メンバーからある程度尊敬を集める意味で、技術力は必要だと思っています。僕もそうだったので。彼らにとっても心理的に安心できますし、チャレンジしていることの凄さもわかってあげられるとより大きなチャレンジができるんじゃないかなと。
――スポーツでも、監督が現役時代にどれだけの結果を残したかは、選手への説得力が全然違ったりしますよね。
古川 上に立つ人が尊敬できないと、メンバーからは「この人には従いたくないな」という雰囲気が出ちゃうと思うんです。そういう意味で、シニアとマネージャーを両方続けられているのは良いことなのかなと思います。
――実際にマネジメントを行なっていてぶつかる課題は、どのようなものがありますか？
古川 僕がマネージャーをしているAPソリューショングループは新しい技術に挑戦していくグループなんですけど、そうなると今までの方法論と全く別のことをやらないといけないというのがあるんですね。
例えば、弊社のメインで使ってるサービスですと、シングルページアプリケーションではなく、従来どおりのHTMLページをJavaやOracle等を利用してサーバで作って返すアプリケーションが多いです。この上でさらにJavaScriptで動きを与える事が多いのですが、元々の既存のHTML生成やサーバの処理に問題があると例えフロントエンドのアーキテクチャが優れていても良いプロダクトになりません。
従来の方法論ではHTMLが主体でJavaScriptはおまけでした。今はHTMLもJavaScriptも同様にフロントエンドの重要なパーツであり、どちらかだけが優れていれば良い、というものではなくなっています。そのためサーバの動きとHTML、JavaScriptそれぞれでどこになんの処理を書くべきか、といったアーキテクチャの議論が必要になります。
どうしても既存のやり方だけしかやった事がない人に新しいやり方を説明しても受け入れてもらえません。そういう方々に対して新しいフロントエンドの開発方法が「わからない」や「知らない」といった状態から「わかった」「知ってる」という様に把握してもらい、その上で新しい開発方法にも慣れてもらう必要があります。
これまでは、作り方においてはJavaが主導権を握っていたんです。ただ、シングルページアプリケーションにおいては今度はブラウザでJavaScriptが主導権を握って作らなければいけなくなって、主導権の奪い合いになるんです。どちらがどちらの処理を書くか、ということになりがち。
機能の譲り合いになるかもしれないんですけど、それだと結局今までの方法論の上でしか作れないんです。その価値観を崩さなきゃいけないので、「サーバーをこうやって作りましょう」という決めを引かなきゃいけないんですけど、その中で今までやっていないことをやることに抵抗が生まれちゃったりするので。
普段はマネジャーとしてメンバーに案件を任せているので、細かい議論には参加していませんが、新しいやり方を既存のやり方の間でハレーションが起きた時は、直接入って行って『なぜこのアーキテクチャがいいのか』を説明するサポートはするようにしています
既存のやり方と新しいやり方が出てきた時に、新しいやり方の良さを人にちゃんと説明できるようにしておかないと、揉めちゃうことがあります。「ただ新しいことを入れたい人」という風に見えがちですから、「こっちの方がすごく良いんだ」というのを理解してもらう必要があります。
「正しさ」には2つあると思います
――これまでのご経歴は一社目に富士ゼロックス、2社目でDeNA、3社目でリクルートテクノロジーズ社。比較的大手の会社を渡られてると思うんですが、もっと規模の小さい会社に興味があったりはしたんでしょうか？
古川 これは、僕がテクノロジー志向のエンジニアであることが影響しています。サービスを作ることは嫌いじゃないですし、サービス志向のエンジニアなら小さい会社がマッチすると思います。一方、テクノロジー志向のエンジニアは「この技術をどうやったら活かせるか」と考えちゃうんですね。
どちらかというと研究職に近いというか、「この技術を使って新しいウェブアプリケーションを作る場」を求めるので、そうなると小さい会社では難しいんです。立ち上げ期は、技術よりもサービスを作って伸るか反るか、売り上げが上がるかをやっていかないといけないですから。
僕の目指しているエンジニア像としては売上だけ、納期だけ満たせばそれで良い、というエンジニアではありませんでした。また逆に特定の技術だけ実施できていればそれで良い、というエンジニアでもありませんでした。
僕が学んできたのは、テストをちゃんと書いてメンテナンス性を上げるとか、セキュアな実装になっているかチェックするとか、パフォーマンスを下げないように維持するとか、何百万人のトラフィックを捌くにはこうした方が良いとか。
つまり、機能要件を満たして、納期と売上も満たしつつ、非機能要件をその制約の中でどこまで満たせるか、というのが僕の中での理想的なエンジニア像です。
――業務を行う上で大事にしているモットーや、好きな言葉があれば教えてください。
古川 最近好きな言葉は「正しさには２つある」です。validationとverificationという言葉があって。validation は value から来てて、「価値がある」という意味、verification は very から来てて「とても、まさしく」という意味です。
2つの言葉は日本語に直訳すると「検証する」とか「検証された値の正しさ」という意味なんですけど、中身はちょっと違っていて。会社で置き換えるなら「数字で貢献できている」がバリデーションです。ソフトエンジニアでいうと、何かをリリースしたという価値に貢献していますよね。これはこれでやらなきゃいけません。
一方、ベリフィケーションは「あるべき姿であること」。テストをちゃんと回していてメンテナンス性が高いとか、機能要件ではないけどサクサク動いていてユーザー体験が良いとか、セキュリティ面で変なバグが仕込まれていないとか。品質が高いことが、正しくあるべき姿だと思うんですね。
これは、どちらかを満たせば良いわけじゃないんです。両方満たさなきゃいけない。締め切りまでにリリースしなきゃいけないのはもちろん、クオリティを上げてソフトウェアの価値を高めることもやらなきゃいけない。
これを両方保てる人間になってほしい、というのが最近やってることですね。期日に追われる中でも、自分たちの価値を最大化しましょうと。そのためには、結局勉強するしかないんです。ソフトウェアを勉強するというのは、両方の正しさを満たすため。どちらかやればいい、というわけではないんです。
エンジニアリングというのは深い学問で、テストもやらないといけないし性能も学ばなきゃいけないしアルゴリズムも考えなきゃいけない。それでいて、開発する速度を落としてもいけない。難しいです。でも、理想の状況に近づけることは重要ですし、僕もそうなるために努力しています。
――あらゆる職業に言えることですね。
古川 そうだと思います。理想論だとは思いますけど、理想論だからあきらめようではなく「それを解決するのがエンジニアリングなので頑張ろう」という感じですね。
ロールモデルである、という意識を持っています
・専門性向上 5
古川 僕自身が、技術を上げることが好きだからですね。ライフスタイルとしても、下げることはしないだろうなと。Node.jsとかJavaScriptだけの専門性を上げていくよりは、別のことをやっていくかもしれないですけど、何かの技術を学んでいくことは生涯止める気持ちはないかなと。それができる組織、働く場所が一番という気はしています。
・仲間 5
一緒に働いている人はどうしても影響を受けやすいし、僕も影響を与えることになると思うので。ある程度、信頼しあえる仲間というのが重要だなと思っています。
・お金 2
お金は嫌いではないですが、相対評価として。生活できるお金はほしいです（笑）。あと、僕みたいなキャリアを目指している人がいるとして、「実はもらっているお金が低いです」「全然稼げていません」となると目指さなくなる人が増えると思うんです。自分はロールモデルである、という意識を考えて、ちゃんともらうのは大事だなと思います。重視していないわけではありませんが、相対評価として２ということで。
――ロールモデル、パイオニアである意識をすごく持たれてるんですね。
古川 そうですね、でもそうなったのはリクルートに入ってからです。リクルートの中で、シニアエンジニアはあまりいないんです。リクルートテクノロジーズの中だと10数人。リクルートのシニアはすごい人が多くて、「自分は、彼らと肩を並べているのだ」ということは意識しています。
シニアになるうえの条件の一つが、「ロールモデルであること」なんですね。社内からも尊敬を集め、社外からも認知を集めていることが１つの条件。さらに、会社への貢献度を見越した位置づけになります。意識を高く持っておかないといけません。常に情報収集やアウトプットを怠らないようにしています。
・事業内容 4
古川 エンジニアである以上、人の役に立ちたい気持ちが根っこにあります。自分がやっていること、自分が使うサービス、周りが使っているサービスは事業内容として大きいと思っています。何をやってもいいわけではないなと。
・働き方自由度 2
古川 今かなり自由にさせてもらっています。ただ、最近リモートワークが盛んだと思うんですけど、弊社では子育て中の社員や、介護中の社員にのみ在宅勤務が認められています。
このような制度になっているのは単純な理由で、正社員だけで開発しているわけではないからです。開発パートナーや事業会社のメンバーなど、関係者が非常に多いので、出社して仕事をする方が生産性が高い、という判断を会社でしています。働き方自由度という面では一種の制約かもしれませんが、僕自身はみんなと顔を突き合わせて仕事するのが好きなので、そこまでこだわってはいないですね。自分自身は9時から10時までには出社するようにしてますが、メンバーには特に制限を設けていません。11時までに出社しない時は一報の連絡をさせるようにしている程度です。
・社畜度 ２
古川 社畜度って言葉が（笑）、どちらかというと「会社愛」が近いかもしれないですね。リクルートテクノロジーズだけではなく、グループ全体で労働時間の管理はかなり厳しくされています。もともと長く働くことではなく、出した成果で評価される会社ですし。年間で決められている残業時間のトレンドを超えると、労働時間を下げるように動いてもらう形になっています。
会社愛という意味で言うと、僕を高く評価してくれた結果シニアエンジニアだったりマネージャーだったり重要なポストにつかせてもらってるので感謝しています。一方で会社を選んだり、場所を選ぶときにブランドにはこだわりません。面白そうな会社がいいと思います。
――ロールモデルやパイオニアであり続けるモチベーションは、どのあたりにありますか？
古川 情報をアウトプットすることや、発表した時にポジティブなフィードバックをいただくことがモチベーションになっています。誰からも見向きもされず価値がないと思われていたら、やらないと思うんです。マネージャーも似てるところがあって、メンバーの成長が見られたりポジティブなフィードバックをもらえたりすると「やっててよかったな」と思います。
――インタラクティブなコミュニケーションが、源泉になってるんですね。
古川 勉強会を主催しているのも、そういう理由ですね。僕はNode.js 日本ユーザーグループの代表でもあるんですが、そういうことをやるのは単純に面白いからですし、海外のエンジニアから「こんなことをやってるんだ、知らなかった」というフィードバックがあると「またやってみようかな」という気になります。ネガティブなフィードバックもあるんですけど、そちらはあまり目に入れないようにしています。もちろん、建設的なフィードバックは目に入れるようにしてますけどね。
技術で戦える場所を目指してほしい
――転職を志している読者に対してメッセージをお願いします。
古川 技術でちゃんと戦える場所、会社は日本にも多いと思います。そういうところを目指してほしいですね。
あと「マネージャーにはなりたくない」みたいなことを言ってしまうエンジニアは多いですけど、どんなマネジメントをするかの中身によってはそこまで大変でもない、面白いこともあります。そういうことが伝われば、「こういうキャリアもありだな」と思ってもらえるかなと。
僕がやっているキャリア管理やエンジニアのリソース管理だけならそこまで大変ではないし、メンバーと一緒に自分も育成される感覚です。自分1人だけが成長するよりも、みんなで一緒にテスト勉強したほうが成長しやすいという話だと思うので。自分だけの視野で「マネージャーはやりたくない」とは思ってほしくないですね。
転職を考えるときも、「大きな会社だから、マネージャーをやらされるんじゃないか」と考えてほしくなくて。技術的にチャレンジできる場を選んでほしいし、さらにその上で、誰かを率いるということもいとわないで欲しいなと思います。
