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


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

もっと見る
開発現場の仕組み見直しとグローバル化とは【連載記事紹介】 

    ◆ 開発現場の仕組み見直し、目指すべき開発体制 「擦り合わせ型」の文化は、日本企業文化ととして形成されてきたもので、...

    ◆ 開発現場の仕組み見直し、目指すべき開発体制 「擦り合わせ型」の文化は、日本企業文化ととして形成されてきたもので、...


普通の組織をイノベーティブにする処方箋 (その187) 妄想を「形」にして残す

・見出しの番号は、前回からの連番です。 【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! 妄想はネ...

・見出しの番号は、前回からの連番です。 【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら! 妄想はネ...


製品開発とコストダウン(その3)

◆コストダウンのための仕組み作り    コストダウンを容易に検討できる仕組みについて解説します。製品開発のステップをもう一度思い出して下さい...

◆コストダウンのための仕組み作り    コストダウンを容易に検討できる仕組みについて解説します。製品開発のステップをもう一度思い出して下さい...


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

もっと見る
富士フィルムにおけるコア技術の活用戦略

 本業であるフィルム事業がなくなることを経験した、富士フィルムの技術の棚卸活動は注目に値します。アスタリフトや液晶用フィルムは、フィルム事業で培ったコア技...

 本業であるフィルム事業がなくなることを経験した、富士フィルムの技術の棚卸活動は注目に値します。アスタリフトや液晶用フィルムは、フィルム事業で培ったコア技...


システム設計5 プロジェクト管理の仕組み (その37)

 それでは、機能以外にも注目してシステム要件をリストアップするにはどうしたらよいでしょうか、 そのための手法として FURPS+ を紹介したいと思います。...

 それでは、機能以外にも注目してシステム要件をリストアップするにはどうしたらよいでしょうか、 そのための手法として FURPS+ を紹介したいと思います。...


設計部門と組織政治の影響(その1)

 これまで数回にわたって、設計部門における仕組み構築の考え方や手順を解説してきました。仕組み構築のためのシステム化計画作成は、頂上を目指す登山ルートを設計...

 これまで数回にわたって、設計部門における仕組み構築の考え方や手順を解説してきました。仕組み構築のためのシステム化計画作成は、頂上を目指す登山ルートを設計...