目次
■エンジニアの軌跡
2018.08.21 2023.12.14 約3分
GMOペパボの主席研究員、Forkwell技術顧問などを務める松本氏が「Forkwell Portfolio」をレビュー！実績のアウトプットによる引き抜きを懸念する企業側へ「それとこれとは別問題」とバッサリ。エンジニアへ向けては「アウトプットしまくって、外から声がかかりまくるエンジニアになってほしい」と激励の言葉を送ります。
──Forkwell Portfolio を出した時に「コード変更行数も指標になっているけど、行数が多ければ必ずしも良いわけではないよね？」という声をいただいています。
松本：コード行数は悩ましいですね。毎回そうではないですけど、1週間で1行の変更をするのに悩んだことがあります。客観的に見ると1行の変更なので価値がなく見えますけど、それは社内で僕にしか出来ない1行の可能性もあって。
もちろん社内で優れた評価をされているエンジニアになる人は、ものすごい行数を書いています。必要十分ではないですけど、行数を書くことも重要だと思います。ただ、そこに客観的指標が入りづらいのは問題かなと思っています。
例えばStar数は自分でコントロールできないですよね。それは客観的指標なんですけど、コントロールできないしStar数を増やそうと思うと何かしらアクションが必要になってくる。でも、行数は実績を良く見せたい人が簡単にコントロールできる。なかなかこの基準を強く押し出すのは難しいかなと思います。
客観的な指標が入るパラメータを使って、その客観的指標を自分でコントロールするにはかなりのコード力が必要だということを重要視していくと良いんじゃないかなと思います。
Star数の話でいうと、海外でやっているGit AwardsはStar数でランキングを出すというのがあるんですけど、例えばすぐ使えるツール的なものはStarがつきやすい一方、規模の大きいミドルウェアなどはつきづらいものがある。Starに近い客観的指標で、それらしいものができると良いかなと思います。Star数については依然賛否両論ではありますが。
──積極的なアウトプットや、自分の活動をまとめて社外に発信することを推奨されていると聞きました。
松本：アウトプットでエンジニアとしてのスキルを言語化することで、社内よりもより広い規模でのフィードバックと改善を回すことができる。これがエンジニアの成長に繋がると考えています。サービスも社内だけでやるより公開して色々な人に使ってもらう方が良くなっていくのと同じですね。
組織では事業貢献が基本的な指標ですが、エンジニアとしての価値を考えると客観的指標、つまり「社外から見た評価」も同じくらい重要だと考えています。
アウトプットして、それが社外から評価されたり影響を与えているかどうかは客観的指標のひとつにもなりますよね。
──メンバーがアウトプットしているかどうか、どのように判断すればよいでしょうか？
松本：まずは社内でCFPを集めてレビューをするのも良いと思います。例えばRubyKaigiに出す時に、PRでCFPを書いてそれをみんなでレビューすれば、切磋琢磨できる環境がつくれますよね。
また、アウトプットを全社的に公表する仕組みがあれば、メンバー以外にも周知できる。査定の時にそういったCFPの実績や勉強会に参加したことをちゃんと残しておけば、成長にも評価にもつながるのではないかと思います。
──自分のプロフィールや実績をまとめて、社外に発信している人はいますか？
松本：僕の周りでは、まだ一部の人間しかやっていないですね。そこを、ポートフォリオサービスをうまく巻き込めるといいなと思っていて。実績って、書いてみると「ないこと」に気づいちゃうんですよ。アウトプットって継続的にやってないと、ふとした時に何もやってない感がすごくある。
実績が増えてきてある程度有名になると、まとめるのが面倒くさくなる。「自分は知られてるし、アウトプットし続けるから実績ページなんていらない」という考えになってしまいがち。そこを、ポートフォリオサービスで押さえられるといいと思っています。
──企業の中には、エンジニアへのアウトプットを促すことで引き抜きを恐れる方もいます。
松本：僕や知り合いのCTOの共通認識なんですけど、そこは別問題として捉えています。極端に言うと、引き抜かれても良いと考えているんですね。実績をオープンにすることと、引き抜かれそうになったときに他の会社に行きたいと思うことは別の問題だと思っていて。
アウトプット → 言語化 → のサイクルは必ずエンジニアの成長に繋がります。その結果引き抜きがあれば、正しい成長です。やりがいや給与への満足度、楽しめているかは別の問題かなと。
アウトプットしまくって、外から声がかかりまくるエンジニアになってほしいと思っています。アウトプットし続け成長しているエンジニアの方が、社内で成果を出してくれますから。引き抜かれそうになっても今いる会社にいたいと思ってもらえるように、エンジニアが適正に評価され、労働しやすい環境にしていくという考え方でやっています。
──成長過程のエンジニアにアドバイスする際に、松本様が気をつけられていることはありますか?
松本：成長過程にある人が共通してハマるところがあります。とにかく量を書くこと、継続することができないんです。
例えば毎日ブログを書きますって宣言して書き始めるんですけど、成長過程の人は影響力がないので、誰も見てくれないからアウトプットする意味がないと思って止めちゃう。
それだけでなく、内容が薄すぎるから「しっかり考えてクオリティ高いものを書かないといけない」と思って継続が止まる人がいるんですね。自分のやれていることよりも高いものを書く、というのはそれこそストレスだし大変なこと。やろうやろうと思っているうちに、業務とかプライベートとかいろんな精神面の問題から止めちゃうのがあります。
そんな人に言い続けているのは、「大した内容でなくても良いので、ひたすらアウトプットし続ける」ということです。それを乗り越えると、徐々に良いエントリーを書けるようになるんです。
良いエントリーを自然に書いてしまうと、ちゃんと拡散される。ちょっとやっただけで誰も見てくれない、でも止めるのではなく。内容のないブログであっても気にせず書き続けるのが、いずれ成長に繋がっていくのかなと。量が質に転化し始める。
──それをできない人とできる人の違いは、どういう部分ですか？
松本：本人が優れたエンジニアになりたいと強く思っているかどうか、つまり、目の前の課題や苦労によって諦めたりすることのない大きな目標を持っているか、に左右されますね。人によってはなりたいと思ってない人もいて、それは人それぞれなので。そういう人たちを活かせる環境をつくることも組織には必要です。
ただ、その人たちにもアウトプットすると楽しいと思える瞬間もあります。勉強会もそうですしカンファレンスもそう。カンファレンスに参加して成功体験を積むというのは効果があると思います。
最初の一歩を踏み出すのはすごく大変なので、そこを強く支えることはやっています。GitHubは草が生えるからやっている人もいるので、継続してやることの支えになっている人もたくさんいて。
ポートフォリオサービスだとうまく連携できると思うので、毎日コミットする、ブログを書くことが「ポートフォリオを充実できて楽しい」という体験につながれば良いなと思っています。同時に、ここを乗り越えた人はまた違うパターンの継続性になると思うので。そこをうまく表現できると良いなと。
ポートフォリオは、実績が積まれていくと楽しいんですよね。自分で書いてみると大したことなかったとか。実績を積むことに対する楽しさを提供できると、もっといろいろな人が使うと思います。
バッジとかも今はまだベータ版ということ、精度とかもいろいろあると思うんですけど付随する何かしら楽しいこと、体験として楽しいなと思えることがポートフォリオの中であるとスキルの可視化に繋がっていくと思うので。その楽しさと成長が重なり始めると理想的だと思いますし、それらを支援するポートフォリオサービスが必要だと感じています。
一方で、継続はすごく重要だと思うんですけど、成長し始めたエンジニアはいつしか一般的に言われる継続とはまた別の、冒頭に申し上げたような量より質のフェーズに入ります。
そうなってくると、GitHub の草はまばらになり、定期的に濃い緑がつくだけになります。数年単位でずっと継続していて、粒度は荒くなってはいるものの継続的についている人もいる。それを「継続性がない」と評価するのは違いますよね。
逆に、今成長過程にある人が薄い緑だけど毎日コミットすることにしていれば、それはそれで価値があると思います。
──周りの人が積極的にアウトプットしているのをみて、自分もアウトプットしてみようと思うことがあると思います。
松本：そういう状況は意識的に作っていますね。職位が高い人こそ何かしら提案だったりカンファレンスで喋るチャンスがあった時に、誰よりもそれに乗っていくというのをオープンな場でやるべきだと思います。乗っていくことをあえて見せる。
刺激を受けることで、徐々にチャンスに乗っかっていく。それが当たり前で楽しいことだと教えるのは、狙ってやってるところはあります。職位が上がっていった人が積極的にずっとやり続けているという雰囲気を出すようにはしていますね。
──周りのメンバーはそういう姿を見て自分もそういう行動をした方が良いんだろうなと気づき始めて引き上げられていくということですね。
松本：ちゃんとアウトプットして成果を得た人には、自分の経験を雑に語るだけじゃなくて、ちゃんと自分のキャリアとして経験を一般化するよう促しています。「これをやるとうまくいったのは自分だけ」というところと、共通しているところを一般化してちゃんと言語化してね、と。それが周りの人にもいい影響を与えます。
