開発組織を支えているのは、エンジニアやデザイナーといった職種のメンバーだけではありません。組織構造の設計や組織拡大のための採用・育成、社員が働きやすい環境づくりなどを担うメンバーもまた、開発組織にとって欠かせない存在です。
プロダクト本部 DevHR（開発人事）に所属する門田矩明は、そうした“組織づくり”の業務を担う社員のひとり。門田はなぜChatworkに入社し、現在の役割を担うようになったのでしょうか。その経歴をたどりました。
■プロフィール
プロダクト本部 DevHR（開発人事）
門田 矩明
2012年サイバーエージェント中途入社。メディア系サービス立ち上げにエンジニアとして関わった後、広告系SaaSサービスの責任者として、開発組織の改善やサービス提供体制の整備などの組織作りに取り組む。2020年にChatwork株式会社に入社。急拡大する事業を支える開発組織の強化施策や、エンジニア採用強化に奔走中。
社会人1年目から複数プロジェクトを担当。ガッツのある新卒だった
――門田さんがIT業界に就職するまでの流れを教えてください。
高校生のときにエンジニアになろうと考えていました。いろいろな情報を調べて進路を考えた結果、大学に進学するのではなく、情報系の専門学校に通うことを決めたんです。大学の授業では、エンジニアの仕事に直接的に結びつかないことも習うじゃないですか。
当時の私はそれが嫌でした。「将来、仕事で使わない内容を学ぶ意味はあるだろうか？」と思っていたんですよ（笑）。専門学校卒業後は独立系のSIerに就職しました。
――SIerではどのような仕事をされていましたか？
1年目から複数のプロジェクトをかけ持ちしていました。新入社員を採用した場合、育成に時間がかかるので通常は採用コストをペイするまでに数年かかりますよね。でも私はそれが嫌で、入社時に「私は1年で採用コストをペイしたいから、たくさんのプロジェクトにアサインしてほしい」と言ったんです。ガッツのある新卒でした（笑）。その希望を聞き入れてもらい、仕事を割り振ってもらえました。
――特に思い出に残っている仕事はありますか？
ひとつは、2年目から3年目のときに携わったECサイトのリプレイスプロジェクトですね。相当に炎上してデスマーチ状態になりました。でも、そうなった原因は自分にあったんです。ある技術をよく理解しないままシステムに導入した結果、完成直前の負荷試験で全くパフォーマンスが出ず、つくり直しになってしまいました。
――かなりシビアな状況ですね……。
技術を正しく理解して使うことの大切さを学びましたね。そのプロジェクト以降は、フレームワーク・ライブラリのソースコードの中身をきちんと把握してから使うとか、特定の技術を導入する前に特徴を調査するなどを心がけるようになりました。
もうひとつ印象に残っているのは、3年目から携わった金融システムの開発・運用です。そのプロジェクトでは自分がコードを書いたシステムを保守運用し、何かアラートが鳴った際には24時間365日対応する必要がありました。質の悪いコードを書くと、自分の首をしめることになってしまうんですよ。エラーハンドリングをきちんと書かなかったせいで障害の原因になってしまったりとか。コードの品質は運用の負担に直結することを実感しましたね。
基幹になるアイデアは、多くの人を巻き込んで検討する
――その後、サイバーエージェントに転職された理由を教えてください。
SIerはお客さんのシステムを開発するのが仕事なので、対外的に「自分の実績です」と言えないものばかりなんですよ。勉強会などに参加しても、みんなが自社の事例を発表しているなか、自分は発表できる内容が何もない。今後のエンジニア人生を考えると「これはまずい」と感じて、自社サービスの開発に携われる会社に転職しようと思いました。
当時のサイバーエージェントは会社としてスマートフォンシフトを掲げており、100個のスマホアプリをつくるという戦略を発表していたんですよ。すごくいいタイミングだなと思いました。技術者としてサービスを立ち上げる経験を積みたくて、サイバーエージェントにJavaのサーバーサイドエンジニアとして入社しました。
――入社後はどのような仕事をされましたか？
ブログやSNSなどメディア系サービスの立ち上げを複数経験しました。開発したサービスのなかでも印象に残っているのが、最初に担当したマッチングアプリですね。そのアプリでは、当時まだ珍しかった月額課金の仕組みを導入することになりました。その頃は、AppleやGoogleの月額課金に関するドキュメントが英語版しかなくて、日本語の資料が全くない。サイバーエージェント内でも事例がない。完全に手探り状態からのスタートでした。
そこで、エンジニアのメンバー全員で英語のドキュメントを読みながら、月額課金の設計・実装を進めていく方針にしました。もちろんスムーズには行かなかったですよ。ノウハウがないので、アプリが何度もリジェクトされました。でも、そのたびに誰かが「こんな問題が起きたから、こういう対策はどうだろう」とパパッと仮説を出してくれました。
全員が調査に携わったからこそ、全員が意見を出せる状態になっていたんですね。この経験から、サービスの基幹になるアイデアは、特定の人だけで考えるのではなくて、なるべく多くの人を巻き込んで検討すべきだと学びました。
ChatworkのDevHRチームの仕事でも、その考えは活きています。DevHRでは組織施策の企画・設計・運用や採用、技術広報、マネジメントのサポートなどを実施していますが、一般的な企業では、このような業務は特定領域に対してひとりが担当することが多いですよね。
しかし、そうすると仕事の属人性が高くなりすぎてしまい、組織の成長のボトルネックになりますし、担当者が休みを取りにくいなど働き方にも悪影響があります。だからこそ、業務内容をDevHRのみんなで共有しあって、チームとして動けるように心がけています。
エンジニア組織を運営する難しさとやりがいを学んだ
――サイバーエージェントから子会社のCyberZに移った経緯をお聞かせください。
サイバーエージェントには、エンジニアが2年ごとに異動希望を出せる制度があります。サイバーエージェントの社内だけではなく、子会社への異動も可能です。サイバーエージェントの収益源の大きな割合を占めるのがアドテク事業なんですが、せっかくこの会社に入ったので、広告系の仕事を経験しておきたいと思いました。そこで、アドテク事業をやっているCyberZへ移り、SaaSプロダクトの開発・運用に携わりました。
――CyberZではマネージャーとして組織づくりも担われていたとか。マネージャーになったきっかけは何でしたか？
サイバーエージェントと比べると、その頃に扱っていたSaaSプロダクトは技術的な部分がレガシーでした。CI/CDが導入されていないとか、Javaのバージョンが古いとか、フレームワークが使われていないとか。この環境のままでは、エンジニアとして思うようなパフォーマンスを発揮できないかもしれないという危機感を覚えました。
そんなある日「エンジニアチームの責任者にならないか」という打診が来たため、「マネージャーになればモダンな環境に変えていけるかも」と考えて引き受けることに。マネージャーとして組織づくりに携わる中で失敗も成功もたくさん経験して、多くのことを学びましたね。
――失敗や成功について具体的にお聞かせください。
まず失敗事例としては、技術目標制度と20%ルールを導入したことです。給与査定において、事業寄りの目標とは別でスキルに基づく技術目標を設定しました。さらに、業務時間のうち一定の割合を、技術向上などに使うというルールを設けたんです。当初はプラスの影響やアンケートの高評価が続いていたものの、徐々にマイナスの影響が出始め、アンケートでも高評価と低評価が極端に分かれる状態になりました。最終的にはマイナスの影響が顕著になったため廃止しましたね。
――良さそうな仕組みに見えますが、なぜ失敗したのだと思いますか？
エンジニアには、スキルアップをしたいタイプと、事業貢献をしたいタイプの両方がいます。この施策は前者にとっての利点が大きいものの、後者にとっては事業のために使える時間が減ってしまいストレスになっていました。また、技術目標を事業目標と切り離して設計したことで、個人のスキルアップが組織やチームとリンクしていない、もしくは結びつきが弱いものになってしまったのも要因のひとつだと思います。
一方の成功事例としては、マネジメントレス（マネジメントレイヤーの廃止）の施策が印象に残っています。もともと開発組織では、マネージャー・リーダーポジションのメンバーが組織を管理する階層構造の組織体制（ヒエラルキー型組織）にしていました。
しかしこの体制の場合、マネジメントレイヤーのメンバーを増やさなければ組織をスケールさせられません。マネージャー・リーダーポジションの採用・育成は難易度が高いため成長のボトルネックになり、開発組織がなかなかスケールできないという課題に直面していました。
そこで、マネジメントレイヤーを廃止して、代わりにひとつのチームを3～4人くらいの少人数にして合議制をとるようにしました。ホラクラシー的な組織にしたわけですね。チームメンバーが自分たちで考えて行動できるため、意思決定のスピードが速くなりスムーズに回るんです。それまでの組織運営の課題が解消されて、大成功でした。あとで詳しく述べますが、実はこの考え方をChatworkでも推進しようと考えています。
「50人の壁」の先を見たくて、Chatworkを選んだ
――その後、どのような経緯でChatworkに転職されたのですか？
その後は一度、専業主夫になって1年弱ほど休業したのですが、また社会人として働き始めるために転職活動を始めました。どの企業を選ぶのか非常に悩みましたが、自分のやりたいことと向き合った結果「もう1回SaaSをやりたい」と思ったんです。前職では30〜40人ほどの開発組織を運営していましたが、“その先”を体験したくなりました。
組織づくりではよく「50人の壁」と言われますよね。開発組織の人数が50名を超えたときにどんな課題が生じるのか、そして前職で培った知見がどれくらい活かせるのかを試してみたくなりました。要するにサイバーエージェント時代の取り組みを、新しい職場でもう一度再現したくなったんですね。ビジネスモデルと組織課題はリンクするため、前職と同じようにSaaSの事業を提供している会社を選ぶのが、自分のやりたいことを叶えるための近道だろうと思いました。
――数あるSaaS企業のなかで、Chatworkを選んだ理由を教えてください。
Chatworkはまさに現在進行形で、組織づくりに注力している会社だという点に惹かれました。それに、開発組織の人数も（門田さんの入社時点で）50人を超えたくらい。解決しなければいけない組織の課題がたくさんあって、自分がリスタートするにはぴったりだと思えたんです。Chatworkが目指す方向性と自分のやりたいことがマッチしていました。
そうしてChatworkに入社し、プロダクト本部のDevHRチームで仕事をしています。開発組織拡大に向けての採用・育成や組織設計、マネジメントのサポート、エンジニア・デザイナーの人たちがより働きやすい環境をつくるためのサポートなどをしていますね。
また、インタビューの本線からは外れるかもしれませんが、現在はChatworkの料金プランに関する機能開発を行うチームのマネージャーも兼任しています。SaaSモデルと課金は切っても切り離せない関係じゃないですか。SaaSのことをより深く理解したいと思い、自らマネージャーに立候補しました。
組織が変われば、メンバーの働き方やキャリアも変わる
――先ほど“組織の課題”というフレーズが出ましたが、具体的にはどんな課題を解決しようと試みているのでしょうか？
現在の開発組織は、サーバーサイド（PHP）やモバイルアプリなど、職域ごとに部署を分けています。何かのプロジェクトが開始する場合には、それぞれの部署からメンバーをピックアップしてチームが組成され、数か月ほど開発が続けられるケースが多いです。
この運営方法にはいくつかの課題があります。機能がリリースされた後にプロジェクトチームが解散するため、チームとしてのノウハウが蓄積されないんです。また、この体制では各部署にマネージャーを配置する必要がありますが、マネージャーを担える人材は絶対数が少ないため、組織としてスケールさせることが難しくなってしまいます。
その課題を解決するため、私たちは特定の機能単位のチーム（Featureチーム）を組成しようと構想しています。ひとつのチームのなかには複数の職域のメンバーが配置されており、チーム単位でプロジェクトを完結させられるようになっています。そして、全チームのピープルマネジメントはVPoE室というマネジメントチームが一手に担う方針です。
――Chatworkの開発組織がより良いものに変わっていくのですね。
この構造にすることで、開発組織をよりスケールさせやすくなるだけではなく、開発メンバーのキャリアにも好影響があります。
例えば、今まではサーバーサイドの部署に所属しているメンバーは、基本的にサーバーサイドのことを中心にキャリア形成を行っていました。しかし、機能ごとのチームであれば「これまでサーバーサイドの開発をやってきたエンジニアが（チーム内で必要になったため）モバイルアプリの開発にも挑戦してみる」といったことが実現できると考えています。メンバーの可能性や市場価値を高めていくうえでも、この組織構造が有効に働けばいいなと思っています。
――ワクワクするようなビジョンで、実現が楽しみです。今回はありがとうございました！