ストーリー
田
田中VPoE
アジャイルとリーンを全社に広げるうえで最大の障壁は何だと思う?
あなた
部門間のサイロ化でしょうか。営業と製造と情報システムが別々に動いている
あ
田
田中VPoE
その通りだ。DXは部門の壁を超えないと成果が出ない。顧客体験は営業・マーケ・製造・物流・サポートすべてが関わる。部門横断のクロスファンクショナルチームを編成し、顧客価値を中心に全員で取り組む体制を作る必要がある
あなた
でも、部門長は自分の部門のリソースを出したがらないのでは?
あ
田
田中VPoE
だからこそ経営レベルのコミットメントが必要だ。そして、部門横断チームの成功体験を作ることで、「協働すれば自部門だけでは出せない成果が出る」と実感してもらう。今日はその編成と運営手法を学ぼう
部門横断チームの必要性
サイロ化がDXを阻害するメカニズム
| サイロの種類 | 具体例 | DXへの悪影響 |
|---|
| 情報のサイロ | 営業が持つ顧客データと製造の品質データが繋がっていない | 顧客起点の品質改善ができない |
| プロセスのサイロ | 受注→製造→出荷の各段階で別システム・別手順 | エンドツーエンドの業務最適化ができない |
| 目標のサイロ | 営業は売上、製造はコスト、品管は不良率と個別KPI | 全体最適ではなく部分最適に陥る |
| 文化のサイロ | 部門ごとに価値観や仕事の進め方が異なる | DX施策の統一的な推進ができない |
部門横断チームのメリット
| メリット | 内容 | 定量効果の例 |
|---|
| 意思決定の速度 | 必要なメンバーが揃っているため調整時間が激減 | 意思決定リードタイム70%短縮 |
| 顧客視点の統合 | 多角的な視点で顧客価値を検討できる | 顧客満足度15%向上 |
| イノベーション | 異なる専門知識の掛け合わせで新しい発想が生まれる | 新規アイデア創出数3倍 |
| 組織学習 | 部門間で知識・ノウハウが自然に共有される | ナレッジ共有率40%向上 |
クロスファンクショナルチームの設計
チーム編成の原則
| 原則 | 内容 | 注意点 |
|---|
| ミッション駆動 | 機能ではなくミッション(顧客課題)でチームを編成 | 「何の部門か」ではなく「何を解決するか」 |
| 自律性 | チーム内で意思決定と実行が完結する | 毎回上位承認が必要な設計にしない |
| 多様性 | 異なる専門性・経験・視点を持つメンバーで構成 | 同質的なメンバーだけにならない |
| 適正規模 | 5-9名(Two-Pizza Team) | 大きすぎるとコミュニケーションコスト増大 |
DXプロジェクトの推奨チーム構成
| 役割 | 人数 | 所属元 | 責務 |
|---|
| プロダクトオーナー | 1名 | 事業部門 | ビジネス価値の定義、優先順位の決定 |
| スクラムマスター / ファシリテーター | 1名 | DX推進室 | プロセスの促進、障害の除去 |
| ビジネスアナリスト | 1名 | 事業部門 | 業務プロセスの分析、要件の整理 |
| テクニカルリード | 1名 | 情報システム部 | 技術選定、アーキテクチャ設計 |
| 開発者 / 市民開発者 | 2-3名 | 情報システム部 + 事業部門 | ソリューションの構築 |
| UXデザイナー | 1名 | マーケ部 or 外部 | ユーザー体験の設計 |
| データアナリスト | 1名 | 経営企画 or R&D | データ分析、効果測定 |
クロスファンクショナルチームの構造:
┌──────────────────────────────────┐
│ DXミッション(顧客課題) │
├──────────────────────────────────┤
│ PO SM BA Tech Dev │
│ 事業 DX推進 事業 情シス 混成 │
│ │
│ UX Data │
│ マーケ 企画 │
└──────────────────────────────────┘
↕ 情報・成果の共有
┌──────┐ ┌──────┐ ┌──────┐
│営業部│ │製造部│ │情シス│
└──────┘ └──────┘ └──────┘
母体組織(専門性の維持・育成)
部門横断チームの運営
マトリクス型組織の課題と対策
| 課題 | 原因 | 対策 |
|---|
| 二重報告 | 母体部門とプロジェクトの両方に報告義務 | プロジェクト優先の明確なルール設定 |
| リソース競合 | 母体部門の業務とプロジェクト業務の衝突 | 専任比率の明確化(最低50%専任) |
| 評価の曖昧さ | 誰がどの基準で評価するか不明確 | プロジェクト成果を人事評価に反映する仕組み |
| 帰属意識 | どこに所属しているか分からない | 母体部門のアイデンティティを維持しつつチームの一体感を醸成 |
部門横断コラボレーションの促進策
| 施策 | 内容 | 期待効果 |
|---|
| ジョブローテーション | 半年間、別部門に配属して業務を経験 | 他部門の業務理解、人的ネットワーク構築 |
| 共有OKR | 部門を超えた共通目標を設定 | 部門間の目標対立を解消 |
| 物理的近接 | 部門横断チームのメンバーを同じフロアに配置 | 偶発的な対話の増加 |
| デジタルコラボ | Slack/Teamsのクロスファンクショナルチャネル | リモート環境でも部門間の情報共有 |
「部門横断チームの最大の敵は”元の部門に戻りたい”という帰巣本能だ。だからこそ、部門横断チームでの経験が”キャリアにプラスになる”と感じてもらう仕組みが必要だ。DXプロジェクトの成功体験を人事評価やキャリアパスに組み込むことで、「行きたい場所」に変える」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|
| サイロの問題 | 情報・プロセス・目標・文化の4種類のサイロがDXを阻害 |
| チーム編成原則 | ミッション駆動、自律性、多様性、適正規模(5-9名) |
| 推奨構成 | PO + SM + BA + Tech + Dev + UX + Dataの7-8名 |
| 運営の課題 | 二重報告、リソース競合、評価、帰属意識への対策が必要 |
チェックリスト
次のステップへ
次は「演習:アジャイル・リーン導入計画を策定しよう」に取り組みます。Step 3で学んだアジャイル組織、リーン思考、実験文化、部門横断チームを統合し、全社導入計画を作成しましょう。
推定読了時間: 30分