まずはできるところから!ウォーターフォール派も試してみたくなるアジャイル開発の新しい試みとは <後編>

まずはできるところから!ウォーターフォール派も試してみたくなるアジャイル開発の新しい試みとは <後編>

こちらは、メンバーズエッジカンパニー主催で開催したウェビナー「まずはできるところから!ウォーターフォール派も試してみたくなるアジャイル開発の新しい試みとは」の書き起こし記事です。(前編はこちら)

登壇者紹介

Renee Liken氏(フォード・モーターFordLabs プロダクトマネージャー
フォード・モーターの顧客体験の最適化を担う研究所、「FordLabs」のプロダクトマネージャー。過去にアジャイル開発環境や中小企業の経営、クリエイティブエージェンシーにおけるデザイン業務のキャリアを持つ。
FordLabsでは、UXデザイナーやプロジェクトマネージャーを経験し、ビジネス要件、プロダクトビジョン、そしてユーザの目的到達に何が必要かを見極めることに長けている。現在はプロジェクトリソースの状況を踏まえたうえでリリースに向け、開発チームを支えている。

Jonathon Bezak氏(フォード・モーターFordLabs プロダクトマネージャー
フォード自動車にてソフトウェアエンジニアとして活躍。入社後、自動車組み立て工場の車両スケジューリングシステムの改善に従事。それからは同社の車両エンジニアやデータサイエンティストにアナリティクスソリューションを提供。以前はウォーターフォール派であったが、現在はリーンスタートアップと人間中心設計を専門とするプロダクトマネージャーとして革新的なソリューションをアジャイルに検証し、新たなビジネスチャンスを模索するのに貢献している。

アジャイルな計画づくりへの道

別のケーススタディを見てみましょう。「アジャイルな計画づくりとは」についてです。アジャイルに挑戦するとは何かについてお話してきたので、今度はアジャイルなリリースと計画作りとは何かについてお話します。以前いた組織で起こったことについてお話します。Fordではなく、とあるスタートアップです。私が近い位置で働いていたリーダーシップのチームは、彼らが以前所属していた組織で、20~30年ほどのウォーターフォール開発の経験がありました。アジャイル開発チームにリリース計画の共有を切望しましたが、コミュニケーションに苦戦していました。コミュニケーションは非常に大事ですが、残念ながら、顧客と共有しているロードマップは顧客との打ち合わせ用にリーダーシップチームが作ったPowetPointのみという状況でした。Excelで作られた機能一覧はありましたが、定期的にアクセスできるのはプロダクト責任者だけでした。何が求められているかをアジャイル開発チームが理解するのは、非常に難しい状況でした。

この課題を解消するために、まずホワイトボードに手書きすることから始めました。どんな顧客要件か、どういった期間で構築されているかを追い始めました。まずは2週間ごとなどの直近の期間からはじめ、その後に月間の単位で検討しました。ホワイトボードはすばらしく、直近で何が行なわれるか、またソフトウェアチームとして緊急で解決すべき課題についての共通認識を持つことができました。しかし、ホワイトボードセッションが終わると進捗管理ができなくなるためこの方法は恒久的には使えませんでした。

そこで、ふせんを試しました。まず、1枚の黄色いふせんに1つの機能を書くことから始めました。そして、リーダーシップチームに次のリリースに含めたい最も優先度の高い機能を特定してもらいました。リリースは通常、数ヶ月に一度でした。コードネームとして、各リリースに国立公園の名前をつけました。この例では「セコイア」です。このリリースにはたった6つの機能しか載っていませんでしたが、それでもふせんがあることで、開発チームは構築すべきものをきっと理解していると思い込んでいたのが、各機能について開発チームとすり合わせる機会を生むことができました。

プロジェクトを進める中で、ホワイトボードとふせんはさらに進化していきました。私たちは、リーダーシップチームがステータスを頻繁に確認できるよう、また、どのようなものが構築されているのかを理解できるように、彼らの机の近くにボードを設置しました。そしてこのようなものから、次のようなものへ変わっていきました。「この開発は始めた?」「これは進んでいるの?」「これは終わっているの?」「この機能がどういう風になっているかは、いつ確認できるの?」といった会話が繰り返されていたので、カンバン形式で管理することにしました。「Needs Planning」の部分にある機能は、何を作るのかの認識をまだ開発チームと揃えておらず、開発を始める前に、活発的な議論が必要なものです。リーダーシップチームの近くにボードがあったので、ふせんが動いていく様子が彼らに伝わっていきました。この例では、「お、セコイアはかなり進捗してもうすぐ完成だね」といったようにです。

当然ここから更に進化しました。各開発チーム内の進捗管理をどのように行なうべきかについて話し合いました。この写真は、6~8の開発チームがそれぞれ個別の機能の進捗を管理しているボードです。カンバンによく似ていて、「TODO」「In Progress」「Review」「Complete」の4段階ですが、「In Progress」の中で5チームに分割したセクションを設けています。特定のリリースに対してどのチームがどの機能にアサインされているかをリーダーシップチームのメンバーがひと目で理解することが可能になりました。また、「Pullaheads」というセクションも追加しました。

この写真でも確認できますが、優先度別に塊として分けて見られるようなホワイトボードを作りました。左側に1、2、3、4と数字があります。私たちは「Pullaheads」にあるアイデアの検討を始めました。Pullaheadsとは、あると良い機能のことです。しかし、何をPullaheadsとするかについての議論は簡単には決着しませんでした。段に分ける形で優先度付けを可能にすることで、リーダーシップチームがどの機能を確実にリリースに間に合わせるべきかについて具体的な会話を持つことが可能になりました。1段目が次のリリースに含めるべき最も重要な機能です。その下にある優先度2段目が、その次に重要なもので優先度3段目、4段目の機能は重要な機能ではありますが、特定のリリース機会に間に合わなくてもそれが致命的ではないということです。また、それぞれの列には検討しているプロダクトを配置しています。つまり、各列にあるプロダクトには異なる優先度をアサインされた開発チームが紐づいていることを示しており、コミュニケーションがとりやすくなりました。これらすべてが「今、私たちはリリースに向けてどこにいるか」「リリースまでに何をすべきか」についてのよりよいコミュニケーションに役立ちました。

そのうちに、ふせんでも不十分になりました。私たちのチームはアメリカに住んでいる人、ドイツに住んでいる人、そのほかの国に住んでいる人など分散したチーム構成でした。もっとデジタルな解決策が必要になったのです。そのため、壁に貼ったふせんでの管理からExcelでの管理へ移行することを決めました。この表では、それぞれのふせんが1行になっています。リーダーシップチームと私はどの機能を次のリリースに含めるかをミーティングで話し合いました。

その後、Atlassian社のWiki製品であるConfluenceを使って各開発チームと情報共有を行ないました。その後、Aha!という全ての機能の情報を持つ集中データベースのようなツールの利用へと更に進化していきました。ここに見られるように様々なレポート生成が可能になり、リーダーシップチームとはカードのような見た目のレポートを使って開発チームとはSIチーム、DPチームといったフィルタリングを用いたリストベースのレポートで共有するようになりました。

ここで得た学びとしては、計画は大事です。そして、意思決定者が慣れている計画プロセスから始めるべきです。そこから進化することはいつでも出来ます。あなたが歩む進化の形は、私のとは全く異なるでしょう。それでよいのです。なぜなら、あなたの意思決定者のための進化だからです。ステークホルダーの懸念に答える形で見直し進化させていきましょう。なぜなら、同じ質問を繰り返しされることはないからです。彼らが学ぶごとに、あなたのプロセスは改善され、より深い質問になっていくはずです。そして、繰り返しになりますが、開発チームとリーダーシップチーム、もしくはステークホルダー、それぞれで異なる計画のアウトプットを出すことには価値があります。もし私が全員に対して同じアウトプットを出していたら、そこから何かを得るものは誰もいなかったと思います。多少時間がかかっても別々の2つのアウトプットをつくることで、実際に行動が起こり、リリース計画がきちんと完了するほうが望ましいと感じます。いいですね。あなたのチームにとって、有効な方法がたくさんあることを示すためのいい方法だと思います。しかし、小さな変更を加えてみてどのような効果があるか見るまでは実際のところわかりません。

結果ベースのロードマップとは

次はロードマップについてです。ロードマップのコンセプトについてまずストーリーをお話します。これはおよそ2000年前に考えられていた世界を表現した地図です。当時考えられていた、「世界はこうなっているだろう」という状態が描かれています。この地図には、現在の私たちが事実ではないと知っている事柄も描かれていますね。息を吹くことで貿易風を起こす人がいたり、あるはずのない場所に陸があったり、あるいは海があったり、何より、世界は球体ではなく平らであると考えられていました。私たちは今、これらのことが必ずしも現実ではないことを知っていますが、今日の地図が昔とは異なるように、あなたのロードマップも時を経て学び続けることによって変化していきます。

下の図はよくある伝統的なロードマップです。ここにはいくつかアジャイルらしくない点があります。例えばこのようなロードマップは、長期間を想定して作られていることが多いです。6ヵ月後、1年後またはそれ以上の時間をかけて実行される予定のことが書かれているかもしれません。でもこれはある種、詐欺のようなものであると誰もが知っています。なぜなら、ヒトは未来を予測する能力に長けていません。自分が遠い未来を予測できるわけがないと思っています。

また、この形式は日付と厳密な時間管理を重視しています。アジャイルでは、一般的に見積もりをより重視します。ある機能を一定期間で完了できると想定するとします。しかし、そこに厳密な時間的コミットメントを持たないでおくことが重要です。なぜなら、ソフトウェアというのは非常に難しいもので、変更が頻繁に発生するためです。とある機能に一定期間取り組むと、時間を見積もった時には想像もしていなかった事態が発生したりもします。ですので、このようなロードマップはたった数週間で予定が狂い始めることが非常に多いです。

ここでご紹介するのが、「結果ベースのロードマップ」というコンセプトです。これまであなたが見てきたものはアウトプットベースのロードマップです。このように考えることができます。例えば、左側には私たちが想定する「アウトプットベースのロードマップ」が描かれています。この地図には、あなたが進むべきルートが決まったものとして描かれています。不必要な詳細情報もたくさん含まれています。実際に起こっているかどうかわからない渋滞予測も含まれています。一方、右側には「結果ベースのロードマップ」が描かれています。こちらは、目的地とそれがどのようなものであるかはわかっていて、そこに行きたいという目的があっても、目的地に至るまでの決まったルートがありません。余計な詳細情報もありません。そして、私たちは終わりが変わることだってありえると知っています。つまり、目的地そのものが変わることもありえるのです。

ぜひ、結果ベースのロードマップを作成してみてください。ロードマップの目的は、ステークホルダーや全社あるいは事業に関わる全員に進捗を見せ、何に取り組んでいるのかや、どのようにして目的地にたどり着くのかを共有し、コミュニケーションをとることです。そう、ロードマップはコミュニケーションツールなのです。このロードマップが優れているもうひとつの点は、不確実性と変化を受け入れており厳密な時間的コミットメントがないところです。例えば「Now」「Near」「Far」という列がありますが、一般化された時間枠になっています。このロードマップは、目的に応じて時間枠を変えることができます。例えば「Now」は今週やること、次の列は数ヶ月先までにやること、そして一番右側の列が半年先までにやること、としたり、あるいは「Now」は今月、「Near」は3ヶ月、「Far」は1年など。全てが一般化されていてお互いに関連を持たせられるので、それぞれの列にどのような意味を持たせるかはあなた次第です。

そして何より、このロードマップは「結果」にフォーカスしています。アウトプットではなく、結果に注力して考えるようにしましょう。アウトプットというのは、単純に仕事量を測るものです。例えば、「この機能とあの機能とあの機能を完了しました。」といえば、アウトプットの例です。結果というのは、「何を成し遂げましたか?ビジネスにどのようなインパクトを与えましたか?」といった問いに答えるものです。例えば、自社ECサイトの売上を向上するために検索機能の改善を行い、リリースしてユーザーに届けたとします。しかし、売上数量に変化がなかった。この場合、求める結果には至らなかったと言えます。アウトプットとしては、あなたは確かに仕事を行ないました。しかし、何の影響も与えることはできなかった。このロードマップで注力したいのは仕事の結果です。

また、このロードマップが優れている点として他にあげられるのは、現在、今週あるいは来週あるいは来月に何が起こっているのかを合理的に予測可能なことです。ただし、NowからNear、そしてFarに移るごとに物事は少しずつ曖昧になっていき、予定というより推測に近くなっていきます。そして、先ほどこのコンセプトを紹介するためにお見せした世界地図のように物事は変化していきます。ですから、ロードマップを更新し続けリリースを楽にしましょう。

あなたの職場で挑戦してみるべきことをまとめます。先ほども申し上げましたが、顧客はまれに起こる大きな変化よりも、頻繁に行なわれる小さい変化を好みます。頻繁なリリースとデモを心がけましょう。新しいバージョンや新しい機能のリリースを祝うことをやめましょう。それらはアウトプットであり、大事なのは結果です。計測し、望まれる結果を達成したら、その時にお祝いしましょう。そして、異なるグループにどのようにしたら情報が伝わりやすいのかを学び、違いを念頭に置いてコミュニケーション方法を変えましょう。みんなが同じ方法でコミュニケーションを行なうわけではありません。相手にあった方法を考え、実行しましょう。

アジャイルな環境でどのようにUXデザインをマネジメントすべきか

では、最後のケーススタディです。アジャイルな環境でどのようにUXデザインをマネジメントすべきか、私たちの経験をお話したいと思います。まず、デザイナーがリリースサイクルのどこに登場すべきかについて考えてみましょう。これまでアジャイルなリリースについて話してきましたね。果たしてデザイナーはどこに登場するのでしょうか?このホワイトボードに描かれた図のように、私が以前所属していた1~2人のデザイナーが所属する開発チームには、リリースまでにたくさんのデザイナーとの接点がありました。リーダーシップチームに説明するためのモックアップづくり・直近に行なわれたユーザビリティテスト結果の報告など・開発チームと直接やり取りし、ユースケースについて伝える・開発チームと想定するユーザー体験について議論する・構築完了後に開発者に伝えていたユーザー体験と適用された機能に乖離がないか確認する、などなどです。デザイナーは全ての場面で重要な役割を果たしています。そして私はこれが理想の形であり、デザイナーが全チームメンバーと関係構築をしっかり行なうべきだと考えています。

デザイナーにも、デイリースタンドアップ、スプリントプランニング、振り返りといったイテレーションのセレモニーに参加してもらいましょう。しかし、これは時にデザイナーの重荷になってしまいます。彼らはとても忙しいのです。そこでおすすめしたいのが、UXのタスクもアジャイル方式で管理することです。開発者向けのストーリーのように、デザイナー向けのストーリーを作成しましょう。リサーチに取り組んでいる時や、開発者のサポートを行なっている時、新しいモックアップやワイヤーフレームを制作する時など、先ほどお見せしたリリースサイクルを表したループの図には、さまざまなタイミングがあります。これらそれぞれをストーリーにすることで、優先度についてデザイナーと対話することが可能になります。なぜなら単に「このデザインをお願いね」と言われても、どれがすぐに必要で、どれが来週まで着手を待てるのかといった判断は、デザイナーには難しいからです。

以上の2つのことに取り組んで得た学びです。デザインのタスクを開発と同じように管理してみると、顧客へ提供する価値ごとにタスクを分割することができました。例えば、ある個別の機能に取り組んでいるとき、ページ全体をデザインするのではなく、1セクションとどのように顧客が見るかだけをデザインしました。このことは、計画全体の中で今何を行なっているか、また、それに紐づくインタラクションの詳細検討に役立ち開発チームと共に更にイテレーティブに動けるようになりました。スプリントプランニングやデイリースタンドアップといったセレモニーを、デザイナーとやることはとても価値があることですが、これらは同時に開発チームだけでも実践すべきでしょう。そうすることで、各位が抱えている課題や将来のユーザー調査で何を求めるのかについてなどを開発者だけでじっくりと話すことができます。私たちはカンバンボードを使いましたが、あなたに合った方法で管理すると良いでしょう。

定期的な対話は、どのように優先度をつけていくかだけでなく、デザインチームのキャパシティについても共有する機会になります。ストーリーのレビューといった開発者の支援や、ユースケースを伝えるといった業務によって、新しいデザインに時間を割く余裕が少なくなっているかもしれません。優先度の変更はいつでもデザイナーと相談できます。大事なことはコミュニケーションをとり、デザインチームがどこに時間を使うべきかについて、全員が同じ認識を持っている状態を維持することです。

お伝えしたいのは「今」のためにデザインするということです。デザインとしてどこに向かいたいかをはっきりさせておくことは非常に重要です。例えば、最終的なデザインを作成することや、1年後の姿を想定することは大事でしょう。しかし、アジャイルでは課題をいかにしてできる限り早く解決できるかを求めます。そのため「今」のためにデザインするという意識を持つことが非常に大事です。

顧客満足度を高めるために、小さく定期的なリリースを行なうべきであるとお伝えしてきましたね。例えば、顧客が職場へ車で向かうのに車輪だけを与えるわけにはいきません。それでは乗り物になりません。あるいは、上の絵のように2つの車輪だけ、あるいは車輪とボディだけがあっても、ハンドルがなければ意味がありません。それよりも重要なのは、スケートボードを与え、それが自転車、バイクへ発展し、最後に車となるようなメソッドで進めるということです。このメソッドでは、変化は小さくとも徐々に改善されていく形で製品を届け、顧客が目的を達成し続けることができます。こうしたプロセスを進める中では、今できることに注力してデザインできているか気を配りましょう。

そしてデザイナーがいかに重要か、また彼らが開発のどこで登場するのかについてお話します。これは、とあるビルにある非常用はしごの写真です。非常はしごがここにあることは大事ですね。このビルの横には、非常はしごのほかにメーターがいくつかあり、扉と有刺鉄線が上部についたフェンスに囲われています。メーターがきちんと守られていることは重要ですが、非常はしごで降りた先が、有刺鉄線のあるフェンスに囲われた場所であるというのは、良いデザインとは到底いえません。このようなことは、開発チームとデザインチームが一緒に取り組んでいないときによく起こります。彼らがもし一緒に取り組んでいたら、両方のニーズを満たしていたはずです。メーターを守りながらも、罠の中に誘導しない非常階段を作ったことでしょう。

では、あなたの職場で挑戦してみるべきことです。課題を特定し、デザインチームに開発チームと共に有用な解決策を見つけるよう促しましょう。両者が共に取り組むことは非常に重要です。

「今」を意識したデザインをしましょう。遠い未来のことは気にしなくて良いのです。どこに向かうのかが見えていることは大事ですが、今ある課題を解決するほうが先決です。最後に、開発チームにデザイナーを組み込むことを検討すること。先ほど申し上げたとおり、この2者が一緒になって取り組むということは非常に重要です。デザイナーとエンジニアが一体であることは大きな成果をもたらします。

最後にお話したかったのは、私たちのインスピレーションの源についてです。私たちが特に気に入っている本がいくつかありますのでご紹介します。

リーン・スタートアップ

リーン・スタートアップは、アイデアをプロダクトに、プロダクトを企業に変える方法です。過去、技術に関しては「それで何ができるか?」という疑問がつきまとっていました。ハードウェアに注力し、速く動かせるかどうかが重要でした。実現可能かどうかはわかりませんでした。2020年のソフトウェアでは、ほとんどのことが実現可能です。私たちが持つ新たな疑問は、「人々は本当にこれを求めていて、使ってくれるのだろうか?」ということです。エリック・リース氏はこの本で、ビジネスアイデアを検証し、アイデアから成功するソフトウェアプロダクトを構築する方法について説明しています。

ユーザーストーリーマッピング

この講演ではユーザーがプロダクトを見つけて利用するまでのユーザージャーニーの整理についてお話しました。この本では、プロセス全体となぜユーザーストーリーを用いるべきで、なぜ共感が重要なのか、なぜユーザーのほうを見続けるべきか、といった考え方を説明しています。もしこのトピックについて興味があれば、ジェフ・パトン著の「ユーザーストーリーマッピング」を読むことをおすすめします。

インフルエンサー──行動変化を生み出す影響力

ウォーターフォールからアジャイルへ移り変わる中で、仕事に取り組み、最も興味深いと感じた本のひとつがVitalSmartsチームによって書かれた「インフルエンサー」です。著者の名前は本の表紙に書かれていますが、この本は、変革管理についてと目的を定めた後に達成のための重要な行動が何かを見出す方法を紹介しています。例えば、定めた目標を達成するために関係者に何を行なってもらわなければならないかといったことです。重要な行動が何かが定まったら、目標達成のためにどうしたら「その行動をとりたい」と人々に思ってもらえるかを考えなければなりません。この本には個人・社会・構造の能力と個人・社会・構造のモチベーションの6つの主な影響力の発生源が書かれています。そしてこれらのメソッドが、さまざまな組織でどのように活用されているかを示す事例がたくさん載っています。

ジョイ・インク 役職も部署もない全員主役のマネジメント

私はこの本に書かれている会社で働いていたことがあるのでバイアスがあるかもしれませんが、率いていたチームをウォーターフォールからアジャイルに変革する中で、リッチシェルダン氏が何を見て何を学んできたのかを知り、非常に勉強になりました。彼はその後、自分の会社を設立する道を選び、アジャイルに取り組み続けています。Menlo Innovationsというたった1社で起こったことですが、この本に書かれているリッチ氏や彼のチームが体験してきたことは、あなたの状況とも関連付けられるかと思いますし、社内でどんなことに挑戦するかを考えるヒントになると思います。

アジャイル開発についてや、ウォーターフォールとの違いを解説した記事
ウォーターフォール開発とは何か。概要を解説
プロダクトマネージャがアジャイル開発に取り組む際のポイント
アジャイル、スクラムの基本知識と、アジャイルを成功させるために大切な3つのこと

採用情報

メンバーズエッジで最高のチームで最高のプロダクトを作りませんか?

最高のプロダクトをつくる 最高のチームで働く

在宅でも、地方でも、首都圏でも。多様な働き方で最高のチームをつくり、お客様のプロダクトパートナーを目指します。アジャイル開発を通じ、開発現場の第一線で活躍し続けたいエンジニアを募集しています。