この記事は アイスタイル Advent Calendar 2022 10日目の記事です。
こんにちは、アイスタイルで基盤側のサービス企画・ディレクションを行なっているkitakです。
今年もあっという間にこの季節がやってきました。もう年末ですね。
去年の記事では元々エンジニアとしての経験もあったことから社内でエンジニア→ディレクターにジョブチェンジをしたことについてアドベントカレンダーに書きました。
12月時点でディレクターとしてサービス企画の業務に携わり1年半が経ちました。
今年はディレクター業務を行ってきた今までを振り返りつつ、サービス企画の業務を行なって学んだこと、教訓になったことなどを踏まえて色々とまとめていきたいと思います。
エンジニアが多く投稿するアドベントカレンダーですが、サービス企画の業務にも興味を持ってもらえたら嬉しいです！特にこれから企画の仕事を行なっていく方にも是非読んでもらいたい内容となっております！
これまで携わってきた基盤システム
- 会員基盤(@cosmeの会員まわりのサービスの企画・ディレクション)：21年5月~22年2月
- 決済基盤(@cosme shoppingなどで利用される決済サービスの企画・ディレクション)：21年5月~22年2月
- メール配信基盤(各サービスに関係するメール配信等のディレクション)：21年8月~22年12月
- 商品データ基盤(@cosmeで掲載する商品を登録するツール・サービスを中心とした企画・ディレクション・進行管理)：22年2月~現在
まずこれまで自分が携わってきたサービスの一覧です。自分が所属しているプラットフォーム部では主にサービスやシステムの基盤となる部分を扱っており、サービス企画やディレクションの業務を行っています。
最初の1年目は包括的に様々なシステムのサービス企画・ディレクション業務を兼任し、幅広く経験してきました。今年の2月から商品データ基盤の担当に専任となり、現在動いているPJTの企画・ディレクション・進行管理などに現在まで携わっております。
サービス企画を通して学んだこと
ここから下は話の本題であるサービス企画で必要なこと・学びになったことについて紹介していきます。
思考する範囲・視野は常に広げる
関係する各所との調整や対応する中で的確に相手に共有・依頼する業務が多く、
影響範囲の確認や関連する技術の知識のインプットなどを含め、
普段の業務から考えるべき箇所、確認項目において取りこぼしがないように
普段から常にアンテナを貼る必要があります。
思考の守備範囲が広いなぁと業務を通して度々実感させられました。
視野が狭いと進捗共有や資料レビューをする際、観点や検討の抜け漏れや生じることがあります。
気をつけないと簡単に抜け漏れが発生するので防止策を以下３点にまとめました。
- MTGの種類ごとに着目する要点は決めておく(MTGの種類：進捗共有、仕様確認、案件共有など)
- 実施背景・目的をまず頭に入れる
- ゴールイメージをもつ(達成したらどうなるのか、何ができるようになるのか、など)
一度決めた方針・軸は変えない
PJTの中での方針や方向性などを決めていくこともサービス企画をしていく中では必要になっていきます。例えば、限られた予算の中で仕様のどこを取捨選択しなければならないか、を決めることも業務の中では発生します。
その中で「最終的にどうしたいか」の軸や目的がブレてしまうと「思っていたのと違う！」といった成果物が生まれることになります。
自分の失敗談として前回のMTGで決めた方針が反映されないまま課題を解決するべき案をいくつか用意したため、指摘を受けたことがありました。
まとめると以下の3点に気をつけるようにしています！
- 最初に決めた目的や方針は変えずに遵守する
- PJTや課題となるトピックの背景や目的・方針はドキュメントに残す
- 定期的にアジェンダの方針や目的・背景に関してはMTGの冒頭で共有するようにしている
何かを決定する際の自分の意志はしっかり共有する
前述の話と同様に、システム・サービスの仕様を考える上での方針や方向性を考える際、大きく決定を行う場面が多く、その判断に迷うケースも時には発生します。
自分は最初、PJTの中で何かを決める際にチームメンバーに対してどうすれば良いかを伺って
その中で決めるといった形で話を進めていたため、
「この場合に自分だったらまずどうしたいのか？」といった共有をまずはじめにしてほしいというFBを貰ったことがありました。
他者に決定を委ねるではなく、まず自分がどうしたいのかを意志と明確な決定理由をはじめに共有することで、そこから議論が進むため、MTGの流れとしても話しやすくなります。その中で大枠これは必要になってくる大方針に関しても共有しておくと何を決めなければならないかがまとまってくるので用意しておくことが大切です。まとめると以下の3つです。
- 自分がこうしたい意志、アイデアを初めに共有する(ドキュメント、シートなどでまとめておくと良い)
- 根拠となる決定理由を用意する
- 大枠の大方針が決まっている場合は合わせて共有する
共有・依頼をする際は情報を話しすぎないようにする
サービス企画の業務は関係各所への共有、依頼を行う場面が多いです。
事業部側、開発側とのやりとりも多く、時には板挟みになることもあるため、
わかりやすく的確に伝えるなど、コミュニケーションはスムーズにする必要があります。
自分の失敗談として、相手に理解してもらうために詳細な情報をはじめに説明を加えて依頼をした際、
依頼を受けた側は「何の依頼を受けたのかがわかりづらかった」と困惑する場面がありました。
自分は以下の３点に気をつけるようにしています。
- 依頼内容はシンプルにまとめて相手に伝える
- 相手の理解度に合わせて要点を的確にまとめる
- 普段から必要最低限の共有で収めるようにする
自分のオリジナリティはアウトプットに出す
「こういうものを作りたい」といった仕様の話を日々考えていく中で、ある程度大枠が決まったものを画面仕様に書き起こす作業を行っておりました。
その際、「ある程度きまったもの」をそのまま反映させた画面仕様を作成してしまい、
レビューの中で「事前に考えた内容がそのまま反映された仕様になってる」という指摘を受けました。
立場上企画者であるため、作成するものの観点から
「自分ならもっとこうしたい」,「こうすればもっと画面として良くなるんじゃないか」
といったことを日々考えつつ、
仕様を作成するときなどには特に自分が思う箇所や項目に対してアイデアを多く出したほうが自分の評価に繋がると思います。
但し、出す際は意図・理由をしっかり用意することを忘れずにです。
さいごに
いかがだったでしょうか？
システムの担当が兼任でなく専任になってから深く携わることが多くなり、
それと同時にサービス企画の難しさにより気づくことができました。
まだまだ一人前になるまでの壁は分厚く、これらを一個ずつ壊していきたいなと思います！
最後に余談にはなりますが、今年の出来事としてはとあるエンジニアをやっていた知り合いが
サービス企画にジョブチェンジをしたという話を聞き、エンジニアからサービス企画に職を変えるということも珍しくはないなということもしみじみ感じました。
実際にはエンジニアの経験がある人が企画職にジョブチェンジをすることで組織として大きく貢献できたりするので興味が湧いたら今後のキャリアで挑戦してみるのもありかなと個人的には思います。(もちろんまたエンジニアに戻るでも全然ありです！)
休日の投稿でありながら最後まで読んで頂いた方ありがとうございました！
みなさん良い週末をお過ごしください！