---

スクラム以前には、何が混乱といら立ちを生んだのでしょうか？意外な発見があるかもしれません！

スクラムがソフトウェアエンジニアリングの実践と事業に与える影響を理解するため、プロジェクトの一日を見てみましょう。

組織にスクラムによる開発とデリバリーを取り入れる前の、過去のプロジェクトを少しお話ししたいと思います。

これを書いた数日前、ほぼ20年前に一緒に働いた元同僚と昼食を取りました。

マーカスは、 スクラムマスター認定資格 や スクラムプロダクトオーナー認定資格 を、 International Scrum Institute™で取得しました。現在は、アジャイルプロジェクト管理ソフトウェアの分野で、主要なソフトウェア企業の一つに、スクラムマスターとして勤務しています。

世界各地に分散するメンバーから成る、アジャイルなスクラムチームの支援を担っています。

昼食中、マーカスは、分散したアジャイルなスクラムチームには、典型的な課題が多いと認めました。自分のプロジェクトの構成に関して、特に挙げた問題は、次のとおりです。

• メンバーの働き方の違い。
• 時差。
• 文化の不一致。
• 言語の制約。

それでもマーカスは、アジャイルなスクラムのプロセスでプロジェクトを進める方が、20年前よりも楽しく、生産的で、充実していると付け加えました。 スクラムによる開発とデリバリーを使わなかった時代と比べて、ということです。

優れた経験豊富なマネージャーであり、スクラムマスター、プロダクトオーナーでもあるマーカスの発言は、スクラムの価値を示す、大きな証言でした。

ありがとう、マーカス！

次に、スクラムを採用する前の、私たちの過去のプロジェクトを説明しました。認定資格を取る前の自分のプロジェクトにも、似た経験があったと思うスクラムマスターは多いでしょう。

1990年代後半、私たちは、スマートカードを使う 公開鍵基盤を構築する開発グループにいました。スマートカードが参加者の秘密鍵を安全に保護し、対応する公開鍵と、それを包む証明書は、名前のとおり公開して配布しました。

当時、それ自体が比較的複雑なITプロジェクトで、相互に依存する複数のハードウェアとソフトウェアの開発チームが必要でした。膨大な、 研究開発（R&D） を行い、完全に機能するハードウェアとソフトウェアのシステムを作る必要がありました。

このプロジェクトでは、まだ、 実用最小限の製品（MVP） という考え方で、実験し、作り、学び、再び試すことを行っていませんでした。

スクラムなしで、多数のハードウェアとソフトウェアの要素から成る高度な基盤を作るのは、大きな課題でした。

次に、 三つの重大なつまずき を紹介します。当時のチームには、スクラムマスターも、認定資格を持つ人もいませんでした。