この記事でわかること

• 自社の業界・業務への理解を、新しい商品の機能に生かす考え方
• 誰に売るか、選ばれる理由、価格と提供範囲の決め方
• 購入・継続利用の条件を確かめ、開発会社と商品を形にする進め方

「自社が詳しいこの業界で、役立つアプリやWebサービスをつくれないだろうか」 長年の事業で蓄積した専門知識は、新しい商品を考える材料になります。 現場で起きる問題、判断に必要な条件、仕事を進める手順。 その知識を組み込み、顧客が日々の業務で使える仕組みとして提供する方法があります。

たとえば、設備保守の知識を点検・報告サービスに、研修のノウハウを学習・実践支援アプリにする。 自社が人の手で提供してきた支援の一部を、複数の顧客が繰り返し使える商品にする発想です。 利用する価値を認めてもらい、料金を払って使ってもらうことで、新たな売上をつくることを目指します。

業界の困りごとと解決方法を、顧客が繰り返し使える商品にすることが、専門性を生かす一つの形です。 この記事では、自社の専門知識をアプリ・Webサービスに組み込み、商品開発につなげる順番を紹介します。 Webサービスは、ここではブラウザー上で入力や計算、記録の管理などができる仕組みを指します。

1. 自社の専門性を、新しい商品の材料として考える

出発点になるのは、長年関わってきた業界で、自社がどんな問題と解決方法を理解しているかです。 普段の仕事では、わざわざ言葉にしていない判断もあるかもしれません。 まずは、顧客を支援するときに確認していることや、経験をもとに助言している内容を振り返ってみましょう。

• 現場で起きやすい問題と、その原因
• 判断するときに必要な条件や、例外の扱い
• 仕事を進める順番と、つまずきやすい箇所
• 既存のツールでは対応しにくい、業界特有の事情

たとえば生産計画を支援する仕事なら、設備の稼働時間だけでは予定を組めない場面があります。 製品を切り替える準備に時間がかかったり、特定の作業ができる人員が限られていたりするためです。 そうした事情を知っているからこそ、実際の仕事に合う計画を提案できるんですよね。

この知識を商品に組み込むなら、準備時間や人員を入力する欄を設け、計画の計算に反映する案が考えられます。 予定どおり進められない場合は、その原因となる条件を結果に表示する形です。 現場を理解していることが、入力項目や計算方法、結果の示し方につながります。

最初に書き出したいのは、「どんな顧客の、どの仕事に、自社の知識が役立っているか」です。 その支援を何度も必要とする顧客がいるか、似た困りごとを持つ会社がほかにもあるかを考えてみてください。 そこから、複数の顧客に提供する商品の候補を探していきます。

2. 専門知識を、顧客が使う商品の形にする

商品の案は、顧客がその仕組みを使って、どの仕事を進められるかまで描いてみましょう。 知識を閲覧することに加えて、計画を立てたり、記録から対応を判断したりできる形を考えます。 以下は、商品としての姿を説明するための架空の企画例です。 実在の導入事例や成果を示すものではありません。

点検・報告サービスなら、保守事業者の担当者が設備の種類を選び、必要な項目に沿って点検結果を記録します。 記録に応じて追加の確認事項を示し、顧客へ提出する報告書まで整理できる商品を考えます。 専門家の確認が必要なケースは、確認待ちとして扱う流れも含めたいですね。

生産計画のシミュレーションは、条件を変えたときの計画を試算することです。 段取り替え、つまり製品を切り替えるための準備も含めて、設備や人員の使い方を比べる形が考えられます。 工場の担当者が複数の案を試し、採用する計画を検討できることが、商品の利用価値です。

研修会社なら、講師が受講者の理解に合わせて課題を出し、実践を振り返ってきた経験を生かせそうです。 確認問題への回答から課題を提案し、職場で試した内容を記録して振り返れるアプリを考えます。 研修を受けた後も、顧客企業が社員の学習と実践に繰り返し使える商品になりますね。

個別支援で培った方法のうち、複数の顧客に共通して使える部分を選ぶことがポイントです。 そのうえで、人による支援を残す部分も決めていきましょう。

3. 誰に売り、何を理由に選んでもらうかを決める

商品を具体化するには、対象顧客が今どんな方法で仕事をしているかを知る必要があります。 Excel、汎用の業務ツール、外部への委託など、比較する相手はすでにあるはずです。 その方法から切り替えてもらう理由を考えましょう。

たとえば点検記録を保存するだけなら、今のExcelで足りると感じる顧客もいるかもしれません。 一方、対象設備に合う確認項目が最初から用意され、現場で使う報告書まで作れるとしたらどうでしょうか。 毎回項目や書式を整えている会社にとっては、導入を検討する理由になりそうです。

ここで「設備保守会社ならどこでも」と広げず、扱う設備や会社の規模、困っている作業を絞ってみてください。 たとえば、特定の設備を扱い、複数の担当者の報告内容を責任者が毎回確認している会社を想定します。 その会社で、確認漏れや書き直しを減らせるかを確かめるわけです。

使う担当者と、購入を決める責任者では、重視することも違います。 担当者には、現場で入力しやすいか、いつもの手順に合うかを聞いてみましょう。 責任者には、報告内容の確認に役立つか、導入や教育にかかる手間も含めて費用に見合うかを確かめます。

自社の専門知識が、今の方法のどの不便を改善するのかを説明できると、選ばれる理由が具体的になります。 顧客が現在の方法で十分だと感じている場合は、対象や解決する課題を見直す材料にしてください。

4. 価格と提供範囲を、商品として設計する

料金を考えるときは、顧客がどの単位で使い、何に価値を感じるかを整理します。 利用者数、拠点数、処理件数など、商品の使われ方に合わせて検討しましょう。

点検・報告サービスなら、担当者ごとの料金や、事業所単位の料金が候補です。 研修アプリでは受講者数、生産計画サービスでは利用する工場数なども考えられます。 ただし、件数に応じた料金で顧客が予算を読みづらくなるなら、一定件数を含む形にする余地がありますね。

価格と一緒に決めたいのが、料金に含める支援の範囲です。 初期設定やデータの移し替えを手伝うか、操作説明を行うか、専門家への相談を組み合わせるかを整理します。 専門的な相談を含める場合は、回数や対応内容まで決めておくと、提供に必要な手間を見積もりやすくなります。

顧客ごとに変えたい部分を、どう扱うかも決めておきましょう。 たとえば報告書の社名や点検項目は、管理画面の設定で変えられる形が考えられますね。 会社ごとにプログラムを作り直す要望は、標準の料金に含めるか、個別対応にするかを分けて考えましょう。

提供後には、知識や基準の更新、問い合わせへの回答、システムを動かす費用もかかります。 顧客一社あたりの設定や支援に必要な時間を見積もり、想定する販売数で続けられるかを確認してください。 料金の収入と、提供・運営にかかる費用を並べることが、商品としての計画になります。

5. 最初の商品を絞り、購入する理由を確かめる

最初に試す商品は、対象顧客と業務を絞ると、購入する理由を確かめやすくなります。 点検・報告サービスなら、特定の設備を扱う保守会社向けに、点検の記録から報告書の作成までを試す形です。 日々の一つの仕事が終わる範囲を選んでみましょう。

画面案や試作品を見てもらうときは、最近行った実際の仕事に当てはめてもらいます。 入力する情報を用意できるか、作成される報告書をそのまま使えるかなど、具体的な確認ができますね。 あわせて、商品として購入・利用を続ける条件も聞いてください。

• 実際の仕事で使えるか。足りない情報や手順はないか
• 現在の方法から切り替える手間をかけても、導入する価値があるか
• 提示した料金と支援内容で、導入を検討するか
• 社内で導入を決めるために、誰の確認やどんな資料が必要か

「便利そう」という感想が出たら、どの業務で使うか、誰が導入を判断するかまで話を進めてみましょう。 料金への反応も、実際に費用を負担する立場の人に確かめたいところです。

試験導入では、次の点検や次の計画作成でも使われるかを見ていきます。 一度試して終わった場合は、使う機会がなかったのか、元の方法に戻ったのかを聞いてください。 実際の利用と、担当者の支援にかかった時間を合わせて確認すると、見直す点がわかりやすくなります。

画面案への好意的な反応だけで、売れると決まるわけではありません。 購入判断に必要な条件を一つずつ確かめながら、最初に開発する範囲を調整していきましょう。

6. 業界・業務の知識と、開発の専門性を合わせて形にする

自社が持つ業界の知識と、開発会社が持つシステムづくりの知識を合わせて、商品を具体化していきます。 自社からは、想定する顧客、困っていること、普段どのように解決しているかを伝えます。 開発会社とは、その判断や手順をどんな画面や処理にするか、最初にどこまで作るかを整理しましょう。

点検サービスなら、異常な記録があったときに何を確認し、どこから人の判断が必要かを説明します。 その内容をもとに、追加の入力欄や確認待ちの表示、責任者に知らせる機能などを検討できます。 判断基準が変わったとき、誰が内容を確認し、どう更新するかも相談したいところです。

複数の顧客が使う商品では、利用者向けの機能と一緒に、運営するための仕組みも考えます。 たとえば、次のような検討が必要です。

相談の際は、普段使っているチェック表やExcel、報告書などが、専門知識を説明する資料になります。 典型的な仕事の流れと、判断に迷う例外を一緒に示すと、開発会社も機能を考えやすいですね。 資料を共有するときは、顧客名や個別の取引情報を伏せて用意しましょう。

ミライスタートでは、課題や要望の聞き取りから、必要な機能をまとめる要件整理、設計・開発まで相談できます。 仕様が固まりきっていない段階の相談も、システム開発の案内( https://www.miraistart.com/si )で紹介しています。 機能をすべて決めてから相談しようとせず、顧客の課題と商品の案をもとに、開発の進め方を検討していきましょう。

おわりに

まずは、自社が詳しい業界で、顧客が繰り返し困っている仕事を一つ挙げてみてください。 その仕事をどう解決してきたか、同じ方法を使いたい会社がほかにもありそうかを考えることから始められます。 想定する顧客と解決したい課題が見えてくると、商品に組み込む専門知識の話も具体的になりますね。