本セッションのアジェンダ
大竹健斗氏：僕はカスタマーサクセスという立場からなので、「CS起点で考えるPM業務とタスク依頼の必勝法！」ということでお伝えできればなと思っています。
簡単に自己紹介をさせてもらったあと、実際にPMをやっていた時期と事業フェーズをお伝えして、今回の主題である守備範囲の変遷、先ほどのおんちゃーん（恩田茜氏）と同じようなどういう変遷があったのか説明をさせてもらって、4つ目にCSというか僕ならではになるかなと思うんですが、PMのポイント（をお伝えします）。そして最後に困ったことと乗り越えたことをお伝えして、7分で締められればなと思っています。
大竹氏がPMをやっていた時期とフェーズ
まず簡単に自己紹介です。サイシードというAI系のテックベンチャーで、今はカスタマーサクセスの責任者をやっています。もともとはリクルートグループで営業をやっていたので、先ほどのおんちゃんさんとはまったく違う事業畑というか。営業畑からITというかプロダクト開発みたいなところに携わってきた人間という感じです。
PMをやっていた時期とフェーズですが、だいたい2年ぐらいごとに変遷してきている感じです。創業が2015年とか2016年とかなので、最初の1年は、本当に何もない状態からとにかくみんなでがんばっていたので役割とかロールみたいなものはなかったんですが、2017年ぐらいから徐々になんとなく役割のグニュグニュッとしたものが出てきて、営業兼PMというかたちでやっていました。
この時はもう事業創造フェーズという感じなので、営業でいう紙芝居営業と言われるような（ものをしていました）。まだ物がないような状態からだったので、マーケティングリサーチだったり、お客さんの話を聞きながらすぐにエンジニアにフィードバックして「何を開発する？」みたいなものを機能に落としていくみたいなことをやっていました。
マネタイズフェーズで「売れるようになってきたね」となってきてからは、そのあとの導入後の支援もしないといけないということで、CS兼PMというかたちで2年ぐらいやらせてもらっています。2年ぐらい前からは完全にカスタマーサクセスとして独立した部門を立ち上げたので、PMについては今は専門のチームが発足してやってくれている。
今日、実際に今PMをやっているメンバーというかマネージャーも参加しているので、「へー」と思ってくれたらいいなと思います。
守備範囲の変遷 営業兼PM時代
実際の守備範囲と変遷で先ほどの3つに分けて説明をしていくんですが、最初の事業創造フェーズは超シンプルな話で、「売る」と「作る」というファンクションしかない中でなんとかその間をつなぐという、ただそれだけ。
この大きさがすべてなんですが、PMの権力みたいなものはほとんどなくて。「売る」というというものと「作る」というファンクションをとにかくつなぐみたいな感じで、プロジェクトのマネジメントや後ほど出てくる、大げさにいうとピープルマネジメント、お尻叩きみたいなところ（をやっていました）。
あとは、開発の要望をまとめて、どういう項目をどういう順番でやっていくべきなのかとか（を決める）。あとは売る、作る以外のところも全部（担当）なので、契約書の雛形を作ったり、SLA（Service Level Agreement）やセキュリティシートを作ったり、テストシートを作成して「JIRA」でテスト業務をやったりとか、そんなことをやっていました。
守備範囲の変遷 CS兼PM時代
ようやく「ちょっと売れるようになってきたね」となってからはCSも立ち上がって、PMとQA、テスト業務が僕の業務カバー範囲になりました。PM業務としては、先ほどに引き続き、開発要望のまとめとかになってきます。
CSとしては、まずはハイタッチと言われる、お客さんを直接支援していくというようなものを中心にやりました。ここでテクニカルサポートやカスタマーサポートを立ち上げたり、顧客の要望をヒアリングしたり、画面遷移図を作成したりみたいなことをやっていました。
QAとしては引き続きですがテスト実行者。実行は（僕とは）別でやっていたんですけど、実行者を充てたり、あとはバグが起きたり不具合が起きたら緊急対応をする感じで業務カバー範囲が設定されていたかなという感じです。
守備範囲の変遷 CS専門時代
今はCSの専門なので急に仰々しくなるんですが、いわゆるパイプラインとしてマーケティングから始まって、IS（Inside Sales）、FS（Field Sales）、そして受注から納品までのフロント側のPM。あとはいわゆるカスタマーサクセス業務で、開発側にフィードバックする（こと）。（スライドを示して）設計、開発、品質保証みたいな、一連の流れの中のだいたい真ん中の大きい部分をカバーしているみたいな感じに変遷してきています。
CS観点があったからPMとして強みになったポイント
ここからは、CS観点があったからPMとして強みになったポイントです。先ほどの図の右側のところに書いたんですが、3つあるかなと思っていて。
1つはお客さんの声を直接聞くことができるところ。やはりユーザーの声を直接聞けるのは大きいなと思っていました。ただ聞けるだけというよりか、関係性ができているので、不満だけじゃなくて「サイシードさんに期待しているからもっとこういうのを叶えてよ」と。
「そしたらもっとお金払うから」「応援するから」みたいな。「それを使ってくれてもいいから」みたいなことで、関係性の中で顧客の声を聞けたのは大きいかなと思っています。
2つ目が、お客さんの声を鵜呑みにしないで開発に届けられると。これも非常に重要だと思っています。ただ聞けるだけ、伝書鳩みたいに開発に流すだけだとぜんぜん意味がないんですが、お客さんが言ったことに対して、ちゃんと咀嚼して「それってこういうことですよね？」というWHATの部分をかなり定義した状態で開発に届けられたので良かった。
3つ目が、シンプルにPM、CS、QAのところをカバーしているので、やはり速い。迅速な意思決定ができて、かつ僕は非エンジニアで（良くも悪くもビジネスライクなので、そういう）PMの方があまりこだわりすぎる（ような）ところが（僕には）ない。とにかく機能を網羅的に満たすということを心がけていたので、スピーディにできたかなと考えています。
あとはもう1つ、（先ほど）“ピープルマネジメント”と大げさに言ったんですが、最初に僕が入った頃とは開発側が2人しかいなかったので、とにかくこの2人に仕事をしてもらわないと何もできないという状態でした。
この2人ですが、非常に優秀なんですよね。N氏はテクノロジーに関する圧倒的な知識や実績があって、弊社はコロナワクチンのシステムとかも作っているんですが、大規模開発とかもできるようなPM力があったりします。
ですが一方で、（その方は）お客さんとの対応とか交渉、あるいは何かあったら謝罪する。あとは自分が「いらない」と決めたらもうやらないみたいな。そういうちょっと癖のある人でした。なので僕はとにかくお客さんが過剰にブチ切れてるという演出をして、「ここまで言ったんですけどこれ以上は無理なので、これ以上（のことをするん）だったら開発してもらって、無理ならお客さんに一緒に謝りに行きましょう」と言うと、「じゃあわかったよ」というふうにやってくれるみたいな。そういう演出をしたりして（開発を）やってもらっていたり。
逆にA氏のほうはかなり基礎研究に力を入れているというか興味がある人間で、ゼロから何かをやるとか1人で完璧にやりきるみたいな。完璧じゃないか。1人でやりきるような力はあるんですが、とにかく仕事、タスクというもの全般が嫌いなところがあったので、そういったところをなんとか攻略できるように、大喜利みたいにして「大喜利で僕が勝ったらこのタスクをやれよ」と、仕事にゲーム性を持たせてやるみたいな。かなりトリッキーなマネジメントをしながらやってもらっていました。
CS観点、お客さんとのマネジメント目線を社内でもやっていたのが僕ならではかなと思っています。
困ったことと乗り越えたこと
最後に困ったことと乗り越えたことです。正直、非エンジニアというか、IT領域がわからなかったので、開発の流れがよくわからないとか、ITや用語がわからないみたいなところはありました。これは本を読むとかググるだけじゃなくて、開発者会議にとにかくジーッと、ぜんぜんわからないけど参加し続けることをやっていました。
あとは、タスクの難易度とか納期がわからないということに関しては、逆にいうとビジネス視点がかなりあるので、WHATとHOWでいうとWHATの部分。（これを）弊社では“お気持ち”と呼ぶんですけが、お気持ちの部分をかなり意識して明確にやっていました。
最後のお客さんの声がぜんぜんわからないということに関しては、具体的なオペレーションまで再現して伝える。あとは画面遷移図というかなり細かいところまで落とし込んで、エンジニアのほうに持っていくことを意識して乗り越えていました。
こんな感じで以上になります。ご清聴ありがとうございました。
