エンジニアが幸せになる組織を目指す―――新たな「はたらく」を作り出すための柔軟な開発力とは?

alt

 「必要な人に素早くサービスを届けるため、エンジニアリング力の最大化」というミッションをかかげながら、急ピッチに組織の拡大を図る“サービス開発統括部 エンジニアリング部”にフォーカス。

”集まったエンジニアが幸せになる組織にしたい”といつも話すのはエンジニアリング部でマネジャーを務める鹿野。組織づくりや開発に対する考え方を訊いてみました。

※本取材は5月にリモートで実施しました。

僕たちは0→1でサービスを作りたくてこの会社に入った

――今日はオンライン取材よろしくお願いします!鹿野さんは、現在仙台で働かれていらっしゃるんですよね?

鹿野:はい。仙台に生まれ育ち、新卒1社目は、東京に勤務していました。結婚して子どもが生まれてからは、やはり育児環境という面からも仙台で子育てがしたいなと。それ以来、ずっと地元で働き続けていますね。

 

――仙台のTech人材事情って、どんな感じですか。

鹿野:IT技術者はどうしても首都圏に集中しがちです。仙台と東京は距離的に近いですし、給与面やスキルアップ環境という観点からも、東京で働きたいと考える人は多くいらっしゃいます。しかも地元企業には技術者の受け入れ態勢が整っていないという問題もあります。

そんな中でも僕は、IT技術者が仙台にもう少し増えてほしいと思っているんですよ。仙台市では現在、積極的にIT投資を行っていて、技術者を増やし、企業を誘致しようと考えています。それによって、一度は東京に流出していった人材が「なんだ仙台でも働けるじゃん」と思えるような、安心して働ける場所が増えたらいいですよね。

alt

仙台市の取り組み効果もあり、最近は仙台でもITコミュニティや勉強会が活発に動いていて、学生や未経験者の人たちが自己学習しつつエンジニアとコミュニケーションをとり、活躍する環境が出来てきました。それって、僕が仙台に戻ってきた10年前にはなかったことです。もちろん僕もコミュニティに参加していますし、有償無償問わずにコミュニティが活発化していけば、もっとエンジニアが増えていくと思います。

 

――仙台を拠点に活動を続けている鹿野さんがどのような経緯でパーソルキャリアに入社されたのでしょうか。

鹿野:パーソルキャリアには2018年7月に入社したんですが、端的に言うと前々職の上長だった三口から誘われたんですよね。

以前、三口と一緒に働いていた時に初めて自社サービス開発を経験して、自分たちのサービスを自分たちで考えながら大きくしていく過程がかなり面白いと感じていて、、、。前々職ではやむを得ず離れることになりSIerに戻ったのですが、もう一度自社サービスをやりたいと常々思っていたので、声がかかったときにはとても嬉しかったことを覚えています。

 

――自社サービスといっても他の企業も考えられると思いますが、それでもパーソルキャリアへの入社を決めたのはなんでだったのでしょうか?

鹿野:そうですね。自社サービスの中でも「ゼロイチ」で新規サービスを開発する経験は貴重だと思って決めました。SIerだとしたら、お客様からの要件を整理して開発することが正ですし、規模の大きいWeb企業でも既存サービスの機能追加や拡張が中心。事業会社に身を置きながら、ゼロ→イチで開発タイミングにいられるというのは稀だと思い、詳細を聞いた後はすぐに「やります!」と返事しました。もちろん、僕が仙台にいられるならという条件付きでしたが(笑)。

ちなみに入社してから今日に至るまでは前回の記事でもお伝えしているので、合わせてご覧ください。


――前回もありがとうございました(笑)そして現在に至るわけですが、今期定めたエンジニアリング部のミッションについてご説明をいただけますか。

鹿野:「必要な人に、素早くサービスを届けるためのエンジニアリング力の最大化」というミッションをおいています。そもそもパーソルキャリアには「はたらいて笑おう」というビジョンがあり、それを実現するために、「人々に“はたらく”を自分のものにする力を」というミッションを用意しているという構造です。

今は「doda」という既存の大きいサービスがありますが、転職だけではなく、あらゆる世代の働く人々へサポートを拡張していくことが必要です。それぞれのターゲットに合わせた新しいサービスを複数立ち上げ、それらを通じて全体をサポートしていく必要がありますが、どのサービスがフィットするかは、実際に作った上でユーザーの反応を見なければ判断できません。

一つひとつのサービスを立ち上げるのに時間がかかっては機を逃しますし、的外れなサービスでもダメ。なので必要な人に素早くサービスを届けるというのは、ミッションの達成に深く関わっていきます。そのため僕たちは “素早くサービスを提供するために” エンジニアリング力の最大化と言うミッションを自身に課しています。

 

――そのミッションを、どのように実行していこうと考えているのでしょうか。

鹿野:まずはそれがターゲットにとって必要なのかどうかを検証するために、ミニマムなサービスを作ります。そこで一定の反響が得られるのであれば、もちろん作り込むべきだと判断します。ミニマムなサービスは外注ではなく、現状では基本的に内製で対応するのでリソースが限られることからも、すべての企画案を形にできるわけではありません。また、企画部門のメンバーもいるので、そこから依頼されて作るケースもあります。

僕が入社直後に手がけた最初のサービスは、企画案を中心に丁寧に要件を整理して作りましたが、本来は僕たちエンジニアも本気で企画に向き合い、しっかりとサービスの先にいるユーザーの課題を見据え、企画自体をブラッシュアップしていく気持ちがなければ、そのサービスの価値やクオリティは向上しないと思います。

エンジニアにとって開発する能力というのは単純に手段なので、難しい技術を使ったからといって必ず良いものができるわけではありません。本当にそのサービスに価値があるかどうかを考えて作る必要がありますよね。

エンジニアとしては要件通りに作ったとしても、自分から提案して作ったとしても、丁寧に開発は行われます。しかし、エンジニア自身がそのサービスに価値を感じて作らなければ本当に価値あるものは生まれないと思っています。と言うか、せっかく貴重なゼロ→イチ開発、本気で考えて、本気で作って、楽しまないと損です。

 

――エンジニアも意思をもってサービスを創っていかないといけないという事ですね。サービスを創るうえで、企画とエンジニアそれぞれの立場ではどのような違いがありますか?

鹿野:どちらがリードするかという話ではなく、双方でしっかり意見交換ができるかどうかが重要だと思います。サービスを企画する人にも“このサービスを使えばこのような世界になる”というビジョンがあります。しかし、その世界観がベストかどうかは、その時点においては誰にもわかりません。理想の世界を作るためには段階的なステップを実現しながら、その方向性が合っているかなど検証を重ねていく必要があります。その方向性を重ねていく中で、それぞれ違う立場から多角的に見て、議論していく必要があるのではないかと思うんです。

 

――そういった企画側とエンジニアとの間の理想的な関係を作るには、どのようにコンセンサスを得ているんでしょうか。

鹿野:個人的には、双方の歩み寄りが重要なんじゃないかと。私たちから企画側に提案を行ったり、企画側がエンジニア側への理解を深めてもらえれば、より良いサービスができると思っていて、そういったエンジニアリング部の考え方は地道にお伝えしていくべきだと思っています。

alt

例えば、エンジニアリング部内で社内勉強会を月に2回実施。毎週末には、その週の個人の成果などを発表するミニセッションを行い、個人としてのアウトプットを意識的に行えるよう評価制度にも落とし込みました。アウトプットは重要です。自分自身や組織をブランディングしたうえでアウトプットしなければ、社内にも社外にも広がらないので、とても大事だと思っています。こういった社内勉強会や、組織を超えた交流会、社外への展開も含めてアウトプットを意識してやっています。

 

――アウトプットが重要なのですね。

鹿野:そうですね。やはりアウトプットにより、自身のブランディングができることは大切だと思っています。会社や組織の看板で評価されるのではなく、自分という個人が評価されている状態。そういう状態の人が私たちの “新しい「はたらく」を作ること”に興味を持ってジョインしてくれているのが理想ですね。

エンジニアもゼロ→イチでサービスを作りたいと言っていますが、「どこを目指して成長していきたいのか」「最終的にどのようなエンジニア技術を習得していきたいのか」というのはみんなバラバラです。それをうまく会社のミッション・ビジョン・目標に紐づけたうえで、“このミッションに貢献することがあなたの成長に繋がる”とフォローしていく必要があると思います。

 

パーソルキャリアで働いたことが「エンジニアの幸せ」につながるように――

――エンジニアリング部内の体制や役割を教えてください。

鹿野:現在は「サービスアーキテクトグループ」「クラウドアーキテクトグループ」「エンジニアリンググループ」と3つのグループに分けています。

なぜかというと、今、僕たちはゼロ→イチで新規のサービスを作ることを任されていますよね。初期段階であれば、ミニマムでシンプルなものを作ればよかったので、正直ここまでグループを分ける必要がありませんでした。ところがひとつめのサービスができあがって、運用フェーズ、追加開発フェーズに入ってくると、事情が変わってきます。

今までは1つのチームだけでカバーしてこれたことが、徐々に画面を作るプロフェッショナルが必要になったり、追加開発をしながら別サービスの新規開発と更なるスピードが求められたり、サービスが大きくなるにつれてアクセス数が多くなり、それに耐えうるインフラやサーバーを用意しなくてはならないという状況になってきました。しかも僕たちはサービスに対しても物申す立場にあり、サービスデザインやUXにも言及しなくてはなりません。

エンジニアリング部が掲げる「エンジニアリング力の最大化で、新しい働くサービスをつくる」というミッションにブレはありませんが、それぞれに役割を与えて、組織のエンジニアリング力を底上げしようと考えたのですね。得意な分野で組織に貢献する、そんな意図があります。

 

――立ち上げ当時からサービスのフェーズごとにエンジニアとして求められることが変化してきているんですね。エンジニアリンググループはどんな役割ですか?

alt

鹿野:「エンジニアリンググループ」では、今後の僕たち組織が目指す開発環境や、技術の習得に関する方針や施策を考えたり、新しい技術をいち早くキャッチアップして、社内の関係部署で連携をはかりながらカタチにしていくことを意識しています。例えばAIまわりのサービス化では、dodaのデータを使った機械学習モデルを作成。自動で判別できるモデルを用意し、他の部署と連携してサービスに繋いでいきます。

とはいえ、一方で「素早くサービスを作る」というミッションも掲げているので、その実現のためには、ある程度自分たちの手でまかなっていかなくてはならない。今後必要となる、あるいは注力しなくてはならない技術領域はどこなのだろう?という指針を決めていきます。

 

――エンジニアリンググループが、横断的に全員で組織の在り方を考えるんですね。

鹿野:はい。そして現在は複数のプロジェクトが同時に動いています。僕が入社した直後はエンジニアが4人しかしなくて、それでも「複数のサービスを作る」と言われていたので、正直、“できるわけがない”と思っていました(笑)。

それで、エンジニアの採用に乗り出したのですが、まずは各プロジェクトで使用している開発言語や環境を共通化して、誰でもすぐにジョインできるようにしたのですね。もし途中でプロジェクトが変更になっても、使っている技術は共通なので、好きなプロジェクトにジョインできるという形を目指しました。

ただ難しいのは、いつまでも同じ技術で良いのかという点です。エンジニアリンググループとして議論しているなかで、新しい技術はどんどん出てくるので、チャレンジして習得していかなければなりません。エンジニアが幸せになる組織というのは、パーソルキャリアが魅力ある会社ならば、もちろん長く働けるとは思いますが、その人のやりたいことが別で発生したらいつかは離れていきます。そのときに「パーソルキャリアで働いたことで成長した。パーソルキャリアで働けて幸せだった」と思える組織の状態がいちばん良いと思うのですね。

それって、自分の成長を実感したときにはじめて思えることだし、その実感したことをアウトプットしてその上で成長して、また新しいレベルにチャレンジする。さらにアウトプットして成長するというループを回せる状態が幸せに繋がると思います。そういう組織になるように配慮しています。

個人が成長するループを作れるようにしながらも、即戦力で仕事をしてもらう必要があるので、共通するルールや技術は必要。そのバランスをとるのは難しいですが、そこはチームで話し合って決めるようにしています。全部が同じ開発環境ではなく、一部でチャレンジするという感じです。せっかく複数のプロジェクトがあるので、「このプロジェクトでは、この部分をチャレンジしよう」という形にして、総じて自分たちのやれる範囲が広がっていくというのが、今のところは良いやり方だと思って続けています。

 

――リーダーとしては、エンジニア個人の能力と、新しい仕事のどこにどのエンジニアをジョインさせたら最適なのか、その両方を把握していなければならないということですね。

鹿野:そうですね。組織ではコミュニケーションを重視しているので、自分にはどこのスキルが足りないのかというのは、自分自身はもちろん、周囲のメンバーも把握しています。プロジェクトにアサインするうえでは、本人の得意分野だけでなく、それ以上にもっと新しい、今後1年後、2年後も使える技術や今後も潮流となる技術にもチャレンジできるよう配慮しているつもりです。

リーダーには人心掌握力、技術トレンドに対するアンテナ、自分たちがやろうとしているサービスの中でそれをどのように取り入れて、その人をどのように成長させるかの3つの力がバランスよく必要になってきますね。 

互いに理解をすることが、ミッションに近づける最短の近道

――転職してきた鹿野さんだからわかる、新しいメンバーが苦労する点やぶつかりやすい壁があったら教えてください。

鹿野:ここは…正直言っちゃって良いんですかね(笑)僕から見ていると、これから入社するエンジニアには企画や他部署に対して変に遠慮をせずに、考えをきちんと言葉にすることを大事にしてほしいですね。

ゼロ→イチのサービス開発を経験したくて入社をしたけれども、エンジニアがうまくそれを言葉にできずに、結局言われたものだけを開発する状態に陥ると面白くないですよね。エンジニアなので、もちろん作る面白さもあるのですが、やはり僕たちはゼロ→イチでサービスを創るにあたってを企画や他部署とディスカッションしながら、より良いサービスを作りたい気持ちもあるはずです。その気持ちを言葉にしてほしいですね。

alt

またこれは他の記事でも出ていましたが、ツールが多いということでしょうか。開発に使うツールでさえ、それなりに多いのですが、それ以上にコミュニケーションツールが多すぎる。営業や人事、総務の方と連絡を取るのにメールや別のツールを使わなくてはいけないのはちょっと…。もちろんセキュリティに対する意識が高いのは理解できるのですが、エンジニアのスキルを阻害するようなルールを長く放置しているようにも見受けられます。

 

――ツール問題…確かに他のエンジニアの方もおっしゃってましたね。

鹿野:そうなんです。エンジニアが、自分たちの領域を超えて管理側や情報セキュリティ、法務の中に入っていくことが必要なのかな、と思ってます。社内ルールを整備する部門などへのリソース投資を検討して、もう少し人数を増やしたり、専門家を入れたりすれば改善されていくとは思います。

環境改善については、エンジニアサイドから働きかけをしている段階なので、劇的に変化していくことを期待しています。

 

――このように組織が変わってくる段階でエンジニアが入社することの価値って、どのようなものだと思いますか。

鹿野:従業員5000人以上の企業規模で、ミッション実現へ向けて、ここまで大きく、本気で取り組んでいる会社はあまりないと思いますし、少なくとも僕自身、周りで話を聞くことはありません。しかも、やっていることはゼロ→イチで面白いし、組織としての変化もある柔軟な会社だと思います。ですので、その変化を楽しめるという方には大きな価値があると感じています。

だからこそ、受け身ではつまらない。自分からアウトプットしていける人でなければ楽しめないかもしれません。新たなジョイン頂いたエンジニアは口々に「大きな会社なのにベンチャーのようなスピード感がある」と言います。僕としては逆に、そのくらいのスピード感でなければ、優秀なエンジニア層に興味を持ってもらうのは難しいと思っていますね。

 

――今後、チャレンジしたいことを教えてください。

鹿野:エンジニアって、マネジャーみたいな管理職になるというよりも、自分たちでアウトプットして作ることに面白味を感じる人が多いです。せっかく「サービスを作りたい」と言っているエンジニアが集まっていて、その環境もあるので、当然、サービス企画から一貫して、すべてコミットできる組織にしたい。そのためには開発業務が主体のエンジニアリング部が企画にチャレンジしたり、エンジニア発のサービスを作ったりできれば、組織の壁を超えた動きも可能になると思います。

お互いがそれぞれの領域の仕事を超えて理解しあうことが、ミッションに近づける最短の近道になると思いますね。

また、僕は仙台で働きたいので、仙台のエンジニアだけで開発ができるような、仙台発祥のサービスをこちらで作りたいですね。自身で作りたいものを考え企画し、会社のミッションに寄り添いながら、実際に形にしていくというサイクルができたら、より“自分らしく働く”ということに近づけると思います。

alt

――ありがとうございました!

(取材=伊藤秋廣(エーアイプロダクション)/文=THE TEXT FACTRY(エーアイプロダクション)/撮影=古宮こうき)

鹿野徹也

鹿野徹也 Tetsuya Sikano

パーソルキャリア株式会社 サービス企画開発本部 サービス開発統括部 エンジニアリング部 マネジャー

SIerに新卒入社後、金融系PROJECTにて要件定義〜開発〜マネジメントを経験。その後、地元へUターンし、地方ソフトウェアハウスにてIBM、FUJITSU、NEC等のリホスト業務(ランタイム作成、言語変換)に従事。地方と東京の「はたらく」違い・差を実感し、より自分らしく「はたらく」ため Webアプリケーションエンジニアへ転身。RubyOnRailsから始まり、アプリ連携、サーバレス開発、AGILE(SCRUM)開発リードと各種Webサービス開発で経験を重ね、2018年にパーソルキャリアへ入社。昨今はGV提唱のDesignSprintを利用したサービス企画に加え、マネジャーとしてエンジニアの「はたらく」をサポート、より良いチーム開発の実現に向けて挑戦中。

※2020年6月現在の情報です。