"結論から逆算して必要なタスクを洗い出せ"

これまで上司や周りの同僚から言われ続けてきたことです。

具体的なユースケースを考えてみます。

1つ目はSoftware開発の場合です。

何らかのCodingを伴う開発作業を行う際は、先ずTest Code(結論を検証するためのもの)を書きます。

Testは必ずNGになります。機能のCodeは実装していないため。

次に機能のCodeを実装してTestがOKになるまで修正を重ねます。

OKになったらCodeのメンテナンス性を高めるために構造化(リファクタリング)します。

個々の機能のCodeから実装するのではなくTest Codeから実装しているため結論から考えていると言えますね。

2つ目はコンサルタントの課題解決提案の場です。

IR情報やOECDが公開している情報を元に調査を行い、"根本的な課題はこうでこうすると解決になるのでは"(結論)といった仮説を立てます。

立てた仮説をプロジェクトチーム内の複数のメンバーと議論したらクライアント向けの提案書にまとめます。

提案書には"いつまでにどんなアウトプットを出すのでxx万円になります"といった内容を記載します。

クライアントの合意を得ることができたら詳細な調査作業に開始です。

詳細な調査を行う前に外部情報を元に結論を考えていますね。

3つ目は営業の場です。

来四半期の売上と利益目標のノルマは来四半期の2ヶ月目までに達成する(結論)と上司に宣言します。

来四半期開始まであと1ヶ月あるとしたらその時間を使って現在のPipelineを精査します。

見込み顧客の課題が明確で意思決定者が課題を認めている

いつまでに実証実験を終わらせて実証実験が成功したら月額xx万円の発注をxxまでに行う

これらを書面で合意できている案件が何件あるか確認して合計すると来四半期のノルマをクリアできるかチェックします。

ノルマをクリアできない場合はPipelineを見直しします。

そもそも見込み顧客の課題を理解していないのにPipelineに入っている場合は課題を理解するように努めます。

当四半期の前にノルマ達成を宣言しているので結論から考えていますね。

ウソでも何でも良いので結論を立ててからその結論を検証するほうが無駄なことに時間を割かなくて良いですよね。

結論が大ウソだったら軌道修正してウソの度合いを下げれば良いかと。