効果的に学びを得るためには、一連のワークフロー全体をひとまとまりで捉えることが大切だと最近気づいた。
一つずつの工程を順番に進んでいくより、全体を通して何週もした方が良いことが結構ある。
プログラミング学習なら、
最初から１つずつの技術をしっかり学習して理解度や実装のクオリティを上げて行くよりも、とりあえず１回本当にダサい状態のサイトやアプリを作成して、ネット上に公開するまでを体験した方がいいと思う。
プロダクト開発なら、アイデアを出して開発するよりも、その後ローンチしてセールスすることの方が、難しいと思う。
なので、早い段階でその一連の流れを行うことが大切。
じゃないとローンチとセールスができなくて詰む。
結局のところ、人の見積もりなんてものは、当てにならないということなんだと思う。
実際にステップ１に取り組む中で、当初想定していなかったような問題が次々と出てくる。
それはステップ２でも、それ以降もずっと繰り返される。
つまり、最初に予定を立てたり、見積もったりすることはたいして意味がないんだと思う。
その上、現実のあらゆる物事のワークフローというのは、すでにある程度最適化されているんだ。
最適化されているということは、効率の良いということだ。
ほとんどの場合、ステップ１での取り組みは、それ以降のステップに繋がるように設計されている。
それ以降のステップを有利に進めるために、あるいは先を見越しておかないと余計な問題が発生してしまう可能性があるから、ステップ１で「タスクA」を行うことが推奨されているんだ。
でもそれって、結局最初から最後まで、一連のワークフロー全体を知っている人の視点なわけです。
そういう人のアドバイスは、大抵正しいし、本当に役に立つものだと思う。
「先人の知恵」とか、
「巨人の肩に立つ」という言葉があるくらいだから。
でもそのアドバイス、あるいは、先を見越してステップ１で推奨される「タスクA」の意味というのは、段階的に進んでいる最中に理解できないということなんだ。
ゆっくり順番に、丁寧に進めば進むほど、一連のワークフロー全体をひとまとまりで見るという作業が先になる。
その作業が、多くの発見やアイデアを生み、次回以降の最適化に繋がるんだ。
ステップ１で取り組んでいることを理解して、「上手くやる」には、一連のワークフロー全体の視点が必要になる。
これに関しては、『The Need to Read（読む必要性）』というエッセーにも重なる。
ここに書かれているように、人は
読むことで、同時に書くことを学んでいる。
書くことで、同時にアイデアを得ているんだ。
それらは、インプット、アウトプット、ひらめきというそれぞれ独立したプロセスではないということ。
それぞれ依存しているから、周回で強化していくアプローチが有効になる。
もし、プログラミング学習をしているなら、早いうちに作成しているサイトやアプリをネット上に公開する必要がある。
本当にダサい状態でいいから、１回体験する必要がある。
もし、スタートアップ、プロダクト開発をしているなら、早いうちにマーケットに入って行く必要がある。
それはつまり、ターゲットとなる人にたいして、適切なチャネルでMVPをローンチし、セールスする必要があるんだ。
それはアイデアの段階でも。まだ製品がない段階でも行うべきなんだ。
そして、人力でできる限りの価値を提供してみる必要がある。
その中で、たくさんユーザーと話す必要がある。
それが
「アイデア出しから、製品の構築、ローンチ、セールス、価値提供、カスタマーサクセス（カスタマーサポート）」
までの製品提供の一連のワークフローだからだ。
直感に反することが多いが、段階的に進むことは、本当に危険だと最近学んだ。
特に時間やお金など、リソースが限られている状態では、速度が重要になる。
なので、なおさら効果的に学びを得るために、最も早く成長することに焦点を当てたルートで目的地を目指さないといけない。
それには、一連のワークフロー全体をひとまとまりで捉える視点が不可欠なんだ。
