新卒採用の広報解禁日である3月1日が近づいています。i-plugでは自社サービス「OfferBox」を活用し新卒採用を実施しています。OfferBoxは一般的なエントリーシートや履歴書とは違い、「私の将来像」「過去のエピソード」「研究内容」など就活生が自由に文章を入力することができる項目があります。
i-plugに新卒で入社したメンバーは、OfferBox内のプロフィール項目である「自己PR」と「私の将来像」に何を書いていたのか、新卒入社したメンバー8名に聞いてみました。

赤星さん

i-plugではLightning Talk会（以下、LT会）が不定期で開催されています。LT会を担当する枡井さんへ開催の目的や内容について聞きました。
また10月に開催されたLT会の様子もお届けします。

 

2022年11月に入社した山岡さん。これまでの経歴やi-plugに入社したきっかけ、そしてエンジニアリンググループ第2チームのチームリーダーとしての仕事をするうえで意識していることや今後の取り組みについて伺いました。

2022年7月にi-plugサービス開発部（現プロダクト企画開発部）に入社した道産子の池内さん。i-plugに入社したきっかけやプロジェクトマネージャー（以下PM）としての業務内容、入社してみて感じることなどをお伺いしました。

クックパッドで技術部長を務めたのち、複数の企業で技術顧問やCTO/VPoEに就任。2022年にCTOとして入社した小川さんに、これまでの経歴や作りたい未来を伺いました。

 

大学院卒業後、最初に就職したのは大阪のWEB制作会社でした。当時はいわゆるWeb1.0の時代。それに関する開発を何でもしました。言語はPerlやPHP、Adobe Flashなど。社内向けのWebシステムの開発も担当していました。社長は大学の同級生で、初めての社員が僕。なし崩し的に僕がどんどんマネジメント業務を担うようになりました。

今でこそCTOですが、当時は体を動かして物を作るのがすごく好きで、新しい技術習得や調べるのも大好きで、もっと技術に触れていたいという思いが膨らんでいきました。GREEやDeNA、サイバーエージェントが盛り上がっていた頃で、東京に出たいという思いが膨らみ、東京の会社への転職を決意しました。

2社目の会社は、Ruby on Railsを使ったWebサービスのサービス開発とインフラ設計のようなものを網羅的に開発していました。インフラの構造やサービス設計にも積極的に意見を出していくうちに周囲からアイディアや考えを求められるようになり、やがてマネジメントレイヤーを期待されはじめました。当時の僕はマネジメントをしたいわけではなかったので、その会社も離れようと考えました。

クックパッドに誘われたのはちょうどその時。個人的に所属していたRubyのコミュニティで、声をかけられました。いろいろ悩んだのですが、当時Rubyを使っている大きなサービスは食べログとクックパッドぐらいで、Rubyを使って手を動かす仕事がしたくて入社を決めました。

技術者たちの組織をより強く、働く環境をもっと良くしたい

クックパッドに入社してからは、サービス開発やデータ分析のための開発をメインに取り組んでいました。やがて、プレミアム会員に関する事業部のまとめ役を担うようになった頃、社内ではエンジニア採用に課題が浮かび上がってきました。同時に、ちらほらと不満が聞こえだすように。みんなが楽しいと思える会社の実現はなかなか難しいものの、会社全体として取り組む必要があると考え始めました。

部長に現状の問題を起案したところ、採用を含めた会社全体のエンジニアに対する課題に取り組む業務を担うようになり、人事の兼務や技術部長への就任など、多くの役職を兼任することになりました。マネジメントにどっぷり浸かっていた期間は1年半ほど。コードを書くのはプライベート、趣味としての時間でしか取れませんでしたが、全然苦ではありませんでした。むしろ、開発組織を強化し、これから道を切り開いていくエンジニアたちのキャリア支援に面白みを感じたことを覚えています。3つもの部門を兼務したのは、多忙でしたが良い経験です。

今思うと、避けていたにも関わらずこのタイミングでマネジメントに取り組んだのは、自分自身の変化によるものが大きいです。

自分を変えたのは、同僚のおかげと言えるかもしれません。お互いに技術のスキルを認めあえる、好きだと思えるような専門領域に特化したエンジニアたちに、もっといい環境を整えたい、組織を強固なものにしたいという強い思いが膨らみ、自分は縁の下の力持ちとして取り組んでいくのも悪くないと感じたのです。

Webはまだまだ若い業界です。特に、僕がクックパッドにいたときはエンジニアの方のロールモデルがない時代、技術職の地位も今に比べると重要視されていなかった時代でした。そこでエンジニアの領域から一歩踏み込んで経営の基盤や組織開発に携わることで、これから来る人たちの上に何かを切り開く思いが強かったように思います。

採用もまた例外ではありません。エンジニアの採用にはやっぱりエンジニアが関わる方が良い。面接や面談も重要ですし、リファラルが自然発生するような状態を目指すことが重要です。多くのエンジニアはリファラルで入社しています。実際、クックパッドのエンジニアの入社経路もリファラルの比率が高めでした。

クックパッドを退社してからは業務委託で開発をしたり、技術顧問をしたり。技術だけではなく人事や役員と組織開発や採用について相談されるケースも多かったですね。ただ、組織に所属していない限りはあくまでもアドバイザー。自分が手を出すことは難しく、もどかしい思いもありました。

それならちゃんとCTOや技術責任者としてどこかの会社に入って、組織も採用もプロダクトも網羅的に携わりたいという気持ちが芽生え、タレンティオやロコガイドでCTOやVPoEを務めたのち、i-plugとご縁がありました。

もっと気軽に転職できる未来をつくる

i-plugへの入社を決めたのは、キャリア全般を扱う事業領域と自分の興味関心の親和性が高かったためです。

数年前から難しいと言われているエンジニア採用を例に挙げます。エンジニアの数が不足していることに起因する問題ですが、「ではエンジニアを増やしましょう」と簡単に増やせるものではありません。ただ、エンジニア適性のある人たちが違う仕事をしているケースが世の中にはたくさんありそうだと感じています。　

実際、20代半ばからプログラミングを始め、CTOになれるくらい優秀になった人もいます。大学で情報工学に行ってなければ駄目、子どもの頃からPCに触れていなきゃ駄目、という世界ではない。頭が良いとか悪いとか、そういう話でもありません。適性が大事かなと考えています。

キャリア領域はもっと関心が増えていいと考えています。キャリアにまつわる様々な課題を解決しないと、日本はおそらくダメになってしまう。今の日本では、入社半年で退職する新卒も珍しくなく、また、中途市場でも転職したくても出来ない人がいます。

もっとみんなが楽しく仕事をもっと楽しめるように、気軽に転職できたり、職種を変えてもなんとかなる仕組みを作れないかと考えています。現時点で未経験だとしても、経験すれば面白いと思える仕事はあるはずなので、個々の適性や志向性に合わせて、キャリア選択の可能性を示せる仕組みを作れたら面白いんじゃないかなと思います。

だから僕は、そういう未来を作る仕組みを技術で実現させたい。大変だと思うんですけど、その未来ができたら働くことに対しての負のイメージが少し払拭されるかもしれない。もしくは、働くのは楽しくてもいい。ただ、給与が待遇がいいとか。何かしら「働き続けられる」仕組みが作れたらと思います。

良いプロダクトなら売上も上がる。売れないなら、良い価値提供ができていない

僕が一番大切にしているのはプロダクトです。技術も当然大事ですが、プロダクトとして人々に何を提供するのか。何のために何を提供するかが肝であり、明確にすべきポイントだと考えています。

次に大切なのは、売上です。技術職や研究職の方で積極的に売上を口にする人は多くありませんが、私は重視しています。良いものを作れば、お金を払ってもらえるはず。逆に言うと、お金を払ってもらえないものは良い物といえないわけです。ですから、プロダクトを大切にしつつ、お金を払ってもらえるほど価値を提供できているかという点を重視しています。プロダクトの良さを測るために、売上は良い指標だと考えています。

続いて、技術とエンジニアたちが大切です。彼らが楽しみながら働ける環境づくりを重視したいと考えています。技術における言語の選定や投資対象も大事ですが、開発部門のみならず会社全体の風土や雰囲気、MVVなどを含めた組織開発が求められ、文化を醸成させることが大切かなと考えています。

文化の醸成は一筋縄ではいきません。リーダーが文化を体現しないと根付かないため、自らの行動としてどうあるべきかは常に意識をしていきます。加えて、対話も重視します。チャットで済ませたがるエンジニアも多いものの、その人らしさが伝わるのは、対面で会った時に感じる「非言語コミュニケーション」による醸成も多いものです。

体現とコミュニケーション。文化を作るまではいかずとも、根底にある人の大事な考え方の認識が揃い、楽しもうという気持ちが生まれるよう取り組んでいきたいです。

そういう文化ができあがると、もっと開発組織は良くなると信じています。例えば、エンジニア側から自発的に改善案が生まれたり、売上を高めるための戦略を考え出す。そこからスピードを持って開発ができる組織を目指したいと考えています。

こんにちは！採用グループ 業務委託メンバーの東良（ヒガシラ）です。この記事では、今期中途入社として新たにジョインしたエンジニアの力石さんにフォーカスします。

力石さんは、情報系の専門学校卒業後、前職まで一貫してSIerのシステムエンジニアとしてキャリア形成してきた方。数社で経験を重ね、プログラマーからチームリーダーまで一見着実にキャリアを形成してきたように見えますが、その道は決して平坦なものではありませんでした。業績不振による会社都合での退職や、プロジェクトの炎上による度重なる残業。一度はIT業界から離れようとさえ考えた事もありました。

どのようにしていまのキャリアに至ったか、力石さんにインタビューしました。

 

弊社サービス開発部には、プロダクトの課題を仮説検証し、探索的に課題解決を図っている「グロースチーム」があります。今回はグロースチームに所属している藤田をご紹介します。

所属しているチームと役割について

初めまして、UXグループの藤田です。チームでは主にOfferBoxを利用した学生と企業のマッチング数の向上にコミットするための活動をしています。

そのなかで、私はデータサイエンティストとして、主に以下の活動をしています。
・論点を設定して仮説構築し、分析すべき問題を定める
・企業や学生がOfferBoxで活動したデータを収集
・データからそれぞれの行動を分析
・プロダクトの質的改善に繋がる施策の立案
データサイエンティストといえば、データ分析が主な仕事と思われがちですが、実際にはその前段階である分析テーマの企画にも携わっています。

施策を打ち出す際には開発した機能のABテストを実施し数値を測定しながら効果検証をおこないます。私が入社する前も統計的仮説検定を用いた検証は既に行われていました。これに加えて、私がテスト前検証や効果量を考慮した必要サンプルサイズの推定などを導入したことで、より慎重に効果検証が行われるようにしています。

i-plugに惹かれた理由

i-plugに入社する以前は、大手化学メーカーでデータ分析の業務を担当していました。どちらかといえば機械学習による予測タスクの精度向上をメインに仕事をしていましたね。
当時からデータサイエンティストとして働いていましたが、まだ自分のスキルには不足している点を感じていました。
データサイエンティスト協会が開示しているデータサイエンティストの3要件には、「データサイエンス力」「データエンジニアリング力」「ビジネス力」があります。私はこの中でも、ビジネス力を伸ばしたいと考えていました。
i-plugと出会ったきっかけは、i-plugがランチスポンサーをしていたデータコンペティションです。登壇内容を聞いているうちに、i-plugでの業務内容に興味を持ちました。
また、i-plugが運営する「OfferBox」は新卒採用の課題を解決するために生まれたプロダクトだと知りました。私自身も新卒で入社した会社で苦労した経験があります。i-plugは就職活動の仕組みを変える会社ということで、入社して自分のように困っていた学生を助けることができたら良いなと思い、選考を受けることにしました。
選考過程でOfferBoxの現状の課題を聞き、問題としてはかなり難しいものに挑戦しているなと思いました。特に難しいのは、企業と学生の2つの軸で課題と解決策を考えないといけないところです。両者のニーズが噛み合うように最適化しないと良い改善ができません。
一方で、私自身には解けないことが濃厚な問題や簡単な問題は自分の成長に繋がらないという考えがあるので、非常に挑戦する価値のある課題だと感じました。

どういったプロダクト成長を目指したいか

結果ありきの成長はしたくないと考えています。KGIにしても、達成するための過程が大事だと思います。考え得る施策を手当り次第に実施し数値達成することは良い課題解決とは言えないでしょう。
良い課題解決とは、プロダクトに求められる要件を見定め解決策を練り上げていくことにあります。そのためにユーザーのニーズを見極めていくこともデータサイエンティストには求められますし、勘や経験則に頼った解決策ではなく、データに基づいて何が必要なのか、足りていないのか、課題はどこにあるのかを炙り出していきたいですね。

今後のキャリアについて

先述しましたが、現時点ではよりビジネスサイドの知見を深めたいと考えています。
これまで機械学習やデータ分析はしてきたものの、ビジネス課題を特定・解決する能力がまだまだ足りていないですね。仮説を証明する力としての分析だけではなくてその前工程部分をもっとできるようにしていきたいと考えています。

今回は「最高の結果を出すKPIマネジメント」という本を読んで得た要点を、勇者と魔王のファンタジー世界観になぞらえて書いていこうと思います。

はじめまして。プロセスソリューションチームの立見です。

いきなりですがチームの紹介から。プロセスソリューションチームは社内業務を効率化することでサービス価値を向上させるミッションを持ったチームです。主に社内業務に関する技術的サポートや社内業務を通じてサービス価値を向上させる提案から開発まで行います。

今回、チームのミッション達成度合いをどのように測るかを考えまして、KPIによって実現できるのでは無いかと思い下記書籍を読みました。

「最高の結果を出すKPIマネジメント」
https://www.amazon.co.jp/dp/4894519844

この本を読んで得たことを、勇者と魔王のファンタジー世界観になぞらえて書いていきます。
なぜわざわざファンタジー世界観を使うのかというツッコミは無しでお願いします。固い言葉が並んでいると眠たくなるからです。

勇者と魔王のファンタジー世界観

ゲームでよくある世界観ですね。果たして何がどのくらいになればこの村の人類は繁栄できるのでしょうか？

KPIを設計して数値管理してみましょう。

 KPIとは

KPIとはKey Performance Indicatorsの略で、日本語にすると「重要業績評価指標」と呼ばれるようです。
書籍では以下のように説明されています。

私はKPIという文字自体はなんとなく知っていたものの、事業の重要な数字が並んでいるものくらいの印象しかありませんでした。

何も考えずにKPI設計してみる

さて、何がどれくらいの数値であれば、この勇者と魔王の世界において、この村の人類は繁栄できるのでしょうか？
うーん・・・、魔王によって平和を脅かされているし、たぶん以下の要素が重要なのではないでしょうか。

•  勇者の強さ
• 勇者の武器の強さ
• 勇者の防具の強さ
• 勇者が行動するためのお金の量
• 魔王の強さ
• 配下の化け物の量

これらをそのままKPIの項目にしよう！全部重要そうだし。

勇者の強さ	武器の強さ	防具の強さ	お金の量	魔王の強さ	化け物の量
？	？	？	？	？	？

あとはそれぞれの項目の目標数値を決めれば完璧だ！！！

この時点でイケてないKPI設計をイケてるKPI設計にする

残念ながら、この時点でイケてないKPI設計なようです。
なぜ？　全部重要に思える項目なのに！

その理由は、以下の3点が原因です。

• KGIに繋がるように設計していない
• CSFが不明
• KPIがたくさんある

 

では、イケてない理由の詳細と、どのように解決したら良いかを見ていきましょう。

イケてない理由その１「KGIに繋がるように設計していない」

KGIとは、Key Goal Indicatorsの略で、最終的な目標数値です。
最終的に何がどのような数値になっていれば良いのか？を表すものです。数値という言葉どおり定量的な指標が望ましいとされています。

また、KPIはKGIにつながるための指標にしなければなりません。

今回の世界観のKGIは何か？

KPIをKGIにつながる指標にするため、まずはKGIを確認しましょう。

魔王を倒せば平和になって人類は繁栄できるのだから、KGIは「魔王の生存数=0」でしょ！
と思われる方もいるかもしれません。

しかし本当にそうでしょうか？
最終的に達成したいのは村の人類の繁栄ですね。
ですので、KGIは村における人類の繁栄を数値に置き換えたものになるはずです。

人類の繁栄を数値に置き換えると何になるでしょうか？人口？文化の発展度？村の魅力づけ？
色々あると思いますが、この記事ではKGIを「人口=2,000人」にしたいと思います。
実際の業務でのKGIは、事業の戦略資料に書かれていたり、事業計画資料に書かれていたりするはずです。確認してみましょう。

KPIがKGIと繋がっていない？

さて、KGIを「人口=2,000人」としました。
改めて、先に設定したKPIを見てみましょう。

勇者の強さ	武器の強さ	防具の強さ	お金の量	魔王の強さ	化け物の量
？	？	？	？	？	？

今のKPIはKGIと繋がっているでしょうか？
勇者が強くなれば人口は増えるでしょうか？人口の減少が止まるでしょうか？
関係はあるかもしれませんが、直接繋がっていないように思えます。
これでは、今のKPIをどれだけ管理しても、人口にどのような影響があるかわかりませんね。

イケてない理由その2「CSFが不明」

続いてのイケてない理由は、CSFが不明である点です。

CSFとは、Critical Success Factorの略で、重要成功要因です。
KGIを実現するための様々なプロセスの中で、最も重要なプロセスのことを指します。プロセスですので、これは定量に落とし込まなくて構いません。

では、この世界のCSFを見ていきましょう。

今回の真のCSFは何か？

イケてないKPIでは、魔王によって平和を脅かされていることで繁栄を阻害されているのだから、CSFは「魔王を討伐すること」であると考えました。
本当にそうでしょうか？
今回のKGIは「人口=2,000人」です。現在この村には1,000人ほどしかいませんから、あと1000人増やす必要があります。

人口が増える方法を探るために、まずは人口が増減する要因について冷静に分析してみましょう。
その結果、人口増減の要因が下記のようにわかりました。

人口増減の要因

これらを人口に与える影響として数値化させます。

増加要因
コウノトリお願い率<br>
6人 / 1000人 = 0.6%

減少要因
魔王の影響による引っ越し率
3人 / 1000人 ＝0.3%

入院率
5人 / 1000人 = 0.5 %

余生まっとう引っ越し率
5人 / 1000人 ＝0.2%

どうやら魔王やその配下による影響よりも、それ以外の部分が大きく人口に影響を及ぼしているようです。
人口がどのように成り立っているのか式で表すと下記のようになると思います。

1ヶ月後の人口予想をこの式に当てはめると

になります。

もし魔王を倒してその影響が無くなったとしても

と、減少の一途をたどってしまいます。

どうやらKGIの「人口=2,000人」を達成するためには、下記の要因のほうが重要なようです。

この中で「老後の引っ越しを認めないようにする」は、不可だと思うので外します。コントロールできないことをCSFにしてしまうとどうしようもありません。
とすると残った「コウノトリにお願いする」ことか「予防する」ことがCSF候補として考えられます。

赤ちゃんは現状ではだいたい月6人生まれるのに対し、入院者数は現状だいたい月5人、かつ入院率よりもコウノトリお願い率のほうが人口への影響が大きいため、今回のCSFは「コウノトリにお願いする」にしようと思います。書籍によると、CSFを一つとするのは重要なようです。なぜ重要かは後述します。

イケてない理由その3「KPIがたくさんある」

ここまでは、KGIとCSFを確認しました。いよいよ、KPIに挑みます。

現在、イケてないKPIでは項目が6つあります。
なぜそれがダメなのでしょうか？

KPIがたくさんあると・・・

書籍では、KPIは信号だと例えています。
KPIが達成できているのであればそのまま進め、KPIを達成していないのであれば何か問題が起きつつある。KPIが大幅に未達であれば今の戦略や戦術を見直す必要があると判断できます。

しかしKPIがたくさんあると、今のままでいいのか何か方針転換したほうがいいのか判断しづらくなります。
例えば勇者の強さは達成しているが、お金の量が足りていない場合、どうすればいいのでしょうか。
このまま進むことで本当に目標を達成できるのでしょうか？判断に迷いますね。

改めてKPIを考えてみる

初めの方でKPIの説明を書籍から引用し下記のように書きました。

ここでいう「事業成功」とは、KGIである「人口=2,000人」
「鍵」とはCSFである「コウノトリにお願いする」と決めました。

KPIとは「鍵」を「数値目標」で表したものなので、
KPI項目は「コウノトリにお願いした件数または率」となります。

CSFが多くあるとそれに従ってKPIも多くできてしまうので、CSFを1つに絞ることは重要なんですね。

 数値目標