Chapter 15無料公開

┣ 基本的なプロジェクトの進行フロー

Yoshio Kakehashi
Yoshio Kakehashi
2021.12.08に更新

広告・クリエイティブ系の仕事のフローはおおまかに以下のようになる。

  1. 引き合い、あるいは自社プロジェクトの出発点
  2. 企画
  3. 技術選定・検証、工数見積もり、外部パートナー探し
  4. プロトタイプ・モック制作
  5. プレゼン
  6. 計画・スケジュール
  7. 実装、テスト
  8. クライアント確認
  9. リリース
  10. 運用

この順番はあくまで参考で、実際は技術検証とプロトタイプが一緒になったり、企画時にモックを作ることもある。プレゼン前、プレゼン後の実装、リリースといったところが大きなフェーズと言える。

それぞれのフェーズで求められるクオリティやスピードは違う。

ここではざっくりとした概要と、プロジェクトに対する姿勢を説明する。

1. 引き合い、あるいは自社プロジェクトの出発点

引き合いの場合

  • 代理店やクライアントなどから「こういう案件があるんですが」「こういうことをしようとしてるんですが」と来る
    • 「一緒に企画から入ってください」というパターン
    • 「こういう企画があるので、この部分を担当してください」というパターン
    • などといくらかのパターンがある
  • 「おもしろいプロトタイプを作りました!」と発表すると引き合いがくることもある

自社プロジェクトの場合

なんらかの理由で発生する

2. 企画

  • みんなで頭をひねりつつも、クリエイティブディレクターがバシッと決めることが多い
    • 難しすぎる案件だとモックを作って捨てまくってゴールにたどり着くことも
  • 小さい案件ならエンジニアが主になって考えることもある
  • 企画意図を知り尽くすことも必要
    • 企画意図を汲んでいないと、外れたものを作ってしまう
    • 特に意図がなくふわふわした状態のときもあるので、その場合はこちらが理想とする状態へリードすべくヒアリングする
  • このフェーズではデザイナーが企画書のデザインで忙殺されることが多い
    • 俺たちはただ応援するのみ……!がんばれ~~~!うぇ~~い!

3. 技術選定・検証、工数見積もり、外部パートナー探し

  • ざっくりと使える技術をピックアップする
    • 工数や予算、人的資源などのリソースを含めて検討する
  • サーバー代金の見積もり
    • AWS等の試算をする。
    • 「x日間でx万人が来てAPIを叩くので、えーっと、サーバー代が1億万円です!」みたいな試算が行われる
  • 工数見積
    • 案件が確定してないときの工数見積もりはめちゃくちゃにめんどくさいので注意。だいたいふわふわしてる状態で見積もることになる。気力が劇的に減る
    • 工数見積もりは段階がある
      • 超概算
      • 概算
      • 精緻
    • 超概算なら4-10倍まで幅をもたせたることもある
    • 基本的に見積もりにはバッファを足しておくこと
      • 3日で終わると宣言して、3日で終わることなどほとんどない
    • とはいえ、実際は納期・期限が決まっているものが多数。それに合わせて、できることできないこと、無理やりねじ込ませるには?といったことを考慮して見積もる
  • 外部パートナー探し
    • まだ案件が確定してない段階だが、専門的な技術を持つメンバーを集めなくてはいけない…
      • 「まだ確定してないんですが、来月から2ヶ月間空いてませんか……???」
    • 優秀な人々のリソースは8割がた空いてない。ソシャゲのガチャレベルの排出度だと思ってほしい

4. プロトタイプ・モックアップ制作

企画のよしあしはプロトタイプ・モックでわかる。想像してもわからないことが、実際に目で見て手にとって触ると、わかる。というか、作らないとわからない。

プレゼンで分厚い企画書を読み上げ重い空気が流れたあとに、プロトタイプ・モックを見せるとクライアントを一撃で倒すこともしばしば。まさに百聞は一見にしかず的なやつだ。

  • プロトタイプ・モックはとにかく、素早く作る
    • 経験値と広く浅い技術を持っているとスムーズに作れる
    • コードのきれいさはどうでもよい
      • (しかし、コードがきれいなほうが作るのが早かったりする)
  • 企画のおもしろいところを嗅ぎ分ける、"嗅覚"も必要になる
    • 少ない時間で最大限おもしろいところを磨いて提出するのみ

モックとプロトタイプの違いは以下

  • モック:
    • プログラムは組んでおらず、紙芝居で「このボタンを押すと、こんなイメージで動きます」といったもの
    • XDで遷移するようなペーパープロト
  • プロトタイプ
    • 体験の大事な部分を実際にプログラムを組んで動くようにしたもの

5. プレゼン

  • Keynote使ってみんなでスライドを編集していき、さあプレゼンへ
  • クライアントにプロトタイプ・モックを体験してもらう
  • 前人未到のプロジェクトを作り続ける朴さん(@boku)のプレゼンは異次元
    • 賢く振る舞い、場の流れをよくし、めちゃくちゃ楽しそうに提案する
    • 俺がクライアントだったら、プレゼンを聞いたら即、実行したくなるような気分にしてくれる。簡単に真似できるもんじゃないけど、真似したい

プレゼンが通ったらいよいよものづくりへ。

6. 計画・スケジュール

実装の計画・スケジュールを立てる

  • 実装の全体スケジュールを立てられるひとはリーダーとしての素質がある
  • リードエンジニアになれば計画を建てる立場になる
    • めんどくさいけど逃れられないので、諦めて計画を建てるほかない…
  • 初級者と一緒にやるときは、必ず初級者のスケジュールも立てて、見てあげる
    • 難題が多いクリエイティブでは初級者を放置しておくと炎上し、スケジュールだけでなく、その人もまた潰れてしまう

7. 実装、テスト

  • デザイン・実装・テスト、ほぼすべてが同時に進む…!
    • 「デザインが来たから実装しよう!」なんて世界はない
    • 「いつまでにデザインあがりますか?」を毎日聞いて、手助けするために自分で構成も書いて、それでもデザインがこないなら管理画面を作って、そしたらようやくデザインがくる。
    • だいたいが短納期でひたすらにぐちゃぐちゃに進むのでよいPMがいると、めちゃくちゃ楽になる
  • そして、ひたすら実装
  • 外部の協力者さんとも仲良くする
    • 高度な人間スキルが試されるッ……!
  • テスト
    • 広告・クリエイティブエンジニアリングにおいて、テストコードを書くことはほぼほぼない
      • 俺も昔は書いてた時期もあったけど、使い捨てなコードに対して書く意味がほとんどない
        • 長期運用でコードをどんどんアップデートするなら書いたほうがいいかもしれない
    • 厳密なテストコードは書かないが、テスト的なことはする。詳しくはよくやるテスト・検証にて

8. クライアント確認

  • 社長確認とかでよくバグるので注意(あるあるネタ)
    • 動かなくなったときのために、動作しているときのキャプチャも用意しておくとよい
      • 聞こえのよさそうな言い訳を用意し、謝る準備も怠らない
        • APIが壊れた
        • サウナで開発してたらマシンが壊れた
  • 実装意図をきちんと伝える
    • なんらかの理由があってそのデザインや機能・画面遷移としたはずなので、正しく伝える

9. リリース

リリースしてからも修正することは多々ある

  • リリースをゴールテープにしてアクセル全開で作りきってしまうと、リリース後に待ち受ける怒涛の修正対応に体力が追いつかないことがある
    • ソシャゲでロンチ直後にサーバーがメンテなんてよくある話…。対岸の火事ではない…。
  • きちんと体力管理をしてからリリースに挑むこと

10. 運用

  • 基本的にアルバイトでもオペレーションできる仕組みや、間違いのないUIにする
  • 遠隔で把握・操作できるようにする
    • ネットワークカメラで現場を遠隔監視
    • リモートデスクトップでPCを遠隔操作
  • 長期運用するとスタッフがダレてめちゃくちゃになりがちなので、たまに視察をする

詳しくは運用にて

それぞれのフェーズで自分がどこでバリューを出せるのかを考えること

すべてのフェーズで最高のパフォーマンスを発揮できるような人間はいない。

自分が輝けるフェーズはどこか?あるいは最適な担当おらず穴になっているフェーズはどこか?そういったモチベーションや制約条件についても考えて動くといいだろう。

また、コロナ禍の昨今ではプロジェクトのより初期のフェーズが重視されるようになった。今までの正解パターンが通用しない世の中にシフトした結果、まったく新しいアプローチをしつつも有効性のあるプロジェクトが求められるようになったからだ。

今後もそのような状況が続き、さらに変化が起こる。それも踏まえて自分のバリューを出せる場所を開拓するといいだろう。