ハコベル株式会社
執行役員 システム開発部長／VPoE
丸山 佳郎
大学を卒業後、制作会社にてディレクター・エンジニアとして6年間Web制作に携わる。その後、ラクスルに入社し物流マッチングプラットフォーム・DXシステムである「ハコベルコネクト」の開発を牽引。2021年よりテックリード、2022年より開発チームマネージャー、2025年4月にシステム開発部長／VPoEに就任（現任）、同年11月より執行役員。
物流業界における深刻な人手不足や業務の複雑さに対し、テクノロジーの力で変革を起こすハコベル社。同社のVPoEである丸山さんは、現場理解と自律自走を軸にした開発組織づくりを進めています。
事業成長とともにチームが拡大する中でも、ハコベル社が貫いているのは「解像度」と「裁量」の両立。エンジニアが現場の一次情報に基づき、自ら仮説を立て、プロダクトの価値に責任を持つ状態をどう実現するかにこだわり続けています。
今回は、そんな丸山さんに、組織設計・技術選定・文化づくりに込めた思いと、物流という“現場起点”のドメインでプロダクトを磨き続けるための工夫について伺いました。
事業理解を起点にした自律型エンジニア組織の設計
まずはじめに、ハコベル社の事業内容について教えてください。
私たちは「物流業界をテクノロジーで変える」ことを掲げる物流テック企業です。主なソリューションは二つあり、一つは運送手配のマッチングサービス。もう一つが、配車や倉庫業務など物流業務を効率化するDXシステム群の提供です。
こうしたプロダクトを展開するうえで、ハコベルが大切にしているのが「オープンなプラットフォームの実現」という思想です。物流業界は、業務プロセスが煩雑かつプレイヤーも多様で、1社のプロダクトだけですべての課題を解決するのが難しい構造です。だからこそ、自社プロダクトだけで完結させるのではなく、他社のサービスや顧客の基幹システムと柔軟に連携しながら、業界全体の課題解決を促進する“ハブ”のような存在を目指しています。
丸山さんご自身の役割についても教えてください。
現在は、VPoE兼システム開発部長として、開発組織全体のマネジメントを担当しています。もともとはフロントエンドエンジニアとしてハコベルに入社し、UI/UX設計やユーザーインタビューなど、現場に深く入り込む形でプロダクト開発を進めていました。その後、テックリードやエンジニアリングマネージャーを経て、現在の役職に至ります。
現在はコードを書く頻度は減りましたが、ビジネス戦略と技術戦略をリンクさせ、エンジニアリングが事業価値に変換されるための組織基盤づくりに注力しています。
開発組織の規模について教えてください。
現在、ハコベルの開発体制としてはエンジニアやPdM、デザイナー、それに業務委託で参画いただいている方を含めて40名程度の体制です。組織の拡大に対しても、単に人数を増やすのではなく、事業課題に確実に向き合える体制構築を意識しています。
たとえば、2024年にはM&Aによりトラック簿というプロダクトとチームが新たに加わりましたが、その際もEMやPdM、テックリードが中心となりチーム単位で立ち上げることで、既存体制との整合性を保ちながら事業・プロダクトを軌道に乗せることができました。
組織運営上、どのようなチーム構成をとっていますか？
ハコベルでは、プロダクトごとにPdM・デザイナー・エンジニア（テックリードやEMを含む）で構成されたクロスファンクショナルなチームを編成しています。特徴的なのは、各チームが仮説の立案から実装、検証、振り返りまでを一貫して担い、事業に直接向き合う点です。
たとえば、ユーザーから挙がった課題に対し、PdMが仕様を固めるのではなく、現場に詳しいエンジニアも一体となって一次情報をもとに意見を出し合いながら形にしていく。ビジネスサイドとの議論も含めて、チーム全体で「誰にどんな価値を届けるのか」を解像度高く捉えるよう意識しています。
チームには裁量と責任があり、意思決定も自分たちで完結させます。役職や部門を超えて密に連携し、自律的に動く体制が、変化の多い事業フェーズでもスピードと柔軟性を支えています。
裁量と最適化を両立させるための進化
各チームにはどの程度の裁量がありますか？
技術選定から開発プロセス設計まで、基本的には多くの部分をチームに委ねています。現場が最も状況を理解しており、スピードや納得感のある判断をするためには、そのチーム自身が意思決定するのが最も合理的だからです。
その一方で、全体整合性の難しさはありませんか？
プロダクトの数が増え、チームも拡大する中で、横断的な最適化や共通基盤の整備も重要になってきました。そこで現在は、VPoEの私が主に組織全体を見ながら、技術横断の責任者であるVPoTが技術戦略や開発手法も見ていく体制に進化させています。
各チームの裁量は維持しつつ、「これは共通化した方がいいか？」「システム負債を増やさないか？」といった視点で、チームをまたいだ対話が生まれやすい環境を整えています。
現場とプロダクトをつなぐ「解像度」の追求
物流業界ならではの難しさはどんなところですか？
物流は“現場が主役”の業界です。思い込みやイメージだけで課題を定めても現場のリアルとは乖離しているというようなことが多々あります。トラックを運転している方や、倉庫で働いている方々が実際にどんな業務をしていて、どの場面で非効率が発生しているのか。これは現場に足を運んだり直接声を聞かないと分からないものです。
たとえば、Webサービス上にすごく便利な機能を追加しても、ユーザーの方が倉庫内を忙しく行き来していてそもそもWebサービスを頻繁には見ていられなかったりなど、実際の現場にはソフトウェアだけでは拾いきれない“リアルな事情”が数多くあります。こうした背景を知らずにプロダクトを設計してしまうと、表面的には整っていても、実際の業務ではまったく使われないということが起こり得ます。
ハコベル社では現場との接続をどう実現していますか？
ハコベルでは開発メンバーも含めて現場を訪問したり直接顧客にヒアリングなどをすることが組織文化の一つになっています。物流のリアルを知ったうえで開発に臨むことで、課題の本質を見誤らずに済みます。また、ビジネスサイドとの定例会でも、現場起点で見えていない情報を補完し合っており、営業やカスタマーサクセスから現場の声を汲み上げる仕組みも整っています。
そしてもう一つ、私たちの組織の大きな強みが「オペレーションチームの存在」です。
社内にオペレーションチームがいることの強みを教えてください。
ハコベルのオペレーションチームは、物流業界で実務経験を積んできたメンバーが多く、今も現場に近い立場で業務を担っています。たとえば、荷主企業や運送会社と日々やり取りをしながら、配車の調整や問い合わせ対応などを進めており、こうした業務を自社のプロダクトを使って行っています。
つまりオペレーションチームの方は、業務を通じてプロダクトを“毎日使っているユーザー”でありながら、その背景には現場を熟知した物流経験者としての視点もある。開発にとっては、これほど信頼できるフィードバック源はありません。
たとえば、「この仕様って現場で本当に使えるのか？」とSlackで聞けば、すぐに実情を教えてくれる。現場訪問では拾いきれない温度感やストレスのような情報も、彼らを通じて開発に伝わってきます。開発チームがより高い解像度で課題を捉え、具体的な改善につなげるうえで、オペレーションチームの存在は非常に大きな意味を持っています。
カルチャーの核にある「自律自走」と「価値貢献」
組織文化として大事にしていることを教えてください。
エンジニア一人ひとりが「裁量をもって自律自走」すること、そして「解像度高く課題を理解すること」を大切にしています。最終的には「何のためにやっているのか？」を自分で考え、目的がブレてきたと感じたら軌道修正の提案もします。
そのために、エンジニアも上流から関与し、ビジネスサイドとの議論にも積極的に参加します。役職や年次に関係なく意見が交わされるのは、ハコベルの大きな特長のひとつです。
印象的な取り組みがあれば教えてください。
最近では、社内向けにAIハッカソンを実施しました。全社から業務上の課題を集め、それに対してエンジニアが解決策を試作するという取り組みです。開発領域に限らず、バックオフィス業務なども対象とし、「社内全体を良くする」視点で実施されました。この取り組みも、私からトップダウンで指示をしたわけではなく、メンバーから「こういったことをやりたい。こういった取り組みに価値があるのではないか」という声からボトムアップで実現しました。
単なる技術の披露ではなく、「どこに価値があるか」「それを何に使うか」を問い続ける姿勢が、こうした取り組みにも表れています。普段の開発から一歩引いて、会社全体を俯瞰し、自分たちが貢献できる価値を考える。このような場でも、ハコベルらしいカルチャーが自然と滲み出ていると感じます。
拡大フェーズでもスピードと柔軟性を維持する工夫
今後の組織拡大を見据えて、どのような仕組みを取り入れていますか？
ハコベルではOKRを導入し、全社→部門→チーム単位に目標をブレイクダウンしています。目標を立てること自体が目的なのではなく、むしろ「何にフォーカスするか」そして「何をやらないか」を明確にすることが重要だと考えています。
特に成長フェーズでは、やるべきことが増えて混乱しやすくなる。そうした中で、OKRを起点に「それは本当に今やるべきか？」「それはこのチームがやるべきか？」という問いを持ち、無理に抱え込まずに“やらない判断”ができるようになってきました。
OKRを現場レベルで活用する上で工夫していることはありますか？
OKRはトップダウンで落とすのではなく、メンバー・チームとの対話を通じて目的をすり合わせるようにしています。目標設定の際には、チームで集まり「このOKRの本質って何だろう？」「自分たちがそこにどう貢献できるか？」を議論する。結果として、行動の納得感や当事者意識も高まっている実感があります。
このプロセスを通じて、チームごとの視座が自然と上がり、「なぜこのタスクに取り組むのか？」「これは本当に今やるべきか？」といった思考が定着していきます。結果として、開発の優先順位がより明確になり、ビジネスと技術のズレも最小限に抑えられるようになります。
拡大によって文化が薄まる懸念はありませんか？
確かに、組織が大きくなると、情報の粒度や価値観の共有にばらつきが出てきます。そこで私たちは、チーム単位の裁量を維持しながらも、共通の判断軸として「価値提供にとことんこだわる」ことや現場への解像度やオーナーシップといった明文化されたValueを大切にしています。
また、チームとしてOKRという共通言語を持つことで、「この行動はOKRに沿っているか？」「最終的に誰のための価値なのか？」という対話が自然と生まれやすくなっています。
これから入るメンバーに求めることはありますか？
変化の中で自律的に動くためには、自分で目的を捉え、状況を判断し、優先順位をつけられる力が必要です。それを支える仕組みの一つとしてOKRもありますし、現場レベルでの解像度や、事業理解も求められます。
私たちの開発組織は、スピードも柔軟性も高く、裁量も大きいですが、その分「なぜやるのか」「本当にやるべきか」を常に問い続ける姿勢が求められます。そこに面白さを感じられる方にとっては、非常にやりがいのある環境だと思います。
VPoEとして描く、これからの組織像
今後の開発組織をどう進化させていきたいですか？
まず前提として、物流業界も私たちのビジネスも、今後も変化を続けていきます。そうした環境下で求められるのは、変化に対して柔軟で、かつ自律的に動ける組織です。私はVPoEとして「どんな状況になっても価値を出し続けられる組織」を目指したいと考えています。
そのためには、仕組みや体制を固定化しすぎないことが重要です。現時点ではクロスファンクショナルなチーム体制がフィットしていますが、それも業界や事業の状況によって見直していけばいい。大事なのは、変えてはいけない“軸”を守りながら、構造はどんどん変えていける柔軟さだと思っています。
“変えてはいけない軸”とは、どんなものでしょうか？
繰り返しになってしまいますが、一言で言えば「価値提供にこだわること」です。何のためにそれをやっているのか？ その目的をチームでしっかりと共有し、自分たちのアウトプットが誰にどう届くのかまで想像できること。その状態を保ち続けたいと思っています。
ハコベルでは、物流という物理的な現場に向き合う必要があるからこそ、エンジニアも常に一次情報に触れて、仮説を持って、対話していく必要があります。だからこそ、「高い解像度」と「自律自走」の両方を持った組織にしなければなりません。
この先、組織がどれだけ大きくなっても、「誰のどんな課題に応えているのか？」という問いを忘れずにいたい。それこそが、どんな変化にも揺るがない、ハコベルらしさの原点だと思っています。
ハコベルの開発部の組織体制について、ぜひこちらの記事もご覧ください。
編集後記
取材を通して強く印象に残ったのは、「変化に合わせて組織の構造は柔軟に変えていい。でも、“価値提供へのこだわり”という軸だけは絶対にぶらさない」という丸山さんの言葉でした。
ハコベル社の開発組織は、現場起点の解像度と、自律自走の文化が支えています。エンジニアがユーザーと地続きで対話し、一次情報に触れながら価値あるプロダクトを生み出していく。その営みが、社会インフラである物流の変革を着実に前へと進めているのだと感じました。
組織が成長しても、本質からブレないチームをどうつくるか──そのヒントが詰まったインタビューでした。
