どうも、oskn259です。

皆さんは、アジャイル開発というものをご存知でしょうか？

アジャイル開発は、要求が変化するというソフトウェア開発の常において、 文字通り機動力の高い対応を可能とする開発手法として注目されています。

これに対し、設計や仕様を事前を定義する文書を初めに作成し、 その通りに開発を進めるウォーターフォール型開発という昔ながらの開発手法があります。
このケースでは、一度仕様が固まると変更がほぼ効かないため、 ビジネス上の価値と制作物が乖離しやすく、 「闇」 だとか 「大人の事情」 みたいな表現をよく聞きます。

ソフトウェア開発で家を粉砕することはありませんが、ビジネス要件の変更に対応できないのはやはり致命的です。
じゃあアジャイル開発一択じゃないかという事になりますが、 このアジャイル開発というものを正確に理解して実行している人がどれほどいるかは未知数です。

今回はアジャイル開発解説の名著 「アジャイルサムライ」 の内容を解説していきます。
筆者の理解をもとに解説するので、詳細や正確なところはぜひご自身で確かめて見てください。

https://www.amazon.co.jp/dp/B00J1XKB6K

PJにおける3つの真実

アジャイル云々に関係なく、ソフトウェア開発ではこの3つの事が必ず起こります。

• プロジェクトの開始時点に、全ての要求を集めることはできない
• 集めたところで、要求はどれも必ずと言っていいほど変わる
• やるべきことはいつだって、与えられた時間と資金よりも多い

この制約を認知して事前に対策するか、 無視して進んで途中でどうしようもない壁として現れるかは重要な差ですね。

アジャイルなメンバー

アジャイル開発では、 チームとしてその仕事を終わらせる ことを重要視します。
僕はコーダーだからテストは任せた、 私はデザイナーだから要件の抽出は預かり知らぬ、 ではないのです。
もちろん、デザイナーに難しいロジックを組ませるということではありません。
存在するタスクを、 必ず誰かが進められる状況 を確保するのです。

アジャイル開発の持つ特性から、以下のようなメンバーが向いていると言えます。

• ゼネラリスト傾向
• 曖昧で、変化しうる状況に抵抗がない人
• 我を張らない人

同じ職場で働く

アジャイル云々に関わらず、チームの生産性は同じ職場で集まって働くことで向上します。
質問が飛び交い、問題もすぐに共有できるためメンバー間での信頼が築きやすく、それが更なる速度向上に繋がります。

顧客というメンバー

メンバーの中で特に重要な役割を果たすのは、 顧客 というメンバーです。

顧客は何を作るべきかを唯一知っている、 真実の源 として深くプロジェクトに関わる事になります。
たまに経過を見てもらうだけでなく、MTGへの同席、毎日決まった時間の確保、 厳しい事実の共有など、密に情報共有をしましょう。
顧客の信頼を得て、協力を依頼するのは重要なミッションです。

インセプションデッキ

インセプションデッキを作成する事で、以下のメリットが得られます。

• 顧客に対する納得感のある説明と、期待マネジメントの両立
• PJがどこへ向かっているのか、メンバーが共通認識を持つ

プロジェクトの開始にあたって、これを数日~2週間程度の短期間で作成します。
初期の段階で何ヶ月もかけて正確な計画を策定する必要はありませんし、土台できません。

我々はなぜここにいるのか？

実際に顧客の解決したい問題を理解するために、 実際に問題が起きている現場へ足を運んで自身でそれを体験しましょう。
又聞きでは得られない体験をし、現場の人に質問をして、より詳細な情報を集めましょう。

例えば、 「当社は最安航空会社である」 のような簡潔な言い回しでそれを文章化しましょう。
これが土壇場での、進むか退くかの判断基準となります。

エレベーターピッチ

<潜在的なニーズの解決、抱えている課題の解消>したい
<対象>向けの
<プロダクト名>というプロダクトは
<プロダクトのカテゴリー>である。
これは、<対価に見合う重要な利点>ができ、
<代替手段の有名どころ>とは違って
<差別化の決定的特徴>が備わっている。

例えばこのような構成で、30秒でアイディアを伝える文章です。
用意することで、以下のような利点があります。

• 誰のための何なのかが明確になる
• チームの意識を顧客に向けさせる
• 本当に重要なことを明らかにし、優先順位を示す

パッケージデザイン

もし自分たちのプロダクトが商品棚に陳列されるなら、どんなパッケージが良いか？
時間制限を設けて、みんなで考えてみましょう。

1. ブレストでキーワードを洗い出す
2. 機能から踏み込んで、ユーザーにとっての効能を洗い出す
3. キャッチコピーを決める（世の中にインチキ臭くないキャッチコピーなど存在しない！）
4. パッケージデザインを描き出す

やらないことリスト

やること、やらないことをブレストしながら仕分けていきましょう。
時が来ないとわからないものは、後で決めるリストに入れておいてOKです。

ご近所さんを探せ

PJに将来関わる可能性のある人、部門、組織にはあらかじめあいさつをし、信頼関係を築きます。
チームでブレストしながら、関係者一覧を作成するのが良いでしょう。
PJ終盤で待ったをかけられるような事態は避けるに越した事はありません。

解決案を描く

アーキテクチャの図を書いて、不安要素、不確定要素について話し合いましょう。
顧客もMTGに参加してもらうことで、

• 期待のマネジメント
• どこまでやるのかを明確に伝える
• リスクを伝えられる

という意義も生まれます。

チームメンバー選定 = アーキテクチャ選定

「大きな金槌を持っていると、何もかもが釘に見える」

どんなメンバーも、自分の得意分野を生かして物事を解決しようとします。
メンバー候補者には得意領域をあらかじめ表明してもらい、 マネージャーの提案する解決策に足並みを揃えられるメンバーを選定することが重要です。

夜も眠れなくなる問題

• PJが中止になる可能性は？
• 顧客は時間を割いてくれるのか？
• メンバーが退職する可能性とその対策は？
• メンバーがリモートにこだわり、同じ職場で作業できない
• もし間に合いそうにない場合、誰がどのように対処するのか？

例えばこういった、 してはいけないんじゃないかと思うような手強い質問 を全て出してしまうのです。

これらを 取り組む値打ちのあるタスク とそうでないタスクに分類します。

例えば、景気が低迷してPJが中止になるかもしれない、 というのは我々が考えてもどうしようもないことです。
自力で変えられる事柄に集中し、そうでない出来事を受け入れましょう。

期間を見極める

重要なのは、 「初期の見積もりは、最善を尽くした当てずっぽう」 であることを認識しておくことです。
この当てずっぽうを元に、顧客に完了時期を確約してはなりません。

詳細な手順は後述します。

何を諦めるのかをはっきりさせる

どんなPJであっても、この4つの制約が立ち塞がります。

• 時間
• 予算
• 品質
• スコープ（どこまでやるか）

これらはトレードオフの関係にあり、何かのためには何かを諦める必要があります。
多くの場合、スコープを調整するのが良いでしょう。
「どれも最優先」 は現実と乖離しています。

また、上記の4つ以外にも必要と思われる項目を追加しておくのが良いでしょう。
期限通り、予算の範囲内、一切不具合もなく、予定通りのものができたとしても、 それが全く面白くないゲームでは意味がありません。

単なるPJの成功以上に、ビジネス的に成功させねば意味がないのです。

何がどれだけ必要なのか

ここまでの計画で、どんなメンバーがどれだけ必要かはなんとなく想像がつくでしょう。
開発者、デザイナーなどはともかくとして、顧客というチームメンバーは非常に重要です。

顧客は、

• PJのために時間を割いてもらえるか？
• PJ主導のための権限を与えられているか？
• 意思決定をする覚悟があるか？

といった資質を持たねばなりません。

最終判断を下すのは誰か？

PJにおける最終判断を下すのは顧客である、ということを顧客に認識してもらいましょう。

PJのステークホルダーや関係者が多数いますが、 彼ら全員の思惑を個別に聞いていたのではPJ内部で意見が衝突して、何かよくわからないものが完成するでしょう。

彼らの意見を聞いた上で、 最終判断する人間は顧客ただ一人 に絞らねばなりません。

費用はいくら？

このように概算できます。
メンバー単価 x 人数 x PJ期間

ただし、「3つの真実」に則れば、この時点で正確な見積もりをすることは不可能です。
期間の見積もりと同様に、 いい線いってる当てずっぽう であることは全員が認識しておきましょう。

ユーザーストーリー

ユーザーストーリーは、顧客が実現したい事を簡潔に書いたものです。
例えば、「ユーザー登録ができる」といった具合です。
これは言うなれば会話の約束であり、必要なタイミングで打ち合わせをし、詳細を確定させるのです。
半年前に打ち合わせしたとしても、状況が変わり、その内容は意味がなくなっている事でしょう。

すぐれたユーザーストーリーは以下の特徴を持ちます。

• ビジネス上の価値を記述する
• ストーリーごとに独立している
• 交渉の余地がある
• テストできる
• 小さく、見積もれる

また、例えば「ページのロードが2秒以内で終わる」といった、 全体にわたる制約のようなストーリーは、他のストーリーと区別して定期的にテストすると良いでしょう。

重要なのは、顧客が要件の洗い出しに積極的に関わるという事で、 そうであればユーザーストーリーを自分で記述しても構いません。

ユーザーストーリー収集ワークショップ

1. 広く見渡せる部屋に顧客とメンバーを集める
2. 制作物について、ブレストで出た内容を多数の図に（粗くイメージが掴めればOK）
3. それ眺めながら、ユーザーストーリーを抽出
   • 1~5日で実装できるサイズを目安に
   • それ以上のものはエピックとして保存し、後に判断
4. 負荷検証、書類仕事、運用手順書、関係者一覧、などの諸々もブレストしてストーリーにしておく

アジャイルでは、重厚な文章よりも対話を重要視します。
1日をかけてこのようなワークショップを行えば、 向こう半年程度の計画は立てられるでしょう。

見積もり

結局見積もりで知りたいのは、 このPJは実現可能なのか？ ということです。

不確実性コーンという言葉が示すように、初期での見積もりには大きな誤差があります。
そうした中で意味ある見積もりをするには、以下の点をおさえればOKです。

• 今後の計画を立てられる
• 当てずっぽうだという共通認識を持つ
• ソフトウェア開発は複雑だという共通認識を持つ

相対サイズによる見積もり

仕事のサイズを、日数などの絶対サイズではなく、他の仕事と比較した際の相対サイズで見積もっていきます。
ストーリーAを3とするなら、ストーリーBは5かなぁ、といった具合です。

ここで使用する数値は「ポイント」と呼ばれ、 1ポイントを何日でできるという対応は存在しません。

まずは、PJを代表するようなストーリーの中から、
1pt, 3pt, 5pt に対応する3つを選出しましょう。
これを、その他のストーリーを見積もる際の基準とするのです。
ポイントを細かく指定する必要はなく、以降のストーリーもこの3通りに当てはめていけば十分です。

後述のベロシティを測定し、これらのポイントと照らし合わせることで、 見積もりは初めて確度を増していくのです。

プランニングポーカー

自身が思うストーリーのポイントを1,3,5で想像し、せーので出し合うことで認識の共通化を図ります。
このとき数値が一致しないなら、それは認識に差があるという事で、今後起こりうる齟齬の発見につながります。
認識を共有して、最終的なポイントを決定しましょう。
正解探しではなく、認識を合わせる目的であることは念頭におきましょう。

まとめ

アジャイル開発における準備段階の内容をまとめました。

総じて、 「メンバーの認識を統一する」 「顧客にメンバーとして参画してもらう」 「期待をマネジメントする」 ということが強調されていたように思います。
アジャイルかどうかに関わらず、どういった場面でも大事な事ですね。

次回は、開発が始まった段階の内容をまとめていきます。