SHIBUYAにて開催しました。ついて幅広くお話しました。本記事では当日のイベントの様子を一部ご紹介します。プログラマとしてGoogleや株式会社はてなでインターンを経験し、在学中の2011年にプログラマのための技術情報共有サービス「Qiita」をリリース。大学卒業後の2012年2月に、Incrementsを設立し代表取締役社長に就任。プログラマ出身の経営者として、プログラマが成果を出しやすい環境や自立した組織づくりを推進。2017”に選出される。Jobs」をリリース。執行役員)1974年岐阜県生まれ。システムの基盤技術開発に従事。2000年、株式会社ネクスト(現LIFULL)へ転職し、Webエンジニアとしてサービス開発、事業運営に関わる。2009年、エイチームへ入社。現在は、グループ会社であるエイチーム引越し侍及びエイチームコネクトの技術統括の他、管理部門系の責任者としても会社運営に携わる。エイチームグループ全体のエンジニア採用も担う。執行役員)1978年大阪府生まれ。大学在学中の1998年に個人事業主としてWebサービス開発に従事。大学中退後にサーバホスティング事業を経験し、2007年にエイチームへ入社。その後ラルーン事業、エンターテインメント事業本部のメディアサービス事業を経て、2017年にエイチームライフスタイルの執行役員に就任。現在は、エイチームライフスタイルにおけるエンジニアの組織作りに加え、デザイン組織の立ち上げやマネジメント行いながら、エイチームのEC事業本部のエンジニア組織のマネジメントを担うなど、活躍は多岐にわたる。Incrementsのエイチームグループ入りとその後M&Aをしてから、公の場でお話しするのは初めてですね。M&Aのキッカケは何だったんですか?海野:2016年頃、Incrementsが組織的に不安定な時期がありました。「Qiita」や「Qiita:Team」は多くのユーザー様にご利用いただき、ユーザー数自体は好調に伸びていた時期でしたが、組織として課題が多く、マネタイズも上手くできていなかった。Incrementsの2016年12月期(2016年3月~12月)における営業損失は8,000万円くらい。サービス規模が大きくなり、着実に成長しているものの、稼ぐ力が私たちには弱かった。サービスを存続させる上で、お金を稼がないと継続もできないし、新たな挑戦のための投資もできない。Incrementsが倒産する...という感じではありませんでしたが、しっかり稼いで、投資して、より良いサービスをつくるために、事業をスピーディに成長させていける会社と一緒に組みたいと思っていました。会社を選ぶときに重視したポイントは3点です。事業をグロースさせることができる新たな事業を一緒に創ることができる教育や育成など、人に対するサポートができるIncrementsは「エンジニアを最高に幸せにする」というミッションのもと、月間700万のユーザー様にご利用いただく「Qiita」を運営しています。そのため、事業を共に伸ばし合う共同体として、サービスを一緒にグロースさせたいという熱い想いを持っている会社が良いと考えていました。何社か候補を出して、最終的にエイチームグループ入りを決めました。M&Aはどのような流れで進んだんですか?エイチームを選んだ観点を教えてください。海野:M&Aにおける助言業務を行うファイナンシャル・アドバイザーに、Incrementsと相性が良さそうな会社をリストアップしてもらいました。M&Aの候補として挙がった企業には、社名やサービス名は明かさず匿名で伝えていましたが、事業内容が「国内最大級の技術情報共有サイトを運営」となっているため、みなさんお察しされていたでしょうね(笑)何社かと面談をして、将来の方向性がマッチするかどうかなど、そして価格の交渉を行いました。M&Aの目的は、Incrementsの事業を伸ばすためのグループ入り。事業を継続的にグロースさせることのできるノウハウや経験があること、そして相性は良いか、人の面でのサポートが受けられるか、このような観点で検討していました。Incrementsは外部の投資家より資金を投資してもらって事業を運営していました。そのため、M&A後に投資のリターンがあるかどうかも、企業選定における重要な観点でした。最終的には、同じくらいの情熱を持って事業やサービスを伸ばしていけるかどうかといった、想いの部分を重要視していましたね。エイチームグループ入りしてからのギャップはありますか?海野:稟議がめんどくさい!!(笑)Incrementsは約20名の組織。エイチームグループは1,000名を超える大規模な組織。ワークフローやプロセスも異なるし、いろんな人たちが在籍していて、歴史も長い。非常に良かった点としては、エイチームの人たちは良い人たちばかりだということ。お互い仲が良く、話をしていて気持ちがいい人たちが多い。この点は、自分もエイチームのみなさんとコミュニケーションをして、自信を持って強く言えます。そのため、一緒に働く仲間として全く違和感がなく、とても良かったですね。大きい会社であるがゆえのワークフローや歴史的負債は、直せるので一緒に改善していけばいい。思うと、エイチームグループ入りをしてからのギャップとかは、あまりなかったですね。シンクロした部分は、Incrementsとエイチームが掲げる「幸せ」の定義に共通点があったところですね。Incrementsは「エンジニアを最高に幸せにする」というミッションを掲げていて、エイチームは「みんなで幸せになれる会社にすること」「今から100年続く会社にすること」を経営理念に掲げています。他にも、エイチームの林社長が元エンジニアだったり、同じくうるう年の2月29日が設立日だったり、共通点を感じる部分が多かった。高橋:組織統合をする上で心配だった点は、エンジニアの働く職場環境の違いですね。Incrementsはエンジニア主体の組織のため、エンジニアが求める環境が整っている。エイチームは、エンジニアの他にもマーケターやビジネス系の職種など様々な職種の人たちがチームワークを大切にして働ける環境を重視している。働き方の大きな違いは2点あって、リモートワークとフレックスタイムのコアタイムの違いです。Incrementsが完全にエイチームに合わせるのは嫌かもなぁと思っていました。海野さん、実際のところどうでしたか?海野:高橋さんの言う通り、エンジニアが働く職場環境に違いがありますね。環境において大切なことは、仕事の価値を最大限に高めるためにどのように働くかです。十数人の会社の働き方と1,000人規模の環境では、セキュリティーや設備面など難しいところもたくさんあると思います。その点は、Incrementsのノウハウをエイチームに提供できればと思っています。あと、12~17時のコアタイムは、エイチームの10~16時に合わせてよかったですね。午前中寝て、昼過ぎに出社するみたいな...。一緒にランチに出かけたりなどのコミュニケーションも希薄でしたので、お互い顔を合わす時間が増えて良くなったと思います。エンジニアの評価制度と報酬エンジニアのみなさんも興味深い評価と報酬について聞いてみましょう。Incrementsにはどのような評価制度がありましたか?海野:M&A前は、厳密な評価制度はありませんでした。一人ひとりのことがよく分かるので、評価者の役員がよしなに評価していました。ベンチャーあるあるみたいな(笑)社員数が少ないため、評価制度をゼロからつくる工数のほうが大変。それと、評価制度の必要性をそこまで当時は重要視していなかったかもしれないです。スタートアップベンチャーを希望するエンジニアには、金銭的な報酬よりも、事業やサービスにコミットして大きくしたいとか、IPOで将来的に経済的なリターンを期待する人の方が多かったこともあり、優先順位は低い時期が長かったです。エイチームの評価制度はどのようなものでしょうか?高橋:エイチームの評価制度は、全職種共通の等級制度を導入しています。等級ごとに期待する役割を評価していきます。エンジニア専用の評価項目が特にあるわけではありません。メンバーは上長との間で半期に1回、目標設定を行います。スキル目標」3つがあります。エンジニアの場合は、エンジニアの上長と一緒にこれらの詳細を設定します。船越:主にWeb系のサービスを運営するライフスタイルサポート事業本部のエンジニアは、約5年前から各エンジニアの評価を横軸で見る取り組みをしています。査定は半年に1回あり、まずは各部門の給与会議を経て、全社員約1,000人の給与を決定する全社の給与会議を経て最終的に決まります。その給与会議と並行しながら、エンジニアの評価や査定、給与を横軸で比較しながら決定します。今後、評価制度などの人事制度も統合していく予定はありますか?海野:評価制度の統合は必要だと考えています。グループ内での事業支援や人材の交流・異動などを考えた時に、評価の軸がそろっていないと、矛盾が生じてしまう。A部署では給与が上がって、B部署では給与が下がって...。なると本来期待していた人材の交流が生まれにくくなってしまう。評価は本当に難しく、事業やサービスのフェーズや状況によって求められる成果が異なる。エンジニアであれば、新規開発なのか、運営・保守なのか、それとも高い技術力なのか。その人が担う役割によって、評価すべきポイントが大きく変わってしまう。高橋:評価制度の統合は、いま人事部と連携しながら着々と進めています。評価制度には正解がないため、手探りではありますが、少しずつ改善していきたいと考えています。今だからこそ話せる黒歴史ここからさらにぶっちゃけてお話しいたましょう!まずは、技術的な点で黒歴史はありますか?高橋:Incrementsのとあるエンジニアが「あの頃の俺に戻りたい」と言っていたのが印象的でしたね。開発当初は「Qiita」と「Qiita:Team」のリポジトリを別々にしたいと言っていたのに、結局一緒にしてしまった。その後の開発でかなり苦労したと聞きました(笑)海野さん、実際はどうだったんですか?海野:「Qiita」と「Qiita:Team」のリポジトリを一緒にしたのは、それぞれのサービスにおいて共通点が多かったからです。今思えばデータベースも完全に分けて認証サーバーを設置するなど、解決策はいくつかありました。サービス自体が立ち上がらないと意味がありません。スピードが出なくてもダメです。サービスローンチ後、検証できるほどのある程度の成果が表れたタイミングでサービスを止めて、再検討して改善・検証する、とかできたらいいですけど、現実的には難しいですよね。本来は、サービスが軌道に乗り始めてから、リポジトリを切り分ける...けど、そうした判断は当時うまくできなかった。高橋:私が所属しているエイチーム引越し侍が運営する引越し比較・予約サイト「引越し侍」においても、引越し価格を比較して見積もりを提示する機能と業者を予約する機能を一緒にするかしないか、議論が起きました。サイト構成上、同じ画面内に機能があるように見えますが、中身は全く別物。データベースも分けています。分けて良かったのか、分けない方が良かったのか、今でも判断が難しい問題です。引越し比較・予約サイト「引越し侍」のサイトトップ。左側のオレンジ色の枠:価格を比較する機能。右側のグリーンの枠:サイト上で引越し業者を比較し予約する機能。船越:「作っておけばよかった、もっとこうしておけば良かった」という声があがるのは、サービスが伸びてくる2~3年のタイミングではないでしょうか。トリガーとしてサービスがどのような状況かにもよりますが、開発のリソースを再配分したり、プロジェクト内でシステム改善のための20%ルール(※)を導入したりなど、どうすればより良くなるかを前向きに考えて取り組むようにはしています。事業を正しく理解していないと、できない判断ではありますね。高橋:私が「引越し侍」の開発に携わる前の話ではありますが、サービスを全部作り直したことがあります。サービスをストップすることはできないので、既存サイトの改善・改修などの運用をしながら、新規サイトへのリプレイスを行いました。結局2年くらいかかったんですが、リプレイス完了後には当時採用したフレームワークがすでにEOL(※)となっていたり...。ものすごく悲しいですよね。実は今も、引越し侍のリプレイスを新たに計画していますが、特定のフレームワークに依存しないアーキテクチャで設計・実装しています。※EOL...IT業界では製品の生産終了や販売終了、ソフトウェア製品などのサポート終了、修正・更新プログラムの提供終了などの意味で用いられることが多い。海野:リプレイスは難しいですよね。Spolskyも「リプレイスプロジェクトは大体失敗する。やらないほうが良い」とまで言っていますね(笑)ただし、使っている技術によっては、リプレイスせざるを得ないときもある。段階的に移行することも難しくって、例えばPHPからRubyにリプレイスするにしても両方が共存する設計はハードですし、その知見はまだ世の中には少ないと思う。船越:サイトリニューアルであれば、サービスの価値向上に直結するし、ユーザビリティーも向上するので、エンジニアの貢献度がわかりやすいですよね。一方で、リプレイスはとても重要ですが、システムの裏側なので、UI/UXのように見てわかりやすいものではありません。何が変わったか、わかりづらい。ページ表示が速くなったとか、軽くなったとかは感覚的で、あまり意識しないですよね。大きな速度改善があればCVRに影響が出たりもしますが、1~2年かけてリプレイスしても、サービスの価値向上に与える影響が見えづらいから、エンジニア自身のモチベーション維持も難しい。そんなとき、不具合でも出たら、泣きたくなっちゃいますよね。高橋:モチベーション維持のためには、技術的な好奇心が必要だと思います。好奇心の対象が新しい技術のみだと心配な点もありますね。開発初期はモダンな技術だと思い、楽しみながら開発していたのに、1~2年経つとその技術はもう古くなっていて、モチベーションが低下するということにもなりかねない。船越:技術的負債はまとめて返すんじゃなくって、計画的に返しましょう。小まめに返しましょうね、という話ですね(笑)一緒に目指す「未来予想図」を語る「ヒト」「モノ」「カネ」。Jobs」の成長など、様々な事業展開を行い、ミッションの「エンジニアを最高に幸せにする」を目指すと共に、エイチームの経営理念の共通項である「幸せ」の実現を一緒に担いたいです。エイチームとIncrementsのお互いの得意分野を活かし合いながら、共に事業の成長を目指したい。エイチームのライフスタイルサポート事業で運営するサービスは、様々なライフステージで利用する「バーティカルメディア」の要素が強い。一方で「Qiita」は、エンジニアが日常で継続的に使う「CGM(※)」です。「Qiita」のメディア特性を活かしたサービス運営ノウハウをグループに横展開したいと考えています。「バーティカルメディア」と「CGM」との融合や連携により、サービスの可能性を広げていきたいです。今回のグループ入りで、エイチームからはノウハウや資金、人材の面でサポートしてもらっているので、サービス運営の点では、Incrementsがエイチームグループに貢献したいと思っています。消費者生成メディアとも言い、Webサイトのユーザーが投稿したコンテンツによって形成されるメディア。高橋:エイチームは東証一部上場企業で社員数は1,000名規模、多くのサービスを多角的に展開するものの、エンジニアの中で知名度が低いという課題がありました。Incrementsは、国内最大級の技術情報共有サイトを運営する会社として、エンジニアの知名度が抜群に高いし、好感度も高い。両社が統合することで、より多くのエンジニアに一緒に働きたいと思ってもらえる会社にしたいですね。船越:全社員が集まるイベントで、Incrementsのエイチームグループ入りを発表した時、エンジニアたちから大歓声が沸き起こりました。12月で、グループ各社対抗でアドベントカレンダーを実施していた時期でもあったので、特にテンションが高かった。それほど、Incrementsのグループ入りは歓迎モードでした。社内のエンジニアからは、「お互い切磋琢磨しながら技術的な取り組みやサービス開発を一緒に進めていきたい」という非常に前向きな意見が多数寄せられました。一緒に取り組めていることは少ないですが、これからどんどんその機会を増やしていきたいと考えています。Increments、エイチームグループが必要としている人材とは?海野:高い技術力や特殊な技術力を求めているわけではありません。サービスを開発する上で、当たり前のことを、当たり前に改善することがとても大切。特定の専門性はあまりいらなくて、「この機能を改善した方が使いやすくなる」「ユーザーの利便性を考えて、新しい機能を実装してみる」「自分がユーザーの立場だったら...」そのように考えられるプロダクト志向の方を求めています。一緒にサービスを良くしていきたいという気持ちを持っている方がいいですね。高橋:技術は手段です。必要な時に使えるようにしておくことが大切です。探究心があって、成長意欲がある方がいい。技術を使ってサービスの開発や改善をしたい、事業として成長させていきたいという気持ちを大切にして欲しいですね。良いサービスを作るためには技術が必要なので、同時に技術に研鑽を怠ってはいけません。サービスは一人で作るものではなく、複数の職種の人たちとチームで作っていきます。海野:チームでつくるというのは大事。孤高の天才エンジニアではなく、みんな議論して連携しサービス開発ができる人ですね。船越:絶対的に求めていることは、技術を楽しめること。課題がない事業・サービスはありません。課題がなければ、これ以上の改善や成長の余地がないと理解しています。逆に言うと、課題には必ずニーズや改善のヒントが隠れています。その課題をエンジニアとしてどう向き合い、アプローチして解決していくかを楽しめる方が活躍できると思います。エイチームもIncrementsも、技術という手段を使って、事業の課題解決を楽しみながら仕事している人たちが多いですよ。エイチームでは事業拡大のため、新しい仲間を募集しています。