企画職が行うサービス/プロダクト管理の実際とは？
■これからキャリア選択や就活を考える方
■起業やスタートアップに興味ある方
■人生を豊かにしていきたい方
「企画職が行うサービス/プロダクト管理の実際」について解説します!!
はじめまして。東工大発ITベンチャーGoMA(ゴーマ)株式会社で代表をしております「平賀良」と申します。よろしくお願いします。
今回は「企画職が行うサービス/プロダクト管理の実際」について、
ご紹介させていただきます。
あなたの時間を無駄に搾取するので失礼なので、
僕の考えを1000字以内でまとめます。
「短時間で学べる情報」を配信していく予定ですので、
良かったらフォロー/いいね！よろしくお願いします。
前回のこちらの記事で、
企画職に必要な三つのスキルの一つとして、
「サービス/プロダクトの管理」について共有させていただきました。
今回は、そちらの詳細な管理方法について、
僕自身の経験を踏まえて、お話させて下さい。
【①サービスローンチ前における管理方法】
管理方法に関しては、大きく二つあると思っていて、
「サービスローンチ前」と、「ローンチ後の運用フェーズ」に分岐します。
「サービスローンチ前」というと、
スタートアップや起業して事業を考える場合もあるかとは思いますが、
ここでは、企画職に必要なスキル面で考えていきたいので、
社内で新規事業を行う場合や、
クライアント企業から案件として実行する場合を想定していきます。
どちらの場合も、
要望/要求を出す「オーナー」が存在します。
オーナーは予算であったり、組織での実行権を握っている場合がほとんどのため、企画職はオーナーの意向に沿った形で、アウトプットの用意をする必要があります。
ここで、サービスのローンチを進めていくのですが、
注意するポイントが三点あります。
このポイントを抑えずに実行すると、炎上案件になります(笑)。
ポイントは以下の通りです。
1：タスクフォースについての理解
2：スケジュールの確認
3：工数/予算の管理
「タスクフォースについての理解」というのは、
「オーナーを探せ！」ということです。
先ほどさらりと、オーナーが存在するという話をしましたが、
企画職の最初の仕事は「オーナーが存在するのか？」疑うところから始まる場合が多いです。
「新規事業を行いたい！」といったのは誰なのか？
どの程度の熱量でそれを言っているのか？
発信者は予算を計上できる役職なのか？
といったところを調査し、現実的かどうかを判断する必要があります。
その上で、オーナーとなる対象者が存在し、
コンタクトを取れるようになれば、
その人へスケジュールや予算の話を進めていくという流れになります。
社内新規事業の場合は、役員会で予算と担当者が割り振られる場合が多く、
案件の場合は、発注者を含めた部署が、オーナーとなる場合が多いです。
次に、オーナーに対して、
「どれくらいのスケジュールで、どのようなアウトプットを希望しているのか？」ヒアリングする作業を行います。
ヒアリングから実行までの粒度がどれくらいかによって、
プロジェクトの勝敗が決まるのですが、
その責任を負うのが企画職になるのです。
ここが腕の見せ所といっても過言ではないくらい、
担当するPLによって成果が全く異なってきます。
IT業界でいうところの「要求分析」や「要求定義」と言ったりしますが、
「オーナーの意思をどれくらい尊重できるか？」が問われるのです。
サービスローンチを目的とする場合、
サービスの概要をここでフィックスする必要があります。
フィックスしたものに対して、希望しているスケジュールが問題なければ、
そのオーダー通りで進行していきます。
スケジュールが過密で、問題が発生する場合、
人員増強や断るといった判断をする必要が出てきます。
サービス概要とスケジュールが確定した場合、
次に工数について相談していきます。
ここで、オーナーと予算管理を実行している人間が別の場合、
面倒な問題が発生するので、事前にタスクフォースを理解しておく必要があるということです。
基本的には、オーナーが予算管理を行っているので、
工数を計算し、見積を用意し、必要があれば稟議を通す資料や説明を行って、見積を受理してもらいます。
「契約」といわれる作業が、ここに含まれるのです。
ここまでの流れをまとめると、以下のようになります。
1：「Aさん」こんなサービスをローンチしたい！
Bさん、お願いできませんか？
2：「Bさん(企画職)」オーナーはAさんですよね？
3：「Aさん」その通りです。
4：「Bさん」分かりました。作りたいサービスはこんな感じですか？
5：「Aさん」その通りです。
6：「Bさん」では、スケジュールはこんな感じですか？
7：「Aさん」はい。それで問題ないです。
8：「Bさん」では、Bさん。
これくらいお金かかるのですが用意できますか？
9：「Aさん」稟議を通したので用意できます。
10：「Bさん」では、この内容で契約して進めていきましょう。
11：「Aさん」さずがです！ありがとうございます。
ざっくりとした流れはこのようになりますが、
こんなに簡単に人間が動く訳はありません(笑)。
僕自身の経験では、
ここまでの手続きを組織単位で行うために、6カ月以上要しました。
何度も問題が発生し、修復を繰り返しながら形にしていくという地道な作業になります。
ここまでの流れをなんとかこなし、
オーナーの意向に沿った形で、無理のない契約を進められそうとなった場合、次にアウトプットの準備を進めるためのチームを形成する仕事が発生します。
オーナーとの関係性は保つことができた。
でも、「本当にサービスをローンチするためのアウトプットを用意できるのか？」を考慮していく必要があるのです。
もちろん、これはオーナーとのコミュニケーションの中で、
同時並行を前提としていますが、
サービスローンチを行うためのチームを形成していきます。
こちらの詳細に関しては、別の記事で投稿していきますが、
サービスローンチ時のチームは少数精鋭で、
お金のために働くサラリーではなく、
未来のために働いた経験を有するか、起業家マインドを持った人材でないと、正直きついと思います。
なぜかというと、
サービスローンチ前は、それが成功するか分からない状況が続き、
挑戦に近い仕事も多く含まれるため、
給料や労働時間ではなく、「ローンチすること」を一番に考えられる人材のみで、作業していかなければ難しいからです。
そして運よく、そういった人材を確保し、チーム形成を行うことができれば、オーナーの意向に沿ってサービスローンチが行え、
お金をいただくことができるということです。
これが、サービスローンチ前の全体図になります。
【②ローンチ後の運用フェーズにおける管理方法】
運用後のフェーズですが、
恐らくほとんどのサービスの場合、ローンチしたチームや企業が、
そのまま運用を行うケースが多いかと思います。
ここで問題なのは、
サービスをローンチするのに必要なチームのスキルと、
運用フェーズにおけるチームのスキルは異なるということです。
そのため、
同じチームが請け負う場合、チームメンバーの再編成や、
マインドの変更が必要になってきます。
これは、企画職の方も、
ローンチ前と後で、思考内容が異なるということを
しっかり認識しながら作業を行うべきということです。
では、「どのように異なるのか？」考えていきます。
ローンチ前では、
契約こそ行うものの、日々の作業内容やオーダーが頻繁に変更するため、
決まっている座標の数が少ないという特徴があります。
そのため、IT業界では「アジャイル形式」と呼ぶ場合がありますが、
PDCAを回しながら、ゴール設定を修正し、最終的なローンチに向けて、
個々人がチームをけん引していくという、スキルが必要になってきます。
しかし、
ローンチ後のフェーズでは、
ローンチする際に、ローンチ後の運用方法について、
ある程度取り決めを行うので、作業内容や運用ルールについて、
決定している項目が多いという特徴を有します。
そのため、ローンチ後にもとめられるスキルというのは、
決定しているルールを理解し、それに沿った作業を行い、
問題が発生しないようにするということです。
ですので、
ローンチ時には必要であった「起業家マインド」よりも、
決められた出来事を、決められた範囲で行う「作業者」の方が、
現場で求められる可能性が高くなります。
これは、運用期間が長ければ長くなるほど、
作業者よりの人材が増えてくるという特徴があります。
例えば、
paypayはサービスローンチ前は、
企画や開発を行う少数精鋭であったのに対し、
ローンチしてトラクションが大きく膨らんでくると、
カスタマーサポートとして問い合わせ対応を行う人材や、
障害が発生した場合に対応する人材、
導入を進める営業人材の分母が増えていきます。
このような、「作業者」の数が増え続けているサービスは、
ローンチ後の運用フェーズの成功事例と言えます。
彼らは、決められた業務範囲で採用され、
決められた業務を、決められた評価軸に沿って行うほど、
評価される制度の中にいます。
それができるのは、運用ルールを作ることに努力したからです。
そして、ここでも重要になってくるのは、
「ローンチ前後で、この運用ルールを企画職を含めたチームがどれくらい努力して作れるか？」ということです。
では、「どのようにルールを構築していくのか？」
事例とともに共有していきます。
サービスをローンチする際に、
必ず運用のことを考える必要があります。
例えば、オーナーの意向に対して、
ローンチ後に改修した方が良い事項を列挙し、
優先順位をつけて、タスクにまとめます。
それを、ローンチ日以降のスケジュールに組み込み、
適切な人材へタスクとして共有します。
これは、おそらく企画職やPLが行うことが多いかと思います。
弊社では、運用フェーズにおける管理方法として、
BacklogやNotionをツールとして活用しています。
これらをもとに、
優先順位がどれくらいのチケットを、誰がどこまで進捗を出していて、
いつまでに完了させる必要があるのか？チケットベースで管理しています。
このような方法によって、
サービス改修の運用を行うことができるようになります。
これらは、チケットという明確な作業内容が定義されているため、
工数管理が非常にしやすいです。
そのため、採用のハードルも下がり、
より多くの人材を募集して、安定稼働に向けた取り組みを行うことができます。
また、
お客様からの問い合わせ件数が増えるというような、
運用フェーズで問題が発生した場合には、
CSチームを形成する、運用マニュアルを見直す、新しいルールを追加するというような対応を行い、第三者に引き継ぐことを前提とした解決方法を、
検討していくスキルが必要になってきます。
このような方法で、
サービスの安定稼働ができるようになることが、
運用フェーズにおける管理方法と言えます。
最後まで読んでいただきありがとうございます。
良かったらこちらの記事も参考にしてみて下さい。
【会社概要】
社名：GoMA株式会社
称号：東京工業大学発ベンチャー(授与番号110号)
所在地：東京都港区芝浦3-3-6
東京工業大学田町キャンパス 4F
代表者：代表取締役 平賀良
設立：2019年12月9日
事業内容：
・デジタルコンサルティング事業
・B to B to C向けWebアプリケーションパッケージの開発
起業したい若者の挑戦のために使わせていただきます！ よろしくお願いします。