「アジャイル」という言葉が一人歩き――アジャイル開発における理想と現実：アジャイル時代のプロジェクトマネジメント入門（3）

プロジェクト管理の基礎からアジャイル開発の理想と現実、成功例と失敗例、を紹介し、ベストプラクティスを提案する連載。今回は、実際の開発現場での理想と現実、失敗談をお話しし、アジャイル開発を進めるためのツールとして「Pivotal Tracker」を紹介します。

[石川靖，株式会社Cuon]

連載目次

　本連載では、「アジャイル時代のプロジェクトマネジメント」というテーマで、プロジェクトマネジメント／プロジェクト管理の基礎から、アジャイル開発の理想と現実、成功例と失敗例、そしてベストプラクティスの提案までを紹介します。

　前回の「現代のプロマネが知っておきたいアジャイル開発の基礎知識まとめ」では、開発手法やアジャイルの基礎、その他の開発手法との違いなどを中心にお話ししました。さて今回は実際の開発現場での理想と現実、失敗談をお話しし、アジャイル開発を進めるためのツールとして「Pivotal Tracker」を紹介します。

実際の現場での理想と現実

　ここ最近、少しずつではありますが「アジャイル開発」でお問い合わせをいただくことが多くなってきました。筆者の所属するCuonでは変更に強いRuby on Railsでの開発を得意にしているからかもしれません。以降、実際いくつかのアジャイル開発プロジェクトでの理想と現実をお話しします。

こんなはずじゃなかった

　「アジャイル」という言葉が一人歩きしてしまった例をお話しします。その開発プロジェクトでは、当初の要件が緩く、企画段階ではあったものの、スケジュールの制約があったため、まずはスタートということになりました。

　Webのシステムでしたが、コアな部分を決め、設計・実装を途中まで対応していた時に、根幹に関わる部分に修正が必要なビジネス要件が出てきました。根幹に関わる部分であることから小手先の対応ではなく、設計に立ち返って再度検討からスタートしました。案の定、スケジュールに大きく影響しサービスのローンチ時期の調整が必要になりました。

　その段階で「そんなの聞いていない」とクライアントから指摘を受けました。「アジャイルなのだから……」と。

　アジャイルでの開発を進めていく上では、最初の“握り”は非常に大切です。発注側と開発側がお互いWin-Winになるためには、必ず前提条件を話し合っておくことが重要です。

　また発注側にも、ある程度のスキルや考え方が必要であるといえます。アジャイルだからといって、全ての変更を受け入れつつスケジュールも担保することは難しいのですから。

意見の対立

　アジャイル開発だけに限定される話ではないですが、設計者とプログラマーの間でケンカが起きることが多いです（もちろん、お互い良い方向に向いているケンカです）。

　あるプロジェクトでは基本設計と詳細設計・実装を別の会社で行うケースがありました。このケースでは、設計での“あるべき論”と、プログラマーが考える実装方針などで何回か衝突を繰り返すことになりました。最終的には良い方向に転がりましたが。

　クライアント（プロダクトオーナー）、設計担当メンバー、プログラミング担当メンバー、それぞれの思いがあり、非常に苦労しました。メンバーが増えるとコミュニケーションパスが増えますので、プロジェクトマネジャーのスキル・経験が問われるわけです。

契約方法と見積もり方法の違い

　次回以降でもう少し深掘りしますが、契約方法と見積もり方法について“もめる”ことがありました。

　アジャイル開発の基本は実績生産（時間生産）を取ることが多いです。近ごろは、時間生産の準委任契約も増えてはいるものの、最初からその想定で契約を結んでいればいいのですが、システムのプロジェクトは請負契約で締結することも少なくありません。

　アジャイル開発では、実は見積時のトラブルが付きものです。いろいろなリスクを個々のイテレーションの中で解決していく手法であり、見積もりにリスクを積んでしまうと、結局ウオーターフォールでの見積額よりコストが高くなってしまい、クライアントにとってもメリットが失われてしまうことがあります。

　請負契約の場合はウオーターフォール型を取ることが多く、もし請負契約でアジャイル開発の手法を採る場合は契約時など、事前にいろいろな部分をクリアにしておくことをお勧めします。

　ちょうど現在請負契約でのアジャイル開発を実践中であり、本連載の最終回で少し取り上げることができると思います。こう、ご期待。

プロジェクト内で正しい認識を

　アジャイル開発の意味を「仕様決定の先延ばし」と考える思考がプロジェクト内に存在すると、失敗につながりやすくなります。

　確かに現在進行中のイテレーションで確定しなかった仕様を後続イテレーションで組み込み、完成度を上げていくことは、アジャイルではよくある光景ですが、だからといって、決まらないものをただ安易に後続イテレーションに後ろ倒しをしても問題は解決しません。

　なぜ決定を延ばすのか？ 本当に今決定できないのか？ などを精査する必要があります。また、その決定をプロジェクト内で一つにするのも大切です。

別の開発手法でも良いところは取り入れる――リーンとウオーターフォールの融合

　複数の開発手法の融合（他の開発手法を取り入れること）によって、プロジェクトマネジメントは汎用性を増します。ここでは、前回紹介した、アジャイル開発手法の一つであるリーン開発手法とウオーターフォール開発手法の融合を例に挙げて見ていきます。これは実際のプロジェクトで実績のある組み合わせです。

　アジャイル開発を行っていると仕様の変更などで、都度ドキュメントを更新する必要にせまられ、進捗（しんちょく）が伸び悩んだり、ドキュメントが最新でなかったり、そんな経験をされた方も多いのではないでしょうか？

　Cuonでも同様の問題がたびたび発生し、リーンとウオーターフォールを組み合わせた開発手法をしばしば利用しています。これは、各イテレーション内をウオーターフォールで進めることにより、イテレーション内で確定したことについては、次イテレーション以降では基本変更しないという開発手法です。

　クライアントが早く実物を見たい機能を早い段階で開発することにより、プロジェクト全体での認識ずれが発生しづらくなります。また開発者にとってコアな部分を早めに開発するため、後続イテレーションのリスクを軽減できます。

ツールの活用――かんばん方式とPivotal Tracker

　最後に、ツールを紹介します。

かんばん方式

　プロジェクト管理におけるタスク管理の方法として「かんばん方式」が存在します。コルクボードやホワイトボードなどに、下記について、付箋などを利用して記述し、タスクを管理する方法です。

• TODO ：やること
• DOING：やっていること
• DONE ：やったこと

　プロジェクトメンバーで行う毎日のミーティングは、この「かんばん」を元に行い、メンバー間での進捗情報を共有します。

　ここでは、かんばん方式をSaaSで実現するためのツールとしてCuonでも導入を始めている「Pivotal Tracker」を紹介します。

Pivotal Tracker

　Pivotal Trackerは、アジャイル開発で利用されるプロジェクト管理ツールの一つです。

　本ツールを利用することにより、ベロシティ（特定期間での開発量）を明示化することができます。

　例えば、あるプロジェクトで必要な開発量が100ポイントとします。今週の開発したポイントが25ポイントだった場合、全ての開発が完了するのにはあと3週間かかる計算になります。

　Pivotal Trackerを使うと、開発量はリアルタイムに管理されるため、開発がいつ完了するのかを明確に把握できます。

　いつ完了するのかが分かると、プロジェクトマネジャーはプロジェクトの遅延に対して、早い段階で手を打つことができます。

　Pivotal Trackerの詳細は、記事「いまアツいアジャイルプロジェクト管理ツール9選＋Pivotal Tracker入門」を参照してみてください。

　非常に有用なツールなので、利用を検討してみてはいかがでしょうか。

次回は成功するプロジェクトと失敗するプロジェクト

　次回は成功するプロジェクトと失敗するプロジェクトについてお話しします。どんなプロジェクトが成功するのか？ そのとき、アジャイル開発はどうなの？ ということについてお話ししますので、お楽しみに。

「アジャイル時代のプロジェクトマネジメント入門」バックナンバー

• プロジェクトを成功に導く4つのベストプラクティス
• 失敗するプロジェクトと成功するプロジェクト
• 「アジャイル」という言葉が一人歩き――アジャイル開発における理想と現実
• 現代のプロマネが知っておきたいアジャイル開発の基礎知識まとめ
• プロマネ初心者に送るプロジェクト管理の基礎知識まとめ

著者紹介

石川靖

株式会社Cuon 執行役員

株式会社Cuonで事業部長と営業を兼任。現場のプロジェクトマネジャーとしても活躍中。PMI認定PMP資格保有者。趣味はGolfと料理。

Facebook