OSSなどから学んだヒューマンスキルと経験を武器に。人生最大の挫折を越えてなおも歩む螺旋のキャリア

サーバーサイドからインフラ領域を中心としたWebエンジニアとして、リードエンジニアからプロダクトマネージャー、CTOと、順調にマネジメントの階段を上がってきた松木雅幸（Songmu）さん。その後、再びプレイヤーとして転職し、現在またマネジメントに取り組んでいます。この螺旋（らせん）のキャリアと呼ぶ働き方の変遷と、それを支えるOSSへの取り組み方について寄稿いただきました。

▲ベストスピーカーを獲得したYAPC::Tokyo 2019での登壇（写真提供：Japan Perl Association）

私は、小粒ながら多くのOSSを開発してきました。他にも技術的な情報発信や、ISUCONでの優勝経験、エンジニア向けSaaSのプロダクトマネージャーやCTOといった経歴があるため、技術力でキャリアを築いてきた人間だと思われがちです。しかし実は、エンジニアの中では相対的に高めなヒューマンスキルを武器にしてきた自覚があります。

強みとしては、営業等を含めたさまざまな経験であり、情報収集能力をベースに状況を俯瞰して直感的に判断する力、エンパシースキルと言語化能力、周囲をメッセージでモチベートするリーダーシップなどです。一方、業界に入ったのが30歳前後と遅く、叩き上げ的に現場の技術を身に付けてきただけなのでコンピューターサイエンスの基礎力に欠け、そして英語もそれほど得意ではないことが弱みです。

もちろん技術力の定義は難しく、全般的な問題解決能力だと考えれば、自分はそんなに悪くないレベルにあるでしょう。ただし技術力を、純粋な技術的スキルだけで課題をねじ伏せる腕力のようなものだと考えるなら、自分が逆立ちしても敵わないレベルの多くのハッカーを目の当たりにしてきました。その独自の武器ともいえる技術があったからこそ問題を解決できた、といったあり方には憧れがあります。

そもそもWeb業界に入ったのもハッカーに対する憧れからです。Web 2.0の時代、私は傍観者でした。同年代のハッカーが技術でイノベーションを起こしていることに羨望の眼差しを向けていたのです。そしてハッカー的なスキルを身に付けずとも、器用な立ち回りで生き残ってしまった。それもひとつの術だと割り切ってはいますが、技術力だけで勝負できないことにどこか負い目を感じてもきたのも事実です。

この記事では、そんな私がどのようにキャリアを進めてきたのかを紹介します。ハッカーに憧れた原体験を大事にしたいという気持ちは、今でも強く持っています。

OSSを通じてハッカーとステークホルダーが協調する
OSSを引き継ぐ・プロダクトを引き継ぐ・事業を引き継ぐ
挫折して次のステップへと螺旋に変化し続けるキャリア
ともに切磋琢磨できるエンジニアが増えてほしい

OSSを通じてハッカーとステークホルダーが協調する

2011年に30歳でカヤックに入社したのが、自分のキャリアの本格的なスタートです。カヤックではリードエンジニアを任され、新規プロジェクトのミドルウェアやライブラリを選定したり自作したりしました。リードを任せられる経緯などは以前の記事で書いていますが、現在でいう技術選定やアーキテクトのような仕事を担っていたわけです。

カヤックには多くの優秀なエンジニアが在籍しており、業務上のソフトウェア開発だけではなく、対外発信にも積極的でした。業務上のコードの一部を抽象化してOSSとして公開したり、業務時間外で学んだノウハウや趣味的に作ったOSSを社内に導入したりしつつ、さらにその成果を対外発信するというサイクルを自然に回していたのです。それが会社の文化であり、私にもそういった動き方が求められました。

現在の私は、GitHub上で200を超えるOSSを公開しています。既存のOSSに対してもこれまで1,000件近いプルリクエストを送り、取り込んでもらいました。そのため「OSSが趣味だ」と嘯（うそぶ）いていますが、その多くは業務上の必要に駆られて開発したものです。それも小さなツールやライブラリが多く、言うなれば現場志向のOSS活動をしてきました。例えば、社内で横断的に導入したい仕組みをOSSにしておくと、エコシステムのツールチェインに乗れるので結果的に社内への浸透も速かったりするのです。

既存のOSSに多く貢献しているのも、業務で使うOSSの開発に主体的に関わることでより活用できると考えるからです。例えば、新たにOSSの採用を検討するときには、まず試しに触ってみたりドキュメントやソースコードを読んだりしますが、可能なら次にプルリクエストを送ってみます。ソフトウェアには細かいバグがあるものですし、自分たちのユースケースがエッジケースとして見落とされていればパッチで機能追加を提案します。

その反応から、協調可能なOSSかどうかを探ります。メンテナンスはアクティブなのか、実装ポリシーがマッチしているか、意見を取り入れてもらえたり開発に協力できたりするか。相性がよさそうなら採用しますし、そうでなければ有名なOSSであっても見送ることがあります。突き詰めれば、ソフトウェア開発も人と人との世界であり、OSSのエコシステムでも作者と貢献者と利用者といったステークホルダー間の協調が重要です。

OSSの世界では、個性豊かなハッカーたちがそれぞれの流儀を持ちながら、実は協調しているところが魅力的で、面白いのです。インターネットの基本精神とされる「自律・分散・協調」に通ずるものがあります。それぞれが幸せになる方法を考え、コミュニティの力をうまく借りつつ還元できた人が、OSSを一番うまく活用できるのです。

OSSを引き継ぐ・プロダクトを引き継ぐ・事業を引き継ぐ

OSSのメンテナンスは、プロダクトマネジメントでもあります。

実現したいことを明確にすること。さまざまな人から送られてくる直接のフィードバックを参考に機能を追加すること。逆に不必要な機能提案にはノーと言うこと。環境の変化に適応する、具体的には周辺ソフトウェアのバージョンアップやエコシステムの変化に追随していくこと。そういった変化を通して自分の意見やスタンスも変化させ、実現したいビジョンを再定義していくこと。これらは正しくプロダクトマネジメントのサイクルそのものです。

OSSとはいえ一定のオーナーシップがあり、決断することも必要です。最初のうちはそれが嫌だと感じることもあるでしょう。心理的負荷がかかることもあります。しかし、さまざまな思惑が交錯する複雑な状況下で決断のサイクルを回すことは、成長につながる得難い経験です。しかも事業のリスクを取らず、誰でもすぐに小さく始めることができます。業務上のステークホルダーもそれほど存在しないためハッキリと発言でき、かける労力も自由に判断できます。いざとなれば誰かに移譲することもできます。

実は私も数十のメンテナンスを引き継いできました。中にはghqのように2,000スターを超えるOSSもあります。片や私のプロダクトは、100スターを超えるものがいくつかあるくらいです。自力で生み出せないソフトウェアをメンテナンスできるのは、嬉（うれ）しいことです。むしろ私は、新たに生み出すことよりも引き継いで伸ばしていくことが得意だと気付かされ、そこに面白みを感じるようになりました。

このようにプロダクトマネジメント体験の第一歩として、OSSのメンテナンスはオススメです。エンジニアは「プログラマー風林火山」と言われるように特性の違いがあり、補完しあってよりよいものが作られる。そこにモノづくりの面白さがあります。私もこうして自分の特性を自覚できたことで、OSSだけでなく業務上のプロダクトや事業を引き継ぐ機会にも恵まれました。例えば、はてなのMackerelです。

Mackerelはクラウド監視のSaaSです。リリース当初からかかわっていましたが、事業を立ち上げた役員が退職することになり、プロダクトマネージャーを引き継ぎました。エンジニア向けのプロダクトなのでユーザーのペルソナが自分と近く、SREや信頼性といった志向にもマッチしていました。プロダクトの立ち上げから成長期にかけて、関連するOSSのメンテナンスやコミュニティマネジメントまで含めて業務としてかかわれたことは、なかなか得難い経験になりました。

その後、スタートアップのNatureでCTOを務めることになりますが、これも前任のCTOに請われたものです。前任者は0を1にすることが得意で、私が尊敬するエンジニアでした。1を10にするフェーズは私が得意だということを評価してくれた上での要請だったので、意気に感じて引き継いだのです。

挫折して次のステップへと螺旋に変化し続けるキャリア

カヤックから10年、前節のように自分なりのアクションとそれに伴って訪れた機会をうまく掴みながら、私はリードエンジニアからプロダクトマネージャー、CTOへと順調にキャリアを歩んできました。

しかし、冒頭に述べた「ハッカーになりたい」という原体験に対しては、何かしら燻（くすぶ）っている思いがありました。当時はマネージャーとしての力不足にも悩んでおり、組織が自分の能力で律速されてしまうことに心苦しさを感じていました。また、日本の狭いコミュティでしか通用しない人材で終わってしまう危機感も感じていました。

よく私は「変化は常に正しい」と言います。変化して、早くフィードバックを得て、また変化する。この繰り返しが個人にせよ事業にせよ、一番速く成長できるからです。そしてこれは、保守的な自分に言い聞かせる言葉でもあります。以前の記事に書いた通り、私は保守的で安定を望む一方で、未来が予想できない方が楽しいという感覚もあります。自分に刺激を与えるため、敢えてノイズを混ぜるような極端な選択をすることもあります。結果として選択に後悔しないよう行動すればよいと考えています。

そんな折、川口耕介さんが立ち上げたLaunchableという西海岸のテックスタートアップに魅力を感じ、ICとして転職することを決めました。エンジニアとして自分を鍛え直し、一段階上に行くためにフィットした環境だと感じたからです。ちなみにLaunchableの面接を受ける前に、彼らのOSSに些細なバグを見つけたのでプルリクエストを送って取り込んでもらいました。採用の合否への影響は些細なものだと思いますが、私がどのようにOSSに貢献するかを示すエピソードとして気に入っています。

同じころ、オブザーバビリティ企業のHoneycombのCTOで『オブザーバビリティ・エンジニアリング』の著者でもあるCharity Majorsさんが2017年に書いた「The Engineer/Manager Pendulum」というブログ記事を知ります。テック業界の優れたリーダーとして、エンジニアとマネージャー両方を振り子（pendulum）のように行き来するキャリアサイクルを推奨する記事で、マネージャーからプレイヤーに戻ろうとする自分の状況もあって感銘を受けました。

振り子といえば、和田卓人さんがデブサミ2018における「技術選定の審美眼」という発表で「技術の変化の歴史は一見すると振り子に見えるが、実は螺旋（らせん）構造で同じところには戻ってこない」と語っています。この「一見すると振り子だが実は螺旋構造」という考え方は、前述した「振り子のキャリア」にも言えることです。私もエンジニアとマネージャーの間でさまざまな点を巡ってきたので、自分のあり方としてよりフィットする「螺旋のキャリア」を意識するようになりました。

その後、残念ながらLaunchableは1年そこそこで退職することになります。これは、人生最大の挫折とも言える経験でした。40歳を超えてここまで大きな挫折を体験できることはなかなかないとは思うので、前向きに捉えようとしていますが、やはりショックを引きずっている部分もあります。

幸い次の職はすぐに決まり、現在はヘンリーという医療系のスタートアップで次のチャレンジを始めています。入社当初はコードを書いていましたが、今はマネジメントやエンジニア採用を任されています。これもまた、螺旋が次の段階に巡ったということでしょう。

ともに切磋琢磨できるエンジニアが増えてほしい

私のキャリアについて書いてきましたが、最近はソフトウェアエンジニアが魅力的な職業だと見なされはじめ、若く優秀な人がどんどん参入してくるようになりました。なりたい職業の上位にITエンジニアが名を連ねるようになり（2023年7月発表のソニー生命保険による調査など）、大学の情報系学部の人気も高まっています。優秀な若者が参入してくる業界には未来があります。

私の周囲にいる10代・20代のエンジニアも恐ろしいほど優秀な方ばかりで、自分が同じ年齢だった頃と比べると雲泥の差です。それは知の高速道路の整備が進んでキャッチアップがしやすくなったことの証左でもあり、人類の進歩の結果です。総じて非常に嬉しいことです。

一方、私が螺旋のキャリアで時間をかけて積み上げてきた経験にも、価値があると思っています。経験に基づく直観力や決断力で勝るのがベテランの戦い方でしょう。それぞれが異なる強みを生かしながら、同じ土俵で切磋琢磨し続けたい。私もまだまだ研鑽できるし、若い人に置いていかれることなく一緒に長く戦えると思っています。成長する喜びを分かち合う仲間として、エンジニアが増えてほしいと願っています。

編集・制作：はてな編集部