アジャイルにおけるマインドセット

こんにちは。プロダクトチームのJennです。

今回は、私たちがプロダクト開発において用いてる多数のプロセスのうちの1つをご紹介します。おそらくあなたは知っているかもしれませんし、好きもしくは嫌いかもしれませんが、そのプロセスはアジャイルと言います。アジャイルとは一体何なのでしょうか？どこから来たものでしょうか？

本記事ではGoodpatchのプロダクトチームで用いているアジャイルプロセスを中心に、より理解を深めていただけるようにご説明します。

アジャイルって何？

アジャイルは、大規模なリリースではなく、小さな成果物で製品をリリースするためにチームやグループが使用する開発システムです。アジャイルはウォーターフォール開発の中でチームの欠陥を見つけたデベロッパー達の「アジャイルマニフェスト」によって提唱されました。彼らは共に集まり、作業プロセスとソフトウェアのアウトプットをどのように構築し維持するかのコアとなる部分を整えました。

アジャイルマニフェスト

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

これは2001年の出来事でした。社内のチームは毎日のワークフローにアジャイルを組み込み、製品をより迅速に開発し、小規模のチームを迅速に統合することに成功しました。では、私たちがこのアジャイルをどのように応用しているかをご説明しましょう。

アジャイルプロセスの概要

私達は作業を視覚化し、反復構造を維持するためにカンバンとスクラムを混合したスクラムプロセスを使います。カンバンとスクラムの違いについてはAtlassianのページで知ることができます。

名前	定義
ユーザーストーリー	ストーリーに分解された小さな作業ユニット：１タイプのユーザーとして、価値を見出すために機能が欲しい
エピック	ユーザーストーリーとタスクの本体
スプリント	チームが作業を終わらせる作業時間
バックログ	ロードマップとその要件から導かれた開発チームの作業の優先順位リスト
ストーリーポイント	ストーリーポイントは0,0.5,1,2,3,5,8,13などのフィボナッチ数で作業の労力を評価し、私達はデザインチームとして、Tシャツのサイズを使用してユーザーストーリーを評価します。（S、M、L、XL、XXL、α）

プロセスの始め方は以下の通りです。私達のチームは仕事のバックログを優先するビジネスの戦略計画に基づいて、実装したい機能を洗い出します。通常、このバックログはプロジェクトの最初のキックオフ前に作成されたデザイン調査/ビジネスニーズによって作られます。Some Useful Definitions

次にタスクと要件をユーザーストーリーに分解します。そのユーザーストーリーは予め並べた実装したい機能に基づいた大きな要素やエピックの作成に役立ちます。これにより、チームが完了しえる1〜2週間のスプリントにまたがる作業ユニットが作成されます。これらのストーリーはストーリーポイントにより重み付けされ、何を実施し、何をバックログに戻す必要があるのか​​をチームに知らせます。これらのストーリーをカンバンに載せ、デイリースタンドアップミーティングを行い、週を通して仕事の進捗状況を共有します。

アトラシアン・アジャイル・コーチ

スプリントの最後には、スプリントで完成した成果物のデモをチーム全体の前で発表し、リリースするか改善するかを決定します。デモの後には、レトロスペクティブを行い、スプリントにおけるチームの成功やペインポイントをシェアします。その後はスプリントプランニングを行い、バックログの中から、次のスプリントで行うタスクを決め、見積もります。全てはこの繰り返しです。

アジャイルでいること

アジャイルが何であるかはお分かりいただけましたでしょうか。では一体、「アジャイルでいる」とはどういう意味なのでしょうか？

私達は2週間のスプリント、毎日のスタンドアップミーティング、改善などの全プロセスを行っていました。スクラムは成功しているように見えたのです。しかし、各2週間のスプリントでは、成果が見えにくかったのです。完了した総合点は低く、チームが正しく見積もりしても何らかの理由でタスクを完了することが出来ませんでした。何がうまくいかなかったのでしょうか？
私はチームにジョインした当初から、転職前にいた環境の経験からチーム内の問題を発見することができました。私達は確かにアジャイルを行っていました。しかしアジャイルではなかったのです。ユーザーのニーズに基づいて意思決定をしていたわけでも、ユーザーの目標に標準を合わせたロードマップを策定していたわけでもなかったのです。あまりにも多くの人が1つのことを決定しようとして、チーム全体が身動きの取れない状況に陥っていたのです。なかなかスピードが出なかったことにより、チーム内でのボトルネックが解消できず、実装すべき機能は先延ばしになっていたのです。

私はデザインチームと協力してカンバンの再構築に取り組み、結果チームがユーザーストーリーに基づきタスクを整理できるようにしました。そして私達はミーティングをより生産性のある、気が散ることのないような構成しました。私達は迅速に動き、より多くのストーリーを完成させ、健全なバックログを持ち、チームが自主性を持つことを可能にしました。私達はより迅速に動けるように、チームの大きさと構造のバランス見つけようとしています。

プロダクトチームとスプリントプランニングをする様子

アジャイルになることはプロセスであるだけでなく、継続的に改善をし、失敗から早く学ぶというマインドセットでもあるのです。スプリントは早く学び、結果を次に活かすために役立ちます。スクラムやカンバンは、アジャイルのイデオロギーを成立させるためのシステムでしかないのです。

デザイン+アジャイル

多くのデザイナーは、アジャイルの厳密なルールによって制限されることを恐れ、デザインプロセスにアジャイルを応用しようとしません。アジャイルとデザインは、デザインの価値をよく分かってない人からすると、上手くいかないということには同意します。純粋なアジャイル・プラットフォームはデザイナーの生産性を向上し、より問題解決における価値を発揮しやすくします。

デザインとアジャイルの相互作用が上手く機能するかは、デザインプロセス上でアジャイルスプリントの機能が明記されているかに依存します。私たちはアジャイルをチーム内を明瞭にする手段として使用しますが、仕事と実装をアウトプットする方法は開発チームほど簡単ではありません。グッドパッチのデザインプロセスは次のとおりです。プロブレムスペースではユーザーのペインポイントを発見したり新しい機能を構築したり、現在の機能を修正します。これらの機能を念頭に置いてアイディエーションとテストを行い、新しい機能を実装します。その後エンジニアと共有し、デザインスプリントに追加します。これは、通常、ソリューションスペース内のビルドフェーズで発生します。アイデアの複雑さにもよりますが、先にチームに共有してフィードバックを得て正しい方向に進んでいることを確認します。私たちは、2週間のスプリントを使用して詳細な画面を作成・実装し、迅速にデザインを進めます。

私たちがしないことは、アジャイルをプロセスのすべてのステップに強制することです。特に序盤の機能のアイディエーションのフェーズなどには、適していません。プロブレムスペースとソリューションスペースの開始時には、私たちはスプリントを進捗報告として使用します。デザイン思考を抑制する可能性があるので、アウトプットを提示するためには用いません。DesignBetter.coはDesignOpsにまつわる素晴らしい本を書き、この発見と理解というアイデアを具現化しました。私たちはデザイナーがアイデアを自由に探求し、最良の詳細なデザインではなく、複雑な環境の中でも自由に最高のソリューションを創造してほしいのです。

学び

私はアジャイルのエキスパートではありませんが、アジャイルのフレームワークがどのような状況下で力を発揮するのかを見てきました。

アジャイルは、大きなプロジェクトや社内プロダクトの開発ではうまく機能します。複雑なシステムは、アジャイルとスクラムを使用して整理することができます。しかし、私の個人的な意見は、何かを素早くデザインしアジャイルの方法論に取り組みたいのであれば、フレームワークには手をつけないほうがいいです。 Googleの5日間のスプリントは、現実世界で何かを構築してテストするための迅速な作業の素晴らしい例です。

私が昨年のアジャイル環境で働いていたことから見てきた最も重要な学びは、価値のデザインが最優先だということです。デザインが最上位に評価されていない環境で働いている場合は、アジャイルになりましょう。素早く働き方を良い方向に持っていきましょう。

アジャイルワークフローについて他の考えやリソースを参考にしたい場合は、ぜひ下記の記事も読んでみてください。

https://www.designbetter.co/designops-handbook/introducing-designops
https://www.designbetter.co/principles-of-product-design/break-black-box
https://www.atlassian.com/agile
https://www.atlassian.com/agile/project-management/user-stories
https://www.intercom.com/blog/there-is-no-hand-off-product-design/