【イベントレポート】エンジニア組織の作り方 ―LIFULLに学ぶ、内製型エンジニア組織を成長させる3つのポイント―
23,000名(※2023年10月末時点)のプロの経験・知見を複数の企業でシェアし、経営課題を解決するプロシェアリングサービスを運営する当社では、毎月10回程度のウェビナーを開催しております。
2021/11/4回では、エンジニアの採用や組織定着で苦戦している企業担当者の皆様に向けて
LIFULLに新卒で入社し同社初のCTOとしてエンジニア組織の拡大に貢献してきた長沢氏に、エンジニアの採用から組織強化において日々心がけているポイントを自身の失敗経験からの学びも含めご紹介いただきました。
「DXの実行フェーズにいるが、エンジニア採用に苦戦している」
「せっかく採用したエンジニアの定着率が悪く、何をすべきかわからない」
こうしたお悩みを持つご担当者様はぜひご覧ください。
当日参加できなかった方、もう一度内容を振り返りたい方のために内容をまとめましたので、ご参考になれば幸いです。
長沢 翼氏
株式会社LIFULL 執行役員CTO
2008年新卒入社。「LIFULL HOME’S」のフロント、サーバーサイド、ネイティブアプリなどアプリケーション開発に従事した後、バックエンド・インフラ系を担当。API基盤の刷新、事業系システムのAWSへの移行チームを責任者として牽引。2017年CTO就任。同年に社内情報システムの担当部長も兼任し、事業系・社内系システム両面で技術戦略の策定し実行。ベトナムの開発子会社の委任代表も努めており、国内外のエンジニア組織の技術力向上及び組織力強化を推進。
村田 拓紀
株式会社サーキュレーション プロシェアリング本部
FLEXY部マネジャー
中古車のマーケットプレイスシェア首位の企業にて拠点責任者、営業戦略策定、メンバーの採用から育成まで幅広く従事。IT企業を経てサーキュレーションに参画。現在はIT戦略における中期ロードマップ策定、IT企画人材育成に向けた技術顧問活用プロジェクトなどDX推進に舵を切る多くの企業を支援。
新井 みゆ
イベント企画・記事編集
新卒で入社した信託銀行では資産管理業務・法人営業・ファンド組成の企画業務に従事。「知のめぐりを良くする」というサーキュレーションのミッションに共感し参画。約1500名のプロ人材の経験知見のアセスメント経験を活かし、サービスブランディング、イベント企画等オンライン/オフラインを融合させた各種マーケティング業務を推進。
※プロフィール情報は2021/11/04時点のものになります。
Contents
DX推進におけるエンジニア組織の必要性とは？
国内大手企業のエンジニア組織内製化が急速に進行
従来、日本企業はシステム開発の7割を外注していたと言われている。しかし現在、国内大手企業は続々とエンジニア組織の内製化を進めている真っ最中だ。実際にエディオンやカインズ、グロービス、セブン&アイグホールディングスなど、事例は枚挙にいとまがない。
その背景にあるのは、DX推進の必要性やビジネスのスピードが速まっていることなどが挙げられる。自社内で開発リソースを確保することで、より柔軟かつスピーディに開発を進行しようというわけだ。
従来の外注システム開発構造ではユーザーニーズに対応できない
柔軟性とスピード――新たな開発ニーズの高まりは、同時に開発構造の変化をも呼んだ。従来の外注システム開発構造といえば、システムの要件定義をきっちりと行い、何を作るかを決定する「ウォーターフォール型」で行われていた。しかし、完璧な要件定義を行うには時間がかかる。構想に数年かかるようなシステムの場合は、完成する頃にはすでにニーズに変化が起きている……という事態になりかねない。
そこで台頭しているのが、UXを重視したアジャイル開発だ。計画から設計、実装、テストまでを小さなサイクルで素早く回し、顧客ニーズにマッチしたシステム開発が求められている。こうした動きは、当然社内なら小回りが利くため実現しやすく、内製化が進む要因の一つといえるだろう。
外注システム開発の50％が失敗する要因は「テクノロジーの理解不足」
以上のような背景に加えて内製化の動きに拍車をかけているのが、外注システム開発の成功率だ。実に50％は失敗すると言われているが、ここで注目したいのはその原因。失敗の理由の多くは、要件定義の不十分さや追加開発作業の発生などだが、その根本にあるのは発注側のITリテラシーやコミュニケーション不足なのだ。
組織を内製化する場合であれば、社内のITリテラシーはより一層、必須のものとなる。またエンジニア組織を内製化するといっても、完全に全てを内製化するのはハードルが高い。部分的に外注を活用するシーンも踏まえて、自社のITリテラシーを向上させていくことが、システム開発成功の鍵を握るといえる。
マクロ環境から見える3つの要因と立ちはだかる課題
ここまでにご紹介したマクロ環境から見える、DXにおけるエンジニア組織の必要性をまとめると以下のようになる。
エンジニア組織内製化において第一の課題となるのが、「エンジニア組織作り」だ。どのような体制で、どのような人物をアサインし、どのような制度のもと人材を評価していけばいいのか。
今回のウェビナーではLIFULLの事例を基に、エンジニア組織のよくある課題やその解決策などを探っていった。
LIFULLの事業を加速させた内製型エンジニアリング組織の概要
新卒から一貫してLIFULLで活躍し続けるCTO長沢氏の経歴
今回、講師としてお越しいただいたLIFULLの長沢氏は、新卒でLIFULLに入社。エンジニアとしてiOSアプリの立ち上げやベトナムの開発子会社の委任代表といった経験を経て、2017年にはCTOに就任。現在に至るまで、事業やエンジニア組織全体の成長を牽引している。
人材の流動性が高いエンジニア業界で、一貫して同じ企業で活躍を続けている長沢氏。その理由については、「組織内で難易度が高く、新鮮な課題に挑み続けられていたことと、提案すれば組織全体を変えるチャンスがあったこと」が要因だったと語る。
事業部制と職能型を交互に繰り返すLIFULLの組織変遷
LIFULLの組織変遷は非常にユニークだ。その特徴は、簡単に言えば組織がその時々で直面した課題やフェーズに応じて、事業部制と職能型で交互に組織編成を変更している点にある。
企業の戦略に合わせて変化する組織とは、果たしてどのようなものなのか。これまで4段階の変遷を遂げてきた背景や課題、対策などについて次の項目から詳しく伺っていく。
LIFULLのエンジニア組織拡大と事業の加速の裏側
マーケットごとに分かれた事業部で部署最適な開発を実施
長沢氏が入社した当初の組織体制は、事業部制が採られていた。LIFULLの代表的なプロダクトである不動産・住宅情報サイト「LIFULL HOME’S」でいうと、賃貸や分譲、中古不動産といったマーケットごとに事業部が存在し、その中に営業やエンジニア、企画職のメンバーが所属していたという。
村田：事業部制を進める中でいくつか問題が発生してきたということですが、スライドにあるシステムの分離や他部署間連携の不足などは想像しやすいですね。技術スタックがバラバラだったというのは、どういうことですか？
長沢：システムの話になってしまいますが、例えば賃貸の事業部はプログラム言語にPHPのバージョン5.2、フレームワークはZendを使っていました。一方、分譲はPHPの4系、フレームワークは自作です。エンジニア同士がコミュニケーションをしたり技術を横断して共有したりできるような仕組みがなかったので、技術スタックがバラバラになっていたのです。
これらの問題を解決すべく、LUFULLは共通基盤の開発を施行。エンジニア組織においてはありがちな「車輪の再発明の防止」も狙いとしてあった。これにより、組織全体として短期的な効率アップを実現したという。
会社として技術を共通化しプロジェクトごとにチームを組成
技術的な共通基盤を構築した上で、組織は事業部制から職能型へと変更された。以下の図にある通り、営業、エンジニア、企画職といった職能別組織内に、サービスごとのチームが組成されているという構造だ。
村田：技術が共通化されたことでナレッジマネジメントができるようになった一方、職能型組織への変更によって技術力の低下が発生したそうですね。
長沢：技術の共通化を進めれば進めるほど、エンジニアが自分で考える幅が狭くなってしまうからです。例えばインフラやサーバーの規格、APIなどの共通システムを規定しすぎると、エンジニアはそれを「使うだけ」になってしまう。そこが技術力低下の原因でした。
村田：結論としては再び事業部制に戻したそうですが、「失いかけていたプロダクトに対する思いの醸成」が対策の目的の一つだったというのは、どういうことですか？
長沢：このときは職能別にした上でプロジェクト制を採っていたのですが、例えばAチームという5人編成のチームがいたとしたら、3ヶ月は賃貸事業のプロジェクト開発をして、その次は分譲事業のプロダクト開発をまた3ヶ月、その次は流通事業……といったように、短期的に違うプロダクトにアサインされます。その結果、どうしてもプロダクトを自分が育て続けているという実感がわかないことが、大きな課題でした。
職種間のつながりを保ったまま事業部制へと回帰、再生
二度目の事業部制への回帰によって職種間のつながりを保ったままの移行が可能となり、当初の事業部制で起きた課題は解決されたかに見えた。しかし、今度は別側面でハレーションが起きる。このフェーズにおける課題は、評価に対する反発だった。簡単にいえば、「エンジニアの上司が企画職」などの場合に、エンジニアの技術が正当に評価されないという状況だ。
また、「大きな変化への対応力低下」も課題だったという。
長沢：事業部制になると、「いかに事業部内に与えられた目標を達成するか」にフォーカスすることになります。その結果、当社が手掛ける「住まい」という大きな領域ではなく、あくまで賃貸や分譲という事業の中で何ができるか、という考えに寄ってしまいがちになりました。
村田：コミットする範囲が絞られてしまったということですね。
これらの課題に対して、LIFULLは社内兼業制度や評価アセスメント、評価テーブルの再構築などを実行。さらに再度職能型組織への移行を決定した。
中長期的な会社全体としての動きにも対応できる組織へと再結合
村田：事業部制のときはどうしても事業部の短期的なゴールがインセンティブとして強く、リファクタリングなどがなかなか実施されなかったということですが、ここは職能型に戻すことで解決されたのでしょうか？
長沢：そうですね。リファクタリングはビジネスに結び付くものなのですが、事業部制の場合はその理由を説明できるエンジニアが所属する事業部が限られていました。職能型にすることで、部の方針としてリファクタリングをやっていくと言えるようになったのは、かなり大きいですね。
リファクタリングとは、表面上のソフトウェアの動作は変えることなく内部構造を整理する作業のことで、「改善」や「メンテナンス」に相当する。
機能追加やリニューアルとは異なり表向きには変化や成果が見えづらい工程ではあるものの、技術負債を解消してシステム上起こり得るリスクを回避するという視点で、リファクタリングはエンジニアにとっては非常に重要な意味を持つ。LIFULLが再び職能型に回帰したのは、中長期的な事業の成長を考慮したものでもあったのだ。
内製型エンジニア組織の作り方と成長させる4つのポイント
事業部制と職能型を必要に応じて採用し、それぞれのメリット・デメリットを体感してきたLIFULL。ここからは、常に最適な組織のあり方を追求してきたからこそ見えてきた、エンジニア組織拡大のための成功ポイントについて教えていただく。
4つのポイントに触れる前に簡単に解説しておきたいのが、そもそもエンジニアが採用できない、あるいは入社しても定着率が悪い組織にどのような特徴があるのかという点だ。
これはそのまま、エンジニア組織を拡大させるポイントへとつながるものでもある。
それぞれのポイントがなぜ重要で、どのような組織にしていけばエンジニアが定着してくれるのか。一つひとつ伺った。
最も重要なのはエンジニアが共感できる「ビジョン浸透」
まず、4つのポイントの中でも最も重視すべきはビジョン浸透であると長沢氏。
村田：エンジニアとビジョンは遠いとイメージしている人も多そうですが、ここは重要なのでしょうか？
長沢：もちろんエンジニアといってもいろいろな人がいますから全員に当てはまるわけではありませんが、エンジニアというものは基本的に問題解決が好きです。その上で、自分の開発したプロダクトやサービスがどうユーザーに使われて喜んでもらっているのか。ここに共感できると単純にうれしいですよね。ですからビジョンは大事です。
実際、LIFULLでは経営層からのメッセージ発信や、事業部単位、チーム単位でビジョンについて策定するワークショップなどを実施。さらにエンジニアの採用自体も、ビジョンフィットを最も重要な基準としている。
その中でも特筆すべきは、LIFULLがビジョン浸透のための取り組みに使っているリソースだ。大体全体として、5％程度は割いているという。
長沢：当社は設立当初からビジョンを重視して、浸透のために時間を割いてきました。ビジョン浸透を行うためだけに存在する、20名程度の「ビジョン委員会」というものもあります。例えば各チームがビジョンを策定する際のサポートをしたり、メンバーがどのように業務にビジョンを活かしているのかを社内報で発信したりするなど、さまざまな取り組みを行っていますね。
経験と失敗によってエンジニアの成長を促す挑戦機会の提供
長沢氏自身がLIFULLに長く在籍している理由として、「さまざまな挑戦機会があったこと」を挙げていたように、エンジニアに対して多くの経験や失敗ができる成長機会を与えることも重要だ。
村田：これは権限委譲にも近い話だと思うのですが、LIFULLさんの中ではどのような形で成長機会を与え、権限委譲をしているのでしょうか？
長沢：基本的に、「挑戦をしよう」という社風があります。そして、失敗をした人を笑わない、罰さない文化も根付いている。その上でダイナミックに権限委譲をして、若手でもいろいろやってもらおうという風潮がありますね。
もちろん問題が起きたら困るので、最低限のセーフティネットは用意しています。例えばシステムのレビューはきちんと知見のある人がやる、品質保証は横断部門が担当するといったことです。
そのほか、新規プロジェクトの社内公募を実施、取り組みを行った上で、ある程度軌道に乗れば参画メンバーを中心に組織化も可能とするなど、新規事業を起こしやすい環境も整えているという。実際に長沢氏が過去に手掛けたiOS開発プロジェクトも、公募によってメンバーを集めて推進された。
エンジニアの特性を理解したスキルと評価の透明性
ビジネスサイドにとってはなかなか理解が難しい技術を扱うエンジニアだからこそ、正当な評価を受けられるような制度作りも大きなポイントとなる。LIFULLの場合は職種とそのグレード（等級）ごとに必要なスキルマップを明確に定義。さらに全社員に向けて給与テーブルを公開するなど、どんな職種でどのようなスキルを磨けばどのような待遇になるのかを、かなり透明性の高い形で定めている。
村田：エンジニアの評価ポイントとして「売上」を設定するのはなかなか難しいので、ミッションごとにKPIのようなものを設定するのが大事なのでしょうか？
長沢：もちろん売上を評価軸として持てる人もいるとは思いますが、エンジニアはその手前、いかにしてプロダクトを開発できたのかという軸で評価する必要があります。そうでないと、素晴らしいプログラマーが素晴らしいプロダクトを作っても市況によって売れない場合に、評価をされず退職してしまうからです。
建設的に協力し合えるような会社におけるエンジニアのポジション
最後のポイントが、会社におけるエンジニアのポジション――いわば、エンジニアの存在意義をきちんと経営陣やビジネスサイドが理解をすることだ。
村田：少し難しい概念かもしれませんが、どうしてもエンジニアがコストセンターとして扱われているケースが多いのかなと思います。きちんとビジネスサイドとエンジニアが建設的意見交換をできるような協力関係を築くことが大事ですよね。
とはいえ、やはりエンジニアとはなかなか理解し合えないと感じる場合もあると思います。エンジニアとビジネスサイドが上手くやっていくためのコツはあるのでしょうか？
長沢：理解し合えない部分は一定あると思いますが、会社として同じビジョン、解決したい問題に向き合っているという意味では、エンジニアも同じです。ただその手段や文化、コミュニケーション方法が違うというだけなので、やはりまずは同じ仲間だと認識することですね。
例えばエンジニアには「ミーティングよりチャット」で、やり取りをテキストで残す文化があります。そういった違いを理解しながら、コミュニケーションを取ることが大事なのではないでしょうか。
エンジニア組織の作り方まとめ
今回のウェビナーのポイントを、「すぐに取り組んでいただきたいこと」として以下の3点にまとめた。
特に「信頼できる一人目のエンジニアを見つける」という点について、長沢氏は以下のように述べる。
長沢：何より大事にしてほしいのが、会社のビジョンや理念、目指す方向がCEOと合うかどうかです。一方で、エンジニアの技術レベルを一般の人が測るのは難しいこと。その場合は外部の専門家に協力してもらいながら「最初の一人目」を見つけていくと、信頼性が上がると思います。
また、「エンジニアに対するスタンスの明確化」という意味では、「経営陣全員が同じ言葉でエンジニアという存在の大切さ、魅力を語れるようにすることがポイント」と長沢氏。
エンジニアとどのように協力し合いながら、事業にどんなインパクトを出したいのか。エンジニア組織を作る際は、ここを定めることからスタートすべきなのかもしれない。
今回ご紹介したウェビナーで使用した資料は、未公開部分も含め以下のリンクからDLできます。エンジニア組織の作り方にご興味を持たれた方は、ぜひご活用ください。
エンジニア組織の作り方 ―LIFULLに学ぶ、内製型エンジニア組織を成長させる3つのポイント―
