＜PM座談会＞アジャイルプロジェクトの現場で感じる”ホントのところ”【後編】

――　アジャイルソフトウェア宣言に「ドキュメントよりも動くソフトウェアを」という言葉がありますが、皆さんのプロジェクトではドキュメントをどの程度作成されていますか？

Rさん：
私のプロジェクトでは、テスト結果の記録としてドキュメントを作成していますが、設計書のようなドキュメントはほとんど作成していません。ただし、リリースのタイミングには成果物としてドキュメントが必要な為、コードをベースに設計書を作成しています。

Eさん：
うちのプロジェクトも基本的にドキュメントは少ないですね。テーブル定義やアーキテクチャー部分については設計資料を作成しています。または要件定義を行った際、アジェンダレベルで色々取りまとめた資料も作成しましたが、内部設計に該当するような実装ベースの設計書はほとんど作っていないです。

Oさん：
私のところは、システム仕様が非常に細かく、受け入れ条件だけでは書ききれない部分があるので、設計書を作成しています。あとは、複雑な機能については、オフショア開発メンバーに理解してもらうために仕様書以外の資料を作成することもあります。

――　皆さんのプロジェクトではドキュメントを作成している部分もありますが、全体的にアジャイル宣言の通り作成するボリュームとしては少ない印象ですね。ドキュメントを作るか作らないか、作る場合はどの程度を作るのか、正解はないと思いますが、何のために作っているかをよく確かめ、無駄なく必要なものだけ作る事が本来あるべき姿だと感じました。

――　アジャイルの作法に沿って開発を行ったが想定した効果が得られていないという課題を持っている企業は一定数存在しているようですが、皆さんは同じような課題を持っていますか？何か良い対策があれば教えてください。

Oさん：
もちろんうまくいかない場合もあります。良い対策になるか分かりませんが、レトロスペクティブ（retrospective＝スクラムではスプリントの最後に行われる振り返り活動）の活用は一つの方法だと思っています。自分のプロジェクトではテストレビューがありまして、毎回テストでどのような不具合があったのかなどをチェックしますが、繰り返し発生する不具合があった場合は、どのような事があったのか、何が原因なのかについてレトロスペクティブで深堀りしてもらい、改善点を探るようにしています。

Eさん：
レトロスペクティブは改善に繋がる有効な方法だと思います。ただ、開発メンバーだけが集まるトレロスペクティブにありがちですが、開発者個人の振り返りに終始してしまいがちなので、開発メンバー以外のプロダクトオーナーやスクラムマスター、またステークホルダーも含め、なるべく多くの関係者から意見を聞いて、それぞれの目線で改善してほしい点を集めたほうがいいかもしれません。その意見リストからテーマをピックアップしてレトロスペクティブで話し合ったらいいと思います。こうすることで個人的な振り返りに偏る問題も回避できます。

Rさん：
私のプロジェクトも基本的に同じような形で実施しています。レトロスペクティブで良い点と問題点を振り返った後、皆さんでどの点が重要と思えるか投票します。そして、次回のスプリントでチームとして改善したい部分を決めて、どのようにすれば良くなるかについて話し合います。

――　レトロスペクティブは個人の振り返りだけではく、プロセスの問題点やチームとしての改善ポイントを議論する場でもありますので、アジャイルの効果を高めるために有効な方法だと思います。
レトロスペクティブを行う事が難しく感じている人もいますが、少し工夫したら良い結果を出せるではないかと思いました。リクエストリストと投票は良いアイデアですね。是非もっと多くの方に紹介したいです。

――アジャイル開発で作られたプロダクトの品質が悪いというような意見も時々聞こえますが、皆さんのプロジェクトではいかがでしょうか？

Oさん：
私のプロジェクトでは、リリース前のテストスプリントを必ず設けてあり、そのスプリントで最終的なテストを実施します。また、通常のスプリント内でも基本動作確認テストを実施しています。ある程度時間が必要になりますが、デグレ検知の効果が高いと思います。以前は動いたものの、今回の変更で動かなくなってしまったなど、新機能に影響されているかもしれないというような問題や懸念事項をすぐに発見、対応できています。

Eさん：
私の場合も、各スプリントの中で開発者自身が単体や結合テストを実施しています。テスト観点やポイントも作成してもらうのですが、その品質は人によってバラつく可能性があります。後続のストーリーテストに影響を及ぼす場合もあるので、レトロスペクティブでテスト品質の維持についてみんなで話して共通認識を保つようにしています。

Rさん：
R＆D分野は、各スプリントで作成したものに対してしっかりと動作確認し、不具合があれば対応しますが、研究結果を出すことがそのままスプリントの結果になるので、品質が著しく悪いというケースは今のところあまり見当たらないですね。

――　アジャイル開発に限らず、どんなプロジェクトにおいても品質管理は重要な課題です。アジャイル開発においては、テストは品質を左右するポイントの一つだと思います。アジャイル開発のためのテスト手法やアーキテクチャーについて別の記事（※）で紹介したことがありますが、繰り返しテストを行うことで、早い段階で小さな不具合を撲滅することがプロダクト品質を担保するための良い方法ですね。

※：別記事（【連載特集】エンタープライズアジャイルにおける品質担保をどう実現するか ― 第２回　品質を支えるアジャイルテストとは）

――　最後になりますが、これからアジャイルプロジェクトに取り組む方々に対し、アドバイスを一言お願いできますでしょうか。

Oさん：
プロダクトオーナーの役割を果たすために、本当は業務とシステムの両方に対する理解が必要ですが、現実的に両方とも備えられるケースは少ないと思っています。弱い部分を補うためにプロダクトオーナーサポートを付けることをお勧めします。自分が業務について詳しければ、システムに強い人をプロダクトオーナーサポートにつけて、逆も同じです。プロダクトオーナーは一人で無理をせずにサポート役に手伝ってもらってください。

Eさん：
私のアドバイスをいわせて頂きますと、最初から100点を目指さないことです。アジャイルの考え方では10のプロジェクトは10のやり方があり、自分たちのプロジェクトに一番合う効率的な進め方がベストプラクティスだと思っています。最初から満点を目指すのではなく、やりながら徐々に改善して成熟していくことを目指したら良いのではないでしょうか。

Rさん：
ウォータフォール型の開発では、1年以上かけて行うプロジェクトも多いのですが、アジャイル開発の場合は、1週間や2週間のスプリントで成果を求められます。初めてアジャイルプロジェクトに参加する方にとっては、このようなスピード感は苦労するところだと思います。そのスピード感に慣れてくると、より良いパフォーマンスを達成できると思いますので、難しいなと感じてもあきらめず乗り越えるよう頑張ってください。

――皆さんの応援メッセージありがとうございます。かなり実用的なアドバイスなので、自分でもアジャイル開発をやってみたいというワクワク感が湧いてきました。きっとこれからアジャイル開発に取り組む方の参考になると思います。

今回のように三者三様のアジャイルプロジェクトマネージャーを集めて、一緒にディスカッションできる事は本当に貴重な機会でした。皆さんの現場経験をもとにとてもリアリティのある話をたくさん聞くことができ、共通している課題や工夫点、異なる課題や工夫点があることがわかりました。

アジャイル開発に取り組まれている方々にとっても、きっと共感できる部分が多いでしょうし、これからアジャイル開発に取り組まれる方にとっては役に立つ内容が多くあったと思います。ご参考にしていただければ幸いです。

＜PM座談会＞アジャイルプロジェクトの現場で感じる”ホントのところ”【前編】