副業案件の初動を YWT 法で振り返ってみる

先日知り合い経由でサイト制作のお仕事をいただきました。

案件自体は要件定義の途中くらいで諸事情でナシになってしまったのですが、こういったフリーランスや副業での初動の立ち回りくらいはなんとなく理解できたので、KPT を使って振り返っていこうと思います。

おさらい: YWT とは？

始めは KPT(Keep, Problem, Try)で振り返ろうと思っていたのですが、『YWT』というフレームワークもあるようです。 今回は「やったこと」を明確にしておきたいので、YWT でやってみようと思います。

一方 YWT は「やったこと」「わかったこと」「つぎやること」の 3 つの質問に答えて、アクションを決めるフレームワークです。KPT の「Try」と YWT の「つぎやること」は同じニュアンスで、ほかの二つの質問が違うということはすぐに理解いただけるかと思います。 https://qiita.com/viva_tweet_x/items/bab769c190508c4808be#kpt%E3%81%AE%E5%88%A9%E7%82%B9%E3%81%A8ywt%E3%81%AE%E7%89%B9%E6%80%A7

やったこと

時系列順です。

  • 口頭で案件を受ける
  • 初回打ち合わせの日程調整、ZOOM のスケジュール作成
  • 依頼者にヒアリングシートを事前に埋めてもらうように伝える
  • ある程度の技術選定
  • ざっくり見積もり作成（松竹梅の 3 プランを提案）
  • 初回打ち合わせ
    • アイスブレイク
    • 自己紹介
    • ヒアリングシートに沿って作りたいものの外枠を掴む
    • 松竹梅プランのどれで進めるか決める
    • 今後の動きを整理
      • 依頼者には画面のラフスケッチを作ってもらうように伝える

わかったこと

口頭で案件を受ける

  • 後続の技術選定ステップのために案件の概要を正確に聞き出すべきだった。
  • 具体的なスケジュールや予算は詰めすぎない方が良いと感じた。
    • この段階では判断材料が足りなすぎるため。

初回打ち合わせの日程調整、ZOOM のミーティングルーム作成

  • 日程調整と同時に ZOOM のスケジュールを作っておくと、当日慌てずに済む。

依頼者にヒアリングシートを事前に埋めてもらうように伝える

  • これは非常に良かった。打ち合わせ当日に聞くことのチェックリストとしても機能する。
  • テンプレートはそのへんで拾ってきたものを使ったが、今回の案件に合わない項目が多々あったため、自分で作ったほうが良さそうだった。

ある程度の技術選定

  • 結果としてはこれもやってよかった。
  • 案件の実現可否がわかったことと、実現方法を複数提案できるようになり、依頼者側に交渉の余地をもたせられた。
  • 今回 AppSheet が要件にハマりそうだったので簡単なサンプルアプリを作ってみたが、打ち合わせ当日に依頼者にでもを見せつつ「AppSheet ができること・できないこと」を共有できた。

ざっくり見積もり作成（松竹梅の 3 プランを提案）

  • これも相手の予算・納期・品質に対する温度感がわかるので、何通りか実現方法を用意しておいてよかった。
    • 松竹梅でも Easy/Hard でもなんでもいいが、相手に交渉の余地をもたせることが大事。
  • 値付けは相場がわからなかったため非常に難しかった。

初回打ち合わせ ＞ アイスブレイク・自己紹介

  • なんだかんだ今後の関係性を築くためには大事な工程だと思った。
  • 人間が苦手なので、意識しないとすぐ本題に進めたくなってしまった。

初回打ち合わせ ＞ ヒアリングシートに沿って作りたいものの外枠を掴む

  • ヒアリングシートのおかげで聞き漏らしが少なかった。
  • 話を聞きながらメモするのが難しい。キーボードは打鍵音が響くので悪印象を与えていないか気になってしまった。

初回打ち合わせ ＞ 松竹梅プランのどれで進めるか決める

  • ヒアリング結果を受けて、意向に沿わないプランが出てくる。
    • 「こういうプランを用意してきたんですけど、今回の要件には合わなそうですね」と相手の立場になって判断することが大事。

初回打ち合わせ ＞ 今後の動きを整理

  • ラフスケッチ作成を丸投げしたのはやりすぎだったかもと反省している。
    • とはいえ依頼者にもプロダクトのことを考えてもらいたい…。

次やること

口頭で案件を受ける

  • 要求を正確に聞き出す。
  • 可能であればメモとペンでフローチャート・ラフスケッチで全容を掴む。

初回打ち合わせの日程調整、ZOOM のミーティングルーム作成

  • 継続。

依頼者にヒアリングシートを事前に埋めてもらうように伝える

  • インセプションデッキを参考に自分でテンプレートを作る。
    • 我々はなぜここにいるのか？
    • エレベーターピッチ（ここがメインになりそう）
    • やらないことリスト

ある程度の技術選定

  • 継続。
  • プロトタイプを見せれる段階まで持っていければ ◎。

ざっくり見積もり作成（松竹梅の 3 プランを提案）

  • 周りのエンジニアに相談して相場観を鍛える。

初回打ち合わせ ＞ アイスブレイク・自己紹介

  • 例えば 15 分など、アイスブレイクにかける時間の枠を設定して使い切る。

初回打ち合わせ ＞ ヒアリングシートに沿って作りたいものの外枠を掴む

  • 事前のヒアリングシートを元に、もっと話をふくらませる。
    • 具体的な使用者や使用場所など。
  • 話をふくらませた上で、やること・やらないことを決める。

初回打ち合わせ ＞ 松竹梅プランのどれで進めるか決める

  • 継続。

初回打ち合わせ ＞ 今後の動きを整理

  • 次回はヒアリング段階で一緒にフローチャートを作ってみる。
  • さらに時間が余ればラフスケッチもこの場で作って、ユーザーストーリーを集めてしまいたい。
  • 次回打ち合わせまでに予算と納期を見積もり、やる・やらないを判断してもらうだけにする。

YWT してみての所感

じっくり振り返って 1 時間半くらいかかってしまった…。 結構思考が整理できた感覚はあるので、早く次の案件で実践してみたいところですね。

YWT 自体については「わかったこと」と「次やること」を混同してしまいがち。W, T に関しては無理に時系列順に挙げていかなくても良いのかも。

『アジャイルサムライ』を読んだ

感想

アジャイル開発の具体的な進め方が章立てに沿って書かれた本。4月から本格的なアジャイルで仕事をすることになりそうなので慌てて読んだ。

「アジャイルといえばインセプションデッキ」みたいなイメージがあったけど、別に各プラクティスにこだわらなくてもいいらしい。 いちばん大事なのは顧客に毎週価値あるプロダクトを届けられることで、そのために自分にあった手段を選びましょう、ということが書かれていた。

思い返してみると今まであんまり期間が決まったプロジェクト開発ってやったことないかもしれない。そういう場合には無理にイテレーションでやらずに、カンバンでやるといいと書かれていた。もう少し真面目にTrello使ってみようかな。

ところどころスターウォーズネタ（マスター・センセイ、フォース、遥か彼方の銀河系で…など）が挟まれていて、ニヤリとしながら読み進めることが出来た。というか「Sensei」って海外でも通じるのね…

まとめ

アジャイル入門

価値ある成果を毎週届ける

  • 大きな問題は小さく、シンプルにして扱いやすくする
  • 本当に大事なことに集中する。
  • テスト済みの「動く」ソフトウェアを届ける。
  • お客さんからフィードバックをもらう。
  • 必要になれば計画を変える。現実を変えない。
  • 成果責任を果たす。

アジャイルな計画づくり

  • マスターストーリーリスト
    • プロジェクトの TODO リスト。(＝バックログとも呼ばれる)
    • 顧客が実現したいと思うフィーチャ（＝ユーザーストーリー）を載せる。
    • フィーチャに顧客自身が優先順位をつけて、開発チームが見積もることで計画が完成する
  • イテレーション
    • 開発期間のこと。
    • 1~2 週間でストーリーを動くソフトウェアに変換していく
  • ベロシティ
    • 一回のイテレーションで完了させられるストーリーの量。
    • 実測することで、自分たちのこなせる仕事量が把握できる。

チームをアジャイルにするコツ

  • 同じ仕事場で働く
  • 顧客に積極的に関わってもらう
    • デモを見て、質問に答え、開発チームにフィードバックをくれる存在
  • 人に合わせて役割分担を決める（肩書や役割を気にしない）

アジャイルな顧客とは？

  • 何を作るか決める
  • 優先順位をつける
  • スコープについて決断を下す

アジャイルな方向づけ

インセプションデッキを使って全体像を捉え、具現化させる方法。

  • なぜインセプションデッキを作るのか？

    • 自分たちのプロジェクトに対する期待を共有して、認識を合わせる
    • ステークホルダーの判断材料にする

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

  • エレベーターピッチ
  • パッケージデザイン
  • やらないことリスト
  • 「ご近所さん」を探せ
  • 解決案を描く
  • 夜も眠れない問題
  • 期間を見極める
  • 何を諦めるのか
  • 何がどれだけ必要か

全体像を捉える

インセプションデッキの前半で、プロジェクトのスコープを明確にする。

  • なぜプロジェクトをやるのかを理解している
  • よく練られたエレベーターピッチがある
  • パッケージデザインがどうなるかを知っている
  • スコープの境界が定められている
  • 「ご近所さん」と仲良くなろうとしている

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

  • お客さんの意図を掴む。
  • 必要であれば実際に自分が現場に行ってみる。

エレベーターピッチを作る

  • プロダクトを明快にする
  • チームの意識を顧客に向かわせる
  • 核心を捉える

テンプレート：

- [潜在的なニーズを満たしたり、抱えている課題を解決したり]したい
- [対象顧客]向けの
- [プロダクト名]というプロダクトは、
- [プロダクトのカテゴリ]である。
- これは、[重要な利点、対価に見合う説得力のある理由]ができ、
- [代替手段の最右翼]とは違って
- [差別化の決定的な特徴]が備わっている

パッケージデザインを作る

  • 顧客が買う理由を明確にする
  • 顧客に訴求する要素を明確にする
  • プロダクトの値打ちを明確にする

手順：

  1. プロダクトの効能（≠ フィーチャそのもの）をあげる
  2. キャッチコピーを決める
  3. パッケージをデザインする

やらないことリストを作る

  • プロジェクトのスコープを明確にする
やる：
- 検索
- 印刷

やらない：
- オフライン利用

あとで決める：
- 更新

ご近所さんを探す

  • プロジェクトに関わりそうな人を明確にする

具現化させる

インセプションデッキの後半で、具体的な解決案とプロジェクトの陣地を決める。

  • 技術的な解決案を描く
  • リスクを検討する
  • プロジェクトの期間を見極める
  • 諦めるべきものをはっきりさせる
  • プロジェクトに何がどれだけ必要なのかをスポンサーに提示する

解決案を描く

顧客の前で、チーム全員でアーキテクチャ構成図を描く。

  • ツール・技術の期待マネジメント
  • プロジェクトの境界・スコープを目で確認できる
  • リスクを伝えられる

夜も眠れなくなるような問題

プロジェクトのリスクについて腹を割って話し合う。 逆にプロジェクトの成功に何が必要なのかを納得することができる。

例：

- チームが同じ仕事場に居ない
- 顧客を巻き込めない
- 自分の開発環境をコントロールできない

期間を見極める

おおざっぱな予測でもいいから納期を決める。 なるべく短い方が良い。

- 構築　〜3ヶ月
- 受け入れテスト 〜1週間
- トレーニング 〜1週間
- リリース

何を諦めるのかをはっきりさせる（トレードオフスライダー）

プロジェクトに影響を与えるフォースをコントロールする。

  • 時間
    • 固定する
  • 予算
    • 固定する
  • 品質
    • 固定する
  • スコープ
    • 動かす！

トレードオフスライダーを使ってフォースの影響を顧客と話し合う。

// どれも最優先はNG.
// 同じメモリが2つ以上あってもNG.

MAX <-|--|--|--|--|-> MIN スコープ
MAX <-|--|--|--|--|-> MIN 予算
MAX <-|--|--|--|--|-> MIN 時間
MAX <-|--|--|--|--|-> MIN 品質
MAX <-|--|--|--|--|-> MIN その他プロジェクトの命運を左右する要素

何がどれだけ必要なのか？

プロジェクトに必要なチーム・期間・費用を説明する。

アジャイルな計画づくり

ユーザーストーリーを集める

  • 「文書化」は難しい。小さいインデックスカードに顧客の要望を書くのが丁度いい。
  • フィーチャの本質を捉えるキーワードを書き留める程度
  • 細かい要求はあとで取り組む直前で分析する
  • ユーザーストーリーは E2E になっていると良い
    • UI→ ロジック →DB までが一貫されている

例：

- ユーザーアカウントを作成する
- 新規物件が投稿されたらメーリングリストに通知される
- メーリングリストの購読を停止できる

「よく書けた」ユーザーストーリー

  • 他のストーリーに依存しておらず、独立している
  • 「松案・竹案・梅案」のように交渉の余地がある
  • テストできる
期限切れアカウントでのログイン

- 通常のログインができる
- 期限切れログインはリダイレクトされる
- 適切なエラーメッセージを表示する
  • 見積もれる程度の大きさである

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

  • 顧客と一緒になって、なるべくたくさんのフィーチャを集める。
  • 全てを実装するわけではなく、なるべく多くを議論の机上に乗せるため。

手順：

  1. 大きくて見通しの良い部屋を用意する
  2. 図をたくさん書く。
    1. ペルソナ
    2. フローチャート
    3. プロトタイプ…などなど
  3. 図を辿りなからユーザーストーリーを抽出する
  4. 漏れ・ダブリを排除してリストを磨き上げる

見積もる

プロジェクトの概算見積もりは 100%当たらない。 アジャイルでは「何がどれくらいかかったか」を計測して、それをもとに計画を立てる。

  • 相対サイズで見積もる

    • ストーリーを互いが互いに対してどれくらいの大きさなのか見積もる。
      • 「おもちゃを作る」は「おもちゃを修理する」の 2 倍くらい
    • 実際にプロジェクトを始めてベロシティを計測する。

  • ポイントで見積もる

    • 相対見積もりの単位を扱いやすくする。
      • 1 日、3 日　 → 　 1pt, 3pt

見積もり手法

  • 三角測量

    • プロジェクトの代表的なストーリーを大中小それぞれ選出する
    • 残りのストーリーを基準ストーリーとの相対サイズで見積もり、振り分ける

  • プランニングポーカー

    • ストーリーそれぞれをメンバー全員で同時に見積もる。
      • 「いっせーの」で 1,3,5 のポイントを同時に出す
    • 議論を重ねて、再度見積もる

現実と向き合う

初回の計画づくり

  • ① マスターストーリーリストを作る
    • フィーチャの一覧を載せる
    • 顧客が優先順位をつける
    • 開発チームが見積もる
    • 「リリース」の単位にまとめる
      • ※1〜6 ヶ月でこなせる量に収めておくこと
# マスターストーリーリスト
- 1pt ユーザーを追加する
- 2pt 旅程を印刷する
- 5pt 予定をキャンセルする
…

## リリース1
- ユーザーを追加する
- 旅程を印刷する

## リリース2
- 予定をキャンセルする
  • ② プロジェクト規模を見極める
    • 三角測量・プランニングポーカーをもとにプロジェクトがいつ終わるかを見極める
  • ③ ベロシティを見積もる
  • ④ 期日を仮決めする
    • 期日固定：優先順位の劣るスコープを諦める
    • フィーチャセット固定：期日を諦める

バーンダウンチャート

チームがどれくらいの速度でストーリーを実装しているかがわかる図

f:id:kterui9019:20210312134057j:plain
アジャイルサムライ P166より

アジャイルなプロジェクト運営

イテレーション

1〜2 週間の間に分析・開発・テストを行いストーリーをソフトウェアに変換する。

Step1 分析と設計をする

  • 「必要な分を、必要なときに」分析する。
    • 同じ場所で働いているならインデックスカードと会話で事足りることもある。
    • もう少し大きな規模なら、概要をまとめた文章・ストーリーをタスクに分解したリスト・テスト条件の一覧などがあればよい。
    • イテレーション(n)で分析して、イテレーション(n+1)で開発する

f:id:kterui9019:20210312134153j:plain
アジャイルサムライ P188より

  • 複雑なストーリーなら、それ相応に時間にかけるしか無い。
    • フローチャートを書いて、システムの動作・必要な手順を示す
    • ペルソナを作り、どんな人達がどうやって使うかを示す
    • ペーパープロトタイプで色々なデザインを試す
    • 受け入れテストを書く
      • インデックスカードの裏に「このストーリーが完成したことを確認できそうなこと」を3 つ書こう

Step2. 開発する

Step3. 作業の結果を確認する

  • お客さんにデモをしながら、ストーリーの受け入れテスト条件を一つづつチェックする

カンバン

  • 運用業務など、プロジェクトの期間が決まっていない場合に使える
    • イテレーションが必要ない。
    • 手が空いたら優先順位の高い作業に着手するだけ
  • チームが同時に着手できる作業数（WIP）を定める。
  • メリット
    • 差し込みの業務に割り込まれずに済む
    • 1 回のイテレーションに収まらない仕事にそのまま取り組める
    • 期待マネジメントしやすい（一度にやれる仕事は WIP 数まで、と割り切れる）

イテレーションでの意思疎通

イテレーションごとにやるべきミーティング

ストーリー計画ミーティング

ジャストインタイム分析の結果を確認するミーティング。

  • これから取り組むストーリーの準備が整っていることを全員で確かめる
  • 顧客と一緒に受け入れテスト条件をレビューする
  • 開発チームが見積もりの数値を確認する
  • その他必要な調査に漏れがないことを確認する

ショーケース

イテレーション後に顧客に実装したストーリーをデモで見せ、フィードバックを得る。

イテレーション計画ミーティング

次回のイテレーションの作業を計画する。

  • チームのベロシティを確認する
  • 次に取り掛かるストーリーを整理する
  • 次回のイテレーションでチームがコミットメントする作業量を見極める
  • バーンダウンチャートでプロジェクトの進捗具合を確認する

ミニ振り返り

10~15 分で「うまくやれたこと」「どうすればもっとうまくやれるか」を話し合う。

デイリースタンドアップ

毎日立って自分のやることをほかのチームメンバーと調整する

  • 昨日やったこと
  • 今日やること
  • チームの開発速度を下げてしまうことがあれば言う

アジャイルなプログラミング