---

確約の不足、変更管理、チームワークの課題を乗り越える！意外な発見があるかもしれません！

スクラム以前のプロセス改善の枠組みの最大の弱点は、次の点でした。 主に、リーダーの都合に沿う組織上の要求に集中していた.

監視、規則への準拠、予測可能性などが、その要求でした。 顧客への良いサービスや、従業員の士気の向上には、まったく注目していなかった.

そのため、ソフトウェア管理チームや社内外のさまざまな関係者は、提供プロジェクトの締め切りを固定し、開発の各段階の進捗を簡単に監視しようとしました。

計画から外れると人を罰し、予定した完了日までに、現れた問題を解決できることを期待しました。

さらに、独立した縦割り部門が、完全に分離した開発の段階を実施しました。たとえば、開発チームは、テストによる検証のチームから完全に独立していました。同じ事業の使命のために働くはずの人々の多くが、互いの名前さえ知りませんでした。

組織が、事業の使命や従業員の職業人としての成熟よりも、このような縦割りの考え方を重視した理由は何でしょうか？

理由は単純で、 マトリクス管理 です。マトリクス管理は、組織の管理と人員配置の仕組みで、1970年代から使われてきました。一見すると、その発想は賢明に見えます。

リーダーは、似た職能や技術スキルを持つ従業員を、同じ縦割り部門、良くても隣接する部門に集め、組織構造を作ります。

マトリクス組織におけるウォーターフォール型のプロジェクトデリバリーモデル

当時の会社には、「コンピテンスセンター」と呼ばれる専門部門がよくあり、それぞれが独立し、自律した縦割り組織でした。

C++開発者の部門、データベース管理者の部門、海外の完全に独立した品質保証部門と、分割は延々と続きました。驚くような状態でした。

マトリクス組織の最大の課題は、スクラムの枠組みとスクラムマスターなしでソフトウェアプロジェクトを届けるために、プロジェクトマネージャーが各部門から従業員を一時的に借りなければならなかったことです。

その従業員は、プロジェクトチームと物理的に同じ場所にさえおらず、各自の専門部門の部屋にとどまっていました。

プロジェクトが終わると、一時的なチームは解散し、参加者は別のプロジェクトの次の仕事へ移りました。

そのため、進行中のソフトウェアプロジェクトが目指す事業価値は、独立した各部門にとって、最優先にはなりませんでした。

自分の仕事を、こちらのプロジェクトで一つ、あちらのプロジェクトで一つと、チェック欄を埋めるように捉える傾向がありました。

リーダーとマトリクス組織モデルは、専門家として、売上、収入、利益を含む最終的な業績の向上に、どう主体的に取り組むべきかを教えませんでした。

McKinsey & CompanyによるMcKinsey Quarterlyの記事も、この点を明確に示しています。 マトリクス組織を超えたコスト最適化の幻想 .

Gartnerは、世界中の組織が毎年、 ITシステムの復旧に6,000億米ドルを費やしている と推計しました。予定外の保守作業と不具合への対応です。

ここで、ソフトウェアプロジェクトで変更管理と障害への対処がどう進んだかを、少し想像してみましょう。ウォーターフォール、マトリクス組織、スクラムなしという構成では、どうなったでしょうか。

そう、そのとおりです。

経営側も従業員も、変更管理、障害、不具合への対処を、そもそも起こるべきではなかった、歓迎されない例外として扱いました。

そのため、変更は遅れと同義になりました。遅れが次々に波及するドミノ倒しがよく起き、チームは、不具合や障害の責任を負わせる相手を探しました。

さらに、各部門には、誤りに対処し、修正し、学ぶ仕組みがなかったため、同じ失敗を繰り返しました。

また、受け身で問題に対処しようとする間に、 技術的負債の量を増やし続けました 。