GreenHopper マネージャーによるスクラムに関する Q&A (前編)

2012-09-20 (Thu)  •  By 伊藤  •  活用のヒント  •  アジャイル開発 翻訳

今回の記事は、アジャイル開発に関するアトラシアン ブログ「Scrum Q&A with the GreenHopper Product Manager 」の弊社翻訳版の前編です。原文と差異がある場合は、原文の内容が優先されます。

ソフトウェア開発チームによるアジャイルへの移行は急速に進んでいます。スクラムは、動作するソフトウェアを期間が固定されたイテレーション (スプリントと呼ばれます) 内にデリバリーすることを重視した開発アプローチです。また、スクラムはもっとも人気のアジャイル開発手法です。アトラシアン アジャイル シリーズの今回の記事では、GreenHopper 製品マネージャーの Shaun Clowes 氏にスクラムへの思いを語っていただきました。

なぜスクラムなのか

スクラムを採用することで、チームはより高品質のソフトウェアをより迅速にデリバリーできます。スクラムは今日のビジネス環境が生まれ持っている不確実性を受け入れ、さらに顧客にとっての価値あるソフトウェアを少しずつデリバリーすることに専念できるようにチームを手助けします。チームは、実際のユーザーの目の前にソフトウェアを提供し、進行中の開発に彼らのフィードバックを取り入れることが可能です。結果として、ユーザーのニーズを予測する必要性が少なくなり、成果物はユーザーの実際のニーズにより「適合」したソフトウェアになります。これにより、チームは関連のない問題の解決をする必要もなくなります。

数年前までは、ユーザーはスクラムが一時的な流行ではないかと考えていました。そのような疑念はすべて払拭されています。スクラムは 10 年近く生き延びていますし、さらには 50% 以上の企業が採用しているくらいに大変人気ですから。

スクラムのメリットとは

伝統的なウォーターフォール型開発プロセスは、初期段階における準備がとても大変です。プロジェクト開始前に、正確な要件およびデリバリーのタイムフレームを理解するためにかなりの労力が費やされます。プロジェクトに費用がかかり過ぎる、もしくは、プロジェクトが不必要であると判明した場合は、この労力はすべて無駄となります。

例えプロジェクトが承認されて作業が開始された場合でも、要件およびスケジュールが確定しており、かつそれがプロジェクト チームに届けられているという考えは間違いです。これは、単に注文を混乱させるわけにいかないからです。つまり、存在しないものにたいして無理強いすることはできません。たとえ要件がどんなに上手に記述されていたとしても、曖昧であったり、不十分なユース ケースは必ず存在します。その結果として、チームは不必要な機能や目的にそぐわないソフトウェアのデリバリーに時間を浪費することになります。要件における曖昧さは、一般的に知られていない問題領域や実装に使用される技術プラットフォームによって増幅されます。多くの場合、この曖昧さは見積がひどく不正確であることを意味しています。チームは見積の増大や工程の省略を迫られることになるため、品質問題の原因となります。

本当にやっかいなのは、計画どおりに製品をデリバリーしたにも拘らず、プロジェクト開始時とと状況が変化していたため、その成果物の関連性や必要性がなくなっている場合です。チームが問題解決に孤軍奮闘している間、市場もしくはビジネス ニーズが大幅に変化しているかもしれません。

スクラムならこのような問題を回避できます。スクラムは必要以上の事前計画を避けるように明確にデザインされています。スクラムではスプリントごとに増分値をデリバリーするため、プロジェクトを継続しつつ、ビジネス ユーザーと協力して要件を共同開発することができます。それ以外にも、会社や市場のニーズが変更した場合に、スクラムは方針を変更することが可能です。

顧客にとってより価値のあるものをより早くデリバリーすることがすべてです。信じがたいかも知れませんが、スクラムはすばらしい結果をもたらします。結果的にスクラム チームは生産性と品質の向上させながらも、コストを削減しています。スクラム プロジェクトは、ウォーターフォール型プロジェクトに比べ、失敗が少ない傾向にあります。また、失敗する場合でもより早い段階であるため、必要以上に時間を浪費することはありません。

他の鍵となる要因には、スクラムがもたらす連携が挙げられます。スクラムは、開発者とマーケティング専門家 (外部プロジェクトの場合) やビジネス ユーザー (内部プロジェクトの場合) が協力して共通理解を確立でき、さらにはこれらユーザーに適合する結果をデリバリーできます。これはより優れたソフトウェアにつながります。また、さらにはすばらしい副次効果がもたらされます。つまり、技術部門とビジネス部門が相互にやり取りすることになるため、やる気および組織の効率性全般が向上します。

チームにとって、スクラム実践を手助けするツールは本当に必要か

ツールの使用は、チームにとって大変有用ですが、必ずしもツールが必要というわけではありません。重要なことは、ツールはスクラムを採用しやすくするということです。手動のスクラム プロセスが自動化や簡略化されるため、チームはアジャイルへの転換に専念することができます。例えば、GreenHopper は、チーム メンバーやスクラムマスターが行わなければならない多くの日常的な課題、例えば、バーンダウン グラフやベロシティ グラフの更新などを自動化することで、チームが集中/専念することを手助けします。

スクラム アプローチにおいてチームが成熟するにつれ、いくつかの理由でツールの重要性に気が付きます。行うべき作業に関するバックログを順序付けて管理することは徐々に困難になってきます。ユーザー ストーリーの数が増大し、他ユーザーからのインプットも取り入れる必要があるからです。スプリントの最中、チームは作業の管理の難しさに気が付きます。さらには、自分たちの進捗を同じ組織内の他ユーザーと共有する手段が必要であることを自覚します。特定のスプリントの結果の追跡や、スプリント間で完了した作業の量の追跡は、時間が経つにつれ厄介になってきます。GreenHopper のようなツールはこのような問題を軽減します。

しかし、これら複雑な問題すべてを考慮した上でも、スクラム ツールが今日の世界で大変重要であることの主な理由のひとつは作業場所の構成の変化です。最近の統計では、チーム全体が同じ場所で作業しているのは 30% 未満となっています。つまり、物理的なウォールボードや立ちミーティングは、価値が大変減少している、もしくは単に非効率的となっています。分散チームが本当に必要ななものは、世界観を全員で共有できるツールです。在宅勤務の割合の増加やチームにおける地理的な分散が引き続き進むため、効率的なツールは絶対的に不可欠となります。

企業がスクラムを選択する前に自問すべきこと

リサーチによると、スクラムの成功を秘訣のひとつが、採用ならびに組織における処理原則への意欲でした (特に幹部関係者)。たとえそれが組織レベルでの大幅な変遷を伴うとしても、変化を心から望み、さらにはスクラムは実行可能な選択肢であると認識する必要があります。それ以外にも、スクラムは特効薬ではないことを理解する必要があります。確かに大変効果がありますが、それは、基本原則が確立しており、かつ変更が上手に管理されている場合に限ります。

しかし、結局のところ、反対に、スクラムを行わない理由を自問すべきでしょう。成功の証拠は揃っていますし、また、同じ人数でより良い結果を残したくない人がいるでしょうか?組織が変化に対して抵抗を感じていることが理由である場合、スクラムを採用している競合他社が競合上の優位性を得ることの危険性を十分に理解する必要があります。スクラムが複雑で採用過程が難航することが理由である場合、役に立つツールを調べることをお勧めします。GreenHopper は、チームによるスクラムのベスト プラクティス、および手動処理の自動化をお手伝いするように明確に設計されています。

ツールの選択にあたり、チームが探すべきこと

スクラム チームの開始にあたり、チームを成功に導くツールが必要となります。チームが探すべきツールは、一般的なスクラムのベスト プラクティスを直接サポートしており、かつ、チームにとって採用や利用がしやすいものが良いでしょう。採用にあたっては、簡潔さが重要となります。ツールが原因でチームの信頼を失いたくないでしょうから。

しかし、それよりもさらに一歩踏み込む必要があります。なぜなら、採用というハードルを乗り越えたら、今度は変化が必要となるからです。例えば、まったく新しいスクラム プロジェクトの場合、行うべき作業は、機能やユーザー ストーリーの短い一覧です。しかし、時間の経過と共に、その一覧は大きくなり、それの管理を補助するためのツールが必要となってきます。また、バグをまとめる必要があります (恐らくたくさん出てくるでしょう)。そして、これらバグに加え、機能を管理するための、統合されたアプローチを備えたツールが必要となるでしょう。プロジェクト チーム単独から組織全体の係わり合いと言った自然な変化により、スクラムを導入していない他チーム (例えば品質管理チームやビルド エンジニアリング チーム) とも情報を共有して作業する必要が出てきます。つまり、ツールはそれらのチームに対して違う見せ方をする必要があります。この成熟過程により、チームはアイテムにワークフローの強化を望むようになります。これにより、チームは自分たちのプロセスが守られます。ツールはこれを実現する必要があります。

また、スクラムは連続した改善に重点を置いているため、チームの要件は引き続き増大することになります。その結果として、チームは定期的に物事をより効率的に行う方法を模索することになります。これらのことにより、チームが自然に求める機能は、関係者がバックログにアイテムを追加している間にもシームレスに 継続的インテグレーションをサポート するスイート、顧客が フィードバックや問題を記録 するために直接アクセス可能なツール、そして スクリーンショットを直接取得 できるツールなどになります。


Related Articles

お気軽にお問い合わせください

お問い合わせ