シェア
はてブ
初めまして。丸山しんぺい（@shinpei0213）です。Classi株式会社で、VPoT（Vice President of Technology）という役職に就いています。技術部門の責任者として、Classiという会社がソフトウェアの力で教育をよりよくしていけるようなあれこれについて、技術の視点からグランドデザインを描き、そのグランドデザインを達成することに責務を負っています。
今回、キャリアとその選択について書く機会をいただいたため、あらためて自分のキャリアを振り返ってみると「スペシャリストとして成長した先に、技術の責任者があった」となりそうです。それが正しいとも、誰でも参考になるとも思っていませんが、それでもソフトウェア・エンジニアは比較的新しい職種であり、再現性の高いキャリアパスもまだまだ整備されていない世界だからこそ、誰かが振り返ったキャリアが他の誰かのヒントになることがあるかもしれないと考え、自分の経験をひとつの事例としてアウトプットしてみようと思います。それが偶然、誰かにとって参考になってくれれば幸いです。
- 哲学を学んだわたしがソフトウェア開発のスペシャリストに
- 仕事の技術的な成果をもってコミュニティに飛び込んだ
- コミュニティの切磋琢磨でエンジニアの強みと位置を知る
- なぜ以前に失敗した技術の責任者に再びなろうとしたのか
- 自分を構成する要素をターニングポイントから分解してみる
- 人との関わりの中で学ぶために
哲学を学んだわたしがソフトウェア開発のスペシャリストに
わたしは今でこそソフトウェア・エンジニアリングの世界で活動していますが、実は学部時代には文学部で哲学を学んでおり、大学では情報工学とまったく無縁の生活を送っていました。
文学部というのは本当に就職先がないことで有名ですが、幸いにも趣味でプログラミングを多少たしなんでいたこともあり、「まあ自分ひとり食うに困らない程度にはなんとかなるんじゃないかな」くらいの軽い気持ちでプログラミングの仕事を探したところ、なんとかコードを書いてお金をいただく職に就くことができました。そしてこれが、わたしのソフトウェア・エンジニアというお仕事の第一歩になりました。
なんでも屋のフリーランスからテックリードそして開発組織の責任者に
それから数社を経験したのち、フリーランスのソフトウェア・エンジニアとしてRailsを中心にインフラからDB周り、フロントエンドの開発まで「なんでも屋」的に活動していました。そして、当時の友人にたまたま誘われ、ふたり目のエンジニアとして前職に入社してからは、フリーランスではなく社員としての働き方を続けています。
前職では、最終的に開発組織の責任者に従事させてもらっていましたが、いちエンジニアとして働きたくなり、現職に転職。テックリードを経て、現在は自分のキャリアの中で2度目となる技術責任者をやっております。
ざっと振り返ってみても「何がしたいのかよく分からん経歴」といった趣で、エンジニアリングのスペシャリストやりたいのか、それとも責任者やりたいのか、どっちやねん？ という感じですが、だからこそ言えることがあるとも思っており、自分がどういうターニングポイントを経て、ソフトウェア開発のスペシャリストとしてどういう成長をしてきて、今また直接ソフトウェア開発をするわけではないVPoTという役職に就いている理由などを、ここでは語っていきたいと思います。
ソフトウェア・エンジニアリングに楽しみを覚えたきっかけ
大学で哲学を学んでいたわたしにとって、最初のターニングポイントは当然ながらソフトウェア・エンジニアという職種を選び、そしてはまり込んでいったことです。
もともと趣味でプログラミングを多少たしなんではいたのですが、その当時は「自分が作ったりいじったりしたものが動くことが面白い」くらいの感覚でしかなかったことをよく覚えています。前述したように「軽い気持ち」でソフトウェア・エンジニアとして第一歩を踏み出したわけですが、実際にこれをお仕事にしてみると、「ただ動くのが面白い」ということはまったく異なるレベルで、そこに面白さが横たわっていることに気付くことになりました。
自分ひとりで作って動かすだけならば、保守性について気にすることも、運用について気にすることも、そこまで必要になりません。一方、仕事となると、自分が思いもしない変更が必要となったり、後続の誰かが変更しやすいコードである必要があったり、運用していく中で問題が起こりにくい状態にしておく必要があったりします。
そういった要請を満たすには、ソフトウェア設計やシステム設計が非常に重要になってきます。設計というのは、混沌とした現実に対して、問題意識に応じて秩序と構造を与えることです。その中でもソフトウェア設計の場合、秩序と構造を与えるために概念を駆使することが重要です。
そう理解したとき、わたしは「軽い気持ちで始めたものだけど、これは哲学に似た部分があるし、めちゃめちゃに面白い仕事だぞ」と気付き、より自覚的にソフトウェア・エンジニアリングと向き合うようになりました。
仕事の技術的な成果をもってコミュニティに飛び込んだ
自覚的に向き合うようになった結果、ソフトウェア設計についてさまざまな書籍や雑誌で学んでいったのですが、そこで知ったのが、ソフトウェア・エンジニアが自助的に作り上げてきたコミュニティの数々でした。
特に当時のPerlコミュニティの勢いはすごくて、プロダクトだけでなく、プロダクトを作るためのプロダクトが次々と生み出される熱量がありました。コミュニティで活躍しているエンジニアたちが、新しい技術をどんどん作り上げていく。その様子を憧れをもって見上げていましたし、「自分とは違う、すごい人たち」の世界だと感じていたことをよく覚えています。
技術的なチャレンジに初めて自分で解決構造を与えることができた
ちょうどその頃、技術的にチャレンジングな仕事にぶち当たりました。スマートフォン同士でリアルタイム通信をするメッセージブローカーを開発するという仕事です。
今でこそWebSocketやSSE（Server-Sent Events）などでリアルタイム通知やリアルタイムチャットは当たり前になっていますが、当時はまだ標準的な通信方法がなかったり、ライブラリが充実していなかったり、回線が貧弱だったりということもあり、自分でバイナリプロトコルから策定し、双方向のリアルタイム通信を低コストで行うサーバーを、Perlを用いて開発することになりました。
この仕事は、自分にとってふたつの意味でターニングポイントになっています。
まずひとつは、技術的な面。この仕事は今から考えると幼稚な部分がとても多く、スケーラビリティやメンテナビリティにも問題を抱えてはいたのですが、とはいえ先人のやってきたことをなぞっただけの仕事ではなく、先人の智恵を用いながら新しい試みをしたという点で、既に定まったベストプラクティスではない、課題に対する新しい解決構造を初めて自分で与えることができた仕事だったと思います。
エンジニアリングが好きならコミュニティは新参者を受け入れてくれる
もうひとつが、コミュニティへの参加です。上述のようにベストプラクティスを単になぞったものではなかったため、「これは勉強会で発表できるかもしれない」と思い始めました。とはいえ当時のわたしにとって、そこは「自分とは格の違う、憧れの人たちが集う場所」でした。
「これはもしかすると発表する価値があるかもしれない」という思いと「でも自分は、あの世界の住人と比べるとレベルが低過ぎる」という思いに引き裂かれ、ぐるぐると思い悩んでいたわたしを見て、そのとき所属していた会社の代表が「もう業務として命令するけど、勉強会に行ってきな」と背中を押してくれたことをきっかけに、Yokohama.pmという勉強会で初めて登壇させてもらいました。
今から思い返すと内容は稚拙で、顔から火が出る思いなのですが、その稚拙なわたしの発表に対して、懇親会で憧れのハッカーたちがたくさん質問やアドバイスをしてくれました。
そこでわたしは、「ソフトウェア・エンジニアリングが好きで、そこに対して工夫をしていて、先人たちの智恵に敬意を持ってさえいれば、今のレベルがどうであろうと、コミュニティは新参者を受け入れてくれる」と実感し、その後は安心してコミュニティに参加することが可能になりました。
コミュニティの切磋琢磨でエンジニアの強みと位置を知る
その後、わたしはPerlコミュニティを中心に、小さな勉強会から大きなカンファレンスまで積極的に参加し、その縁もあって『WEB+DB PRESS』や『Software Design』といった雑誌で特集記事を書かせてもらったり、ソフトウェア・エンジニアとしてものすごく能力の高い友人たちを得ることとなりました。今この記事を書いているのも、この縁が回り回っていただいた機会だと思っています。
自分がコミュニティ活動の中で何を経て、どういう変化があったのかをあらためて振り返ってみると、大きなトピックがふたつあるなあ、と思います。
発表へのフィードバックで底上げされるエンジニアとしての能力
ひとつは、エンジニアとしての能力を底上げしてもらえたという話です。「自分はこういう考え方で設計をしているよ」という話だとか、「こういう問題にぶちあたって、それをこういう考え方で解決したよ」という発表をすることで、コミュニティのみんなからフィードバックを得ることができました。
これは、自分のエンジニアとしての実力を、ひとりで学ぶより何倍も効率よく引き上げてくれたと実感しています。
強いひとに特定の技術ではかなわないが別の強みが自分にはある
もうひとつは、他人の強みと自分の強みを客観視する視点が得られたことです。
コミュニティの中では、さまざまな得意分野を持ったエンジニアが議論し、切磋琢磨しています。その相互作用の中で、わたしは「何か特定の技術に対して深く深く掘っていくような部分に関して、自分は強い人にどうしてもかなわない」ということを実感しました。他人のスペシャリストの強みを実感した、ということです。
一方で、そのようなすごい人と比べても、自分は「混沌に対して概念を整理し、秩序を与え、言語化して他人に伝える」という部分については、他の人に負けない強みを持っていることも実感できました。
能力を底上げしてもらえたからこそ分かる強い他人
このふたつのトピックには、非常に高い関連があると思います。というのは、自分以外のスペシャリストがどれだけ高いスペシャリティを持っているかを理解するには、自分自身もその分野についてそれなりに深く理解している必要があるからです。
例えば音楽の世界でも、楽器がうまくなればなるほど、トップレベルのプレイヤーがいかに化け物であるかを解像度高く理解できるということがあります。他人のスペシャリティを解像度高く理解するには、それが分かるだけの能力が自分にも必要になるわけです。
わたしは、コミュニティでの切磋琢磨により自分のベースラインを引き上げてもらったおかげで、周りのすごさを「ただ憧れていた頃」より解像度高く理解できるようになり、同じように自分の強みに対して自信を持つことができるようにもなりました。
なぜ以前に失敗した技術の責任者に再びなろうとしたのか
さて、話題をコミュニティでの切磋琢磨から、仕事の話に戻します。わたしは前職で技術の責任者になりましたが、なぜ技術のスペシャリストではなく責任者を引き受けたのかという話をします。これは、わたしがコミュニティから得たことと無関係ではありません。
他人の強みが分かるからこそ自分は構造を考える人になるべき
先ほど振り返ったように、わたしはコミュニティ活動を通じて、他人の強みを高い解像度で理解することができるようになりました。ふたりめのエンジニアとして入社した前職でもその後の採用がうまくいき、自分よりスペシャリティの高いエンジニアが入ってきてくれました。
このとき自分が何をすべきかを考えると、自分よりスペシャリティが高い人がいるならそこは任せて、自分の強みでもあるもう少し抽象度の高いレイヤーで、問題に対して解決となる構造を与え、それを言語化して周りのステークホルダーに伝えて構造を変えていくような仕事をすべきだ、と思うようになったという背景があります。
この判断は、他人の強みと自分の強みの両方を理解するという、コミュニティで培われた力なしには、なし得なかったと思います。
ただし前職を振り返ってみると、その役割を果たし切れたとは思えません。自分ができる精一杯をやったとは胸を張って言うことができますが、それが成果につながったかといえば、おそらく良い評価を得られる成果を出せてはいないでしょう。これは特に、自分がピープルマネジメントを非常に苦手していることがかなり足を引っ張ってしまったなあ、と今では思っています。
自分の弱みも理解してより強みを生かせる仕事を担う
その結果、あらためていちエンジニアとしてやっていこうと考えて現職に転職したわけですが、結局は今また技術の責任者をやっています。
なぜまた責任者をやっているのかといえば、ひとつには前職と同じ理路で、現職でも自分より能力の高いエンジニアがたくさんいて、自分はその人たちの能力の高さを理解することができるし、自分の強みも理解していて、それならば全体最適のために他人の強みも自分の強みも生かせる選択をすべき、と思っているところがあります。
もうひとつには、自分が苦手とするピープルマネジメントを別に担う人（VPoE、Vice President of Engineer）が今はいるから、という理由があります。実際、ピープルマネジメントの面でわたしは現職でまったく役に立っていませんし、何の仕事も担っていません。
その代わり、今の会社がソフトウェアの力で教育をよりよくするため、技術的に何をしなければならないかという課題に対して、概念を整理し、構造と秩序ある状態にするために設計し、それを言語化し、全社を巻き込んだコミュニケーションなどに全振りした仕事ができています。
自分を構成する要素をターニングポイントから分解してみる
さて、これまでのキャリアをターニングポイントとともに振り返ってきましたが、自分の強みと弱み、そして他人の強みを見つけて理解することが今の選択を作っているのだな、という結論になりそうです。
そして自分の場合、そういった強みや弱みを見つけて理解するために、仕事以外の場で大きく寄与してくれたのはコミュニティだった、ということが言えそうです。
他人の力を解像度高く理解するには自分にも相応の力が必要であることは前述した通りですが、そもそも自分はその力をコミュニティ活動の中で身に付けてきました。自分の強みを見つけたことも、さまざまなスペシャリストが集うコミュニティで議論する中で、自分の位置を冷静に見ることができるようになったという面が大きいです。
また、さまざまな強みを持った人たちがコミュニティの中で相補的に動くことで、よりよい結果が生まれるということも見ることができ、「全部において自分が一番強くなくてもいいんだ」ということも学べました。
人生は9割が運と縁だけど……
わたしはよく「人生9割運と縁」と言うのですが、実際に自分が今の選択に至ったのも、コミュニティにおける運と縁によって、自分の強みと相手の強み両方を理解し、尊重することを学んだから、ということが大きいと思います。
とはいえ、当然その9割の運と縁を支える行動というものもあると思っています。わたしのような凡人が、運と縁を味方に付けるためにやっていることを最後にお伝えして、この記事のまとめとさせてください。
人との関わりの中で学ぶために
運と縁は、人との関わりがなければ発生しません。何よりもまず、人と関わる必要があります。そのためには当然ですが、「一歩踏み出す勇気」が前提になります。
「そんなこと言われても、そもそも最初から踏み出す勇気があれば苦労しないわけで……」という話もよく分かります。実際、前述しましたが、わたしも初めて勉強会に登壇するときは「自分なんかが入っていいのだろうか」とかなり思い悩みました。当時の会社の代表が背中を押してくれたから一歩が踏み出せただけで、初めての発表当日は怖くて怖くて、何度もトイレで吐いていました。とてもじゃないけど、ひとりで一歩目を踏み出せたとは思えません。
わたしのような凡人は、一歩踏み出す勇気を出すことよりも、踏み出すために背中を押してくれる誰かを大切にするように心がけています。今の会社で「責任者をやってくれないか」という話があったときも、周りを見渡すと、一度失敗していることに再チャレンジする背中を押してくれる人だらけだと気付きました。その期待に応えたいという思いがなければ、再度のチャレンジはできなかったと思います。
あなたにしか言えないことを発信しよう
切磋琢磨できる場所に踏み出した後には、自分から積極的に発信することも必要です。特に凡人ほど、その必要があると思っています。なぜなら、発信は議論の「ネタ振り」になるからです。何もしなくても議論に参加できる強者ならば苦労しないわけで、凡人は議論のネタを提供して初めて議論に参加できます。自分から積極的に発信することも、運と縁を味方に付けるために重要だと思っています。
発信する際に、凡人はどういうネタを選べばいいのでしょうか。わたしは「自分にしか言えないこと」ならば何でもいいと思っています。例えば「この本にこういうことが書いてありました」という情報は自分でなくても発信できます。というより、その本を読めばいいだけです。
一方で、「こういう本を読んで、こういう実践をした結果、自分にとっては新しいこういう発見がありました」という情報は、自分にしか発信できません。同じ「本に書いてあった情報」が出発点でも、そこにあなたの経験と考えが入ってくれば、それはあなたにしか言えないことです。弊社で一緒に働いてくれているlacolacoさんのブログにも近い内容の記事がありますので、ぜひ参照してください。
「自分にしか言えないこと」を発信し、別の視点を持った人と議論する中で、自分と他人の視点を比べることが可能になります。そうやって自分の視点は引き上げられ、他人の強みを高いレベルで理解することができるようになり、自分だけの強みが見付かる。そしてまた、あなたにしか言えないことのレベルが上がっていく、という良い循環が生まれるとわたしは考えています。
自分だけの力ではなく運と縁を味方に
わたしは、自分の力だけで自分や他人の強みを見付けられる強者ではなく、運と縁を味方に付けて初めて強みが理解できる凡人です。ただ、そんな凡人が大きな責任を任せてもらえる立場に今いるのはなぜなのか。そして、そんな凡人が何を大切にしているのか、ということをお伝えしてきました。
まだまだ未成熟で再現性のあるキャリアパスが整備されていないこの業界において、いち凡人の経験がどこかで誰かのプラスになることがあれば幸いです。
編集：はてな編集部
丸山 晋平
1984年2月生まれ。中学生のころから趣味でWebサイトの構築などを行う。文学部を卒業後、2006年にWebプログラマーとして仕事を初め、何度かの転職を経て、現在はClassi株式会社でVPoTを務める。
しんぺい a.k.a 猫型蓄音機 / 猫型の蓄音機は1分間に45回にゃあと鳴く
