デザインの「デ」の字も知らなかった僕がCRM SaaSのPMになるまで

僕について

今年の7月、2年間お世話になったERPベンダーを退職し、hokan Inc.に参画した。
前職では日本を代表するナショナルクライアントのみをターゲットに、業務コンサルティングおよびセールスを実施し既存のプロダクトを億単位の金額で提案することを行っていた。年間で数億円の売上をあげ全社員のMVPに推薦されたものの、表彰を待たずに辞退しInsurTechスタートアップへ参画した。
hokanでは、プロダクトオーナーとしてCRM SaaSの機能要件定義・デザイン・テスト・リリースという一連のフローを、ユーザーヒアリングを実施しながら必要性や・優先度を考慮して実施している。
詳しくは、以下のリンクを参照いただきたい。

https://www.wantedly.com/companies/hokan_insurtech/post_articles/129774

勿論、分業・権限移譲が発達している大企業では業務がオーバーライドすることは稀であるため、メディアで流行りのデザインを見る程度で全くのド素人であったわけである。そんな僕が、プロダクトオーナーを３ヶ月で務めるに至ったプロセスを公開する。
そうすることで、急成長するVertical SaaS市場で共に知見を共有できる仲間を見つけ、結果として様々な業界をアップデートできたらハッピーであると考えている。

これまで何を行ってきたか

1.　SketchでTrelloのUI Trace

・コンポーネントの設計・1px単位での配置等の緻密さに嫌気が差した。
・強調したい要素の扱い、フォントサイズ、色彩の強弱、線による情報・区間の区切り等をよく観察した。
・sketchの直感的な操作感とTrelloの情報設計の奥深さを肌で感じた。「シンボル」という概念に感動。

2.　募集人の顧客対応業務を一元化する目玉新機能の要件定義

顧客対応業務フローの理解、コアユーザーへのヒアリングを実施。
ホワイトボードを利用し、業務理解に時間の大半を費やした。実は、（主にtoBにおいては）デザインの概念・専門知識を知っていることよりも業務理解が最も重要である。

3.　Epicに落とし込み、ユーザーの動作から必要な画面・機能を定義する

Product Sumarryを定義する具体策によりコンセプトは実現し、コンセプトにより課題は解決され、課題解決によってビジョンが実現するという構造を意識し、Epicとして落とし込む。
プロダクトにとってもっとも難しい実装とは、プロダクトのコアとなるユースケースを明確にすることであり、誰が、何のためにこのプロダクトを使うのか、というストーリーを定義することは不可欠。

上記内容に基づいてワイヤーフレームの作成・デザインを実施。
デザインツールとしてsketchが主流な中、フロントエンジニアの要望によりfigmaへ移行。shortcutsも未だ存在しない中で、親指が腱鞘炎になりながらも、誤操作から勝手にshortcutsを覚えるなどの不思議な事象にも支えられ、高速にプロダクトデザインを実施。