アジャイルって？GPTさんと対話しながら綴る、ビジュアル分析のサイクルとアジャイル開発
こんにちは!Rikaです。
Tabjoアドベントカレンダー、参加させていただきありがとうございます！今年は「アジャイル開発」をテーマに、GPTさんとコミュニケーションしながら、私の思いをお伝えしていきます。
はじめに
私には実感があります。
「Tableauのダッシュボード開発とアジャイル開発は相性がいい！」
Tableau Creatorの皆さんご存じ、ビジュアル分析のサイクル、を改めて見返して、その親和性を紐解いていきましょう。
ビジュアル分析は、直線的ではないプロセスです。たとえば、ユーザーが最初のタスクや質問からスタートし、関係するデータを探して、分析のための準備を行ったとしましょう。分析を行っていると別のデータが必要なことに気づき、そのためステップをいくつか遡ってさらにデータを入手し、新しいビジュアルマッピングを選んで、新しいインサイトを引き出します。ビジュアル分析のサイクルではこの例のように、どのステップでも繰り返すことができます。
ユーザーが最初のタスクや質問からスタートし
→ユーザーストーリーの作成
どのステップでも繰り返すことができます。
→イテレーティブなアプローチ
私はアジャイルコーチのようなアジャイルの専門家ではありませんが、ビジュアル分析のサイクルのそこここに、アジャイル開発のエッセンスを感じ取ることができます。そして、ビジュアル分析で忘れられがちだが、大事な事も、アジャイル分析の中に感じるのです。
アジャイル開発とは
さて、早速GPT４さんと一緒に進めていきましょう！
Rika
アジャイル開発について、ダッシュボード、特にTableauを用いたダッシュボードやレポート作成者に伝わりやすい形で、開設してください。
アジャイル開発をTableauを用いたダッシュボードやレポート作成に適用する際、以下のような形で説明すると理解しやすいでしょう。
アジャイル開発とは？
アジャイル開発は、ソフトウェア開発の柔軟で迅速なアプローチです。この手法は、大規模な計画や長期の開発サイクルではなく、短期間の作業サイクル（スプリント）に焦点を当て、継続的な改善と顧客のフィードバックを重視します。
Tableauでのダッシュボード開発にアジャイルを適用する
スプリント計画：
Tableauプロジェクトを小さな段階（スプリント）に分割します。各スプリントは一般的に2週間から1ヶ月です。
スプリントごとに特定のダッシュボード機能やレポート要素を計画します。
ユーザーストーリーの作成：
ダッシュボードの各機能や要件をユーザーの視点から「ユーザーストーリー」として記述します。
例：「セールスマネージャーとして、私は週別の売上データを見たい、なぜなら目標に対する進捗を追跡したいから。」
フィードバックと反復：
スプリントの終わりに、作成したダッシュボードやレポートのプロトタイプをレビューします。
ユーザーやステークホルダーからのフィードバックを受け、それを次のスプリントでの改善に活用します。
柔軟性と改善：
ビジネス要件やユーザーのニーズが変わった場合、迅速に対応し、ダッシュボードを調整します。
継続的なテストとフィードバックにより、品質を高めながらダッシュボードを改善します。
透明性とコミュニケーション：
プロジェクトの進捗、課題、成功事例をチーム内外で共有します。
定期的なミーティングやデモセッションを通じてコミュニケーションを保ちます。
メリット
迅速なデリバリー：アジャイルは迅速なデリバリーを可能にし、ユーザーの手に早く製品を渡すことができます。
柔軟性と適応性：市場や要件の変化に対して素早く反応し、ダッシュボードを適宜調整できます。
ユーザー中心の開発：ユーザーのニーズに焦点を当て、彼らのフィードバックを積極的に取り入れます。
注意点
継続的なコミットメントが必要：アジャイルは定期的なレビューと改善を必要とします。
全員の協力が鍵：チーム全体がアジャイルの原則に従い協力する必要があります。
ブラボー…私の誤字（開設→解説）も上手に無視して回答してくれました。
GPTさんが説明してくれた通りなので、あえて私から申し上げることはありませんが、強調すべきなのは、これらのキーワードでしょう。
柔軟で迅速
短期間の開発サイクル
ユーザーストーリー
透明性とコミュニケーション
継続的なコミットメント
ビジュアル分析のサイクルとの共通点
柔軟で迅速
ビジュアル分析のサイクルの内側を見てください。ステップの間をめまぐるしくいったりきたりするこの矢印。
ビジュアル分析は、この柔軟な試行錯誤を歓迎します。
Get dataして Choose visual mappingをしている間に、Taskに疑問を感じれば、もう一度分析の目的に立ち返ります。
Develop insightの時点で、データ品質に疑問を感じれば、ためらいなくGet dataをやり直します。
価値観の点で似たアプローチであると感じます。
ユーザーストーリー
ユーザーストーリーとは、これもGPTさんに教えてもらいましょう。
Rika：ユーザーストーリーとは。who why whatのキーワードを入れて解説してください。
「ユーザーストーリー」は、アジャイル開発において使用される、製品やサービスの機能を記述する手法です。ユーザーストーリーは通常、"Who（誰が）", "Why（なぜ）", "What（何を）" の三つのキーワードを用いて構成されます。これらの要素は以下のように定義されます：
Who（誰が）：
この部分では、どのユーザーまたは顧客が対象であるかを特定します。これは、特定の機能や改善を必要としている人を明確にすることで、開発の焦点を絞ります。
Why（なぜ）：
ここでは、その機能や改善が必要な理由、すなわちユーザーがその機能からどのような価値や利益を得ることができるのかを説明します。この理解は、製品の利用価値を最大化するために重要です。
What（何を）：
最後に、具体的にどのような機能や改善が必要かを述べます。これにより、開発チームは具体的な目標に向かって作業を進めることができます。
例えば、ユーザーストーリーは次のようになります：「ビジネスアナリストとして（Who）、私は詳細な売上データをリアルタイムで見ることができるダッシュボードを望む（What）。なぜなら、より迅速にデータ駆動型の意思決定を行えるようになるから（Why）」。
このアプローチにより、開発チームはユーザーの視点から製品やサービスを考え、ユーザーの実際のニーズに合わせて価値を提供することが可能になります。
ビジュアル分析のサイクルで、最も大事な事。それは、「タスクから始める事」。
分析の目的を忘れてはいけない、というとても強いメッセージです。
とはいえ、「タスクを決めろって言われても…」と多くのTableauユーザーが途方に暮れ、とりあえず分析のための分析を始めてしまう姿はよく見ます。
そんな時に役に立つのが、アジャイル開発における、ユーザーストーリーの作成手法です。
Who, Why, Whatという３つのWを押さえたアプローチのおかげで、解像度高くタスク(why)に迫ることができます。
ダッシュボード・レポートの作成者であれば、必ず押さえておきたい手法です。
アジャイル開発が思い出させてくれる、ビジュアル分析で忘れがちなこと
短期間の開発サイクル
BIツールを用いたダッシュボードやレポートの開発は、本来素晴らしくスピーディです。
その中でもTableauのスピード感は抜群と感じています。
一方、ダッシュボードの開発計画の中には、半年以上のものも多く見られ、何か月も経って出来上がったダッシュボードを見て、「なんか想像と違う…」という不幸な出来事が後を絶ちません。
アジャイル開発では、プロジェクトを小さな段階（スプリント）に分割します。各スプリントは一般的に2週間から1ヶ月、小さく設定した「スプリントゴール」を短期間で達成し、わずか２週間や１か月の成果物だったとしても、スプリント毎にユーザーからのフィードバックを得て次のスプリントに反映します。
これによって、スピード感を維持しつつも、「なんかこれ違う」という不幸を防ぐのです。
透明性とコミュニケーション
継続的なコミットメント
ビジュアル分析のサイクルとアジャイル開発の一番大きなニュアンスの違いは、主語がIか、Weか、にあるように私は思います。
ビジュアル分析のサイクルは、分析者にチームの気配はあまりなく、Iのニュアンスが強いため、ともすれば、分析者の頭の中でサイクルが完結します。
セルフサービスBIによる分析アプローチであるので、これはこれで自然なのかもしれません。
一方、アジャイル開発では、クロスファンクショナルな「スクラムチーム」を形成し、Weで取り組みます。ご想像の通り、ソフトウェアの開発には、BIよりもより多くの役割（プログラマー・デザイナー…）が必要なので、チームで取り組むのが前提となっているからでしょう。
これもGPTさんに解説してもらいましょう。
Rika：スクラムチームについてごくシンプルに解説してください。
スクラムチームは、スクラムというアジャイル開発フレームワークにおいて、製品やサービスの開発を行う自己組織化された小規模なグループです。スクラムチームは主に以下の特徴を持ちます：
小規模：
チームは通常、5〜9人程度のメンバーで構成されます。
クロスファンクショナル：
チームメンバーは、プログラミング、デザイン、テスト、ビジネス分析など、必要なさまざまなスキルを持っています。
自己組織化：
チームは、外部からの直接的な管理指示なしに、自らの作業を計画、分担、実行します。
コラボレーションとコミュニケーション：
チームメンバー間では、緊密なコミュニケーションと協力が重視されます。
主要な役割：
スクラムマスター：チームがスクラムの実践を適切に行えるよう支援します。
プロダクトオーナー：プロダクトのビジョンとバックログを管理します。
開発チーム：製品の開発に直接関わるメンバーです。
スクラムチームは、定期的なスプリントと継続的な改善のプロセスを通じて、製品開発を進めていきます。
プロジェクト期間中、開発者で形成されたスクラムチームは、スプリントという短期間の区切りで、ユーザーからのフィードバックと自分たちの成果物によるコミュニケーションを密に、しかも継続的に行います。
BIツールを使ったダッシュボードやレポートを作る営みは、１人で行ってしまった方が効率が良いシーンが多いですし、セルフサービスBIというくらいなので、リッチな分析業務を一人で完結させてしまえることは、良いところでもあります。
しかし、ともすると、
ユーザーを置き去りにしてしまったり、
ユーザー側も「じゃ、良きに頼むよ、できたら教えて」のような、
コミュニケーション不足があったのでは、と私はアジャイル開発に出会って思うようになりました。
そして、せっかく作っても見てもらえないダッシュボードが山積されるわけです。
BIの開発者がアジャイルに出会って
正直に言うと、最初は、
「いやー、ダッシュボード１個つくるのに、こんなに人巻き込んで、コミュニケーションしなきゃだめなの？！めんどくさいな」
と思いました。
けれど、ユーザーのフィードバックや、BIツールのユーザーでなくても関る余地のあるアクティビティを通じたコミュニケーションの過程で、徐々に、「私のダッシュボード」から「みんなのダッシュボード」になっていく姿を見て、
あぁ、面倒かもしれないけど、組織のダッシュボードとして活躍するようなダッシュボードを生み出すには、多くの人に関与してもらうしかないんだ。
と実感するようになりました。
私もまだまだ学びの途上ですが、Tableauユーザーがアジャイルに学ぶことは多いです！
ぜひ一緒に学びましょう！
この記事が気に入ったらサポートをしてみませんか？