アジャイルソフトウェアプロジェクトを管理する

はじめに

　ソフトウェアプロジェクトにまつわるすべての事象は、良いことも悪いこともすべて管理者の責任です。管理者が配置した人材が適切だったかどうか、あるいは管理者がプロジェクトに積極的に関与していたかどうか、といった点が問われます。

　管理は決して容易ではありません。プロジェクトを成功または失敗させる要因は数え切れないほどあります。最も望ましいのは、目覚ましい働きをする優秀な人材に恵まれた環境です。たまたま第一級のチームを率いていれば、あまり有能でないソフトウェア管理者でも、その能力をよそに成功を収めることができます。第一級のチームが収める成果はすべて管理者の功績になります。

　その反面、失敗をチームのせいにすることは難しくなります。問題に遭遇したときに、それを解決するのは管理者の責任だからです。この記事では、アジャイルソフトウェアプロジェクトを管理する際に役立つヒントと知識を紹介します。

アジャイルを目指す

　リーン（Lean）、エクストリームプログラミング（Extreme Programming: XP）、スクラム（Scrum）――おそらくこの3つが、最も有名なアジャイルフレームワークでしょう。しかし私の考えでは、これらはいずれも単独では不十分です。

　現時点で最もよく知られているのは（少なくとも私の周囲では）スクラムだと思われます。人々がイテレーション（反復）を「スプリント」と呼ぶのを耳にする機会がますます増えています。管理者たちは自分の部下をあちこちのスクラム研修に送り込んでいます。

　けれども、XPなしではスクラムは無防備です。スクラムでは技術的なプラクティス（実践項目）に関する指針があまり示されませんが、プロジェクトにソフトウェアが関係している限り、技術的なプラクティスは重要な鍵となります。

　チームを管理するときは、技術的な指針を適切に示すことを忘れないでください。私は、リーン開発の原則に従って管理し、スクラムのフレームワーク内でプロジェクトを運用し、XPによってソフトウェアを作成すると優れた成果が得られることに気付きました。これらの手法はかなり相補的に作用します。

　個々のアジャイル手法の詳細については読者に調べていただくことにして、ここではプロジェクトを管理し、アジリティを目指して努力する際にどのような事柄に注意を払えばよいかについて特に説明します。

　アジリティとは、顧客や製品オーナーの要求に合わせて絶えず進路を変更し、適応する能力だと考えてください。ソフトウェアはリリース2日目とまったく同じ保守性を維持する必要があります。また、プロジェクトとそれ以降のリリースのペースは安定している必要があります。

固定スコープの誤信

　この業界で「スコープクリープ（scope creep）」という言葉がこれほど広く知られている理由の1つは、スコープが同じ状態を保つことがめったにないからです。たとえ固定スコープのプロジェクトであってもスコープは変化します。

　その理由は、顧客とユーザーが、ビジネス上の問題を解決するために必要なスコープを100パーセント理解していないからです。理解しているのは50パーセントのこともあれば、80パーセントのこともあります。高度に統制された環境では、これが90パーセント台になることもありますが、今度は意思疎通の要素が入り込んできます。

　あなたはスコープをどのように伝えますか。ユーザー、開発者、または管理者は、それを散文で書き留めようとしていますか。彼らは長時間口頭で会話をしていますか。たとえ顧客が問題の解決に必要なスコープを、理論上は100パーセント理解していたとしても、彼らはその知識を前もって100パーセント伝えることはできません。

　アジャイルプロジェクトの管理者は、スコープが流動的な目標であることを理解しています。大きくなればなるほど、スコープは変化しやすくなります。スコープ自体がそれほど大きく変化するわけではなく、そのスコープに対する理解が変化します。

　理論上は100パーセント理解していたとしても、開発チームへの情報の移行は変動要素であり、完全な伝達手段ではありません。このため、チームにとっては、実際に変化していなくてもスコープが変化したように見えます。

　それでは、理論上の100パーセントの理解から離れ、より現実的な50パーセントの理解に目を向けましょう。顧客は解決すべきビジネス上の問題を抱えており、その解決策を知り尽くしているつもりであるという、よくある環境を想像してください。これが50パーセントの理解です。この環境を管理するには、チームと顧客の両者がビジネス上の問題の核心を理解し、全力で解決に取り組む必要があります。

　顧客が想定しているスコープは、重要な意味を持つ場合もあれば、そうでない場合もあります。ソフトウェア管理者は、前提を疑問視することを歓迎するような環境を培う必要があります。

　このような環境で、ソフトウェアチームは検討中のあらゆるストーリーを批判的な目で見て、そのストーリーが最終目標の達成に役立つかどうかを評価します。批判をくぐり抜けたストーリーだけが、チームが時間をかけるに値すると実証されます。正しい要求に取り組むことは、正しい取り組み方をすることと同じくらい重要です。

　顧客と協力しながら、どのようなスコープで顧客の問題が最もうまく、速く、安く解決するかを判断します。多くの場合、チームはプロジェクトからスコープを切り離すことができます。

暗黙の品質変動要素

　チームを管理するときは、参加メンバーを把握することが重要です。メンバーに支払っている報酬額を知り、メンバーからどれだけの成果が得られているかを把握する必要があります。ソフトウェア技術者の能力には個人差があるので、ちょうど5人の開発者を必要とするプロジェクトなどというものはありません。

　たとえば、報酬1万ドルずつの6人の開発者から成るチームと、2万ドルずつ稼ぐベテラン開発者3人のチームの成果を比較してみましょう（ここではわざと非現実的な数字を挙げています。重要なのは金額ではなく、数字の大きさの比率です）。

　Steve McConnell氏の著書『Code Complete』で紹介されている調査によると、わずか2倍の報酬で、生産性がほぼ10倍の開発者を獲得することができます。重要なのは、個々の開発者のスキルを見分けることです。

　口が達者で、能力は先ほどの6人のチームと同程度の開発者が、裏付けとなるスキルなしに高額の報酬をせしめている可能性は十分にあります。これは管理者のミスであり、その開発者にとっては儲けものです。管理者にまで昇進した人なら、開発者のスキルを見分けられるようになってほしいものです。

　アジャイルプロジェクトでは、スペシャリストよりもゼネラリストが多く採用される傾向にあります。彼らはイテレーションごとの責務を果たすために、全員が一丸となって取り組みます。

　スペシャリストから成るチームを編成すると、意思疎通が限定されてボトルネックが生じ、それによってキューが発生します。キューの理論については、リーンソフトウェア開発の原則を参照してください。

主要業績評価指標（KPI）

　アジャイルソフトウェアプロジェクトを管理するときに、管理者はプロジェクトの進捗を測るのに役立つ何らかの測定基準を追跡したいと考えます。忘れないでほしいのは、どのような測定基準であっても見直しが必要だということです。

　誤った基準を追跡しないように注意してください。たとえば、コードの行数を生産性の尺度として追跡した場合、少なくともその測定基準に従うと、生産性は急激に高まるでしょう。

　尺度の見直し（あるいは見方によってはルールの変更）は理にかなったことなので、本当に必要なもの、つまり提供されるソフトウェアと顧客の満足度を追跡するよう心がけてください。以下の測定基準から始めて、時間をかけて追跡に磨きをかけます。

欠陥のないストーリーの提供

　各ストーリーは、顧客にメリットをもたらすソフトウェアの固有の動作を表します。欠陥があるストーリーが提供されてもあまり価値がないので、それらは勘定に入れません。

顧客の満足度

　最終的に、ソフトウェアを作成するのは顧客のためです。顧客がいなければ、ソフトウェアを作成することもありません。顧客を常に満足させることは重要な測定基準です。単純なことです。満足度が10点満点で何点になるかを顧客に聞いてみます。

安定した速度

　イテレーションごとに、速度が一定している必要があります。速度がいつまでも変動している場合は、どこかに問題があります。6回目ごろのイテレーションの後で、速度の大幅な変化を警告の原因として扱います。チームの構成が変わっていなければ、速度は一定を保つはずです。速度の低下は、コードベースの保守性が失われている兆候の可能性があります。

顧客の管理

　管理者の仕事の一部は開発チームを管理することですが、同時に顧客も管理する必要があります。顧客の満足度は、期待をいかにうまく管理するかに大きくかかっています。

　顧客は不意打ちを好まないので、彼らを驚かせてはなりません。何を期待できるかをイテレーションデモで顧客に知らせます。成果が約束のレベルを下回っていると、顧客は不愉快な不意打ちを受けることになります。たとえば、チームメンバーが育児休暇で離脱しなければならない場合は、次回のイテレーションの成果にその影響が出ることを顧客に知らせます。

　顧客に常に情報を伝えて驚かせないようにするいい方法は、毎日の朝礼に参加してもらうことです。毎朝、チームに次の3つの項目を確認させます。

　この日々の情報に接することで、顧客は自分を部外者ではなくチームの一員と感じるようになります。最新の情報が得られるので、不意打ちを受けることがなくなります。毎日の朝礼、週に一度のイテレーションデモ、および絶え間ない連絡を通じて、顧客の満足度を保ち、顧客に参加してもらうことができます。

　重要なのは、顧客をプロセスに引き込むことです。そうしないと、「我々VS彼ら」という構図になり、機能不全に陥ります。チームと顧客が競っても、どちらの得にもなりません。

バグと欠陥

　欠陥（defect）とは、チームが約束したものと実際に提供したものとの食い違いです。チームがストーリーを約束し、そのストーリーの機能に問題があることがわかった場合は、欠陥があるのでストーリーは完了していません。

　ストーリーを「完了済み」と見なせるのは、顧客がストーリーを「欠陥なし」として受け入れたときだけです。単に欠陥をログに記録し、自分の名前を残しただけでは何の役にも立ちません。

　バグとは、何かユーザーを困らせるものです。バグから逃れる方法があるのかどうかはわかりませんが、絶え間ない連絡が役立つことは確かです。ソフトウェアプロセスを管理する上で、バグと欠陥の違いを理解することは重要です。

　バグには議論の余地がありません。あるソフトウェアの動作がユーザーを困らせていれば、それはバグであり、話はそこで終わりです。しかし、その動作についてチームと顧客が事前に合意していた場合は、それはバグではなく欠陥ということになり、チームは直ちに欠陥を修正する必要があります。

　欠陥は、ストーリー契約と受け入れ基準の食い違いです。バグは、まだ論議されていない厄介物なので、欠陥ではありません。バグはいつでも突然現れます。顧客に十分な意欲があれば、バグを取り除くストーリーを作成し、そのストーリーをバックログに登録します。

　けれども、欠陥について考えるのは顧客の役目ではありません。誰かが欠陥を見つけたら、チームはすべてを投げ出して、直ちに欠陥を修正する必要があります。欠陥は、チームが既に「完了済み」と見なしたストーリーが、実際にはまだ完了していないことを意味します。ストーリーを完了してから先に進む必要があります。

　無欠陥ポリシーを定めてください。すべての受け入れ基準を満たすまでは、ストーリーを完了済みと見なさないでください。バグから逃れることはできませんが、欠陥をなくすことは必ずできます。

回顧（振り返り）

　各イテレーションの終わりに、さらに効率を高める方法をチームで振り返り、練り上げるための短い時間を設けます。これを楽しみながら行うには、次の3つの見出しの下にフィードバックを列挙します。

　すべての項目をアクション項目と見なします。「良い」項目は継続し、拡張します。「悪い」項目と「ひどい」項目は、やめるか、変更するか、全面的に見直します。

　優れた管理者は、「悪い」と「ひどい」の下に列挙された項目を改善しようとします。ほとんどの場合、これらの項目を変更できるのは管理者だけです。チームは自分たちの管理下にある項目を改善します。

　残された項目は、どちらかと言えば組織の問題となります。これらの組織の問題を無視しないでください。簡単ではないでしょうが、不満足な施設、機器、ソフトウェアライセンスなどの問題に対処するのは管理者の仕事です。管理の仕事が楽でないことは既にご承知のとおりです。

　回顧は短く抑えます。回顧ミーティングの適度な制限時間は30分です。アジャイル理論に関する議論にまで及んで長引かせてはいけません。結局は、あなたが責任者なのですから、チームが今後の進め方に関する長い議論を始めた場合は、自ら決断を下す必要があります。

アーキテクチャ

　ソフトウェアシステムの設計によって、チームの能力がうまく引き出されることもあれば、損なわれることもあります。痛みと開発者の不快感を指針にしましょう。

　ソフトウェアのある側面が苦痛だったり不快だったりする場合は、それを修正するために時間を投資します。その時間を投資と見なします。投資した時間は見返りをもたらすはずです。

　たとえば、共有の開発用データベースが痛みの原因になることがよくあります。1人の開発者が新しい機能のためにスキーマを変更したせいで、チームの残りのメンバーが一時的にシステムを利用できなくなることがあるからです。各開発者のコンピュータにデータベースインスタンスを配置することで、この問題はすぐに解決します。

　痛みに敏感になり、「それに関しては何もできない」という答えを選ばないようにしてください。

イテレーション期間の決定

　イテレーションとは、システムの新しい状態を製品オーナーに実演するまでのチームの作業期間です。スクラム開発では1か月を推奨しています。XP開発では1〜2週間を推奨しています。私は1週間を強く推奨します。

　イテレーションはリリースとは異なります。イテレーションはソフトウェア提供のサイクルを表します。リーン開発では、処理能力を高める手段としてサイクル期間の短縮を強調しています。サイクル期間を1週間に短縮することで、チームは提供する機能だけに専念するようになります。提供までの期間が1週間しかないと、本質的なストーリーから逸脱することが難しくなります。

　たった1週間では何も完成できないと思う人がいるかもしれません。もしそれが本当なら、取り組むべき何か重大な問題を他に抱えていることになります。

　アジャイルの価値を採用し始めたばかりのときは、タイプミスを修正してリリースするだけで2か月もかかるようなシステムで作業をしている可能性があります。その場合は、ビルドと展開のプロセスを改善し、2か月ではなく1時間で完了できるようにする必要があります。

　何か途方もなく大きな問題に直面している場合は、その問題の解決に労力をつぎ込む必要があります。組織内のことは、良いことも悪いこともすべて管理者の責任です。指導力を発揮して問題を軽減してください。

　1週間のイテレーションではプロセスがきつく絞られて、機能不全を起こしている部分が表面化します。サイクル期間が短いと、組織の速度を低下させている要因がすべて一目瞭然となります。短いサイクル期間を使用して、問題を潜伏させないようにします。

　既存の問題を検出する手段として1週間のイテレーションを使用してください。チームの活動が円滑になるまで問題に1つずつ取り組みます。それにより、わずか1週間のイテレーションで大きな価値を提供できるようになります。

採用と解雇

　管理者としては、解雇よりも採用の数を増やすことを目指します。チームのメンバー選定は管理者の責任です。

　ここで、私が「差し引きマイナスの（net-negative）開発者」と呼ぶタイプの人の話をしましょう。これは生産性の低い開発者のことではありません。そうではなく、病欠しても誰も困らないような人のことです。彼らは誠実な場合もありますが、彼らがいることでチームの速度は低下します。実際、彼らが休暇に入るとチームの活動が速くなることがあります。

　勇気を出して、チームの強化に必要なメンバーの入れ替えを行ってください。チームメンバーのために高い水準を維持してください。大企業には、業績がよほどひどくない限り解雇はできないというポリシーがあることは承知しています。

　政治的手腕を発揮して、チームの業績を妨げるものを排除するのも管理者の責任です。差し引きマイナスの開発者は、チームの生産性に絶えず重い負担をかけます。勇気を出して、チームのためだけでなく、顧客や製品オーナーのためにも正しいことを実行してください。

　その一方で、「増進者（multiplier）」の存在に気付いてください。業績評価では、この人物が直接の原因と思われるような具体的な項目を挙げることはできないかもしれませんが、増進者が参加しているプロジェクトはどれもうまくいくように見えます。

　彼らはチームの他のメンバーの活動を増進します。もしかすると、彼らは障害を取り除いたり、プロセスの合理化に取り組んだりしているかもしれません。いずれにしても、この人物はそうした活動を通じてチーム全体の生産性を倍増させる可能性があります。

　彼らを高く評価し、見返りを与えてください。彼らは組織の貴重な資産です。採用の過程で、このタイプの人材も見極められるように努めてください。

アジャイルの価値と原則

　この記事を締めくくる前に、「Agile Manifesto（アジャイルソフトウェア開発宣言）」の価値と原則を1つずつ見ていこうと思います。

　管理者は、自分の部署の文化を定める責任を負います。部署の活動のよりどころとなる価値と原則を定義しなければなりません。したがって、プラクティスと原則を区別することが重要です。

　プラクティスは規定することができます。スクラム開発とXP開発ではプラクティスが規定されています。これらの手法では原則も規定されています。アジャイルでは、プラクティスは規定されていません。アジャイルは、価値と原則に基づくソフトウェア手法の分類です。XP開発とスクラム開発のプラクティスは、アジャイルの原則を実装する手段の例です。

　アジャイルソフトウェア開発の4つの価値は、以下のとおりです。

　「Agile Manifesto」では、ツールよりも人間を重視します。ソフトウェアチームはソフトウェアを提供しなければならないので、アジャイルプロセスに従うチームは、ソフトウェア以外の他の成果物よりも、ソフトウェアを提供することを重視します。

　これら4つの価値がアジャイルの考え方を定義しています。アジャイルソフトウェア開発の12の原則はオンラインで参照できます。ここでそれらの原則を1つずつ見ていくことにします。

価値のあるソフトウェアを早くから継続的に提供することによって、顧客に満足してもらうことを最優先事項とする。

　ソフトウェアの提供は、チームが顧客に与える有益なサービスです。状況レポートは役に立ちますが、動くソフトウェアがなければ、とても代用にはなりません。アーキテクチャ図は美しいものの、ユーザーがシステムを使えなければ市場での投資回収率（ROI）はありません。

　ソフトウェアの提供を優先項目の最上位に引き上げる必要があります。それ以外に提供する必要があるものは何であれ、動くソフトウェアの後で提供することができます。

　また、ソフトウェアを継続的に提供することも重視します。つまり、一度きりのリリースはしないということです。進化していくソフトウェアを顧客が利用できるように、早くから頻繁にリリースします。

開発の後期であっても要求の変更を歓迎する。顧客が競合上優位に立てるように、アジャイルプロセスでは変化を味方に付ける。

　従来のソフトウェアチームでは、大規模なソフトウェアプロジェクトの達成に丸1年かかることもあります。プロジェクト開始から12か月経って、顧客が初めて要求を変更するようなことは許されません。

　これに対し、アジャイルソフトウェアチームはソフトウェアの状態を早くから頻繁に実演するので、顧客はソフトウェアが要求を完全に満たしているかどうかを評価することができます。

　ソフトウェアチームは、早くから頻繁にフィードバックを反映させることができます。顧客が大きな誤りを犯していた場合に、ソフトウェアチームはすばやく対応して方向を転換し、ビジネスを支援する必要があります。将来を正確に予測できなかったことが、顧客にとって致命的な誤りにならないようにします。

数週間から数か月の間隔で、動くソフトウェアを頻繁に提供する。この期間は短い方が望ましい。

　なるべく短いサイクル期間を選択します。アジャイルソフトウェアチームは、フルリリースを頻繁に提供します。顧客は、内部用または実際のユーザー向けのリリース用にフルリリースを使用することができます。

　顧客からの生のフィードバックが多いほど、アジャイルソフトウェアチームは重要な変更をより迅速に加えることができます。多くの場合、顧客はソフトウェアの機能を使用できるようになるまで、何が動作するかを知りません。リリースされた機能を使いながら、顧客は機能を改良するためのアイデアを思いつきます。

プロジェクト全体を通じて、企業の担当者と開発者は日々共同で作業をすべきである。

　人間同士の共同作業に勝るものはありません。人間関係は良好な作業環境の重要な鍵となります。関係者全員が毎日顔を合わせるチームと比較した場合、互いを知らない企業の担当者と開発者は大いに不利な立場に立たされます。

意欲のある人々を中心にプロジェクトを構築する。必要な環境とサポートを与え、彼らが仕事をやり遂げてくれることを信じる。

　工場の組み立てラインの原理でソフトウェアを管理することはできません。ソフトウェアは特化された形態の知識作業であり、プロジェクトチームのメンバーは高度な訓練と経験を積んでいる必要があります。

　陸軍のM-16突撃銃の標準パーツのようにチームメンバーを交換することはできません。チームメンバーにはそれぞれ個性があり、独自の考えを持っています。

　管理者は彼らのやる気を引き出し、彼らを解き放つ必要があります。使いにくいツールなど、環境面での障害を取り除いてください。彼らにプロジェクトを達成するための責任を与えます。さらに、必要な活動を行うための権限を与えます。

開発チームに対し、または開発チーム内で情報を伝えるための最も効率的かつ効果的な方法は、直接会って話をすることである。

　意思の疎通において、言葉自体が占める割合は7パーセントにすぎないことがいくつかの研究で結論づけられています。声のトーンが38パーセントを占め、言葉以外の情報が55パーセントを占めます。

　したがって、話し合いの手段を電子メールだけに限定してしまうと、意思疎通の有効帯域幅の93パーセントが失われることなります。これではソフトウェアプロジェクトが進むはずがありません。直接会って話をすることで、意思疎通の力が最大限発揮されるようになります。

動くソフトウェアこそが、進捗を評価する最も重要な尺度である。

　実際のソフトウェアを顧客に見せることに勝る方法はありません。状況レポートには何の効力もありません。

アジャイルプロセスは持続可能な開発を促進する。スポンサー、開発者、およびユーザーは、常に一定のペースを維持できるようにする必要がある。

　ソフトウェアシステムのアーキテクチャは、技術的な複雑さが直線的に増加するような環境を促進する必要があります。にもかかわらず、多くのソフトウェアシステムは指数関数的な複雑さのグラフを描きます。

　このため、後から変更を加えることがますます難しくなります。時が経つにつれて、複雑さのせいでシステムを変更できなくなることもあります。持続した開発のために、複雑さの曲線を直線的に保つ必要があります。

卓越した技術と優れた設計に絶えず注意を払うことにより、アジリティが向上する。

　ソフトウェアの設計を明瞭に保つことにより、必要に応じて設計を変更できるようになります。複製はとてつもない大罪です。ロジックが複製されていると、ビジネスルールが変更された場合に複数の箇所で同じような変更が必要になることがあります。これがアジリティの妨げになります。

単純化（行わずに済む作業の量を最大にする技術）がきわめて重要である。

　企業では、購入か構築かという決断を迫られることがよくあります。独自のソフトウェアシステムを構築する決断を下した後も、コードのすべての行を自力で作成せずに、コンポーネントを購入する機会が残されています。

　最近よくある購入か構築かの決断は、データベースアクセスコードのすべての行を自力で作成する代わりに、オブジェクトリレーショナルマッピングライブラリを使用するというものです。

　同様に重要なのは、顧客が抱える当面の問題をごく単純なソフトウェアシステムで解決できる場合に、提案されたソリューションを顧客が単純化するための手助けをすることです。すべてをできる限り単純にします。複雑なコードを誇りに思っている開発者には気をつけてください。代わりに、複雑なコードを書き直し、開発者が単純なコードを誇りに思うようにします。

最良のアーキテクチャ、要求、および設計は自立したチームから生まれる。

　あなたはおそらく優秀な人材を採用しているはずです。彼らをまとめ上げ、彼らがプロセスの改良に取り組めるようにします。硬直したプロセスを一方的に押しつけても、結局はメンバーの反感を買うことになり、処理能力の最大化には結び付きません。

効率をさらに高める方法をチームで定期的に振り返り、それに従ってチームの活動を調整する。

　回顧を使用して、効率をさらに高める方法を見いだします。このプロセスではチームメンバー全員の知恵を活かします。

　アジャイルソフトウェアプロジェクトを管理することは容易ではありません。すべてを会得することは決してできないので、常に学び続ける覚悟をすることです。改良のアイデアを持つ人の声には進んで耳を傾けてください。良いアイデアは管理者だけが出すものではありません。

　実際、良いアイデアが管理者からしか出ていないとしたら、メンバーの選定に問題があると考えられます。常に権限と責任を委ねて、メンバーが成果を収められるようにします。会社の枠を超えて、コミュニティや業界の他の分野と交流してください。アイデアを共有し、誤りを認めることを恐れないでください。

　誤った方向に進んでいることがわかったら直ちに修正します。ただし、うまくいっていないという証拠がない限り、プロセスを一切変更してはなりません。優秀な人材を採用して確保してください。成果を上げるためのツールと権限を彼らに与えます。その後は、彼らの活動を妨げないようにします。