新しい印刷技術に基づいて高速プリンタを開発するとき、ものごとはどんどん変化する。多くの規律が存在する大規模プロジェクトを管理するための効果的で柔軟なソリューションが必要である。Océ Printing Systemsはスクラムをカスタマイズして協調作業を可能とし、進捗を見える化するためにスクラムをスケールさせることを決めた。
ドイツのミュンヘンにあるOcé Printing SystemsのソフトウェアプロジェクトマネージャであるChristian Sack氏と、R&Dの部門マネージャであるJohn Kesseler氏はSoftware-Centric Systems Conferenceにおいて、ソフトウェア開発者、機構エンジニア、化学者、物理学者、テスターから構成される大規模プロジェクトチームにより、新しい技術のプリンタを構築するためどうスクラムをスケールさせたかについて講演を行った。
InfoQはSack氏とKesseler氏にプロジェクトが直面した主な課題、どうスクラムをカスタマイズして導入したか、アジャイルな方法で仕事をすることに対して電子・機構エンジニアがどう感じたか、スクラムがプロジェクトやR&Dの組織にもたらした利点、そして現在取り組んでいる挑戦と対応計画についてインタビューを行った。
InfoQ: Océのプロジェクトで直面した主な課題はいつどのようなものがあったのでしょうか?
Christian Sack氏とJohn Kesseler氏:印刷技術の開発と同時にプリンタを開発する必要がありました。ですから開発中本当に多くの変更を管理する必要がありました。また、短期間にこのプロジェクトに従事する超大規模なチームを結成しました。複雑な組織の業務を行う必要がありました。その上このプリンタのプロトタイプを評価するリソースは本当に限られていました。
InfoQ: その必要を満たすためにスクラムをどうカスタマイズしたのでしょうか?
Sack氏とKesseler氏: チーム間で優先度を決定するために、プロダクトオーナーの階層を導入しました。全体のプロジェクトマネージャに密着した形で、マスター製品のオーナーの委員会がリクエストされた機能性の優先度を設定することによりリソースの競合を解決することを支援しました。
優れたソフトウェアアーキテクチャ、他のソフトウェア以外のコンポーネントとの依存性、そして組織のインターフェイスが開発者の内面で塾考される必要があります。私たちはスケールされたスクラムのアプローチであるSAFe (Scaled Agile Framework)のプラクティスを採用することにしました。プロダクトオーナーとソフトウェア専門家から構成される、新たに導入されたソフトウェアアーキテクチャチームが前もって要件をよく検討し、アーキテクチャの実装を計画します。
要件分析は2段階で行われます。最初に要件は議論され、レビュー内でこれらのエピックを実装するためのコストが決定されます。コストはエピックポイントで推定されます。エピックポイントはストーリーポイントに相当するものであり、他のエピックとの相対的な推定される努力の量を表します。これにより複数のリリースをまたいだロードマップを作成することができます。次のステップで、次のリリースで実装されるべきエピックがユーザストーリーに分解され、それから個々のユーザストーリーレビューで議論されます。これらのレビューでは必要なスキルが特定されます。これはスクラムチームの編成のための大きな助けとなります。
コスト見積もり、エピックの間の相互関係、そして分析の両方のステップで実施される重要な専門家による検証の詳細説明に関して支援を提供するための、強制力のあるチェックリストが作成されました。全てのチェックリストが問題のない場合だけ、解釈の定義(DoR)がアーキテクトチームにより作成されます。このDoRを満たすエピックとユーザストーリーだけが次のリリースのために計画されます。この活動はバッグログの品質を高め、スクラムチームが予測可能なスプリント結果を残すためにとても貢献します。
そのうちに、リリース毎にチームが平均でどれくらいのエピックポイントを実装できるか(エピックベロシティ)がわかります。エピックポイントにより見積もりが行われ、マスター製品オーナーにより優先度の明確化を行うことにより、1年に対応する約3回のリリースの実現可能なロードマップを計画することが容易となります。エピックレベルでの要件の実装に対する透明性は総合プロジェクトリーダーにとって非常に有用であり、主要プロジェクトレベルにおける決定の重要な土台となりました。
既に述べたこれらのスクラムのカスタマイズに加え、以下のようないくつかの改良も行いました。
- JiraAgileと呼ばれるスクラムプロセスをサポートするwebベースのツールの導入
- プロジェクト進捗に関する、例えば問題になるリソースのボトルネックを早期に共有するなどの議論を行うための全てのスクラムマスターとプロダクトオーナーが全員出席するセッション
- 現在のスプリントゴールに関係しない話題、主に技術的負債や実験的な試みに関する作業を取り扱う、週一回のいわゆるスクラムフリーデイ
InfoQ: スクラムを導入するために行った、通常のトレーニングやコーチング以外の取り組みについて詳しく教えて頂けますか?
Sack氏とKesseler氏: 私たちは技術者の中からプロダクトオーナーを選ぶことを決めました。なぜなら彼らは必要な機能性に対するベストなノウハウを持っていたからです。24人の技術者をスクラムチームのプロダクトオーナーとするためにトレーニングしました。
最初は、訓練したてのスクラムマスターはスクラムチーム内の問題に対処するための経験に欠けていました。例えば、彼らはチームの摩擦を解決することを難しいと感じていました。そこで調整、プレゼンテーション、コミュニケーションと摩擦のマネージメントに関する追加のトレーニングを受けさせました。これが功を奏し、彼らが新しい役割をより効果的に果たす場面が見られるようになりました。
InfoQ: スクラムチームには電子、機構エンジニアがいるとお話しされていました。アジャイルのやり方で仕事をすることについて彼らはどう感じたのでしょうか?
Sack氏とKesseler氏: プロジェクト開始時にはスクラムに対する抵抗がありましたが、導入の後すぐに減りました。ソフトウェア分野ではないメンバーは、彼らはスクラムがソフトウェア分野の人々と統一された規律で業務を行うことを円滑にしたと感じました(逆もまた同様です)。
InfoQ: スクラムによってどのような利点がプロジェクトに対してもたらされたのでしょうか?また、R&D組織に対してはどうでしょうか?
Sack氏とKesseler氏: スクラムは技術者の間、そしてソフトウェアエンジニアと品質保証部門のメンバーの間の協調とコミュニケーションを改善しました。スクラムチームはいくつかの規律を象徴しています。問題を単に指差す代わりに、問題を解決する責任をチームが持っていると感じたことに気づきました。
各スクラムチームには品質保証メンバーがおり、テスト要件は最初からチームに与えられていました。これは明らかにデリバリーの品質を向上させ、開発終盤に長い品質保証期間を取ることをしなくて良くなりました。結合やシステムテストの期間が短くなっただけでなく、予測可能となりました。リリース計画の信頼性が大きく向上したのです。
バーンダウンレポートは進捗の透明性を確保するのに大きく貢献しました。また、プロジェクトのボトルネックとプロジェクト計画からの逸脱がより可視化されるようになりました。
InfoQ: アジャイルに関して現在取り組んでいる挑戦は何でしょうか?また、それらをどう取り扱うつもりでしょうか?
Sack氏とKesseler氏:プロトタイプに必要な費用が高額のため、とても制限されたハードウェアしか持てないことが常にプロジェクトの課題となっています。ですのでチームはテストに必要なハードウェアを競うように使うことになります。これが繰り返されると、チームは開発したソフトウェアをその場でテストすることができない事態が発生します。この課題に対してシミュレーションとテスト自動化に対し更に投資することで対処しています。そして、ある場合では互いが影響しないように並列実行することができるようにしています。後者の戦略は同じスプリントで構築する機能が互いに独立している場合にのみうまく働きます。
スケールされたスクラムが成功したので、スケールできるサイズに依存しますが他のプロジェクトにスクラムを導入するつもりです。必要な箇所があれば、何か新しい具体的な適応方法を導入しようと思います。また、オーバーヘッドを最小にするために、既存のプロジェクトロールとスクラムのロールを統合する必要があります。
Rate this Article
- Editor Review
- Chief Editor Action