組織戦略立案での思考整理をフレームワークを使い実践してみた

執筆者

更新日：2024.09.19

公開日：2024.09.19

目次

組織課題の整理方法
1. マッキンゼーの7Sフレームワークの活用
2. 課題抽出から戦略作成までのプロセス
効果的な組織体制のアプローチ
長期的な組織拡大と拠点分断への対応

PLAN-Bにて開発組織の取りまとめを行なっている小原です。
最近では様々な機会が重なり、プロダクト作りからは少し離れ、プロダクト開発での組織戦略設計や体制・評価制度の設計、採用といった組織づくりの仕事が中心となってきました。
この先のPLAN-Bにおけるプロダクトによる事業作りを成長させていくには、システム部門でもさらなる組織拡大は言わずもがな必要になってくることです。
では、その将来を妄想した時に、改めて、今できていることは何で、何ができていないだろうか？を考えると、言語化できていない様々なことがあるなという状況に気づき、短期・中長期を見越した組織戦略を練り直す必要があると感じていました。今回は、その際に行った思考の整理方法などをご紹介したいと思います。

組織課題の整理方法

マッキンゼーの7Sフレームワークの活用

エンジニア組織の最適な戦略と体制を構築するためには、まず組織課題の整理が重要です。

様々な手法があるかと思いますが、今回は有名なマッキンゼーの7Sフレームワークを利用することにしました。「マッキンゼーの７S」は組織の全体像を把握し、課題を明確にするための有効なフレームワークです。

元々は企業・経営単位での整理に利用されるシーンも多いのかなと思いますが、今回はエンジニア組織での観点で整理を行いたかったので、各観点をエンジニア組織の場合にフォーカスした観点になっています。

＜マッキンゼーの７S要素＞

Strategy（戦略）:
組織が目標を達成するための長期的な計画や方針を指します。例えば、エンジニア組織であれば、技術的なロードマップの策定や市場へのアプローチ戦略がこれに該当します。
Structure（構造）:
組織内の部門構成、報告ライン、チームの編成方法など、組織の物理的または論理的な枠組みを指します。エンジニア組織においては、職能別組織からクロスファンクショナルなチームへの移行などになります。
Systems（システム）:
日常業務を管理・支援するためのプロセスや手続き、ツール、ソフトウェアなどを指します。例えば、継続的インテグレーション（CI）や継続的デリバリー（CD）のための自動化ツールやプロジェクト管理システムがこれに含まれます。
Shared Values（共有価値）:
組織内で共有される価値観や文化を指します。エンジニア組織では、イノベーションを重視する文化や、品質に対する厳格な姿勢が共有価値となり得ます。
Skills（スキル）:
組織が持つ専門的な能力や技術、ノウハウを指します。ここでは、チームメンバーの技術的スキルや、組織全体の学習能力が焦点となります。
Style（スタイル）:
リーダーシップスタイルや組織全体の働き方、コミュニケーションの取り方を指します。フラットな組織文化や、アジャイルな開発プロセスの採用が例として挙げられます。
Staff（スタッフ）:
組織のメンバー、特にその配置や人材育成の方針を指します。多様性のあるチーム構成や、育成プログラムの充実が、エンジニア組織の競争力を高めます。

課題抽出から戦略作成までのプロセス

では、フレームワークを活用して、現状の組織課題を抽出・整理から進めます。

書き出す際にも、現在の組織状態（As-Is）と理想的な状態（To-Be）を比較し、課題を抽出します。その後、各問題の原因を分析し、具体的な解決策＝課題を考案します。

次に、抽出された課題に対して具体的な戦略を策定します。

このプロセスでは、以下のステップで検討を進めて行きました。

現状分析
7Sフレームワークに基づいて、現状の組織を多角的に分析します。具体的には、各要素に対する現状の評価を行い、課題を洗い出します。
課題の優先順位付け
抽出された課題に対して、重要度と緊急度を評価し、優先順位を付けます。
戦略策定
優先順位の高い課題に対して、具体的な戦略を策定します。戦略は、短期的な解決策と中長期的な改善策の両方を含めると効果的です。
実行計画の立案
策定された戦略を実行に移すための具体的な計画を立案します。計画には、担当者の割り当て、スケジュール、必要なリソースなどが含まれます。
モニタリングと評価
実行計画に基づいて進捗をモニタリングし、定期的に評価を行います。必要に応じて、計画の修正や戦略の見直しを行います。

各整理した課題については、細かくは記載しませんが、

組織拡大のスケールを行いたいがその準備をする時間が長年取れない体制であること
各世代のエンジニアがいるが技術力の知識・スキルのばらつきがある＋シニアエンジニア層の不足
中長期での開発スピードを意識した「人以外での開発力強化」への時間投資

と言ったところでしょうか。

効果的な組織体制のアプローチ

では、課題を抽出し整理、対応すべき優先度を定めたのちに組織施策の検討に入っていきます。

優先順位の高い課題に対して、具体的な戦略とそれを実行するための計画を策定します。

「マッキンゼーの７S」では、比較的に変更しやすいとされる＝短期的に変更が行いやすい「ハードの３S」にフォーカスを当てて検討しました。

戦略
組織体制
システム（今回の場合は、「開発フロー」「目標設計」など）

が、それにあたります。

戦略・体制 – DevとOpsの選択集中

大枠の戦略を練りながら、それを実行に移していく組織体制を考えていきます。

PLAN-Bでのプロダクト開発組織の体制としては「DevOps」という体制をとっておりました。

DevOps体制は、開発（Dev）と運用（Ops）の両方を一つのチームが担うことが一般的です。

しかし、組織課題の状況を整理した場合に、技術スキルのばらつきや各チームでのエンジニアの不足・事業優先を進める開発を優先していきたいなどがあります。
その中で、DevとOpsを分離し、それぞれを実行できる体制に変更・集中すべき開発課題を切り分けた形での役割分担という方法でどうかと思いました。

専門性の向上
DevとOpsを役割として担当分離することで、それぞれの専門性を高めることができるため、Devチームは開発に集中しOpsチームはプロダクト運用に集中することで、効率的な作業分担ができると考えています。
役割の明確化
各チームの役割と責任を明確にすることで、業務の重複や混乱を防ぎます。また、各チームのパフォーマンスを評価しやすい形にしました。
コミュニケーションの強化
分離されたチーム間のコミュニケーションを円滑にするために、定期的なミーティングや情報共有の仕組みを設計します。チーム間の連携が強化され、全体としてのパフォーマンスが向上できると考えました。
技術的な支援
シニアクラスのエンジニアをあえてチーム構成からは外し、各所の問題にアプローチできるような自由な動きが取れるフォーメーションにして、技術支援（技術選定・リソース・育成）できる形にしました。

また、元々スクラムチーム内で様々な種類の「開発チケット」をリファインメントしていました。

新しい取り組みでは「Ops」関連でのチケットを各プロダクトチームから持ち寄り「Ops」担当者たちと技術統括にてプロダクト状況を共有しながらシステム課題としての優先度を決め進めていくという仕組みに変更しました。その後、「Dev」担当たちと協力すべきところは、元のスクラムチーム上でのリファインメントにてスクラム体制を組みながらの開発フローに乗せていく取り組みをスタートしています。

戦略・システム – OpsからSREへの拡大に向けて

「Ops」担当のメンバーでは、中長期にかけて「SRE（Site Reliability Engineering）領域」への取り組みに拡大させていくことも検討しています。SREに向けた取り組みに関しては、ドキュメント管理、CI/CD構築・テスト自動化・モニタリング、ツール導入、自動復旧、セキュリティ対策と順を追ってロードマップを作り、３ヶ月単位で取り組む範囲を広げていく形を考えてます。

これまでの「Dev Ops」の取り組みにて、できている部分はあったので、これまで「点」でできていることをプロジェクトとして「線」にしていき、ゆくゆくはSREチーム組成も検討していきたいなという考えもあります。

戦略・システム – シニアエンジニア不足への対策

どの会社でも上がるような経験豊富なシニア層のエンジニアメンバーの不足は、多くの開発組織が直面する課題かと思います。この問題に対処するためには、以下のような検討を進めました。

内部育成
ジュニアエンジニアをシニアエンジニアへと育成するプログラムの設計。具体的には、メンター制度やトレーニングプログラムの実施、キャリアパスの明確化などを検討しました。
外部採用
シニアエンジニアの採用は継続。採用戦略としては、競争力のある報酬パッケージの提供やリモートワークの導入、柔軟な働き方の提案など、自社のアトラクト要素の整理や再検討を進めることにしました。
知識共有の促進
シニアエンジニアの知識を組織全体で共有する仕組みを整備します。具体的には、定期的な技術勉強会やドキュメントの整備、ナレッジベースの構築などが挙げられます。

各自のスキルアップは個人鍛錬ももちろん必要ですが、組織上では有志での勉強会（技術鍛錬会の方が正しいかも）の発足や外部の経験豊富なエンジニアの方に業務委託としてジョインいただき知見と実務を進めていただきながら、採用活動は引き続き注力していく形になりました。

とはいえ採用は常に難しい状況ではあるため、別の打ち手として特に力を入れると決めたのが「知識共有の促進」です。

「ドキュメント文化の徹底」は後半で触れますが、主には「シニア層でのエンジニアスキルを活かした開発標準化」にて純粋な技術としての開発ナレッジを全体に共有していくという形で取り組むことにしています。

方針や技術アセットの大枠を決定し、標準的に開発スキルの育成にも生きていくような仕組みがこの３ヶ月ほどで整ってきたので、いよいよその標準ナレッジを生かしながらの開発が徐々に進んでいく形です。

このあたりは別のテックブログにて実際に取り組んでいるチームメンバーから発信してもらいます。

体制 – 職能別組織からデリバリー体制への移行

従来の職能別組織は、各専門分野のスキルを最大限に活用することができますが、部門間の連携が不足しがちです。

PLAN-Bでも、職能別型の組織体制をとっていましたが、バリューストリームを整理した際では、やはり認識の分断や意思決定にちょっとずつ時間がかかってきている。要は、人数が増えてくるコミュニケーションパスの増加問題に直面していました。

そこで参考にしたのが、「Scaling Teams 開発チーム組織と人の成長戦略」という本にあった組織設計の内容でした。

デリバリーチーム体制を構築しプロジェクトやプロダクトの成果物に焦点を当て、複数の職能を一つのチームにまとめるアプローチです。複数の職能を一つのチームにまとめ、プロジェクトの迅速な推進を図ります。この体制では、エンジニア、PDM、UXデザイナーなどが一つのチームとして協力し、成果物に焦点を当てた開発を行います。

デリバリーチームの構築とは「着想」から「公開」までのソフトウェア開発過程に必要な機能をもれなく備えた自立型チーム。

この体制では、エンジニア、PDM、UXデザイナーなどが一つのチームとして協力し、迅速かつ効率的にプロジェクトを進めることができます。

これまでも実はデリバリーチーム体制を組みながら、プロダクト構築は進めておりましたが、他の組織戦略を実行しながらデリバリーチームがプロダクト開発を行うには、様々な調整が必要になってきたことも問題としてあったので、デザイナーを除く、デリバリーチームをごっそりとそのまま組織体制・組織図としました。

デリバリー体制への移行には、以下のポイントを意識してます。

チーム編成
プロジェクトの目標や規模に応じて、適切なメンバーを選定し、チームを編成します。各職能の専門家をバランスよく配置する形で検討しました。
コミュニケーションの促進
チーム内のコミュニケーションを円滑にするために、定期的なミーティングや情報共有の仕組みを作るようにしました。
責任の明確化
各メンバーの役割と責任を明確にし、チーム全体としての成果物に対するコミットメントを高める形にしました。
継続的な改善
チームのパフォーマンスを定期的に評価し、課題が見つかった場合には迅速に対応し、調整を行うなど常に変化させることの方針で運営することにしました。

さらにデリバリーチームは4つのアプローチ方法があるということも学びました。

事業に焦点を当てるアプローチ：特定の事業目標に注力する
プラットフォームに焦点を当てるアプローチ：OSといった技術理解・共有に注力する
機能に焦点を当てるアプローチ：主要機能に対する注力する
顧客グループに焦点に当てるアプローチ：特定の顧客グループへの価値提供に注力する

結果、各事業プロダクトを展開している事業状況を捉え「事業目標に即した最適化」が最も自分たちにとっては取り組みやすかったため、今回はそのアプローチでデリバリーチームの体制を組んでいきました。

合わせて、事業重要度に直接インパクトしない開発をデリバリーチームでは行わない、システム組織課題を解消するチーム組成を別の体制図として作ったことも今回の体制変更のポイントではあります。

システム – モニタリングと評価

ここ半年で組織戦略・体制に着手したばかりではありますが、徐々に良いなと思える形も少しずつ出始めているような気がします。

大きな点で言うと組織スケーリングに向けた準備が徐々に進むようになった点です。

戦略の方針を明確にきり、動ける体制、工数を確保し、プロジェクト管理の体制・環境を作ったことが良いのかなと現状では思います。

もちろんその上でプロジェクトの推進役やしっかり忙しい中でもタスクを進めてもらっているチームメンバーたちのおかげですね。

また各自の評価の体制も少しだけ変化を入れて「チャレンジの数」と「チャレンジ・学びの言語化」をキーワードにしながら、その点も評価に加えていきたいかなと思ってます。

モニタリングに関しても、月一でマネジメント層では各進捗のプロジェクト共有や課題について各種のプロジェクト進捗と課題・アクション決定まで行う取り組みも行なっており、Q単位でレビューという形で進めています。

長期的な組織拡大と拠点分断への対応

組織課題として「ハードの3S」以外の面でも、「ソフトの4S」でも中長期アクションは切るようにしています。

中長期戦略は、目の前のことに集中してしまい忘れがちになりますので、まずはしっかり工数を捻出、MTGを設計、プロジェクト化して、着実にひとつひとつ取り組むことにしました。

ドキュメント文化の徹底

組織が拡大し、複数の拠点に分かれる場合、情報共有の重要性が増します。ドキュメント文化の徹底は、情報の一貫性を保ち、効率的なコミュニケーションを実現するために不可欠です。以下のポイントを押さえながら、ドキュメント文化を徹底します。

ドキュメント作成の方針を決める
全社員に対して、ドキュメント作成の基本的なスキルやルールをまず技術戦略チームにて議論し定義します。またドキュメント作成の優先度も決定して何があるのか、何がないのかといった整理から行いました。
ドキュメントの標準化づくり
全社員が共通のフォーマットやテンプレートを使用することで、ドキュメントの一貫性をルール化しました。
ドキュメント管理をどうするか
ドキュメントの作成、共有、更新をどのように管理していくかを決定し、情報の検索性とアクセス性を高める方針を決めました。
定期的なレビューと更新
作成されたドキュメントが常に最新の情報を反映するよう、定期的なレビューと更新頻度も大枠の方針を固めました。

場所にとらわれない大阪・東京といった拠点拡大の連携強化のポイント

PLAN-Bの開発組織は複数拠点で開発を行っているため、ある種の開発文化形成とも言える点で組織間での連携を強化も必要かなと感じています。そこで以下のポイントが重要になると考えました。

リモートコミュニケーションツールの活用
ビデオ会議、チャットツール、プロジェクト管理ツールなどを活用し、拠点間のコミュニケーションを円滑にできるように少しずつ整備とルールなどを決めて進めています。
定期的な交流イベントの開催
拠点間のメンバーが直接顔を合わせる機会を定期的に設け、信頼関係を築けると考えてます。例えば、Q単位での開発組織全体での振り返り・共有といった納会・チームビルディングイベントなどを実施することにしました。
一貫したプロセスとルールの導入
全拠点で共通の業務プロセスやルールを導入し、業務の標準化を図る取り組みをプロジェクトとして定義してスタートさせました。
拠点間のベストプラクティスの共有
各拠点・チームでの成功事例やベストプラクティスを積極的に共有できる部門納会の設計と実施を行なっています。

リモートでの仕事前提ではコミュニケーション設計にまだまだ課題も残る点もあり、各自のアクションによって解消されている部分に依存してしまっている点も多くあります。

その中でも業務プロセス整備・出張ベースでのリアルコミュニケーションの頻度増加は意識して取り組んでもらってますが、何よりも効いてくると感じているのは「ドキュメントに残す」「文章でのログ・会議でのアジェンダ・議事録文化」などはいつも意識してもらっています。

リモートワークでのMTGはさっと遠隔と繋いで話し合うスムーズさになりましたが、逆にいうと何が決まったんだっけ？誰が何するんだっけが起きやすいこともしばしばあります。ですので、会議アジェンダ・アクション整理は行なってもらうように依頼しています。

PLAN-BではMicrosoft Teamsをコミュニケーションツールとして利用していますが、アクション管理は「Asanaと言ったプロジェクト管理ツール」を活用し、会議→アクション管理を行いながら、拠点間の円滑なコミュニケーション・タスク管理に取り組むようにしています。

将来は「PLAN-B開発 Hand Book」として文化発信

最後になりますが、これまでの取り組みなどを踏まえながら、長期的にはプロダクト開発組織として、その会社の文化発信しているものを「Hand Book」として集約して行きたいなという妄想もしていたりします。

僕と組織作りに携わっている箱根から出たアイディアですが、それを発信できる開発組織を作りたいよねぇとはいつも話しているようなことです。

PLAN-Bでのエンジニアリング組織文化
働く環境
技術領域や技術戦略

色々な準備は整ってきた形で、これまでの組織を土台としながらも、新しい取り組み・やってみたいなどは柔軟に受け入れながら前に進む。方針や選択を間違えたと感じた時には、間違いを受け入れ、メンバーにも迷惑をかける時にはごめんなさいをしっかり伝え、それでも歩みを止めないような強い組織にできればと考えています。

それこそソフトウェアとしてのプロダクトを作るように、組織の形やあり方・戦略などは柔軟に変えながらも、数年後にまた新しい景色が見れるように。
今、現在の状況を楽しみながら、組織作りとプロダクト作りを楽しんでいきたいと思います。

執筆者

小原聡

株式会社PLAN-B プロダクトインテグレーション部部長

2014年に中途として入社。LP専属の制作ユニットを経て、クリエイティブユニットのWebディレクターとして従事。広告事業の社内プロダクト開発に従事した頃から徐々に自社プロダクト開発に携わるようになり、2019年から自社開発プロダクト「SEARCH WRITE」のPM（プロダクトマネージャー）として、プロダクトの立ち上げを進める。次なる新しいサービス「SEARCH WRITE LEAD」の立ち上げも行い、2022年4月よりサービス開始。本格的なプロダクト作りは後任メンバーに移行し、現在は、組織戦略設計・組織体制検討・メンバーマネジメントなどを進め、プロダクトを生み出す組織作りに携わっています。

DOWNLOAD

無料資料ダウンロードはこちら

CONTACT

お問い合わせはこちら

組織戦略立案での思考整理をフレームワークを使い実践してみた