エンジニア組織がない会社でエンジニア組織を立ち上げるためにやった3つのこと

LITALICO CTOの岸田崇志(@takish)です。
2017年のアドベントカレンダーもついに最終日となりました。

入社して2年経ち、エンジニアも順調に人数が増え、新卒採用からの育成、そして新規事業ラインへのエンジニアラインがスケールアウトできるようになってきました。

特に前職ではインターネット事業の急激な成長を経験したので、エンジニア育成サイクルの礎を築いて置くことの重要性は身にしみて感じていたので、最初からそれを念頭に組織を組み立てています。

はじめに

筆者はエンジニア組織の立ち上げは3回目なので「デジャヴ？！」と感じる事も多々あり（笑）、既視感ありまくりの2年でした。

一方で既視感があるということは、どこも成長のフェーズにおいて同じ課題に直面するということでもあるという事でもあります。
そのため、そのような経験を基に過去失敗した轍をもう一度踏まないことを心がけました。

成長フェーズでは自転車操業的になりがちですが、継続的に成長することが会社の価値だと思っていますので、場当たり的な対応とせず「仕組み」を作るための根気強さが必要な2年でした。

前職で経験したフェーズ

• 自分の管轄する組織だけで10名くらいから250名くらいまで拡大したフェーズ
  • 全社だと100名から2400名まで急拡大したフェーズ
• プロダクトラインはMax11ライン

急激な成長を経験させて頂いたことはとても貴重でした。**人生最大の学びの場でした。**自分の未熟さ故ご迷惑をおかけした方もあると思います。ですので、その経験を社会に還元することができればと思っています。
前職でも後半は組織開発で貢献させていただきましたが、一連を通しその中でこうすればよかったなと思うことを再度別の会社で実践している事例になります。

前職で学んだこと

• 会社の成長時系列に沿ったチームの構成・計画の必要性
  • 立ち上げ期・安定期・成熟期などフェーズごとでの任せていく範囲の拡縮
  • 壊すことと守ることの塩梅。守り過ぎも壊し過ぎもよくない
• 間違った軌道修正
  • ベタだけど人月の神話的な話。遅れが発生した時に人を足すという解決はよく見かけます。不思議とどこでも起こりがちなのであえて挙げておく。早く産まれて欲しいからって母親を1人足しても子供は5ヶ月で産まれてこない
  • チーム全体の開発力の足りないところの見極め方、そこの成長のさせ方の重要性。足りないところを見極めてチームの実力を高める事がプロダクトクオリティとスピードを上げる近道。次にもつながる。
• エンジニアの自主性と裁量の幅を適切にもたせる必要性
  • 技術選定と幅を狭めたことによる事業の打ち手の遅れ
  • エンジニアが個々の能力を最大化し活躍しやすい場をつくり切れなかった
  • 成長の頭打ちによる離職リスク。中長期で見るとボディーブローのように効く
• 採用後の立ち上げフェーズの重要性
  • 育成プロセスを整えていなく、立ち上げフェーズからコア人材が必要なときに足りなかったことの後悔
  • 人材不足を採用「だけ」で解決する発想では採用限界がくる
    • 入社時のスキル評価で満足するのではなく入社後にスキルが伸びる環境の必要性
• その他、たくさん…

これらを通して学んだのは、ビジョナリーカンパニーに書いてある**「時を告げるのではなく、時計をつくる」**という言葉の重要性です。（初め読んだ時は言葉の上っ面しか理解してなかった事を時につれ実践するにつれ感じます。）

本エントリではその観点にたって、場当たり的な対応ではなく、エンジニアの採用から育成、事業ラインのスケールアウトまで数年先を見越したサイクルをどう作るかという話となります。

LITALICOって？

LITALICOは主な事業はインターネット事業では無く、就労支援事業などを中心としたリアルビジネスの会社です。

世の中全般を見渡しても、
「インターネットのみのビジネス」
から EdTech / HRTech / FinTech / HelthTech / AgriTech… など X-Tech系の
「リアルとネットを融合したビジネス」

へのシフトが進みつつある時代だと思っています。

このような領域のもともとリアルビジネスを営む会社はネットと融合することで価値を多くの人に届けることができるようになります。
一方で、既存事業とエンジニアリングの融合はなかなか難しい問題です。
そのようなリアルビジネスを営んでいる会社で今後エンジニア組織を立ち上げたいと思っている方の参考となればと思います。

入社したときの状況

（インターネット事業に絞って記載）

• メンバー
  • エンジニア新卒1年目から4年目
  • 新卒を中心とした組織で開発経験が浅い方が多い
  • 中途エンジニア数名
  • 人数は10名弱
  • エンジニアマネージャー不在
• 開発ライン（2年前）
  • ほぼ1ライン
    • 明確に分離しておらず兼務状態が多い。特定の人に集中的に負荷。そのため、新規サービスの立ち上げが生じたときにラインとして分割が難しい
    • 技術的ストレッチがなく中途社員を採用しても手が余る
    • 新人のフォロー環境が手薄
• 社内環境
  • 一方で、主事業の方は社員は1000人を超しニーズは多く要望も様々
    • 社会課題は無数にあるので作りたいものがたくさんある
      • 今回は触れませんがやるべきことのトリアージなども工夫しました
  • 開発すべきものの時間コスト管理と金銭コスト管理がうまくできていない
    • 理想像、期間コスト、それを作るための技術スタック・育成像がなくだいたい気合いソリューション
    • 事業として成功する前に経験の浅いチームは「作り切る」も大事なスキル
      • 延々と開発が続くなどもあったように思います

そこで心がけたこと

• 育成環境や育成サイクルの構築
• 組織全体の開発力の向上
• 技術的チャレンジができる環境

一重に育成・開発力の向上といってもいろいろあります。
リアルビジネスでやっている強みを活かすためにも、ユーザーさんに届けたい価値を実現するために、下記の図のようにアイデアと企画・実装の「ギャップ」をチームや個で小さくするための環境構築を行いました。

エンジニア採用での課題感

エンジニア採用で難しいのが、カルチャーマッチングとスキルマッチングです。
特に福祉領域は双方を満たすエンジニアは非常に少ないです。

両方を満たす人がいればいたに越したことはないですが、
社会課題を解決したいという想いがあるエンジニアを世の中に一人でも増やしたいという思いもあり、組織として何とかしたいとまず思いました。

どのようなきっかけであれ教育・福祉領域に興味を持ってくれる方がいるのであれば、そこを解決する人を増やすことが会社としてのミッションであると思っています。

ですので、育成環境の構築をはじめに行いました。

将来的にはLITALICOの教室の先生や支援者の方がエンジニアリングをできるようになると業界自体が変わると思いますので、そういったこともできるようになると良いなと思っています。

組織を成長させ続けるための3ステップ

育成のステップの策定においては、組織を成長させ「続ける」仕組みづくりを意識しました。

• 組織のスケールアウトを前もって意識しておく
• エンジニアのスキルやクリエイティビティを最大限に活かしやすい環境を目指す
• エンジニアのマネージャーは、開発マネジメントだけではなくプロダクト全体を責任を持つようにするプロダクトマネージャーとする
  • 受注発注の関係にならないためエンジニアがカバーできる領域を増やす
  • 幅を広げ能動的に動きやすい環境にする
    • プランニング / ワイヤフレーム / 分析 etc.
  • （マネージャーの仕事がただの人月管理になると悲しいですよね）

上手な転び方、失敗の仕方というものが有ると思います。
一回も転ばずにうまくなるということはありません。
柔道の「受け身」のようにチームも個人もフェーズに合わせた上手な転び方を学びながら、少しずつ大きなチャレンジができるような環境の構築を目指しています。

そこでまず定めたゴール

• 小さな失敗を積み上げながら成長できる環境を作ること
  • 研修・メンタリング・プロダクトマネジメントそれぞれの中で異なるプロセスでも一貫したコンセプトを学び続けスケールアウト感を養うこと
  • 失敗を成長につなげ続けられる仕組み
• 経験が浅くても独り立ちできる環境を作ること
  • メンターによるフォロー環境
• エンジニアとして新しいスキルを身に着け続けられる環境を作ること
  • 一つの技術だけでなく複数技術のパイプラインを用意しておく
  • 技術選定をそのチームの力量や事業環境によって選択を任せる
• エンジニアの市場価値を高め続けられる環境を作ること
  • エンジニア「だけ」の仕事ではなくユーザー視点に立ってプロダクト全体を見渡す能力を身につけること

STEP1：エンジニア立ち上げ編

育成環境の構築

• 「まずは」育成体制と事業を分離する
  • 育成と事業を分ける重点的育成の重要性
    • 割りとスタートアップに多いのですが、「いきなり現場で活躍できます！」という謳い文句で新人を放置プレーしても成長できる人と成長できない人に分かれます。
  • 修羅場成長できる人は一定いますが、そういう人はもともとデキる人なので、それだけでは組織としては不十分です
  • 修羅場成長できない人も引き上げてあげる「仕組み」を用意してあげることが重要で、それが組織としての役割です。

• 成長はメンターによるところが大きい
  • 私の経験上なのですが、特に新卒の成長においてはメンターの影響が大きいと思います
  • 何が足りなくて、次にどうしたらよいかを示してもらうことはエンジニア初級者には大事です
  • レビューや一歩ずつの前進感、軌道修正ははじめはとても意味があります

ホーミングミサイル形式メンタリング

• 手とり足取りではなく、マイルストンを設定し、そこに至るプロセスを育成することが大事です。
• 以下の図のように、学習は学びと迷いの繰り返し、迷ったときに軌道修正して上げる役割をメンターが果たします。ホーミングミサイルのガイドのような役割です。

メンターとの目標設定

ゴール地点をメンターとメンバーで話します。
メンターがホーミング役として、次の目標地点を定めます。

今年のLITALICO AdventCalenarでメンバー視点とメンター視点でそれぞれ書いてくれているので、見てみてもらえればと思います。

• メンバー視点
  エンジニアになりたいプログラミング初心者文系大学生にとって最も大切なこと

• メンター視点
  ペアプロ懐疑派だった僕が、実務でペアプロ導入して180度考えが変わった話

STEP2：育成環境の循環編

実はここから先が本番です。
研修を行うメンター自身も以下の3点においていい学びの機会になります。

• 教える事によるさらなる技術理解
• メンバーの特性を見ながら教えることでチームプレイ力が上がる
• 1人だけじゃなく2人でゴールに向かう経験をする

ホーミング役をやりながら自分もミサイル役をやるわけです。

メンターも将来のプロダクトマネージャー候補なのです。
一般的にエンジニアの"組織"マネージャーとなるとネガティブな印象を持ちがちですが、チームでプロダクトを作っている過程の中では"マネジメント"要素は大小あれどみんな実はやっているのです。

みんなで力を合わせてプロダクトを成功させることの喜びは格別だったりします。それが、チームでプロダクトを作る楽しみなんだと思います。

ポジションとしてのマネジメントとプロダクトマネジメントは似て非なるものですが、良いプロダクトを作る上でのチームプレイは本質的にはとても楽しいはずのものです。
ですので、教えながら導くというものは教える側の経験としても重要な場所だと考えています。
そのような"プチ"マネジメントをこのプロセスで経験してもらっています。

普通は育成だけで終わるところですが、学びの連続性を持たせているこのSTEP2が工夫をしているポイントです。

こうすることで、以下の図のように「個」だけの育成ではなく、「ユニット」としての育成が合わせて行えることを行います。
一枚岩のチームではなくユニット単位で、チームを組めることで以下のようなメリットもでます。

• 少人数でのスピード感
• 意思決定の速さ
• 企画から実装まで「チーム」として責任をもてる
• 各々の判断で状況に合わせて技術採用判断ができる

少数精鋭のユニットを育成することで、エンジニアの裁量が増えやりたいことができ、結果クオリティとスピードが上がります。

まとめると、

• 育成環境を作る
• メンターはポインタを示す
  • HOWだけじゃなくて、プロセスの中で学びにつなげる
• メンター自体も教えることによって学ぶ
  • 教えることで理解できてなかったことへの気付き
  • 人への伝え方やレビューの仕方を学ぶ
• メンターと新入社員がよいパートナーとなる
  • 個での働き方だけでなく、信頼できる仲間を育成プロセスを通じて増やす

STEP3：プロダクトマネージャー編

この写真を見てください。
いわゆる団子サッカーですね。

こどもがやるととてもほほえましいですが、プロダクト開発において実際に似た光景を見ることが多いです。
ぶっちゃけ笑えません（笑）

そこで必要なのがプロダクトマネージャーです。
そのため、LITALICOプロダクトマネージャーの育成に力を入れています。（当然これ限りではないですが）

プロダクトマネージャーに求められるもの

• プロダクトの成長ストーリを描き、チーム全体を同じ方向に導き、伝えること
• 定量面と定性面でプロダクトに対して責任をもつこと
• 世の中に価値あるサービスを提供すること

そのためにやったこと

• 共通言語を作る
• つくるものベースで会話をするためにエンジニア全員にsketchを覚えてもらいました。
• 必ずしもSketchではなくてもよいですが、手書きでもお互いのアウトプットを揃える作業を冒頭にやることが重要です
• 職掌関係なくSketchを共通言語とすることで開発の手戻りも減り、ユーザー視点でのコミュニケーションが促進されます。
• 社内受託のようになっていてはもったいないのであくまでもプロダクト（実物をみて話す）環境をつくることが優先です。
• プランナーから企画が上がってないから作れない、ワイヤーが無いから実装できないなど。「待ち」状態を減らすことが開発のスピードアップや社内受託状態を減らすことができます。
• モックベースでの開発
• そもそも「無い」ものを作るわけですから一刻もはやく「ある」状態にして「ある」ものベースから会話をしてくほうがゴールに近くなれます。
• これで養うのはHowよりも何を目的としてプロダクトに向かうかという視点を養えます。

次にやったこと

プロダクトマネージャーは、文字通りプロダクトをマネジメントする役割ではなく、「実現したいゴールを設定し、ストーリーを作る」ことが再重要です。

• 達成すべきゴールから考える

• まず達成したいゴール像を定義します。

• ゴールをブレイクダウンする

• チームごとに月か四半期で実現可能な目標に解釈し直します。

• ブレイクダウンしたものをストーリとして伝える

• ブレイクダウンしたものをそのままチームに伝えるのではなく。「何が実現できて、その後どうなるのか？」をストーリとして伝える事が重要です。

• 達成した姿をみんなの共有イメージにしてワクワクさせる

• モックやモノだけじゃなく将来のイメージについても同じイメージを持つことでより強固に同じ方向を向くことができます。

ホーミングミサイル形式プロダクトマネジメント

ホーミングミサイルのスタイルは個人のときと基本同じで、チームになったときは**チーム全体の「学び」**になります。
メンターとして教えていた経験が今度はチームに対しても同じプロセスで導く役割を果たせます。

ここでのポイントは今までプロセス自体は研修からメンターでやってきたことと基本変わらず適用範囲が広がっただけという事です。

チームとなることで、前述したゴール設定からのストーリーがホーミングミサイルとしてのガイドとして有効に働くのです。

Howについてはいろいろあり、実際はプロダクト毎にグロース設計や分析すべきケースは異なるためここでは割愛します。ご相談頂くか去年の記事をごらんください。

• サービス開発は9割が失敗する - 6つの診断パターンからみるサービス設計がうまくなるコツ（前編）
• [サービス開発は9割が失敗する - 6つの診断パターンからみるサービス設計がうまくなるコツ（後編）]
  (http://asagao.hatenablog.jp/entry/2016/12/06/170000)

中心にいる人がいないと特定の課題に全人員が集中したり、3ヶ月先の計画が立っていないことが起きたりします。

今プロダクトラインが4ラインになってきましたので、新規サービス開発へのスピード感を損なわないようプロダクトマネージャー体制へのシフトを進めています。

エンジニアをエンジニアリングのみとする時代は徐々に変わってきているのかなと思っています。
当然個々のスペシャリストは重要なのですが、いろいろな技術がオープン化され簡易に使いやすくなってきているので
いかにどう組み合わせてユーザーにとどけられるかが重要になってきていると思っています。
（私自身元々はネットワークエンジニアだったのですが、それだけで生きていた場合は仕事の幅は昔と比べて減ったと思っています）

日本のエンジニアにおける環境が良くないのは、プロダクトマネージャー不足というものもあると思っています。
個々のエンジニアのスペシャリティを活かすためにも、価値のあるところにエンジニアの時間を割くという役割を采配するひとがまだまだ不足しています。

• エンジニアの役割は時代とともに変わり、どうプロダクトを実現するか？が求められている
• エンジニア = エンジニアリングのみだけでなくプロダクト全体に責任をもつようにする

という時代に進化しないと行けないのかもしれません。

そして現在

あれやこれやありましたが、あっという間に二年が経ったという印象です。

• 現在
  • ライン数
    • 4.5ラインと分離でき、それぞれが自律的に運営できる状態
  • 技術
    • 技術領域もWebからNativeApp、知育アプリなど多様
  • 共通基盤系など重点的にやったほうが良いものはゆるくつながっている状態

組織が大きくなる中で、特定の人に依存しすぎるとスピード感も落ちますし、事業ライン数もスケールしません。
とはいえ、システム化しすぎると個人が生きてきません。

組織の成長の中で「属人化」がよくないとか、「システム化しすぎた先に訪れる大企業病」だとかをよく聞きますよね。これはどちらもよくないです。

自分のチャレンジとしては、エンジニアの強みが活かせるようシステム化しすぎない一定属人化を残した形での疎結合型組織を目指しています。

現在は、以下の図のように

• メディア
• 知育アプリ
• インタラクティブアプリ

など複数の多様なサービスが作れるような組織となることができました。
来年以降も複数のサービスを出していければと思っています。

さいごに

事業は指数関数的に成長することはありますが、人と組織の育成は必ずしもそうならないケースが多いです。

特にネットサービスは指数関数的な成長を期待して立ち上がるケースが多いです。
事業成長と育成にギャップが大きく生じないように、メンバーを育成しておくことがとても重要だと思っています。

ですので、組織として今後事業成長を担保するために育成環境の構築はとても重要です。
育成環境をはじめに構築しておくことで、採用の幅も広がり、結果多様なエンジニアが活躍できる環境を作ることができます。

また、育成環境の構築と一重にいっても将来的に起こりうるギャップを埋めるためには、戦略的な人員の育成が求められます。

人の採用から、育成、配置、事業成長までの一環の流れを兵站として私は捉えています。

兵站とは、孫子の兵法によると、以下のような記述があります。

孫子曰く、凡そ用兵の法は、馳車千駆、革車千乗、帯甲十万。 千里にして糧を送れば、則ち、内外の費、賓客の用、膠漆の材、車甲の奉、日に千金を費やして、然る後に十万の師、挙がる。

こちらは戦いにおいて最前線だけに目が行きがちですが、それだけではなくは兵站の重要性を説いています。

私は現代の組織において、以下のように解釈をしています。

事を起こすときにはその場での配置だけやれば良いわけでなく、メンバーの育成計画から配置および環境構築の計画も含めて初めて新規事業が起こせます。

故に、戦略を実行するためには兵站が重要となります。

ここでいう兵站とは、
エンジニアの育成、配置、ミッション定義
そして、個だけではなくユニットとしての育成が重要です。

LITALICOのようにリアルビジネスをやっていてエンジニア組織を立ち上げたいと思う企業や、スタートアップから拡大期のエンジニア組織の立ち上げで参考となればと思います。

以上、@takish (twitter, facebook)でした！
メリークリスマス！