Pivotal Labs Tokyo最終回のコラムは、プロダクトマネージャーの坂田さんによる寄稿です。
なぜアジャイルが注目されているのか、デザイナーはアジャイルなチームの中でどのような役割を担うのかなどについての内容となっています。
こんにちは、Pivotal Labs のプロダクトマネージャーの坂田です。
Pivotal Labs を知らない方が多いと思いますので、簡単にご紹介しますと弊社オフィスでクライアントのチームと一緒に開発をすることを通して、アジャイルチームの育成をサポートする米サンフランシスコに本社を置くコンサルティング会社です。2015年に東京オフィスが開設されてから、ラクスルなどのスタートアップから Yahoo! JAPAN やANA といった大企業まで様々な規模、業種の組織へ向けたリーン・アジャイル開発の支援を行なっています。私はそこのプロダクトマネージャーとして、毎日楽しく働いています！
さて、これまでの「アジャイルチームのデザイナー」シリーズでは弊社のプロダクトデザイナーの伊藤がデザイナーの立場から、アジャイルなチームにおけるデザイナーの価値を最大限に発揮するためのアプローチや手法をご紹介してきました。シリーズの最後となる本記事では、プロダクトマネージャーの視点からアジャイルチームの在り方、そしてデザイナーの在り方を考えていきたいと思います。
アジャイルなチームはサステナブルであり、フレキシブルでもある
最近ニュースを賑わせているサービスの早期撤退に代表されるように、インターネット業界は非常に流れが早く、変化も早いです。その変化に対応するためには、ソフトウェアのみならずチームにも目を向ける必要があります。なぜなら、ソフトウェアをつくったとしても、その開発を常に続けなければユーザーに価値を提供しつづけることが難しくなるからです。そのため、今、正に求められているのは「確かなものを正しくつくり、ユーザーの反応を見ながら素早く学び、そして変化に対応できるチーム」なのです。
Pivotal Labs が考える、アジャイルなチームとしての在るべき姿は「Deliver Value Fast, and Forever」を体現できることです。直訳すると、「素早くつくり、頻繁にリリースしながら持続可能なペースで続けられる」ということです。つまり、理想的なアジャイルなチームは動くソフトウェアによってビジネス並びにユーザー価値を創出し続けることができます。
ソフトウェア開発のあるべき姿は、マラソンに例えることができます。最初から全力疾走で走るのではなく、負担が少ない一定のペースを保ちながら進むことで上り下り、追い風や向かい風といった急な障害や状況にも焦ることなく対応ができるようになります。だからこそ、マラソンランナーは長距離でも走りきることができるのです。
なぜ今、アジャイルなチームが求められているのか？
従来のソフトウェア開発手法であるウォーターフォール型開発は、要件定義、設計、開発、テスト、リリースという上流工程から下流工程へ順番に完了しながら移行していく開発手法です。この開発手法の特徴は、一度完了した工程に移行したら戻れないことです。開発を進める際に、問題や漏れなどがあった場合は、戻ってやり直す必要があり（場合によっては最初からやり直すことも！）時間とコストがかかってしまいます。
そのため、ウォーターフォール型開発は、変化に弱い開発手法と言えます。今つくっているソフトウェアを素早く検証しなければ、最初に決められた要件を満たすことがゴールとなってしまい、開発が終わって世に出す頃にはユーザーに使われずに失敗に終わってしまうケースがあります。
では、どうすれば成功の確率を上げることができるのでしょうか？それは、失敗するリスクが高い「思い込み」を特定し、検証方法を考え、その「思い込み」は結果として正しかったのか、間違っていたのかを検証して学習し続けることです。そのためのチームが、今求められているのです。
ケーススタディ：Zappos を成功に導いたチームの取り組み
実際にはどのような取り組みをすべきなのか。靴のネット通販会社「Zappos」がビジネスの成功確率を上げるために、実際に行なった取り組みをご紹介します。
リスクの高い思い込み：人はネットで靴を購入するだろう
検証方法：
- サービスの入り口となる簡単なウェブサイトを用意し、販売を開始
- 在庫は自社で持たず、サイト上で靴が売れたらショッピングモールに出かけて靴を購入
- 発送も物流業者に頼らず、郵便局に出かけるなど、すべてをマニュアル作業で行う
結果：ユーザーは、実際にお金を払って Zappos 上の靴を購入した
最初から完成されたサービスをつくらず、実際は裏を手作業で進めることで、ソフトウェア開発をせずに投資額を最小限に抑えながら、ユーザーのニーズを早期に確かめることができたのです。
この場合の最も危険な思い込みは「人はネットで靴を購入する」ことです。当時（1999年）はネット通販が普及する前だったため、本当にどれほどの人がネットで靴を購入するかわかりませんでした。この思い込みが違っていた状態のままで開発し、システムを構築していたらどうなっていたでしょう？
最終的にユーザーがネット上で靴を購入したことは変わりませんが、実際に世に出るまで分からないという不確実性が高い、まるでギャンブルのような状態が続くのは持続可能なチームを構築する上ではよくありません。Zappos のような取り組みが実践できるチームこそ、今求められているアジャイルチームなのです。
まとめ：アジャイルなチームにおけるデザイナーの在るべき姿とは？
以上のことから、私が考えるアジャイル・チームにおけるデザイナーの在るべき姿とは、リスクが高い思い込みを検証可能な仮説に落とし込み、最適な方法で検証する方法を見出し、実行と計測を続けられる存在だと思っています。
チームが考えているユーザーはターゲットとすべき人かどうか、という疑問があったとしましょう。そのための検証方法として、伊藤が当シリーズのコラム「ユーザーインタビューでよくある失敗例と成功のコツ」でご紹介したようなユーザーインタビューを通じてユーザーのファクトやニーズを把握する必要があります。
既にあるアイディアまたはソリューションは最適なのだろうか？少ない労力で検証することができるペーパープロトタイプなどを用いてコンセプト案を出してみましょう。別案のユーザーインターフェイスを採用することで、今よりも使い勝手がよくなる、という思い込みを検証するには、オンライン・プロトタイピングツールを利用してユーザーの行動を観察・分析することを推奨します。ユーザーが問題なくタスクを終えることができれば、少しづつビジュアルデザインの確度を上げて実際に動くソフトウェアをエンジニアが主体となってつくっていきます。
しかし、これらをすべてデザイナーが1人で行うことは難しいです。プロダクトマネージャーやエンジニアといった他のチームメンバーをどんどん巻き込んでいきましょう。そして、伊藤が当シリーズのコラム「デザイナーはチームの中でこそ最大限に力を発揮する職種である」で紹介したように、チームにおける意思決定といったアクティビティにも積極的に参加し、ユーザー視点をチームに持たせましょう。そうすることで、ソフトウェアを、チームをより成功へと導くことができるはずです。
これまでの話を振り返って見ると、デザイナーの価値は、デザインをする立場からデザインを導く立場へと変わっていっているように私は思います。それも、ソフトウェアのように持続的に。
Pivotal (Pivotal Software, Inc.)について
Pivotal は、クラウト゛ネイティフ゛・フ゜ラットフォームと開発ツール、ユニークなメソト゛ロシ゛ーを組み合わせ、 世界の大手企業か゛最も重要なソフトウェアアフ゜リケーションを構築し実行する方法の変革をこ゛支援していま す。 当社のテクノロシ゛ーは、ク゛ローハ゛ル 2000 企業か゛ソフトウェア開発およひ゛ IT 運用における戦略的優位 性を達成するために使用されています。
企業サイト：
https://pivotal.io/jp/
