はじめに
ソフトウェアプロジェクトにまつわるすべての事象は、良いことも悪いこともすべて管理者の責任です。管理者が配置した人材が適切だったかどうか、あるいは管理者がプロジェクトに積極的に関与していたかどうか、といった点が問われます。
管理は決して容易ではありません。プロジェクトを成功または失敗させる要因は数え切れないほどあります。最も望ましいのは、目覚ましい働きをする優秀な人材に恵まれた環境です。たまたま第一級のチームを率いていれば、あまり有能でないソフトウェア管理者でも、その能力をよそに成功を収めることができます。第一級のチームが収める成果はすべて管理者の功績になります。
その反面、失敗をチームのせいにすることは難しくなります。問題に遭遇したときに、それを解決するのは管理者の責任だからです。この記事では、アジャイルソフトウェアプロジェクトを管理する際に役立つヒントと知識を紹介します。
この記事はもともと『CoDe Magazine』の2008年5月/6月号に掲載されたものです。許可を得てここに転載しました。
アジャイルを目指す
リーン（Lean）、エクストリームプログラミング（Extreme Programming: XP）、スクラム（Scrum）――おそらくこの3つが、最も有名なアジャイルフレームワークでしょう。しかし私の考えでは、これらはいずれも単独では不十分です。
現時点で最もよく知られているのは（少なくとも私の周囲では）スクラムだと思われます。人々がイテレーション（反復）を「スプリント」と呼ぶのを耳にする機会がますます増えています。管理者たちは自分の部下をあちこちのスクラム研修に送り込んでいます。
けれども、XPなしではスクラムは無防備です。スクラムでは技術的なプラクティス（実践項目）に関する指針があまり示されませんが、プロジェクトにソフトウェアが関係している限り、技術的なプラクティスは重要な鍵となります。
チームを管理するときは、技術的な指針を適切に示すことを忘れないでください。私は、リーン開発の原則に従って管理し、スクラムのフレームワーク内でプロジェクトを運用し、XPによってソフトウェアを作成すると優れた成果が得られることに気付きました。これらの手法はかなり相補的に作用します。
個々のアジャイル手法の詳細については読者に調べていただくことにして、ここではプロジェクトを管理し、アジリティを目指して努力する際にどのような事柄に注意を払えばよいかについて特に説明します。
アジリティとは、顧客や製品オーナーの要求に合わせて絶えず進路を変更し、適応する能力だと考えてください。ソフトウェアはリリース2日目とまったく同じ保守性を維持する必要があります。また、プロジェクトとそれ以降のリリースのペースは安定している必要があります。
