アジャイルって?GPTさんと対話しながら綴る、ビジュアル分析のサイクルとアジャイル開発
こんにちは!Rikaです。
Tabjoアドベントカレンダー、参加させていただきありがとうございます!今年は「アジャイル開発」をテーマに、GPTさんとコミュニケーションしながら、私の思いをお伝えしていきます。
はじめに
私には実感があります。
「Tableauのダッシュボード開発とアジャイル開発は相性がいい!」
Tableau Creatorの皆さんご存じ、ビジュアル分析のサイクル、を改めて見返して、その親和性を紐解いていきましょう。
ユーザーが最初のタスクや質問からスタートし
→ユーザーストーリーの作成
どのステップでも繰り返すことができます。
→イテレーティブなアプローチ
私はアジャイルコーチのようなアジャイルの専門家ではありませんが、ビジュアル分析のサイクルのそこここに、アジャイル開発のエッセンスを感じ取ることができます。そして、ビジュアル分析で忘れられがちだが、大事な事も、アジャイル分析の中に感じるのです。
アジャイル開発とは
さて、早速GPT4さんと一緒に進めていきましょう!
Rika
アジャイル開発について、ダッシュボード、特にTableauを用いたダッシュボードやレポート作成者に伝わりやすい形で、開設してください。
ブラボー…私の誤字(開設→解説)も上手に無視して回答してくれました。
GPTさんが説明してくれた通りなので、あえて私から申し上げることはありませんが、強調すべきなのは、これらのキーワードでしょう。
柔軟で迅速
短期間の開発サイクル
ユーザーストーリー
透明性とコミュニケーション
継続的なコミットメント
ビジュアル分析のサイクルとの共通点
柔軟で迅速
ビジュアル分析のサイクルの内側を見てください。ステップの間をめまぐるしくいったりきたりするこの矢印。
ビジュアル分析は、この柔軟な試行錯誤を歓迎します。
Get dataして Choose visual mappingをしている間に、Taskに疑問を感じれば、もう一度分析の目的に立ち返ります。
Develop insightの時点で、データ品質に疑問を感じれば、ためらいなくGet dataをやり直します。
価値観の点で似たアプローチであると感じます。
ユーザーストーリー
ユーザーストーリーとは、これもGPTさんに教えてもらいましょう。
Rika:ユーザーストーリーとは。who why whatのキーワードを入れて解説してください。
ビジュアル分析のサイクルで、最も大事な事。それは、「タスクから始める事」。
分析の目的を忘れてはいけない、というとても強いメッセージです。
とはいえ、「タスクを決めろって言われても…」と多くのTableauユーザーが途方に暮れ、とりあえず分析のための分析を始めてしまう姿はよく見ます。
そんな時に役に立つのが、アジャイル開発における、ユーザーストーリーの作成手法です。
Who, Why, Whatという3つのWを押さえたアプローチのおかげで、解像度高くタスク(why)に迫ることができます。
ダッシュボード・レポートの作成者であれば、必ず押さえておきたい手法です。
アジャイル開発が思い出させてくれる、ビジュアル分析で忘れがちなこと
短期間の開発サイクル
BIツールを用いたダッシュボードやレポートの開発は、本来素晴らしくスピーディです。
その中でもTableauのスピード感は抜群と感じています。
一方、ダッシュボードの開発計画の中には、半年以上のものも多く見られ、何か月も経って出来上がったダッシュボードを見て、「なんか想像と違う…」という不幸な出来事が後を絶ちません。
アジャイル開発では、プロジェクトを小さな段階(スプリント)に分割します。各スプリントは一般的に2週間から1ヶ月、小さく設定した「スプリントゴール」を短期間で達成し、わずか2週間や1か月の成果物だったとしても、スプリント毎にユーザーからのフィードバックを得て次のスプリントに反映します。
これによって、スピード感を維持しつつも、「なんかこれ違う」という不幸を防ぐのです。
透明性とコミュニケーション
継続的なコミットメント
ビジュアル分析のサイクルとアジャイル開発の一番大きなニュアンスの違いは、主語がIか、Weか、にあるように私は思います。
ビジュアル分析のサイクルは、分析者にチームの気配はあまりなく、Iのニュアンスが強いため、ともすれば、分析者の頭の中でサイクルが完結します。
セルフサービスBIによる分析アプローチであるので、これはこれで自然なのかもしれません。
一方、アジャイル開発では、クロスファンクショナルな「スクラムチーム」を形成し、Weで取り組みます。ご想像の通り、ソフトウェアの開発には、BIよりもより多くの役割(プログラマー・デザイナー…)が必要なので、チームで取り組むのが前提となっているからでしょう。
これもGPTさんに解説してもらいましょう。
Rika:スクラムチームについてごくシンプルに解説してください。
プロジェクト期間中、開発者で形成されたスクラムチームは、スプリントという短期間の区切りで、ユーザーからのフィードバックと自分たちの成果物によるコミュニケーションを密に、しかも継続的に行います。
BIツールを使ったダッシュボードやレポートを作る営みは、1人で行ってしまった方が効率が良いシーンが多いですし、セルフサービスBIというくらいなので、リッチな分析業務を一人で完結させてしまえることは、良いところでもあります。
しかし、ともすると、
ユーザーを置き去りにしてしまったり、
ユーザー側も「じゃ、良きに頼むよ、できたら教えて」のような、
コミュニケーション不足があったのでは、と私はアジャイル開発に出会って思うようになりました。
そして、せっかく作っても見てもらえないダッシュボードが山積されるわけです。
BIの開発者がアジャイルに出会って
正直に言うと、最初は、
「いやー、ダッシュボード1個つくるのに、こんなに人巻き込んで、コミュニケーションしなきゃだめなの?!めんどくさいな」
と思いました。
けれど、ユーザーのフィードバックや、BIツールのユーザーでなくても関る余地のあるアクティビティを通じたコミュニケーションの過程で、徐々に、「私のダッシュボード」から「みんなのダッシュボード」になっていく姿を見て、
あぁ、面倒かもしれないけど、組織のダッシュボードとして活躍するようなダッシュボードを生み出すには、多くの人に関与してもらうしかないんだ。
と実感するようになりました。
私もまだまだ学びの途上ですが、Tableauユーザーがアジャイルに学ぶことは多いです!
ぜひ一緒に学びましょう!
この記事が気に入ったらサポートをしてみませんか?