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

――　皆さんが担当されているプロジェクトの概要と担当業務を教えてください。

Oさん：
私はパッケージのリニューアル開発プロジェクトのPMを担当しております。リモートオフショアアジャイルで開発を行っていますが、オフショア先はインドネシアの当社グループ企業Mitraisを選定しています。開発メンバーはインドネシアの複数の拠点から参加していて、スクラムマスターもインドネシア側にアサインしています。日本側はアーキテクトやテスターが参加しています。また、自分はプロダクトオーナーとしてチームに参加しています。

Eさん：
私のプロジェクトはエンタープライズ企業のDX化施策として、業務システムの新規構築を行っています。お客様の要望によりアジャイル（スクラム）開発を採用しました。お客様が担当されているプロダクトオーナーを中心にスクラムチームを構成して、開発メンバーは当社のエンジニアが担当しています。自分はスクラムマスターとして参加していますが、マネジメントのためにプロジェクトマネージャーも兼任しています。

Rさん：
私のところは３年程前からスタートした先進技術開発分野のアジャイルプロジェクトで、技術で世界をリードしていくというミッションを持っています。プロジェクトは４チームで構成されており、シーエーシー社員は開発メンバーとして参加しています。プロダクトオーナーとスクラムマスターは顧客側が担われています。私はどちらの役割にも属さず、プロジェクトマネージャーとして開発メンバーが高いパフォーマンスを出せるようなマネジメントをしています。

――　世界をリードできる技術を目指したいというミッションは探索性に優れたアジャイル開発にマッチしていて、いいですね！

――　役割分担については、業務に精通した方がプロダクトオーナーを務め、システム開発に精通した方がスクラムマスターを務める傾向があるようですね。一概にどうあるべきか決めることが難しいですが、どのように役割を果たすかにフォーカスしてアサインすべきでしょうね。

――　皆さんのプロジェクトは背景も開発内容も進め方もかなり違うようですので、課題感もきっと様々だと思います。可能な範囲で構いませんが、自分のプロジェクトで一番苦労したこと、そしてどのように対応したかを教えてください。

Ｅさん：
私のプロジェクトでは、お客様はとても前向きな姿勢でアジャイルに取り組まれているため、経営層や管理層を含めて抵抗感は感じなかったのですが、アジャイル実践ノウハウをあまり持っていませんでした。今回のシステムはお客様社内の多くの部門と関わっていますので、プロダクトオーナーの方は様々な社内調整を行いながら要件をまとめなければならず、網羅性のある要件作りとその実現方法の検討は、けっこう難しい部分がありました。

当初はかなり壮大な計画になっていましたが、あまり現実的ではなかったので、現状を踏まえてお客様にとって何が一番大事かということを何度も意識合わせしました。まず納期を最優先したいというお客様からの要望で、アジャイルの考え方に基づきMVP（Minimum Viable Product＝顧客に価値を提供できる最小限のプロダクト）を決定し、スコープを見直しました。お客様もこのゴールの見直し結果に納得していただきました。

また、チームメンバーだけではなく、関係者にも正しいアジャイルプロセスと意味を理解していただかなければ価値のあるシステム開発はできないので、ステータスホルダーを含めお客様の関係者向けのアジャイル講習会も実施しました。

そして、立ち上げから軌道に乗せるまではアジャイルコーチに参加してもらい、多忙なプロダクトオーナーの補佐役としてプロダクトオーナーサポートという役割を追加し、要件整理や開発メンバーとの調整などを手伝いながら、お客様とワンチームでやってきました。

あとは業務システムを開発する場合によく起こる問題ですが、システム内部には多くの業務機能を持っているので、バックログ作成時にその整合性と網羅性の観点から仕様をきちんと決めておく必要があると思います。そうでなければ、最初に機能Ａを作成し、その後ニーズも徐々に変わってきたところで機能Ｂを作成してしまうと、最初に作った機能Ａとの整合性が合わなくなり、そのための追加対応も発生してしまいます。

――　この問題について、ウォータフォールで開発していたら大丈夫だったのですか？

Ｅさん：
ウォータフォールでは最初に全体の仕様をきちんと決めるので論理的な整合性はとれているはずなのですが、それでもシステムテスト段階で整合性に関する不具合が見つかることもあります。アジャイルの場合はテストしながら開発していますので、ある意味で早い段階でこのような問題を見つけることができてよかったかもしれません。

――　なるほど。ニーズが変わっているから、以前作ったものとの整合性が合わなくなるケースも考えられるので、早く見つけて対応できることはアジャイルの良さとも言えるでしょうか。

――　アジャイルプロジェクトでは似ているようなシーンがよくあるような気がしますが、他のお二人はいかがでしょうか？

Oさん：
ありますね（笑）。リリーススプリントで整合性の不具合を見つけて対応する事は時々あります。これも開発規模がどれぐらいかによりますが、リリーススプリントの中で対応するか、それとも次のスプリントにしてしまうか、いつも相談しながら決めています。ただ、デグレーションをなるべく避けたいので、軽微な修正以外は、基本的にリリーススプリントに入れていません。

Ｒさん：
私のところは研究開発なので、手探りの状態が基本となります。その為事前の仕様決定もあまり明確に行っていません。長期的な目標をある程度立て、各スプリントで実施可能な範囲を決め、整合性を保ちながら進めています。その為、今までにこのようなケースはありませんでした。

――　続いて、オフショアアジャイル開発プロジェクトの話を聞かせてください。

Ｏさん：
一番難しいと感じたのはやはり見積でしょうね。アジャイル開発ではポイント見積が普通ですが、ポイント付与は開発チームの感覚値のため、チーム立ち上げ時の見積はどうしてもスケジュールと乖離が生じやすく、参考にならない可能性が高い。特に初めて業務や技術に関わる場合は、経験豊富なメンバーでも起こりえる課題です。
こういった初期見積の乖離に備え、ある程度慎重に工数とポイントを策定する必要があります。開発チームが仕様や機能にある程度馴染んでからもう一回見積をすると精度が上がりますので、一定期間経て再確認することは有効な対策と思います。

また、これはオフショア開発でよく出てくる問題ですが、プロダクトオーナーとして開発メンバーに仕様を説明し理解してもらう必要がありますが、国が異なるため、日本独特のビジネス習慣や業務内容を理解してもらうのはけっこう難しく感じました。正しく仕様を理解してもらうために日本側で仕様書を作成していました。ドキュメント作成の費用は発生しますが、複雑な仕様に対する理解が進むので作成したほうがいいと思います。

あとは言葉の問題ですが、開発メンバーは全員英語を話せますが、日本側の英語力も必要になり、複雑な仕様を英語で説明するには限度があります。そこでネイティブの社員にプロダクトオーナーのサポート役を担当してもらっています。まずプロダクトオーナーサポートにシステム全体の仕様を理解してもらい、その上で単なる通訳とならないようにオフショアメンバーに仕様説明をしてもらっています。これはコミュニケーションに欠かせない重要な役割を果たしてくれていると思います。

――　ウォータフォール型のオフショア開発と比べて何が違いますか？

Oさん：
アジャイルの開発メンバーにはより高い技術力が求められると思いますね。ウォータフォール開発と同じようにリリース時期を予め設定し同じ開発期間を設けたとしても、スプリント毎に結果を出していかなければならないので、全員の戦力をうまく発揮する必要があります。簡単なことではありませんが、その目標に対する達成感はチームのモチベーション向上に繋がっています。

また、アジャイルでは一つのチームとして一緒に仕事するので、日本側/オフショア側、発注側/受注側のような関係性は一切なくなります。このような作業スタイルはプロダクトオーナーとしてはかなり覚悟が必要ですが、開発の自由度と効率はウォータフォール型より上がります。

――　オフショアアジャイル開発はハードルが高そうですが、技術力やコミュニケーションを工夫すれば大きなメリットを出せると感じました。

――　R&D分野はアジャイル開発に向いていると思いますが、Rさんは難しく感じたことはありますか？

Ｒさん：
お二人のプロジェクトと違って、R&D分野では元々詳細な仕様を決めず開発しながら実証実験を行っていくという特徴があるので、アジャイル開発には非常に向いています。

苦労した事でいうと、どのように開発メンバーのパフォーマンスを向上させるかという部分ですね。ウォータフォールと違って、アジャイルの場合は要件の把握、設計、開発、テストまで一人で全てのフェーズに対応できていないとパフォーマンスをうまく出せません。経験豊富な中堅技術者は大丈夫ですが、若手メンバーにとってはハードルが高いかもしれません。チームの足を引っ張らないように彼らへのフォローとサポートが必要です。

また、私のプロジェクトではスプリント期間を一週間と設定しています。その期間内でしっかりと成果を発揮するというスピード感が求められます。ウォータフォールに慣れているメンバーが初めてこのようなアジャイルプロジェクトに参加する際は、そのスピード感に追い付くためにかなり努力が必要であると考えます。

――　そうですか。先ほどOさんがアジャイルエンジニアに高い技術力と即戦力を求められると言っていましたが、スピード感もアジャイル開発の特徴の一つですね。特に研究開発の世界ではスピード勝負なので、アジャイル開発の必要性はより高いでしょう。

今回は、代表的な３種類のアジャイルプロジェクト（R＆D、エンタープライズ業務システム、オフショアアジャイル）の現場でそれぞれよく遭遇する課題と解決策について話を聞きました。
次回は続いて、多くのアジャイル担当者が抱えている課題（品質担保、ドキュメント作成、アジャイル効果の発揮）にフォーカスし、具体的なやり方や改善方法を聞いてみます。

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