チーム力を最大化し、難易度の高い課題に挑み続ける。組織拡大をリードしてきた山富が、VPoEとして目指す次の組織づくり
こんにちは、山富啓嗣（やまとみけいじ）と申します。
オープンロジに24年2月に入社し、この度VPoEに就任しました。
このnoteでは、私がオープンロジに入社した理由や、VPoEとしてやっていくこと、大事にしたいことについて書いていきたいと思います。
キャリア
大学院を卒業後、ワークスアプリケーションズに入社し開発エンジニアとしてのキャリアをスタートしました。大企業向けのERPパッケージの開発に携わり、開発エンジニアだけでなくマネージャーも担当しました。その後、ワークスアプリケーションズ時代の知り合いに声をかけていただきヒューマンテクノロジーズに入社。小規模企業向けの勤怠管理SaaSの開発責任者を務め、ビジネスサイドとの要件調整、顧客訪問、評価制度の整備など、マネジメント業務全般に携わりました。
前職のラクスでは勤怠管理SaaSの立ち上げから参画しました。当初2名だった課を25名規模の部まで成長させ、プロダクトの方向性をリードしながら組織課題に取り組んできました。
日本の生産性向上に貢献したい
私はこれまでのキャリアで一貫してBtoBサービスに関わっています。その背景には、自分の仕事に対して「やって良かったよね」と言えるような仕事に携わりたい、日本の生産性向上や社会課題解決に貢献したい、という想いがあります。
BtoBサービスの開発は、ただ顧客が求めるように業務課題を解決するのではありません。その業務課題を解決した後に出てくる新しい課題や、横展開していけそうな解決方法など、一歩先まで見据えた開発を行っていくことが求められます。
私はそれが開発組織の役割だと思っていますし、顧客への唯一無二の提供価値となるものだと考えています。
そして、顧客の業務課題解決を進めていくことは、日本全体の生産性改善や、社会課題の解決にもつながると考えています。
顧客の業務課題を解決していくことで、顧客は本業に集中できるようになる。
顧客が本業に集中できるようになるということは、顧客の生産性が上がる。
顧客の生産性が上がるということは、日本の生産性改善や社会課題の解決にもつながる。
目先の課題解決だけでなく、一歩先の課題解決を繰り返す。そしてさらに先の、日本全体の生産性改善、社会課題の解決へも貢献していきたい。これこそが、自分にとってやって良かったよねと言えるような仕事に携わる、ということだと思っています。
物流業界の課題解決＝日本の生産性向上
オープンロジとの出会いは、ワークスアプリケーションズ時代の繋がりでVPoEの坂井さんとお話したことから始まります。
勤怠管理にずっと携わっていたこともあり、物流の2024年問題については知っていました。
しかし、実際に詳しく話を聞いてみると、2024年問題でよく注目される配送領域だけでなく、その上流の荷主業務や倉庫業務にも多くの課題があることを知りました。
特に倉庫においてはテレビで見るような全自動化された倉庫は少なく（日本の倉庫業の90%以上は中小企業であり、システムが入れられている倉庫は多くありません）、アナログなままでシステムによる貢献の余地が非常に大きい状態です。
物流は誰もが使う社会インフラですから、この業界の課題解決、生産性向上に携わることは、日本全体の生産性向上に広く貢献できると確信しました。
また、オープンロジが抱えていた組織的な課題も入社を決めた理由の一つです。
事業や組織の成長と共に、エンジニア組織のマネジメント強化が求められている。ここなら、組織の成長フェーズでマネジメントをしてきた自分の経験を活かして会社に貢献することもできると思い、入社を決めました。
VPoEとして
役割分担
既にオープンロジにはCTOの尾藤さんとVPoEの坂井さんがおり、私がVPoEになることでCTO1名＋VPoE2名のマネジメント体制となります。
CTOの尾藤さんは技術面での戦略を担い、坂井さんと私は組織面の戦略を担います。
組織面の戦略の中でも、坂井さんはこれまでに採用や制度を整備してこられたご経験が豊富なためその領域を、私は業務ドメインにまつわる開発体制づくり、特に事業成長を加速させるための生産性や開発組織のプロセス改善などを進めていきます。
一丸となって目標に向かい、エンジニアが市場価値をあげられる環境へ
オープンロジの開発組織は積極採用の成果もあり、ここ3年で2.2倍の規模となりました。
拡大していく組織の中で、開発メンバーが一丸となって会社の目標に向かって進むための環境をつくること、市場価値をあげられる環境をつくることが私のミッションです。
個人と組織のやりたいことを区別し、チームの総合力を上げる
開発組織のメンバーが一丸となって会社の目標に向かって進むためにはまず、個人としてやりたいことと、組織としてやるべきことをきちんと区別できるようにすることが必要だと考えています。
個人としてやりたいことと組織としてやるべきことをきちんと区別することは、組織のチームワーク向上につながります。ここで言う「チームワーク」とは、「メンバー一人一人が協力すること・信頼し合いながら働き、チーム全体の成果を最大化すること」です。
個人としてやりたいことと組織としてやるべきことが一致している状況であれば、それをやれば良いので悩むことはありません。しかし、組織に所属している以上、それらが一致しない場合もあります。
例えば、何か不具合が見つかり、チームメンバーが調査をしているものの原因を突き止められず悩んでいた場合。仲間が困っていたら助ける、というのはチームワークとして重要ですよね。「ここを調べてみたら？」とか、「以前、類似の事例があってこういう原因だったから似たような原因かも？」など、助言すると思います。この助け合いはオープンロジでも大切にしている文化であり、既に定着しています。
重要なのは、各々が果たすべき役割を果たすこと、組織としてやるべきことに対して、チーム内で自分に何ができるのかを考え行動することです。
時にはこれまでできなかったことにも挑戦してもらいながら、各々が発揮できる成果を最大化する。そうすれば、個人の能力も上がっていきますし、チームの総合力が各段に上がります。
また、他にもよくある例として、特定の技術を使ってみたい、導入してみたいということがあります。想い自体はエンジニアとして素晴らしいことだと思いますが、それは、組織としてやるべきことなのか？費用対効果がどうか、取り組む価値・工数があるのかを、必ず考えなければなりません。
事業を成長させるには、必ず人を巻き込まなければならない瞬間が発生します。そういった時に、誰を巻き込み、相手にとって欲しい情報を持って、妥当性が説明できるかどうか。
これを的確に判断・説明できる人はポジションを問わずどの企業に属しても重宝されますし、市場価値も高いです。
特に今のオープンロジのような拡大フェーズでは、組織の規模が大きくなる分、人の巻き込み力は一層求められるスキルです。そこを身に着けられる環境を作っていくことも、私の役割の一つだと考えています。
例えば既に取り組んでいることとして、開発リーダーやメンバーには、これまで私や坂井さんが担っていた、経営陣も含めた他部署との調整作業を、必要に応じて一部メンバー自身に担ってもらっています。
オープンロジには、代表の伊藤さんを筆頭に、現場の声を大事にする文化があります。
ただ、立場が異なる以上、時にはうまくいかないこと、目線が合わないこともありますので、事前に「どうコミュニケーションをとろうとしているのか？」「その場合はこういう話が出てくるのでは？」と壁打ちを行うなど、しっかりサポートを行うようにもしています。
仮説と検証を大切に
何かを進める際には、必ず仮説を立て、それに基づいて行動し、その結果を検証するというサイクルを繰り返すことも、効率的な開発や組織運営に不可欠だと考えています。結果を検証するために計測可能な数値指標を置きたいところですが、現実はそんな簡単ではなく、数値指標を置くことが難しい場面ばかりだと思います。そういった場合は、定性的な評価指標を置いてみることも必要です。
一方で、実際のところはやってみないと分からないのも事実です。重要なのはきちんと結果を想定することだと考えています。想定がなければ、再現性に乏しく、生産性のある行動に繋がりにくくなります。迷ったらまずやってみる、という言葉もありますが、これは、”行動することに不安や懸念を抱えている人”に対して、行動することで学ぶことも多いし行動しないと結果はついてこないよ、ということを伝えたい時に言われる言葉です。
仮説と検証という要素を加えるなら、「迷ったら（やってみた結果どうなるか、その理由は何かを想定した上で）まずやってみる」ということになるでしょう。括弧で書いた部分を抜いてしまわないように私自身も注意して使っていきたい言葉です。
仮説と検証を大切にしながら、組織としてやるべきことに対して各々が果たすべき役割を果たせば、チームの力が最大化される。チームの力が最大化されると、ビジネスが成長し、チームはより難度の高い課題に挑戦することができるでしょう。
組織としてやるべきことに焦点をあてることは、巡り巡って自分の市場価値にもつながるのです。
組織課題
「テクノロジーを使い、サイロ化された物流をネットワーク化し、データを起点にモノの流れを革新する」というのがオープンロジのビジョンです。そして、これを達成するために必要となるプロダクトを実現していくのが開発組織の存在意義です。
ビジョンを達成するとは、売上も大きく利益も出ているような状態だと思っています。ただそのためには時間軸が10年20年といったものになることや、ビジョン達成に必要な開発が直近1年間の売上にあまり寄与しない状況もあると思います。
直近の売上成長に寄与する開発とビジョン達成に必要な開発（言い換えると、中長期の売上成長に寄与する開発）とを、どのようなバランスで進めていけば良いかを決めるのは経営層での話ですが、その判断材料となる指標を開発組織として示していく必要があります。
現時点でその指標はまだ未定で、どういった指標が良いかを検討している段階です。
また、ビジョン達成と直近の売上成長を両方やっていくためには開発組織だけに閉じていて良いわけでもありません。PdM（プロダクトマネージャー）やビジネスサイドと意見交換しながら、開発組織としてできることを提案していくべきです。こうした協働体制の下で、開発メンバーが活躍していける環境を作り上げていくことも私の役割の一つだと考えています。
これまでの取り組みと今後の展望
私がオープンロジに入社してVPoEの坂井さんから言われた課題が二つありました。1つ目は、開発組織がプロダクトロードマップにどれだけコミットできているか分からないということ。2つ目は開発スケジュールが当初想定していたものからズレることが多いということです。
前者については、元々各メンバーの方々には工数入力をしてもらってはいましたが、それを活用できていない状況でした。月末に一ヶ月分の工数を入力するメンバーもおり、入力された内容がどこまで正確か分からない状況でした。
開発の工数を正確に把握することは、メンバーの状況を把握できるだけにとどまらず、案件ごとの費用対効果（かけたコストに対して、どれだけビジネス的な影響があったか）を把握するための非常に有効な手段です。新たな施策を始める際にも、それらの数値を参考にして話を進めれば、組織としてより納得感をもって取り組むことができるようになります。
そのため、現在は各チームごとに週次定例の場で工数状況の確認をしていくことで入力漏れを防ぎつつ、ある程度の精度を保つようにしています。
後者については、開発中に要求仕様が変わってしまうことでスケジュールが遅れてしまうことが主な要因でした。そのため、PdMチームと相談し、設計フェーズを終えたタイミングで要求仕様が不明確な部分を無くしておく。その上で、開発タスクの洗い出しおよびその工数見積もりを行い開発スケジュールを引き、そのスケジュールを遵守するようにしました。
とはいえ、開発中に要求仕様が変わってしまうことは許容しておきたかったので、新しい要求によるタスクの追加も許容しています。設計フェーズが終わったタイミングで洗い出したタスクとは分けて管理するようにし、後日どれくらい想定外のタスクが出てきたかも振り返れるようにしました。
数値だけを見ていくとどうしても機械的になってしまいますし、常にフルスピードで走らないといけない状況になりがちです。それは組織の疲弊につながり、技術力向上など他のことに手をつける余裕もなくなってしまいます。数値で見れる部分はしっかり数値を見つつ、常に遊びのある状態をキープしている組織にしていきたいと考えています。
幸いなことに開発メンバーからは「仕様検討の抜け漏れを事前に把握できてPdMと調整しやすくなった」「作業の見通しがよくなった」「整理整頓が好きなので性に合っている」など、比較的ポジティブなフィードバックをもらえているのは嬉しいところです。
物流、業務課題解決、社会貢献にご興味がある方へ
オープンロジのステークホルダーには大きく分けて荷主様と倉庫様がいます。それぞれの業務領域で求められる要件は異なるため、開発チームはそれぞれに分けています。しかし、物流という特性上、荷主業務向けの開発であっても倉庫業務を、倉庫業務の開発であっても荷主業務を想定しながら開発を進める必要があります。複雑な要件になりやすく、難易度の高い課題に向き合うことも非常に多いです。そこに面白みを感じるエンジニアにとっては、日々刺激的な毎日を過ごすことができる環境だと思います。
オープンロジのビジョン達成まではまだまだ道のりが長く、課題もたくさんあります。しかし、それを乗り越えた先には、物流業界の圧倒的No.1のポジションがあると思っています。その過程の中で組織や技術課題の解決などもしていく必要がありますので、オープンロジでの経験は必ず今後のキャリアに活きてくるでしょう。
「物流」、「課題解決」、「社会貢献」、このようなキーワードに興味がある方、一緒に業界No.1への道へ歩んでいきましょう！ご応募お待ちしております。