プロダクト思考とサービス思考
最近お手伝いしている所のサービスについて色々ディスカッションする機会が増えて、時折議論が噛み合わないなぁと感じることがあったり、別件で、違う会社の人の話を聞いてても、些細な所でちょっとした違和感を感じるケースがあったりしました。
なんでそういう違和感を感じるのかイマイチ掴めてなかったのですが、自分は、常にサービスという言葉を常に意識して言葉に出してるのに対して、相手の方はプロダクトという言葉をおそらく無意識に使ってるからなのかなとなんとなく感じました。
ここでいうサービスとプロダクトの言葉の意味合い
言葉の定義としては、自分の中ではこんな意味で考えてます。
プロダクト思考
- どういう機能がいいのかをまず考える
サービス思考
- 誰が使うものなかを考える
- アプリとかサービスを出したらおしまいではないのでその後どうやったら使い続けてもらうのかを考える
- 使い続けてもらうからには当然売上も立たないといけないし、そのサービスを維持するのにコストがかかりすぎるのもいけないのでそこも考える。
- プロダクトはサービスの中の要素であるので、プロダクト単体で技術的に難しいことがあっても、実際のオペレーションで対応したほうがコスト的に割に合うならそちらを優先することを意識
あと、ここでの話は小さい会社（ベンチャーとかスタートアップという言い方がされる領域かな？？）でのことを想定してます。他の状況だと少し捉え方がかわりそうな気がしたので一応この点についても触れておきました
自分は元はプロダクト思考だった
自分は元はプロダクト思考でした。プロダクト思考からサービス思考になったきっかけはたぶん2000年の電子年賀状システムを社内向けにリリースした頃だったと思います。ちょっと昔話をしながらもう少し掘り下げて書いていきます
当初は電子年賀状システムを「作る」という発想しかなかった
流石に15年近く前のことなので、当時の細かい背景は正確に覚えてないのですが、当時の上司（上昇志向がとても強い外国の方）が自分たちの所属していた部署のプレゼンス（存在意義的な意味合いで使っていた気がする）を高めたいという気持ち＋αから、何か社内向けにサービスを提供したいというのがあって、電子年賀状システムという構想を出してそれをやることになりました
話を聞いた時に、Windows＋WSH/ASP+VBScriptみたいな構成を得意としていた自分としては、BASP21というCOMコンポーネントを使いつつ、HTMLメール送信すればイケそうという考えがすぐに浮かび、作るということしか考えてませんでした。
作るのが必ずしも正解とは限らない
自分たちで機能面について考えて、それについて実際に利用しそうな人からフィードバックもらってという感じのアプローチをたぶんとった気がします。※あまりに昔のことなので当時こんなことを考えていたかどうか微妙ですが(^_^;)
フィードバックもらう中で、
みたいな意見が出て、自分の当時のスキルではBASP21でHTMLメールの送信は出来てもそれ以外の機能で、特にテンプレートを任意に選ぶというのが技術的に難しい印象を受けました。
ただ、当時の上司の頭のなかでは、作る前提では考えておらず、むしろ外部に使えそうなパッケージ製品があればそれを積極的に使って欲しいというスタンスでした。
自分としては作りたい気持ちがとても強かったので、正直おもしろくないという気持ちが全面に出てたのですが、しぶしぶ、外部のものを探したら、今回のやつにとてもフィットするのがあったのでそれを採用しました。（結果的にそれを選んで正解でした）
大事なのは「誰に」「どのように」使ってもらうのかを考えることが大事だと知った
当時いた会社は、まぁみなさん凄腕なエンジニアの方が多くいらっしゃるような環境だったし、営業やマーケティングの人たちも、会社自体がIT系だったからみなさんITリテラシーは高い方が多くいらしていました。
取引先に対して、本文に自分が選んだテンプレートで年賀状がメールで送られる、しかもFlashとかでもなく、ファイルが添付されるものでもないというのはみなさんすぐに理解してくれたとおもってます。
紙の場合には、決まった日までに書かないと届かないという問題があったけど、メールベースのものだったので、12月31日までに書けばOKだし、メール送信予約機能も当然あったので
- Aという顧客には元旦に届くように設定する
- Bという顧客は、年明けに会社で見るだろうから元旦ではない日付で設定
みたいなことも出来るような仕組みを整えていました
開発元の方（たしかカナダの方）の協力を得ながら、割りと細かい使い勝手まで気を配ったり、元旦に出社して、メールの不具合がないかどうかサポートもして、年明けしばらくしてから、部署を横断して社内の問題点について議論するような会議が定期的に開かれていたので、そこで結果報告＆フィードバックもらったのですが、そこそこの評価をいただきました。※同じくらい、来年度に向けての改善（連名機能ないのがおかしいとか）もガンガンもらった
こういうフィードバックもらってからは、「誰に」「どのように」使ってもらうのかを考えないとダメでプロダクト単体でモノゴトを捉えていた自分がいるなぁとなんとなく反省した気がします。
サービス思考に切り替わってからの変化
この電子年賀状と並行して、社内のユーザさんが利用していたノートPCを大量に環境移行しないといけなかったので、データ＆PC環境の一部をPC間で移行するVBScriptを自分たちで書いてました。
ツールの完成度はユーザさんには直接のメリットは無い
ベースとなるものを自分ともう1人の人とで「このRegistryKeyの値を読み出すとxxのアプリのプロファイル情報参照できそうだから移行時のパスとして使えるんじゃねー」みたいなことを話しながら一緒に書いてて、それをやっていた頃は、そのツール自体の出来というか完成度を高めることを強く意識しすぎていました。
ただそのツール自体の完成度というのはユーザさんにとっては別にどうでもよくって、「仕事に支障が出るから、なるべく短時間で環境移行が終わってほしい」というのが本来求められてる所でした。
電子年賀状に関わった後、ちょっとづつですが自分の中ではユーザさんにとってのメリットが何かをまず先に考えるようになりPC環境移行についてもどうやったらユーザさんがPC使えなくなるダウンタイムを減らせるのか？ ということをまず先に考えるようになったかなと思います。
サービスという視点で全体を捉えるようになった結果として
環境移行のオペレーション全体で最適化することでダウンタイム減らせるかもという仮説の元で
- ユーザさんが好きな日程で環境移行の日程を調整出来る
- そこの作業の日程調整はメールでやると互いに煩雑なので社内上にWebアプリを作った。
- このWebアプリはカレンダーっぽいUIをなんとか実現して空き日程＆時間帯がすぐにわかり、空き日程をクリックすれば予約受け付け終了＆確認メール送信されて、実際のオペレーションする人もいつ、誰のPCを設定すればいいのか別の画面から確認できて割りとイケてたモノだった気がする
- 日中に環境移行出来る人の枠は当然のことながら、忙しい人向けに夕方預かり→翌朝引き渡しの枠も設定
- PC環境移行の作業自体はほぼ自動化されていたので、最後PCを預かって、最低限の作業だけすると、夜間に、PC→PCへの環境移行が終わるように前述のスクリプトなどを組み合わせて実現していた。最悪環境移行が完了しなくてもPC自体はあるのでそこから足りないデータをコピーする手はずを整えていたのでそれで全然OKだった。
というようなことをやってました。
このオペレーションが確立されたことで、この環境移行のために適宜人員を増やして対応していたものが、通常の業務の1つとして組み込めるようになったことで、余力ができるので、費用対効果を意識しつつ、ユーザさんにとって利便性があるサービスがどんなものがありそうかを考えて・・ということが出来るような体制になっていきました。
残念ながらその後は、大掛かりな組織変更があったことでずっとこういうことが出来たわけではないのですが、
- ユーザさんにとってのメリットは何か？
- そのサービスを回すためのオペレーションをする人が無理なくこなせる仕組みがどのようなものか？
- 効率化や作業ミスなどを回避するために、積極的に技術的な所は活用するけど、その技術が何を解決するものかを忘れないようにする。
みたいな発想が2000年〜2002年頃の間に養えたのは、今振り返るととてもよかったなぁと思います。
まとめ
プロダクト思考とサービス思考のどっちが良い・悪いという決め付けをするつもりは全くありません。ただ何か議論してるような時に、話が噛み合わないなぁと思った時に、互いにどういうスタンスで話をしてるのかを明確にするだけでも、噛み合わない状態からちょっと先に進めるのかなと思ったので、まとめてみました
