スケールド・アジャイル・フレームワーク (SAFe) の導入開始

更新日

投稿日

 
  SAFe
 
 はたして僕が勤める企業はスケールド・アジャイル・フレームワーク (SAFe) を上手く導入できるのでしょうか。もちろん導入に成功しているソフトウェア企業は多くあるので、一般的に言えば SAFe の導入は可能だと思います。しかし僕の勤める会社でそれが実現可能かどうか聞かれれば、「今の段階ではすごく難しいのではないか」と答えるでしょう。理由はいくつかあります。
 
  • 純粋なソフトウェア開発企業ではないこと(半分以上がハードウェア開発業務)
  • SAFe でハードウェア開発部門も取り込もうとしていること
  • ハードウェア開発部門はアジャイル開発の経験が全くないこと(ソフトウェア部門は SCRUM を不完全ながらも導入済み)
  • 部門間のセクショナリズムが激しく、SAFe を導入する基盤が整っていないこと
 
 以上挙げればきりがないのですが、一言で言えば、 SAFe 導入にあたってはまだ未熟な組織だということです。
 

1. 導入の背景

 
 SAFe 導入の背景には、「それぞれの製品開発工程の予測が立たず、製品開発全体のスケジュールが予定通りに進まない」という問題がありました。製品がソフトウェア、ファームウェア、制御基板、パワー基板、機械部品、筐体など多岐に渡っているため問題が複雑化し、また複雑に絡み合った構成部品それぞれの依存関係が、さらに製品開発をスケジュール通りに進めることを難しくしていました。スケジュール上の問題が起こるたびに各部門が責任の擦り合いを始め、部門同士の信頼関係の悪化も問題となっていました。
 
 そこで、その「予測不可能な製品開発スケジュール」の問題を解決するために昨年より何度も話し合いが行われ、その結果、部分的なプロセス「改善」ではなく、根本的なプロセスや組織の「改革」が必要だろうという結論になり、今流行のエンタープライズ・アジャイルの一つ、スケールド・アジャイル・フレームワーク (SAFe) の導入が決まったというわけです。
 
 SAFe はリーンを基礎にしています。そのため、僕はリーンシックスシグマ、特にリーンの立場から、SAFe の導入は面白いと思いました。
 

2. コンサルタント契約と導入開始

 
 SAFe の導入が決まってからすぐにその予算が付き、SAFe コンサルタントとの契約も完了しました。そしてコンサルタントは僕が勤める会社に常駐するようになり、アジャイル・リリース・トレイン(ART)の準備を始めたり、社員のトレーニングを始めました。
 
 コンサルタントの薦めにより、多くの社員(エンジニアとマネージャー)がトレーニングを受けました。僕もその一人です。しかし少し気になることがこの時から感じるられるようになりました。
 
 僕は二日間のトレーニングを終えた後、オンライン試験に合格し、無事にSA(SAFe Agilist)の認定を受けることができましたが、どうもオンライン試験を受けたのは僕以外にはあまりいないようなのです。同僚に聞くと「トレーニングは会社からの命令で参加したけど、試験は強制じゃないからね。それに SAFe にはあまり興味がないし勉強する気にならないな」ということでした。多くの社員達(エンジニアもマネージャーも)は SAFe に冷めているようなのです。
 

3. コンサルタントとの会話

 
 契約しているコンサルタントはとても優秀な方で、コーチとしてもプロであることを感じさせてくれるような人です。そのプロ魂のためか、僕の「こんな冷めた社員達が SAFe を導入できると思うか」というネガティブな質問にも「大丈夫」と常にポジティブな答えを返してくれます。
 
 リーンシックスシグマ、特にリーンの側面から、僕は SAFe にとても興味がありますし、またリーンを知り、行っているものとして、SAFe は十分納得のいくものです。しかしそれ故にリーンを導入することの難しさも知っていますし、またリーンが成果を表すまで長い間時間を要することも知っています。SAFe もリーンを基礎にしている以上、導入はそれほど簡単ではないはずです。とくにソフトウェア開発から発展した SAFe を複雑怪奇なハードウェアに当てはめることは至難の業だと思います。
 
 コンサルタントはソフトウェア開発の出身で、また SAFe をハードウェア開発に導入した経験はこれまでのところないそうで...
 
  SAFe
 
 はたして僕が勤める企業はスケールド・アジャイル・フレームワーク (SAFe) を上手く導入できるのでしょうか。もちろん導入に成功しているソフトウェア企業は多くあるので、一般的に言えば SAFe の導入は可能だと思います。しかし僕の勤める会社でそれが実現可能かどうか聞かれれば、「今の段階ではすごく難しいのではないか」と答えるでしょう。理由はいくつかあります。
 
  • 純粋なソフトウェア開発企業ではないこと(半分以上がハードウェア開発業務)
  • SAFe でハードウェア開発部門も取り込もうとしていること
  • ハードウェア開発部門はアジャイル開発の経験が全くないこと(ソフトウェア部門は SCRUM を不完全ながらも導入済み)
  • 部門間のセクショナリズムが激しく、SAFe を導入する基盤が整っていないこと
 
 以上挙げればきりがないのですが、一言で言えば、 SAFe 導入にあたってはまだ未熟な組織だということです。
 

1. 導入の背景

 
 SAFe 導入の背景には、「それぞれの製品開発工程の予測が立たず、製品開発全体のスケジュールが予定通りに進まない」という問題がありました。製品がソフトウェア、ファームウェア、制御基板、パワー基板、機械部品、筐体など多岐に渡っているため問題が複雑化し、また複雑に絡み合った構成部品それぞれの依存関係が、さらに製品開発をスケジュール通りに進めることを難しくしていました。スケジュール上の問題が起こるたびに各部門が責任の擦り合いを始め、部門同士の信頼関係の悪化も問題となっていました。
 
 そこで、その「予測不可能な製品開発スケジュール」の問題を解決するために昨年より何度も話し合いが行われ、その結果、部分的なプロセス「改善」ではなく、根本的なプロセスや組織の「改革」が必要だろうという結論になり、今流行のエンタープライズ・アジャイルの一つ、スケールド・アジャイル・フレームワーク (SAFe) の導入が決まったというわけです。
 
 SAFe はリーンを基礎にしています。そのため、僕はリーンシックスシグマ、特にリーンの立場から、SAFe の導入は面白いと思いました。
 

2. コンサルタント契約と導入開始

 
 SAFe の導入が決まってからすぐにその予算が付き、SAFe コンサルタントとの契約も完了しました。そしてコンサルタントは僕が勤める会社に常駐するようになり、アジャイル・リリース・トレイン(ART)の準備を始めたり、社員のトレーニングを始めました。
 
 コンサルタントの薦めにより、多くの社員(エンジニアとマネージャー)がトレーニングを受けました。僕もその一人です。しかし少し気になることがこの時から感じるられるようになりました。
 
 僕は二日間のトレーニングを終えた後、オンライン試験に合格し、無事にSA(SAFe Agilist)の認定を受けることができましたが、どうもオンライン試験を受けたのは僕以外にはあまりいないようなのです。同僚に聞くと「トレーニングは会社からの命令で参加したけど、試験は強制じゃないからね。それに SAFe にはあまり興味がないし勉強する気にならないな」ということでした。多くの社員達(エンジニアもマネージャーも)は SAFe に冷めているようなのです。
 

3. コンサルタントとの会話

 
 契約しているコンサルタントはとても優秀な方で、コーチとしてもプロであることを感じさせてくれるような人です。そのプロ魂のためか、僕の「こんな冷めた社員達が SAFe を導入できると思うか」というネガティブな質問にも「大丈夫」と常にポジティブな答えを返してくれます。
 
 リーンシックスシグマ、特にリーンの側面から、僕は SAFe にとても興味がありますし、またリーンを知り、行っているものとして、SAFe は十分納得のいくものです。しかしそれ故にリーンを導入することの難しさも知っていますし、またリーンが成果を表すまで長い間時間を要することも知っています。SAFe もリーンを基礎にしている以上、導入はそれほど簡単ではないはずです。とくにソフトウェア開発から発展した SAFe を複雑怪奇なハードウェアに当てはめることは至難の業だと思います。
 
 コンサルタントはソフトウェア開発の出身で、また SAFe をハードウェア開発に導入した経験はこれまでのところないそうです。僕が悲観的なのか、それとも常にポジティブなコンサルタントが楽観的過ぎるのか良くわかりませんが、これから注意深く様子をみることになりそうです。
 

4. 今後の展開

 
 最初の ART(アジャイル・リリース・トレイン)を近いうちに発車する予定です。しかし SAFe が定める組織の新しい役割を誰がやるのかはまだ決まっていないようです。幸か不幸か、僕は SAFe 導入を少し距離を置いて見ることができる立場にいますが、事の成り行きには興味があります。願わくば我々が SAFe の成功事例となることを期待していますが、仮に失敗事例となってもそこから学ぶ事がたくさんあるような気がしています。SAFe の導入に興味がある方のためにも、今後定期的に途中経過を報告していきたいと思います。
 

   続きを読むには・・・


この記事の著者

津吉 政広

リーンやシックスシグマ、DFSSなど、問題解決のためのフレームワークを使った新製品の開発や品質の向上、プロセスの改善を得意としています。「ものづくり」に関する問題を一緒に解決してみませんか?

リーンやシックスシグマ、DFSSなど、問題解決のためのフレームワークを使った新製品の開発や品質の向上、プロセスの改善を得意としています。「ものづくり」に関...


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
技術文書の品質管理(その1)文書の内容が明確に伝わるかどうかを確認

     【目次】 1. 技術文書の品質管理とは 製造業での品質管理とは「製品の品質に問題がないよう...

     【目次】 1. 技術文書の品質管理とは 製造業での品質管理とは「製品の品質に問題がないよう...


普通の組織をイノベーティブにする処方箋【連載記事紹介】

  連載中の普通の組織をイノベーティブにする処方箋が無料でお読みいただけます!   ◆ 曖昧なイノベーションの定義 近年に...

  連載中の普通の組織をイノベーティブにする処方箋が無料でお読みいただけます!   ◆ 曖昧なイノベーションの定義 近年に...


自社の強みの定義とは 普通の組織をイノベーティブにする処方箋 (その44)

        前回まではKETICモデルのK(Knowledge)の知識の3つの要素、すなわち「技術知識」...

        前回まではKETICモデルのK(Knowledge)の知識の3つの要素、すなわち「技術知識」...


「技術マネジメント総合」の活用事例

もっと見る
‐技能と技術の融合化によるITを応用した技術開発‐  製品・技術開発力強化策の事例(その4)

 前回の事例その3に続いて解説します。ITの普及と共に技術者や技能者の質的内容が大きく変化しつつあります。今まで何回もの練習と経験を積む必要性が高かった業...

 前回の事例その3に続いて解説します。ITの普及と共に技術者や技能者の質的内容が大きく変化しつつあります。今まで何回もの練習と経験を積む必要性が高かった業...


品質の仕組みとは3 プロジェクト管理の仕組み (その29)

 これまでISO9001を例にした話になっていますので、ここで PMBOK (Project Management Body of Knowledge) ...

 これまでISO9001を例にした話になっていますので、ここで PMBOK (Project Management Body of Knowledge) ...


サブシステムの開発目標 プロジェクト管理の仕組み (その41)

 前回までで、化粧品の自販機についてシステムの内部構造を決めました。システム内部構造は、システムを独立したサブシステムにブレークダウンしたもので、ブロック...

 前回までで、化粧品の自販機についてシステムの内部構造を決めました。システム内部構造は、システムを独立したサブシステムにブレークダウンしたもので、ブロック...