イベントの目的と目標、参加者の思い。
ブログ書くまでがイベント！ということで、最近あんまり書いてないブログを書く。
先日、11/20,21 に４回目の RailsGirlsKyoto にコーチとして参加してきました。 イベントの内容が、、というのは他の方にお任せするとして、いちいちそもそもなんでこれやるんだろう？とかなんでみんな来るんだろう、とかどうなるといいんだろう、とか考えている。。。
頭の中をドサッと出してみて、とりとめないけど思ったことを書いてみます。
イベント開催の目的・期待すること
仕事でもなんでも同じだけど、何かするときには、何かしらの目的とか目標が欲しい。 別になんでも良くて、仕事なら利益がどうの、とか顧客満足が・・・（結局は利益に還元されたりしそう）とかもそうだし、もう少し主観的なものとして楽しいから、とかでも目的としてはいいと思う。もちろん、それが必要だ、という何かしらの理屈が欲しいけど。
プログラミングの言語コミュニティーの場合でも、今回は RailsGirls という思想がもともとあるものだけど、やはり主催しようと思う人には、それぞれの思いとかきっかけがあるんだと思う。 主催者が全て、というわけではないけど、やはり主催者が一番強い何かを持って開催するのだと思うので、それは知りたい。
「楽しそうだから」「イベントのオーガナイズをしてみたい」とかでもいいと思うし、「自分が体験した感動をいろんな人に・・・」とかもいそうだし、なんでもいい。スタッフとしては主催の人の思いを実現できるように、というように動くのが必要なことだと思っている。なんでもそうだけど、モットーなりビジョンなりが欲しくて、それさえあれば後はその価値観で判断していけばいいはずだから。 （スタッフは主催の人の思いを実現するために・・・、というだけではもちろんなくて、各々の思いを出して行ったらいいと思う。自分はほっといても自分の思ったことをやっていくので、その上で主催者の思うものを後押ししたいなぁ、という感じ）
前回の 3rd では「繋がり」ということだった。今回の 4th のテーマとして「広がり」というキーワードが出て、解釈は色々だろうけど「よしっ！」という感じになった。 仕事の場合は、色々な物事が必須事項としてついてくるけど、コミュニティーの場合はあまり縛りが無く進んでいくので、せめてどこを向いてるのか？目的・目標はなにか？という辺りは共通認識として必須、と思いたい。（同じ方向を向くのが必須、ではなくて認識してることが必須、という感じ）
イベントではどうなるといいんだろう。。
では、具体的にイベントではどうなるといいんだろうか？
- 全員がチュートリアルを終える
- 楽しかったー、という感じで帰る
- なんかモヤモヤして続きが気になる
- スッキリ終わる
今回のテーマでは、「広がり」ということで例えば "RailsGirls が終わった時にその先に何かやりたいことが見えてくる" となると、先の方に広がった、ということになるだろうし、単純にパソコンを使ってやれることが増えた（やったことがあること、でもいい）となれば、少し世界が広がった、というと言ってもいいと思う。
少し細かく分けると、全体・個人で分けることができそう。
個人（Girls）の場合
全くプログラムを書いたことが無い、という方が多数なので、イベントの趣旨としてはやはり「プログラミングを体験する」というのが真ん中に来て、やってみた・動いた、というのができると、達成できたことになるのかな、と思う。 個別に聞き取りもするし、事前に意向を聞いているケースもあって、基本的な体験以外にも、次に繋がることや元々持っていた課題や疑問が解消される、ということが達成されること、ということになるように思う。
結構しっかりと聞き取りしておかないと、終わってみて「これでいいんだっけ」となりそうな気がする。 「触れてみたい」なのか、「実際にサービス作りたい」なのか「プログラミングしたい」なのかによって、それぞれ結構覚えること・大事になることが違ってくると思う。 アドリブが増えるので難しいけど、大事なことにかなり偏らせたつもりで初めて良いバランスになると思う。偏らせるのは難しいので
コーチ・スタッフの場合
これは他の人が何を思っているのか？があんまり分かっていないので完全に人によるだろうな、と思う。 こういうのは、イベントの前なり後なりに話を聞いておけば良かった気がする。（まだ聞くタイミングもあるかな）
自分の場合は、あまり思ってることを表に出していくとかなりうっとおしい感じになってしまうので控えるようにしていて、とにかく少しでも楽しく・期待したことが実現できるように、というスタンスで参加してます。サービス業としてのコーチをやってたりもしたので、割とお金もらってるくらいの徹底した感じにしてるところもある。もちろん、コミュニティーは一方的に与える／もらうものではないと思うので、全員でこれやったらマズイよな、と思っているけど、自分くらいはそういうスタンスでもいいですよね、とか思ってます。
イベント全体として
イベント全体、となると状態がどうなっているか？とか何を達成、とかはわかりにくくなってしまいそうなので、楽しい、とかの分かりやすい主観的なものとか、その後で繋がった・イベント継続、みたいな客観的な情報で良さそうな感じならいいと思う。
反省がたくさんあっても、良かったことがたくさんあればそのイベント自体は成功と思うし、反省がネガティブに記憶されるのではなくて次回に活かせば良かったり、何か他の事への参考になればいい、という程度じゃないでしょうか。。。
雑感としての感想
楽しい雰囲気が常にあって、良い雰囲気が土台になった良いコミュニティーだなぁ、という感じでした。 １・２日の短い間でしたが、全員で良い雰囲気が作れた感じがしていて、スタッフだけではなくGirlsも一緒に雰囲気を作っている感じ。
関西の人のノリ、というのも良く作用してイベントの流れと噛み合って、一体感があるなぁ、と。
その他の思ったこと
今回は単発のイベントだったけど、この後どうするか？というのがコミュニティー運営の難しいところなので、 誰かに依存する、というのではなくうまく回す仕組みが欲しいところ。
こういうイベントに来てる学生さん見ると、就職とか仕事の話をするのが社会人としての務めなんじゃ？と思った 大して悩まずに就活どうにかしたり、内定蹴ったりしたけど、もしも興味ある業界とかならじゃんじゃん話聞いたらいいじゃないだろか。。。
難しいけど ...
大事なことを覚えるためには「大事ではないことを覚えない」ということが大事で、 今何が大事で優先すべきなのか？と同様に「今やってるこれは今大事なのか？」ということを意識したい。（意識して欲しいと思った）
自分が学習するときにも人に説明するときにも同様だけど、特にいろんな未経験者には非常に情報が多いので適切な量の時期にあった情報がInputされることが大事だと思う。 （最初から体系的に・・・、ってやらないとダメな人もいるし、最初は流した方がいい人もいるので、人によるけど。）
奈良に行った
朝、早めに起きたので日曜の話を書いておく。 （けど、書ききらずに下書きに入ってたらそのまま放置してた・・・。）
（これ、だいぶ前だなーと思ったら 2015/6/21 だった。。。）
土日に奈良でムジークフェストというのをやると聞いて、鹿も見に行きつつと思っていたけど、天気がイマイチな天気予報でいつ行こうかと様子見ていた。
土曜は雨も降りそうだし、近場で過ごそうということで京都水族館に子どもを連れて行ってその後京都駅のイオンに行って買い物した。意外と天気良くなってて、奈良に行っても良かったかもー、という感じで日曜にかける！みたいな感じ。
夜になって天気予報は相変わらずイマイチで、翌朝起きてからもTVの天気予報だと雨！みたいな感じだったので諦めモード・・・。
と思ったけど、９時半くらいにじわじわ晴れてきて、なんか行けるかも！ってなって一念発起（？）、出かける支度！子どもにシカの話をして盛り上げつつ出発。
（バス停で京都駅行きのバスを待っていたら、昨日のイオンからの帰りに一緒のバスに乗っていたおばあちゃんと孫：大学生くらい？が同じバス停で待っていた。別のバス（昨日と同じバス）に乗って行った）
京都駅からは、近鉄の特急に乗る。５１０円で指定席に乗れて、子連れだけど大人一人なので隣の席が空いていて、そんなに混んでいないので隣に子どもを座らせて行った。空いててお得。３０分で京都／奈良移動できる。JRだと１時間かかりそうなので結構早い感じ。
家から奈良までは１時間１５分くらいで行ける。Googleで「奈良公園」って入れると２タップくらいでルート案内が出る。GoogleNow 気持ちいい。
奈良に着いて、近鉄奈良駅でせんとくんと子どもが手をつないで写真を撮る。全く可愛さ無くて誰もせんとくんに食いつかない。ここまで愛されないキャラも珍しい感じする。海外からの観光客もみんなスルーしてるように見える。
（ここまで書いて放置してた・・・）
子供がトイレできるようになってるので（一気にできるようになった）トイレを済ませてから奈良公園に向かう。
途中でなんかビール飲めるところがあって、ここかなーと思ったけど、音楽っぽさがなかったので違うと確信して先に進む。奥の方に進んでいって、東大寺の近くまで行くとなんかやってた。
途中、メインの目的（子供向け）だったシカに鹿せんべいあげたりしつつ行く。
雨上がりだったので、所々水たまりだったりドロっとしてて、シカの攻撃を避けつつ水たまりを避ける感じ。
・・・・
長いのであらすじだけ書こう。
- ムジークフェストのステージに着いた
- 人多くて日差しも強くなってきて、食事買うの並べなかったのでサータアンダギーだけ買う
- 音楽聴きながら、子供と二人でサータアンダギー食べる
- 飽きてきたようなので、広いところに移動してまた食べる
- 原っぱの真ん中で日差し暑い
- 奈良公園はむやみに広いスポットたくさんあってすごかった
- 何かの花がたくさん咲いてるスポットあったので見に行く（あじさいだったような・・・）
- 奥の方の林っぽいエリアに行く。シカがポツポツといる
- 原っぱに戻って石舞台みたいなので、幼稚園で覚えた踊りを踊る
- ステージに戻って、太鼓を見る
- きいやま商店やってたので聞きつつなんか揺れる
- 会場を後にする
- 鹿せんべいあげつつ、川の流れてるエリアで何か探す（何も居ない）
- 小さいお店でかき氷食べてる人を見かけるけど、ビール飲みたいので強行で戻る
- オクトーバーフェスト（ビールのやつ）に向かう
- かき氷みたいなやつが一つだけあったので買って食べて待っててもらう
- IPA のやつだったかとソーセージ的なやつを買って、食べて飲んで美味しい思いする
- 雨ふりそうだったから退散
- 商店街を通って１００均でシカの角的なの買う（実際はクリスマス用のトナカイヘアバンドみたいなやつ）
- 奈良駅に向かう
- 雨降ってきて、本降りになってきてた。（すでに屋根のあるところに退避済みで成功）
- 電車乗って帰ってくる。
- 平城京とかが電車から見えて不思議な気持ちになる
- 家まで頑張って帰る・・・・。
長すぎて大変なので箇条書き。 楽しかった。
またシカに会いに奈良に行きたい。若草山とか、その麓の辺りとかもなんかあるらしくて、思ったより奈良も奥が深そうな感じする。
言語別 duck typing してみた。
最近 golang 書いてるけど、ちょっと独特なメソッドのレシーバーの指定の仕方だったりしてなんとなく比較を書いてみる duck typing といえば、Rubyが代名詞的な感じがあるけど他の言語でも普通にできたりする。Rubyほど「意識して」使われない気もするし、JavaScriptとかではそもそもクラスが無いのでそれが普通だったりする。
そもそも duck typing とは
「ダック・タイピング」。一応。
アヒルのように鳴くならアヒルとみなす、みたいな感じ。Rubyだと型が無いので、特定のメソッドがあって呼び出しできるなら中身が何でもいいよね、みたいな感じだろうか。雑だけど
例えば、 call() というメソッドがあって戻り値が string だったら〜〜機能として実行できる、とかそういう感じになる。（説明は割愛：Rubyの記事とか探して読むと良さそう）
最初から色々メソッド（関数）を実装しておかなくても、好きなタイミングでメソッドを生やしたりして機能を追加できるよ、みたいな感じで使われたりする。
各言語での実装例
Ruby
メジャーどころ
msg = "婚活デカみてる。" def msg.sudden <<-FMT ＿人人人人人人人人人人＿ ＞ #{self} ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣ FMT end puts msg.sudden
String でもなんでもイケる。なんでもかんでもできすぎる感もあり、多用すると危ない。 特に、↑みたいに String クラスに生やすのは、影響を完全に把握してないとやばい
JavaScript
これは特別な感じではないので、いちいち気にして使わない
var msg = {}; msg.str = "婚活デカみてる。"; msg.sudden = function() { return "＿人人人人人人人人人人＿\n"+ "＞ "+this.str+" ＜\n"+ "￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣"; }; console.log(msg.sudden());
Coffee Stript
JS書いたしおまけ
msg = {} msg.str = "婚活デカみてる。" msg.sudden = ()-> """ ＿人人人人人人人人人人＿ ＞ #{this.str} ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣ """ console.log msg.sudden()
golang
主題。これも別に特殊さは無いけど、他の言語から見るとちょっと考え方が変わってる感じする。
package main import "fmt" type MyString struct { Str string } func main() { msg := MyString{"婚活デカみてる。"} fmt.Println(msg.sudden()) } func (s MyString) sudden() string { return fmt.Sprintf(`＿人人人人人人人人人人＿ ＞ %s ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣`, s.Str) }
string 型には直接functionを生やすことができないけど、自分で宣言した type（というのか struct というのか）に生やす感じになる。
func宣言で 「レシーバー」「関数名」「引数」「戻り値（複数戻り値があるときはカッコで括って複数書く）」という感じで並ぶ。C言語の系統での宣言とはちょっと並びが違うので「お？」ってなる。けどこれはすぐに慣れる。 （Rubyのヒアドキュメントでインデントできる、という仕組みがなんかいいな、と思う）
実行結果
＿人人人人人人人人人人＿ ＞ 婚活デカみてる。 ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣
おまけ
php
duck typing はできない。
<?php $msg = "婚活デカみてる。"; function sudden($s) { return <<<FMT ＿人人人人人人人人人人＿ ＞ {$s} ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣ FMT; } echo sudden($msg);
※ 完全に蛇足。諸事情あって、PHPはそんなに詳しくないけど。
golang のかるーいネタ書きたかっただけなので、大して意味ない。
軽い加齢臭の家
先日、加齢臭の話をされた。
我が家は子どもと３人で布団を並べて川の字になって寝ている。 夜だか朝だかに３人でゴロゴロしていたら、妻が僕の枕の近くに来た時に「加齢臭が」みたいなこと言ってた。ので、それからしばらく（１ヶ月くらい経った今でも）耳の裏とかの辺りを念入りに洗うようにしている。
でも、ふと気づいたらそもそも我が家は寝室（和室）の壁がなんか臭くて、加齢臭というか柔道着みたいな汗臭い感じの臭いが、ふっとしたときに漂ってくることがある。
普段、気になる程ではないけど、壁（白い普通のマンションの壁紙）に近づくとフッと臭う。
気になって一時期ファブリーズしてたけどあんまり効果がないみたいだ。
これ、正確では無いけどおそらく寝室でバルサンを炊いたあとからの臭いな気がしていて、最初からこの臭いがしていた訳ではない。
バルサンを炊いたのは、部屋に「死番虫」という嫌な名前の虫が発生したからで、多分発生箇所は和室の畳。胡麻くらいの大きさの（胡麻、ごめんなさい）甲虫みたいなやつで、そんなに被害は無い。
ただ、少し飛んだりしてテーブルにいることがたまにあったりするので、当時子どもが１歳ちょっとだったりして困るので退治しよう、ということにした。
発生元が畳だったりして、引っ越しで持ってきた何かが発生源にはなってないようなので、引っ越した時点でもう卵なりが畳にあったんだろう、という想定をした。で、マンションの管理会社に連絡して畳（畳表）を変えてくれ、引っ越した時点で虫がいたと思われるしそちらの責任で（確証ないのでやんわりと）と伝えたけど、「バルサン」炊いてくれ、という回答。
嫌だったので拒否したけど、当然のように言われたので仕方なく炊いた。
という感じで、壁が臭い和室が出来上がった。
これも確証ないので不満の向け先がない。 多分、自分の耳の裏が臭いわけでは無さそうで良かったけど。
全然良くないけど・・・
メモのとり方
軽い話。
誰かが書いてたのか、ビジネス（仕事の仕方）コラムみたいなので見たような気もするけど、「メモのとり方」についてしっくりきた話。
メモを取る目的にすると良さそうなこと
後で質問したいことを書き留めておくこと
結論は大体これ。
なんか、覚えたいこと・大事なことをメモる、というのが一般的なのかな、という気がするしそういう感じでいままで過ごしてきたけど、自分で振り返ると誰かの発言とかTipsみたいなのをメモっておいても後で見ることはほとんどない。
メモを取るタイミング
タスクを依頼されるときとかにその成果物定義を書く、とかならまあそれなりに何か書いたりするし直後にその書いたものをタスク化する目的で清書したりする気もする。
でも、あとからそういうものを見返したりすることはほぼ無くて、何かタスクが漏れてて後で「わー」ってなることもほぼ無い。そもそも、人に言うことはそこそこあっても言われる／依頼されるということがあんまり無いのでメモするタイミングが訪れない。
・・・ と思ったけど、電話でお客さんと話をしてるときに、３０分とか電話することもあって要件もまとめて４〜５個くらい話をしたりするので、メモしないといけないこともある。
と、少し話がズレた気もする。
手書きメモをささっと取る必要があるケースとしては、なんかの面接／面談とかミーティングとか勉強会みたいなやつ。情報がそれなりに多くて、かつ対話形式じゃなかったり話者が止まらない感じのシチュエーション。
必要のないメモ
打合せとか、勉強会みたいなのでメモるとき、大抵は頭に入る感じで話を聞いてるのですぐ後に思い出して整理すればいい、ということが多い。勉強会なら、アジェンダみたいなのが出てることとか多いので、わざわざ自分でメモる必要は無さそう。
メモってると、話に集中できないので話を聞き逃すと思う。
必要なメモ
自分の場合は、それなりに疑問点あればすぐに聞く。でも、タイミング的に質問できないことがあったり、質問すると流れを遮ってよく無さそうということはそこそこあると思う。
で、そういうときに、質問したいこととか疑問点をちょっと書いておく。
内容によっては、すぐ後に答えみたいな話になることもあるし、少しして話が整理されたら理解できることもある。
質問コーナーみたいなのがあったり、話題が切り替わる前に、とかのタイミングでメモっておいたことをちょっと思い出して聞く、とかがいいと思う。 どうせ、有用な情報を全てメモることはできないし、（自分の場合は）後で見ない、必要ならその時にググるとか「あ、あの時に言ってたあれか」っていうきっかけになればいい、というくらいでいいと思ってるのでメモにしたものを使うことが無い。 （Evernoteに記録してる、とかだと後で探せるんだろうけど、今回みたいな想定ケースだとノートになぐり書きする程度がせいぜい、という感じ）
これなら、話を集中して聞けるのでメモがいい感じに使えてる。
ただし〜〜に限る
ただし、質問する人に限る。
後でググる情報とかを書いておく、とかでもいいのかも。
golang で子プロセス実行するときに、Backgroundにする（やり方が分からず・・・
Goで書いてる運用系のツールで、以下のようなことをやりたかった。
- メインのツールと、サブツールみたいなのがある。
- サブツールはバックグラウンドで起動しておいて、メインのツールから利用する軽いWebAPI
- メインのツールはある程度起動／停止を繰り返す感じになる
- メインのツール起動時にサブツール(API)が起動してなかったら、バックグラウンドで起動したい
つまり、メインのツール（M）起動時に、サブのツール（S）が起動してなかったらバックグラウンド起動しておく、ということをしたい。
プロセスの存在チェック
プロセス調べるのは、Goの標準ライブラリで無さそうなので pgrep "S" コマンドを実行して、ExitCodeで判定
package main
import (
"bytes"
"fmt"
"os/exec"
"strings"
"syscall"
)
func main() {
process_name := "target_tool_name"
cmd := exec.Command("pgrep", process_name)
cmd.Stdin = strings.NewReader("")
var out bytes.Buffer
cmd.Stdout = &out
err := cmd.Run()
if err != nil {
e := err.(*exec.ExitError)
s := e.Sys().(syscall.WaitStatus)
status := s.ExitStatus()
if status == 1 { // exit(1) は見つからない時
fmt.Printf("process '%s' is found")
} else {
fmt.Println(err) // なんかその他のエラー
}
} else { // プロセス１つでも見つかるとエラーにならない
fmt.Printf("process '%s' is found", process_name)
}
}
こんな感じ。無駄もあるかもしれないけど Linux ならこで良さそう？
ExitCode 取るのが思ったより面倒だった。
プロセス実行しつつ、バックグラウンドにする
os/exec の Command では、 Start() / Run() 辺りでプロセスを実行する。
Run() だと終了を待つけど、 Start() は goroutine で実行して待たない。
Wait() 使うと、プロセスの終了を待つ感じになると思う。
で、 Start() を使うとバックグラウンド実行かな、と思いきや、
自身のプロセスが終了するタイミングで Start() で実行したプロセスも終わってしまう。
（Ctrl-C で終わる場合）
このサイト見ると、プロセスグループが同じだから（？）みたいなことが書いてあって、
cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true} で分離できそうなことが書いてある。
（と読んで思った）
けど、できなかった。
結局、 /path/to/sub/tool & でバックグラウンド実行するように shellscript を作っておいて、
その shellscript を golang から実行するようにした。
Goのメインツールのプロセスとは分離できたけど、イマイチな感じになった。
感想
もうちょっとスマートな方法ありそう。 勉強が必要そう。。。。
（追記）そう言えば supervisord 経由で起動するがどうの、という感じのことが書いてあった。
失敗して何かを覚えるよりも、最初からうまく行ったほうがいいと思う
タイトルに言いたいこと書いた。
知らないことをやるときのアプローチ
今日、自分のチームの隣の人が（ECサイトの開発してる）「初めて決済周りの改修案件に関わる」ということで新しくこの決済サービスの連携についての見積もりをしていた。 決済周りはチーム内で知ってる人が限られてるので、多くの人が携わったほうがいいよね、ということで新たにやってみよう、という感じでその人にタスクを割り振られた。
とりあえず、そのサービスの資料を読んで何をやればいいのか考える、ということをしていて、決済の辺りを分かる人は最初は説明せずに「まずは自分でやってみて。分からないことあった聞いて」くらいのスタンスでいる感じだった。 １日くらい見てから、分かる人に聞いたら、気にしなくていい箇所を見ていたらしくちょっと観点が違う感じ、という話をしていた。
「分かる人」は、聞かれたら答えよう、と思っていてとりあえずはやってみたら、というつもりだったと言っていたけど、自分も決済周りはやってないので、モヤっとは感覚分かるかもしれないけど時間が無限にあるわけでもないので、もし自分だったら１時間程度資料見たらあとは聞きながら進めると思う。「わからないなりにやってみる」というのは当然ゴールへの最短経路ではない。
最初は失敗してもいいんじゃないの？という考え方
おそらく、タスクを依頼したり有識者として「聞かれるまで答えない」というスタンスは、
「最初はみんなうまく行かない。失敗して覚えるのがいい」
みたいなイメージがあるのかな、と思う。
もちろん、本番にリリースしてから問題起きた、という失敗ではなくて、わからないなりにやってみて聞いた時に間違えを指摘される、という程度。
これは自分の考え方ではマズイ方法だと思っている。
仕事で求められること、求めること
仕事していて、「仕事のやり方自体を模索して覚える」という必要があればこれは別にいいかもしれない。
他に事例が無いことをやるときとか、人に頼ることができない状況では自分で仕事を進める方法を考える必要があるので、失敗して模索する、ということ自体を覚える必要があるかもしれない。
ただ、今回のような「チームで開発をしている」場合には、得手不得手があってフォローし合えばいい、というのが前提になるのと（社員じゃないのでOJT的なスタンスが不要なのもあるけど）、仕事の内容自体を覚えるだけでいいはず、というケースになると思う。
新入社員を教育するなら、うまく行かない感じを体験させる必要もあるかもしれないけど、すでに１年とかいる外注の人にそういうの必要だとは思わない。
今回のようなケースでは、覚えるべきは「決済周りの開発方法」であって、「知らないことをやるときにどういう仕事の仕方をすればいいか」では無いだろう、ということ。
これがWebアプリケーション開発なら
老害っぽい感じで、WebアプリFWとか使わずに新人は最初はFWを使わずに（例えばPHPなら）「素のPHP」を使ってアプリを作るべき、という発言に該当すると思う。
そうすると、ロギングとかMVCがどうの、ORM、セッション管理が・・・、とかを覚える必要があるので全部理解してからWebアプリケーションを作ることになるよね、という話。
分かりやすい話で、この辺りは知識として持っておいたほうがいいけど、自分で作る必要とか無いでしょ、というのが世の中の総意だと思ってるけど、こういうレイヤーは現在は「インフラ」というか前提として付き合えばよくて、もっと別のレイヤーにリソースを割くべき、という話だと思う。
動くまでにやること、というのは先人たちが頑張ってくれたので、素直にRailsとか使っておいてもっとUI/UXやら開発のスピードをどうにか、とかにフォーカスすればいいと思う。
少し戻る
今回の話で言うと、改修方法は知ってる人にサラッと教えてもらって、「次回に同様の話があった時にスムーズにできれば良い」とかが実現できれば、「改修方法を覚えた」ということになってそれで十分だと思う。
今回の場合は、早く終わって他にやることたくさんあるよね、となればいいので早く終わることはいいことでしかない。
最短で「うまくいく」ということを体感する意義
言いたいことは、「失敗しないほうがいい」というよりも「すぐにうまく行くべき」という点で、うまく行くことをクセづけすることが必要だ、という点。 失敗がクセになるよりはいいのは分かると思うけど、問題は「失敗」まで到達してしまった時に覚えている範囲で「成功」することができるかどうか？
スポーツの例
例えばテニスでボールを打つとき、難しい（失敗しやすい）状況でたくさん打って崩れたフォームが多くなるよりも、簡単なボールをたくさん打って良いフォームでクセをつける方がいい（と思ってる）。 良いフォームで体が覚えると、難しい状況で体制が多少崩れてもクセになっているキレイなフォームで打とうとするため、体がある程度は補正できる（はず）。 崩れたフォームだと力の入り方に無理が出たり、一定のレベルまで行くと上達が止まったりする。 （元テニススクールコーチ談：自分）
子どものトイレの例
子どものトイレは、おしっこがトイレでできる、というのを繰り返さないといつまでもオムツが取れない。 ・・・割愛。
プログラミング／設計の例
プログラム書いていても、うまく切りだされていない千行あるメソッドがあったとして、新人が誰かの手本無しでキレイに分割できるだろうか。良いサンプルをみてポイントを理解したらできるかもしれないけど、良い感じの実装／設計を見ないとそもそも何がいいのかがわからない。
試行錯誤して自分の作ったものを見直していくのには、何年か（or アプリが４つ以上とか）かかると思うが、手本を元に最初からうまく行く状況を作ると何年か分を先に進めることになる。
まあ、アンチパターンを知ることも大事だけど、自分のコードである必要はない。
仕事の仕方の例
たとえば タスクとかプロジェクト という単位だとして、失敗したあとでそのフィードバックを元にリカバリしてうまく行くように、というのを試すタイミングはあるのだろうか？
タスクの粒度にもよるけど、大抵は似たようなケースには出会わないと思う。
自社サービスをやっている会社でも、粒度が大きいとサービス作って失敗して潰してPJが赤字になって次の予算が・・・、とかになりそう。それでも次をやる体力があればいいのかもしれない。 （だとしても、全員が「自分が体験する」のでないと覚えないのだと色々足りない）
貴重な機会を失敗で終わるよりは、誰もが通るようなポイントは事例だけ聞いて教えてもらってクリアしてしまって、一番難しい・注力したいところにリソースを割けばいいと思う。
要はフィードバックループ（？）の問題
失敗する余地がない、という訳ではなくて、要は与えられた期間の間に「うまくいって終わる」ことができれば良くて、１ヶ月のタスクなら１週間でフィードバックを得て残りの３週間でうまくいくように進む、ということができれば問題は無いと思う。
ただ、失敗するのが分かってることなら、アンチパターンとして共有するくらいで良くてしれっと最初に聞いてしまって先に進むのでいいと思う。時間がもったいない。
どう考えても、「うまく行った！やった！」ってなったほうが、気持ちいいし、次に同じような機会がもし合った場合には、より難しい課題にチャレンジできる状態になっているはずなのでそのほうがいいはず。
チャンスは少ないし、時間は有限だ。 どんどん先に進まないと、後ろからどんどん抜かれることになる。
