モラルと技術−パート２

プロジェクトにおけるモラルと技術について考える、２部構成の第２部。第１部はこちら。第２部ではスクラムが抱えている問題点と、プロジェクトを技術的に下支えする共通基盤チームについて考察する。（この記事は、今年３月にパート１のみ公開していたものを整理したものです。）

スクラムの問題点

もうだいぶ前のことになりますが、James Shore氏のブログ記事「James Shore: The Decline and Fall of Agile」に端を発した、スクラムについて再考する動きがありました。M. Fowlerがブリキに「FlaccidScrum」を載せていたことは記憶されている方も多いのではないかと思います。さて、「モラルと技術」と題した２部構成記事の前回では、スクラムのプロダクト・オーナーのモラルについて「Agile Software Development.com」の記事を題材に考えてきました。今回は、「コミットメント」という課題をクリアした上でなお残る、技術的な問題について考えるために「脆弱なスクラム」問題について振り返ってみたいと思います。

スクラムが内包する問題点は、「技術的なプラクティスを含んでいない」という点に集約されます。

But because Scrum works in short cycles and doesn't include any engineering practices, it's very easy for teams using Scrum to throw out design. Up-front design doesn't work when you're using short cycles, and Scrum doesn't provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt.

しかし、スクラムは短いサイクルで機能する上に技術的なプラクティスを含まないので、スクラムを適用したチームが設計をおざなりにするということが至極簡単に起こってしまいます。アップフロントな設計は短いサイクルではうまくいかないし、だからといってスクラムが代わりのものを準備している訳でもありません。継続的でインクリメンタルな設計をしなければ、スクラムチームはすぐに技術的借金という墓穴を掘ることになってしまうのです。
James Shore: The Decline and Fall of Agile

簡単に言えば、「アジャイル開発にとって技術的な要素は重要なのだが、スクラムにはその方法論はない。したがって技術的な要素を無視してスクラムの方法論だけを推し進めると大きな問題が発生することがある」ということなのですが、そういったことを踏まえてShoreはスクラムを擁護します。

It's not entirely Scrum's fault. Agile development isn't just about good engineering practices. It's also about acknowledging the importance of people in software development, forming cross-functional teams, obtaining high-bandwidth communication, constantly reflecting and improving, delivering value, and changing plans to take advantage of opportunities.

しかし、それがスクラムの責任だということはまったくありません。アジャイル開発とは技術上の優れたプラクティスに関することだけではないのです。アジャイル開発とはソフトウェア開発に携わる人々こそが重要なのだということを認識することであり、様々な職務を横断するチームを形成することであり、広帯域なコミュニケーションを手に入れることであり、定期的ににふり返り、改善し、価値を提供し、機を得て計画を変更することなのです。
James Shore: The Decline and Fall of Agile

その上で、重要なのはスクラムを適用したプロジェクトが、スクラムの方法論には技術的要素が含まれていないということについて自覚的であるということでしょう。Fowler氏は「脆弱なスクラム」にてスクラムを擁護しつつ、次のように語っています。

In defense of Scrum, it's important to point out that just because it doesn't include technical activities within its scope should not lead anyone to conclude that it doesn't think they are important. Whenever I've listened to prominent Scrummers they've always emphasized that you must have good technical practices to succeed with a Scrum project.

スクラムを擁護する上で重要なのは次の点を指摘しておくことでしょう。スクラムが技術的活動をスコープに含んでいないという理由だけでスクラムが技術を重要だと考えていないと結論づけるべきではありません。スクラムに慣れた人の話を聞くと、スクラムプロジェクトを成功させるためには優れた技術的なプラクティスを持たなければならないことが強調されます。
FlaccidScrum

その上でFowler氏はスクラムを技術的に補うものとしてXP(Extreme Programming)を提示します。

If you're looking to introduce scrum, make sure you pay good attention to technical practices. We tend to apply many of those from Extreme Programming and they fit just fine. XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work. Sniping aside, the XP practices make a good starting point - and are certainly going to be much better than doing nothing at all.

もしスクラムを導入しようと考えているのなら、技術的なプラクティスに対して充分な注意をはらって下さい。私たちはよくExtreme Programmingのプラクティスの多くを適用していますが、これはちょうどよく当てはまります。XP実践者がよくジョークとして次のように言います（ある程度は正しいのですが）。「スクラムはXPから技術的プラクティスを取り除いたものだ。でも、この技術的プラクティスこそが、XPを機能するものにしているのに。」これは置いておくとしても、XPのプラクティスは優れたスタート地点になります。そして間違いなく、何もしないよりは何かをした方がはるかに良いのですから。
FlaccidScrum

技術的考慮の囲い込みと業務的視点での実装

「技術的なプラクティス」が重要であることを疑う余地はないと思いますが、開発者の人数が増えれば増えるほど「プログラミングにおける基本的な作法を理解した上での実装」自体が難しくなってきます。この問題に対する解の一つとして、技術的な問題を専門のチームに囲い込むというものが考えられます。こういったチームは、一般的に「共通基盤チーム」という名前で呼ばれることが多いようです。このチームのミッションは、一言で言うと方式設計および標準化ということになりますが、このような観点から見た時に特に重要になるのは、業務的視点からアプリケーションの処理方式を定め、アプリケーションの設計／実装をできる限り「業務」に近い所で実施できるようにプロセス／フレームワークを整備するということになるでしょうか。

もっともこの戦略が成立するには「画面数が多く、かつ、１つ１つはトランザクションスクリプトでシンプルに実装できる」という前提が必要になります。いわゆる「ドメイン駆動」とは対称的なパターンですが、実際には多くのプロジェクトおいて有効であるように感じています。