LiBのお仕事大解剖！「企画のシゴト」とは？
新卒入社後、将来的に「企画系の職種」に就きたい方に向けて、LiBでの「企画のお仕事」についてご紹介したいと思います。
本記事では、LiBの中でも特に企画立案→設計→実装という仕事が多く、個人ユーザー様の「LIBZ」への集客、アクティブ化を担う領域チームの以下3名から、実例も踏まえたリアルな情報をお届けします。
チームメンバー
花井 リブ入社6年目 担当：集客＆ユーザーアクティブ化の企画を担う
安藤 リブ入社4年目 担当：集客＆ユーザーアクティブ化の企画を担う
鈴野 リブ入社5年目 担当：企画のシステム実装に向けた仕様設計、エンジニアとの協業を担う
企画ってどんなテーマを取り扱うの？
テーマの種類としてはまず、大きく2つに分類されます。
進化系テーマ：中期、長期（3ヶ月後〜1年くらい）の得たい効果から逆算して今から取り組むべきテーマ
成果系テーマ：短期（1〜2ヶ月）の得たい効果に向けて現状課題となっているものを解決するために取り組むべきテーマ
LiBでは行動指針に「Stack up Value（時間を味方に）」を掲げていますが、この体現のために、仕組みの基礎力を向上させる必要があり、基礎力の向上＝既存の仕組みは積み上がる資産と捉えています。
Stack up Value（時間を味方に）
打ち上げ花火的なものではなく、「常に会社や自身のありたい姿を顧みながら、長期的な価値を積み上げていこう」とするバリュー
上の図のように、目の前の行動を、どんな目標とどの時間軸で目掛けているのかをきちんとわけて捉え、実行することを大切にしています。
それでは具体的に直近で実施した「進化系テーマ」と「成果系テーマ」に関する実例の一部をご紹介します。
進化系テーマ（鈴野）
目標：
個人ユーザー様とエージェント間の面談日の調整〜確定を双方快適に行えるようにし、”会員数が増えた際にも”耐えうる状態にする
課題：
該当の既存ツールはあったが、ツールが重い＆ミスが発生しやすいものになってきていた
解決策：
一から機能を実装するのではなく、他機能で既に実装されている機能をベースに、既存ツールを廃止→システムの機能として実装
ポイント：
直近でいうと、既存ツールで対応ができないわけではないが、中長期の視点で考えると半年後に会員数を増加させる際に、業務の停滞や生産性の低下を招くと想定し、半年前から企画をスタートし、オペレーションの導入を実施
成果系テーマ（安藤）
目標：
LIBZで転職活動を実施するユーザー数の増加
課題：
LIBZに登録してはいるけれど、まだ転職活動自体は行っていない個人ユーザー様に、LIBZで行う転職活動に興味を持ったいただく
解決策：
LIBZで転職活動を行う場合にどんな転職先をご紹介できそうか？というデータを個人ユーザーに頭出しする
ポイント：
個人ユーザー様に闇雲に連絡してもネガティブなイメージを持たれてしまうだけなので、ご興味を持っていただけそうな個人ユーザー様に対して、ご興味を持っていただける内容を送れるようにアルゴリズムを作ったこと
企画が最終的にどういう形になっていくのか？
LiBの企画はやりたいことを綺麗にまとめて、あとは各所にお任せする仕事ではなく、実装を完了し、世に生まれるところまで責任範囲として持ちます。
実現する上では大きく3つの方法に分かれます。
①システムへの実装
企画・設計した内容に必要な機能をシステム開発してユーザーに届けられるようにする
②コンテンツへの実装
企画・設計した内容に必要な機能や情報をコンテンツ化してユーザーに届けられるようにする
③オペレーションへの実装
企画・設計した内容に必要な機能をヒトのオペレーションに組入れユーザーに届けられるようにする
LiBでは、②が企画内容の実現化としては最も用いられている方法です。
その理由としては、設計者がエンジニアリングの知識なしに、ノーコードで実装できる独自のフレームワークを用いているからです。
（詳しくは、弊社近藤の「【営業会社のIT企業化-後編】 採れぬなら 育ててしまえ PdM」を参照。）
そのため、大半は非エンジニアである企画者が一気通貫で、ユーザーにLIBZのサイトを通して情報を届けることができます。
これは実は、IT企業としてはかなり珍しい仕組みなのです。
多くの企業では企画者と実装者は分かれています。
そうなると例えば、
やりたいことを、実装者のアタマに漏れなく適切にインストールする必要がある
インプットが甘いと、実現したいこととアウトプットがズレる、手戻りが発生する
何か違う、もっとこうしたい、があっても直せない
というようなことが起こりやすくなり、一つ一つの工程に時間がかかってしまったり、納期を遵守する上で妥協をしてしまったりすることがあります。
LiBでは、おおよその企画をUI上で企画者自身が現実化できるので、自分の企画に対して実装、成果を出すまでの分析、改善までになえる経験を積むことができます。
具体的には、以下のような診断なども簡単に誰でも作成できます。
LiBで企画を行う上で大切なこと
企画は立案するのがゴールではなく、その企画が実現化された後も改善し続けることで、ユーザーにとって価値提供ができ、結果得たい効果を得られるようになることが大切です。
そのために、以下を前提に企画を立案します。
エンジニアやオペレーションを担う人など、ともに実現してくれる人に理解＆納得してもらえる企画内容であること
実装後、運用される中で多方面からフィードバックをもらい、高速PDCAサイクルを回していくこと
上記を叶えるために、「why（なぜやるのか？）」「what（なにをやるのか？-定性/定量）」を整理することに一番の苦労と時間をかけています。
ピンとこない方も多いと思うので、実際にチームメンバーの「why / what」を大切にする理由と、整理方法について紹介します。
鈴野
「why / what」を大切にする理由
「why（なぜやるのか？）」がはっきりしていると、「what（なにをやるのか？-定性/定量）」も明確になり、さらに先の「how（どうやってやるのか？）」を具体的に考える時に、「この機能本当にいる？」という疑いの心が出てなくて済むんですよね。つまり、企画を実行して改善するための最短距離が「why（なぜやるのか？）」「what（なにをやるのか？-定性/定量）」を誰もが納得できるものに言語化されていることにあると思っています。
整理方法
まず1回「why（なぜやるのか？）」を多少雑でも良いので、言語化してみて、そこから「何で？」を10回くらい問いかけて、「◯◯だから」と自問自答。そこで「why（なぜやるのか？）」をシャープにしていくことが多いです。その上で、複数の課題を解決したいと思ったら、課題を整理して、「what（なにをやるのか？-定性/定量）」でどこをフォーカスするか検討していくようにしています。
安藤
「why / what」を大切にする理由
鈴野さんとは違う観点では、why・whatが言語化されていると、他のメンバーとコミュニケーションを取る際のコストが大きく下がります。いきなり「how（具体的な施策）」から入ってしまうと、メンバーに共有する際に「なんでそれをやるの？」「その方法が本当にベストなの？」というフィードバックをもらうことになります。ほとんどの企画は一人では完結しないからこそ、why・whatを正しく伝え、メンバーと会話する時間を最大限に有効活用できるように準備することが大事だと思います。
整理方法
「課題の観点」を絞ります。例えばUX（ユーザーエクスペリエンス）上での課題なのか、オペレーション上での課題なのか..….etc。観点を整理したら、ひたすら課題を列挙して、その因果関係を見える化し、フォーカスすべき課題を絞り込む、という手順で整理します。
最後に
最後までお読みいただきありがとうございます。LiBの企画のお仕事について少しでもご興味いただけたら嬉しいです。
内容を見ていただくとお気づきかもしれませんが、LiBでは全てのメンバーが企画者であり実行者でもあるということが実現できる環境です。そのため、自らの気づきや経験、アイデアをすぐに企画して形にして実行できるという楽しさがあります。
より詳しく聞きたい方は、お気軽に採用担当にお問い合わせください。