エンジニアの生き様をウォッチするメディア

自分の経験を言語化すると、周りの人に良い影響を与える 松本亮介様〜(Forkwell Portfolio スペシャルインタビュー)

f:id:grooves:20180817171658j:plain:w450

Forkwellではこの度、GMOペパボ株式会社チーフエンジニアでペパボ研究所主席研究員でもある松本亮介氏を技術顧問に迎えました。

Forkwell Pressでは早速松本氏にインタビューを敢行、Forkwell Portfolioへのご意見だけでなく、「成長し続けるエンジニア」についても語っていただきました。

1週間で1行の変更に悩む。でもそれは僕にしかできない1行の可能性もある。

――Forkwell Portfolio を出した時に「コードを変更した行数も指標になっているけど、行数が多ければ必ずしも良いわけではないよね?」という声をいただいています。

松本 コード行数は悩ましいですね。毎回そうではないですけど、1週間で1行の変更をするのに悩んだことがあります。客観的に見ると1行の変更なので価値がなく見えますけど、それは社内で僕にしか出来ない1行の可能性もあって。

もちろん社内で優れた評価をされているエンジニアになる人は、ものすごい行数を書いています。必要十分ではないですけど、行数を書くことも重要だと思います。ただ、そこに客観的指標が入りづらいのは問題かなと思っています。

例えばStar数は自分でコントロールできないですよね。それは客観的指標なんですけど、コントロールできないしStar数を増やそうと思うと何かしらアクションが必要になってくる。でも、行数は実績を良く見せたい人が簡単にコントロールできる。なかなかこの基準を強く押し出すのは難しいかなと思います。客観的な指標が入るパラメータを使って、その客観的指標を自分でコントロールするにはかなりのコード力が必要だということを重要視していくと良いんじゃないかなと思います。

Star数の話でいうと、海外でやっているGit AwardsはStar数でランキングを出すというのがあるんですけど、例えばすぐ使えるツール的なものはStarがつきやすい一方、規模の大きいミドルウェアなどはつきづらいものがある。Starに近い客観的指標で、それらしいものができると良いかなと思います。Star数については依然賛否両論ではありますが。

――自社のエンジニアの方々に対して積極的にアウトプットすることを話されたり、自分の活動をまとめて社外に発信することを推奨されていると聞きました。

松本 アウトプットすることでエンジニアとしてのスキルを言語化して客観的に抽象化することで、社内よりもより広い規模でのフィードバックと改善を回すことができる。これがエンジニアの成長に繋がると考えています。サービスも社内だけでやるより公開して色々な人に使ってもらう方が良くなっていくのと同じですね。
組織では事業に貢献することが基本的な指標だとは思うのですが、エンジニアとしての価値を考えると客観的指標、つまり「社外から見た評価」も同じくらい重要だと考えています。
アウトプットして、それが社外から評価されたり影響を与えているかどうかは客観的指標のひとつにもなりますよね。

――メンバーがアウトプットしているかどうか、どのように判断すればよいでしょうか?

松本 まずは社内でCFPを集めてレビューをするのも良いと思います。例えばRubyKaigiに出しますってなった時に、PRでCFPを書いてそれをみんなでレビューすれば、切磋琢磨できる環境がつくれますよね。また、アウトプットしたら全社的に公表する仕組みがあれば、メンバー以外にも周知できる。査定の時にそういったCFPの実績や勉強会に参加したことをちゃんと残しておけば、成長にも評価にもつながるのではないかと思います。

――自分のプロフィールや実績をまとめて、社外に発信している人はいますか?

松本 僕の周りでは、まだ一部の人間しかやっていないですね。そこを、ポートフォリオサービスをうまく巻き込めるといいなと思っていて。実績って、書いてみると「ないこと」に気づいちゃうんですよ。アウトプットって継続的にやってないと、ふとした時に何もやってない感がすごくある。

実績が増えてきてある程度有名になると、まとめるのが面倒くさくなる。「自分は知られてるし、アウトプットし続けるから実績ページなんていらない」という考えになってしまいがち。そこを、ポートフォリオサービスで押さえられるといいと思っています。

f:id:grooves:20180817171938p:plain

実績をアウトプットすることと、引き抜かれることは別問題

――企業の中には、エンジニアへのアウトプットを促すことで引き抜かれることを恐れる方もいます。

松本 僕や知り合いのCTOの共通認識なんですけど、その問題は別の問題として捉えています。極端に言うと、引き抜かれても良いと考えているんですね。実績をオープンにすることと、引き抜かれそうになったときに他の会社に行きたいと思うことは別の問題と思っていて。

アウトプットして言語化してさらにアウトプットしていく、というサイクルは必ずエンジニアの成長に繋がっています。やればやるほど成長すると思っています。その結果引き抜かれるとなった時は、正しい成長です。エンジニアがやりがいがあったり、給与に満足していたり、楽しめているか等は別の問題かなと。

アウトプットしまくって、外から声がかかりまくるエンジニアになってほしいと思っています。アウトプットし続け成長しているエンジニアの方が、社内で成果を出してくれますから。引き抜かれそうになっても今いる会社にいたいと思ってもらえるように、エンジニアが適正に評価され、労働しやすい環境にしていくという考え方でやっています。

大した内容でなくても良いので、ひたすらアウトプットし続ける。気にせず書き続けるのが、いずれ成長に繋がっていく。

――成長過程のエンジニアにアドバイスする際に、松本様が気をつけられていることはありますか?

松本 成長過程にある人が共通してハマるところがあります。とにかく量を書くこと、継続することができないんです。

例えば毎日ブログを書きますって宣言して書き始めるんですけど、成長過程の人は影響力がないので、誰も見てくれないからアウトプットする意味がないと思って止めちゃう。

それだけでなく、内容が薄すぎるから「しっかり考えてクオリティ高いものを書かないといけない」と思って継続が止まる人がいるんですね。自分のやれていることよりも高いものを書く、というのはそれこそストレスだし大変なこと。やろうやろうと思っているうちに、業務とかプライベートとかいろんな精神面の問題から止めちゃうのがあります。

そんな人に言い続けているのは、「大した内容でなくても良いので、ひたすらアウトプットし続ける」ということです。それを乗り越えると、徐々に良いエントリーを書けるようになるんです。良いエントリーを自然に書いてしまうと、ちゃんと拡散される。ちょっとやっただけで誰も見てくれない、で止めるのではなく。内容のないブログであっても気にせず書き続けるのが、いずれ成長に繋がっていくのかなと。量が質に転化し始める。

――それをできない人とできる人の違いは、どういう部分ですか?

松本 本人が優れたエンジニアになりたいと強く思っているかどうか、つまり、目の前の課題や苦労によって諦めたりすることのない大きな目標を持っているか、に左右されますね。人によってはなりたいと思ってない人もいて、それは人それぞれなので。そういう人たちを活かせる環境をつくることも組織には必要です。

ただ、その人たちにもアウトプットすると楽しいと思える瞬間もあります。勉強会もそうですしカンファレンスもそう。カンファレンスに参加して成功体験を積むというのは効果があると思います。最初の一歩を踏み出すのはすごく大変なので、そこを強く支えることはやっています。GitHubは草が生えるからやっている人もいるので、継続してやることの支えになっている人もたくさんいて。

ポートフォリオサービスだとうまく連携できると思うので、毎日コミットする、ブログを書くことが「ポートフォリオを充実できて楽しい」という体験につながれば良いなと思っています。同時に、ここを乗り越えた人はまた違うパターンの継続性になると思うので。そこをうまく表現できると良いなと。

ポートフォリオは、実績が積まれていくと楽しいんですよね。自分で書いてみると大したことなかったとか。実績を積むことに対する楽しさを提供できると、もっといろいろな人が使うと思います。バッジとかも今はまだベータ版ということ、精度とかもいろいろあると思うんですけど付随する何かしら楽しいこと、体験として楽しいなと思えることがポートフォリオの中であるとスキルの可視化に繋がっていくと思うので。その楽しさと成長が重なり始めると理想的だと思いますし、それらを支援するポートフォリオサービスが必要だと感じています。

一方で、継続はすごく重要だと思うんですけど、成長し始めたエンジニアはいつしか一般的に言われる継続とはまた別の、冒頭に申し上げたような量より質のフェーズに入ります。

そうなってくると、GitHub の草はまばらになり、定期的に濃い緑がつくだけになります。数年単位でずっと継続していて、粒度は荒くなってはいるものの継続的についている人もいる。それを「継続性がない」と評価するのは違いますよね。

逆に、今成長過程にある人が薄い緑だけど毎日コミットすることにしていれば、それはそれで価値があると思います。

――周りの人が積極的にアウトプットしているのをみて、自分もアウトプットしてみようとなることがあると思います。

松本 そういう状況は意識的に作っていますね。職位が高い人こそ何かしら提案だったりカンファレンスで喋るチャンスがあった時に、誰よりもそれに乗っていくというのをオープンな場でやるべきだと思います。乗っていくことをあえて見せる。

刺激を受けることで、徐々にチャンスに乗っかっていく。それが当たり前で楽しいことだと教えるのは、狙ってやってるところはあります。職位が上がっていった人が積極的にずっとやり続けているという雰囲気を出すようにはしていますね。

――周りのメンバーはそういう姿を見て自分もそういう行動をした方が良いんだろうなと気づき始めて引き上げられていくということですね。

松本 ちゃんとアウトプットして成果を得た人には、自分の経験を雑に語るだけじゃなくて、ちゃんと自分のキャリアとして経験を一般化するよう促しています。「これをやるとうまくいったのは自分だけ」というところと、共通しているところを一般化してちゃんと言語化してね、と。それが周りの人にもいい影響を与えます。


Forkwell Portfolioは、エンジニア向けのポートフォリオサービスです。
Gitリポジトリを解析して、あなたのアウトプットをグラフィカルに可視化します。

Forkwell Portfolioのご登録はこちら!