ソフトウェア開発を楽しもう。SIerや事業会社、技術コミュニティでの経験で変化していった私のキャリア観

HRテックサービスを提供するカオナビでCTOを務める松下雅和（@matsukaz）さん。R&DやSI、メガベンチャー、スタートアップ、事業会社とITのさまざまな業態で経験を積み、複数のポジションを体験したことで、ソフトウェアエンジニアとして働く上で大切なことを実感してきました。

若い頃にはボトムアップでチーム改善を進めようとしてうまくいかなかった経験もありますが、技術を学ぶ楽しさ・チームで働く楽しさ・プロダクトを世に送り出す楽しさ、そういったソフトウェア開発の世界にあるさまざまな「楽しさ」こそが、コミュニティを含む活動のエネルギーになっています。

以前とは違って組織や開発プロセスの改善をトップダウンで進める役職にある現在、ボトムアップでの挑戦や楽しさドリブンで働いてきたことがどのように生きているのか。松下さんのキャリアを振り返りながら、エンジニアとして技術やプロダクト、チームや組織とどのように向き合うべきかを伺いました。

新卒エンジニアが出会ったロールモデルと技術的な目標
ボトムアップで取り組んだ改善がうまくいかない理由
コミュニティのマインドから周囲を巻き込む取り組みに
プロダクトとチームへの興味が高じてスタートアップへ
積極的なアウトプットと改善の提案を

新卒エンジニアが出会ったロールモデルと技術的な目標

── 松下さんの現在の職務について教えていただけますか。

松下　株式会社カオナビでCTOを務めています。会社全体の技術的な課題の「見える化」や解消に向けた方針決め、開発の流れに対して優先度をどうするべきかを考えたりする役割です。開発生産性の向上にも取り組んでいますし、採用にも関わっています。

またCTO室を編成して、その室長も兼務しています。CTO室は技術課題に対して、より横断的に取り組む部署です。フロントエンドやバックエンドなどに特化したメンバーがそろっており、自分たちで行動することもあれば、方針を打ち出して現場を巻き込んでいくこともあります。おそらく社内でも一番いろいろなチームとコミュニケーションをとっている部署ではないでしょうか。

▲ カオナビのCTOに就任して2年半がたった頃のオフィスでフロントエンドのテックリード（右）と

── ありがとうございます。それでは松下さん自身のキャリアを振り返っていきますが、そもそもエンジニアを志したきっかけはなんだったのでしょうか。

松下　エンジニアとして働くようになったのは大学を卒業した2001年からですが、もともと情報科学研究というゼミにいて、物事と情報を結びつけて考える研究を行っていました。そのゼミで、ホームページの運用程度ですがサーバを所有していたんです。

その管理をゼミ生が代々引き継いでいて、私は当時からパソコンがすごく好きでインターネットでチャットしたりホームページを作ったりしていたこともあって、サーバ管理者の仕事を任されました。そこで、今でいうインフラエンジニアのような経験をしたことがきっかけになっています。

── 当初はソフトウェア開発よりインフラに興味を持たれていたんですね。

松下　はい。最初はインフラの中でもネットワークに興味があって、ネットワークエンジニアを目指していたんですが、新卒研修を受けているうちにプログラミングが楽しくなり、ソフトウェアエンジニアに切り替えました。配属になったのは研究開発部門、いわゆるR&Dです。

当時はJavaを使用したWebアプリケーション開発がはやりはじめた頃で、私が働いていた会社でも社内フレームワークの開発がスタートしていました。先輩と一緒にフレームワークを開発し、社内への展開や、フレームワークを利用したプロジェクトを支援するといった業務を行っていました。

── 最初の会社は、一般的に社会人のキャリアで大きな意味を持つことがありますが、松下さんにとって1社目はどういった職場でしたか。

松下　とても大きな出会いがありました。当時の先輩で、社内で一番の技術力を持ち、どんなときも嫌な顔をせず、最善の選択肢を導き出していました。人柄も素晴らしく、頼りにされていて、今でも「あの人ならどう判断するだろう？」と考えることがよくあります。自分にとってエンジニアのロールモデルと呼ぶべき先輩で、いろいろなものを学びました。

── そして5年目の2005年に転職されました。きっかけは何だったのでしょうか。

松下　もともと技術に対して貪欲なところがあり、もっと技術力を高めたい、エンジニアとして成長したいと思っていました。そのため「デブサミ」や「XP祭り」といった外部イベントに参加するようになり、そこでは平鍋健児（@hiranabe）さんや倉貫義人（@kuranuki）さん、米持幸寿（@pandrbox）さん、榊原彰（@AquilaDC）さん、鈴木雄介（@yusuke_arclamp）さんといったそうそうたるメンバーの登壇を目にすることになりました。

そういった方々の発表を見ていると、将来の自分が同じ場所に立って話している姿がとても想像できません。じゃあその違いはなんだろう？そう考えたとき、やはり技術力だろうと思いました。当時の仕事は受託開発がメインだったのですが、開発を他社に依頼することも増えていて、このままでは開発に携われない、技術が伸びないという焦りがありました。

ボトムアップで取り組んだ改善がうまくいかない理由

── 転職先ではどのようなお仕事だったのでしょうか。

松下　転職した企業は「アーキテクト集団」を名乗っており、各プロジェクトに1人はアーキテクトがアサインされていました。私もアーキテクトとして入社し、プロジェクトを成功に導くために開発基盤の整備やアーキテクチャ設計、システム構築などの業務を行っていました。特にお客さんと話すのが得意だったためか、客先に常駐することが多かったですね。

── 働き方が変わったことで、エンジニアとしての興味関心やキャリア観に変化はありましたか。

松下　最初の2、3年は業務系の案件が多く、BtoBの経験を積むことができました。学ぶことも多くて楽しかったですね。その後はBtoCが多くなり、私自身は事業系の会社に常駐することが増えました。

一方、会社では受託開発も行っていて、その案件で炎上する場面がけっこうありました。中には精神的に疲弊して休職される方もいたんですが、当初は「自分にできることはない」「この状況に耐えるしかない」と静観してしまっていました。周囲も半ば諦めのように状況を受け入れていて、自分たちでプロジェクトや会社を改善していこうとは思っていませんでした。

ちょうどその頃、外部の勉強会でDevLOVEという集まりによく参加していました。DevLOVEでは、いろいろな企業のエンジニアが自社のよい取り組みや課題を持ち寄って、情報共有したり意見交換したりしていました。そうした活動を通じて、当事者意識を持って主体的に動くことの大事さを痛感し、現場をより良く変えていきたいと考えたのです。

── 具体的にはどのような改善活動をされたのでしょうか。

松下　私自身が変わったように、みんなのマインドを変えていきたい、一緒に行動してくれる仲間が欲しい。その想いを社内SNSに投稿し、共感してくれた10名ほどのメンバーを集めてワークショップを開催しました。それぞれが感じていた問題意識を持ち寄り、目指すべきエンジニア組織やプロジェクト体制、チーム開発の進め方、何よりどうやったら周りの主体性を引き出せるかをたくさん話しましたね。

こうした取り組みには管理職の方々の協力も不可欠だと考え、上司や他部署のマネージャー、社長にもアプローチして、ミーティングの合間や飲みの席でも話にいって、活動を応援してもらいました。ですが、結局この活動はうまくいきませんでした。

── なぜうまくいかなかったのでしょう。

松下　一番の理由は「変化を望まない人が多かった」ことです。主体的になって今までのやり方や考え方を変えるのはとてもパワーがいることですが、何度かワークショップを続けた中でも「そこまでしたくない」「今のままでも納得のいく働き方ができている」という意見も出てきました。

そういった方はプロジェクトが炎上しても「自分は耐えられるからかまわない。むしろ今のやり方を変えたくない」と考えます。当時の私はよかれと思い、自分の考えで動いていたのですが、「現状のままでいい」方にとっては押し付けに感じられたのだと思います。自分本位になっていた部分もあるし、すごく反省しました。

── こうしていたらよかったと思うことはありますか。

松下　自分自身の働き方で示すことがもっと必要だったと思います。当時の私は常駐が多かったので、なかなか自分の働き方を見せる機会が社内にありませんでした。例えば私自身が受託開発のプロジェクトに入って「こういう考え方や働き方をした方がエンジニアとして楽しいし、成長できるよ」と背中で見せていくべきでした。外部から言葉で伝えるだけでは説得力がなかったと思いますし、何より全然楽しそうに見えていなかったかなと。つらそうな活動では応援する気にはなれないですよね。

コミュニティのマインドから周囲を巻き込む取り組みに

── 先ほどお話にあったDevLOVEについても詳しく教えてください。

松下　ソフトウェアエンジニアの勉強会は当時からたくさんありましたが、中でもDevLOVEは特定の技術には寄らずに、開発を愛する人たちが集まって開発の楽しさを再発見し、広げることを目的としたコミュニティです。DevLOVEのスタッフをしている人が社内にいて、声をかけてもらったのがきっかけとなり、2010年ごろから私もスタッフとして関わっていました。

DevLOVEでは誰かリーダーがいるわけではなくとも、各自が面白そうなネタを持ち寄って、やりたいイベントをやりたいように開催する。そこには主体性と、今まで見たことのない熱量がありました。毎日のように深夜にチャットでミーティングをしたり、多いときには週に3回もイベントを開催していたり、みんな開発の楽しさを体現しているような人たちでした。私自身も活動に参加する中で、そうした「楽しさドリブン」とでもいうべき考え方を学ばせてもらったと思います。

── 逆にそれまでは「楽しさドリブン」ではなかったということでしょうか。

松下　そうですね。どんどん新しい技術が出てきている中で、常にトレンドを追いかけていないとエンジニアとしていつかやっていけなくなるんじゃないか。正直なところ、そういう危機感で動いていました。学ぶことが筋トレのようになっていて、新しい技術に触れても、ワクワクするというより学び続けることが苦しいと思うこともありましたね。

そこから「楽しさドリブン」にマインドチェンジしたことで、技術も純粋に楽しめるようになり、ブログや勉強会で登壇したり、アウトプットとして個人開発にも取り組むようになりました。やがて業務委託ではなく事業会社の一員として自社プロジェクトに関わってみたくなり、サイバーエージェントに転職を決めました。海外向けのゲームや、コミュニティ系のサービス開発に携わることができました。

── 楽しさドリブンは実践できましたか。

松下　はい。まさに自分が求めていた環境でした。エンジニアもみんな楽しそうに仕事をしていて、楽しみながら成長するマインドを持っている人が多かったように思います。技術も進め方も現場で決定してどんどん進めていくカルチャーがあり、そこが面白さでもありました。ただ、大変なことがなかったわけではなくて、働き方としてはかなりハードワークだったと思います。

── そうした環境に身を置くことで、松下さん自身のマインドや活動に変化はありましたか。

松下　より主体的に動いて、積極的に周囲を巻き込むようになりました。自分と同じように中途入社したエンジニアを集めて「中途同期勉強会」を開催したり、社内で開発プロセスがあまり整備されてなかったのでスクラムを広める活動を行ったり。スクラムについては、スクラムマスター研修を受けにいって、社内向けにスクラム勉強会を開催して認知度を高めたりしました。Gitが本格的に社内に広まったのも、私がGitの勉強会を実施したのがきっかけでした。

── そういった「周囲を巻き込む活動」は、まさに以前の会社でやりたかったことですね。

松下　そうですね。以前の自分は「こうあるべき」を押し付けてしまってうまくいかなかったわけですが、サイバーエージェントでは「まず乗っかれる人たちを見つけて一緒に始めよう」というスタンスで活動できました。盛り上がるにつれて参加する人もどんどん増えましたし、活動の範囲も広がりました。

プロダクトとチームへの興味が高じてスタートアップへ

── その後、事業規模がメガベンチャーとはずいぶん違うスタートアップに転職されますが、どういった気持ちの変化があったのでしょうか。

松下　サイバーエージェントは事業会社ということもあり、誰もが自分たちのサービスを成長させることにやりがいを感じていたし、ハードワークなのも納得の上で楽しみながら働いていました。これはそれまで経験した2社のSIerと違った点で、自社サービスならではかもしれません。

そのためチームで開発することや、プロダクトの成否というものをそれまで以上に気にするようになりました。ただ担当していたゲーム領域はかなり競争が激しくて、リリース後に理想の成長曲線が3カ月くらいで描けなければクローズすると判断されることもあり、開発したプロダクトが残っていかないことには厳しさも感じていました。

そのタイミングで、サイバーエージェントの後輩が起業した会社に誘ってくれました。私としても、チームやプロダクトをイチから全て立ち上げる経験をしてみたいと転職を決めました。最初はエンジニアとして入社したのですが、クライアントアプリ以外の全ての領域をカバーする動きをしていたので、それならCTOという立ち位置の方がいいだろうということで途中から就任しました。

── これまでのお話では現場のプレーヤーとして開発に携わりたいという思いを感じますが、CTOともなるとマネジメントが主な仕事になるかと思います。その点はどう考えたのでしょう。

松下　スタートアップの場合は人数規模も小さいですし、CTOといってもチームリーダーくらいの感覚なんですよ。その意味では、現場で普通に手を動かしていましたから、当時はマネジメントらしいことはほとんどしてなかったですね。

── となると本格的なCTOの仕事としては、現在のカオナビに転職されてからになりますね。

松下　スタートアップでも役職としてはCTOを経験したわけですが、他社のCTOの方とはレベルが明らかに違うなと感じていました。経営層の考えや会社組織の動きがもう少し分かる立場で、トップと連携しながら仕事がしてみたいと考えるようになり、エージェント経由で紹介してもらえたのがカオナビでした。

── ボトムアップで改善を提案していた松下さんが、今はトップダウンで改善を実践する役回りに変化したわけですね。

松下　転職時点ではエンジニアとして入社したので、開発もやりながら現場からボトムアップで技術的な課題や組織改善に取り組んでいたんですが、体制を組むにはトップダウンでの判断が必要ですから、経営層と話をしてCTOになりました。今は現場の意見や課題感をしっかりと聞けるように、チームごとにテックリードを配置して、テックリードが集まる毎週の分科会には参加するようにしています。こちらで決めるべきところは決めるので、自分たちで主体的に動けるところは動いてほしいという気持ちです。

── カオナビの事業はHRテックということで、事業領域もこれまでのキャリアとはまた違いますね。

松下　当時、世の中にいろいろなSaaS事業が誕生していて、自分としてもSaaS事業が面白そうだと感じていました。

積極的なアウトプットと改善の提案を

── 最後に、エンジニアとして技術的に成長したくて最初の転職を決めた松下さんですが、この20年でそういった若手エンジニアをめぐる環境の変化を感じることはありますか。

松下　現在はYouTubeやオンラインスクールなど学習コンテンツもたくさんあって、技術力を高めたいなら自分でどんどん学べる時代になりました。若手エンジニアを見ていても、インプットをすごくしっかりしている印象です。ただ、アウトプットについてはインプットと比較すると弱いように感じるので、もっと手を動かして自分なりのアウトプットを出していくことを意識するといいんじゃないかと思います。

── かつてボトムアップで悩んでいた自分と比べてどうでしょう。

松下　私が若手だった頃、会社というものは組織がしっかり決められた状態になっていて、その枠内でしかやれることがないんじゃないかと思っていました。知らず知らず自分の領域を狭めていたところがあったんです。

やはりエンジニアがやりたいこと・うまくいくんじゃないかということを自分たちで提案するのは良いことだし、改善したいことがあればもっと出した方がいいですよね。カオナビでも、もっと自分たちはこういうことがやりたいとか、こういうやり方をすればうまくいくんじゃないかとか、アイデアをどんどん提案できる組織にしていきたいです。

松下雅和さん近影

取材・構成：山田井ユウキ（@cafewriter）
編集・制作：はてな編集部