SI案件でアジャイル開発を進めるときの勘所

みなさんこんにちは。@ryuzeeです。

10月に発売となった『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』ですが、まだお読みになっていない方是非よろしくお願いします。また、ここ数か月新しい書籍の翻訳に取り組んでいて、来年の春くらいには発売になるかと思います。この本も楽しい本だと思うので是非楽しみにお待ち下さい。

さて、先日、プライベート講演で、SIのコンテキストでアジャイル開発を進める場合に、どのような点に気をつけておくとよいかを話して来ました。汎用的な内容で読者の方の参考になるかと思いますので、資料を公開しておきます。

以下、資料だけ見てもわからない方向けの解説です。

TL;DR（結論）

SI案件でアジャイル開発を適用する場合、顧客側がアジャイルを正しく理解していない可能性があるので、案件開始前に教育すべし
ステークホルダーマネジメントは重要。これはウォーターフォールでもアジャイルでも変わらない。SI案件の場合、プロダクトオーナーの重要な仕事はこれ
要求される品質を開始前に明らかにする。そのために社内品質管理部門と連携したり顧客と調整したりする必要がある
品質を最後に上げることはできないので、最初から最後まで確保し続けられるようにする
成果を出したければ良いチームを作ること
複数プロジェクトの兼任はムダでしかない

ステークホルダーマネジメントはSI型のアジャイル開発の肝

SI型の場合、プロジェクトには多くの関係者が登場します。顧客（発注者）、顧客（関係部門）、顧客（ユーザー）、自社内のマネージャー、運用部門、セキュリティ部門、監査部門などなど多岐に渡ります。これらステークホルダーがいかに共通認識を持つかというのが重要になってきます（多くの場合、期待値や認識にズレがあります）。

特に大きいのが「アジャイル」に対する理解です。昨今顧客側がアジャイルを指定することが増えていますが、それを単純に鵜呑みにすると問題が起こるかもしれません。過去にあった誤解を紹介しておきます。

このような誤解を持たれたままプロジェクトを始めてしまうと、無理難題を言ってきたり、発注者としての責務を果たせなかったり、期待値のズレによって揉め事になったりします。まずは、実際に契約を締結する前に、顧客が意図しているアジャイルとはどのようなものなのか、アジャイルによってどんな成果や効果を得たいのか確認しておくことをおすすめします。アジャイルは、「同じ物」を速く作る方法ではありません。必要に応じて、初期の段階で顧客にもトレーニングを受けてもらうのも良いでしょう。

余談ですが、顧客がアジャイルを理解していれば「請負契約にしたい」なんていう言葉は出てくるはずがないので、もしこれが出てきたら焦って契約せずに教育が必要です。目先の数字や案件欲しさで飛びついてしまうと痛い目にあいます。

プロダクトオーナーは実際のところ誰がやればいいの？

IPAの資料などでは、プロダクトオーナーは発注者が望ましいと書かれています。とはいえ、現実的にはそれができる顧客の数はそう多くないというのが正直な実感です。

プロダクトオーナーはその性質上単一障害点になりやすいロールです。またスクラムチーム全体が成果を出せるかどうかはプロダクトオーナーによるところが大きく、プロダクトオーナーはスクラムチームの外側の半分の時間を使い、残り半分をスクラムチーム内部に使うようなフルタイムの仕事だと考えておくのが良いです。しかし、顧客がそれだけの時間を実際に使えるかどうか疑問符がつくことが多いのが実情です（すでに複数の仕事を抱えていることが多い）。

また、複数の利害関係者間の相反する要望の調整をしたり、スコープ調整をしたりといったことがうまくできず、言いなりになってしまうこともあります（社内の立場的にシビアに調整しきれないこともあります）。プロダクトオーナーと開発チームの関係性が、発注者・受注者の関係性と同じになってしまい、フィードバックループが形成されなかったり、価値が伝わらなかったりすることもあります。

もちろん経験やスキルによるところは大きいですが、大きなリスクになりえる箇所だということは認識しておかなければいけません。どうしてもという場合には、十分な教育やサポート体制を組んでください（固定のサポートメンバーを常時つけるなど）。

品質を定義し、それを維持する

言うまでもなく、SI案件だろうが、自社開発のサービスだろうが品質は重要です。ただ、SIの特性上、プロジェクトを開始するタイミングで達成すべき品質を明確にしておく必要があります。

品質を無視して進めてしまうと、リリース時に大きな問題が起こります。また顧客の要求する品質と乖離があった場合に揉め事になる可能性もあります。つまり、初期の段階で品質を定義し、その品質を維持し続けられるような仕組みを考えなければいけません。

SIのコンテキストでは品質は開発側で勝手に決められるものではなく、顧客側と品質要件を明確にする取り組みが必要になります。一方で開発側の社内にも品質基準が存在することが多く、顧客が要求する品質と、自社で標準的なものとして設定している品質を比べながら、どの程度の品質を目指すのかを定義しなければいけません。これを行うためには、初期の段階から社内の品質管理部門などを巻き込む必要があると言えます。

その上で、定義した品質をどう維持するかの戦術面（テスト自動化、その範囲など）を一緒に考えていく形が理想です。

機能しているチームで取り組む

アジャイル開発での成果は下の図にあるように掛け算です。いくら素晴らしいアイデアや解決の意義のある問題を定義しても、開発力がなければ成果は少なくなります。またチームとして機能していなければ、開発力を活かせません。従って、開発力やチーム力を常に上げていけるような取り組みが必須です。

チームが成長する上では、成長に使える時間的な余裕と、心理的安全性が欠かせません。意見を言えて、改善や実験（と失敗）を繰り返せる安全性がハイパフォーマンスにつながります。

チームが機能するようになるには時間がかかります。毎回チームを1から作っていては勝負にならないので、「良いチームを維持して高く売る」というモデルを考えると良いと思います。チームを維持するからこそ、チームの成長に継続的に時間を使えるようになります（焼畑農業とは逆の考え方です）。

なお、時間的余裕という観点でも、仕事のリードタイムの増加やコミュニケーションオーバーヘッドの増加という観点でも、ストレスマネジメントという観点でも複数プロジェクトの兼任はお勧めしません。タイガーチームのような特殊スキルセットの人を除き、プロジェクトのメンバーとしてさまざまな作業を行う人は1つのプロジェクトに専念すべきです。ワインバーグ氏を始めとして、多くの先人たちが昔からそう言い続けています。