金属加工業向け図面管理SaaS「図面コネクト」を1ヶ月で開発した話
アプリボットDX事業部の嶋です。
DX事業部としては建設、製造業のDXに携わってきており、
「ゲーム開発で培ってきた要件定義力とサービス開発力」
で価値を生み出せる領域を見つけて取り組んできています。
今回は昨年開発した図面コネクトの概要と、開発完了までの経緯について書こうと思います。
金属加工業様向け図面管理SaaS「図面コネクト」
DX事業部では昨年、金属加工業様における見積もり図面の保存・検索サービスの図面コネクトを開発しました。
このサービスは、
・過去に自社で扱った図面(PDF,dxf等)と案件情報をセットで保存できる
・見やすいUIで簡単検索、類似の案件であれば過去事例からすぐに回答可能
になる図面管理サービスです。
30社ほど金属加工業の会社様をヒアリングさせていただいた際、
「見積もりの回答業務が非常に大変」という話を数多くの方から伺いました。過去見積もりで類似の案件があった気がするけど、探し出せなくて改めて見積もりをしているとの話を伺い、
・図面と案件情報をシステム上で適切に保存する
・適切に探し当てる
ことを、我々のクラウドサービス開発経験をもとに実現できないかと着想しました。
画面は
・一覧/検索画面
・案件詳細画面
のシンプルでわかりやすい構成にしています。
PDFと案件情報は別々に保存されていることが多いですが、管理番号をそれぞれから抽出し紐づけるアプローチをとっています。
金属加工業者様への30社ヒアリングし開発に至るまで
あなたが金属加工会社の社長です。
1日の業務を終え疲れて自分の席に着くと、図面の束が積まれています。
この図面を1枚ずつ、内容を確認しながら見積もり金額を算定して見積もり依頼者に返答する必要があります。
金額を決めるには加工方法や材料の金額を踏まえる必要があり、専門性の高い業務です。ゆえに社長自身が見積もりをする必要があるケースが多くあります。
他の社員に分担できれば理想ですが、基本紙で対応しているため過去の見積もりを探して参考にするなども難しい状況です。
直接金属加工業者様の工場に伺い、お話を聞く中でこの課題感を知るにいたりました。既存のシステムで図面を管理できるようなサービスもあるのですが、
・PCにインストール前提のソフトウェアで、初期費用も高い
・現状PDFと案件情報が紐づけられていないので、そのままは使えない
とのことでした。
これらを踏まえ、クラウドを用いてサービス開発してきた経験を踏まえ、
・クラウドサービスとして構築し、初期費用が低いサブスクSaaSとして開発
・現状のPDFと案件情報をいただいて紐付け方法を科学し、結合してSaaS上でご提供
というアプローチでSaaS開発することにしました。
実際の業務フローに沿ったプロダクトにするため、各業務内容とフローについて詳細に因数分解し、開発要件に落としました。
わずか1ヶ月でのプロダクト実装。小さく作って素早く出す
我々DX事業部のアプローチに特筆することがあったとすれば、この図面コネクトを1ヶ月で実装、リリースしたことだと思います。
メンバー構成は下記で、6月に実装着手して7月の初頭には実際の会社様のデータを投入、ご提供していました。
・プロダクトオーナー1名
・開発ディレクター1名(私)
・フロントエンド1名
・バックエンド2名
・デザイナー1名
開発機能を50%削減。「その機能のユースケースは？言えないなら開発対象外で。」
サイバーエージェントグループとして開発力・開発速度が高いのはもちろんありますが、開発速度に一番効いたのは、
「コア機能以外、徹底的に削除する」
姿勢です。
初期に出てきた要件に対して、ユーザーのユースケースを徹底的に問い但し、今回届けたい体験に直結しない機能は全て対象外にしていきました。
今回でいえば、
・ユーザー画面、検索機能はきちんと実装する
・データの結合、投入する機能は全て落とす。全て手動対応する
判断をしました。
データ操作関連の機能は実装工数が膨れがちになる上、最初に届けたいユーザー体験に直接的に影響しません。
また実際に使ってみた上で、データの運用フローが業務の実態に合わなかったり、検索機能等そもそもの課題が発覚して全て無駄になる可能性もあります。
これらを鑑み、データ操作機能・画面は全て対象外にすることとしました。
とはいえ1ヶ月で完成させるためには数々の技術判断や進め方の調整は行いましたが、6月開発7月リリースを無事完遂することができました。
小さく素早く開発してリリースし、ユーザーの声を聞く重要性
特にDXのプロダクト開発において、
「課題だと思ってこだわって作った機能が、実は全然いらなかった」
「サービス提供後思ってもみなかった課題感で、作り直しになる」
ことが非常に多いです。
なので、小さく素早く開発してリリースし、ユーザーの声を聞くことが何より大事だと思っています。
この考え方は、ALL for SaaSでの開発の進め方に一部乗っ取っています。
巷のプロダクト開発で開発が長期化・高コスト化する大抵のパターンは、
・届けたいユーザー体験を語らず、個別の機能を語る -> やりたかったことがぼやけ、機能を増やす圧力が強くなる
・あった方が良さそうな機能は全部入れる -> 足りなかったらどうしよう、の恐れ
によって、開発が肥大化している印象があります。
これを回避するには、
・最初に満たすべきユーザーのユースケースをきちんとヒアリング、要件定義をする
・そのユースケースを満たす最小機能で開発、リリースしてユーザーに触ってもらう
ことが重要だと考えています。
この記事が気に入ったらサポートをしてみませんか？