【営業会社のIT企業化-後編】 採れぬなら 育ててしまえ PdM

はじめに

私は今株式会社LiBにおいて「エンジニア採用が困難な営業会社をIT企業化する」という企業版行動変容に取り組んでいます。その全体像を社内外に正しく伝え、共感・支援してくださる方を増やすことが本記事の目的です。

本記事の要点は以下の2点です：

• 分散化させたエンジニアの仕事を、エンジニアではない人が担えるようにしている背景
• その担い手となるプロダクトマネージャー（以下「PdM」と略記）を確保する方法

後編だけ読んでも成立するようになってますが、できれば前編の「採れぬなら 分散化（バラ）してしまえ エンジニア」から読んでいただけると、意思や意図が伝わやりやすいかと思います。

本記事における「エンジニア」は「ソフトウェアエンジニア」「ITエンジニア」のことを指します。

エンジニア業務の分散化を実現する鍵

前編では「エンジニア業務の分散化」というテーマで、LiBが取り組んでいる5つの工夫を紹介しました。

具体的には、
　①参画形態の分散化
　②要求スキルの分散化
によって組成したチームによって、
　③マスターデータの分散化
　④新規開発業務の分散化
　⑤最終成果物担当の分散化
が実現可能な環境＝フレームワークを実現すること、という内容でしたが、③④⑤でエンジニアから切り離した仕事を担う人をどう揃えるかが次の障壁となります。

いきなりですが、その答えは 「非エンジニアの分散処理戦力化」 です。要は、分散化させたエンジニアの仕事を、エンジニアではない人が担えるようにするということです。

これを聞いて「なるほどねー」と思われる方はほとんどいないと思うので、本記事ではそこを掘り下げてみたいと思います。

そもそもなぜエンジニアが足りないのか？

「業界」の選択肢の1つとして「IT業界」が並んでいることに違和感を感じるくらい、もはやIT化していない業界はないのではないか、という時代。急速に高まるITエンジニア需要に対して、その供給が不足していることは明らかだと思います。

これだけ需要があるのに供給が不足し続けるというのはなぜでしょうか？

文系理系の過度な分断など色々仮説が浮かぶと思いますが、私は 「入り口がプログラミングしかないことの弊害」 が大きい気がしています。

IT技術の進化に合わせ、プログラミング環境もここ数十年で急速に改善しています。一昔前はポインタやメモリ管理などで脱落していたプログラマーやエンジニアの卵も多かったと思いますが、そういった脱落ポイントを意識しなくて良い環境（※）が主流になりました。

※：自動車のマニュアル運転がほぼオートマ運転に切り替わったようなものだと思ってください。

ただ、それでも 「実用的なプログラミングスキル＝現実世界で価値を感じられるような成果物を出すためのスキル」 だとすると、その獲得コストは依然高いと言わざるを得ません。

図：壁の高さをほのめかす謎の画面＠TVや映画

一方で、その獲得コストの高いスキルを身に着けたエンジニアがずっとプログラミングしているかというと、実はそうではないという事実もあります。

どんなエンジニアでも、実際にプログラミングをしている時間は半分もなく、大手企業のエンジニアなどであれば2,3割というケースも珍しくない（※）のではないでしょうか。

※：設計が甘く、手探りでコーディングしているようなレベルは除きます。

では、エンジニアは一体何に時間を使っているのでしょうか？

翻訳業務のコスト

エンジニアが意外と時間を使っているのは 「翻訳」業務です。

エンジニアの仕事は、現実世界とコンピューターの世界をつなぐため、現実世界の物事をプログラミング言語というコンピューター用の言葉に翻訳することであるとも言えます。

例えば以下のようなイメージです：
・現実世界での言葉：7月以降にログインしているユーザーの一覧を取得
　　↓　翻訳
・コンピューター用の言葉：getUsers(lastLoginDateFrom:"2022-07-01")

なので、そこに時間を使うこと自体は正しいのですが、これを自分自身でやる場合と、伝言ゲーム形式でやる場合では、かかる時間が圧倒的に異なります。

例えば、「最近アクティブなユーザーの傾向を見たい」という超簡単そうな要求ですら、以下のような一次翻訳作業が発生します。
・「最近」→今年の7月以降とする
・「アクティブ」→最終ログイン日時で判断する
・「傾向」→年齢／性別／職種で見る

エンジニア自身が企画者になる場合は、この翻訳をリアルタイムにやってしまうことが多いんですが、そうじゃない場合は1つ1つ翻訳＆確認が必要になってしまいます。

図：PDCAの現実（LiBの採用資料より抜粋）

前編で紹介した上の図にも表現されているように、ものづくりの工程では、企画者と実装者の間でキャッチボールを行うポイントが何度もあります。

そのため、この企画者に相当する人の言語化スキルが乏しいと、恐ろしいほどの翻訳コストが都度都度かかってしまいます。 企画者が自分自身で全て考えておらず、偉い人や他のステークホルダーの意見を取りまとめているだけの場合などはなおさらです。

逆の見方をすれば、エンジニアが重宝がられる要因の1つには、周囲の言語化スキルが低い（※）ことがあるのかもしれません。

※：そもそも「コミュ力」と「言語化力」の区別が付いていない企業が多そう、という課題感を持たれている方もいるようです（こちらのツイート参照）。

翻訳できる人を増やして活かせば良いのでは？

これまでの話をまとめると、

• 現実世界の物事をプログラミング言語というコンピューター用の言葉に翻訳するのはエンジニアの仕事
• エンジニアはプログラミング以前の翻訳業務（言語化・構造化）に時間を使っていることも多い

ということになります。

これを図で表現すると、黄色の矢印部分の会話コストがかなり高く、エンジニアの負担になっているケースが多いということです。

図：ものづくりにおける登場人物とそのコミュニケーション

そして、その状況は「非ものづくり職種」の視点から見ると以下のような印象になることも・・・。

図：「エンジニア 会話」でググると出てくる衝撃のサジェスト

この状態を改善するアプローチとして、現実世界の物事を、エンジニアやコンピューターが理解しやすい言葉に翻訳する役割を設置するのはどうでしょうか？

同じ図で表現すると、右下の領域の人を増やせないか、という発想です。

プログラミングは言語化・構造化力を育む上で非常に有用な手段なので、プログラマーがエンジニアにクラスチェンジすることも多いです。これからの時代の需要を考えると、そのルートはより一層太くすべきですが、プログラミングが壁になりがちであることがわかっているのであれば、違うルートを開拓する余地もあるのではないか（※）、と私は思っています。

※：最近では、「漫画を作りたい」と思った人が活躍できる場は、原作・作画・編集のように色々あることが知られていますが、それと同じ思想です

【戦略その2】非エンジニアの分散処理戦力化

今回も前フリが長くなりましたが、いよいよ本題です。

LiBでは、現実世界の物事をエンジニアやコンピューターが理解しやすい言葉に翻訳できる人材は、そのまま分散化させたエンジニアの仕事を担える人材となります。

分散化させたエンジニアの仕事を担える人材（分散処理の戦力となる人材）とはどんな人なのか、それを満たす人材をどうやって確保しているのか、簡単に紹介していきます。

求められる4つのスキル

前編で紹介したエンジニア業務の分散化は、単なる「分業」ではありません。その本質は「自分で考えたことを自分で実行する」という直接性向上のためであり、それによるスピードとクオリティの向上にあります。

おなじみPDCAの分担で言えば、縦で切らず横で切るようなイメージです。

図：PDCAの分担方式

一人でPDCAを回すためには、最低限以下のようなスキルが必要です。

企画力：ゴールを定義する力
・現状をしっかり把握し、何のために何をやるべきかを見極め、定められること
・主な成果物は、企画書など

設計力：最終成果物を定義する力
・企画したことを実現するために、誰が何をどのように行えばよいかを定められること
・主な成果物は、仕様書やテストケースなど

実装力：最終成果物を扱う力
・設計したことを適切な粒度の実装タスクに分割し、それを完遂できること
・主な成果物は、マスターデータやコンテンツやノーコード環境で実装されたUIなど

検証力：成果を証明・検証する力
・実装、実行したことの結果を適切に測定・分析し、説明できること
・主な成果物は、分析結果レポートなど

4つのスキルを持つ人＝PdM

LiBでは前述の4スキルをプロダクトマネジメントに必要なテクニカルスキルとして定義しています。

図：LiB社内資料より

上図の一番下の段に並んでいるグレーの箱は、PdMの教科書とも言える書籍で定義されているスキルです。ここで定めたスキルがあまりにLiB環境に特化し過ぎていないかチェックするために比較してみたんですが、概ね似たような構造になっていました。

PdMという職種名が日本に浸透し始めて歴史が浅いので、会社によってその役割定義はバラバラで、求められるスキルもバラバラだという話をよく耳にします。綺麗なプレゼン資料を作るスキルだったり、仕様設計するスキルだったり、FigmaでUIデザインするスキルだったり、部署間調整するスキルだったり、プロジェクトマネジメントするスキルだったり、事業管理をするスキルだったり。

LiBではシンプルに以下のように考えています。

PdMスキル　＝　ものづくりスキル　ー　プログラミングスキル

要は、プログラミング以外、ものづくりに必要なことは全部やるということです。

• そんなオールマイティーなPdMなんてどこにいるの？
• 前編で「大谷探しをしない」って言ってたのに、イチローとダルビッシュを探せってこと？

・・・と思われるかもしれないので、それについては次のセクションで説明します。

PdM育成に必要な4つの資源

そんなオールマイティーなPdMはどこにいるのか？

残念ながら、あまりいないと思っています。以下理由です。

• 本気のPDCAをガンガン回してるところ＝成長産業じゃないと育たないが、現在の日本では成長産業と呼べるものが限られている（涙）

• 一定規模以上の企業では分業するのが当たり前で、そもそも組織が役割ごとに分かれているので、勝手にあれこれやろうとすると怒られる

• 逆に人がいないスタートアップでは、スキル不足な人が全体を回すと単に失敗するだけなので、最初から高スキルな人（当然レア人材）が無双するのが普通

• そんな高スキルな方は採用市場で奪い合いであり、数が少ない上に採用競争率も高いので、普通は採れない（少なくとも、まだ営業会社扱いのLiBには来てくれない・・・）

なので、育てるしかない（ようやくタイトル回収！！） というわけです。

では、どうやって育てるのか。LiBでは、以下の4つの資源を確保することを意識しています。

①【思想】「育てるもの」という前提

PdMのスキルは、プログラマースキルと違って学生時代には獲得しづらいものです。強いて言えば、自分でプロダクトを作り切った経験がある人は獲得できますが、それも企業のPdMとして必要とされるスキルのごく一部に過ぎません。

つまり、ほとんどのPdMは企業で育てるしかないわけですが、「プロダクトマネージャー、未経験だけどやってみたいです」という人を受け入れられる組織は、世の中にどれくらいあるんでしょうか。「即戦力採用」というフレーズが当たり前になってから、人を「育てる」という思想は新卒専用になってしまっているような空気すら感じます。

そもそも供給が追いついていない職種・スキルであるなら、ただ採用を頑張るだけでなく、自ら育てるものであるという前提を持つことが必要だと考えています。（採用サービスの会社をやっている立場で力説するのもアレですが・・・）

また、LiBには、業務に必要なスキルはいつでも誰でも獲得できるようにしていきたいという思想もある（この記事の「アビリティ指向」欄を参照）ため、PdM職を増やすだけでなく、PdMスキルを少しでも持っている人を増やしていくというアプローチを採っています。

②【砂場】自分でトライアンドエラーできるように

子どもが自由に遊べる砂場になぞらえて、他への悪影響を気にせず、プログラムを自由に動かせる隔離された環境のことをサンドボックス（sandbox/砂場）と呼びます。自分自身やお子様の砂場体験のことを思い返してみると、あの砂場で育まれるものは計り知れないのではないでしょうか。

ものづくり環境も同様で、このサンドボックス／砂場に相当するものを設置できるかどうかで、そこにいる人材の成長速度が変わってきます。 何かを作ったり変えたりする行為に対して、いちいち承認が必要な環境では成長ペースは限定的ですし、ましてや、何かやるたびに怒られたりするような環境では育つものも育ちません。

LiBでは、前編で説明したノーコード開発環境によって、影響範囲を適切にコントロール（※）しながら、トライアンドエラーを思う存分行えるようにしています。

※：コントロールがない状態で無邪気に試行錯誤すると、エンジニアが疲弊したりユーザーが離れてしまうことが多いです。砂場を使わずに家の中のモノで無邪気に試行錯誤してしまうと、家族が疲弊してしまうのと同じです。

③【階段】適切な階段

LiBは「人間はアップデートできるもの」という思想で事業を展開しているため、社員の成長についても同じスタンスで取り組んでいます。

成長機会を提供する上で、高い壁を設定して乗り越えてもらうスタイルを「クライミング型」の育成と呼ぶなら、目の前の階段をコツコツ登っていくことで自然と高みに至る「階段型」の育成もあって良さそうです。

図：成長機会の提供（クライミング型と階段型）

PdM育成に関しては、以下のようなことを意識することで、適切な「階段」を設定しています。

・過去経験を活かしたアサイン
　→階段型でもゼロからスタートしなくて良いように
・身につけていくべきスキルの全体像と現在地を可視化
　→暗中模索にならないように
・任せる領域の明確化
　→小さくても自分が最後の砦になれるように

実際LiBでは、PdM業務どころかプロダクト開発未経験の人材でも、気がつけば、複雑な仕様を設計したり、SQL書いたり、Sentry見たり、ERB書いたり・・・といったこと（※）ができるようになっています。

※：SQL／Sentry／ERBなどは「普通はエンジニアの仕事とされるようなことの例」だと思ってもらえればOKです。

④【時間】時間をかける

①〜③はすべて環境に関するものですが、いくらそれらが完璧に揃っていても「時間」が欠けていては育ちません。植物の育成において、いくら素晴らしい気候や土壌や肥料を用意しても、成長に要する時間を劇的に短縮できないのと同じです。

変化の速い時代、ついつい色々なことをショートカットしたくなりますが、なんだかんだでビジネスの世界でも「急がば回れ」は正しいなと思うことが多いです。無理なショートカットをやってみても、結局後でツケを払わされたり。

LiBでは、あらゆることを 「点」ではなく「線」で考えることを重視 しています。人材育成についても最大瞬間風速を重視するのではなく、継続的に発揮能力を高め続けられることを重視しているため、ある時点でできることだけで人材を評価するのではなく、成長のためにかけた時間に応じて発揮能力が高まっていくはず、という健全な期待値を持つようにしています。

図：「点」と「線」での人材評価イメージ

「非エンジニアの分散処理戦力化」のまとめ

LiBにおける「分散化させたエンジニアの仕事を担える人材」について、

• 4つのスキルを求めていること

• それらのスキルを持つ人をPdMと呼んでいること

• PdM育成に4つの資源を確保していること

の3観点で紹介してきました。

実は、LiB内の職種名・部署名に「プロダクトマネージャー」「プロダクトマネジメント」という単語が入ったのはつい最近です。もちろん、それ以前も「他社ではPdMの仕事だと言われるようなことをやっている人」はいましたが、「LiBにおけるPdM」のレベル感を正しく設定するために、「世の中標準で見てもPdMと名乗って恥ずかしくない」というレベルになるまで待ちました。

現在LiBには6.5名（0.5は兼務）のPdMと5名のエンジニアが社員として在籍していますが、前編後編通じて本記事に書いたことが絵空事ではないことを日々証明してくれています。中でもPdMは、LiB以外でPdM業務を経験したことがある人は1名のみであり、残りは全員LiBの「砂場」で育った人材です。

「営業会社のIT企業化 - 前編＆後編」のまとめ

本記事は、読者にとって身近な環境と比較することで異なる感想を持たれそう・・・と予想していますが、実際どのように感じられたでしょうか？

最も多いのが 「変わったことやってるな〜」 と思われる方かなと思います（笑）。前編では「弱者の戦略」であると書きましたが、その戦略と会社の経営思想や人材マネジメントポリシーがしっかり噛み合ってきたので、単なる「変わったこと」ではなく、独自性と言えるものになりつつあります。

また、ここで紹介したもののほとんどは、私のオレオレ発明ではなく、自分を育ててもらえた環境のいいとこ取りだったりします。過去経験をふまえ、自分がメンバーとして在籍したい環境を再現するとこうなった、とも言えるので、どこかで繋がりを感じてくださる方がいたらとても嬉しいです。

前編・後編と長文になりましたが、お読みいただきありがとうございました。ここに書かれていることによってLiBのサービスも（よくある転職/採用サービスから）どんどん変わっていくので、少しでもLiBという会社に興味を持っていただければ幸いです。採用情報はこちら。