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


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

もっと見る
味覚 普通の組織をイノベーティブにする処方箋 (その154)

  現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための2つ目の要素「同じ一つの行動をするにしても思...

  現在、イノベーション実現に向けての「思考の頻度を高める方法」を解説していますが、そのための2つ目の要素「同じ一つの行動をするにしても思...


市場を各グループ、セグメントに分割する 普通の組織をイノベーティブにする処方箋 (その69)

 前々回から「知識・経験を物理量で整理する」議論を始めていますが、今回も前回に引き続き「整理の為に考える要素」の解説をします。 ◆関連解説記事『技術...

 前々回から「知識・経験を物理量で整理する」議論を始めていますが、今回も前回に引き続き「整理の為に考える要素」の解説をします。 ◆関連解説記事『技術...


普通の組織をイノベーティブにする処方箋 (その170) 動物を深く知る

【目次】   【この連載の前回:普通の組織をイノベーティブにする処方箋 (その169)へのリンク】 これまでアナロジーと体感につい...

【目次】   【この連載の前回:普通の組織をイノベーティブにする処方箋 (その169)へのリンク】 これまでアナロジーと体感につい...


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

もっと見る
マトリクス体制での品質保証3 プロジェクト管理の仕組み (その32)

 前回のマトリクス体制での品質保証2に続いて解説します。    これまで説明してきたのは、プロジェクトごとに作成する品質計画(プロジェクト品...

 前回のマトリクス体制での品質保証2に続いて解説します。    これまで説明してきたのは、プロジェクトごとに作成する品質計画(プロジェクト品...


製品開発部へのカンバン導入記(その3)

        前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点...

        前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点...


‐現場観察のチェックポイント‐  製品・技術開発力強化策の事例(その8)

 前回の事例その7に続いて解説します。現場観察はどのような場合でも非常に大切です。 価値ある情報をくみ上げる観察力を絶えず自己啓発する必要があります。現場...

 前回の事例その7に続いて解説します。現場観察はどのような場合でも非常に大切です。 価値ある情報をくみ上げる観察力を絶えず自己啓発する必要があります。現場...