インタビュー中、にこやかな表情で「決して自分はすごい人物ではない」と、プロダクト本部 副本部長の田中佑樹は語りました。しかし、この言葉とは裏腹に、田中はChatworkの開発組織を改善するため、いくつもの課題と正面から向き合い続けてきました。今では、組織の根幹を支える重要な存在です。何を目指して田中がChatworkで働き続けるのか、その想いを聞きました。
■プロフィール
プロダクト本部 副本部長 兼 プロダクトセキュリティ部マネージャー
田中 佑樹
2013年にChatwork株式会社へジョインし、BiwaUIへの刷新プロジェクトのWebフロントエンド開発や外部向けREST API開発、メッセージ検索サーバー刷新など数多くのプロジェクトを担当。現在はプロダクト本部 副本部長とプロダクトセキュリティ部マネージャーを兼務し、組織改善のために尽力する。
部署間にこぼれ落ちそうなボールを拾い続けている
――まずは田中さんの役割や業務内容を教えてください。
プロダクト本部の副本部長を務めています。プロダクト本部とは「プロダクトを創る」業務に関連する部署が複数集まった部門です。エンジニアの他にプロダクトマネージャーやデザイナーなどが所属しており、どのようなプロダクトを開発するか、各プロダクトをどんな方法で開発するかを考えてプロジェクトを推進しています。
また、本部全体の組織課題に対応するために、最近DevHRチームを発足しました。採用や人事評価、組織開発、組織のコミュニケーションの改善、メンバーのモチベーションアップなどが主な仕事です。自分の仕事をざっくり言うと、開発組織全体がより良くなるように、部署間でこぼれ落ちそうなボールを拾い続けているという感じです。
――プロダクトセキュリティ部のマネージャーも兼任していると伺っています。
Chatworkには、プロダクトのセキュリティを担保するための専門部隊としてプロダクトセキュリティ部があります。従来は各部署が他の業務と並行してセキュリティ対応をしていましたが、機能開発と比べると、セキュリティ関連のタスクはどうしても、誰が責任を持って対応するかという役割が曖昧になりやすい。セキュリティをいかに担保するかが会社全体の課題でした。そこで、セキュリティを一手に担う部署を作りたいと思い、プロダクトセキュリティ部を立ち上げました。
SESでいきなり現場に。右も左もわからない状態から経験を積んだ
――ここからは、田中さんのキャリアについて伺わせてください。新卒ではどのような会社に入社されましたか？
新卒で入社した会社がSES*の事業をしており、入社から間もなく右も左もわからない状態で派遣先の現場に投入されました。参画していたのは複数の事業を展開している大手IT企業でした。業務内容は難しくてかなり大変でしたが、実務を通して技術を身につけられたので、私のスキルの土台になっています。
*…ソフトウェアやシステムの開発・保守・運用における委託契約の一種。特定の業務に対して技術者の労働を提供する契約。
――特に印象に残っている案件はありますか？
フォトブックサービスの開発プロジェクトが、強く印象に残っています。ユーザーはWeb上で写真をアップロードした後、テンプレートを選んでフォトブックのレイアウトを作ります。そのデータを工場に送ると、印刷された実物のフォトブックが届くサービスです。
私はWeb上のフォトブックエディターでユーザーが作成したレイアウト情報を、PDFデータに変換するバッチ処理の一部を開発していました。扱うデータの規模が非常に大きいバッチで、その現場で初めて大規模なWebアプリケーション開発に携わりました。大規模プロジェクト特有の難しさや楽しさ、やりがいなど多くのことを学びましたね。
大規模サービスの開発は、多くの人が関わるからこそコミュニケーションコストも増大します。メンバーが増えるにつれ、仕組みや組織を整備しなければうまくいかなくなり、システム開発の生産性や品質を向上させるための方法も考えなければなりません。当時学んだ知見は、Chatworkに入社してからも活きていますね。
――他に印象に残っているエピソードがありましたら、お聞かせください。
その後に配属された別の現場も、今振り返ると大きなターニングポイントでした。大規模なシステムだったのですが、非常に歴史が長いシステムで、ソースコードやアーキテクチャの一つひとつに歴史を感じました。
当時の私は「綺麗なコード＝正義」と考えていたので、最初のうちは「自分の価値観と相反するコードだなあ」と思っていたんですよ。でも、いろいろな経験を経て自分の考え方が変わってきたように思います。その古くてレガシーなコードが、ビジネスを支えて誰かを幸せにし、企業の利益を生み出してきたんですよ。だからこそ、歴史のあるシステムに対して敬意を払うべきだと思うようになりました。
実際のところ、Chatworkのコードベースもサービス開始から10年以上が経過しており、レガシーな部分もあります。でも、それらのコードを支えてきた人がいるからこそ、現在のビジネスが成り立っているわけです。
事業に深く携わるため、自社サービス開発の会社に行くと決めた
――その後、転職されたのはなぜでしょうか？
SESでは業務委託という立場で開発に携わるので、ユーザーの声を直接聞くことはできないですし、システム運用の根幹の部分には絡めません。経験を積むにつれ、自分の開発するサービスに責任を持ちたくなり、自社サービスを開発している会社に転職したいと思うようになりました。
――そうして、Chatworkと巡り合ったわけですね。
転職エージェントから紹介されるまで、正直なところChatworkの存在は知りませんでした。でも、企業がこれから伸びていく面白いフェーズであり、自社サービス開発にも携われるという理由で、エージェントに勧められて。また、当時はまだ珍しかったSPA（Single Page Application）の技術を用いていたのも魅力的でした。その頃の私は、フロントエンド開発に携わりたいと思って、企業を探していたので。
採用面接を受けるために東京オフィスに行くと、マンションの一室のような場所で、十数人くらいでシステムの開発・運用をしていました。こんなに小さなオフィスで、これから巨大になりそうなビジネスをしているんだなと、興味を持ちました。
それに、面接に対応してくれたメンバーが20代～30代で、年齢が近いこともあって親近感が湧きました。入社後もメンバーの距離感が近くて。社長も役員メンバーも社員とデスクを並べて一緒に仕事をしたり、みんなでランチに行ったりしていました。SES時代には考えられなかったです。ああ、仲間と一緒に働くって、こういうことなんだなと思いましたね。
仕事において絶対的な正解なんてない
――Chatworkで携わったプロジェクトのなかで、特に田中さんの成長につながったものはありますか？
入社してすぐのタイミングでアサインされた、外部向けREST APIの初期リリースのプロジェクトです。エンジニアリングだけではなく、プロジェクトマネジメントまでまるごと担いました。
プロジェクトが始まるときに「今年の秋までにリリースしてほしい」とお願いされました。開発すべき機能が多かったので、間に合うかどうかかなり厳しい状況で。私ともう1人のエンジニアが開発を担当して、締め切りに追われながらがむしゃらに頑張りましたね。結局、リリースしたのは11月30日。ギリギリ、秋までに間に合ったという（笑）。かなり大変ではあったのですが、初めてプロジェクトマネジメントを経験し、ユーザーへの影響が大きい機能をリリースができた点で、すごく記憶に残っています。やりがいも大きかったですね。
――その後、田中さんは徐々にマネジメントの役割を担われています。入社当初と現在とで、仕事のやり方や考え方が変わった点はありますか？
昔は「自分がエンジニアとしてどうしたいか、何をしたいか」という意識が強かったです。マネージャーを経験するうちに、どうしたらメンバーが仕事をしやすく、モチベーションが高まるかを重視するようになりました。自分が所属している部署はもちろん、会社全体に目を配っています。
さらに経営目線で、いかに組織を成長させるか、どのようにプロダクト開発の成果を最大化できるかを考えるようになりました。個人から組織へ重点が移った感じですね。エンジニアとマネジメント職では、求められるものが違います。それぞれの自分の役割のなかで価値を発揮しようとした結果、考えが変わったのだと思います。
他にも考え方の変化がありました。昔の自分は、仕事のやり方には何か明確な正解があると思ってその答えを探していましたが、最近は「絶対的な正解なんてない」と思うようになりました。今の状況や環境でなるべくベターなやり方を探して、行動してみてダメなら改善する。そのくり返しを続けています。
日本の生産性に直結するプロダクトに携わる面白さ
――Chatworkならではの仕事のやりがいや面白さについてお聞かせください。
Chatworkは事業も組織も急速に拡大中で、今すごく面白いフェーズです。どんどん会社が大きくなっているので、変化に富んだ刺激的な局面だと感じています。2021年にプロダクト本部が80名強の人数になりましたが、おそらく2022年には100人を超えるでしょう。しかし、それに伴い既存の組織体制のままではスケールしない部分も見え始めています。
現在はPHPやモバイルアプリといった職能別に部署を分けています。その体制だと、あるプロジェクトを開始する際に、いろいろな部署から人を引っ張ってきてプロジェクトチームを組成し、終わったら解散という形になります。
何が問題かというと、チームビルディングのイニシャルコストがかかりますし、部署間でのコミュニケーションコストも高く、チームとしてのノウハウも貯まりづらいんですよね。そこで、今後は職能横断型で機能単位のチームを組成することで、DevOps的な動きができるようにし、所属する人々が知見を蓄積しやすい体制を目指しています。
エンジニアリングとしても、面白いことをやっていると思います。CQRSを使ってKafka + HBaseでメッセージを扱っており、現在は約90億くらいのメッセージデータを格納しています。それくらいサービス規模が巨大なんですよね。すごく世の中への影響があるサービスを運用している実感を持てるので、エンジニアとしては働いていて面白いはずです。
Chatworkは今、一種の社会的インフラになりつつあります。仮にサービスがダウンすると、本当に多くの方にご迷惑をかけてしまうんですよ。だからこそ、自分たちは日本の生産性を支える仕事をしているのかなと感じています。それに、現在も継続的にレガシーなシステムのリプレイスプロジェクトを続けています。非常にチャレンジはしやすい環境ですし、チャレンジする楽しさも味わえる環境だと思いますね。
