開発チームを改善するためのスクラムTips インデックス

開発チームを改善するためのスクラムTips

第4回　プロジェクトを予測することの限界、改善法としてのスクラム

文：かわぐちやすのぶ（@kawaguti）
2012/1/30

 

「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。

第3回

■なぜプロジェクトの予測は外れるのか？

プロジェクトリーダー：プログラム1の進ちょくはどうですか？

開発者A：現在、製造に着手しています。

プロジェクトリーダー：期限までにできそうですか？

開発者A：いくつか気になることはあるのですが、なんとか間に合うと思います。

　……1週間後……

プロジェクトリーダー：期限まであと1週間ですが、プログラム1の進ちょくはどうですか？

開発者A：現在、製造に着手しています。

プロジェクトリーダー：期限までにできそうですか？

開発者A：いくつか問題は起きているのですが、期日までにはなんとかリカバーします。

　……1週間後……

プロジェクトリーダー：プログラム1は完成しましたか？

開発者A：すみません。深刻な問題に直面しており、もう少しかかりそうです。

◇◇◇

　なぜ、ソフトウェア開発における予測は外れるのでしょうか？

　理由はシンプルです。「作ってみるまで分からない情報や、顧客や利用者に実物を見せるまで得られない情報があるから」です。

　開発を始める時点の“想定目標”と、実際に目指すべき“本当の目標”がずれてくることは、現場でしょっちゅうあるでしょう。予定どおりに全部作って利用者に提供したら誰も欲しくなかった……なんてこともあり得ます。

　スクラムは、こうした「予測が難しいチーム運営を改善する」ために生まれました。

■プロジェクトは予測不可能な「複雑適応系」

エンジニアライフ コラムニスト募集中！

あなたも＠ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある！ コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中

　スクラムは1993年頃、医療機器を作っていたアメリカのイーゼルという会社で生まれました。

　発案者の1人ジェフ・サザーランド氏はソフトウェア開発プロジェクトの現場で、「リリース直前で失敗が明らかになる」という厳しい現実に直面しました。

　当時の管理手法は「あらかじめ目標を詳細に定義し、スケジュールや人員などの資源を計画し、計画をなるべく正確に守ることで、予定通りの成果物を構築する」というものでした。

あらかじめ目標を詳細に定義する

　しかし、プロジェクトは本来、単純な設計も完全な予測も不可能な「複雑適応系（Complex Adoptive System）」です。さまざまな変化要因が相互に影響して、状況を変化させてしまうからです。

■環境の変化とともに、プロジェクトのゴールは揺れる

　変化要因はさまざまです。市場環境の変化や組織構成が変わる、新技術の登場、プロトタイプを偉い人に見せたらウケてしまって要求水準そのものが変わってしまうこともあります。大海に浮かぶ船が風向きや天気に左右されるように、チームを取り巻く環境は変わります。

最初に決めた目標は、環境とともに変わる

　外部環境ではなく内部環境の変化――例えばチームメンバーが予想外の行動を起こす場合もあります。インフルエンザが蔓えんして、チームメンバーが順に倒れていく……なんて悪夢のような経験がある人もいることでしょう。

■フィードバックと改善で、常に最善の進路を考える

　環境と目標は変化します。変化に対応し、プロジェクトをゴールに導くために、チームは何をすべきでしょうか？

　定期的に「目標」と「状況」の変化をチェックし、チームの進むべき方向を“修正”すればよいのです。

　決められたサイクルで、プロジェクトの変化にまつわる最新情報を集めます。もし、目標が変化していたり、未知の課題が明らかになっていたら、チーム方針を変更します。スクラムでは「バックログ」などを使います（参考：「“なる早”タスクにスケジュールを乱されないための「バックログ」」）。

目標を定期的に見直し、細かく修正をかける

　最悪の場合、新しい情報がシステム自体の失敗を示すこともあります。しかし、それでも、リリース直前に明らかになるよりマシです。

■変化を察知するには、チームは多様であれ

　ポイントは「変化に誰かが気付く」ことです。いくらチェックを繰り返していても、目標や環境の微妙な変化を見逃してしまっては意味がありません。

　この場合、「チームの多様性」がとても重要になってきます。

　例えば、新人ばかりのチームは、達人であればすぐに見つけられるような落とし穴でも見逃してしまうでしょう。たとえベテランであっても、似たような知識を持つ人が集まれば、アンテナが偏ってしまい、ある特定の徴候を皆で見逃してしまうなんてこともあり得ます。

誰かが変化に気付けばよい

　多様な技術、多様なバックグラウンドを持つ人々で構成されるチームの方が、より多様な気付きを得られます。そのため、チームを構成する立場の人は、できる限り多様性を尊重するとよいでしょう。

» ＠IT自分戦略研究所 トップページへ

» ＠IT自分戦略研究所 全記事一覧へ

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）