2020年10月からエンジニアリング統括部内で“エンジニア循環施策”がスタート。短期間の「調査旅行」、2か月程度の「留学」、そして「移住」と旅をイメージさせる用語を用いて、自身が所属している部署だけでキャリアが閉じないような仕組みにトライしています。全3回にわたり、本施策の様子を追っていきます。まずは「はじまり編」と題し、エンジニア循環施策を企画した、エンジニアリング統括部エグゼクティブマネジャーである三口に話を訊きます。組織で抱えている課題や本施策に込めた思いとは―――
真の異文化交流を――旅行になぞらえたエンジニア循環施策
――まずは施策のお話の前に、そもそもエンジニアリング統括部にはどんな課題を感じていたのでしょうか？
三口：テクノロジー本部 エンジニアリング統括部という内製開発を推進する組織の中には、第一開発、第二開発、第三開発、第四開発という部署があり、それぞれ担当する領域が異なります。
内製開発を進めるというコンセプトは共通ながら、第一開発はARCSといわれる基幹システム、第二は新規サービス、第三はdodaサイトおよびdoda関連のサービス、そして第四はdodaキャンパスを担当しています。それぞれの領域でやり方が変わってきていることもあり、正直、蛸壺化としている部分があり、各々の部署が何をやっているか分からなくなっていました。
――それぞれ異なる領域を担当しているので、横連携が取れていなかったということですね…。
三口：そうなんです。でも、他の部署の事情を知ることは重要ですよね。例えば、第一開発が取り組んでいる内容が他の部署にとっても良い内容であったり、失敗が共有できていると、他の部署も同じ失敗を繰り返すことはなくなります。そういった意味で情報共有の必要性を感じていました。
単に情報を共有するだけだったら、“こういう成功例がありました”と報告しあうような場を設ければ済みますが、それだけでは不十分だと感じていたんです。そこからメンバーを行き来させることで、人づてに情報を確実に行き渡らせられるんじゃないか、という話が持ち上がりました。
さらに、作る物が違えば、当然、必要な技術も違うので、メンバーが行き来すれば情報だけでなく、実際に手を動かしたり、設計したりすることで、メンバー自身の担当領域、スキルが広がることも考えられます。
メンバー側の目線で考えると、その部署に採用・配属された後、業務内容や人間関係で何かうまくいかなくなった時や“この部署では学ぶことは無いな”と思った時は、退職を意識しがちです。それを回避するために、キャリアチャレンジ制度という人事制度を設けており、パーソルキャリア内だけでなく、グループ会社への異動希望を申請することができます。
ただ僕としては、統括部内の行き来くらいであれば、もう少し気軽にできないかな、と。あるいは、所属している部署で “学ぶことが無い”と思っても、他の部署では、自分にとって面白そうな事をやっているということがわかっているだけで、モチベーションが上がったり、他部署に行くことで力を発揮できるかもと思えるかもしれません。そういった選択肢や可能性を増やしてあげることも必要ですよね。
行き来することで、元々の自分の部署に戻るとなった時に、違う部署の良いところ、悪いところを持ち帰って共有する、そういう人を介した情報共有も可能になったら良いのではとも考えました。
――色々な要素が詰まっていますが、この着想は、どこから生まれたのですか。
三口：例えば第三開発部が部署としてほしい人材、第二開発部で渡せる人材がアサインされれば良いのですが、異動となると“もう戻って来ることができない前提”があると思うのですね。少し短い2週間～1カ月というスパンで、行ってみて学んで戻ってくる。戻ってくることが可能であれば、もう少し気軽に他の部署をのぞいてみようという考えも起こってきます。そういった発想を言語化して関係者に説明する時に「旅行」という言葉が浮かんできました。
まあ、「移籍」＝「移住」だとすれば、事前にその場所について調べるフェーズがあってもいいですよね。いきなり住むのってハードルが高いので、まずは「旅行」にいって、その後戻ってくる。すごく良ければ、もう少し長い期間、例えば留学みたいな形で2～3か月滞在してみる。それでもやっぱり住みたいと思えば移住します。そんな表現を使えば、皆、理解できるのではないかと思い、「異動」という言葉を使わないで説明しました。
――異動のハードルを下げて、事前部署を理解する期間を「旅行」としているのですね。仕組的には問題ないと思いますが、企画時点で想定しているハードルがあったら教えてください。
三口：もちろん旅行に行くメンバーは、所属部署で必要だから採用しているわけで、その人の工数は計算に入っているわけです。当然、異動や短期的な留学をしたいとなると、その分の工数が減るわけなので、その補填はどうするのか？という課題が生じます。そのため、送り出す側の部署に協力をお願いしないといけません。
受け入れる側としても、人が増えたから工数が加算されるわけではありません。短期間のアサインでは、下手をしたらプロジェクトの説明をして、慣れたらサヨナラとなるため、計算には入りません。数字だけを見ると、送り出し側の人口が減って、受け入れ側が増えるのだからトントンだと思われますが、実質的な工数はお互いに減るわけですから、両部門に負担がかかります。短期的に結果を求めるのは厳しいですし、実質的に痛みを伴う施策であることは重々理解しています。
ただ長期的に見れば、今までできなかった技術的なブレイクスルーはもちろん、情報共有によって、もしかしたら失敗が回避できるようになるかもしれない。効果としては少しずつ回収できるものだと確信しつつ、まずはやってみようという話になりました。
――ところで、この調査旅行の間の人事的な評価はどうなるのですか？
三口：大事な質問ですね（笑）。そのあたりも当然議論のポイントになりました。まだ起きもしないことを心配して、色々と議論するのは無駄だよねということで、まずは1回目の2週間をやってみて、評価を考えようということになりました。
これについては、「参加するだけでも評価しましょう」という考えももちろんありました。そうしないと、誰も参加しないという懸念がありましたし、1発目に参加することはそれなりに勇気が要ることですから。
でも最終的に参加するだけでは、「評価をプラスにすることも、代わりにマイナスにすることもしない」という結論にいたりました。今回の旅行を通じて、すごく良いものを持って帰ってきた、行った先でも価値を発揮した、など良い評価がお互いにつくのであれば、それはプラスにしてもいいよねという話になりましたが、仮に失敗したとしてもマイナスの評価にはならないようにしました。
――それは留学も一緒ですか。
三口：留学については、もう少し議論があり、評価に入れてもいいのではないかという話はありましたが、ここは人事上の問題がありまして、現在も検討中です。3か月ごとのQ内に収まるように進められれば良いんですが、そんなきれいに収まるプロジェクトがあるわけではないから、それは厳しいよね、ということになりそういう意味で留学は２カ月になりました。ワンクォーター内でどうにか収まるような感じで受け入れが可能であれば、評価にも入れることはできなくない、という感じですね。
――施策の背景や評価への組み込みも検討していることも理解してきました。旅行者の人選は、どのようにしたんですか？
三口：まずは、各部署が何をやっているかを、マネジャーに動画で説明してもらい、それを見たうえで興味のある部署をアンケートで答えてもらい、その中から選定しました。もちろん、初回は重要です。良い結果につながりそうだったら、2回、3回目と続いていきますが、参加者が単に「面白かったです」くらいの感触しか得られないようでは、次につながりません。ですから、今回は現在所属している組織の良い面、悪い面を伝えられる人で、短い期間であっても何らかのインプットをしてこようという意欲がある方を選定しました。
受け入れ側の第三開発部は、半年前からスクラムに取り組み始めていて、そのあたりのエキスパートでもありました。この組み合わせであれば、お互いに学べるものがあるのではないかと踏んだのです。
――今回の応募は何件くらい集まったのですか。プレで試すのは、まず1人だったわけですよね。
三口：47人にアンケート回答をしてもらった中で、「行ってもいいよ」と言ってくれたのは13人。実を言うと、“応募する人は全然いないのではないか”という悲観的な観測もあったので（笑）、それなりに行きたいという人がいてくれて、正直、ホッとはしています。行き先の希望も偏るのではないかという危惧もあったのですが、意外とバラけましたね。
今回は、この施策自体に慣れてもいないので、“送り出してこんな大変なんだ”“受け入れるのはこんな大変なんだ”という混乱が一気に起きてしまうとお互い疲れてしまうので、まずは1名を送り出し、1部署で受け入れる、ということになりました。
――調査旅行の期間はどれくらいでしょうか。
三口：調査旅行は2～3週間程度です。もっと短くてもいいかとも思いましたが、それだと単なる体験になってしまうので、もう少し長めにということで、そのくらいの期間を定めました。留学になると2カ月程度になる予定です。
大切なことは“お互いを知り、助け合う事”
――これを通じて、浸透させたい文化、もしくは醸成しておきたいものがあったら教えてください。
三口：そうですね、壮大な理想で、まだまだ全然足りないのですが、エンジニアリング統括は、内省を推進していく部署としての目指す組織状態を定義しています。
そこでは、こんなふうに表現をしています。
自分が担当しているプロジェクトにロイヤリティがあること自体は良いこと。ただ、自分のプロジェクトさえうまくいけば良いのではなく、他部署の取り組みにも興味を持ち、必要があれば取り入れ、また応援出来ることがあれば応援する。
あるいは、自分たちの部署でうまくいった情報を他の部署に共有しようという意識を当たり前の行動にすること。
パーソルキャリアのエンジニアとして、また内製開発に携わる人間として、どんどん自分から発信していくことや、逆に困っているところがあれば自分が名乗り出て手伝っていくようなチーム、組織であればいいというのが前提にあります。お互いを知らなければ、そういう気持ちも沸かないと思いますし、共通理解が生まれません。お互いを知る企画も立案していますが、それぞれの共通理解を深められればと考えています。
お互いやっていることは違う前提で、“こういった新しいツールの取り組みを、そちら側でも使えるのではないか”とか、“うちでは採用しないサービスだったが、そちらのプロジェクトだったら使えるよね”という発想や会話が自然に生まれることが理想的ですよね。
――確かにお互いを知ることは、大事だと分かっていても、用意された資料を読んだり、口頭で伝えあうだけでは足りないことも多そうですね。本当の旅行でもガイドブックやテレビ番組だけではわからないことがいっぱいあります。
三口：そうですよね。旅行は非日常、通常の生活では得られないものを得るのですが、単に雑誌やテレビで得た情報ではなく、現地に行って現地の生活をして、やっとわかる事があると思います。それでまた行きたいと思う、それは他の組織においても同じことかなと思います。
異文化交流というものです。そういうのは体験しないとわかりません。頭の中だけの理解ではなく、実際に体験すると、こういうことなのだ、あんなに厳しい所を潜り抜けているサービスなんだねと思えるようになる。実際にやった人の話を聞かせるのはもちろん、実際に体験させたいという気持ちがあります。
第二開発でも人の理解、コミュニケーションを大事にしています。あとはダイバーシティと言っている中で、外国人の方も採用しています。共通の理解がないと、そもそも言語が違うし文化が違いますし、ベースになる物がないとコミュニケーションができません。
同じことを言ってもイメージが違うという事が起こりうるので、やはり基本的には完全に分かり合えた気になっているだけで、同じことをイメージできる共通の体験が、それぞれの理解を進める上では必要になってくるのかなと思います。実際に同じ釜の飯を食うという事と同じ話で、実際に触っていただいて、百聞は一見に如かずではないですが、こういうことだったのねという実感がわかってもらえるのかなと思います。
――共通の体験をするという事はとても大きいですね。これってエンジニアの世界だけでなく、ビジネスサイドも含めてやってみると面白そうですよね。
三口：それもあると思います。恐らく、企画側の人も実際の作業を目の当たりにすると、“こんな大変なことをやっているのか”“自分たちはできないな”といった実感の中から、お互いのリスペクトが生まれ、自分が苦手な分野をカバーしてくれるメンバーと共に、チームとしてやっていこうという意識が醸成されるのではないでしょうか。
企画と開発の仲が悪くなるというのは、よくある話ですが、それはお互いの理解が足らない、共通の言語がないから起きるのでしょう。ちゃんと実感を伴ったイメージの共有ができれば理解も生まれ、アイデアの交換も活性化されるに違いありません。
――そうですね。お互いを理解し、共通言語で話していくことが良いチームを生み出しますね。この施策が始まることがとっても楽しみになってきました。次回は実際に旅行に出るメンバーに話を訊きます！お楽しみに！
（取材・文＝伊藤秋廣（エーアイプロダクション））
三口聡之介 Sonosuke Mikuchi
サービス企画開発本部 サービス開発統括部 エグゼクティブマネジャー
京都大学在学中に、株式会社ガイアックスの設立に参画。その後、KLab株式会社で携帯アプリケーションの開発に従事したのち、楽天株式会社に入社し、プロデューサーとしてMyRakutenなどを担当した。2013年から株式会社百戦錬磨に参画、取締役に就任。2013年にとまれる株式会社を設立、代表取締役社長に就任した。その後、ベンチャー企業複数社を経て2018年2月からパーソルキャリア株式会社に入社。サービス開発統括部のエグゼクティブマネジャーを務めている。
※2020年11月現在の情報です。
