思考と試行のフィードバックループ
これまで何度か失敗のことについて書いてきた。ページの下にある検索窓で『失敗』と入れて検索すれば過去のエントリが出てくる。どれほど失敗好きなのかとも思わなくもないが、人生なんて期待していたような結果になるより、期待していなかったことの方ばかりだ。人生の面白いところは、期待していなかった結果は全てマイナスの結果ばかりではなく、プラスになることも稀にある所だ。
仕事では、失敗はした方がいいということをこれまで何度か書いてきた。それも小さな失敗をして、失敗したやり方を学び、残った選択肢から成功に辿り着こう、と述べてきた。仕事だから失敗をして評価を下げたくないとか、昇進の機会を失いたくないとか、思うかもしれない。それについては誰も否定しないだろうし、結果を選べるなら誰だって成功する方を選ぶだろう。
でも、やっぱり失敗する。これは避けられない。初めてやってみる仕事は失敗の連続でしかない。システムを導入する前には、要件を整理し、運用に機能を適用して実務を設計する。このとき、要件の整理が甘かったり、ボヤケテいると運用自体が間抜けな設計になるし、現実的でない運用を設計すれば使われないシステムが居座るだけである。
そんな失敗にしないために、要件をちゃんとやれとか、運用を設計しろとか言っても正論すぎて、そうですねという感想というか馬耳東風にあしらわれるのが精一杯で、何も産まない。エンジニアであれば誰もがコンサルや第三者から正論ばかり指摘されてうんざりするという経験していると思うが、正論や正義はなんら解決策を産まない。
我々の欲しいものは、価値のある現実解である。その現実解は、労働集約的な要件から思考と試行を必要とする誰も答えを知らない要件に移ってしまった。それにどうアプローチするか、であるがそうした考えは別の人に任せるとして、思考と試行を必要とする要件の現実解を手に入れるためには、次のように取り組むと、試行から思考にフィードバックできるようになり、次に繋げられるので良い。
- 要件は小さくする
- 最小少人数でやる
- 先に、思考する時間枠を決める
- 思考してローンチできるまでを固まった時間でやりきる
要件を小さくするのは小さく失敗をするためである。
最小人数でやるのは、長々と議論をしないとか、意思決定を遅らせないためである。
先に、思考する時間枠を決めるのは、リソースを確保するためである。
ローンチできるまで固った時間でやりきるのは、細切れで断続的に作業をして、失敗がわかるまでの時間を伸ばさないためである。
この他にも、思考するときは紙に描いておしまいにすることも大事だ。清書なんていらない。記録が欲しければスマホで写真を撮って、slackに貼っておけば良い。でも、大事なのは描き残した紙だが、思考の結果があれば、そのまま試行に移れる。間に試作をするのであれば、紙をみて作れば良い。