1
/
5

「唯一無二の物流プラットフォームでゲームチェンジャーになる」CTOの尾藤がオープンロジで目指すこと

こんにちは!オープンロジ採用広報担当です。
今回は2023年2月に執行役員CTOに就任した、尾藤 正人の記事です。

私たちオープンロジの事業ドメインである物流業界はシステム開発が十分ではなく、時代に取り残されてきました。ただシステムを導入するだけでは解決できない、リアルなオペレーションが発生する物流業界においては"現場”が重要で、一部の最先端の倉庫を除き、多くの中小の倉庫は投資も限定的でレガシーなままです。

オープンロジはそのようなレガシーな現状を変えたいと事業を行ってきた中で、プロダクト開発とそれを支える技術は、非常に重要でした。
これまでも多くのエンジニアがプロダクト開発を行ってきましたが、1つ上の物流プラットフォームを目指す中で、エンジニア組織もアップデートが求められていました。

2021年7月にVPoEの坂井が入社し、技術を牽引出来るCTOの採用が急務!という中で出会ったのが今回のnote執筆者である尾藤です。

それでは、尾藤のアツい思いをご覧ください!!


ご挨拶

こんにちは!!尾藤 a.k.a. BTOです。

実は2023年2月1日に執行役員CTOに就任しました!!
技術の責任者としての任を仰せつかりましたので、オープンロジをテックカンパニーにするべく邁進する所存でございます。

尾藤 正人とは何者か?

今までウノウ、UUUM、ReproでCTO職をやってきました。今回のオープンロジで4回目のCTOとなります。自分でも懲りずによくやってるなと思いつつ、ここまで来るとだんだんCTO職に愛着も湧いてきました。

「物流版AWS」の開発を目指すオープンロジ

我々はすごく簡易的に言えば物流Techの会社ですが、ただの物流Techではありません。
オープンロジでは荷主・倉庫双方の業務を効率化するシステムを提供する他、パートナーである倉庫様をネットワーク化し、柔軟性と拡張性の高い、"物流ソリューション”をEC事業者様に提供しています。

今後もさらなるシステムの拡充、倉庫ネットワークの拡大をしていくことで、唯一無二のプラットフォームを構築していきます。そして「物流版AWS」というプロダクトコンセプトにあるように、荷主様が物流に悩まない世界、そして効率的かつ低負荷なモノの流れを生み出し、物流業界の課題を解決しようとしています。

事業の成長性と優秀な経営陣に惹かれて

前職の退職を考え始めた時にYOUTRUSTの転職意欲のステータスを変更したのですが、その時にVPoEの坂井さんから連絡をもらったのがオープンロジを知ったきっかけです。実は転職媒体を使った転職は今回が初めてで、それまでは全て人づてで決めてきました。

オープンロジの他にも何社か連絡を頂きお話させてもらいました。ですがその中でもオープンロジの事業領域である物流・EC領域は、純粋に自分が全く知らなかった分野だったためより面白さを感じましたし、事業の話を聞いて一番成長性を感じました。物流ドメインの中でも着眼点の面白さというか、「こんな世界があるんだ」と思いましたね。
(事業の成長性についてはこちらの記事で詳しくお話しています!!是非ご覧ください)

また、入社前に経営会議に一度参加させてもらったのですが、そこでの議論が活発で経営陣に優秀な方が揃っているなと感じました。どんなに良いビジネスモデルでも最終的に会社を成長させるのは人なので、この経営陣なら一緒に事業を大きくしていけるなと感じました。

「テックカンパニーになる」というミッション

僕は技術の責任者としてオープンロジをテックカンパニーにしていくというミッションを持っています。

では、オープンロジにおけるテックカンパニーとは何なのか。テックカンパニーという言葉を聞いて人それぞれ思い浮かべるものは違うでしょう。この問いに対する答えは僕自身も持っていないのですが、ただ一つだけ確実に言えるのは、テックカンパニーとは技術で事業を伸ばしていく会社だということです。

次に、技術で事業を伸ばしていくためにはどうすれば良いのかということは、様々な要素があり簡単に言語化することは難しいのですが、僕は一番重要なのはプロダクトロードマップだと考えています。

事業は「強いプロダクト」と「強い技術」の両方がそろっていなければ、爆発的な成長はできません。(日本の場合、プロダクトが強く、技術が弱いために爆発的な成長ができていない、というのは何となく考えているところです。が、この話はまた別の機会に。)
「爆発的な成長を成し遂げるためのプロダクトロードマップ」を実現できるように、盤石なシステムをつくっていく。システムを成長させるためには会社として投資できるかどうかももちろん大切ですが、そこについては事業が成長できれば問題ないでしょう。

描いたものを実現するところにコミットするのが、技術で事業を伸ばしていくということであり、僕の役割のひとつです。

ビジネスとシステムを両方スケールさせていく

オープンロジのシステムは9年ほど開発・運用されていて、それなりに歴史のあるシステムです。今はLaravelで実装されていますが、初期はCakePHPで実装されており、しっかりと設計がされていなかったのでLaravelに移行したような経緯があります。9年間開発しているにしては、比較的システムはしっかりとしていますが、さすがに長年の開発で技術的負債もたまりつつあります。最近は大型の契約も増えてきて、大量データ処理や拡張性の課題が顕著になりつつあります。

今後のビジネスのスケールを考えると、ここで技術的負債をしっかり返済して、システムもスケールする構成にしていく必要があります。

戦略はトップダウンで戦術はボトムアップで

私は今まで色々な開発の現場に関わってきました。そして、技術的負債の返済ができずに開発効率が上がらず、エンジニアのモチベーションが下がってシステムの品質が落ちている場面を何度もみてきました。
技術的負債を返済する方法はいろいろあります。テストコードを書く、コード整形をする、設計を見直す、作り直す... やることはわかっているのになかなか実行されずに悪化していく。

やれば良いだけなのに実行できないのはなぜでしょうか?
当たり前ですが、技術的負債の返済には工数がかかります。エンジニアの工数を確保しないことには返済はできません。どんなに優秀なエンジニアが来てくれても実行できなければ改善は進みません。そして技術的負債の返済にリソースが確保できないほとんどの理由は、そこにリソースを投入するというトップダウンでの意思決定ができないというところです。リソース確保の意思決定はボトムアップではできません。それがダメだとかそういう話ではなく、そもそも役割が違うのです。

CTOの役割=システム戦略を立てる事

技術的負債を返済するためのタスク一つ一つは戦術レベルの話になります。戦術はいくら積み重ねても戦略にはなりません。戦術の積み重ねをしていっても大局的な動きは見えてきませんし、大局的な動きがわからないものに意思決定をすることは、もっとできません。
全体的なシステム戦略を立てた上で、個別の戦術を積み重ねていくことが大事なのです。戦略を決めて改善の方針が決まれば、戦術レベルの話はエンジニアがどんどん提案してくれて改善が進みます。戦略はトップダウンで行い、戦術はボトムアップで行うのが物事をうまく進めていくための鉄則になります。

オープンロジに入社してからは、現場のエンジニアからのヒアリングを重ね技術的課題を明らかにし、中長期に渡って技術的負債をどのように返済していくかの全体的な計画を立てました。経営陣にも「ビジネスの投資として技術負債の解消が重要であること」を説明し、合意ももらいました。そして、先日開催された全社キックオフでも、技術負債の解消に取り組んでいくことを大々的に発表しました。

オープンロジは今、経営にも、ビジネスサイドにも技術負債の解消に理解がある状態です。

技術的負債の解消に銀の弾丸はありません。エレガントな方法論で一気に解決するのはほぼ無理で、地道に一つ一つの施策を着実に積み上げていく必要があります。その中でも優先順位をつけて、一つのゴールに向かって負債の解消を進めていく必要があります。

負債の中にも大小様々なものがあります。とりかかりやすいのは小さな負債の解消からですが、小さい負債の解消ばかりやっても根本的な解決にはなりません。まずは大きな負債にしっかりと向き合って取り組んでいきます。オープンロジのシステムの中でも長年エンジニアを苦しめてきた巨大なクラスがあり、そちらの負債の解消に向けて計画を立てています。またDB Schemaにも大きな課題があり、マイグレーションにかなりの工数がかかりますが、ここも構造変更をしていこうと計画を立てています。

負債が今後さらに解消されていけば、Developer Experience​​がもっと向上し、開発スピードも加速度的に上がっていきます。そうしてエンジニアが活躍・成長していけば、オープンロジが進んでいくプロダクトロードマップ、成し遂げたいこともちゃんと実現できるようになります。

エンジニアが活躍できる組織を作っていく

そして、テックカンパニーになるためには負債の解消以外の観点でも、エンジニアが活躍できる環境を作っていかなければいけません。

エンジニアが活躍できる環境について、僕は以下の3つが必要だと思っています。

1.Developer Experience​​の高い環境

DXの向上には技術的負債の解消もそうですが、そもそもの開発環境の整備も進めていく必要があります。静的解析の強化、Lintによるコード整形、テストコードの充実や高速化、CI/CDの整備、ディプロイ環境の整備など、システムで品質を担保する環境を構築していくことが必要不可欠です。

そもそも、こういったシステムで解決するべき問題を人が頑張って解決するのは効率が悪くなりますし、こういった環境で開発生産性を上げていくことなどできません。エンジニアがエンジニアとして当たり前の開発ができる環境をしっかりと作っていく必要があります。

2.自分の開発が事業の成長に結びついている、という実感が得られる環境

オープンロジはエンジニアとビジネスサイドに壁が無い上、月一で行われる全体会、月次振り返りなど情報共有の場が複数あるので、既にある程度ユーザーの声や事業の成長に関する情報が得られる環境ではあります。ただ、今後もっと強化していきたいと思っています。

その為に最近、CREチームも発足しました。これにより、もっとユーザーの声が聞きやすい環境になっていくと思います。

3.裁量をもって、戦術レベルの意思決定及び実行が行える環境

先にも書いた通り、CTOの役割は戦略的な意思決定を行うことだと考えていますので、戦術レベルの意思決定及び実行はエンジニアにどんどん任せるつもりです。その方が裁量を持って開発に取り組むことができますし、チャレンジにもなり、エンジニア自身の成長にも繋がります。エンジニアが成長していけば開発成果もあがりますので、会社にとっても嬉しい状態を生み出すことができます。

エンジニアが活躍できる環境を作っていかないと、そもそもレベルの高いエンジニアを採用することもできません。自分が活躍できない会社に入りたいエンジニアがいるでしょうか? もちろん活躍できるかどうかは本人の努力次第ですが、この3つを満たし、ちゃんとエンジニアが活躍できる舞台を用意するのも僕の役割だと思っています。

一緒に技術を使って物流の未来を作っていきませんか?

オープンロジが挑む物流業界は、「暗黒大陸」とも呼ばれるほど課題が見えていない業界です。オープンロジもまだまだ探索フェーズではありますが、その大きい大陸を一番見通せるロードマップを持っていると僕は思っています。

そのロードマップを信じて、僕は爆発的な成長を起こすための、強い技術を作り上げていきます。

もし少しでもこの挑戦に興味を持ってくれる方は、是非お話しましょう!!
皆さんからの応募を心よりお待ちしています。


その他、尾藤の記事はこちら💡

‎fukabori.fm:Apple Podcast内の89. 複数社のCTO経験から学ぶエンジニア組織マネジメント w/ BTO
‎fukabori.fmの番組、エピソード89. 複数社のCTO経験から学ぶエンジニア組織マネジメント w/ BTO-2023年2月22日
https://podcasts.apple.com/jp/podcast/89-%E8%A4%87%E6%95%B0%E7%A4%BE%E3%81%AEcto%E7%B5%8C%E9%A8%93%E3%81%8B%E3%82%89%E5%AD%A6%E3%81%B6%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E7%B5%84%E7%B9%94%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88-w-bto/id1388826609?i=1000601069435
~「失敗」から学ぶエンジニア組織論~ CTO尾藤とVPoEの坂井が語る、組織づくりに必要なこと【イベントレポート】 | Engineer team
こんにちは!オープンロジ採用広報担当です。今回は、先日行われた弊社主催の「CTO・VPoEぶっちゃけトーク! 〜失敗から学ぶエンジニア組織論〜」のイベントレポートをお届け📦三イベント内では弊社の...
https://www.wantedly.com/companies/openlogi/post_articles/478514
株式会社オープンロジからお誘い
この話題に共感したら、メンバーと話してみませんか?
株式会社オープンロジでは一緒に働く仲間を募集しています

同じタグの記事

今週のランキング

オープンロジ リクルーターさんにいいねを伝えよう
オープンロジ リクルーターさんや会社があなたに興味を持つかも