巨大で複雑なシステムを開発し、レガシーコードを扱うとき、企業は統合とデリバリを支援するシステムが必要だ。モジュール化はアジャイルが複数のチームで並列に働きならがスケールするのを助ける。この仕事をするのは、フレームワークや方法論ではない。Hans Dekkers氏によれば、問題解決のためにチームのメンバがどのように働くか、が重要だ。
Bits&Chips Software Engineeringカンファレンスは6月3日にオランダのアイントホーフェンで開催され、3つのセッションがあった。スクラムでは不十分というセッション、そして、デリバリトレインをブーストする、実世界のモデル駆動エンジニアリング、という3つのセッションだ。アムステルダム大学の情報学研究所で講師をしながら、マネジメントコンサルタントもしているHans Dekkers氏は最初のセッションを仕切った。
スクラムは小さなチームでうまくいきます。反復的に新しい機能を追加するのです。従来の開発者をスクラムで働くように転換させるにはどうしたらいいでしょうか。複数のチームを協調させるにはどうすればいいでしょうか。レガシーコードはどのようにメンテナンスすればいいでしょう。アジャイルいよってハイテク産業の抱える課題の解決はどのように広まるのでしょうか。このセッション"スクラムでは不十分!"は、このような困難について振り返り、ベストプラクティスを紹介します。
InfoQはHans Dekkers氏にこのセッションについてインタビューし、レガシーソフトウェアの難点やアジャイルな対処方法、アジャイルのスケール、他のフレームワークとスクラムの組み合わせについて話を聞いた。
InfoQ: "スクラムでは不十分!"というセッションを取り仕切りました。なぜこのセッション名にしたのですか。
Dekkers: スクラムは開発チームを運用のど真ん中におき、頻繁なデリバリとフィードバックのサイクルを保証します。こうすることで、チームが決めなければならないことはたくさん生まれます。
ソフトウェアプロジェクトのパフォーマンスはアーキテクチャの適合具合にかなりの割合で依存します。多くのプロジェクトで、スプリントの境界を越える目的を達成するのに必要なエンジニアの数は増えています。異なる利害関係者の間で適切なトレードオフを見つけなければなりません。また、ユーザの調査に基づいた、優れたインタラクションの設計が必要です。統合やデリバリを支援するシステムが必要です。
多くの企業で、スクラムは優れたパフォーマンスを発揮するためのより大きな組織(プロセス、文化、仕組み)に埋め込まれています。このセッションでは、これがどのように実現されているのか、私たちにはどのような選択肢があるのか、どのようなトレードオフがあるのかについて話をしました。
InfoQ: セッションは、個別の講演ではなく、異なる組織に属している話者同士が特定のトピックについて議論するという形になりました。どうしてこのようにしたのですか。
Dekkers: 目的は困難な点に注力することです。つまり、よりしっかりと定義された問題や野心について話したかったのです。全体の流れとしては、まず、最初の話者が自身の困難な点について話をし、何が行われたのかを説明します。そして、他の話者がそれを分析し、ソリューションを提案します。このソリューションはそれぞれの経験に裏打ちされています。また、研究やコンサル活動も根拠になっています。ひとつの困難な点にも複数の側面があるということを示したかったのです。そして、異なる選択肢を提示し、刺激的な議論に話者と聴衆を巻きこみたかったのです。
InfoQ: レガシーソフトウェアへの対処が議論のひとつに上がりました。企業が直面しているこの大きな問題について、教えてください。
Dekkers: レガシーなソフトウェアは私たちを取り囲んでいます。多くのプロジェクトがこの文脈で動いています。多くの既存のソフトウェアが生み出す環境の中で、企業はその制約を受けながら動かなければなりません。ひとつの大きな問題は神のコンポーネントとよばれるもの、すなわち、すべてのユーザストーリーがそのコンポーネントの変更を要求してしまうようなコンポーネントです。また、複雑なソフトウェア環境で回帰テストや継続的ビルドをどのように構成するかについても大きな問題です。よりアジャイルになるには、プロセスの変化だけではなく、ソフトウェアのインフラの大きな変更お必要だと考えています。しかし、それはどのように組織化すればいいのでしょうか。
InfoQ: レガシーなソフトウェアを管理するためのアジャイルな手法を採用している企業の例を知っていますか。彼らはどのようにしてそれを実現しているのでしょうか。
Dekkers: ASMLは、自分たちのソフトウェアの環境で、スクラムの要素を使ったプロセスでの働き方について語っています。ロッテルダム港のプロジェクトは、スクラムベースのプロセスを採用して成功し、古いレガシーシステムを排除しました(このプロジェクトについてはInfoQでHaMIS: One 24/7 Product and Four Scrum Teams, Four Years Laterという記事で取り上げている)。
また、PhilipsとABN AMROはレガシーなコードが支配的な環境でもっとアジャイルな方法を採用しています。ABN AMROは新しい開発でのスクラムの実践とレガシーコードのメンテナンスでのスクラムの実践に違いはないと言っています。DevOpsチームがあるからです。
DevOpsへの投資やソフトウェアのリノベーションへの投資は、重要であり、成功のための前提だと思います。スクラムは顧客の最終的な目的への明確な貢献をするチームの上に構築されます。チームがコンポーネントごとに作られていて、コンポーネントで完了する必要のある作業とユーザストーリーの関連が明確でない(クリアなAPIでない)場合、スクラムの中核的なアイディアは有効性を失います。全体を調整する仕組みが必要なのです。この仕組みには計画することが含まれます。つまり、事前に仕様を策定し、最後には統合テストをするということです。スプリントの間に、新しい設計と共にチームで生まれるコンセプトは大きく制限されます。できるのは、部分的な最適化だけです。しかし、システム理論学者が示すように、私たちは常に全体にフォーカスを当てて最適化をするべきです。
また、学習能力もアジャイルでは重要な役割を果たします。スプリントの後、製品は配置の準備ができているという考えを実現するためには、スプリントの間に、自分たちの仕事の連携具合について、フィードバックが必要です。このフィードバックが生まれない環境の場合、学習と応答の能力は失われます。
InfoQ: アジャイルのスケーリングについても取り上げていましたね。企業がアジャイルをスケールするときに活用できるアプローチについて教えてください。
Dekkers: 複数のチームが並列で動くようにスケーリングするのに一番必要な戦略はモジュール化だと思います。チーム間の依存関係を低減するアーキテクチャを採用するべきです。しかし、協調の問題は常に残ります。必要なのは、事前の調整と統合、そして、スプリントの間の調整です。これに対処する拡張フレームワークがあります。SAFeフレームワークです。これは、企業に異なるチームがすべての規則や要件を満たすように働くことを保証する機会を与えます。また、Scrum.orgによるNexusフレームワークもあります。このフレームワークのエッセンスは、スクラムを制度化することによって、組織の構造で開発者の動きを促すということです。
InfoQ: スクラムと他のフレームワークを結合したいと思っている組織に向けて、アドバスをお願いします。
Dekkers: 自分自身の問題を見つめてください。仕事をするのは、フレームワークや手法ではありません。チームでそのフレームワークや手法をどのように活用するかが重要です。自分にとって何が有効なのかを明らかにしてください。オープンで、実験的で、学習し、改善することを忘れないでください。批判的かつ建設的なアプローチを実践してください。