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

## はじめに

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

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

## 長く売れる製品とは？

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

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

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

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

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

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で読み取る**のか、「**普通**」として認識してしまっている事がまだまだ多くあり、ここからも**示唆**を得る事ができるかもしれません。

## おわりに

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

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