企画職とは、
• サービス、プロジェクトの骨格を考える
• メンバーに対して御用聞きをしてサービス、プロジェクトを推 進する
がメインの業務です。
サービスづくりとは
ユーザーに最大限の恩恵を与えるサービス/プロダクトを創出すること
その結果、 会社に最大限の利益をもたらすこと
企画の役割
実際には
・ 企画(メイン業務通りの企画)
・ ビジネス開発的企画 (情報提供元や広告主等外部のパートナーとの交渉や契約業務を行う対外向け企画)
・ ディレクター的企画(エンジニア、制作と連携しながら開発の進捗 管理を行う対社内向け企画)
などがありますが、領域意識がで きてもよくないので、一括で「企画 」と呼びます。
案件がスムーズに進捗するプロジェクトとは・・・
・ プロジェクトの目的(ビジョン、ゴール)が明確
・ 目的に向けてやるべき道筋(プロセス)が明確
・ PJ内で、作業内容、役割分担が共有されてる
・ 事前の各所調整が抜け漏れなく行えている
・ イレギュラーケース発生時に即応できるチーム力
ものづくりの中心としてハブとなって,連絡を漏らさずつなぎましょう
企画: マーケ QA 制作 CP 経理 技術 PM SM CS 法務 営業
お見合いでボールを落とさないように
企画担当の心得
・承認者やプロジェクトメンバーをその気にさせる説明を。 → 背景、市場環境、競合、目的、サービス概要、わくわく感
・仕事の範囲は自分のタスクだけではない。 → プロジェクト全体目配り、マネージする。
・メンバー全員の話をよく聞く。 → 公平かつ正確な状況認識とジャッジを
・リスクのリストアップ+分析を忘れない。 → やるリスクも大事だが、やらないリスクも認識しよう
・誰も拾わないボールが落ちないように動き回る。 →ボールが落ちたら、真っ先に拾う。
・企画はコードを書けないから・・・→ 技術、制作がいないと何も生まれないことを肝に銘ずる。
・「No」と言わない。→ 「できない」ではなく,「どうやるか」「いつやるか」。
・悩んだら歩き出す。→ 3時間でできないことは、3日かけてもできない。ならば、歩みだす。
KGI、KPIとは
・KGI (Key Goal Indicator) →最終的に達成したい成果指標
どの山(標高○m)に登るか? 例:2年で利益2倍!
・KPI (Key Performance Indicator)
→KGIに辿りつくまでの業務遂行指標
どのルートでどのように登っていくか?
例:2011年末で100万DUB突破
PV→DUB変更の理由
• いままで (PV)
- 広告売上=PVが在庫になっていた
- サービス側は、とにかくPV増えればいい (=1人が超いっぱいPV稼いでもよし)
• これから (DUB)
- 1人がいっぱい見る< いっぱいの人が見る
- 一見さんが多い< リピーターが多い ⇒いっぱいの人がリピートしてくれるのが一番いい
KPI=DUB
• DUB = Daily Unique Browser (日次)
• 全てのデバイスをカバーしたBクッキーベースの
一日のユニークブラウザ数
デバイス、ブラウザが変わるごとにカウント
スマートデバイス上ではアプリは別カウント
• 評価指標としては直近7日間の平均値を用いる
• デイリーアクティブ率＝DUB/MUB
あるべき姿とは、ビジョン!
・ビジョン (こうなりたい!)
組織全体が今後目指すべき姿、方向性。組織全体の 共通の目的となり、構成員の気持ちを鼓舞するメッ セージ。
・ミッション (こうあるべき)
組織の存在する使命、理由、役割。誰にどんな価値を 提供するのかを定義したもの。
コンセプトって何?
「コンセプト=企画のへそ」 と言いましょう。
 「企画のへそ」は、
発想の中心を端的な言葉にしたもの。
• 全体を貫く骨格であり、活動すべての指針となる
• しかもどこか新しく、今までにない
• 何に取り掛かるか、どのような変化をもたらしたいか、手 がける仕事の意義が見える.
• 自分だけでなく,他者にとっても全体のイメージが共有でき、それぞれが何をすべきか見えてくる.
- 夢のある魅力的な仕事を想像できる言葉だったらなおさら
コンセプトづくり
1. 現状認識
いわゆるas is、内外両面から なるべく広く
2. 時代洞察
行動と意識の裏にある 深層心理を深く読む
3. 夢を加える
自分の考える夢(to be)を加え,1と2の新しい接点を探せ!
4. 言葉に表す
その発見,主張を内外に伝える言葉に変え、共感、確信、動機をも たらし,一気通貫で動く!
コンセプトづくりの要チェックポイント
★へそな部分以外の言葉はそぎ落とす
→覚えやすいように
★みんなで納得、腹落ち状態になる
→一人だけで決めない
★決まったら、何度もメッセージ発信していく
→つくっただけにならない
コンセプト提案書と企画書の違い
• コンセプト提案書(可能性)=主に目的や期待効果などから"ある取り組み"に対する可能性を示す青写真
• 企画書(実現性)=その取組みを具体化するために多角的な視点で実現性を示すためのドキュメント
• 定性的表現から定量的表現へ
企画書の要点
企画書の基本は5W2Hを1ページで
→とくに重要なのは、誰に、どんな、どのように
・WHERE、WHO どの市場、もしくは誰を対象にするのか
・WHEN いつ提供するのか
・WHAT どんなサービスを提供するのか
・HOW どのような形で提供するのか
・WHY、HOW MUCH なぜ実施する必要があるのか
(どのような方法で収益をあげるのか)
5W2Hを前提に サービス企画書は以下の要素から構成される.
0.サマリー
1.企画意図・目的
2.サービス概要
3.対象顧客(ターゲット)
4.期待効果
5.市場状況(マーケット)
6.競合状況
7.リスク
8.リスク回避策
9. プロモーション、誘導計画
10.効果測定方法、集計期間
11.プロジェクト予算
12.情報提供元など関連企業
13.セキュリティチェック
14.リソース計画
15.スケジュール
よくあるリスク
1)納期遅れ
2)公開遅延
3)品質が基準以下
4)予算オーバー
5)リソース不足
6)事故発生
7)個人情報漏洩
8)利害関係者とのトラブル
よくあるリスクへの対策案
1)ステークホルダーとの綿密なMTG、議事録作成
2)実現可能なスケジュール作成、見直し
3)品質基準書を作成、総合テスト実施
4)早めの見積もり取得、あいみつ
5)必要な人員リソースの早期確保
6)企画、スケジュールの見直し
7)セキュリティ上の問題点の確認、契約締結
8)契約書での作業内容・成果物の具体的明記
企画書づくりの要チェックポイント
★抜け漏れなく考えられているか?
→5W2H以外にも必要項目を網羅する
★他人に伝わるように書いてあるか?
→自分のためではなく、承認者、案件担当、ほかサービス担当者が読んで分かるように
★わくわくするか?
→これがリリースすると、世の中どうなっていくか?
外部仕様書とは
外部仕様とは、製品でいえば、 「設計図」と「製品模型」と「製品の取り扱い」についてまとめたものです。
つまり外部仕様とは、企画書でまとめた要件が
• 「どんなUI(見た目)で」
• 「どういったシステムや画面遷移(どう使われるか) を実現する」
• 「どのように運用していくか」 のかといった概要を設計したものになります。
外部仕様書に必要なものとは
省略
開発~リリース時に企画が動けること
・ テスト環境での動作チェックをいっしょにやる
→開発担当が気づけないところをWチェック
・ ほか部署との調整を事前にやる
→QA、CS、マーケ、広報など事前周知
→トラブルあった場合もすみやかに連絡
・ プロモーション仕込み依頼しておく
→プレスリリース、TOPリンク、横リンク、twitter投稿など
リリースまでの要チェックポイント
★情報共有はこまめに。対面でコミュニケーションする
→メール、メッセだけに頼らない
★任せるところは任せる
→任せる役割分担のラインは明確に
★神は細部に宿る
→どれだけ細かいところにこだわれるかがサービスの 価値を決める
よくある意見のぶつかり
・ デザインそのものが気にくわない
・ UIに要件の重要度が反映されてない、誤解釈されてい る
・ システムで表示できないUI設計
・ 更新運用しやすいカラム構成になっていない
・ 容量制限をオーバーしている
・ システムのパフォーマンスを定義してない、想定してない
→いずれの場合もまず意図をよく聞く
→伝えたことをみんな見えるようにドキュメントに残す
効果測定を踏まえた改善の考え方
• サービスはリリースしたら、案件終了ではありま せん
• プロダクトではなくサービスなので、育てていかないといけません。
• 1つの大規模開発も大事ですが、10個の小改善をずっと繰り返しし続けるのも大事です。
リリース後、企画時に想定した目標を達成してい るか、きちんと効果測定を実施、承認者やプロジェクトメンバーにレビューを行いましょう。
Checkの意味
• リリースまでの進行管理で、問題となった点や 今後の残課題などの洗い出し.
• その分析のもと、次はこうすればイケるはずと 仮説を立てる.
Actionの意味

• Checkの仮説に基づいて実際行動する • 仮説の精度が高いと、ギャップが埋まってくる
• こうやると成功する/失敗する,のノウハウが 溜まる
完了レビューは、当該サービスの成果報告だけに とどまらず、同様のプラットフォームやコンテンツ、 ビジネスモデル等を踏襲するサービスの参考データとなる、貴重な情報資産です。
そういう意味でも、ヤフー全社員へ情報共有されるよう、こころがけてください
評価の要チェックポイント

★何をもって成功か失敗か
→コンセプト、KGI/KPIと照らし合わせる
★振り返るのを習慣化する
→リリースしっぱなしはよくない
★ときにはサービス撤退の判断も
→リソースの選択と集中で
Comments