60%の状態でいいから、進捗を頻繁に投げることが大事
前人未到で未知なものを作る。そのためにとる戦略はなにか？たくさんの可能性を考え、たくさんの可能性を試し、よいものを残し、ダメなものを潰すほかない。試行錯誤の回数と精度を爆アゲするほかない。
過去に作ったPDCA爆まわしゲーム
という前提に立つと、90%の状態で進捗報告するのは遅すぎるというより致命的だ。 60%で提出し、サクッと修正して正しい方向に持っていくのが正解だ。
60%のものを複数並べて比較させると、おもしろいものが浮かび上がる
1つの90%のものよりも、5つの60%を並べたほうが、よりおもしろさの比較がしやすくなり、よいことも悪いことも浮かび上がってくる。悩むことがあれば、いくらかパターンを入れ込むのもいいだろう。
ダメなことがわかったら、すぐさま伝える
「『3日でできます！』って言ったのに、ぜんぜんできてない…。どうしよう…」
やってるうちにダメだとわかることなんていくらでもある。だからこそ、ダメな状況を通り越して絶望的な状況になる前に、さっさと伝えよう。ダメなものは仕方がない。
チームのメンバーがが助け舟を出してくれるはずだ。
具体的な報告のやりかた
動画キャプチャを撮ってSlackに上げまくる
- 動画はできれば編集したほうがやさしい。が、編集しなくてもなんらかの説明があれば大丈夫。
- 動画はクラウド等にもまとめておく。プロジェクトの振り返りのときに見返して反省に活かす。
- 俺のCaptureフォルダ。いっぱい録画してる。
- 俺のCaptureフォルダ。いっぱい録画してる。
試したものの正確な前提条件を伝える
- 条件が異なるものを無言で見せられても、何が違うのか、何を注意して見ればよいのかがわからなくなるので、正しく伝える。
- 例: 「センサーの反応をよくするために、前回と比べて、ここと、ここをいじりました」
作業に対する自分の思いや、障害になったことなどを伝える
- それまでの作業において、何らかの試行錯誤を経てるはずなので、そのプロセスも報告する
- 例: 「本来ならこうしたかったが、このような障害やトレードオフが確認され、このような妥協点にたどり着きました」
- 自分が何を思ってその機能やアイデアを盛り込んだのか？というマインドも報告する
- 自分の判断を伝えずに「アップデートしたので、キャプチャを見て確認してください」だけでは伝わらないどころか、説明をしてくれないめんどくさいヤツと認定されてしまうので注意。
事実を伝える
自分の意見と事実は異なる。 ここ、めちゃくちゃ大事。俺も指摘された経験がある。質問されたときは、事実を聞かれてるのか、意見を求められているのかを察知しよう。
めちゃくちゃ参考になる記事↓
また、事実を並べると、他人に判断してもらいやすくなるというハックもある。先にも述べたが、何かを並べて比較すると判断がしやすくなるものなのだ。
報告の頻度: 作っているものの方向性が見えた段階で報告する
頻度としては毎日でもいい。なんらかの判断を下して作っているはずなので、作ったものの方向性が見えた段階で報告するのがいいだろう。
「時間がかかりそう」「やっぱり技術的に無理がありました」というネガティブなこともすぐに報告するのがよいだろう。
まとめ
- 正しく事実を報告し、材料をならべる
- 他人に判断を委ねるものは委ねる
- 自分で入れ込みたいアイデアはプッシュする
- ダメなものもさっさと伝える
結果、作るものの方向性がすぐに見えたり、解決に近づけるだろう。
スピーディにイテレーションをまわしまくって正解に辿りつこう。