#Sprint 2 アジャイルチームをスタートするために、最初に必ずやるべきこと（templateあり）
こんにちは、Yachiです。
前回“アジャイルとは何か？”をテーマに、アジャイルの考え方やScrum（アジャイルの手法の一つ）の特徴を説明しました。
これからアジャイルのワークフローについて書きたいと思います。今回のお題は、一番最初に行うステップ“準備”です。
「じれったいわね。早くメソドロジーまとめて書きなさいよ」
「ロール・プロセス・アウトプット（Sprint 1 参照）を詳しく書いてくれ」
と思う方もいるかもしれませんが、正しい準備を経ずにアジャイルを始めると、たいてい失敗します。
よく見られるのが、事前に準備をせずプロセスだけ真似るケースで、ウォーターフォールの進め方を短サイクルで回し続ける“なんちゃってアジャイル”になってしまいます。
そうすると、従来のやり方と何が違うか良くわからなかったり、ユーザー（顧客）との関係は御用聞き状態になったりします。何より、チームメンバーの疲弊感や不満が顕著です。
「...アジャイルって...こんなにしんどいの？」
という声が、ヒソヒソと聞こえてきます。
1.チームをスタートラインに立たせる
Scrumにおいては、開発メンバーに権限を与え、自律的に運営をします。Scrumでは、“自己組織化されたチーム“と呼んでいます。
自己組織化されたチームを作るには、
・チームのビジョンやルール（ワーキングアグリーメント）の統一
・メンバーの意欲やチャレンジングな雰囲気の醸成
この2つが、とても重要です。
これらを最初に行わないと、スプリント（Scrumにおける開発サイクルの単位）期間中にベクトル合わせやルールの再検討に時間を費やすことになります。低くなったモチベーションを上げるアクションなど、非効率極まりないものです。
そうすると、各スプリントにおけるチームのニュートラルな生産能力が見えなくなり、生産性を確認しながらオペレーションの改善を図るアジャイルとして、機能不全になります。
ちなみに、僕は過去に“ベクトル合わせのミーティング”なるものをひたすら行っていたチームに所属していたことがありました。3ヵ月のプロジェクトの2ヵ月目くらいまでベクトルを合わせていた気がします（辛かった！）
大上段が途中で変わってしまうと、そこを目指して動いていた人の心情としてはやるせないですよね。
日々の会話で、
「僕らの目的って○○だよね」
「ルールに照らして考えてみよう」
と、確認することは良いですが、そもそもの目的やルールを再考するプロセスは避けるべきです。
では、このような事態を避けるために、どのような準備をすればよいのでしょうか？代表的なものが“インセプションデッキ”の作成です。
インセプションデッキは、プロジェクトの開始にあたりチームとして合意すべき項目を10個の質問に分けて用意しています。
簡単に言えば、“プロジェクトのWhy/Howを明確にする”ステップになります。アジャイルに関係なく、チームビルディングに必要な要素が厳選されています。現に、コンサルワークの中で最初にこれを用いる人もいます。
またインセプションデッキに加え、Assignment・Business Environment・Communication・Trainingの4つを事前に決めておくことをおススメします。
インセプションデッキ+ABCT（やや収まりが悪いですが）で、チームをスタートラインに立たせましょう！
☝プロジェクトの全体像（目的、背景、方向性、優先順位、体制など）を端的に伝えるドキュメント“インセプションデッキ”の詳細が記載される良書。ネーミングとジャケットのインパクトは強いが、実践的な内容が良く書かれています。
2.インセプションデッキを作る
インセプションデッキは、以下10個の項目で構成されています。全て必要な要素ですが、今回はいくつか厳選（★の部分）して説明します。
①我々はなぜいるのか(★)／②エレベーターピッチ／③パッケージデザイン／④やらないことリスト(★)／⑤ご近所さんを探せ(★)／⑥解決案を描く／⑦夜も眠れない問題(★)／⑧期間を見極める／⑨何を諦めるのか(★)／⑩何がどれだけ必要か
・我々はなぜここにいるのか
プロジェクトが始まった背景や目的（ゴール）に答える質問です。単に顧客のリクエスト（○○機能を持ったアプリを作る）ではなく、顧客や関係者にインタビューをしながら、本当に解決したい課題は何か、実現したいことは何か（○○へXXXを提供したい）を浮き彫りにします。
そうでないと、最終的に「別のソリューションの方が良かった」ということにもなりかねませんし、チームのモチベーションにも響きます。イシュードリブンよりもビジョンドリブンの方がワクワクするのと同じですね。
・やらないことリスト
プロジェクトのスコープをに答える質問です。何を作るか考えると、どうしても“やること”にフォーカスされます。ここでは、やらないことも含め、“やる・やら”を決めていきます。
優先してやるべきことを浮き彫りにするために、初回リリースのタイミングを前提に考えることがポイントです。あとで決めるものは、“未定”というボックスに記録します。
・ご近所さんを探せ
ステークホルダー（関係者）を整理するための質問です。実はあまり開発そのものには関係のない人が加わっていたり、意思決定者やキーパーソンが明確でなかったりすると、後々のコミュニケーションに影響してしまいます。
主要関係者だけでなく、広い範囲で関係者（なぜか加わっている部外者）を洗い出し、ステークホルダーマネジメントをします。
・何をあきらめるか
別名トレードオフ・スライダー。機能・予算・期間・品質の優先・劣後を明らかにする質問です。これらはすべてトレードオフの関係にあります。機能を増やしたり期間を縮めるには、さらに開発メンバーのアサインが必要になったりします。
当初立てた計画通りに進まなくなった場合などのイレギュラー時の判断軸になります。
もっと詳しく知りたい方は、“アジャイルサムライ“を読むことをお勧めします。
インセプションデッキを作成する本来の価値は、アウトプットそのものではなく、メンバーや関係者とプロセスを共有することにあります。各項目の最終的な合意は必要ですが、正確性や妥当性を突き詰めることよりも、メンバー個々の考えを浮き彫りにさせることを優先させます。
つまり、インセプションデッキは疑問や不安を引き出すツールなんです。
僕は、インセプションデッキを作成したのち、メンバーがいつでも見られるフォルダに保存をしています。そうすると、メンバーがいつでもプロジェクト立ち上げ時に立ち返ることができ、認識が行動がバラバラになる抑制機能となります。
過去には、①「我々はなぜここにいるのか」の議論紙をスクリーンセーバーにしているメンバーもいましたw
以下に、インセプションデッキのtemplateを載せておきます。一般的なフレームですので使用の際に加工は必要ですが、チームワークが伴うほぼ全てのプロジェクトに使えます。
3.ABCT（Assignment・Business Environment・Communication・Training）
ABCTはインセプションデッキの作成の過程において議論がされることがありますので、インセプションデッキ作成時に“意識しておくべき観点”という意味合いで記載をします。
①Assignment（メンバーのアサイン）
Scrumにおいては、プログラマー、テスター、アーキテクト、デザイナーなどの明示的な区分けはされず、一人が多数のタスクを担える“多能工型“で機能横断的に運用されることを目指します。専門性があることは重要ですが、専門のフラグが立っているとタスクを割り振る場合、プロジェクトのフェーズに応じてメンバーの作業量に偏りが生じてしまうからです。
また、メンバーが全て兼務でない必要があります。兼務の場合、50%/50%という前提であっても、現実的にはそう上手く業務量が割り振れることは不可能だからです。
②Business Environment（システム・ツール、ファシリティなど）
アジャイルはシステムやツールに依存するわけではありませんが、ツールによるシームレスなコミュニケーションやダッシュボードでの現状の可視化などで、より生産性を高めることができます。アジャイルのプロジェクト管理ツールとして代表的なものはJIRA（Atlassian社）ですが、Slackなど馴染みのあるツールを用いているチームも多く見られます。
ファシリティはホワイトボード、付箋、マーカー、お菓子（？）など様々です。完全なScrumチームではありませんが、僕の場合、コンサルワークにおいてハンディのホワイトボードを使ったりしています。
☝持ち運べるホワイトボード“バタフライボード”。ブレインストーミング、ディスカッション、インタビュー、面接など、様々なビジネスシーンで活躍しています。見た目もスタイリッシュで注目を浴びます。
③Communication（コミュニケーション、レポートライン）
メンバー間のコミュニケーションやレポートラインのルールは予め決めておきましょう。
例えば、僕の場合、メンバー間のコミュニケーションではリアルタイムフィードバックを決めています。サポートや協働の際には必ずフィードバックを交換するようにしています。あとは、ポジティブで未来形（○○すれば良かった（bud）、○○したらもっと良くなる（good!））のコミュニケーションルールを徹底しています。
レポートラインは、誰に何を報告するか迷わないようにするものです。基本的にはチームの体制を決めた際に設定します。
④Training（アジャイルのトレーニング）
必ずしも、メンバー全員がアジャイルの進め方に慣れているわけではないので、トレーニングの環境を用意します。
研修をやるイメージではなくて（プロジェクト開始前にできるのであればしたほうが良いです）、アジャイルのプラクティスの中で習得できるような仕組みを創ることです。僕の場合は、初心者と経験者でバディを組んだり自己学習できるツールや書籍を渡したりしています。
重要なのは、全員が進め方を理解し、チームとして成熟したアジャイルチームになることです。
4.まとめ
最後に要点をまとめます。
・機能するアジャイルチームとは、自己組織化されたチームである
・自己組織化されたチームになるために、“チームのビジョンやルール（ワーキングアグリーメント）の統一“、“メンバーの意欲やチャレンジングな雰囲気の醸成“を事前に行う
・事前準備には、インセプションデッキの作成が有効である。また、ABCTの観点を用いて作成を行う
・インセプションデッキは疑問や不安を引き出すツール。アウトプットそのものよりも、検討のプロセスやそのあとの使い方に価値がある
次回は、準備以降の具体的なプロセスについて書いていきます。