長く売れる製品を考える為の観点

はじめに

本稿では標準的な差別化戦略の話はせず、いかに長く売れる製品を考えられるかについてのみ記載しました。この方法を記載した理由は、難易度が最も高い方法であるが故に一番楽しいと思われるからです。

前職ですが、約９年程のプロダクトオーナーの経験から得た観点を共有する事で、長く売れる製品を考える楽しさを共有できたら幸いです。

長く売れる製品とは？

端的に表現するとそれは「良い製品」と言う事ですが、さすがに曖昧過ぎるので、もう少し明確化をすると「他の製品と比べて格段に良い製品」であると言えます。

長く売れる製品を考える為の観点

「他の製品」と言うのは、市場における「普通」である事を意味し、これを否定する事で「長く売れる製品」の示唆を得る事ができると考えられます。

聞けば簡単な事と感じられるかもしれませんが、日々の中でそれをする事は容易ではありません。手間を惜しまず、地道に頑張り、現状に不満を言わない謙虚さは、日本人にとって美徳だからです。

「普通」を否定した製品例

Googleの検索エンジンが登場する前、情報を探す人は図書館の本のように分類されたHPの中から、地道に、手間を掛かけて探していました。しかし、Googleが出した検索エンジンでは、圧倒的に速く、簡単に情報を得る事ができるようになり、今でも検索エンジンのデファクトで在り続けています。この例では、「情報は分類された中から探す」と言う「普通」を否定する事に成功したのです。

その他にも、Salesforce.comが提示したアプリケーションを所有しないSaaSモデルや、AWSが確立したインフラを所有しないIaaSと言うのも分かりやすい、否定の例です。それまで所有する事が「普通」だった事を否定し、実現する事で新たな分野を築きました。

「普通」を否定する実践例

次は勤怠システムの「普通」を掘り下げて、それを否定する例を記載します。

「良くあるシナリオ」を記載します

「ある社員が朝会社に行くと、PC打刻で打刻を行い、勤務を開始します。夕方、残業をする事になり、上長に口頭で確認を行い、残業をします。勤務が終了すると再度打刻を行い、帰宅をします。
翌日、勤務開始後に前日の勤怠の確定を行い、上長はそれを受け取り、承認を行います。休憩時間が長い場合など、何か確認したい点がある場合などは後ほど声をかけ、確認をします。
月末近くになり、今月は残業をしすぎた事により36協定時間を超えてしまう為、超過申請を行い、上長の承認を得て、残業を行います。
翌月初めに前月の勤怠を確定し、上長はそれを承認し、給与計算担当者に勤怠情報が渡されます。」

ややレガシー感が強いですが、なんの面白味もない「良くあるシナリオ」になっています。

「埋もれた行間」も追記します

「ある社員が朝会社に行くと、PC打刻で打刻システムで（社員番号とパスワードを使って）打刻を行い、勤務を開始します。夕方、残業をする事になり、上長に口頭で確認を行い、残業をします。勤務が終了すると（社員番号とパスワードを使って）再度打刻を行い、帰宅をします。
翌日、勤務開始後に（自らPCで勤怠システムのWEBページを開き、ログインをし、さらに勤務実績の画面を開き）前日の勤怠の確定を行い、上長は（メールで）それを受け取り、（自らのWEBページを開き、ログインをし、さらに勤務実績承認の画面を開き）承認を行います。休憩時間が長い場合など、何か確認したい点がある場合などは（自ら気づき）後ほど（口頭で）声をかけ、（忘れないうちに）確認をします。
月末近くになり、（自ら）今月は残業をしすぎた事により36協定時間を超えてしまう（に気づいた）為、（自ら）超過申請を行い、上長の承認を得て、残業を行います。
翌月初めに（自ら）前月の勤怠を確定し、上長はそれを（メールで通知を受けて）承認し、（システムがCSVで自動的に連携する事で）給与計算担当者に勤怠情報が渡されます。」

見づらいので割愛していますが、行間には多くの「普通」が埋もれています。

「前後にある文脈」も追記します

「（システム導入時に勤怠担当者が勤怠計算に関する設定を１つ１つ行いました。毎夜、社員の入退社に合わせ、アカウントの改廃がCSV連携により行われています。入社時に、ある社員は勤怠システムの使い方のマニュアルを読み、利用の仕方を学習します。）
ある社員が朝会社に行くと、PC打刻で（社員番号とパスワードを使って）打刻を行い、勤務を開始します。夕方、残業をする事になり、上長に口頭で確認を行い、残業をします。勤務が終了すると（社員番号とパスワードを使って）再度打刻を行い、帰宅をします。
翌日、勤務開始後に（自らPCで勤怠システムのWEBページを開き、ログインをし、さらに勤務実績の画面を開き）前日の勤怠の確定を行い、上長は（メールで）それを受け取り、（自らのWEBページを開き、ログインをし、さらに勤務実績承認の画面を開き）承認を行います。休憩時間が長い場合など、何か確認したい点がある場合などは（自ら気づき）後ほど（口頭で）声をかけ、（忘れないうちに）確認をします。
月末近くになり、（自ら）今月は残業をしすぎた事により36協定時間を超えてしまう（に気づいた）為、（自ら）超過申請を行い、上長の承認を得て、残業を行います。
翌月初めに（自ら）前月の勤怠を確定し、上長はそれを（メールで通知を受けて）承認し、（システムがCSVで自動的に連携する事で）給与計算担当者に勤怠情報が渡されます。
（連携後、給与担当者は給与計算システムにログインし、勤怠情報に基づき残業代や休日出勤手当などの計算を自ら行い、給与に反映し、振り込みを行います）」

こちらも見づらいので割愛していますが、実際にはここにはより多くの「普通」が隠されていると考えられます。

文中から「変えられる」部分を探します

「（システム導入時に勤怠担当者が勤怠計算に関する設定を１つ１つ行いました。毎夜、社員の入退社に合わせ、アカウントの改廃がCSV連携により行われています。入社時に、ある社員は勤怠システムの使い方のマニュアルを読み、利用の仕方を学習します。）
ある社員が朝会社に行くと、PC打刻で（社員番号とパスワードを使って）打刻を行い、勤務を開始します。夕方、残業をする事になり、上長に口頭で確認を行い、残業をします。勤務が終了すると（社員番号とパスワードを使って）再度打刻を行い、帰宅をします。
翌日、勤務開始後に（自らPCで勤怠システムのWEBページを開き、ログインをし、さらに勤務実績の画面を開き）前日の勤怠の確定を行い、上長は（メールで）それを受け取り、（自らのWEBページを開き、ログインをし、さらに勤務実績承認の画面を開き）承認を行います。休憩時間が長い場合など、何か確認したい点がある場合などは（自ら気づき）後ほど（口頭で）声をかけ、（忘れないうちに）確認をします。
月末近くになり、（自ら）今月は残業をしすぎた事により36協定時間を超えてしまう（に気づいた）為、（自ら）超過申請を行い、上長の承認を得て、残業を行います。
翌月初めに（自ら）前月の勤怠を確定し、上長はそれを（メールで通知を受けて）承認し、（システムがCSVで自動的に連携する事で）給与計算担当者に勤怠情報が渡されます。
（連携後、給与担当者は給与計算システムにログインし、勤怠情報に基づき残業代や休日出勤手当などの計算を自ら行い、給与に反映し、振り込みを行います）」

業務の主筋は変えずに、別の方法でも成立する部分を探します。これが「普通」である部分です。

文中の「普通」を否定します

・「システム導入時に勤怠担当者が勤怠計算に関する設定を１つ１つ行いました」

勤怠計算の設定は勤怠担当がやらなければならないのでしょうか？設定はBPOに依頼したりする事もできますし、勤怠の規定に関する内容から、または過去の実績と計算結果により機械学習させる事で自動的にさせる事が可能かもしれません。また、コミュニケーションツールの普及により、設定変更もボットによるナビゲーションで行われるようになるのは、そう遠くないように思われます。業務システムの設定は改善が後回しにされやすいですが、逆にそこには革新的に変えられる部分がまだ多く残っているかもしれません。

・「毎夜、社員の入退社に合わせ、アカウントの改廃がCSV連携により行われています。」

これは既に古いやり方で、APIでの連携や外部認証を利用するやり方がでてきています。社員情報を各システムへ伝播させる仕組みに課題は多く、アカウント管理の製品には伸びしろがありそうです。今後はクラウドベースで作られた仕組みに、オンプレ対応のエージェントを組み合わせの製品が増えていくのではないかと思われます。

・「入社時に、ある社員は勤怠システムの使い方のマニュアルを読み、利用の仕方を学習します」

これも既に前時代的になりつつあります。マニュアルを作成するのではなく、チュートリアルを埋め込んだり、項目にヘルプをつけたり、チャットボットでQAを提供するなど、様々な方法が出てきています。今後はSlackやTeamsなどの統合されたインターフェースからの操作が普通になりますが、そこでの利用方法のサジェストの仕方のデファクトがまだないので、そこに革新性を見出せるかもしれません。

・「ある社員が朝会社に行くと、PC打刻で（社員番号とパスワードを使って）打刻を行い、勤務を開始します。」

これもやや古い感じがしますが、まだ主流のやり方の一つです。今後はSlackやTeams、Lineなどの勤務開始連絡と勤怠の打刻は連携していく可能性が高く、カレンダーの連動なども考える事ができます。コミュニケーションツールやカレンダーとの連携の当たりでもある程度の革新性を見出せ事はできそうです。

・「夕方、残業をする事になり、上長に口頭で確認を行い、残業をします。」

これも既に古い感じがします。この程度の内容であれば、SlackやTeamsで十分だと思います。加えれば、そのやり取りを検知して、ボットが残業申請の提出をレコメンドをする位はできそうです。コミュニケーションツールを介したレコメンド機能にもある程度の革新性は見出せそうです。

・「勤務が終了すると（社員番号とパスワードを使って）再度打刻を行い、帰宅をします。」

ログインそのものの否定は上記に書いたので、パスワードにフォーカスをしてみます。パスワードの安全性は低すぎるので、ここも既に幾つかやり方が出てきていて、デバイス認証などは普及していく可能性が高いと考えられます。この領域はあまり詳しくないですが、能動的に認証をしないで済むようになって欲しいです。

・「翌日、勤務開始後に（自らPCで勤怠システムのWEBページを開き、ログインをし、さらに勤務実績の画面を開き）前日の勤怠の確定を行い、」

上述していますが、業務システムにログインするやり方は既に古く、また、社員が能動的に動かなければ進まない仕組みも前時代的です。前日の勤怠情報の確定のレコメンドが勤務開始時にコミュニケーションツール上にサマリとともに表示され、修正がなければ、そのまま提出する事ができるようになる位は既にできそうな範囲ですが、実現している会社が少ないので、ある程度の革新性は得られそうです。

・「上長は（メールで）それを受け取り、(自らのWEBページを開き、ログインをし、さらに勤務実績承認の画面を開き）承認を行います。」

こちらも同様で、上長のコミュニケーションツールに対応すべき内容としてサマリと供にレコメンドされ、承認もそこでできる位の革新性は予見可能です。

・「休憩時間が長い場合など、何か確認したい点がある場合などは（自ら気づき）後ほど（口頭で）声をかけ、（忘れないうちに）確認をします。」

この当たりも同様ですが、休憩時間が長いなどの通常の勤務とは異なる部分で確認をすべき部分を上長にレコメンドする位もできると思われます。勤怠の異常に関する部分も少なくともルールベースでの抽出は可能で、機械学習による休職者、退職者に見られる傾向などから予測を行い、警告を出す、と言う方向の革新性も考える事が容易です。

・「月末近くになり、（自ら）今月は残業をしすぎた事により36協定時間を超えてしまう（に気づいた）為、（自ら）超過申請を行い、上長の承認を得て、残業を行います。」

この部分は前述と同様の内容になるので割愛しますが、システムに対して利用者が能動的に何かをする時代はそろそろ終わりにしたいですね。

・「翌月初めに（自ら）前月の勤怠を確定し、上長はそれを（メールで通知を受けて）承認し、（システムがCSVで自動的に連携する事で）給与計算担当者に勤怠情報が渡されます。」

CSV連携のような連携に関しては、将来的にもっとファジーに連携の設定をできるようになる可能性を考えています。具体的にはシステム間のインターフェースのマッチングを自然言語によって行う方法です。不可能と感じる人は多いと思いますが、20年位先であれば可能な話だと思います。システム間でネゴシエーションする時代が来るのではないかと考えています。大分SFチックですね。

・「（連携後、給与担当者は給与計算システムにログインし、勤怠情報に基づき残業代や休日出勤手当などの計算を自ら行い、給与に反映し、振り込みを行います）」

こちらも観点は前述した内容と同様ですが、給与計算に関する様々なチェックや試算が自動的に行われ、その中で検出されたデータの不足や計算結果の異常値に関する検出程度はレコメンドされ、対応方法の決定だけするようになる位の革新性を見出す事は可能です。

「普通」を変えて見た例

「（システム導入時に就業規則と過去の勤怠データと計算結果を元に機械学習で勤怠計算に関する設定を自動的に行いました。毎夜、社員の入退社に合わせ、アカウントの改廃がAPI連携により行われています。システムの利用時に、ある社員は勤怠システムの使い方をチュートリアルやオンラインマニュアルで、利用の仕方を学習します。）
ある社員が朝会社に行くと、入室の記録から自動的に打刻を行い、勤務を開始します。夕方、残業をする事になり、上長にコミュニケーションツールで確認を行い、残業をします。勤務が終了すると退室の記録からで再度打刻を行い、帰宅をします。
翌日、勤務開始後にコミュニケーションツールに来た通知に対応する事で前日の勤怠の確定を行い、上長もコミュニケーションツールでそれを受け取り、その画面上で承認を行います。休憩時間が長い場合など、何か確認すべき点がある場合などはシステムが検出し、コミュニケーションツールに自動的に通知された後、必要な分のみコミュニケーションツールで声をかけ、即座に確認をします。
月末近くになり、システムが今月は残業をしすぎた事により36協定時間を超えてしまうアラートを出している為、コミュニケーションツール上で超過申請を行い、上長の承認を得て、残業を行います。
翌月初めにコミュニケーションツール上で前月の勤怠を確定し、上長はそれをコミュニケーションツールで受けて、承認し、システムがAPIで自動的に連携する事で給与計算担当者に勤怠情報が渡されます。
（連携後、給与担当者は給与計算システムからコミュニケーションツール上に計算実行の可否の通知を受け、勤怠情報に基づき残業代や休日出勤手当などの計算をそこから自動的に行い、給与に反映し、振り込みを行います）」

今回はコミュニケーションツールの登場が増えすぎた感はありますが、ご覧のように勤怠システムのほぼログインする事がない事がわかります。このように「否定」をし、「置き換える」事で、「普通」ではない「製品」の示唆を得る事ができました。

その他の「普通」の例

今回の例では記載する事ができなかった多くの「普通」がまだ多く存在しています。

何のデバイスで、どのOSで、どのようなブラウザで、UIは文字なのか、フォームなのか、表なのか、グラフなのか、入力はマウスか、キーボードか、ファイル連携なのか、APIなのか、AIで読み取るのか、「普通」として認識してしまっている事がまだまだ多くあり、ここからも示唆を得る事ができるかもしれません。

おわりに

このように「普通」を見つけ、それを「否定する」事で、「長く売れる製品」を考える観点を纏めてみました。

実際には、示唆を得た後に何に注力するかと言う意思決定をし、推進し、実現する必要があり、これこそが最も「難しい」事です。「普通」ではない程にそれは「難しい」ですが、しかし、これは非常に「楽しい難しさ」なので、是非チャレンジしてみて頂ければと考えています。