こんにちは、オープンロジでソフトウェアエンジニアをしている西山です。
2024年12月に行われた「PHPカンファレンス2024」で「リアルオペレーションを支えるPHPアプリ開発」をテーマに登壇してきました。

当日の様子や、お話できなかったことも含め、レポートを残したいと思います。

自己紹介

アプリ向け広告事業で広告プラットフォームシステムのソフトウェアエンジニアからキャリアをスタートし、オープンロジは2社目です。オープンロジでは2024年1月に入社以来、技術開発部WMSチームのメンバーとして、倉庫業務を支えるシステム開発に携わっています。倉庫の作業効率向上、作業品質向上を支える機能開発に従事しつつ、皆さんの生活を陰ながら支える物流インフラの水準を上げるため、活動しています。

登壇資料

登壇内容

今回の登壇では、オープンロジがここしばらく注力してきたハンディ端末アプリ開発での取り組みについて発表しました。その内容をかいつまんで紹介していきます。

オープンロジとは

まず今回の発表テーマを背景から理解してもらうため、オープンロジの事業内容を簡単に紹介します。

オープンロジでは、倉庫会社様、配送会社様などの物流パートナーと提携しながら、それらをネットワーク化し、EC運用の裏方を一手に引き受ける、いわゆるフルフィルメントサービスを提供しています。

EC事業というのは、まず売りたい商品があるEC事業者（荷主）様と、買いたい商品がある購入者様のマッチから始まります。ただ、そこには物理的距離があり、実際に購入してもらったものを届ける方法を用意しないといけません。しかし、物流業界は複雑で多数のプレーヤーがいるため、EC事業者様は最初に「商品を作ったはいいけど、どう届ければいいか、誰に相談すればいいか分からない」という問題に直面します。

オープンロジでは、その声に対して、システムを通してオープンロジの物流ネットワークにお繋げし、個々のEC事業者様にあった最適な物流を提供していくことで、EC事業者様と購入者様の物理的距離を埋めていくということを目指しています。

倉庫内業務

今回開発したハンディ端末アプリが活躍するのは、オープンロジ物流ネットワークの中でも、パートナー倉庫様における業務です。

倉庫内業務には、概ね倉庫への入庫、倉庫内での在庫管理、倉庫からの出庫という3つの段階があります。まず、物は製造拠点を出発し、倉庫に搬入されて保管され、発送の時を待ちます。ただ、じっと待っているわけではなく、絶えずその時々で倉庫内の最適な位置に移動されています。そして、購入者様から注文を受けると、いよいよ倉庫からの旅立ちの時を迎えます。といってもすぐに旅立つわけではなく、倉庫内の作業場に一度移され、状態確認や流通加工などが行われて、配送業者様に集荷された後、購入者様の手元に届けられます。

このように絶えず物は倉庫内外を動き回っているのですが、物が自ら動いてくれるわけではありませんから、そこには必ず第三者が介在しています。このような物を動かしてくれる方々にどう指示を出すのか、その結果をどうデータ化してシステム管理していくのかを考えるのが、私が取り組む領域になります。

倉庫管理システムと物理的制約

「物は勝手に動いてくれない」以上、倉庫業務には様々な物理的制約が生まれてきます。

例えば、何をするにしても、作業者の方は対象の物がある場所まで移動しなければいけません。また、物を持つだけで両手が塞がってしまうので、「作業をしながら作業内容を記録する」といったことも難しい場面が多いです。さらに、物には体積がありますから、置くだけで空間を占有します。それぞれの物の位置が近すぎると、破損の原因となったり、取り違えの原因となることもあります。

これらの制約の下で、システムと連携するのは至難の業です。システム連携をデスクトップPCでしかできない場合、一度PCのそばに物を持ってきて、作業しながらPCに情報を入力、作業が終わったら物を元の位置に戻すといった作業が必要になり、手間かつ作業ミスの原因にもなります。

そこでハンディ端末、通称HHTの登場です！

HHTによる制約の突破

HHTは倉庫運用の柔軟性と品質の向上を目指して導入されました。
HHTであれば、作業したい位置まで自由に持ち運び、その場でシステム連携することができます。また、手に装着することも可能で、置き場所もいらないため、作業の邪魔になりません。必要なタイミングで使うこともできます。これにより、倉庫空間レイアウトが柔軟に設計できるようになり、置く場所、持ち運びに不自由しないことでシステム連携の幅も広がります。

導入結果は狙い以上で、倉庫空間レイアウトの自由化による作業効率、空間効率の改善に繋がったり、今までシステムが関与できていなかった部分にアプローチできるようになった他、倉庫作業のために必要な機材・設備が単純化するという副次的効果もありました。これは、端末数の調整も自由になり、今まで紙で行っていた作業を代替できたことによるものでした。

HHTアプリに求められたもの

HHTの導入において、ソフトウェア開発現場では幾つか工夫が求められました。

HHTの導入は、システムと作業をより密に連携できるようになるのではないかという期待から始まりました。しかし、HHTの導入を進めていくことによるポジティブな効果が見込まれる一方、システム連携がネックとなり逆に作業の品質や効率が下がる懸念もでてきました。そこで、アプリ開発では、システムとの連携強化と今まで通りの作業品質確保を両立することが求められるようになりました。

具体的には、システム連携時にサーバとの通信待機によってロード待ちが続き、作業の途上で待ちが発生すること、小さな画面を注視しないとミスに気づけないといったことを最小化する必要がありました。ただ、その過程でシステム連携の幅を狭めてしまうと、今度は倉庫全体の作業状況がリアルタイムに確認できなくなったり、正確な作業を保証できなくなったりしてしまい、システム連携する意味そのものがなくなってしまいます。そのため、これらの間でバランスをとり、倉庫作業の阻害を最小化しつつ、システムサポートによる作業支援を最大化する必要がありました。

これを、ソフトウェア開発の工夫で両立させていきました。

ネットワーク通信の工夫

工夫の一つが、ネットワーク通信にメリハリをつけることです。

倉庫運用の柔軟性向上のためにはリアルタイムなシステム連携が求められましたが、それを実現するには細かいネットワーク通信が必要になってきます。しかし、単純にこれを随時通信という形で実現すると、作業中断が起こる可能性が高くなってしまいます。非同期化で解決できる場合もありますが、それでは解決しない場合もあります。特に、システムの連携結果のフィードバックが遅れると、作業を進めてもまたやり直すことになったりと、結果的に作業を阻害する結果に繋がってしまうこともあります。

倉庫の作業をより深く知ると、どうやら作業にはそれぞれの工程ごとに特徴があり、作業中断が起きると大幅に効率が下がり品質に影響してくる工程と、システム連携が遅くてもそこまで作業に影響が出ない工程に分かれる事が分かってきました。私たちはこれが作業効率を損なうことなく、リアルタイムなシステム連携を可能にするソフトウェア設計に利用できることに気づきました。

これをソフトウェア開発にも利用し、中断NGの部分はネットワーク通信を最小限にしつつ、作業が一区切りついたタイミングで通信してシステム連携するような設計を選択しました。作業者の方も人間ですから、ずっと作業をとめどなく行っているわけではなく、ある程度細かく区切りをつけていった方が作業品質が向上します。このような現場の事情も考慮した通信設計を行うことが、HHTに求められる体験の実現に繋がりました。

API設計の工夫

また、API設計も、よりHHTアプリの需要に特化させました。

API設計のプラクティスとして、リソース指向であったり、ステートレスな設計というものがあります。しかし、HHTアプリにおいて、状態をどう扱うか、通信にいかにメリハリをつけていくかは、ユーザ体験、ひいては現場へのシステム連携浸透の生死を分けていきます。そのため、一般的なプラクティスを取り入れていくだけでは、結果的にソフトウェア開発がアーキテクチャとの戦いとなってしまい、コードの保守性向上という本来のプラクティスの目的が達成されなくなってしまいます。大事なのは、一般的なプラクティスに完全に則ることではなく、コードの保守性を維持しつつ、どうソフトウェアの変更に立ち向かっていくか、それによりどうユーザ体験を作っていくかを考えることです。

そこで私たちは、一般的なプラクティスからは外れつつ、HHTアプリに求められているものに合わせたAPI設計を行い、またそれだけでなくAPIの独立性などの保守性に対する指標も保つように開発を進めました。具体的には、作業を工程という単位で整理してモデル化し、その単位でAPIを区切ることで保守性を確保する取り組みを行なっています。

状態設計の工夫

倉庫の業務を支援する上で、状態とシステム開発は切っても切り離せない関係にあります。この状態をいかに取り扱うかも非常に重要でした。

上のスライドでは倉庫の出庫作業に関わる状態を例に出して説明しています。この例のように、見た目の上ではパッと捉えられる状態遷移が、実は全く異なるプレーヤーの思惑や、異なる対象に対して動いているということがよくあります。これをそのままシステム側に反映してしまうと、システムが実はどんどん機能しなくなっていきます。なぜなら、それぞれのプレーヤーで状態を受けて起こす行動が異なってくるからです。

最終的にはこのように整理する方が、それぞれのプレーヤーの都合を反映した状態遷移になり、システムを複雑にさせにくい設計にできました。

先ほどの状態遷移は荷主様側、倉庫様側の行動の一部を切り取り、複合させたものでした。しかし、実際には倉庫様側は、今どの作業工程に入っていて、修正依頼が来た時どの作業工程まで戻らないといけないかを気にしていて、荷主様側は今修正依頼ができるのか、修正依頼が受理されたのかを気にしていました。その情報を元に、行動を変えていたためです。これは元々の状態遷移では反映できない部分でしたが、荷主様側、倉庫様側で状態を分離することで、よりそれぞれの都合にあった体験をできるようになりました。

このような設計を進めていくにあたってのテクニックとして意識したのが、以下の点です。

一つが状態単位の見極めです。都合が異なるもの、対象の異なるものを一緒の状態で扱うのは、多くの場合設計破綻に繋がります。また、都合を作っている人、対象を知ることで、見えていなかった状態遷移の選択肢が見えてくることもあります。ここから、現場の状況変化が誰の都合で起きるのか、何に対して起こるのかを深く知ることが、状態設計において大事になりました。

もう一つが、状態遷移の見極めです。現場での状況変化への対応の仕方や、その判断基準を知ることで、遷移と状態が見えてくることが多いです。ただし、見えてきたものは複数の状態単位の集合だったりもするので、さらに状態単位を見極めるステップを踏むことが大事になります。

状態設計に失敗した顛末を紹介したこのスライドには多くの聴講者の方が共感を覚えたようで、このスライドを見ながら考え込む方がチラホラいらっしゃったのが印象に残っています。

まとめ 

PHPカンファレンス2024で発表した、HHTアプリ開発現場の取り組みを紹介しました。

物流現場は、システム化できない部分が非常に多いと言われています。その原因は、物流現場が物理の法則から逃れられないということに起因しています。その現場に対して、ただソフトウェアを当てがうだけでは、受け入れてもらえませんし、何より根本的な課題解決に繋がりません。
しかし、現場の理解を深め、ハードウェア、ソフトウェアによるエンジニアリングの工夫をぶつけていくと、実は乗り越えられることも多いです。もちろん、そのような開発を進めていくことは非常に難易度が高く、毎日頭を悩ませる日々が続きますが、エンジニアの腕の見せ所であり、また物流の1ユーザとしても非常に面白い体験だと感じています。その一端を登壇でも、この記事でも感じてもらえていれば、嬉しいです。

ちなみに、オープンロジからは同じ開発メンバーである@rikutoさんも「テストコードのガイドライン 〜作成から運用まで〜」というタイトルで個人登壇していて、満席でオープンロジスタッフが応援にいけないという嬉しい悲鳴が上がるという場面もありました。登壇後はブースで、HHTアプリや物流業界に非常に興味を持った方とブースでお話ししたり、それだけでなくエンジニアリング技術として今回の取り組みについて語る機会もあり、非常に面白い機会となりました。

We are hiring!

オープンロジの開発は、お客様が送りたい物と、それを届けることに関わる全ての人、そしてそれを支えるシステムに向き合う仕事です。そこには、ソフトウェア技術的に難しい課題ももちろんありますし、ハードウェアの課題、物理的制約など様々な課題が立ちはだかることもあります。しかし、それを技術の力で乗り越えることで、届けたい物が当たり前に届く、そんな体験をエンジニアが作っていけるのがオープンロジで働く魅力です。

私たちは、一緒にシステムの力で物を届ける体験を変えていく仲間を募集中です！もし、この記事を読んでオープンロジに興味を持ってくださった方は、ぜひカジュアルに話を聞きに来てください。お待ちしております。