アジャイルコーチが見た開発現場～初めてのアジャイルでつまづく12のポイント～【プロジェクト開始時①】

アジャイルプロジェクトをそろそろ開始しようという時。
　「バックログも洗い出したし、抜け漏れがないかチェックしよう」
　「リリース計画を作ってみたけど、経過をマイルストーンとして置いておこう」
　「作る機能ごとに担当者を割り振ろうかな、タスクを一覧化しよう」
そんな事を考えていると、ふとWBSが欲しくなる時ありませんか？

関係者にプロジェクト概要を説明しようした際、どの資料を見せて説明するか迷う時があります。
ウォーターフォールではシステム計画とWBSがあれば説明できたのですが、アジャイルプロジェクトでは、WBSがありません。単にバックログの一覧を見せたとしても、おそらく理解を得るのは難しいでしょう。

そもそもWBSを作成する理由は、作業を洗い出し、構造化して整理することで今後のプロジェクトの動きを明確にすることにあります。そのため、全てのタスクが洗い出されており、階層化され、アウトプットや時期も明確にわかります。この未来予想図は大変わかりやすく使い勝手のいいものです。

ところがこれをアジャイルプロジェクトで用いようとするとうまくいかない場合があります。直近の作業を明確化することはできますが、半年先のタスクを洗い出すことは困難であったり、また細かなタスクは日々変更されるため、常にWBSを最新に保つためには管理工数が膨らんでしまいます。
小規模開発であればWBSを作成することは可能ですが、ある程度の規模になると手間暇かかる上に精度が低いものとなるのでお勧めできません。

そこでお勧めしたい方法は、リリース計画を拡張させるというアイディアです。

対外的にプロジェクトを説明する際、全体像はリリース計画だけでも説明可能ですし、さらに細かなステップや事業計画との連携など必要な情報があれば、それらを付け足していくことで自社に適したアジャイル未来予想図にすることが可能です。重要なポイントは、「いつ」「どのようなものが」できあがるのかと説明することですから、それらが明記されていればWBSである必要はないのです。
どのようにプロダクトを組み上げていくか説明する資料をリリース毎に作成・更新していくことでいつでも使える説明資料になります。

また、タスクの抜け漏れチェックをどのように行うかという点については、やはりバックログが基本となりますが、これについても工夫する余地があります。
事前にストーリーマッピングを行っている場合は大きな粒度のストーリーとの関係性またはどのナラティブフローに基づくものかを分類することで網羅性を見ることが可能になります。

また、一般的にエピック情報を付加することでカテゴライズが可能であることはご存知と思いますが、それ以外にもラベルやタグ付けをすることで機能によるカテゴライズや画面ごとの分類など詳細な整理も行うことができます。開発の観点からすると、紐づく画面やどの機能かといった情報を付与するのが望ましいでしょう。

資料が変わると最初は勝手がわからず戸惑うこともありますが、形式ではなく欲しい情報は何かという本質に立ち返ることで、使える資料が見えてくるのではないでしょうか。

日本では社外のITベンダーに開発を依頼することが一般的と言えます。
アジャイルプロジェクトにおいても、プロダクトオーナーは自社でアサインし、開発者やスクラムマスターは外部に委託するといったことも多いのではないでしょうか？
そんなプロジェクトにおいて少し気になるのは、開発者とプロダクトオーナーの距離感です。

多くの場合、皆さんお互いに気を使って誠心誠意プロジェクトに取り組まれるので問題というわけではないのですが、ワンチームとなることが求められるアジャイルにおいて、少しよそよそしさを感じることも多いのです。

例えば、リファインメント会議でプロダクトオーナーから仕様の説明があった場合、開発者の皆さんはそれを理解することに終始していないでしょうか？「お客様からの要件説明」という認識は間違いではないのですが、理想的ではありません。せっかく同じ目的に向かうチームなのですから、よりよい実装を議論するほうが建設的です。多くの場合、開発者のほうが実装経験を豊富に持っていたりしますので、使い勝手や実装期間の短縮などを意識して、「よりよい」実装アイディアを出すのは良いことなのです。

また、バックログについても要求仕様書として、それを絶対視するような開発スタイルも危険です。上記と同じ理由で、仕様の不整合や（間違いとはいわずとも）あまり最適でない実装方法を見つけた場合は、プロダクトオーナーとよく話し合うべきです。そこにお客様やITベンダーという垣根は必要なく、同じプロジェクトメンバーとして会話することが求められます。
　「こんなことプロダクトオーナーに聞いてもいいのかな？」
　「自分だったらこうするけど、お客さんが言うなら仕方ないか」
そんなことを考えていませんか？遠慮はいりません。プロダクトオーナーとは、どんなことでもいつでもコミュニケーションとるようにしましょう。

一方でプロダクトオーナーやステークホルダーも「開発委託先」という目線は一旦忘れることをお勧めします。彼らは開発のプロフェッショナルですから、彼らの意見を求めることもプロダクトの価値を高めるためには有効な手段です。そのためにもあまり格式ばった「会社vs会社」の構図にとらわれることなく、普段からフランクなコミュニケーションをとって、チームメイトとして付き合うことで、開発者から自然にアイディアが出てくるように雰囲気づくりをしましょう。

大切なことは、プロジェクトゴールに向かって、同じ目線に立つことで最速最善の結果を生み出していくということであり、契約や責任範囲といった会社間の取り決めは必要であるものの、現場の感覚としては、なるべくそういった敷居を感じさせないように配慮し、活発で意欲的な姿勢をお互いが持っていることのほうが重要と考えます。

このあたりを突き詰めていくと、効率的な職場づくりの観点でアジャイルな組織論まで派生していくことになりますが、難しい話はさておき、みんな笑顔で仕事をしたいものですね。

次回は続けて、プロジェクト開始時に起こりやすい別の問題点について解説します。