KURUMの開発風景 - 豊島区限定の位置情報設備トラブルアプリ編
最近カードゲームにハマってます。誰か一緒に対戦してください🫠
というわけで、今回第一弾KURUMの開発風景編は、お客様の新規事業でスマホアプリの開発を行った時の話を紹介します。
開発の話でもなく、ビジネスの話でもなく、お客様とワイワイやりながら真面目にアプリを作っていったぜって話です。
何を作ったか？
本題ですが、位置情報マッチング系のスマホアプリを開発しました。
その名も「キンキューズ」
（まずは）豊島区限定で設備トラブルに特化したマッチングアプリです。
ざっくりいうと、設備トラブル（エアコントラブル、電気トラブル、水道トラブルなどなど）が発生した店舗が、現場の近くの作業員に作業依頼をできるというサービスです。
近くにいなければ、運営スタッフが駆けつける仕様🏃
どうして作ったのか？
私たちがこのアプリを開発した理由は、作業員の手配に関わる時間とコストの問題を解決するためです。
従来の方法では、店舗が設備トラブルに対応するために作業員を見つけるのに膨大な時間がかかり、効率的ではありませんでした。
（代表がLINEで仕事を受けて現場に向かえる作業員を片っ端からあたっていくというやり方。。。）
このプロセスを簡素化し、店舗と作業員が直接やりとりできる仕組みが必要だと感じていました。
まずは、時間とコストの削減を実現することを優先に考えました。
この直接的なコミュニケーションとマッチングシステムにより、設備トラブルの迅速な解決が可能となり、日々の業務効率が大きく向上することが目標になります。
作業員側においては、作業員の手配と管理プロセスをデジタル化し、効率化を図っています。アプリを通じて、作業員は簡単に仕事を見つけ、管理することができます。これにより、作業員の待機時間の削減や、より多くの案件への迅速な対応が可能になります。また、データ駆動型のアプローチにより、作業員のスキルと顧客のニーズをより正確にマッチングすることが出来るようになると考えてます。
顧客側においては、基本的は顧客体験の向上にも注力しており、従来の電話やLINEを通じた受付を行いつつ、アプリを介した直接的なやり取りへとシフトすることで、データを蓄積行い、きめ細かいサービスを目指していくことを目的としております。
電話でやりとりすることに抵抗がある、作業員の情報を依頼する前に知りたいなどの観点においてはニーズを調査していく必要がありました。
どうやって作ったか？
アプリの開発プロセスは、まず現状の業務フローを徹底的に分析することから始まりました。私たちは、店舗と作業員の日常業務を詳細に調査し、どのようなフローであればアプリが最も使いやすくなるかを検討しました。この分析を基に、アプリの主要機能を設計しました。位置情報に基づく作業員の検索、見積もりの提出、顧客による決済、現場に向かうタイミング、チャットが開始される条件など、細かく矛盾なく洗い出しを行いました。
これらの機能がスムーズに連携し、矛盾なく動作することを確認するために、クライアントとの密接なすり合わせが不可欠でした。
各ステップでクライアントのフィードバックを積極的に取り入れ、実際の業務に即した使いやすいアプリの実現を目指しました。
類似のサービスがないため、デザインプロセスは、なるべくシンプルにしつつ、実際に作業を行う方の意見を反映をしていきました。
現状のLINEの運用からなるべく乖離を起こさないように、アプリをひらけば次の現在の状況や、次のアクションがわかるように心がけました。
このプロセスの中心には、Figmaという強力なデザインツールがありました。
Figmaを使用することで、私たちは顧客の要望を視覚的な形に変換し、リアルタイムでの動きやインタラクションを確認することができました。
このアプローチにより、デザインの初期段階でのアイデアを迅速に試作し、改善することが可能となりました。
また、Figmaの共有機能を活用することで、アプリエンジニアとの連携もスムーズに行えました。デザインと開発のチームが密接に協力することで、技術的な制約とユーザー体験のバランスを取りながら、最終的な製品のデザインを洗練させることができました。
あとは、スマホアプリはFlutterで作ったり、リリースまでの工程をcodemagic使って自動化したり、APIのCI/CDや自動テストなど書きたいことは盛りだくさんですが、書ききれないのでこの辺でやめときます！
あっ、パンフレットとかも作成できます🤗
どのような体制で開発してるのか？
お客さんとは、和気あいあいとした中にも、時には戦略的な議論を交わしながら、プロジェクトの方向性を共に決定していきました。
アイデアを出し合い、時には激論を交わしながら、一緒にアプリの未来を描いていきます🚃
心理的安全性爆上がり状態の定例風景 真ん中から左が弊社
技術面では、AWS（Amazon Web Services）の幅広いサービスを活用して、アプリの開発を加速しました。
特に、データ処理やストレージ、サーバーレスアーキテクチャなどのAWSサービスを利用することで、複雑でヘビーな機能も迅速かつ効率的に実装することが可能となりました。この技術的な柔軟性とスケーラビリティは、私たちの開発チームにとって大きな強みとなり、クライアントの要求に応じたカスタマイズや拡張をスムーズに行うことを可能にしました。
チャット機能はAWSのAppSyncを使ってほぼ1〜2日で実装できました🤗
このように、クライアントとの緊密なコミュニケーションと最先端のクラウド技術の活用により、私たちはスピーディーに低コストでアプリケーションの開発を実現しました。
今後もこの体制で、さらなる革新を目指します。
なぜ豊島区限定か？
私たちのアプリは、"スモールスタート、ビッグインパクト"を目指しています！
つまり、いきなり全面的に正式版をリリースするのではなく、まずは小規模でスタートし、実際に使いながら徐々にブラッシュアップしていくという戦略です。
まず、私たちはアプリだけでなく、緊急対応の事業も同時に進めています。これには、電話やLINEを通じた従来の受付方法も含まれており、アプリを通じてのサービス提供も併行しています。この段階的なアプローチにより、お客様は従来の方法と新しいアプリの両方を利用しながら、作業員さんの声を直接聞くことができます。これにより、私たちはお客様のフィードバックを直接受け取り、アプリをより使いやすく、効果的なものに改善していくことができます。
そして、なぜ豊島区限定でのリリースなのかというと、まずは私たちのクライアントのオフィスがある地域から始めることで、サービス品質を高いレベルで維持しやすいからです。地域を限定することで、サービスの質を徹底的に管理し、お客様からの貴重なフィードバックを集めることが可能になります。この地域での成功と学びを基に、徐々にサービスエリアを拡大していく計画です。
結局のところ、私たちの目標は、お客様にとって最高のサービス体験を提供すること。豊島区限定でのスタートは、その目標に向けた最初の一歩なのです。
まとめ
顧客のニーズがあるか分からない、現場の肌感としてはこんなアプリがあったらいい、リリースしてみないと分からない！など、ステークホルダー感でさまざまの思いはありましたが、さまざまなエコシステムに乗っかることで開発スピードも運用コストも下げつつ、改善を続けられる体制になったのかなと思います。
今後もユーザーからのフィードバックを基に、機能の改善とアップデートを続けていく予定です。私たちのアプリが、より多くの人々の生活を豊かにする一助となれば幸いです。（まずは豊島区）
なにより、ものづくりは楽しい！！！
最後にイベント告知
AWSのイベントにも登壇します🤗
すでに募集は終了してますので、後日記事にして公開いたします🙇
それではまた👋
2024/03/09追記 イベント無事終了
無事イベントが終了しました。
登壇に使った資料は以下です。
当日の登壇の様子は以下🙇