パーソルキャリアで内製開発の推進を担うエンジニアリング統括部には、4つの開発部があり、それぞれ担当領域が異なります。それゆえに、実は現場において「他の開発部がどんなことをやっているかイマイチよくわからない」なんて声が上がっていたりします。そこで、各部門の現場ではたらくエンジニアが集結。それぞれに感じている課題や提案事項などを本音ベースで共有してもらいました。
※2020年11月に取材を行い、撮影時だけマスクを外しています。
※三口は退職していますが、本人の同意を得て掲載を継続しています。
巨大なDBを扱っているからこそ、情報のありかをオープンに。
――エンジニアリング統括部の目指す組織状態について、現時点でのKPT（Keep・Problem・Try）を教えてください。
三口：今年（取材当時：2020年）の7月に目指すべき組織というものを皆さんに伝えました。目指すべきということは、実現できていないということですね。内製化、かつ様々な部署に分かれている組織としてどうあるべきかを考えました。もちろん、実現するには何年もの年月がかかるのはわかっています。
まずは何に取り組むべきかということで、直近の課題として、“もったいないこと”の改善というものを掲げています。
現在、開発部が4つあり、大きくは以下のような領域を担当しています。
第1開発部：主にdodaの基幹システムARCS（アークス）の開発
第2開発部：Webやアプリを中心とした新規サービスの開発
第3開発部：dodaやiXといった主要サービスの開発
第4開発部：dodaキャンパスのサービス開発
当然作っているものが違いますし、そもそもルールが違います。しかも、そのルールは全員に共有されていません。自分たちが抱えるであろう課題を回避していくためのルールが各自にあり、それが統一すべきところもあれば、全員に当てはまらないルールもあります。
そして、皆さんそれぞれの中で攻めているので、その中で成功したり失敗することもありますが、それ自体が共有されていないということもあります。せっかく色々と試していて、例えば他の開発部ですでに試していたことがあるかもしれないのに、それらが共有されていないといった、もったいないことが起きています。
また、“この会社の中で自分のやるべき事は終わったから転職しよう”と考えたときに、実は他の開発部では自分が学べる事がたくさんあるかもしれないのに、他の部の情報が分からないので、結局はキャリアパスが閉じてしまっているという問題もあります。これも、とてももったいないですね。
そして、BITAでは勉強会の仕組みがありますが、他の開発部ではまた違う仕組みがあります。その内容に興味があったとしても、やはりやっている業務自体が違うので、使うことがないから学ぶ必要がないということが起きやすいです。共有したいけれども、共有してもあまり効果がないということも起きています。
ちょっと周りを見渡しても、こんなに“もったいないことだらけ”なので、それが改善できる仕組みを考えました。まずはエンジニア循環施策として、実際に別の部署に行って話を聞いてきたり、自分の部署の良いところを他部署に伝えたり、他部署で学んだことを持ち帰って自分の部署でも展開するといったことをはじめています。
またコロナ禍のなかで、部署内でも雑談ができなくなっているかと思います。新しいアイデアや気づきを生むという意味で、雑談って重要ではないですか。なので、部署を超えて、エンジニアとして気になっていることを話し合えるような場作りもはじめました。
――それぞれの業務内容が違いすぎるがゆえに、“もったいないことだらけ”なんですね。共有の重要性について、現場の皆さんはどのように感じていますか。
角本：人によって違うと思いますが、私は技術的な情報が好きなので、めちゃくちゃ人の話は聞きたいですね。例えば、最近はクロスプラットフォームで開発することが主流ですが、第2開発部で利用しているFlutterが React Nativeと比べてどうなのかといったことなど、私が所属している基幹システム側だとなかなか使えないテクノロジーを社内で使っている人がいるというのは楽しいですし、その話は聞きたいと思います。
一方で、チームを見てみると、必ずしもみんながそうではありません。技術が好きな人もいるし、組織や社風が好きという人もいるので、全員が共有すること/されることを求めているか、というと難しいと思います。でも、その情報があるなら、好きな人は見に行くと思うので、その場があるかどうかが重要です。
金子：第2開発は新設された部署でもあるので、最新の技術を使っていたりもするので、正直“これを共有してもニッチすぎるのではないか。他部署ではあまり使われないのではないか？”と思うことはあります。
それは裏を返すと、例えばdodaアプリをどのように作っているか？など知らないことが多いということでもありますね。自分たちが作っているアプリとdoda側が連携するときの手続きや、裏側で動いている基幹システムが動く構成などは知りたいと思います。そのバックボーンが理解できれば、こちらも先に気を利かせて動くことができると思うので、その点が気になっていますね。
業務上で知っておかなければいけないことはもちろんですが、やはり個人的に興味が深い、技術的なことを理解することによって、会社が良くなる方向に進むのではないかと思っています。そのほうが働いていても面白いですし、仕事の成果も上がっていきますね。
――第3開発の中澤さんはいかがでしょうか。
中澤：技術面に関しては、好きな人が、思い立ったときに出席できる、シームレスな勉強会が必要だと思います。業務上必要なのは、サービスや今の仕事に関する知識の共有です。僕も毎日、発見があるほど大きなサイトを担当しているので、そういうものが見つかる度に共有した方が良いと思っています。それはなぜ作られたのか？という背景を知っている人はほとんどいないので、毎日のように悩んでいますが、その悩みを解決する度に循環施策の中で少しずつ伝えています。しかし、本当は自分のチーム内や、わりと絡むことが多い第一開発部と共有したいと思いますね。
角本：同じdodaを取り扱っている側ですが、全く交流が無いですね（笑）。
中澤：そうなんですよね。私たちのグループにも、ITコンサルタントや企画を通して要望がきますが、作り終わった後に、“こちらが対応すべきではなかった”と気がつくケースもあります。また運用してみると、我々が持っていても意味がないと気づくものがあります。
角本：そういうものって、横串で分かっていないと判断するのも難しいですね。
中澤：そう。やはり事業として強くなるためにも、横串連携は必要だと思います。そうでないと、本当に無駄が多く、力が分散させるようなイメージですね。
――それは組織構造に問題があるということなのでしょうか。
三口：組織が大きいこともありますし、役割が分かれているということもあるので、ある程度はその方が進めやすいということがあります。しかし、それが続いてきたのでタコ壺化の状態になり、情報が行き来しないということが問題になりつつあります。
――開発部を繋げるためには、どの部分を共有することが重要だと思いますか。
中澤：“どこ”というよりも、データですね。自分たちはどういう情報を持っているのか、他と比べて何に強い情報を持っているのかということは、オープンにしなければなりません。各チームの各論としては、“実はこのデータにはこんな意味があるから作っている”というのがあるはずですから。
角本：それを知っていれば、私たち第一開発部も助かりますね。データベースが巨大すぎて、全てを把握するのはチーム内でも半ば諦めと言いますが（笑）。まずは自分たちの範囲を掌握して、それから全体を把握しようという流れになっています。今は社内全体で巨大なデータベースを共有しているので、これを総括して全てを把握している人はいないのではないかと思うので、誰かが整理しなくてはならないとは思いつつ、自分たちもなかなか実行できていないという状況です。
――中澤さんがおっしゃるようにデータの共有も必要だと思いますが、三口さんのおっしゃるような、それぞれが実行したことや施策の共有についてはいかがでしょうか。
中澤：失敗は知りたいですね。完全な失敗だけではなく、「ここに障害があったからこのようにした」といったような経緯も踏まえて知りたいです。パーソルキャリアには“成功ありき”のようなところがありますが、もちろん人に伝えるときにネガティブだけを伝えても仕方がないので、ゴールとしてプラスになるのは良いことですが、“なぜ最初にその設計にして失敗したのか”という失敗の深堀が薄いと思います。
――なるほど。第4開発の森さんは、どのように感じていますか。
森：情報の共有というところで言うと、組織やエンジニアの働き方の問題かもしれませんが、やはり中の人がどんどん変わっていく中で、元仕様の理由を知っている人がいなかったり、やっている内に発見するということはどこにでもあるように思います。私の部署でも人の入れ替わりが激しいので、情報の共有というのは課題としてあると思います。
また狭い話で言うと、私が担当しているデータ基盤整備の領域は、他のメンバーには関係のない話だったりします。データというのはプロダクトが動いてから最後に出てくるところなので、私がやっていることが開発の人たちに影響することはほとんどありません。
全員に通じて言えることは、第4開発に所属しているメンバーは、主務がベネッセさんとの合弁会社であるベネッセi-キャリアなので、パーソルキャリア側の情報が入ってきにくい環境です。そもそもネットワークが違うのでパーソルキャリア側にアクセスすることも大変です。
三口：皆さんの話を聞いていて、横串で連携するための専用組織を作らなければならないと思いました。例えば、角本さんが第一開発部で“これは他の開発部でも使った方がいい”と思ったところで、自分の枠の中で各部へ展開するのはかなり大変だと思います。各組織から人を集めて委員会という形を取った方がいいと思いますが、人を集めてどうあるべきかを議論し、そのチームにはある程度の権限委譲をして動かさなければならないと感じました。
また、人材に関しても、各部が違うことをやっているので、違うスキルセットを持つ人が必要ですが、将来的なことを考えると、例えば内製エンジニアとして必要なマインドセットなどは、もちろん各部で最適化をする部分もありますが、共通にする部分もあると思います。しかし、それを現在の枠組みの中で統一化していくのは難しいですね。
――どうして難しいのでしょうか？
三口：今はそもそも情報が足りないので、こういう場もまさにそうですし、エンジニア循環施策もそうですが、とりあえず「各部で違う」ということをみんなに知ってもらうことが重要だと考えます。そこから一歩進み、権限を持たせるような形で、兼務かどうかはまだ分かりませんが、”横串をする“という組織を作らなければ上手くいかないと思いました。
それぞれの部署に存在するローカルルール
――「ルール面」を切り取ったときに、皆さんの組織のローカルルールってどんなものがありますか。例えば、出社or在宅なのかは選べていますよね。
角本：第1開発部は、今はほぼ毎日リモートです。輪番制も敷いていません。新しい人が入ったときの受け入れなどで出社するくらいですね。
中澤：第3開発部は、週1で出社しています。スクラムをやっているので、スクラムイベントで出社をしていますね。緊急事態宣言時はすべてリモートで頑張りましたが、やはりスクラムイベントや棚卸しをして何かしたいとなったときには、なるべく顔を合わせるようにしています。出社する曜日は各スクラムで違います。
三口：ってことはたくさんのスクラムに入っていると、たくさん出社しないといけないの？
中澤：基本的に一人あたり1つですね。
三口：スクラムは2週間？
中澤：僕のチームは2週間に一回のペースに変更しましたが、他のチームは1週間に一回のままです。
三口：1週間でやってるんだ！
中澤：スクラムは1週間でできることをやって、リリースして直していくという開発手法ですが、うちは大きなサイトを担当しているので、1つ直した影響が大きく、1週間では作り切れないのですね。それで2週間にしてもらった経緯があります。
角本：1週間ってリリースで切ってるんですか？
中澤：リリースは純粋に1週間で切っています。（一同、驚き！）人材紹介チームからの重ためのオーダーがくると、スクラム内で別途リリーススケジュールの調整をします。この辺は柔軟ですね。1つの機能であっても、あらゆる箇所を変えなければならないことがありますが、他部署と絡むものはリリース日をこちらで制御できないので、教科書的なスクラムに向きません。現場の営業側に周知をする必要などもあるので、いつどのような形のものができ上がってくるのかを明確に伝えてあげなければ進まなくなってしまいます。最後にどんでん返しの変更などもあるので、最低限の根回しをしておかなければ、リリースができなくなってしまいます。
――第2開発はどうですか？
金子：第2開発部もリモートです。スクラムもリモートで行っています。スクラムイベントもweb上でやっていますが、プロジェクトによってルールが若干違います。「マイポテ」は毎月、リリースがあるので、そこに合わせてスクラムを追い込んでいます。だいたい1週間ごとにタスクを上げていき、最後の週にリリース活動をやるという動きです。
森：私たち第4開発部も、4月からずっとリモートです。出社することもほとんどありません。今は2週間でスプリントを回していますが、イベントもすべてリモートですね。
――スクラムの回し方や働き方に違いがあるというのは、業務内容が違うからでしょうか。それとも考え方の違いでしょうか。
中澤：どちらかというと業務内容依存が強いと思いますよ。
角本：第1開発部はスクラムではありませんが、月に2回の定期リリース便が決まっているので、そこに合わせて修正のチケットをあげていき、決まった日までにテストを実施したうえでリリースをしています。スクラムのようにスクラムマスターが仕切っているというわけではありませんが、小さめのウォーターフォールを回しているという感じですね。
――他にも違いがあったりしますか。
三口：やはり開発環境が違うので、PCのスペックが違いますね。例えば基幹システムを扱う開発部は、機密情報などを取り扱うLANと繋がなければなりませんが、第2開発部が使っている開発用PCではそのLANには繋げません。バージョン管理はどうしてる？
角本：バージョン管理はGitを使っているのですが、GitHubは見られません。当社では、機密情報の漏洩防止のため、当社のネットワーク環境下だと一部のサイトに接続制限をかけています。その関係で接続ができないんです。そのためうちのチームでは、社内でAzure DevOpsというGitHubのようなCI/CDのツールがMicrosoftのサービスにあるので、それで管理しています。
金子：使ってほしい…便利なのに…。
角本：そうですよね。最近はいわゆるOSSという、みんなが開発して使うようなライブラリーやフレームワークがたくさんあり、それを使うことが多いです。そうするとGitHub上に使い方などが載っていて、問題があるとIssueで調べることができますが、GitHubが見られないとそもそも調べることができません。
三口：すでに他の人が解決しているかもしれないのに、それを見られないんだよね。
角本：そうなんです…だから、スマホで頑張って見ていますね（笑）。
――スマホ！これまた…少し業務がしづらいですね…。中澤さんはどうですか？
中澤：実際に入れてみると、dodaのソースのバージョンによっては使えない場合もあるため、検証がしたいのですね。しかしGitHubからソースが入れられないし、ライブラリも入れないので、検証するようなものは動かして検証するところまではいけなくて、“たぶんできる”という仮定から入らなくてはなりません。バージョン管理もリアルでパッと見られないのですよ。
三口：dodaの開発も専用LANに繋がないとダメなの？
中澤：（繋がないと）ダメですね。疑似環境にそもそも繋ぐのに必要なんです。
角本：データベースも当然繋がないとダメですし、連携しているシステムや関連しているジョブやバッチも動かせないので、基本的に開発が成立しない状態になってしまいますね。
中澤：結合試験環境が非常に大事です。他のシステムと連動しなければ出てこないバグがたくさんありますが、他のシステムときちんと繋がっている環境は、やはり専用LANに繋がなければなりません。バッチなどきちんと動かさないとテストになりませんし、自分の手で作ってしまうとテストになりません。
三口：第4開発部はその点、あまり困らないですね。別の会社なので、パーソルキャリアには縛られないですから。僕にはわりと良い環境を作ってもらっているように見えます。
森：そうですね。どちらかというとベネッセルールに基づいて動いていますね。
三口：ベネッセさんは個人情報に関して、厳粛なルールがあります。
中澤さんが言う疑似環境の話ですが、先日パーソルキャリアのセキュリティ部門のトップである根津さんと話した記事が出ましたが、その中でも疑似環境にまつわるルールをさすがに作らないとまずいのではという共通認識になりました。疑似環境は、世の中的な定義では個人情報にあたりますが、このコロナ状況下において、専用LANがないと使えない、というのではビジネスとして進めることができません。今は疑似環境を構築すること自体が大変なので、先ほど言ったような、横串のタスクフォースで突破をすることが必要かもしれませんね。
角本：チーム内の課題感などはやはりありますが、それをプラスαで業務の余剰にできるかというと、やり方が強大なのでなかなか難しいですね。
三口：目安箱のような課題を投げ込みできる場所があるといいですね。それを専門で見ている人たちがその課題について考えていけばいいと思いますね。
――皆さんのチームの中で開発を進める上での前提条件や、暗黙の了解などはありますか。
金子：GitHubにかなり依存しています。GitHub上でIssueを立てて、それに基づいてプルリクして、という体制は第2開発部だと、全チーム整っていると思います。ルールとして設けているというよりも、みんな自然とそうしています。当たり前にやっているという感じですね。私が入ったときはすでにそうなっていました。
三口：統一しましょう、という話は最初にしたかも。割と一般的な方法という感じです。
角本：GitHubは使えませんが、プルリク文化は一緒ですね。Git自体は使えますし、Azure DevOpsでもプルリクは出せるので、相互チェックはしています。しかしうちは初期開発でWordやExcelのドキュメントがたくさんあるので、そこも直して軽量化しようという話もあります。感覚的には相互チェックをするのはエンジニアにとっては普通のことだと思います。
中澤：第3開発部はルールのお勉強が必要になりますね。特殊なルールとなっている背景としては、運用をしているのはグループ会社であるパーソルプロセス＆テクノロジー社（以下、PPT）なので、リリースも含めてお任せしなくてはならないため、本番環境に全員が入れるというわけではありません。そのため、リリースするためのプルリクは誰に出すのかという話になります。最近は、そこに内製が絡み始めてきて、複数のベンダーさんが動いているような状態なので、プルリクの出し方はお勉強が必要です。一般的なプルリクに比べるとコストはあると思います。
角本：決定ファイルだけ違うブランチにすることがありますが、これは昔の保守の風習だと思います。昔の古い文化で風習的に残っているところがあるので、変えられるところは変えていますが、お願いするところはそのまま残っていることもあります。
中澤：もともと作ったCI/CDのツールがそれに対応しなければならなかったり、実際にGitに移行して運用して生まれた課題なので対応できないといったこともありますね。一般的なGitHubでやるというよりもお勉強コストがかかりますね。
――PPTさんの話で思ったのですが、外部ベンダーの活用も各部で違いそうですね。第2開発部はベンダーさんを使っていますか？
三口：使っていませんね。業務委託が何名かいるだけです。
角本：第1開発部はPPTさんとSky社にお願いしています。規模の大きなプロジェクトは、内製開発チームと別のラインで開発して受け入れています。やはり本番環境を直接触る人がPPTさんなので、お願いしなくてはならないところがあります。
森：第4開発部は、一部“このサービス限定”でベンダーさんがいるみたいですが、私は直接の関わりがないので分かりません。一緒に仕事をしている方たちは、協力会社の方に常駐してもらっています。
三口：協力会社の方々は、チームの半分くらいですよね。第4開発については、独自で依頼しています。基幹システムのようなものもあり、それは大きめな規模のところにお願いしていますね。
現場同士の協業や交流が新たな価値を生む
――これまでの歴史を受け継ぎながらやっているという感じですね。それによってルールも違ってきますね。キャリアやステップアップのために取り組んでいることや、勉強会などの違いがあったら教えてください。
角本：組織内では、今は特に決まった勉強会などは開催されていません。業務知識の共有などで、9月、10月で新しく入ってきた人がいるので、オンボーディングの目的での共有会は行っています。しかし、例えば新技術に対する報告会などはあまりありませんね。
どちらかというと社外の勉強会に参加していることが多いです。社外に情シスに関するコミュニティがあり、友人とともに登壇資料を作ったりはしていました。最近ではMicrosoftから.NET5が新しく出たので、その勉強会に参加してきました。周りに好きそうな人がいれば誘って一緒に参加しますが、みんなが興味あるのかというとそういうわけでもないので、僕もグイグイやっていません。
三口：その点では第2開発部は目標に入っていますね。それによって給料が変わります。
金子：そうですね。勉強会を開催することを目標に入れていたり、テーマについても目標に入っています。行動については勉強会が第一ステップで、記事を上げたり登壇したりしないといけません。
三口：勉強会をするということは、アウトプットするということですね。
金子：はい。やはり、勉強をしたままで外に出さないのはもったいないという意識になります。アウトプットができないとまとめることもできません。
中澤：第3開発部は、飯田さんをリーダーとした勉強会、通称「マサミ会」（名前から命名）を2週間に一度開いています。
僕もその勉強会で発表するという目標を立てていましたが、偶然にも関係ないところで他社との関わりができて、ほかイベントでも登壇することになりました。マネジャーも、アウトプットすることでプレゼンスキルの向上や採用に繋がると考えていたところだったので、積極的にチャレンジしましたね。ありがたいことにチームのみんなには僕が作った資料を叩いてくれました（笑）。大規模イベントの登壇は初めてでしたが、作った資料をレビューしてくれる人がいる状態だったので、本番はずいぶん気楽に臨むことができました。
先日の「マサミ会」ではBFFについて話していました。毎回題材を決めて行いますが、いつも最後は同じで「dodaへの導入には難しいね」という結論になりますね（笑）。dodaに導入する際の問題を箇条書きで書いて、それでいつもシートが終わります。
――第一開発部では…。
角本：そうですね…勉強会の文化があればいいと思いますが、今のところはありません…。でも、やってみたら意外に集まるかもしれませんね。最近は人が増えてきたので空気も変わりましたからね。
金子：「勉強会」っていうハードルがあるのかもしれませんね。うちのハードルは低めで、エンジニアリングに関係のないことも発表することがあります。先日の勉強会は“リモートワークにおける健康法について”でした（笑）。エンジニアリングの内容も当然やりますが、例えばOOUIなど、エンジニアリングの内容とは少し離れるようなことでも勉強会で話しています。スクラム開発について話をしたこともありました。
角本：そういう意味だとライトニングトークといって、自分の好きなテーマで話すということをエンジニア同志でやっています。プレゼン資料を作ってストーリーとして話すことは練習としてもとてもいいと思います。その文化があると気楽に話せるかもしれません。
森：勉強会というとカチッとした聞こえになってしまいますが、ベネッセi-キャリア側では月に一度エンジニアだけが集まるエンジニアミーティングというものがあります。そこは勉強会というほど何かコンテンツを用意してがっつりやるというものではなく、新しい試みの共有や、自分のやっている開発で困った点とその解決方法の共有などをゆるくやっている感じですね。また、新しいエンジニアが入ってきたときに、自己紹介をしたり質問をしたりして、交流する場としても使っているので、あまり勉強の要素は少ないですね。仕組みだけがあって、中身は臨機応変にという感じですね。
――最後の質問です！現時点で、現場同士の協業や交流の在り方ってどんなことができそうだとお考えでしょうか。エンジニアとして得たいノウハウ、データ活用の在り方など“こんなことがあったらいいのに”ということも含めて教えてください！
角本：第3開発部もそうかもしれませんが、社内の守りのシステム側なので、どうしても制約的に厳しいものを扱っています。反対に、サービスを作って提案しているという部署が会社内にあるということは頼もしいと思っていますね。自分たちが守っている間に攻めのサービスを作っている人たちが社内にいるということは、とても心強いと思うので、だからこそ両者の内容を共有するということは大きな意味があると思います。
仮に基幹システムだけをやっていて行き詰ったとしても、サービス開発をする部門が社内にあり、そちらに異動して開発ができるというキャリアパスがあれば、エンジニアとしてもわざわざ別の会社に行かなくてもよくなります。エンジニアの幅を広げるという意味でも、社内での情報共有ができるといいなとは思います。
金子：技術的にも守りや攻めという話はあったと思いますが、共通して使っている言語であったり、前職などで使っていた言語など、今携わっているプロジェクトと今まで経験した言語などを照らし合わせると、聞きたいことがお互いに出てくると思います。その点をリストアップして雑談ベースで話すだけでも良いことがあると思います。
――皆さんのこれまでの経歴の中で共通項があれば、話の幅は広がりそうですね。
中澤：部署が分かれている中で、だんだん相手の顔が見えるようになってきたので、それぞれの部署ごとにポータルサイトを作って質問を投げ合ったりできたらいいですね。セキュリティの壁があるのでSlackしかないと思いますが、そういうものを活用できるといいな、と思いました。PPTさんに聞いて、あちらもチケットの優先度順に消化していき、終わったら回答するという状況なので、そのあたりをシームレスに聞けたり話せたりすると、お互いにハッピーになると思います。
森：お互いにサービスは違いますが、似たようなことをやっていて、他の場所で応用できるようなことを皆さんやっていると思いますが、誰がどのような情報を持っているかが見えませんし、声をかけて聞くということもなかなか難しいです。なので、その点がもう少し可視化されたり、誰がどのような情報を持っているのかが気軽に声をかけられる形になると、もう少し情報共有もされてくると感じました。しかし、いきなり知らない人と話すのはハードルが高いので、そういうことも含めて緩和されるような仕組みがあるといいなと思いました。
三口：金子さんが仰っていたスキルマップは作ろうと思っていましたが、その段階に至っていないということで、まずは各文化を知るような施策から始めています。そして、そろそろ次のステップにいく必要があると感じていました。スキルマップや勉強会の投げ込みができるような場所もそうですが、共有することを促進するタスクフォースを作り、施策について考えはじめたいと思います。それについて“いいね”と思ってくれる人、さらには行動してくれる人も何名かはいると思うので、そういう人たちに入ってもらい、“試しにこういうことをやってみよう！”ということができれば、もう少し活性化が進むと思いました。
――それは開発部からメンバーを集めて作るってことですね。
三口：その方がいいかなと思っています。1人だと責任が重くなってしまうので、2人くらい各開発部から出てもらうのがいいかなと。そこで“もっとこうしたらどうだろう”みたいな議論ができたらいいですね。自分の部署からはその委員会の人に投げておいて、その人が集めて、その部署の問題共有や解決方法を話し合ったり、共同で解決したりができたらいいなというイメージです。早速、実行に移したいと思います。
――内製開発を推進するエンジニアリング統括がさらにパワーアップするイメージがわきました！素敵なお話をありがとうございました。
（インタビュー・編集＝伊藤秋廣（エーアイプロダクション）／撮影＝古宮こうき）
三口聡之介 Sonosuke Mikuchi
エンジニアリング統括部 エグゼクティブマネジャー
京都大学在学中に、株式会社ガイアックスの設立に参画。その後、KLab株式会社で携帯アプリケーションの開発に従事したのち、楽天株式会社に入社し、プロデューサーとしてMyRakutenなどを担当した。2013年から株式会社百戦錬磨に参画、取締役に就任。2013年にとまれる株式会社を設立、代表取締役社長に就任した。その後、ベンチャー企業複数社を経て2018年2月からパーソルキャリア株式会社に入社。サービス開発統括部のエグゼクティブマネジャーを務めている。
現在は退職。
角本 良幸 Yoshiyuki Tsunomoto
エンジニアリング統括部 第1開発部 システムアーキテクチャBITAグループ リードエンジニア
新卒でSIerへ入社後、物流系の業務システムを中心に携わる。また、AzureやAWSといったパブリッククラウドを利用したシステム開発やクラウドリフトに従事。2019年10月にパーソルキャリアへ入社。現在は、社内基幹システムの内製開発チームにて、システムやアーキテクチャの改善を担当している。
金子 広大 Kodai Kaneko
エンジニアリング統括部 第2開発部 エンジニアリンググループ エンジニア
前職は中規模の人材紹介会社。toC向けのアプリケーション開発でiOSとAndroid両方のアプリで企画や開発、運用などに携わる。2019年12月にパーソルキャリアに入社し、マイポテの開発に携わる。
中澤 勝 Masaru Nakazawa
エンジニアリング統括部 第3開発部 エンジニアリンググループ リードエンジニア
前職は独立系SIer。携帯キャリアの業務システム開発など幅広い業務システムに携わる。2018年6月にパーソルキャリアに入社し、EFOなどdodaサイト開発に携わる。
森 達裕 Tatsuhiro Mori
エンジニアリング統括部 第4開発部 エンジニアリンググループ エンジニア
アルバイト求人情報「an」の開発を担うWorksBITAや、全社のデータ基盤整備などを担うデータ共通BITAを経て現在ベネッセ-i-キャリアへ出向中。パーソルキャリアに入社してからは、主にデータ基盤を整える業務に従事しています。
※2021年1月現在の情報です。
