自社に閉じない物流業界の “データ標準” はハコベルが担う。さらなるエンジニアリングの価値向上を目指す
寡黙ながらいつも周囲の雰囲気を見守り、人を見る目は穏やかでやさしい。言葉にすることが少ないので、気づかれにくい中村 隆宏の美点のひとつです。物事にある多様な視点からの考察を重視するため、断定的な表現を避けながらじっくりと会社に根づく気風やエンジニアリング観を語ってくれました。
物流DXシステム事業部 プロダクト開発グループ
プロダクト開発部 データ基盤グループ 本部長
中村 隆宏 Takahiro Nakamura
大学を卒業後、システム開発会社に就職し受託開発に2年半携わる。その後、決済デバイスをつくるベンチャー企業のサーバサイド開発、エンジニア向け転職・学習サービスのWebアプリケーション開発を経てラクスルに入社。物流シェアリングプラットフォーム「（旧）ハコベルコネクト」の開発を担当し、開発チームマネージャーを務めた後、現職。
エンジニアリングへの情熱は持ちつつ「それは手段」と認識し、対応できることが重要
—— 現在の中村さんのお仕事内容を教えてください。
いまは「ハコベル配車計画」のエンジニアリングやプロダクトマネジメントと、それらの橋渡しとなる業務に従事しています。プロダクトの開発とプロダクト全体の方針を決める業務、あとはシステム部全体の技術的な方針策定などに関わっています。
他に、データ基盤の運用を自分たちでできるような組織づくりも進めているところ。管掌部署は、物流DXシステム開発部の配車計画開発グループと、新設のデータ基盤部。そこの本部長を務めています。多岐にわたる業務内容なので、対外的にわかりやすくする意味合いから「シニアアーキテクト」という肩書きを名乗っています。
—— まだ立ちあげ中というデータ基盤グループ、どういったスキルをお持ちのかたですと活躍できるのでしょうか。
データ基盤運用に限ったことではなく、ハコベルのプロダクトづくりの価値観に共感してくれることですね。事業やプロダクト目線が強く、エンジニアリングにおいての情熱を持ちつつも「それはあくまで手段」と認識して対応できるかたが活躍しやすいでしょう。
そのなかでどんなふうに専門性に特化した人、さらに活躍できる組織にしていくか、というのが私たちの考える仕事ですね。
ある程度のデータ分析における素養は必要ではあるものの、結局データを扱えることよりも「どこに問題があるのか」とか、「どういうことをやるべきか」といった理解度が深いほうがアウトプットがより正確になる、ポイントを外さないものがつくりやすい。ですから、そういった素養がありますとビジネス面とシンクする際にズレが起きにくいと考えています。
データエンジニアリングの分野での専門性とともに、現在の開発グループで求める人物像、スキルがありつつ志向性や経験も同時に重視しています。
一社一社の意見を傾聴したうえで、汎用的な価値となる機能開発を目指す
—— ご入社以降、多様な経験を積んできた中村さんですが「これぞハイライト」とふり返るご経験をぜひ教えてください。
物流DX事業に関わるプロダクト開発に携わってきて、配車管理、配車計画の開発をしてきました。、領域としてはバックエンド、フロントエンド、エンジニアリングマネージャー、プロダクトマネージャーなどさまざまな経験をさせてもらいました。ですが、そのなかでもやはり「ハコベル配車計画」をつくり出したというか、そこに関わりだしたというところがすごく大きな変化だったと言えます。
１度配車関連のプロダクトをつくるなかで、０→１（ゼロイチ）フェーズのプロダクトをエンジニアとして開発するということを経験したうえで、さらにもう１度、同じ業界でプロダクトの立ち上げに関わっていることが学びとして深いものですね。
「ハコベル配車計画」の現状では、技術的観点とともに「どうしたらユーザーに１番早く機能を使える状態に持っていけるか」と考えており、これらの両立をバランスを図りながら進めることが、仕事の面白さにつながっています。
一方で配車管理、配車計画のプロダクトに関わらず、ハコベルのプロダクトをつくるにあたり共通しているのは、「一社一社それぞれの意見をしっかり聴きつつも、最終的には個別にしか問題を解決しないものではなく、日常に対して汎用的な価値が出るような機能をつくっていこう」とするのが大事にしていることのひとつです。
—— 汎用的な価値を生み出すこととスピード感の両立は面白さと共に困難でもありそうですね。
それはありますね。ハコベルのバリューのひとつである「リアリティ」にあるように、なるべく現場のかたにお話を聞くことは一般的なことです。開発チームでも、ふつうに現場の配車業務に携わっておられるかたにご意見をうかがいますし、導入先企業のIT部門のご担当者にヒアリングしたりしています。
先ほどお話した「個別にしか問題を解決しないものではなく、汎用的な価値が出る機能をつくろう」としているわけですが、お客様がたのご要望は一見バラバラに見えて、根本を突き詰めると近い領域であることが意外に多い印象なんですよね。
ただ、そのなかの優先順位は各社のオペレーションによってばらつきがあり、個別の話を聞いてくなかで、「課題Aに対してはAの機能で解決できそう」だったり、「この課題は機能Bで複数社は解決できそう」、といったことがある。ですが、「AとB、どちらが重要だ」という考えは、会社によって違ったりしますので、そのあたりを調整していくことは難しさを感じるところです。
そういう場合はハコベルの方で「こちらの方が良いですよ」とご提案していくのかというと、新機能の開発においては必ずしもそうではなかったりします。ですが、「こういう機能を使うとこういった運用で問題を回避できるのではないか」と会話することはあって、いずれにしてもやっぱり「バランスをとる」。これに尽きるのかもしれません。
機能開発においては他の業界での動きやプロダクトが刺激になったりするので、アンテナは拡げて情報を自分から採りにいったりもします。とはいえ、もっとも大事なことは「ターゲットにしている業界の方々がどういう課題を持っているのか」。これを中心に据えながら、他のプロダクトも「参考になりそうだな」とか「この裏側の仕組みはこんなふうになっているのかな」とか、そうしたことは日ごろからなんとなく考えるようになっています。
モチベーションを重要視する組織であればこそ、健康的な職場になっていく
—— そうした「目利き」の役割も持ち、視野が広い中村さんですがハコベル以前はどんなキャリアを積んでいらしたのですか。
キャリア初期はいわゆるSI系の業界で、大手企業やメーカーの業務システムや官公庁のシステムをつくる会社で受託開発をしていました。そのあとは決済端末、決済用のタブレットなどをつくる会社で、それにまつわるポイントシステムやクレジットカードの決済システムを構築するなどしたあと、エンジニア向け転職サービスの開発に携わってからラクスル社に入った経緯です。ラクスルでは初めからハコベルに配属でそのままいまに至ります。
社会人になる以前にさかのぼると、学生時代は社会科学系でした。文化人類学・社会学を専攻していて、統計を使うなどはありましたが、プログラミング、ソフトウェア開発に直結する領域ではありませんでした。「文化人類学」がどんな学びかとよく聞かれるのですが、簡単に言うと「人間のグループがどういう価値観を共有しているか」「そういった価値観が生まれた背景、思考や行動におよぼす影響は何か」などをフィールドワークをしながら調査・研究する学問です。
—— 学生時代の専攻が「ソフトウェア開発に直結していない」と仰いましたが、いまのお仕事にいい影響がありそうですよね。
あると思いますよ。ユーザーがどういうふうに考えながら仕事しているか？なにに価値を置いて日々の業務での判断をしているのか？とか、そういったところを見るのはすごくつながっていると感じることが多いです。
意図したわけではなかったのですが、１番最初に入った会社からキャリアはエンジニア、開発、となりましたが、当初は不安でいっぱいでした。やることがあまりに多く、ついていけるのか？とか。受託開発の仕事だったので、いまのハコベルでの開発環境と比較すると、ハコベルでは自分でやることを主体的に決めていけるのは大きいかなと感じています。
オーナーシップを発揮するには、目標決めに自分がどれだけ関われているか、納得できているかが重要なことだと思っています。プロダクトの社会的なインパクト、自分のキャリアにおける志向がいい感じに方向性が合致している状態をつくれると、高いモチベーションで仕事をしていけると考えています。
一方で技術者としては受託開発はそれはそれで良い面がありました。いろいろな業界の知見や知識を得られるというのはプラスの側面でしたね。また、ステップを分解してたくさんの人で解決するための仕組みをつくる、といったこともありますよね。新規開発のようなプロジェクトも多いので、自分たちで１からつくる面白さも醍醐味と言えます。キャリアの一過程としてはすごく面白かった、という気持ちはありますね。
—— やりがいを感じながら技術者としてもマネジメント職としても存分に働ける環境なのですね。
そう感じています。マネジメントとしては、専門性側に思考が強い人たちがどう活躍できるかとか、優先度をどう可視化してすり合わせていくか、というようなことは日々のテーマとしてあります。ビジネスとしての優先度のバランスと、プロダクトとしての優先度のバランス、どこに最適解がありそうなのかを探究することがチャレンジであり、難しいし点とも言えます。
ハコベルの開発チームでは、「Why（なぜ）」「What（なにを）」から始まり「How（どのようつくるか）」にたどり着くまでをチームで議論を深めていくことが多いです。そのなかでの役割分担として「Why」「What」を考えるための材料を集める役割、焦点を絞る役割をプロダクトマネージャーが担うという一面があるのかなと考えています。
みんなで情報収集からすべてのプロセスをやれたら理想的かもしれないですが、なかなか時間の問題や得意分野もあったりしますから、ある程度は役割を分けて効率的にプロダクト作りを進めていく必要があると考えてます。この辺もマネージャーになって変化した視座ではあるのですが、もともと好きな方ではありますね。
個人的な野望は「物流業界のデータ標準になる」こと。日々の仕事はその過程
—— 今後の目標や実現していきたいことを教えてください。
ユーザーのニーズに対して技術力を上手く使い、最短でより良いプロダクトを提供していくこと。それをさらに継続できないか？とか、価値を組んでいけるようなものにしていくこと、そこのバランスを上手く図っていきたいと考えています。
個人的・エンジニア的な野望として、「物流業界のデータ標準は自分たちがつくる」という考えを持っています。まだデファクトスタンダードなサービスがない状態だからこそ、そのチャンスがあるのがいまなんです。
そして、そこのポジションを確立できたら開発がすごく楽になるんだろうなと思っていて、「ハコベルが業界標準だからうちに合わせて周りのシステムつくってください」、という状況になったらすごくエンジニアとしても面白いですし、プロダクトとしても加速することは間違いないと思っています。
これらのデータは現在、業界標準という指標がありません。特に重要なところで言うと配車計画とか配車管理のそれぞれの入口にあたるデータだったり、そこから出力できるデータが業界的に統一されると、非常に利便性高く情報交換がスムーズになるのではないかと考えているんです。
—— これまでも「ハコベルのプラットフォームが業界標準になることを目指す」と仰る方々がいました。「物流業界のデータ標準へ」というのは中村さん独自の視点のようです。
けれど両者は決定的に違うわけではなくて、「プラットフォーム」という言葉を使うか使わないかの違いだけな気もしてはいています。表現として「ハコベル プラットフォーム」が成り立つには、プラットフォームに接続できるような状況が完成できている必要があります。世の中の何割のシェアが必要かははわからないですが、高いシェアを保有していけば、我々に合わせてシステム間の接続をしていくことの必然性は高くなるはずです。
たとえばある運送会社でドライバーの労務管理システムを導入するときに「ハコベル配車管理と連携させて、仕事を触れるドライバーがわかるようにしたいです」みたいなことを運送会社の方々が、他社にリクエストを出してくださる未来があったらすごく嬉しいですよね。
物流の「2024年問題」といって社会的にも急激に課題として広く認識されているいま、物流DXにおいてもプレイヤーがたくさん増えていっています。ハコベルでもご利用いただくお客様が増えていっていますが、お客様ごとに「いまうちで使用しているシステムと連携したいからこういうフォーマットを取り込みたい」といったニーズが生まれてくると面白いですよね。これからどんどん利用されていくわけですから。
継続した価値提供のために、どんどんご使用いただいてどんどん改善していき、量で使っていただくところにさらなる質を追いかけていくことで、物流業界のデータ標準になっていくと思いますので、日々の仕事がそのステップにあると感じています。
この記事が気に入ったらサポートをしてみませんか？