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


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

もっと見る
新規事業は小さなPDCAを回して生み出す 新規事業・新商品を生み出す技術戦略(その18)

        今回は、各界のリーダーの言葉から新規事業立ち上げに対する考え方をご紹介します。  ...

        今回は、各界のリーダーの言葉から新規事業立ち上げに対する考え方をご紹介します。  ...


情報コンテンツ 見えてきた、2030年の技術社会 (その4)

  【見えてきた、2030年の技術社会 連載目次】 1.  自動車業界のパラダイムシフト 2.  シェアリングエコ...

  【見えてきた、2030年の技術社会 連載目次】 1.  自動車業界のパラダイムシフト 2.  シェアリングエコ...


製品開発における上流設計の重要性とDfX(その2)

【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! ◆ 上流工程を支援するDfXとは 前回の製品開発...

【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! ◆ 上流工程を支援するDfXとは 前回の製品開発...


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

もっと見る
技術人材が目指す第3のキャリアとは

1.R&Dの現場に存在する2つのラダー    私は、イノベーションを「価値の創造と具現化」として定義していますが、もう少し突っ込んで...

1.R&Dの現場に存在する2つのラダー    私は、イノベーションを「価値の創造と具現化」として定義していますが、もう少し突っ込んで...


開発工数メトリクス1 プロジェクト管理の仕組み (その21)

 前回のプロジェクト管理の仕組み (その20)に続いて解説します。    進捗管理のための基本メトリクスセットについての解説を続けています。...

 前回のプロジェクト管理の仕組み (その20)に続いて解説します。    進捗管理のための基本メトリクスセットについての解説を続けています。...


設計部門の仕組み構築(その1)

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...