はじまり編、旅行前 編とお伝えしてきた“エンジニア循環施策”のトライアルが無事終了。今回は、2週間にわたる旅行を体験したリードエンジニアである鈴木 拓也（以下、スズタク）に再度インタビュー。「どんな体験をしてきたのか？」「行ってみてぶっちゃけどうだったのか？」直球質問をぶつけながら、忖度なしのリアルな声を拾ってみました！
※鈴木、一階は退職していますが、本人の同意を得て掲載を継続しています。
旅行で見えてきた他部門の良さと違い
――スズタクさん、お帰りなさい！早速ですが、2週間の旅行はいかがでしたか。旅先での様子を教えてください。
鈴木：旅行先はdodaを担当する第三開発部でした。大きく3つあるスクラムチームのうち、エージェント事業を対象とした“集客“のチームに参加させていただきました。第三開発部のリードエンジニアである中澤さんに付きっきりでレクチャーを受けましたが、スクラムに参加して、中途半端に関わって何かを対応するというより、2週間という限られた期間を有意義に過ごすために、色々とインプットさせていただいたり、見せてもらった上で、気になったことがあれば聞くという形を取っていましたね。
基本的なdodaについての説明や、業界の背景、組織としての取り組みについてレクチャーを受け、第三開発部がどの部分に、どのように関わっているのか、システムの全体像などを教えていただき、最終的には会員登録機能周辺の修正チケット対応で手を動かして、それを第三開発部のチームに引き継いで終了しました。
――おお！実際に開発もされたのですね！ただ、ほとんどの期間はレクチャーですか？
鈴木：そうですね。やはり環境構築をしたり、自分の手元で動かすためには内部の理解が必要なので、やはり説明を聞いて、現状を正しく把握することは重要ですよね。初の試みで、お互いに手探りということもありましたが、良い意味での誤算としては、かなりしっかりとレクチャーして頂いたので、思ったよりもたくさんのことを吸収できたと思います。
――ここからは受け入れ組織のマネジャーである一階さんにお聞きします。
この先の移住を考えると、研修よりも体験の度合いが多い方が良いと感じますが、今回スズタクさんを受け入れるにあたり、方針や背景をきちんとレクチャーすることになった理由を教えてください。
一階：我々が携わっているdodaの開発は、構造が複雑で技術的負債も溜まっているため、業務仕様的にすぐに開発に着手することが難しいところがありました。もともと期間が2週間ということだったということもあり、まずはその部分をインプットするということをメインにしていました。
また、事前にスズタクさんから、今後、第二開発でサービスを作るにあたり、dodaとのデータ連携が視野に入ってくるので、“データベース周りの知見を得たい”というお話があったので、そのあたりのインプットを重点的に考えていました。今回、ソースコードにコミットしたというのを聞いて、“そこまでやったのか！”と思いましたね。我々の今の環境では、第二開発部に比べると、なかなか複雑な手順もあったと思います。
レクチャーを中心とした目的には、新規サービスを開発する上で連携ができる第一歩になればいいと思っていました。中澤を充てた理由も、dodaのデータベースがかなり複雑になっていて、そこの構造整理を担当してもらっているので、今回は丁度いいと思い、受け入れ側の担当になってもらいました。
dodaに並ぶ新しいサービスが入ってくると、やはりデータの連携が発生するので、上手くお互いがシナジーを持ってやれたらと思い、積極的に受け入れを行ったという背景があります。
――複雑な構造が故に、まずはその理解を進めるためにレクチャーを中心にしていたんですね。スズタクさんは実際に第三開発部で過ごしてみて、技術や文化、仕事の進め方に違いを感じましたか？
鈴木：技術的な違いの部分で言いますと、コードなど、確かに技術的にレガシーな部分はありました。しかし、一階さんが言われていた通り、内製化している様子や、中澤さんが進めているデータベースの構造を変える計画を拝見して、改善を実現しようとしているのは“すごい”と思いました。
旅行前に、「レガシーだ」とは聞いていましたが、既にずいぶんと改善が進んでいるという印象を持ちましたね。これまでも、色々な現場で結構汚いJavaのコードを見ていますが（笑）、それと比較すると、“そこまで酷くないかな”と。
もちろん、部分的にはもっと酷いところはあるかもしれませんが、パッと見たところで解釈に時間はかかるものの、2週間で理解ができないほどのものではありませんでした。中澤さんが構造を変えてきた努力が見て取れたって感じですね。
dodaのように大きなシステムを「改善する」と言っている会社は他にもたくさんあると思いますが、実際にはあまり進んでいないところがほとんどです。しかし、dodaについてはちゃんと進んでいる空気があるということに感銘を受けました。
――空気があると感じたのですね。
鈴木：そうです。空気というかカルチャーですかね。印象的だったのは、今の時点でディレクターやPO（プロダクトオーナー）を中心としてエンジニアも含め、チームでデータドリブンに動けているという点。doda自体がまとまったさまざまなデータが取れるシステムですし、また第二開発部は新規開発のためデータを取るというところではまだまだ難しいところもあり、そういう意味で毛色は違うかもしれませんが、それにしてもデータに基づいて動けているというのは“良いな”と思いましたね。
あとは積極的に勉強会が開催されているのは、やっぱりいいですね。私が所属する第二開発部でももちろん行っていますが、“ウチだけじゃないんだ”って（笑）。
――今のスズタクさんの話を聞いて、一階さんいかがですか？チーム運営で意識されていることはありますか。
一階：自部門管轄のサービス開発をリードするということを目標にしているので、そのために、数字をきちんと読めるようになろうという話をしています。それでエンジニアの方からPOに対して勉強会をしてほしいという依頼をし、その結果、チーム全体としてデータドリブンな視点が持てるようになったというのは、この上期の成果といえるのではないでしょうか。そういった雰囲気が伝わったのは良かったですね。
鈴木：確かに、エンジニアも数字をきちんと理解して、その上で会話ができているという感じでした。さらにディレクターから降りてくる施策自体もしっかりとしているから、開発に注力できているという印象も持ちました。技術的な相談を受けて、それに答え、気になる点は開発からも上げるという感じで、もちろん努力の結果だと思いますが、とても良い関係性だと思いました。
一階：dodaの開発では、“あまり役割を決めすぎない方が良いのでは”という話もあるので、時折、崩したりもしています。また、“リリースのスパンを短くすることが本当に今必要なのか？”という話もあるので実際に我々が携わる領域で最適な方法は何か？を考え、企画などを練って上手くやっていこうと合意も取っています。
自分たちのプロダクトのリリースにあたって、最適な形態というものを、POとエンジニアの間できちんと話し合いをしている結果なので、それが上手くいっているのであれば良かったと思います。
――スズタクさんが客観的に見て、企画と開発がお互いに領域を侵犯し合っていることが良かったのか、それとも役割がきちんと決まっていることが良かったのか、どちらですか？
鈴木：役割が分けられているということが良かったと感じます。企画と開発のレベルがそれぞれに高く、その高いレベルの知見をお互いが活かしあっていると感じました。
今、私が所属している第二開発部はその辺りがまだできていなくて、お互いがお互いの仕事の領域をやり合っているところがあると僕は思います。本来は開発が考えるべき事を企画が検討していたり、開発が企画に口を出して行き違いを起こすようなことがあったので、その辺りを整えたいと思い、第二開発部でもスクラムを導入していました。第二開発部も役割をこえて意見を言い合うところから、徐々にまとまりができはじめてはいるものの、仕事としての完成度で第三開発部は一歩先を行っている気がしましたね。
――第三開発部はPOやスクラムマスターが、各スクラムでどこまでを誰がやるかについてしっかりと話し合った結果なのでしょうか。
一階：スクラムをやるとなったのは開発側発信だったので、プロダクト企画側では「なぜスクラムをやるのか？」と疑問を持っている状態でした。その辺りの合意が取れていなかったり、事前の研修など一切なく、いきなりスクラムを始めたので、結局はスクラムと全く違う形になってしまい、現場でもハレーションが起きていました。なので、正直に話し合う場を作り、問題点や違和感がある点を出して、そこに最適化をかけていきました。
ランチ会の雑談から生まれた新しいアイデア
――循環施策を実際に体験したスズタクさん、一階さんは、それぞれ率直に、施策に対してどのように感じましたか。
鈴木：2週間という期間で考えると、満足していますし、この期間が妥当だと感じました。とくにスクラムなどに参加せずにただ見せていただくという期間だとすると、2週間はお互いに負担が少ないと思います。
実際にどう感じたかというと、私自身やってよかったと思っています。まず痛感したのは、dodaのことを全く知らないということでした。今回はその点を深く教えていただいたので、プラスになっていると思います。
dodaを活用して、今後システム開発を進めていくことでパーソルにいる醍醐味を感じると思っています。その点でやはり、知らないところが知れて良かったですし、dodaを全く知らない状態ではカニバリが発生します。また、業界としてのお作法を知れたことも有益だと思います。ただ、中に入って何か対応をするとなると2週間では足りないとは思います。
――もう少し期間が長ければ、やりたかったこと、ここまで出来たら満足だと思ったことはありますか。
鈴木：スクラムに参加してチケット対応までできればベストだと思いますが、それはやはり2週間という期間では無理だと思います。それをやるならば、3か月ほどの期間が必要だと思いますが、技術的なことを知っている人間でなければ、ただ迷惑をかけて終わってしまいます。なので、スキルセットがどの程度マッチしているかどうかや、ギャップがある場合はそれを埋める対策はかなり気を付けなければならないと思います。受け入れ側の第三開発部にもメリットがあるようにしなければならないと意識をすると、留学する側も考える必要があると思います。
最初はもちろん第三開発部にもプラスになるようなことができたらいいと考えていましたが、2週間という短い期間ではなかなか難しいと思いました。
そもそも、どういったことが第三開発部のプラスになるのかということは、第三開発部の方にしか分からないと思います。なので、反対に第三開発部の方に第二開発部に来ていただいて、そこで得られるものがあればいいというイメージで、受け入れる側で何か準備をしたほうが良いのではないかと思いました。
また、何も知らない状態で自分の意見を伝えてもただうるさいだけになるので、やはり文化を知った上で発言をするのが良いのではないかとも思いました。
もちろん、自分も何かしなければならないという心持ちで行きましたが、文化も随分と違うので、その上で何をすれば良いのかを考える期間として、2週間は短かったとは思います。まあ、文化を理解するところまでは到達したというイメージですね。
――一階さんいかがでしょうか。
一階：まずは、来ていただいて良かったと思っています。第三開発部も人の交流が少なく、第二開発部でどのようなことを行っているのかも知らなかったので、接点を持てたのは良かったですね。また中途入社の方に向けた説明資料を作っていて、それをスズタクさんにも見てもらいましたが、新しく入社された方以外でも有効活用できることが分かりました。
そして、このような話をテクノロジー本部内に展開するということも大事だという気づきもありました。我々、第三開発部は知識や技術が各サービス内に閉じ気味なところがありますが、テクノロジー本部に貢献できることもあるのかなという気づきを得ることもできて、良かったと思っています。
4Qになると、我々の方から第二開発部に数名エンジニアが行くことになるかと思うので、そのときには我々も、何ができるかを考えなくてはなりませんね。
鈴木：ランチ会の時に「自分が持っている企画を第二開発部で提案して、提案だけをして帰るということができたらいいね」みたいな話していました。そのときは冗談で終わりましたが、そういうことができると単純に面白いと思います。
dodaをよりよくしていくために、このようなシステムがあればいいと思うことも、もし何らかの事情でdodaでは実現が難しいならば、第二開発部でならできることもあるかと思います。そういった部分で、この循環施策をうまく活用して、一時的にその案を投下してもらい、それを第二開発部で回収して作っていくということができたら面白いですよね。
一階：第三開発部では既存の業務やツールが多いので、そういう面は強いのですが、新しいものを生み出す力は弱いので、我々が持っている知識と第二開発部が持っている新規性を掛け合わせられると良いですね。
――単純にお互いの業務理解だけではなく、お互いのやりたいことや思いを理解し、共有ができたということですね。
鈴木：そうですね。例えば、このようなことをdodaで実施しているけれども“ここが辛い”といったような、辛いものベースの話が出てくれば、そのまま新規事業の種になると思います。しかし、それは第二開発部にいても入ってこない、第三開発部“ならでは”だと思います。そういうレベルの種でもいただけたらいいですね。
――ランチ会というお話がありましたが、仕事外の交流は一階さんも意識をしていたのでしょうか。
一階：意識はしていましたが、なかなかそこまでできているかどうかは分からなかったので、中澤から「ランチ会をする」と聞いて、良かったなと思いました。dR（doda Recruiters）は留学先として無かったのですが、そこのエンジニアも巻き込んでランチ会をしていましたね。まあ、私はダイレクトに入っていかずに中澤に一任していたので、お父さんのような気持ちで見ていました（笑）。
――留学前にスズタクさんから、doda側の人と繋がることを大事にしたいというお話をいただきましたが、中澤さんを中心に人とは繋がれた感覚でしょうか。また、開発部によって人のタイプの違いを感じる瞬間はありましたか。
鈴木：そうですね。第三開発部の方とはteamsで繋がることができました。継続的に交流がとれています。人のタイプの違いですか…これは、中澤さんが仰っていたことですが、ご自身は保守的な考え方を持っていて、今あるものを守った上で改善していくという考え方を持っていますが、今回、私と関わったことで、先進的な考えだったり、色々なものを作っていくという考えに刺激を受けたと。それがとても印象的でしたね。中澤さんが仰っていたことが、そのまま人のタイプの違いなのかなと感じました。
――第三開発部にとっても、スズタクさんが来た事は刺激になりましたね。
一階：良い刺激がありました。歴史ある大規模システムの開発はやはり保守的な性格が強いのですが、今回新規のやり方やマインドといった新しい視座に気づくことが出来たので、この先に繋がっていくと思います。ちょうど改善のプロジェクトを進めているのですが、実際に自分たちで“こうしたい”という提案を、きちんと現場から発信できていなかったし、その辺りが弱いところでもあるので、今回をきっかけに強化されたらいいなとは思います。
今までの自分をがらりと変えるのはハードルが高いので、そこまでは求めていませんが、エンジニアの働き方はいくつかあることを知るきっかけになったと思います。新規事業サービスは、自分たちとは違うとエンジニアが作っていると思っていたようですが、新規サービスもdodaなどの既存サービスと何らかの形で絡んで展開していきます。“ひょっとしたら自分たちも協力ができるのでは”と話しているのを聞いたので、そういった視点が入ってきたのは、とても良いことだと思います。
初回から“シナジーが実感できた”という成果
――確かに新規か既存か、に分けた時に属していない方は自分とは違う人と括りがちですが、全体を自分ゴトとして捉えなければならないポイントだと思います。今後チャレンジしたいことはありますか。
鈴木：先ほど勉強会の話をしましたが、第三開発部でも行っていることが分かりましたし、第二開発部でも勉強会を行っているので、被る部分は絶対にあると思います。なので、お互いの勉強会に参加し合うということは、すぐにでも実践していいのかなと思いました。そして可能であればですが、データ周りの扱いに関して、第三開発部はとても進んでいると感じたので、その知見を第二開発部にも話してくれると嬉しいです。
自分がチャレンジしたいことでは、コードリファクタリングの知見があるので、勉強会などで足しになる話ができればいいですね。どういう情報が欲しいのかは相手にしか分からないので、ためになるものをお互いに共有できればいいと思います。また、私一人ではどうにかできる問題ではありませんが、他の部署からアイデアをもって来たときに、それを受け入れられる体制を第二開発部で作った方がいいと思いました。会社全体を俯瞰した第二開発部の立ち位置として、受け入れられる体制を整えるのは良いことだと思うので、そこは是非やっていきたいです。
――他の部署にも留学したいという気持ちはありますか。
鈴木：ありますね。今回は第三開発部にお邪魔しましたが、もちろん第一開発部、第四開発部にも行きたいです。部署ごとに知見はあると思っていて、それは第二開発部にとって新しいものを作る種になると思うので、一通りお邪魔して話を聞くのもいいと思います。継続的にこのような機会があれば、私は行きたいです。
一階：テクノロジー本部全体でこの施策を行って、パーソルキャリアのエンジニアリング部隊として最適化できれば良いのではないかとも思っています。部署ごとに強みがあるので、例えば我々は転職活動する方向けの業務知識が当然ありますし、CAさんやRAさんが日々どのような業務を行っているかについては第一開発部が一番強みとして持っています。それらの知識は必ず新規サービスに活きてくるので、フィードバックしたいですよね。
また、我々も新規性を取り込んで、例えば第三開発部で新規開発をしたい場合は第二開発部に異動して新規開発ができるような体制を、これをきっかけに作れたらいいなと思います。開発部は第一から第四まであり、お互いに繋がってはいますが、なかなか交わることはありませんでした。シナジーについてもそもそもあるのかと思っていましたが、それは今回シナジーがあることを実感できたので、これをきっかけに垣根を壊すことに務めていきたいと思います。
――単純に情報交換をするのではなく、人が行き来すると何が違うのでしょうか。
一階：説明を受けただけでは“ふーん”で終わることが多いですが、実際に開発してみると調べたりするので、そこから得られる知識もあります。また細かいところを見ていくと分かることもあるので、第二開発部で新規開発するときは、第三開発部で数か月開発して過ごしてから第二開発部に行くということもアリかなと思います。第二開発部で企画をしている人はCAさんやRAさんから来ている人も多く、その人たちと話すには既存業務の知識がなければなかなか難しいと思うので、その部分は第三開発部である程度補えるかなと思います。とにかくテクノロジー本部の全体最適をするために、人の交流を増やしていきたいですね。
――受け入れ側としては、2週間という期間はいかがでしたか。
一階：もともとフェーズを分けていて、まずは短期で旅行がてら来ていただいて、行けそうなら短期留学をして、気に入ったら永住しようというフェーズでこの施策を行っています。なので“まずは相手を知るところから”ということで、短期のホームステイ目的は達成でしたと思いますし、そういう意味でも2週間は最適ですね。
――最後に、今回送り出した側のマネジャーである鹿野さんからもコメントをいただきました。
スズタクさんが留学中の2週間、本来は”スズタクさんがいなくて大変だったよ〜”と言いたいところですが、実際は ”全く問題なし”でした。
というのも、この施策を迎えるにあたり、事前準備としてメンバーアサインを調整し、加えて、留学前にはテスト自動化をはじめとした改善タスクを中心に担当することで、留学中にプロジェクトへ影響が出ぬよう、スズタクさんの方で業務調整を行っていました（さすが）。
とはいえ、やはり一部スズタクさん不在による混乱はありました。しかし、その混乱がメンバの成長に繋がった面もあります。Projectリーダー不在でのSCRUMイベント、スズタクさんが起案したサービスの部内プレゼンなど、リードエンジニアの穴を塞ごうと積極的に動くメンバーの成長を感じることができました。
スズタクさんが帰ってきてからは、周りのメンバも含めて視野が広がった印象を受けます。一階さんをはじめとした第3開発部の皆さんのおかげですが、受入れから各種環境・基幹システムのレクチャー、そして実際の業務対応とかなり充実した2週間を過ごせたと聞いています。
第2開発部のメンバーは中途入社が多く、HR業界および社内基幹システムの知見が不足しているメンバーもいます。その状態で新たな「はたらく」サービスを生み出すことができるのか、サービスによっては自社サービスとの連携が必要となることもあり、いわゆるエンジニアリング・技術だけでは解決できない点も多いです。チーム、プロジェクトを牽引するリードエンジニアとして危機感を持ったと言うスズタクさんからの話もあり、その危機感が他メンバーの意識、及び視野向上に広がったと感じています。
循環施策は本人の希望に加え、プロジェクト側での受入調整などコストがかかります。ですが、メンバーからも業務調整が付けばぜひとの声もありますし、今後も前向きに取り組んでいきたいと考えています。
――この2週間をきっかけに、エンジニアのキャリアが複数の部署で広がることが大事ですね。ここから多くの人が参加すると、さらに総和が広がると感じました。とにかくスズタクさん、お疲れさまでした！
（取材・文＝伊藤秋廣（エーアイプロダクション））
鈴木 拓也 Takuya Suzuki
サービス開発統括部 エンジニアリング部 第3グループ 兼 エンジニアリング統括部 第2開発部 リードエンジニア
前職はFintechベンチャー企業で開発部マネージャーを務め、自社で抱える複数のプロダクト開発に横断的に携わる。2020年1月にパーソルキャリアに入社し、CAREER POCKET/転職同期の開発リーダーを担う。現在は退職。
一階 武史 Takeshi Ikkai
プロダクト開発統括部 エンジニアリング部 エンジニアリンググループ 兼 エンジニアリング統括部 第3開発部 エンジニアリンググループ マネジャー
2000年にSIerでエンジニアとしてキャリアをスタート。大規模基幹システムのPLやPMを経験後、事業会社に転職。事業会社ではエンジニア・企画／開発・ラインマネジメントなど、幅広い経験を積む。2020年1月にパーソルキャリアに入社し、doda／iXといったtoCサービスを開発するエンジニア部門のマネジャーを担当中。現在は退職。
鹿野 徹也 Tetsuya Sikano
サービス開発統括部 エンジニアリング部 第2グループ マネジャー 兼 エンジニアリング統括部 第2開発部
SIerに新卒入社後、金融系PROJECTにて要件定義〜開発〜マネジメントを経験。その後、地元へUターンし、地方ソフトウェアハウスにてIBM、FUJITSU、NEC等のリホスト業務（ランタイム作成、言語変換）に従事。地方と東京の「はたらく」違い・差を実感し、より自分らしく「はたらく」ため Webアプリケーションエンジニアへ転身。RubyOnRailsから始まり、アプリ連携、サーバレス開発、AGILE（SCRUM）開発リードと各種Webサービス開発で経験を重ね、2018年にパーソルキャリアへ入社。昨今はGV提唱のDesignSprintを利用したサービス企画に加え、マネジャーとしてエンジニアの「はたらく」をサポート、より良いチーム開発の実現に向けて挑戦中。
※2020年12月現在の情報です。
