運用を支える内製システム開発の優先度をどう考えるか — モビリティシェアリングサービスにおける実践例
社内システムの優先度をどう考えるか — Luupにおける実践例
こちらの記事は、LUUP のTVCM放映に合わせた一足早い「Luup Developers Advent Calendar 2024」の17日目の記事です。
はじめに
本記事では、システムの優先度付けの考え方や判断基準について、実例とともにご紹介します。
Luupでは、日々のバッテリー交換や車両の修理を支えるフィールドオペレーション部、ハードウェア部、カスタマーサポート部など、多岐にわたる部署から寄せられる開発要望に対して、限られたリソースで対応していく必要があります。
そのため、私たちが特に大切にしている優先度決定の方法や評価基準について解説します。社内で新しいシステム要望が提案される際、その要望をどのように評価し、実際の開発につなげていくかの手法として、ぜひ参考にしてください。
優先度決定のために重要な考え方
-
欲しい機能ではなく解決したい課題の共有
解決したい課題をシステムの開発チームと共有し、根本的な問題を明確にすることが大切です。単なる機能のリクエストではなく、課題の背景や業務の流れを共有することで、より効果的な解決策を導きやすくなります。 -
顕在化している課題だけを解決対象とする
システム開発のリソースを最適に配分するため、解決すべき課題はすでに認識されており、具体的な損失や影響が発生しているものに限ります。特に重要なのは、その課題に対してすでに何らかの具体的な行動が取られている、つまり課題が顕在化していることです。例えば、オペレーション上の障害が発生していて、作業時間を割いて手動でその作業が行われている、現場レベルでスプレッドシートなどのノーコードツールで運用がされているなど、既に対処が進行中で、手動対応が増加しているなどの具体的な兆候がある課題にこそ、システムによる解決を導入すべきです。 -
一度に一つの課題を解決する
同時に複数の問題を解決しようとすると、開発が複雑化し、コストやリスクが高まります。課題解決は1つの課題に集中し、それ以外の要求は極力削ぎ落とす方針が効果的です。
システム開発で解決すべき課題の基準
次のような場合、システム開発による解決が推奨されます。
-
既存のオペレーションのスケールアップ
現在行っているオペレーションが拡大のための対応が必要な場合。 -
損失が定量的に評価可能な課題
課題による損失が具体的な数値で示せるものは、開発効果が測定しやすく、優先度が高くなります。
開発リソースを投下することを慎重に検討するケース
一方で、次のような課題は開発リソースを投入することを慎重に検討する必要があります。
-
未明確なニーズ
「こんなことができたらよいな」というような、曖昧なリクエストでは効果的なシステム設計が難しく、課題解決に結びつかない可能性が高いです。 -
本質的な課題を解明する前にシステム化を検討している
システム開発は業務の効率化や課題解決を支える重要な手段ですが、あくまで組織間の連携や業務フローを改善するサポート役であるべきです。例えば、営業やカスタマーサポートの間で情報共有のすれ違いが発生した際、システムを利用して解決することも有効ですが、システムを介してのみ対応しようとすると、解決に必要な根本的なコミュニケーションやフロー改善が後回しになるリスクもあります。そのため、システム開発においては、システムが解決すべき課題が明確かつ本質的であることを重視し、業務フローや部門間の協力体制を補完する役割としてシステムを活用することが重要です。
内製化の基準
次のような基準でシステムの内製化を判断しています。
-
独自性が求められる領域
自社の強みとして活用すべきオペレーション(例:車両のバッテリー交換など)に関するシステムは内製化し、業務にフィットした設計を重視します。 -
外部プロダクトで十分な領域
業務の標準化が進んでいる分野(例:経費精算など)については、外部のSaaSプロダクトを活用し、コストと効率のバランスを取ります。
コストパフォーマンスを意識した開発
最小限の労力で最大の効果を得るためには、開発コストと効果のバランスが重要です。次のような要素を考慮しながら優先度を決定します。
-
シンプルなデータ管理
既にデータが正規化され、簡単に操作できるようなケースでは、低コストで開発が可能です。 -
例外的なフローが少ない作業
例外の多いオペレーションや頻繁に変わる業務フローは、開発が高コストになりがちなので、これまでどおり手動で対応していくのも選択肢の1つです。
最後に
課題の優先度を正確に見極め、効率的なシステム開発をするためには、何が本当に必要で、どこまでを今解決するべきかを判断する力が重要です。本記事で紹介した考え方が、エンジニアやプロダクトマネージャーの皆さんの開発や意思決定のヒントとなれば幸いです。
Discussion