「イテレーション0」をやらないアジャイルは出だしでつまずく
渡会健氏（以下、渡会）：あと、もう1つ次のヒントで、イテレーション0をやらないアジャイルは出だしでつまずくんじゃないかなというところで、よく、アジャイルをやるための準備としてイテレーション0、もしくはスプリント0というものをやりましょうという話をします。
その時によくアジャイルの本で書いてあるのは、こちらです。「インセプションデッキを作りましょう。ユーザーストーリーマッピングをやりましょう。それで初期プロダクトバックログを作りましょう」。
これ、大事です。作るものの準備のRebuildもしなきゃいけないんですが、意外に忘れがちなのは作り方の準備ですね。
ソフトウェア開発の場合、どんなことをするかというと、構成管理のルールを決めたり、コーディング規則を決めたり、やってみて、「あぁ、ここ違うな」と思った時にどんどん改善するのはいいんですが、初めから野放図で当てずっぽうで始めるんじゃなくて、最初からそういったものを決めていく。
イテレーション1が始まった時には、もう使える成果物が出せる準備を整えていく。この両輪が必要なんですが、だいたいこっち側（アジャイルプロセスのための準備）だけで終わっちゃうことが多いので、やるとしたら、作り方の準備をやっていただければなと思います。
作り方の準備をやらないで、結局作り始めてから「あれがうまくいっていない」「これがうまくいっていない」となると、実際のものづくりに集中できないということが生まれちゃったりもします。
あとは、イテレーション0する時にはスキルマップを作ります。このスキルも、アジャイルなのでやはりRebuildしていくよというかたちでやります。
例えば参画した当初、自分はこういったところに強みがありますよ。プロジェクトが終わった時にはこういったところを伸ばしたいですよ、みたいなことを見える化しておく。こういうことをしていくと、実際にタスクをやっていく中で、モブワークなりペアワークなりをする時に、誰と誰を組めば技術のトランスファーができるかね、みたいなことを考えながらやっていける。
スキルそのものをみんなでRebuildしていくことができる仕掛けがけっこうあったりします。
生産性の高いチームほどコミュニケーションを惜しまない
もう1つ、最後のヒントですが、「生産性の高いチームほどコミュニケーションを惜しまないようになるのはなぜか？」というところで、コミュニケーションの取り方のスタンスもだいぶ違っています。
例えばウォーターフォールの場合、できるだけ作業者の手を動かす時間を増やしましょうということに着目します。「そのために会議の時間を短くしましょう」とかね。「とにかく個人がワークできる時間、手を動かす時間をなるべく増やそう、そのために会議を減らしましょう、会話を減らしましょう」。そういったことをけっこうしていくことがあります。
アジャイルではどうするかというと、いかに能力の差を縮めるかというところで考えた時に、プランニングが結局、肝になっていくんですね。だいたい生産性に大きく差が出るのは、いわゆる従来型開発でいうところの設計フェーズですね。
要は、何をどうやって作るのかっていうところで、経験値とか、こういう関数があるとか、知らない使い方だったりとか、ベテランだったら知っているようなノウハウをプランニング会議で全員で共有する。そういうことをすると、あとは手を動かすだけになっていくんですね。
このタスクを振られました、そこから自分で一生懸命やり方を調べてやっていくのではなくて、モブワークじゃないけれど、みんなでモブ設計をしていって、こういうふうにしていくんだよというのをプランニングの中でやってしまえば、あとは新卒だろうがなんだろうが、手を動かすことができる。誰でも助けやすくなる。それはなんでかというと、モブワークの時にどういうものを作るかをみんなで共有しているから。
そういうことをすると何が起きるかというと、一生懸命コミュニケーションを取ろうとするんですよ。プランニングの会議だけじゃないです。実際にタスクを実行する時に、あちこちで話し合いが行われるんですよ。「ここ、どういうふうに作るんだっけ？」「あっ、こうだったよね」「あっ、じゃあ、こう作ろうね」みたいなのをどんどんどんどんやってコミュニケーションをどんどんどんどん高めていく。こういうことをして、実は効率を高めていくよというかたちをしているのがアジャイルの仕組みなんじゃないかなと思っています。
アジャイルのNo.1カンパニーを目指していく
実はMSOL（株式会社マネジメントソリューションズの略称、エムソル）に来てから、研修のテキストみたいなかたちでノウハウを溜めていたのですが、それを今回、全部Rebuildして、ノウハウもRebuildをして、本のかたちにまとめています。もしご興味があれば見ていただければなと思います。
今、我々は、MSOLの中でデジタルを推進していくためには、アジャイルのNo.1カンパニーを目指していかなきゃいけないよねということでやっています。
最後に、今日は後ろのほうのスポンサーブースで、いろいろなものを配っています。今日の講演ではしゃべっていませんが、弊社の事例をまとめたパンフレットをお配りしていますし、抽選で本などが当たります。
あとは、先ほど経歴の中にあったとおり、私はIPAの回し者でもあるので（笑）、そこで出している冊子も置いてあります。IPAの冊子は無料で配っているので、ぜひ取りに来ていただければと思います。
それでは、本日の講演は以上とさせていただきます。どうもありがとうございました。
（会場拍手）
クライアントの社内事情でロールのRebuildができない時は？
司会者：渡会さま、ありがとうございました。ここから5分間のAsk the Speakerに移ります。質問がある方は挙手をお願いします。いかがですか？
質問者1：お話、ありがとうございました。渡会さん、先ほど資料の中で、従来のプロジェクトマネージャーの役割の変化、ロールのRebuildについてお話しされたと思うんですけど。
クライアントさんにこういったご提案をする、ご紹介をする時に、クライアントの社内事情でどうしてもできない場合はありますか？ もしそういうことがあった場合、どういったご提案やアプローチをされているのかをちょっとお聞きしたいです。例えば、適切な人がいないとか、いろいろあると思うんですけども。
渡会：一番、ここに気をつけてくださいというところで、「従来のプロジェクトマネージャーの意識、役割のままでアジャイルチームにどっかりと入らないでください」と言います。
もし、その立場の人たちが入るのであれば、どの役割かを自分で絞って、その役割に専念してくださいという話をすることで、1人の人に責任の集中するリスクを下げています。
ただ、やはりスクラムマスターという役割は、従来型のことをやっている人たちにはなかなかなじまないので、こういったところは、我々がサポートしたり、スクラムマスター代行を出したりとか。スクラムマスターが育つまで、我々が人を出して支えますよ、みたいなことはやっていたりします。
質問者1：ありがとうございました。
プロジェクトの特性やチームの成熟度でイテレーション0の頻度を考える
司会者：（質問を見て）「年単位でアジャイル、スクラムで開発をしている場合、どの程度の頻度でイテレーション0を行えればいいでしょうか？」とあります。
渡会：年単位でアジャイル、スクラムの開発……年単位であろうがなんだろうが、我々は、そのチームの成熟度だったり、そのプロジェクトの特性で考えています。
例えば、チームがよちよち歩きでこれからアジャイルを学んでいかなきゃいけないという状況の時には、学びの機会とやり直しをする機会をできるだけ増やしたいので、1週間スプリントのような短いスプリントを提案することが多いです。
アジャイルに慣れていないから長い期間でやりたいというのは逆効果で、アジャイルに慣れていないからこそ短い期間でやっていかないとなかなかうまくいかない。
我々が新卒を教育する時には、1dayスプリントをしてアジャイルを教育したりしています。短いほうが教育効果は高まります。
逆に、ある程度アジャイルを何度もやっているメンバーでやっている時は、アジャイルにいちいち慣れる必要はありません。そうなるとタスクを作る時間のほうを増やしたほうがいいよねということで、1ヶ月スプリントみたいなことをしたり、普通に2週間スプリントでやったりしています。プロジェクトの期間が長い短いは関係なく、そういったリズムで選ぶことが多いです。
プロジェクトが長ければ長いほどアジャイルのほうが適している
司会者：ほかに会場から、いかがでしょうか？ 前のほうにいらっしゃいますね。
質問者2：ウォーターフォールとアジャイルのどちらを選択するかといった部分で、将来の予想がしやすいものがわりとウォーターフォールで、市場などの変化の影響を受けるものがアジャイルなのかなと認識してるんですけど。
数年単位の長期的な開発を前提にした場合、計画を出せるウォーターフォールのほうが適している気もしているのですが、数年単位だともちろん影響をいろいろ受けるのでアジャイルのほうがいいような気もしていて。
もう少し前提条件は増えるかもしれませんが、そういった部分だとどちらが適しているのか、もしくは、それぞれどういったメリットがあるのか聞きたいですね。
渡会：私の私見ですが、プロジェクトが長ければ長いほどアジャイルのほうが適していると思います。何が起こるかわからない世の中なので、計画を1回で立ててそこからもう動かせなくなってしまうというのは、非常に危険だと思います。
むしろ、半年とかで、「もうここまでの期間だったら状況も変わらないよね、一気に作ろうね」というプロジェクトこそ、ウォーターフォールでがっちり作ってしまったほうがいいんじゃないかなというのが私の感覚です。
質問者2：ありがとうございます。その場合、長期的な開発の最終的なゴールとして、わりとざっくりしたものを置くことになるんですかね。
渡会：それこそイテレーションが終わるたびに目標そのものを見直しています。要は、この目標で正しいのかを毎回毎回スプリントが終わるごとに確認している。
質問者2：ありがとうございます。そういうことですね。ゴールもそのたびに（設定する）ということですね。
渡会：はい。
質問者2：ありがとうございます。
MVPは決定権をもらったプロダクトオーナーが決める
司会者：そのほか、いかがですか？
質問者3：講演ありがとうございました。最小限の機能でリリースして、ROIを最短で向上することを判断するとうかがっていますが、競合他社もいる場合、これを出せば勝ち筋があるなとか判断するのは、開発メンバー、アジャイルメンバーだけだと厳しいとは思います。役員や部長など入って、どのように判断されるのか。MVP（Minimum Viable Product）と言われるところの決め方を教えていただけないでしょうか？
渡会：ありがとうございます。理想論でいくと、その人の立場はあまり関係ないです。現実論として偉い人が入ってくることがありますが、その偉い人ってだいたい忙しいんですよ。忙しくて意思決定をする暇がない人から決定権をもらえる、自由に考えられる人がプロダクトオーナーに座るというのが、肝かなと思います。
本当の責任者、最終的に責任を取る人がそのままプロダクトオーナーをやると、だいたいほかのことで忙しくてあまりやってくれないんですね。であれば、それに対しては「あなたたちに権限を渡しますよ」というところを出してやったほうが機敏な企業戦略には対応しやすいんじゃないかなと思います。
質問者3：では、MVPは、権限をもらったプロダクトオーナーが決めるということでよろしいですかね？
渡会：そうです、そうです。
質問者3：はい、ありがとうございます。
司会者：以上でお時間となりましたので、講演を終了させていただきます。渡会さま、ありがとうございました。
渡会：はい、ありがとうございました。ぜひブースにお越しください。
（会場拍手）
