モチベーション
- 日々、未加工の生肉のような課題っぽいものが飛んでくる
- 課題っぽいものの中で、今の状態で実施すべき打ち手を把握したい
- 課題をうまく整理・仕分けし、上記を実施していきたい
課題の図
そもそも課題とは何でしょうか。本書は課題を理想と現状のギャップと捉えます。 裏を返せば、理想がなければ課題もありません。つまり課題がない、という現象が起こってしまう原因の一つは「理想がない」からです。 ~馬田隆明 未来を実装する P.143~
- 馬場隆明さんの「未来を実装する」という書籍では課題を上記のように定義している
- 僕はこれに加えてもう一つ「知識」が重要な要素だと思っている
- 理想があっても、知識がなければ課題に形を与えられない
- 知識は、文献から得られるものだけでなく、自分たちのチームが実験、検証によって得た体験的な知識も含める
- 形が与えられない課題は、適切な認識がされずに解決されない
- 漠然とした不安をチームに与えるだけである
- 様々な知識をもとに、課題を解決可能な状態に落とし込むための順番を整理したい
- 理想 / 現状 / 課題の図は、個人、チーム、組織と、スケールは違えども大枠や対応方針はだいたい一緒である
課題の種類整理
既知の既知がある。我々が知っているものがあり、そのことを我々が知っていることだ。 既知の未知がある。我々が知らないものがあり、そのことを我々が知っていることだ。 それから、未知の未知がある。我々が知らないものがあり、そのことについても我々が知らないことだ。 ~ アリステアクロール Lean Analytics P.13~
- 理想 / 目標 があれば課題が生まれる
- 僕は、課題を上記のフォーマットで整理する
- 既知の既知は、実行あるのみである
- 既知の未知は、調査 / 学習 / 検証をして、既知の既知にする
- 未知の未知は、課題分析 / 調査 / 仮説検証を行い、既知の未知にする
- 未知の既知は、標準化 / マニュアル化を行い、既知の既知にする
- 今見えている課題は、上記のどこに分類される課題なのかを整理する
- 課題を対処する上で最も重要なのは、いかに迅速に「既知の既知」まで課題を落とし込むか
課題整理 (詳細)
| why | what | how | 状況例 | 実施内容 |
|---|---|---|---|---|
| ○ | ○ | ○ | why what how が分かったので、あとはやるだけ | 実装 / 実行 |
| ○ | ○ | △ | 開発効率を向上させるために、デプロイ頻度を増加させたい。要素技術は分かったが、我々のプロダクトにマッチするか分からない | 検証 |
| ○ | ○ | ✗ | 開発効率を向上させるために、デプロイ頻度を増加させたい。そのための要素技術が分からない | 技術調査 / 技術書の読書会 / 技術的な研修 |
| ○ | △ | ✗ | 開発効率を向上させるために、デプロイ頻度を増加させれば良さそうだが確証がない | 課題仮説の検証 |
| ○ | ✗ | ✗ | 開発効率を向上させるために、何をすれば良いか分からない | 調査 / 課題分析 / 仮説立案 |
- 課題の状況と、それに対する打ち手を整理したものを上の表に示す
- 上の図においては、「開発効率を向上させる」というミッションを持った開発チームを例にした
- チームに落とすのであれば、もう２〜３段階解像度を上げたほうが良い
- 例えば 「LeanとDevOpsの科学」にあるハイパフォーマーを目指すなど
- ここで大切なのは、 課題に対する打ち手は、一足飛びにしないこと
- 何をすれば良いかも分からないのに、技術調査をしても意味がない
- 意味があったとしても非効率
- 目をつぶってバットを振るようなもの
- 検証もしていないのに、本実装に入るのはリスクが高い
- チームで課題に向き合うときは、今見えている課題はどこのフェーズにあるのかを整理することが重要である
- そして フェーズごとに適切なゴール設計と対処 が必要である
- チームにて責任を持つ人の仕事は、下記の通り
- 着手可能な課題を提供すること
- そもそもWHYが固まっていないのに、実行部隊にタスクを投げない
- 課題の詳細を適切にチームに伝えること
- 課題の終了条件をチームに伝えること
- チームが一足飛びに課題を解決しようとしたら、会話して気づいて貰うこと
- 知識の不足により課題を適切に把握できていない場合は、教育の機会を設けること
- 着手可能な課題を提供すること
最後に
- 課題の解像度を高めるために、取れるアクションの回数には限りがある
- なんでもかんでも 「やってみなきゃ分からない 」 は許されない
- 「作ってみてユーザーに当てる」は制限回数が存在するビジネスがある
- 未完成のものを当てすぎると顧客との信頼関係を失いうる
- 開発チームの練度、実績、顧客との信頼関係、プロジェクトの期間、競合の状況などにより実際に作れる回数は自ずと決まってくる
- 庵野監督も、実績がなければあれだけ延期することはできない
- 自分たちの中で判断する分には、どれだけ雑でも良いだろうし、何度でもやれば良い
- その限られた回数をどのように使うか、真剣に向き合うことが重要
