RADICODE BLOG 
◀︎其の1はこちら
◀︎其の2はこちら
◀︎其の3はこちら
◀︎其の4はこちら
◀︎其の5はこちら
◀︎其の6はこちら
◀︎其の7はこちら
◀︎其の8はこちら
◀︎其の9はこちら
◀︎其の10はこちら
◀︎其の11はこちら
◀︎其の12はこちら
こんにちは！
ラジコード編集部です 😊
アジャイルサムライを読む連載記事その5です！😃
前回は第2部 アジャイルな方向づけ の「第4章：全体像を捉える」で、プロジェクトの背後にある「なぜ」を明確にするインセプションデッキの前半の内容について学習できました。
その5は「第5章 具現化させる」を読んでいきます。
それではよろしくお願いします！🙋♂️
本シリーズは「アジャイルサムライ − 達人開発者への道」を1〜5部を1~2記事に分け要点を解説していくシリーズです。全13記事を予定しています。
もくじ
第5章：具現化させる
4章でプロジェクトの「なぜ」が明確になり、理解を深めることができました。
「インセプションデッキ」の課題一覧の後半5つで、具体的な解決案とプロジェクトの陣地を決める方法がわかります。
- 技術的な解決案を描く
- リスクを検討する
- プロジェクトの期間を見極める
- 諦めるべきものをはっきりさせる
- プロジェクトに何がどれだけ必要なのかをスポンサーに提示する
まずは現実的な解決案を示すところから始めます。
アーキテクチャ（構造）の図を描き、開発チームで「もし〜だったらどうなる？」というシナリオを検討しましょう。
同時にオープンソースやフレームワークの採用も検討しておきましょう。
下記3つを決めてどんなシステムの構築を考えているか図で伝えましょう。
- どこにリスクがあるか明確にする
- 対立点やトレードオフのバランスをうまく保てる
- 自分たちで考える権利を与えられるため、優れた解決法を生み出せる
次の条件にどれか1つでも当てはまる場合は必ず、いずれ向き合うことになるプロジェクトのリスクについてチームで考えてみましょう。
- チームが同じ仕事場にいない
- 顧客を巻き込めない
- 自分の開発環境をコントロールできない
- その他、プロジェクトを成功させるために必要だと思うものが揃っていない
プロジェクトのリスクについて早め話し合う利点は以下があります。
- プロジェクトの課題を早い段階であきらかにできる
- 違和感を表明するチャンス
- 不安を分かち合うことで気持ちがすっきりする
この段階での見積もりは大雑把な予測に過ぎませんが、いつ頃なら納品できそうかを伝えないといけません。
こういったときの見積もりは「小さく考える」ことが大事です。
小さく考える
小さく考えるとは「制御できる単位へと分割する」ということです。
ログイン機能を作りたいという要望がある場合、「セキュリティを向上させるために2段階認証を入れたい」「パスワードを忘れたときのフローを追加したい」「ソーシャルログインを取り入れたい。5種類ぐらい対応してほしい」など。
ゴールが定まっていないとこういったやり取りが続き、期間を見積もるのが難しくなる。
まずは、ID・パスワード入力のシンプルな状態からスタートし、機能追加は段階を踏んで対応していくと、見積もりの精度を上げて確実に開発を進めることができます。
プロジェクトの長さへの期待をマネジメントする
自分たちの見積もりを踏まえてステークホルダーに向けて提案するときの選択肢は2つです。
1つは期日を軸にそこに収まるように開発を調整していく作戦。
2つ目は中核をなす機能を届けることを約束し、期日については幅を調整する作戦です。
アジャイル では、時間・予算・品質は固定されたものとみなしスコープを柔軟に扱います。
やるべきことが多すぎるとき、やることを減らす。計画が現実にそぐわない場合は計画を変えて対応していきます。
- スコープは諦めてもらう場合があることに納得してもらう
- どれも最優先はできない
- 同じ目盛りの項目はあってはいけない
トレードオフスライダーを使って、顧客と一緒にスコープ・時間・予算・品質の項目の優先度を決めていきましょう。
機能開発なら、まずは動くところから。使いやすさの向上は後からでも行えます。
優先度が低い項目は大切に考えていないわけではないことは、きちんと伝えていきましょう。
プロジェクトのことが大体わかった段階で、そろそろ期間や費用がどれぐらいかかるか考えてもいい段階です。
まずはどんなチームが必要かをまとめます。
君の「Aチーム」を編成する
与えられたミッションをやり遂げためのベストチームを説明しよう。
- UXデザイナー
- プロジェクトマネージャー
- 開発者
- アナリスト
- 顧客
- テスター
クライアントに説明するときに「顧客」の部分は時間をとって説明してもいい。
それはこの役割が極めて重要だからです。そしてほとんどの企業は「顧客」の役割が文化として根づいていないためです。
アジャイル において「顧客」の役割は非常に重要です。
「開発チームからの質問を受ける時間を確保できるのか」
「定期的（週１など）のミーティングはできるのか」
「プロジェクトの方向性・決定を下せるのか」
「顧客」の役割が初耳という人もいるため、しっかり説明しましょう。
最終判断を下すのは誰か？
開発チームの向かう先・優先度・次にやるべきことを伝えるステークホルダーは1人にしておきたい。
誰が本当の最終決定権を持っているのか？チームや他のステークホルダーにはっきり示すことが大事です。
コストがどれぐらいかを見積もる
プロジェクト予算の概算を出さないといけない場合、チームメンバーの人数にプロジェクト期間中の時間あたりのコストを掛ければいい。
他に必要なソフトウェア・サービスの費用も積んで提出しましょう。
最後のスライドを仕上げる
- いつ完了するのか？
- いくらかかるのか？
これらはステークホルダーがとても欲しがる情報ですが、期日・開発チームのスピード・金額などの様々な情報は、この時点では100％の約束はできません。
インセプションデッキを通して様々な疑問に向き合ってきましたが、今の段階では分からないことが多すぎます。
このセクション冒頭「最初のリリース」の見せ方で想像力をはたらかせよう。
「複数のプロジェクトが連なる・大規模なプロジェクトになる場合はどうすればよいか？」
「自分だったらどんな提案を見たい？」
「投入する資金が自分のお金だとしたら？」
「責任者だったら？プロジェクトを実施する立場だとしたら？」
以上「第2部アジャイルな方向付け：第5章 具現化させる」は、その3で説明した「インセプションデッキ」の後半の解説でした。
開発チーム、スポンサーや顧客全員がプロジェクトの全体像と話の流れを共有することができました。
次回は「第3部：アジャイルな計画づくり」を読んでいきましょう😌
- アジャイル宣言の背後にある原則
- アジャイルソフトウェア開発宣言
- アジャイルサムライ − 達人開発者への道
オーム社 (2011/7/16)
著者：Jonathan Rasmusson 著／西村直人・角谷信太郎 監訳／近藤修平・角掛拓未 訳
月額固定・定額制でアジャイル開発を提供する「サブスクエンジニア」サービスを提供しています。よろしければご覧ください！
