失敗して何かを覚えるよりも、最初からうまく行ったほうがいいと思う
タイトルに言いたいこと書いた。
知らないことをやるときのアプローチ
今日、自分のチームの隣の人が（ECサイトの開発してる）「初めて決済周りの改修案件に関わる」ということで新しくこの決済サービスの連携についての見積もりをしていた。 決済周りはチーム内で知ってる人が限られてるので、多くの人が携わったほうがいいよね、ということで新たにやってみよう、という感じでその人にタスクを割り振られた。
とりあえず、そのサービスの資料を読んで何をやればいいのか考える、ということをしていて、決済の辺りを分かる人は最初は説明せずに「まずは自分でやってみて。分からないことあった聞いて」くらいのスタンスでいる感じだった。 １日くらい見てから、分かる人に聞いたら、気にしなくていい箇所を見ていたらしくちょっと観点が違う感じ、という話をしていた。
「分かる人」は、聞かれたら答えよう、と思っていてとりあえずはやってみたら、というつもりだったと言っていたけど、自分も決済周りはやってないので、モヤっとは感覚分かるかもしれないけど時間が無限にあるわけでもないので、もし自分だったら１時間程度資料見たらあとは聞きながら進めると思う。「わからないなりにやってみる」というのは当然ゴールへの最短経路ではない。
最初は失敗してもいいんじゃないの？という考え方
おそらく、タスクを依頼したり有識者として「聞かれるまで答えない」というスタンスは、
「最初はみんなうまく行かない。失敗して覚えるのがいい」
みたいなイメージがあるのかな、と思う。
もちろん、本番にリリースしてから問題起きた、という失敗ではなくて、わからないなりにやってみて聞いた時に間違えを指摘される、という程度。
これは自分の考え方ではマズイ方法だと思っている。
仕事で求められること、求めること
仕事していて、「仕事のやり方自体を模索して覚える」という必要があればこれは別にいいかもしれない。
他に事例が無いことをやるときとか、人に頼ることができない状況では自分で仕事を進める方法を考える必要があるので、失敗して模索する、ということ自体を覚える必要があるかもしれない。
ただ、今回のような「チームで開発をしている」場合には、得手不得手があってフォローし合えばいい、というのが前提になるのと（社員じゃないのでOJT的なスタンスが不要なのもあるけど）、仕事の内容自体を覚えるだけでいいはず、というケースになると思う。
新入社員を教育するなら、うまく行かない感じを体験させる必要もあるかもしれないけど、すでに１年とかいる外注の人にそういうの必要だとは思わない。
今回のようなケースでは、覚えるべきは「決済周りの開発方法」であって、「知らないことをやるときにどういう仕事の仕方をすればいいか」では無いだろう、ということ。
これがWebアプリケーション開発なら
老害っぽい感じで、WebアプリFWとか使わずに新人は最初はFWを使わずに（例えばPHPなら）「素のPHP」を使ってアプリを作るべき、という発言に該当すると思う。
そうすると、ロギングとかMVCがどうの、ORM、セッション管理が・・・、とかを覚える必要があるので全部理解してからWebアプリケーションを作ることになるよね、という話。
分かりやすい話で、この辺りは知識として持っておいたほうがいいけど、自分で作る必要とか無いでしょ、というのが世の中の総意だと思ってるけど、こういうレイヤーは現在は「インフラ」というか前提として付き合えばよくて、もっと別のレイヤーにリソースを割くべき、という話だと思う。
動くまでにやること、というのは先人たちが頑張ってくれたので、素直にRailsとか使っておいてもっとUI/UXやら開発のスピードをどうにか、とかにフォーカスすればいいと思う。
少し戻る
今回の話で言うと、改修方法は知ってる人にサラッと教えてもらって、「次回に同様の話があった時にスムーズにできれば良い」とかが実現できれば、「改修方法を覚えた」ということになってそれで十分だと思う。
今回の場合は、早く終わって他にやることたくさんあるよね、となればいいので早く終わることはいいことでしかない。
最短で「うまくいく」ということを体感する意義
言いたいことは、「失敗しないほうがいい」というよりも「すぐにうまく行くべき」という点で、うまく行くことをクセづけすることが必要だ、という点。 失敗がクセになるよりはいいのは分かると思うけど、問題は「失敗」まで到達してしまった時に覚えている範囲で「成功」することができるかどうか？
スポーツの例
例えばテニスでボールを打つとき、難しい（失敗しやすい）状況でたくさん打って崩れたフォームが多くなるよりも、簡単なボールをたくさん打って良いフォームでクセをつける方がいい（と思ってる）。 良いフォームで体が覚えると、難しい状況で体制が多少崩れてもクセになっているキレイなフォームで打とうとするため、体がある程度は補正できる（はず）。 崩れたフォームだと力の入り方に無理が出たり、一定のレベルまで行くと上達が止まったりする。 （元テニススクールコーチ談：自分）
子どものトイレの例
子どものトイレは、おしっこがトイレでできる、というのを繰り返さないといつまでもオムツが取れない。 ・・・割愛。
プログラミング／設計の例
プログラム書いていても、うまく切りだされていない千行あるメソッドがあったとして、新人が誰かの手本無しでキレイに分割できるだろうか。良いサンプルをみてポイントを理解したらできるかもしれないけど、良い感じの実装／設計を見ないとそもそも何がいいのかがわからない。
試行錯誤して自分の作ったものを見直していくのには、何年か（or アプリが４つ以上とか）かかると思うが、手本を元に最初からうまく行く状況を作ると何年か分を先に進めることになる。
まあ、アンチパターンを知ることも大事だけど、自分のコードである必要はない。
仕事の仕方の例
たとえば タスクとかプロジェクト という単位だとして、失敗したあとでそのフィードバックを元にリカバリしてうまく行くように、というのを試すタイミングはあるのだろうか？
タスクの粒度にもよるけど、大抵は似たようなケースには出会わないと思う。
自社サービスをやっている会社でも、粒度が大きいとサービス作って失敗して潰してPJが赤字になって次の予算が・・・、とかになりそう。それでも次をやる体力があればいいのかもしれない。 （だとしても、全員が「自分が体験する」のでないと覚えないのだと色々足りない）
貴重な機会を失敗で終わるよりは、誰もが通るようなポイントは事例だけ聞いて教えてもらってクリアしてしまって、一番難しい・注力したいところにリソースを割けばいいと思う。
要はフィードバックループ（？）の問題
失敗する余地がない、という訳ではなくて、要は与えられた期間の間に「うまくいって終わる」ことができれば良くて、１ヶ月のタスクなら１週間でフィードバックを得て残りの３週間でうまくいくように進む、ということができれば問題は無いと思う。
ただ、失敗するのが分かってることなら、アンチパターンとして共有するくらいで良くてしれっと最初に聞いてしまって先に進むのでいいと思う。時間がもったいない。
どう考えても、「うまく行った！やった！」ってなったほうが、気持ちいいし、次に同じような機会がもし合った場合には、より難しい課題にチャレンジできる状態になっているはずなのでそのほうがいいはず。
チャンスは少ないし、時間は有限だ。 どんどん先に進まないと、後ろからどんどん抜かれることになる。
