28
25

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

できるか!?ニュービジネス 初心者が1日で物流追跡アプリを作ってみた

Last updated at Posted at 2022-06-11

1.この記事の対象の方と完成品

1-1 この記事の対象の方

  • トラック間や鉄道の連携、組み合わせの非効率さにお悩みの方
  • DXが大好きで非エンジニアから情報システム部へ異動された初心者の方
  • 「トラック」(陸送)、「鉄道」(モーダル)、「船舶」(海運)、全部ぶつ切りで効率悪くね?と思ってる方
  • 大規模開発しなくても、新規事業は作れると思っている方
  • むしろ新規事業で大規模開発っていろいろやばいよね!?と思ってる方
  • 1日で新ビジネスのモックを作りたい方

私も新米ですがアイデアを形にしようと思いノーコード開発へ挑戦しました。よろしくお願いいたします。

1-2 完成品(第一期)

「トラック・鉄道輸送位置捕捉 配送管理アプリ」

QRコード
image.png

1-3 使用したツール

  • Glide

  • Python(余力次第で使用するかも・・・)

1-4 この記事の狙いと構成

この記事は「ぶつ切りになることが多いトラック間の情報連携」と「もっとぶつ切りになる「陸・海・空」の物流連携」を一元管理できないか?に挑戦した記事です。つきましては
・企画のスコープ切りとインタビュー
・実装
二つの話が必要に応じて交錯します。

2. またトラック行っちゃったよ・・・・・

2-1 出先での荷物の積み替えは一苦労


さてシステム部へ配属されて二か月半。
「残貨どーすんだよっ。遅れたら次の便に乗せらんないだろ!」
という声を毎日、背後にいる物流実務チームから聞かない日はないです。。
ほぼ毎日聞くので、どうにかできないかなと思いヒアリングをしてみました。

わかってきたのは
・物流トラブルは絶対に起きる
・現地で違う貨車へ積み替えや新しいトラックを手配するのはかなり手間暇かかる。
・どうにかしようと、予めこちらから指示を出せればよいが、「JR貨物」「運送会社」「内航船(船舶)」のすべてをアレンジするには、運行情報や状況把握がぶつ切りで正確に把握できるのに時間がかかる。怖い。
・実現できたら大幅な効率改善が見込めるのだが・・・・・。
ということ。

なので「これらを解決できる可能性がある」と伝えたうえでモックを作ってみることにしました。
( Glide 使用(後述)。モックとはガワだけの物のこと)

2-2 モック

「このアプリにどんな可能性を感じるか」
不思議なものでモックが実際に自分の手のひらにあると、皆いろんなイメージがわいてくるようです。
「動かない」と分かっていても思わず画面を触ってしまう人。
パソコンの画面へ直接タッチして、やはり動かないのを納得する人
色々な人がいました。
そして、実感がわくと様々な様々な意見や利用できそうなシーンが当事者たちから出てきました。

モック(デフォルトの設定を流用 遷移先はサンフランシスコのホテル等未設定のまま)
image.png

出てきた意見
・店への配達には使えなさそう(30代 物流実務担当者)
・3PL(直営ではない配送業者さんの事)のトラックも把握できるか。一回限りの契約が多く追跡できないし投資もできない(40代 物流実務責任者)
・ウーバーや東南アジアのGrabのようなマッチング機能はつけられるないのか?インドネシア赴任時に創成期のGrabを見たが最初は使えたものではなかった(新規事業責任者)
・法律とかの規制も調べなきゃまずいよね(30代 物流実務責任者)
・お金はどれぐらいかかるの?(システム担当者)

3. 交通整理と実装開始

3-1 交通整理と限られたリソース

話を聞くと色々なアイデアが浮かんできます。ただ、問題はリソース配分をどうするか。
結構、大きめの粒度なので「一気に実装」は難しそうです。

そこで今回は「MVP」という考え方を採用しました。
MVPとは「実用最低限の機能をコアとして実装を進める」考え方
ガントチャートやWBS(Work Breakdown Structure)といった手法を知っていても、優先順位を間違えては後で苦しくなった経験を持っている人も多いのでは(大型PTあるある)
これは「その優先順位付け」を自身や周囲と共有するための考え方ですね。
image.png

そして今回のMVP(別名 スコープの切り方-コアバリューのありか)は「位置を表示する」こと。
これを第一期構築とし、残りは「需要がありそうなら実施する」フェーズ分けを実施しました。
第三回課題 配車アプリ 推進図ャ.PNG

用語説明
RFPとは

RFPを甘く見ると発注側も最後は困りますよー
(↑発注側で何度も経験した)

3-2 実装開始

さて、今回はGlideというアプリを使用

さきほどはテンプレートからそのまま転用していましたが今度はスプレッドシート設定からです。
理由はこの後、二期・三期と追加になったときに情報追加が必要になるから。
今までは一文字替えるのに数十万請求されていたのが全部、内製化できるのはありがたいことだよなぁ。
やり取りも基本設計→詳細設計で全然違うものが出てきてSEさん、営業さん、発注側全員がそれぞれ違う意味で悶絶することもないし。

今後は発注側でモックを作ってベンダーさんに渡した方がお互いに齟齬がないのかもしれない。

作ったデータベースはこんな感じ。この後、第二期で緯度経度を取得して書き込みに挑戦する(かもしれない、です)
image.png
*写真はGlide側でUPすれば自動的にURLが入るので最初の時点では入りません

Glide側はこんな感じの見え方になります
image.png

4. 完成

4-1 完成画面

トップ画面

配車一覧表

トラック詳細

4-2 皆のフィードバック

これならトラック版Grabみたいなニュービジネスができるのかもね。面白いじゃん(新規事業担当者)
・規模の小さいエリアはリアルタイム捕捉システムを入れると採算が取れない可能性が高い。これなら良いかも。(システム担当者、運行担当者から別個にでました)
・幹線の方でも使用できる。(物流実務担当者)
・今あるお金を払って開発している位置捕捉システムとの整合性はどうする?(システム担当者)
・位置捕捉の正確性はどうなのか?(システム責任者)
・この情報にアクセスできる権限設定はどうなのか?(セキュリティ担当者)

いや、まだ第一期しか終わってない試作版ですから・・・・・。
一日で企画から実装までやったんですよ。
2週間遅れのコードレビュー会みたいな反応はやめて・・・。

とおもいつつ、この辺の質問が来ると思って準備しておいてよかった。
具体的な質問が来る、というのは皆が可能性を感じてくれている事なので。

5. やるのか!?第二期! やれんのか!?(猪木調)

あと3時間時間があります・・・・。やるならPythonだけどでできるのか・・・。
(迷い中)

28
25
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
28
25

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?