6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

※この記事は、経営者・CxO・マネージャー・テックリードを目指している方向けの記事です。

自己紹介

本記事では、私が「よりそう(旧:みんれび)」に入社してから、CTOとして約3年間にわたり取り組んだ組織・技術基盤変革を紹介します。戦略立案から新技術基盤の構想、文化醸成、そして開発生産性を5倍に引き上げるまでのプロセスをまとめました。この記事が、今後同じような課題に直面する方々の一助となれば幸いです。

開発スループット500%達成までの推移
image.png

image.png

はじめに

2022年1月、私はよりそうにCTO候補として参画しました。当時、同社は13年以上にわたる技術的負債や、新規事業・ブランド再編による複雑なプロダクト群、そして退任したシステム責任者の後任不在など、さまざまな課題を抱えていました。
これら技術・組織・経営の三軸で課題解決を進めながら、エンジニアリング組織を変革してきた3年間を振り返りたいと思います。

入社当時の状況と課題

技術的負債の深刻化

長年蓄積された複雑なコードベースは、開発体験(DX:Developer eXperience)を損ね、テストやリリース後対応に多大な労力がかかっていました。テックリードもシステムの全容を把握できておらず、謎のDB負荷や不具合対応が恒常化していたことも深刻な問題でした。

技術的負債ってなに?という方は以下の記事がおすすめです。

複数プロダクトの非効率な並行開発

よりそうは、生前から葬儀の手続きまでをワンストップでサービス提供するため、多数のプロダクトが存在します。サービス横断で見ると、類似機能であるが、目的が違うために別々のプロジェクトで重複開発される非効率さも目立っていました。

image.png

技術選択の分散

PHP、Go、Python、Salesforce、Quasar、Nuxt、Vue、Reactなど、多様な技術スタックが混在し、投資が分散。エンジニアや組織のリソースが集中しづらい構造でした。

技術面での取り組み:技術的負債の返済と技術戦略

STEP1:経営・技術・組織の三軸ヒアリング

プロダクト開発において、経営・技術・組織という三軸は、切っても切れない関係性です。ビジョンを描くために、三軸の状況把握からはじめました。

image.png

  • 経営軸:全社戦略、事業戦略の把握と整理を通じ、マクロな視点で事業ポートフォリオを理解。
  • 組織軸カルチャーモデルの7Sフレームワークを用いて、ビジネスに最適なカルチャーの方向性と現在地を理解。CTO協会の DX Criteriaを用いて、EX(従業員体験)向上白地を把握。
  • 技術軸gilotFindy Teamysを用いたGitHub分析、コスト分析を通じて、開発生産性向上の伸び代を特定。

STEP2:部門戦略「事業シナジーの最大化」と新基盤構想

テック戦略のコンセプト定義

テクノロジー戦略は部門戦略の一環であり、全社戦略や事業戦略を基盤として策定されるべきものです。「よりそう」では、将来的に多角的な事業拡大が計画されていましたが、技術的負債の上に新たな開発を重ねることや、事業拡大のたびにシステム基盤をゼロから構築することは、いずれも効率的とは言えない状況でした。そこで、「事業シナジーの最大化」をコンセプトに、新規事業向けに開発予定だった基盤を、将来的に主力事業にも展開可能な形で構築し、事業横断型の共通基盤を開発する計画にしました。この基盤は、新基盤と名付け、テクノロジーを活用して効率的に事業を推進できるエコシステムの構築を目指しました。

image.png

技術的負債の大分類

ビジョンに対して、問題になるのは技術的負債です。
まずは、技術的負債を以下4つに分類しました。

  1. データベースの断片化
  2. プログラムの老朽化
  3. 適切でないツール選定・開発
  4. 類似機能の重複開発

新基盤構想

技術的負債の返済と、事業シナジーの最大化を目的に、新基盤を構築しました。
具体的には、中央DB・APIサーバをコアにプロダクト群を再構成。ユーザーインターフェース層はマイクロサービス的に分離し、変更容易性を高め、開発範囲・責任範囲を明確化。これにより、各チームが独立性の高い状態で開発を進められるようになりました。

  • 1つのDBに集約(Aurora, DataLake, DWH)
  • 1つのAPIサーバ(Laravelベース)
  • UI層をマイクロサービス化
  • ツール選定の最適化(auth0, Shopify)
  • DDD+オニオンアーキテクチャ採用で負債蓄積を抑制
  • 各層ごとのテスト戦略やE2Eテスト導入

image.png

STEP3:開発プロセス改善と指標導入

開発生産性計測ツール「gilot」の活用

開発生産性は、CTO協会理事・広木氏が公開している「gilot」を用いてGitログを解析し、コミット数、修正行数、参加開発者数などから開発の安定度・出力量・エンゲージメントを定量化しました。
gilotが直接「生産性」や「健全性」を断定するわけではありませんが、有力なエビデンスの一つとなります。

参考:開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った

日常的に計測可能な指標として「コミット数」「修正ライン数」「1人あたりコミット数」をKPIとして設定し、これらの数値が低下した場合は、DX(Developer Experience)の悪化を示すシグナルと捉え、迅速にヒアリングを行い、改善策を立案しています。
ただし、ここで重要なのは、数値そのものが目的ではないということです。DX向上の結果として数値が向上することを目指すべきであり、エンジニア自身がDXの改善を実感することで、他社でも生産性改善をリードできる人材へと成長します。これにより、個々の人材的価値を高めると同時に、組織全体にとって大きな価値を生み出すという理想を実現することができます。この考え方をマネージャーが信じ、メンバーに数値を押し付けるのではなく、サーヴァントリーダーシップの精神で行動することが重要です。

image.png

これらの数値は、形骸化しないように、日次で開発生産性指標(G/P)を集計し、週次で共有するサイクルを確立しました。数値が営業ノルマのようにプレッシャーにならないように、背景や意図を丁寧に説明をしました。結果、G/Pが高い人に対して、どうやって生産性を高めているかを質問するメンバーが現れたり、ペアプロや勉強会、AI活用のナレッジなどが発生しました。

image.png
参照:CTOの頭の中:技術を財務で表現する

また、各プロジェクトごとにプレモーテム・ポストモーテムを実施し、改善点を洗い出し・蓄積する文化を定着。これらの取り組みにより、過去3年間でG/Pは約5倍以上に向上しました。2025年に設定した目標を1年前倒しで達成し、同水準の成果を1/5のコストで実現する状況を確認しています。

今後もAIの自動開発支援や会議体の最適化など、DX向上策を継続し、さらなる生産性向上を目指しています。

参考指標
  • fig.1:ジニ係数とローレンツ曲線
  • fig.2:タイムスロット(2週間)ごとのコミット量分布
  • fig.3:タイムスロット(2週間)ごとの実際の追加・削除行数とその差分
  • fig.4:タイムスロット(2週間)ごとのコミット開発者人数
  • G/Pレポート(自動集計)

さらに、4 Keys (DORAメトリクス) の導入を検討し、

  • デプロイ頻度
  • リードタイム
  • 変更失敗率
  • 復旧時間
    といったグローバルで実績のある指標を取り入れることで、改善の幅を広げています。

組織面での取り組み:文化と評価制度の変革

生産性向上は「技術投資」だけでなく「文化投資」が不可欠です。
新技術基盤による品質向上と、持続的な成長環境を整えたマネジメントによって、組織的な成熟と高速な開発サイクルの土壌を育みました。

image.png

image.png

エンジニア人事制度の再構築

職能資格から職務等級ベースの評価制度に転換し、ビジネススキルだけでなく、役割と専門スキルを評価可能な仕組みに。これにより、評価の透明性と納得感が向上し、エンジニアの定着率やキャリア成長意欲も高まりました。よりそうの人事制度は、株式会社ゆめみさんの人事制度を参考にさせていただきました。ゆめみさんは、エンジニアが選ぶ「開発者体験が良い」イメージのある企業「Developer eXperience AWARD 2024」ランキング上位30 にノミネーションされる素晴らしい会社です。

image.png

マネージャーは、雇用形態問わずコーチングやキャリア相談の機会を提供。1on1を通じてメンバーの強み・弱み・キャリアイメージを明確にし、個人の意志(will)と業務内容を紐づけることでモチベーションを高めています。

将来的にCTO・テックリードを目指すメンバーも増え、「経営・技術・組織」のバランス習得を目指し自律的に行動できる環境が醸成されています。フリーランスで参画している方も、他社では得られない経験・成長機会があるため、長期的なコミットを選択するケースが目立ちます。

ワーキンググループ(WG)による自律的改善

コスト改善や人事制度、バリュー策定など、従来マネージャーが担う業務をWGが自律的に推進する仕組みを構築。これによりメンバーは主体的に改善に関わり、マネージャーの負荷軽減とモチベーション向上を実現しました。

image.png

組織サーベイと360度フィードバックの活用

組織サーベイを用いて定量・定性の視点から組織戦略へフィードバックを行い、全社トップクラスのEX(従業員体験)を実現。

image.png

image.png

image.png

image.png

image.png

image.png

私たちは、マネージャーへの360度フィードバックを定期的に実施することで、組織内のコミュニケーションやマネジメント品質の継続的な改善に取り組んでいます。この制度は会社には元々存在しなかったため、自分たちで構築しました。その際、Google re:Workのマネージャーにフィードバックを提供するを参考にしています。

このフィードバックは、マネージャーのバイアスを取り除き、持続的な成長を促すために重要な仕組みです。私は前職からこの取り組みを始め、現在も半年に一度のペースで、5年以上にわたって実施しています。メンバーからのフィードバックは、私にとって大切な財産となっています。

image.png

マネージャーに今後も続けてほしいこと

ロールモデルとしての姿勢
  • エンジニア・マネージャーとして理想的で、背中を見せながらメンバーを成長させている。
  • 「見立てる・仕立てる・動かす」を体現し、成長に必要な姿勢を示している。
成長を促すフィードバック
  • チームや個人の成長に合わせた課題の提示と適切なフィードバックを提供している。
  • 具体的な行動に落とし込んだアドバイスを継続的に行っている。
キャリア形成の支援
  • 定期的なキャリア形成の話し合いやサポートを行い、個人の成長を組織の成長につなげる姿勢。
環境作りとコミュニケーション
  • 仕事を楽しめる環境作りと、様々なコミュニケーションの時間確保。
  • 定期的な考えの発信と情報共有を行っている。
模範的な行動
  • インプット・アウトプットを誰よりも続ける姿勢が、チームの模範となっている。

マネージャーに改めてほしいこと

話を遮ることのバランス
  • メンバーの話を途中で遮ることが時折あり、議論が一方的になる場合がある。
個々への直接的な関与
  • 定例では全体への関与があるものの、個別プロジェクトやメンバーへの直接的な関与を増やしてほしい。
記憶の抜けや意見の食い違い
  • 忙しさからか、前回の話を忘れることがあり、意見の食い違いが生じる場合がある。
話を聞き流すこと
  • 話を聞き流されていると感じることがある。
圧を感じること
  • たまに妙な圧を感じることがある。

これら取り組みは、組織内の信頼関係強化やモチベーション維持に寄与し、より高い生産性とエンゲージメントを生み出しています。

投資対効果(参考)

開発生産性向上により、1/5の工数で同水準のアウトプットが可能な月も確認。
この工数削減による概算人件費効果は年間約1.3億円規模(従来比)と試算しています。

image.png

今後の展開

現在、指標改善や組織文化の醸成に向けた取り組みが一巡し、自律型組織としての機能が強化されています。これは、エンジニアをはじめとするプロダクト開発に関わる全てのメンバーの努力の結晶です。しかし、これはまだ第一段階に過ぎず、道のりはこれからも続きます。将来的には、私たちのアウトプットが確実にアウトカムへと結びつき、市場に大きなインパクトを与えることを目指しています。そして、数年後には「よりそうで働けて本当によかった」と、エンジニア同士が肩を叩き合えるような組織を築き上げていきます。

image.png


以上が、3年間の取り組みの振り返りです。
これまで技術的負債を整理し、生産性向上の基盤を築いてきました。今後は、この基盤を活かしながら、より強固な組織と文化を育成し、顧客に対してさらに高い価値を提供できるよう努めてまいります。本内容が何かの一助となれば幸いです。

6
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?