2020.01.14

417

ハコベルの開発スタイルをご紹介します!

こんにちは。
物流サービスのハコベルで一般貨物 (普通トラックを使用して荷主の荷物を運送する業界)向けの「ハコベルコネクト」のフロントエンドを担当している丸山です。

私は前職では受託の制作会社におりラクスルに入社して3ヵ月ほどなのですが、ハコベルではこれまで経験してきたものと開発の進め方が結構異なると感じる場面が多かったので、ハコベルが日々どのように開発されているのかについてご紹介します!

ハコベルコネクトとは

ハコベルコネクトは、求貨求車と自社・協力会社の配車管理が簡単にできる「物流プラットフォーム」です。
配車依頼や、荷主様と運送会社様のマッチング、運行状況など物流をトータルで管理・効率化することを目指しています。

新鮮だったところ

FBや要望の吸い上げ・開発が早い

まず特徴的なところとして、FBや社内・顧客要望への対応が非常に早いです。

ハコベル社内にはお客様のマッチングをサポートする配車サポーターと呼ばれるチームがあります。
配車サポーターの方達は日々ハコベルコネクトを使って荷主様の荷物と運送会社様のマッチングを行なっており最も身近なプロダクトのユーザであるため、日常的に社内インタビューを実施し常にサービスの使い勝手や改善できるところがないかを分析しています。
ヒアリング以外にも実際の業務の様子を撮影し、いつ・どんな作業で時間がかかっているのかなどを分析し、より効率的にするための機能開発や改善を行うこともよくあります。

また、営業メンバーなど実際のお客様との接する機会の多いメンバーを対象に週次でFB共有会を行なっており、お客様にどんな機能が喜ばれたか、どんなところに不満があるかなどを開発チームにも共有してもらっています。

こうして挙がった改善案にはそれぞれ優先度が設定され、優先度が高いと判断したものはすぐに開発をしていきます。
受託の開発ですとどうしても実際のユーザの声を吸い上げづらい場面というのも出てきてしまっていたのですが、こうした取り組みよって開発者としての「おそらくこうだろう」ではなく、より精度の高い価値を出すための開発を素早く行うことができます。

最近もこうした要望によって追加された機能がいくつかあるのでそれらがどのようなサイクルで開発されたのかをご紹介します。

案件検索条件の保存機能

ハコベル上で日々発生する膨大な案件(いつ・どこに・なにを運ぶかという依頼)のなかから、自分にあった案件を絞り込むための検索機能はもともとあったのですが、その項目数は多岐に渡ります。

案件検索条件

なのでユーザは検索を行う際にその項目を設定していくのですが、社内インタビューを行う中でユーザごとに頻繁に使う検索パターンがあるということがわかりました。
そこで自分が頻繁に使用する検索の条件をDBに保存することができるように機能追加を行い、保存した条件をすぐに呼び出せるようにしています。

案件検索条件の保存

この機能によって検索条件をいちいち細かく設定する必要がなくなったのですが、その後のFB共有会にて「ページ遷移を行なった際にもう一度保存した条件を呼び出すのが煩わしい」と感じているお客様がいらっしゃることがわかりました。
そこで、最後に検索を行なった条件はブラウザのLocal Storageに保存し、ページ遷移などを行なった際も最後に検索していた条件を復元するように改修を行なっています。

CSVによる案件の一括登録機能

通常ですと案件は1件ずつ積地や卸地、日時の指定などを入力して登録していくのですが社内インタビューを行なっていくと、毎月ほとんど同じ内容である定期案件というものがあり、その入力に非常に時間がかかっているということがわかりました。
CSVで一括で登録する機能を作れば毎月使い回すことができ効率化されるのではという仮説のもと、お客様にもヒアリングをしてみるとCSV一括登録には一定のニーズがあるようです。

そこで機能追加を行うことにしたのですが、定期案件は毎月発生するのですがその月の案件入力までに機能をリリースするのは難しいという判断になり、まずは社内向けにCSVから案件を登録するバッチの開発のみを行い、初月は入力済みCSVをいただいてエンジニアがバッチを実行することで登録を行いました。
その後APIやUIの開発を行い、社外のユーザの方にも使っていただける機能としてリリースしています。

CSV一括登録

これまでは最初にある程度決まった要件があり、納期に向けて全ての開発をまとめて行なっていくというケースが比較的多かったので、このように要望に素早く応え、バリューを出すために柔軟に段階を踏んでリリースしたりというのは新鮮な感覚でした。

スクラム全員が仕様策定部分に参加して理解度を高める

ハコベルでは開発に関わるメンバー全員が、全てではないですが仕様検討に参加しています。
メインとなるのはプロダクトマネージャーではあるのですが、スクラム内のフロントエンドエンジニア・バックエンドエンジニア・QAエンジニア・デザイナーも仕様検討の打ち合わせやユーザインタビューに参加し、プロダクトやプロジェクトへの理解度を高めています。

そうすることで、仕様を改めて説明したり資料を必要以上に詳細に用意する手間が省け、また各自のタスクを同時進行で進めていくことができます。
また、リリース前には必ずQAを行なっているのですが、QAエンジニアの方も仕様を把握しているので開発側で拾えていなかった考慮漏れなどを指摘してもらえたりするのも大きなメリットではないでしょうか。

QA

また、リリースの際には プルリクエスト → CIツールでのテスト → レビュー → QA → Slack上でデプロイコマンドでリリース と確立されているので、新しいメンバーでもあまり迷うことなく安心して開発を進めていくことができます。

まとめ

ハコベルはこのようなフローで日々開発されているのですが、「おそらくこうだろう」ではなくユーザと近い距離でFBをきちんと収集していくことや、チーム全員が共通理解をもって開発していくことで、素早く本質的な価値を提供していけるのかなと思います。

チーム年末振り返り会
カジュアルに年末の振り返りを行なっている様子。普段からワイワイと話し合う機会が多いです。

 

ハコベルおよびラクスルではエンジニアリングの力で世界を変えたいフロントエンドエンジニア、サーバサイドエンジニアを絶賛募集中です!
本記事を読んで興味をもっていただいた方はぜひご連絡いただければと思います!

物流のハコベル( https://hacobell.com )でフロントエンドを担当しています。

2020.01.14 #Culture
417

ハコベルの開発スタイルをご紹介します!

この記事のURLをコピーする
この記事をシェアする ツイート シェア はてな