スクラムは現実解 (arclamp.jp アークランプ)

アジャイル開発というとXPに代表されるようなエンジニアリング的な要素が強いように感じられる。しかし、プロジェクトマネージメントをアジャイルにすることの方が重要だと思っている。僕が気に入っているのはスクラムだ。既に書籍が出ており、かなり明確に体系化されている。スクラムのプラクティスがなにかというのはWebや本で探ってもらうとして、なぜスクラムが良いのか・なにが難しいのか、というあたりを書いてみたい。

スクラムの良さ
スクラムの良さはタイムボックスによるコントロールだ。ソフトウェア開発は、要件も技術要素も非常にあいまいで、ようはやってみなくては分からないことが多い。とはいえ何も基準がないのでは混乱をきたす。そこで、ある時間枠（土日を含む30日間）を基準とする。
チームは少人数（7人前後）で構成されており、自分達で期間内の作業にコミットする。作業ゴールは必ずテスト済みの動くアプリケーションであることが求められる。メンバーは日次のミーティングを基点にコラボレーションしながら、自由に作業を進めてよい。自分達がコミットした作業に向かうため、チームは自己組織化される。
なお、その期間に行うべき作業はクライアントが優先順位を決定している。期間の終了ごとに、動くアプリケーションを見ながら次の期間のプライオリティとリスクの判断が出来るため、顧客価値に重きを置くことができる。

簡単にいえば「さぐりさぐり」ということである。ソフトウェアに限らず、リスクの高いプロジェクトの場合には小さな単位で試行するというのは当たり前の概念だろう。

XPと比べてみると「計画ゲーム」や「小規模リリース」は具体的になっているだけ、「テスト」「リファクタリング」「コードシェア」「インテグレーション」「コード基準」などは、もはや常識なのでスクラムを実現するよい助けとなるだろう。ようは、XPが技術に焦点があるだけの話で、スクラムを実現しようとするとXPの大半のプラクティスは導入することになるだろう。

ちなみにこうした手法の反対がウィーターフォールに代表されるプロセス定義型のマネージメントだ。こうした管理手法は、完全に作業内容が理解される場合のみ有効だ。機械の製造過程に似ている。しかし、そうでない場合こうした管理手法は確実に破綻をきたすことになる。

スクラム適用への壁
さて、こうしたスクラムを通常の企業アプリケーション開発プロジェクトで採用するには大きな壁がある。1つ目は最終リリース日へのコミットメント、2つ目はチーム構成、3つ目は自己組織化である。

1つ目の"最終リリース日へのコミットメント"を考えてみる。通常、プロジェクトはリリース日が1年後と決まればそれに向けて作業を行う。ところがスクラムは1ヶ月間のことしか約束をしないため、1年先の事なんかわかるわけがない。しかし、そんな立場では案件は取れないだとろう（これが許されるのはインハウスの開発チームであり、スクラムの多くの事例がこれに当たる）。

Schwaber氏も

固定価格・固定期日の契約でスクラムを使用することは、たしかにチャンスではありますが、これが顧客がスクラムの使用についての聞き方を知っていて、聞く意思を持っているときにだけ有効です。

と述べている。そのため、現状では固定的な約束をせざるを得ず、その後、クライアントをいかにスクラムの価値に引き込むかというのが焦点になる。

特に難しいのが"遅れの管理"と"プライオリティの決定"だと感じる。

ほとんどの場合、開発作業が始まる前に固定的で遠大なプロセスを定義させられることになる。もちろん、そのプロセスが実体に沿っていればそれでよいのだが得てしてそんなことはない。というわけでスケジュール上の遅延が発生する（不思議なことに前倒すことはまずない）。しかし、システム開発の難しさを理解しているクライアントであれば、こうした遅れが仕方がないことでと理解してくれるはずだ。そこで、ある時点で全体スケジュールを見直して路線を修正する。これを「リスケ」と呼ぶ。
笑っちゃうのだが僕の経験では「毎週・毎月リスケする」というのが一番分かりやすい説明なようだ。リスケというとネガティブな印象が強いが、スクラムの場合は織り込み済みなわけで、むしろポジティブに行う作業になる。そうなると現場担当のクライアントは妙に納得してくれて、逆にスケジュール組み変えるPMの方が不安がる場合もあったりする。

こうした短期間でのリスケで重要なのがプライオリティだ。プライオリティはビジネスニーズとリスクによってのみ判断されなくてはいけない。よく「簡単なら先に消化してしまおう」というのがあるが、簡単でプライオリティが低いものは、スケジュールの遅延が発生した場合にでも調整が付きやすい。
例えば難易度が高い作業Aが5人月で、難易度が低い作業Bが5人月の場合、10人のメンバーがいたらAとBに5人ずつで1ヶ月と考えがちだ。なぜなら難易度が低く確実な作業をとりあえず終わらせて進捗をあげたいからだ。しかしこれは間違っている。Aに10人を投入すべきなのだ。1ヶ月あれば作業Aだけでも終わる可能性は高い。作業Bは終わらないかもしれないが、確実に見えているものであれば不安だが解決策は建てやすい。一方、5人・5人の場合、作業Bは終わるかもしれないが、作業Aが終わらないかもしれない。作業Aは複雑なので、あとどれくらいで終わるのか良くわからない。これは危険な状態だ。
この考え方は「とりあえず進捗を進めて、消化数を大きくしたい」というニーズとの戦いになる。断固戦うべきだろう。

2つ目のチーム構成を考えてみる。例えば、1チーム20人のソフトウェアエンジニアが実装作業にあたってもまずうまくいかない。20人がフラットな組織でコラボレーションするのが不可能だからだ。スクラムでは7人前後が推奨されている。しかし、7人＊3チームでよいかというと、そんなこともない。
僕の経験では、複数チームになると、それらのチームを調停したり、共通部品を作成したり、仕様を管理するためのチームが必要になる。ようは20人といっても、5,6人のチームが３つと2,3人の共通支援チームという構成になるのが良いようだ。
また、スクラムでも強く推奨されているのが、最初は1チームでアーキテクチャを構築するというものだ。これは非常に大事なことで、これの出来いかんですべてが決まるといっても過言ではない。
また要員追加にも注意が必要だ。誰もが無理だとわかっていながら、人を追加したら生産性が伸びると思っている。しかし、新メンバーの受け入れは非常に大きなリスクとなる。スクラムは人に依存しているため、機械の生産ラインと比べると教育コストは非常に高い（これはアジャイル的手法を学んでいるエンジニアが少ないという現状にも影響されているのだが）。そのため、どんな要員かによって教育コストのかかり方も、生産性もわからない。これは大きなリスクである。
そのため1ヶ月の区切れで、十分に受け入れ態勢をとったうえで、かつスケジュールに教育日を加えて挑まなくてはいけない。またスクラムの精神を伝えるためには、各チームに旧メンバーを配置する必要性もある。突然、2倍や3倍に人を増やす事は不可能である。
突然、人を雇い入れるお金があるならチームの生産性をあげるために、オンサイトクライアントの実施、技術コンサルタントの雇い入れ、早くて大画面のPC、空調が効いた部屋、立派な机とイス、おかしを用意したほうが良い。安いもんだ。

3つ目の自己組織化は非常に難しい問題だ。スクラムの価値は自己組織化されたチームであり、様々なプラクティスはその手法に過ぎない。開発リーダーは、促進者、支援者、アドバイザー、コーチである。決して指示する人ではない。長い間の管理手法になれていると、このシフトにリーダーもメンバーも気づかない。
まずリーダーは、自身の発言を控え、メンバーの発言を促すことだ。日次のレポートも、メンバーに話させなくてはいけない。決して、リーダーが「昨日何をやったか？」と聞いてはいけない。メンバーに「昨日＊＊をやりました」と発言させるのだ。
メンバーでは、特に"プログラミングとは、与えられた課題をどれだけうまく作れるかということ"と信じているエンジニアには注意が必要だ。彼らは優秀な人材かもしれない。しかし、スクラムに参加してもらうからには変わってもらわなくてはいけない。仕事は与えられるものではなくて、作るものなのだ。

スクラムは現実解
なんにせよスクラムというのは現実的で常識的な手法だと思う。これまでの手法とは異なるが、決して亜流ではない。Schwaber氏は、

Markは、CMMはソフトウェア開発に対する組織の成熟度を記述するためのフレームワークに過ぎないといいました。組織がそのフレームワークをどうやって満たすかは、組織次第です。
スクラムは経験的手法を採用していましたが、スクラムのプラクティスを採用すると、CMMレベル２のKPAすべてと、レベル３のKPAの多くを満たすのです。

と述べている。

「アジャイルでは管理できない」という発言を聞くことがある。しかし、考えて欲しい、あなたが管理しているものは何なのか。アジャイルは遠大な定義済みプロセスを進めるには向かない。しかし、プロジェクトをクライアントが満足するようにコントロールすることが出来る。だからクライアントから失敗だと認識されることが少ない。
どうか、エンジニアは戦って欲しい。スクラムには価値がある。ソフトハウスであれば、"頭の良い"クライアントに対して実際に使ってみて欲しい（社内プロジェクトでは意味がない）。結果は必ずでる。

なお、2冊の本は並んでいる順に書かれた。2冊目のスクラム入門はより実例が豊富で読みやすいのでオススメだ。これは、1冊目がプラクティスの紹介に注力しすぎてスクラムの精神を伝え切れなかったよう反省から書かれたものだからだ。まず2冊目、つぎに1冊目がよいだろう。