はじめに
「制約の中で工夫するのが好き」 という気持ちを理解してくださる方はいるでしょうか？
- ファミコン／スーファミ時代のゲームクリエイターが、様々な工夫で子供たちを楽しませる
- 戦力的に劣るスポーツチームが、知恵とチームワークでジャイアントキリングする
- 知名度の高い観光資源を持たない自治体が、B級グルメなどの開発で町おこしをする
などなど、制約の中で工夫している事例を挙げればキリがないですが、私はこういった事例がジャンルを問わず大好物です。
その嗜好が仕事選びにも現れたのか、私自身が経験してきたものづくり環境にも様々な制約が存在していたのですが、それらの制約たちがものづくりを面白くしていたことは疑いようがないと思っています。
そんな私が今株式会社LiBで取り組んでいるのが 「エンジニア採用が困難な営業会社をIT企業化する」 という強烈な制約付きゲームです。なぜそんな変わったことに取り組むことになったのかは過去の記事に委ねるとして、本記事では、「どうやって制約と戦っているのか？」について触れてみたいと思います。
本記事における「エンジニア」は「ソフトウェアエンジニア」「ITエンジニア」のことを指します。
本記事のサマリー
本記事の概要は以下の通りです。
【起】エンジニア採れませんよね
そもそも人材採用全般の難易度が上がっていますが、中でもエンジニア採用は最難関
ここ5年くらいで急激に認知が進んだプロダクトマネージャー（以下PdM）も難関
【承】弊社（株式会社LiB）は特に採れませんでした
事業テーマ、技術セット、人事制度の三重苦で、採用のスタートラインにすら立てない状況
一方で、LiBのミッションは、ITをフル活用した仕組みがなければ実現不可能なもの
なのでエンジニア採用からは逃げられない
【転1】エンジニアの仕事を分散処理することにしました
正社員エンジニアの採用を一旦諦めて、エンジニア業務を徹底分解
分解した各要素を担ってもらえる人をコツコツ集めて、ソフトウェア開発がスムーズに回る仕組みを構築
【転2】分散処理要員にPdMを活かすことにしました
分散処理するだけでは結局エンジニア不足に陥るので、PdMを開発戦力として活かすことに
未経験からPdMが育つ仕組みを構築し、一般的な企業ではエンジニアが担当している業務すらPdMが担う形に
【結】結構ワークしてる手応えあります
会社の変革（ハードシングス）期にコソコソコツコツ仕込んできた（＝時間かけた）ことの芽が出てきた
この環境を使い倒して、個人と企業の行動変容を促す仕組みを作ってみたいエンジニア＆PdM募集
上記のような内容なので、想定している読者は、ものづくり経験のある方やエンジニア／PdM／デザイナーといったものづくりを担う職種と関わりを持つことがある方となります。
なお、 基本的に「弱者の戦略」に相当する話 なので、エンジニア不足で困っている会社の方には参考になるかもしれませんが、エンジニアが豊富にいる会社の方にはオススメしません。
大ソフトウェア時代における定説
20世紀終盤からは「世はまさに、大ソフトウェア時代！」ですが、そんな時代に色んな船に乗って旅をしてきたことで、様々な経験をすることができました。
そこで教えてもらったり、試してみたり、成功したり、失敗したりして得た「定説」と呼べることの多くが、本記事で紹介する取り組みの思想的土台となっています。以下、同時代の航海者には当たり前過ぎる話ですが、本記事に関係するものを列挙してみます。
見てる人が考えるべき
- ユーザーをちゃんと見てる人が何を作るか考えたほうが良い
- 価値提供者と受益者の距離は近いほうが良い（D2Cやノーコードの流れ）
- 全く見てない「偉い人」の思いつきは大体失敗する
考えてる人が作るべき
- 伝言ゲームはしないほうが良い
- 役職者→企画者→社内エンジニア→SIer窓口→SIer実装リーダー→二次受け実装者、みたいなリレー環境下では良いものづくりは困難（内製化の流れ）
作りながら考えるべき
- モックやプロトタイプはたくさん作ったほうが良い（100の綺麗なトークより1つの粗いプロト）
- 熟考するより、作りながら触りながら触ってもらいながら考えるほうが近道なことも多い
早く出すべき
- アイデアはすぐ試したほうが良い
- 初期仮説は大体外れるので早く気付いたほうが良い
- ユーザーは答えは持ってないが、良し悪し評価はしてくれる
作り続けるべき
- 凡人がプロダクトの一発正解を出すことは不可能
- 「口だけPDCA」ではなく健全なスクラップアンドビルドを
- 屍を活かし、積み上げに使ったほうが良い
ハード化しつつあるソフトウェア
上述の定説とは裏腹に、実世界にはその実行を阻む壁がたくさん存在します。有名なものにメテオフォール型開発における「神」の存在などがありますが、私は エンジニア不足によりソフトウェアがハード化しつつあることが大きな要因を占めている と思っています。
図：ソフトウェア階層図（出典:フリー百科事典『ウィキペディア（Wikipedia）』）
上の図において、2,3階層目が一般的にソフトウェアと呼ばれるレイヤーで、上に行くほど変更が容易である＝柔らかい（ソフト）というのが特徴です。
ところが、「ソフトウェアを本当にソフトに変更できる人」、一般企業でどれくらいいるのでしょうか？
社長が無邪気に変更指示を出してCTOに怒られたり・・・という話は妥当なことも多そうですが、プロダクトチームのメンバーや、実装を担っているエンジニアすら自由に変更できないということもよくあります。
限られたリソースや予算の中でソフトウェアを扱おうとするとどうしてもプロセスやルールが増えていきますし、エンジニア不足ならその貴重な工数の使い道は厳密に管理したくなるのが人情ですが、誰もがPC一つで世の中に価値提供できる時代のソフトウェア開発が「ソフトに」行えなくなりがちなのは残念です。
私は「ソフトウェアはソフトであるべき」という信念の元、できるだけ多くの人が「定説」を遠慮なく実行できる環境を作りたいと考えています。
言うまでもなく、世の全てのソフトウェアに適用できる考えではありません。ハードに近い扱いをすることが重要な業界やサービスも多々あります。
営業会社をIT企業化するための戦略的アプローチ
冒頭に言及した制約を踏まえ、営業会社をIT企業化する。その際、ソフトウェアをちゃんと「ソフト」に扱えるようにすることで、大ソフトウェア時代における定説を実行できる組織にする。
この難しいゴールに対して、LiBでは2つの戦略的アプローチで取り組んでいます。
【戦略その1】エンジニア業務の分散化
【戦略その2】非エンジニアの分散処理戦力化
それぞれ詳しく説明していきます。
【戦略その1】エンジニア業務の分散化
LiBではエンジニア業務に対して5つの分散化を行っているので、その狙いや効果を1つずつ紹介してみようと思います。
なお、ここで言う「分散化」とは特に専門的な意味ではなく、辞書通り
分散させること、一箇所に集中していない状態にすること、適度にばらつきのある状態にすること、などの意味で使われる表現。
出典：Weblio/ 実用日本語表現辞典
という意味です。
①参画形態の分散化 - 手が届かないものはレンタルで
私がLiBにジョインしたのは2018年10月の「beforeコロナ」時代なので、従業員はオフィス出社必須でした。それに加え、事業テーマ的にも給与水準的にも労働条件的にも、エンジニア採用には極めて厳しい状況だったので、正社員採用は時期尚早だとすぐ諦めました。
一方で、しっかりしたエンジニアリングチームを作らないことには永遠にその状況を脱出できないので、まずはフルリモートの業務委託メンバーでチームを組成していきました。その際、
- 確保できる稼働時間よりスキルを優先すること（例：週5稼働のジュニアより週3稼働のシニア）
- 社員の給与とはギャップがあっても、できる限り能力に見合った報酬を支払うこと（業務委託＝変動費ということで社内も説得）
- 実力発揮してもらいやすいプロセスを整えること（例：柔軟な業務量調整、ミーティングの最小化、月一のフィードバックサイクルなど）
などなどを意識しました。（あらためて書き出してみると普通のことばかりですが・・・）
その結果、多くの「プロフェッショナル」と呼べる社外協力者の方々に集まっていただくことができ、安定して基盤システム開発を進めることができました。システムやチームの基盤ができてしまえば、そこに少しずつ育成対象となるメンバーも足していくことができるので、採用の選択肢も少しずつ増やしていきました。
初期のうちにフルリモート前提の開発チームを作ってしまったことで、コロナ禍でもノーダメージ、採用再開時も居住地を無視した採用ができたので、非常に効果的でした。
②要求スキルの分散化 - 何でもかんでも求めない
とあるスタートアップでの会話：
役員：「うちもそろそろエンジニア採用強化する必要があるな・・・」
人事：「どんな条件で探せばいいですか？」
役員：「とりあえずフルスタックエンジニアやろ」
人事：「具体的にどんなことができる人ですか？」
役員：「iOS/Android向けアプリ開発できて、サーバー/インフラも一通り触れることは必須やな。チームマネジメントも任せたい。年齢は30前半までで、うちのビジョン・ミッション共感は外せへん。年俸は800万まで出したるわ！」
こうして各種転職サイトに「フルスタックエンジニア募集！」という求人が乱立している日本。これはもはや 「大谷翔平みたいな野球選手採ってこい」という指示に近いような気がしますが、実際どれくらいの企業が希望した「フルスタックエンジニア」を採用できているんでしょうか。
少なくともLiBではそういう人材捜索が（参画形態を分散化しても）成功する確率はゼロに近かったので、何を求めて何を求めないかをはっきりさせることを徹底しました。言語やフレームワークを絞ることはもちろん、それぞれが得意領域の実装に集中できるよう、調整系の面倒なタスクはお願いせず、何のために何を実装するのかを極力明確にした上でタスクアサインすることも重要です。
最近は少し余裕が出てきたので、社員エンジニアは意識して未経験領域も担当し、より守備範囲の広いエンジニアを目指すようにしていますが、採用活動時に「大谷探し」をしないことは常に意識しています。
③マスターデータの分散化 - 何度変えても怒られない
サービスを運用しながら調整したくなるような文言・設定系データはシステム内に混ぜないこと。システム開発の教科書にも出てくるような基本ですが、実際に「サービスを運用しながら調整」したくなった場合には、都度エンジニアにお願いして変更＆リリースしてもらっているケースも多いのではないでしょうか。
LiBのシステムでは、マスターデータをシステムとは独立して管理することを徹底しており、適切な単位のJSONファイル（w/ それを自動生成するツール）として分散管理しています。
これにより、PdMはエンジニアに遠慮することなくガンガン改善プロセスを回すことができます。 逆にエンジニアは、「◯◯の文言変えてください」「◯◯の選択肢増やしてください」「◯◯のデータも保存できるようにしてください」といった単純変更作業から解放されることができます。（書き始めると単体で記事になるボリュームなので、詳細は割愛します）
④新規開発業務の分散化 - 健全なスクラップアンドビルドを
「PDCAを回せ」とよく言われますが、ソフトウェア開発が絡む環境でPDCAを行おうとすると、下図のようなあるあるが発生しがちです。
図：PDCAの現実（LiBの採用資料より抜粋）
お手本がないUXを実現する場合には、健全なスクラップアンドビルドを繰り返すことが必要。一方で、無邪気にスクラップアンドビルドを繰り返すと貴重なエンジニアの工数が浪費されてしまう。このジレンマに向き合うためには、下図ような状態を実現することが必要であると考えています。
図：PDCAの理想（LiBの採用資料より抜粋）
この状態を実現するために、LiBの基盤システムには、いわゆるノーコードで様々な画面・機能の実装が可能になる仕組みが用意されており、PdMを始めとする非エンジニアが思う存分スクラップアンドビルドを繰り返しています。（こちらも単体記事ネタなので、詳細は割愛します）
また、社内インフラであるGoogle Workspace環境を活用したスプレッドシート駆動開発というアプローチも行っています。これは、
-
開発要望が出てもいきなりシステム実装はせず、MVCアーキテクチャのModel部分だけシステムを用い、Viewをスプレッドシートで、ControllerをGoogle App Script（GAS）でサクッと実装してしまう
-
スプレッドシート x GAS ベースのシステムを実際に使って、日々ちょこちょこいじりながら、仕様を固めていく（この際、スプレッドシートのUIは利用者である非エンジニアが自分でいじれるため、無駄な伝言ゲームが発生しない）
-
継続して利用されるツールになり、仕様も揺れない状態になり、かつシステム実装する必要性（例：パフォーマンスなど）が明確になったら、初めてシステム実装する
というやり方で、社内メンバーがユーザーとなるシステムはほぼこのアプローチで実装しています。
⑤最終成果物担当の分散化 - 今日からあなたも最後の砦
前項でノーコード開発環境について触れましたが、その環境はもう1つ別の分散化にも寄与しています。それは、プロダクト開発の最終成果物（ユーザーが直接触れるもの）の担当を分散＝分担できることです。
自分で作ったものが最終成果物になるというのは非常に大きなことで、
- 適切な品質でリリースするためのテスト
- 本番で問題が発生した場合の一次解析
- ミス（バグ）を生みにくくする工夫
などなど、唯一の最終成果物担当になりがちなエンジニアしか経験できないことを誰もが経験できるようになります。
「運用時のバグ対応で開発に集中できない！」というのはエンジニアの嘆きあるあるですが、この分散化により運用時の負担も分散し、開発に集中できるようになっています。
また、自分で問題の解析＆修正をするようになると、報告される側の気持ちもわかるようになり、エンジニアに何か報告する際の伝達力も向上し、エンジニアの翻訳業務負荷が下がるという副産物も得られています。
「エンジニア業務の分散化」のまとめ
エンジニア業務の分散化というテーマで5つの工夫を紹介しましたが、これは、
①参画形態の分散化
②要求スキルの分散化
によって組成したチームによって、
③マスターデータの分散化
④新規開発業務の分散化
⑤最終成果物担当の分散化
が実現可能な環境＝フレームワークを実現することであると言えます。
③④⑤の構成を簡単な図にすると以下のような感じです。
図：単純化したアーキテクチャ図
これは、冒頭で引用した
の図における、オペレーティングシステムに相当するものがAPIとDB、アプリケーションレイヤーに相当するものが3種類存在する、と捉えることも可能です。
なお、冒頭でも言及した通り、本戦略は基本的に弱者の戦略なので、それぞれのデメリットを受け入れるのは当然のことです。
①参画形態の分散化
→「今すぐこれ変えて！」みたいな依頼は基本的にできない
②要求スキルの分散化
→全体最適判断できる人がおらず、各自の視野が狭いと不毛なことが起きる
③マスターデータの分散化
→品質の低いデータが紛れ込んでしまい、データ負債が生まれる
④新規開発業務の分散化
→雑なプロトタイプがボトルネックになる（すぐ直せない、動かなくなった、などなど）
⑤最終成果物担当の分散化
→インターフェースをうまく切らないと、一人で解決できないことが増えてしまう
これらのデメリットを最小化することも、また面白い工夫ポイントではあるんですが、一番難しいのは**③④⑤でエンジニアから切り離した仕事を担う人をどう揃えるか、**ということです。
これが 【戦略その2】として言及した「非エンジニアの分散処理戦力化」で紹介したい内容なのですが、慣れない長文作成でHPが尽きてしまったので、後編に続く・・・とさせてください。
ここまで読んでくださった方、本当にありがとうございました。同じような環境で奮闘されている方がいたら、ぜひ情報交換しましょう。また、株式会社LiBに興味を持ってくださった方はこちらの採用情報もぜひ！