見出し画像

メンバーが持てる力を存分に引き出せる健やかな環境をつくる。マネジメントに専念し、事業インパクトを引き出す

 ハコベルの開発を担うマネージャーのひとりとして前回インタビューに登場した丸山 佳郎。会社もチームもスピーディーな変化を遂げる日々にあって、業務内容やマネージメント観の変容について語ってもらいました。

システム開発部 一般貨物運送手配システムG
エンジニアリングマネージャー

丸山 佳郎  Yoshiro Maruyama
大学を卒業後、制作会社にてディレクター・エンジニアとして6年間Web制作に携わる。その後、ラクスルに入社し物流シェアリングプラットフォーム「ハコベルコネクト」のフロントエンド開発を担当。2021年よりテックリード、2022年より開発チームマネージャーを務めている。

フロントエンドエンジニアから始まった業務変遷。向き合う対象も広く深く


—— 最初に現在の丸山さんのお仕事内容をお聞きしてから、前回のインタビュー以降の変遷を含めたおさらいができればと思います。

 現在の私の役割としては、システム開発部 一般貨物運送手配システムグループという部署で、開発チームのエンジニアリング マネージャーを担っています。チームとしては「ハコベル運送手配プラス」と「ハコベル配車管理」の開発を行うというのがメイン業務。それらのサービスは一般貨物のマッチングをご利用のお客様と、物流DXシステムをご利用のお客様、いずれにも向き合った仕事となります。

 ふだんは営業担当者やCS担当者と連携を取りながら、お客様のための新機能の開発改善を進めていく仕事ですね。私個人でいうと、そこの開発チームのマネージャーとして、技術的な面はもちろんなのですが、組織づくりや、ピープルマネジメントの責任を担う役どころです。

 たしか前回のインタビューのときは、マネージャーになりたての頃だったと思うのですが、少し記憶が曖昧なので整理とふり返りの意味を込めて経歴やハコベル入社後の変遷についてお話していこうと思います。

 ハコベルに参画して丸4年が経ちましたが、もともとはフロントエンドエンジニアという、ユーザーが画面越しに触る部分の機能などをつくるエンジニアとして入社をしました。当初はまだSaaS事業、物流システムDX事業は始まっておらず、マッチング事業のみだったんですね。

 それで1番最初は、エンジニアのなかの配車サポートチームに所属して、社内の配車サポートのメンバーたちのための機能改善をおこない、生産性向上をはじめとするさまざまな改善のための開発をメインにしていました。ですので、配車サポートのメンバーに業務状況などを頻繁にヒアリングしたり、モニタリングさせていただきながら開発を進めていたのです。

 そのころは、配車サポートのメンバーがふだん業務で使っているCTI(電話とコンピュータの相互作用を調整できるようにするテクノロジー)と呼ばれる電話機能、電話とハコベルのシステムを連携させるような部分の開発などを行っていました。

—— 前回の記事で「ハコベルの開発は徹底的に寄り添い方型だ」とおっしゃっています。電話とハコベルの連携も、社内の配車サポートの方々の要望からくみ上げてきたのでしょうか。

 そうですね、くみ上げた部分と、もともとそこに改善の余地があることがモニタリングのなかでわかってきていた部分とがあります。当時私が入ったばかりの頃は、電話と「ハコベル」のシステムは完全に別物だったので、電話をして聞いた内容をメモしたり判断するなどしていたんですよね。
 
 その部分を連携させることで、いまかかってきた電話が、「ハコベル」のシステムのなかでいうところの、「この会社のこのアカウントの方から電話がかかってきたな」といったことがわかるようになります。また、通話履歴などがすべてシステム上で一覧化され、「ハコベル」のなかで見ることができ、さらに録音した音声を聞くことができるようになりました。

 たとえば、忙しくて電話に出れなかった際に、「どれだけ出れなかった着信があるのか」、「これは折り返しが必要だ」などの履歴がシステムのなかで見れたり、システムと組み合わせることでふだんの業務の効率化を進められるだろう、ということからそういったものをつくってきました。

 身近なメンバーから実際に「便利になった」という声をいただいたりするのがとても嬉しかったですね。いまはCTIの機能がだいぶ変わったりはしているんですけど、当時はそういうのをやっていました。なので完全に社内のオペレーターのメンバー向け、というところが私の1番最初のメイン業務でした。
 
その後は、SaaS事業、物流DXシステム事業と呼んでいるセクションの事業が始まり、そこをメインミッションにしているチームで業務をおこなっています。それ以降は社内の人ではなく、「ハコベル」を導入してくださるお客様向けの機能開発を長くおこなっていました。

 対象が社内の人からお客様になったという違いはありつつも、仕事の基本的な流れは一緒です。そのお客様たちがふだんどういう業務をしていて、どこに改善の余地があって、どういう機能を必要としているか、みたいなことを、営業担当やチームと共有しながらつくり上げていき、それをプロダクトに落とし込んだらどうなるか?ということを考えながら、機能開発をしていくわけです。

プレイングマネージャーから自分の意志でマネジメントに専念した理由

—— 社内とお客様、双方への向き合い方も業務と共に広く深くなっていったのですね。マネージャーとしての側面もお聞かせください。

 その顧客向き合いの開発をやっている最中にマネージャーになりました。けれど最初のころはプレイングマネージャーで、いわゆる1エンジニアとしての開発をしつつマネジメントもやります、といった感じでした。たぶんそのころに前回のインタビューを受けたかと思います。

 マネージャーとプレーヤーを分けるべきかどうかというのは、人数や状況によって一概には言えないケースも多いんですよね。ですからハコベルでも、いままでプレイングマネージャーという立場の方は結構いましたし、他社さんを見てもいたりいなかったり、みたいな状況だろうと思います。

 今期から私は本格的にマネジメントの方に軸足を移しまして、開発もゼロではないながらマネジメントのほうにかなり比重を寄せています。基本的にハコベルの開発チームでは、マネージャーの期待値や責務といったことを文書化し、定義をしています。技術面の話など多岐にわたりますが、1番はやっぱり組織づくり、ピープルマネジメントに責任を持ち事業インパクトを出す、というのがもっとも重要な責務となります。

 その実際のHowの部分で言えば、メンバーとの1on1を通じて課題の吸い上げや状況把握をおこなったり、メンバーの状況にきちんと気を配りつつ適切な対処をしていきます。また、チームとして事業を成長させていくためのリソースや能力などが足りてないとなれば、外部から採用することで体制を整えるなど、そういった部分も大切な仕事ですね。それによって組織力を強化した結果としてビジネスインパクトを出す、事業貢献する、ということがもっとも求められていると考えています。

—— 今期からマネジメントに専業されることになったのは、キャリアの観点からご自身としても希望したのでしょうか。

 ええ、プレイングマネージャーとしてそれなりの期間をやってみた私なりの結論として、「1度マネジメントに集中して取り組みたい」と考えました。なぜなら、求められることが結構違うんですよ、プレーヤーとマネージャーとでは。

 もちろんどっちが良い悪い、上・下はないですが、求められることが明確に違う、というのと、マネジメント、マネージャー業務って…表現が難しいですが、後手に回ると取り返しのつかないケースというのが結構あるものです。大きいところでは、チームのメンバーが退職してしまうとか、本来はもっと活躍できるはずだった人が活躍できない状況になったりとか、兆候に気づけなかったり、タイミングや対応を見誤ると結構後悔することが多いのです。

 じゃあ「いまうまくいっているか?」と言えば、そこはなかなか苦戦してはいます。実際、注意しておかないと表面化しづらい問題も多かったりしますし、他のことと兼務していると表面化しやすい方に意識が持っていかれがちで、表面化したときには手遅れ…といったこともありました。

 そういった意味でも専業になった方がよりチーム、組織として望ましいな、と考えるようになったんです。あとは、私個人としても、キャリアを考えるうえで選択肢として以前から想起していたものでもありました。プレーヤーとしてもう少し技術寄りの方にフォーカスするか、マネジメントの方にフォーカスするか。

 これを私は一応選択できる状況にあったのですが、今後の自分のキャリアだけでなく、現在のチームに必要なことを考えたとき「エンジニアリングマネージャーとしてマネジメントにフォーカスする、責任を持つ」という答えとなったのです。それは組織成長のためにもそうですし、自分の成長も含めてチャレンジしてみたい、という気持ちから。それでマネジメントの方に軸足を移す選択をしたわけですね。

能力の発揮を阻害する要因をいち早く見つけ、取り除くことで、事業貢献できる強いチームを作ることが仕事

—— なるほど。ご自身のキャリアパスだけでなく、組織成長のためにマネジメントに専業することを選んだわけですね。どんなことを重視していますか。

 これは私自身が、というより全社的にそうだと思うのですが、オーナーシップを持ってやり切るというのがあります。「自立して自走していく」というか、チームとして「なにが良くなかったのか、なにが良かったのか」といったことを自分たちで挙げて、自分たちで「じゃあ次はこうしようか」というサイクルを回し続けるみたいなことを重視してはいますよね。

 チームは実業務を細かく見たらプログラミングがメイン。無機質と言えば無機質なんですが、それをつくるのは結局チームの人間ですから、そのチーム間で「人間を無視できない」というのはとても感じています。チーム間でどのように進めていくか?というのは、コミュニケーションをおろそかにしない、というのは大切にしています。

 マネージャー視点からのチーム運営としてですと、経験の豊富な中途入社の方やベテランと呼ぶにふさわしいメンバーもそうですし、新卒入社の若手メンバーも含めて、すごく優秀なメンバーが多い組織だな、と思っています。

 そういう優秀なメンバーがいるなかで、「マネージャーがなにをやるべきか?」と考えたとき、私がなんでもかんでも取り仕切って「これはこうしよう、こうすべきだ」と言うというよりは、優秀な人が気持ちよく働けるように、力を存分に発揮することを阻害する要因を取り除いてあげることが重要だな、と考えるようになっていきました。

 もちろん重要な意思決定や判断を下すべき時には自分の責任でおこなうことが必要ですが、ふだんの業務上の多くのことは優秀なメンバーの意見や考えを聞きつつ、メンバーが主体性を持って進めていけることが重要だと思っています。

 ですので、全部決めて指示するということはあまりしません。ある程度の大きさで範囲を区切りつつ、メンバーにはどんどんお任せして、「ここでなにか少し困っていそうだな」とか、「ここでぶつかっているな」といった状況を把握できるよう、そこは気をつけて見ていますね。

 「おそらくこれが障壁だろうけど、1人の力ではなかなかやりづらいだろうな」というところを見つけ、少しだけサポートしたり、他のメンバーに助けを求めたりとか、調整役に少し入るなどが、基本的に重視している私の役割なんです。

 そうすることでメンバーの力が十分に発揮される、強いチームを作っていきたいなと思っています。

—— そうしたマネジメント観は独学なのですか。どのように身に付いたのでしょうか。

 試行錯誤して経験を積みながら感じたこともありますし、上司や同僚の他のマネージャーと議論や相談をしていくうちに、自分のなかでのマネージャー像や「こうあるべき」みたいなものの解像度が少しずつ上がっていっている感覚です。

「生存バイアス」とよく言われますが、世の中の経験談とかって上手くいったケースの話が多くて、上手くいかなかったケースや人の話ってそんなに多くないんですよね。でも実際にマネジメントをやってみると上手くいかないことの方がずっと多くて。

 そのたびに何がよくなかったのかを自分で考えたり、ハコベルには私より経験豊富なマネージャーやメンバーも多くいるので、そういった方に相談したりというのを繰り返しながら今の考え方に至るという感じでしょうか。

 ふだん一緒に働いているメンバーでも、本当はもっと上手くいったかもしれないのに、何か小さなことの積み重ねで本来の能力を発揮できないことはそれなりにあると思うんですよ。
 そうしたところに気づいてそこのサポートができて、本来の持っていたはずの能力や力をより生かせるようにしていくことが私の理想ではあります。

 組織成長と自分の成長のキャリアパスというところでいうと、私の理想とするマネージャーとしての成長が、確実に事業成長に寄与しないとなりません。
 いまはチームが十分に力を発揮できる状況を作っていくことで事業に貢献していきたいと思っていますが、もし自分のマネージャーとしての理想像やキャリアパスが変わったとしても、事業成長させていくことが第一義だということ、そのために何が自分にできるかということはぶれずに追求していきたいですね。

「これが自分の仕事だ」と自信を持って語れるように。それがすべての行き着くところ

—— サーバントリーダーなのですね。では最後に、仕事のやりがいを感じる点についてはいかがでしょう。

 「人と現場ありき」というところに尽きるかなと。やりがいも難しさもどちらも同じところから来ているなと思います。これはどちらかというと、マネージャー観点というよりは、もう少し全体のハコベルの事業とか、プロダクトの話になるのですが、「現場のオペレーションはどうなのか」、「実際のペインがどこにあるか」というのを一つひとつ理解し、すくい上げていかないと、うまくいかないということ。

 「人と現場ありき」というのは、なんというか机上の空論が通用しない、非常に難しくもあり、やりがいにもつながるところだなと思います。

 私たちはエンジニアなので、プロダクトの機能開発における「こうしたらいいよね」というものの多くは画面のなかの話ではありますが、ほとんどが実際に物流の現場で働いている人の業務に影響が出ることです。ですからそれを踏まえたうえで、中長期的にどうあるべきか、本当に実行に移すべきなのか、ということを考えていかないとなりません。実際の現場に落とし込んだ時にどれだけ影響が出て、どれだけ効果が生めるようなものか?というのに、しっかり正面から向き合っていかないとうまくいかない、というのが難しさだと感じています。

 ハコベルのプロダクトやサービスって、どこまでいってもネット内で完結することはあり得ない。このサービスですべてのことがおこなわれるということが絶対になく、実体を持った荷物があり、トラックが実際にそれを運び、だからドライバーさんもいれば、配車マンもいて、倉庫の方もいれば、といった「実体、物理」の世界が必ずある。なので、ネットのなかだけを考えて「これがいいよね」と言ったとしても、それって物理の世界とマッチするのか、フィットするのか、というのは、少し視点が違うんです。

 そこのところにしっかりフィットできるかどうか、というのが難しさではあるんですが、その分やりがいもそこにあるなと思っていて。

 実際に現場で働いている人がいて、こういう業務をやっている人がいて、というのがすごく具体的にあり、その人たちに向けて私たちは事業を展開し、サービスを提供しているというのがあるので、直接的に貢献できている感触というのはすごく強いです。

 私たちのサービスは「どんな人でも使えて生活が楽しくなる」ようなサービスとは違いますが、物流に携わる方に対して直接的に貢献のできる感覚、価値を生み出せた実感が得られることは、ハコベルならではのやりがいと言えるでしょう。

 あとはコツコツ積み上げ型というのも、やりがいとしても大きいのではないでしょうか。長期的な視点で長い時間をかけて一つの業界に対して向き合い、腰を据えて取り組んでいくこと。少しずつ少しずつ良くしていけるというのは、やりがいとして大きいとつくづく感じます。

 かっこいい言い方をすると、自分が「おれの仕事はこれだよ」と、自信と誇りを持って言えるかだと思うんですよ。それで、世の中のためになることをしている、と本気で信じられるかどうか、というのがやりがいにつながっていくと考えているんです。






この記事が気に入ったらサポートをしてみませんか?