スケールド・アジャイル・フレームワーク (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など、問題解決のためのフレームワークを使った新製品の開発や品質の向上、プロセスの改善を得意としています。「ものづくり」に関...


関連する他の活用事例

もっと見る
チーム力を活かす設計ルームのレイアウトとは

   今回は、金型メーカーに限らず、機械設備メーカーなども含め、設計室(設計ルーム)でチーム力を活かすレイアウトについて解説します。 &nb...

   今回は、金型メーカーに限らず、機械設備メーカーなども含め、設計室(設計ルーム)でチーム力を活かすレイアウトについて解説します。 &nb...


マトリクス体制での品質保証1 プロジェクト管理の仕組み (その30)

 適切な品質管理を実施できるような仕組みを構築し、運用することが品質保証であることを前回説明しました。品質管理を正しく実施するポイントは、製品(ここではサ...

 適切な品質管理を実施できるような仕組みを構築し、運用することが品質保証であることを前回説明しました。品質管理を正しく実施するポイントは、製品(ここではサ...


技術資源の有効活用: 事例紹介 (その1)

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...