「プログラミングスクールに一ヶ月通ったけど、自分で作れない」という人がいても、諦める必要はないよ、という話

はじめに

自分の会社では毎週土曜日に勉強会開催しているんですが、ちょいちょい「スクールに通ってました」という方がいらっしゃっています。相談所と銘打っているので、大抵は何か課題があったりして困り事を抱えているという感じです。 よく会話の流れで

「でも、自分で作ろうと思うとうまくいかないんですよね」

という話になるのですが、私は結構当たり前だと思っています。この話は

「そういう人いっぱいいるし、それはあなたにセンスがないわけではない。諦めないで！」

と言いたい為の文章です。

宣伝で出ている言葉と実態の差について

「一ヶ月でプロのスキルを」とか、「数十時間で身につける」みたいな言葉が結構出てきますが、「皆がそうなる」とは言っていないので、それが頂点のごく一部の人を指しているのか、習いに行けば皆そうなるのかは伏せられています。多分多くの既にプログラマーになった方は納得してくれると思うのですが「そんなのはいたとしても超センスあるごく一部か、技術以外の部分が多分に占めている方法だ」と思っているはずです。

カリキュラムを真似しただけで即作れるのではない

通り一遍のカリキュラムを真似しただけで何かが動いたという状況は、真似している時点で「体験」の域を出ていないと思います（スキューバダイビングなどの体験とか、乗馬体験などをイメージしてくれれば良いと思います。それっぽいことをやれたけれど、本当のそれではない、ということです）。 本当の目標は教本を写すことではなくて、自分が必要とする動作を自分で考えて作らなければいけません。それには下記2点くらいが必要になってきます。

• 根底の理解の獲得（フレームワークは往々にしてこれを阻むことがある）この辺でチラッと書いてます。参考までに。
• うまく動かない時の対応（デバッグ・検索の能力）

ちなみにカリキュラムを真似するだけであれば、わざわざスクールに行かなくてもWEB上の入門文書や書籍を真似することでも得られる価値は高いです。まずそこからやるだけでもかなり違うはずですよ。個人的には自分でやれそうなことを少しやってみる方をオススメします。

要するに

まだ作れなくても大丈夫。大丈夫だから、継続してスキルアップに励んでみてください。今諦めてしまうのはもったいないんです。お金と時間と脳みそを使った分が回収できるのはここからです。忘れてしまわないうちに、次のアクションを始めてください。悲しいかな短期的に覚えたことはすぐに忘れてしまうので、忘れてしまう前に次をやるのがベストです。

もしもどうしても辛くてしんどいのであれば、ひょっとしたら性格と合わないなどがあるかもしれないので、そこで離脱もありかもしれませんが、宣伝文句や他者との比較でガッカリしてやめる必要などありません。

次のステップまでのオススメの進め方

最初は真似してても良いと思います。真似から得られる全体像を大切にしてほしいです。そして「今動くもの」が一つ手に入るのは大きいのです。

動くものができたらちょっぴりだけ改造してみましょう。きっと簡単には動かない。でも、そこで得られる経験はとても大切です。なぜなら、プログラミングするのならそれをずっと続けるはずだからです。例えば下記のようなことをやってみるのどうでしょう。

• 表示されるものを何か変えてみる。「表示される内容によって文字の大きさや色を変えてみる」とかちょっとしたことでも良い。
• 一個だけ表示していたものを沢山表示してみるとか。
• DBのカラムを追加してみる（DBの変更して、フォームに追加したりViewを変更したりする。色々やらなきゃいけないことがわかってくる）。エラーにもたくさん出会うはず。

ここで獲得しなければいけないのは、おそらくそれまでに獲得できていない下記です。

• うまく動かない時のデバッグの仕方、有用なツールを知る
• 検索して問題解決するコツを掴む

うまくできたら「やったー！」って喜んで良いんです。この達成感で高揚する人は多分向いてます。今は時間かかるかもしれませんが、コツを掴むとどんどん動かせるようになれますよ。

どこかのコードをコピペしても良いです。ただし、コピペしたものがどういう動作なのかは頑張って読みましょう。わからないことは調べましょう。大事なのは暗記することではないので、コードを理解するように努めてください。コピペスキルが物凄く高い人が最初の頃センスあるように見えて、実はセンスが無いというのはあるあるなんです。

成長のイメージ

不安だと思うので、多くの人の伸び方をちょっと書いておきます。

• 最初全然成長しない。してても気づかない。
• いきなり開眼したように一気に伸びる（ここに一ヶ月二ヶ月の真似だけで到達するのは稀だから頑張って！というのがこのエントリの主旨です）。
• また停滞する（ただこの間も作り続けたり学習したりすること）
• いきなり一気に伸びる（それまでとは違う新たな概念や哲学を獲得すると伸びる場合が多い）
• 以下繰り返し

最初の頃のアンチパターン

相談所で出会うアンチパターン書いときます。だいたいこういう感じだとまずそこを直してもらったりします。

• 「エラーメッセージを読まない」英語だからって怖がって閉じる人。沢山います。エラーメッセージは解決方法を教えてくれる大事な情報なので、頑張って読んでください。
• 「ツールを使おうとしない」
  • 無料のエディタでも色分けしてくれたり（これが結構エラー発見に役立つ）、入力中に補完してくれたり、つまらないミスを防いでくれる機能があります。これで時間を無駄にしないようにしましょう。
  • Chromeの開発者ツールを活用すると、思ったような出力がブラウザに出ているかを確認するのにとても有用です。特にHTML/CSS/JavaScriptでうまくいかないときはお世話になること必至です。
  • gitを使わないのは損です。ちょっとだけ改造したりした時に「うわーどうしても動かないー。しかも前の状態に戻せないー（＞＜）」ということがよくあるので、簡単なgitの機能を知っているととても有利です（注: gitがそこそこ難しいとかうまく使えないケースもあるので、難しそうならとりあえずディレクトリ全部コピーとかも最初は良いかもしれません）。
• 「MacなのにVagrantとか仮想環境を入れる」Macを使っている人はVagrantなど仮想環境を入れなくても十分な環境があるので、無理して入れなくて大丈夫です。むしろ入れることで問題の解決がしにくくなって辛くなっている人の方が多く見受けられます。あれはWindows環境の人を救済したり、コンテンツの内容を合わせるためだと思うので忘れても良いと思います（真似しているところが使っているとそのままやっている人が結構多くて、いきなり動かなくて治し方がわからないとかなっているの、もったいないです）。

さいごに

個人的には、最初のとっかかりからプロになるまでをずっと見ていくことを生業にできたら良いなと思っています。でも、現実は人それぞれ成長の仕方が違ったり期間やかけられる時間が違ったり、育成する側の手間暇も違うのでとても難しいです（経営としてもうまく折りあえて、そこまでガッツリやれる方法があったら知りたい）。

少しずつ理想の形が探れれば良いなと思っています。

あと、どうしても困った人がいたらほぼ毎週土曜日の渋谷で開催し続けている（もうすぐまる三年です)プログラミング相談所に来てくれれば、私や弊社のメンバーが相談に乗りますよ。

年末年始、やるぞ！と思っている人、ぜひ諦めずにステップアップしてみてくださいー。

総個人戦するよりも、志向の似ている人と集まってチーム戦がしたい私にとっての働き方へのアプローチ

まとまらない徒然エントリなので、タイトルもなんか後から読んでつけた筋の通ってない感じかもしれませんがお許しを。

note.mu

ちょっと自分にとっても何が言いたいのか決まっていないままに文章を書き始めます。エントリ自体は凄く好き。下記みたいな言葉は熱くてイイ！そんなに波が好きな理由はサーフィンしない僕にはわからないけれど、僕が熱狂している何かと同じくらい熱くなっていることはビンビン伝わってきます。

僕が今実践している、リモートでエンジニアをしている働き方は、「たくさんのいい波に乗りたい」と「次の時代をつくる存在でありたい」というモチベーションのもと、突き詰めているいることで、あくまで僕がやりたいことを実現する方法である。

そんな中、この投げかけが妙に僕の心に引っかかりました。

働き方は、働く「方法」で、あくまで方法であるはず。

あれ？僕にとって「働き方」という言葉は「方法」を示していただろうか。いわゆる弊社やメンバーの「働き方」的なものを並べてみると

• 弊社はコアメンバーがコアタイムなしのフレックスタイム制で働ける（社長の僕自身も「今日は13時出社ね」とかやってるレベル。社会不適合とか呼ばないでください。わかっていますから。）。
• 気が乗らなければ連絡すれば突発でリモートで働くこともできる。もちろん他人にしわ寄せを与えない形で認めている。
• 個人向けプログラミングのトレーニングを生業にしている都合もあって、週休2日の2日が日曜以外にもう一日取るような形でメンバーは働いている。
• 時短社員は週4日で働いている。
• 激しい残業とか強いていない。先月とかその前の時間を見ても160時間とか、時短の人で120時間とかで働いている。今年は一回私が見積もりをヘマして（ごめんなさい）激務タイムがあったけれどそれは異常値としたい。

僕自身は好きなことを仕事に変えることを続けているので、365日殆ど仕事っぽいことをしています。とは言え終わらない趣味を続けているような心持ちです。多分一生仕事してても楽しく過ごせるタイプですが、いわゆる激務好きのワーカーホリックとは違うタイプだとは思っています。忙しいことが大事なのではなくて、僕が望む未来を実現するため に毎日努力できることが大事です。

前置きは置いておいて。

何かを成し遂げる「方法」だとすると、「xxxを成し遂げるために仕事を調整する方法」という風に感じ取れます。それってつまり「仕事はできればしたくないことだ」ということが前提に立っている言葉ではないでしょうか*1。

考え方が逆なんじゃないかなと思うわけです。できれば「好きなことを仕事にする」ことから考えられないだろうか。件のnoteの件であれば、波乗りをするプロ・プレイヤーまで行かなくても、波乗りに関わることを仕事にできれば、彼は最高に楽しい人生になるのではないかとすら感じるのです。私は詳しくはありませんが、サーフィンに関わるシステムの開発は無いのだろうか、とかそういうことを考えてしまうのです。素晴らしいサーフボードを作っているメーカーのWEBサイトを作るとか、サーファーの雑誌のために自分で体験取材するライターとかメッチャ楽しくなる可能性を感じたりします。そういう会社なら「サーフィンを続けるための環境」についても真摯に取り組んでくれるのでは無いかと思うし、なければ自身が作れば良いくらいに感じるのです（理想かもしれませんが）。

ゴールを決めずに書き始めたので文章の方向がグラグラですが、件の彼の生き方を批判したいわけでは無いことを改めて強調します。これって「そういう会社があって彼らのドメインに合わせた形を提供できれば」解決に向かえる話だと僕は考えてしまうのです。会社は働き方を色々と用意することが以前に比べて可能になってきていますが、もっと個人の嗜好に特化した会社ができて良いと思います。自由に何かできる会社を作るのは法制度の問題があったりして経営者は苦労したりもするけれど、そういうことを一つずつ取り除いて「理想の生活が継続できる集まりを作る」ことの方が、価値が高いように感じるし、そういう人たちが後世に「より良い働き方の土壌」を残せるのでは無いかと思うのです。

「私は私の方法を自分で手に入れました。後世の人も苦労して自分の方法を手に入れるように努力してください」 とならないように、私たちの世代がより良いと思う形を集団に対して 再現可能な形で 残していくことはできないだろうか。

僕自身は、個人の力で気に入らないことを何でも変えようとしてしまうし、実際に変えてきたとも思っていますが、同じ苦労を次の世代の人にさせないように今の会社組織を考えていますし、それが会社という存在の意義だとも思うのです。たとえ私が死んでも文化として会社の中により良い働き方への工夫が残る事を願っています。

僕は「国民総フリーランス的働き方」が実現しても幸せになれる人はそれ程増えないと考えています。それは自分の苦手なことや嫌なことをそれが得意だったり好きだったりする誰かに自然に補ってもらう方が良いと考えるからです*2。似たような志向の人と集まれないなら個人の方がマシですが、だから逆に、持っている職能は違っても、 似たような人と集まれるような形 を組織として作りたいです。

ううーん、生煮え過ぎて何が言いたいのかわからない節も多いとは思いますが、何となくこれ残しておいても良いかなと思ったのでキーを打つ手を止めて、終わりにします。とにかく自分としては、同じ方向を見て働ける仲間と一緒に良い形を作って、次の人たちへ伝えていく所存です（なぜか宣言で締める）。

*1:多くの人がそう思っていることはもちろん承知していますが、私は上記のような感じで仕事大好きなのでそういうことだと思ってください。誰かに喧嘩を売りたいわけではなくて、「私はそうなんだ」という事実を書いているだけです

*2:個としてバランス良く何でもできる人の方が少ないし、それをやりたい人も多くはないと考えています

Railsチュートリアルが悪い？違いますよ。Railsチュートリアルから入ってRailsの事「だけ」しか学んでないのが悪いんですよ。

qiita.com

これに関連して私の言いたい事は下記です。

• Railsチュートリアルは単なる文書なんだから間違いが書かれていないなら善悪など無く、悪いのは使う側の人間です。
• たとえRailsチュートリアル「だけ」マスターしても、自分のサービスなど作れないしシステム開発者になどなれなくて当たり前です。
• 必要なのは「教本にないことを実現しようとした時に起こる問題を解決する能力」それにはもっと低レベルの知識がないとできないです。
• 最も悪いのは「そういうこと」を教えてあげないこと（だからこのエントリを書いた）

Railsチュートリアルが悪いのか

チュートリアルはただの技術文書で内容自体に誤りがそんなに無いと思うので、「チュートリアルが悪い」という話はすでに何かおかしいですよ。道具が悪いなんてことは殆どなくて、悪いのは使う側の人間ですから。

文書というのは対象の読者がいて、それに対して適切な粒度で情報が提供されるものです。私の見解ではRailsチュートリアルは「ある程度システム開発がわかっている人向け」に書かれています。実際、文書の方にも下記のように書かれているんです。

本チュートリアルでは少なくともHTMLの知識と何らかのプログラミング経験があることが望まれます。ソフトウェア開発がまったく初めての方には、拙著「Learn Enough to Be Dangerous（英語）」のチュートリアルを先にやっておくことをおすすめします

初めてのシステム開発で初めてのプログラミングという人に向けてはいないと思います。ですから初学者が最初にあれをやろうとすれば「わけもわからずとりあえず書き写して、書いた通りにすればなんとなく動いて、うまく動かなければエラーなど読まずに文書とニラメッコして書き間違いを探し、分からなければ誰かに答えを聞く」という手段になりがちです。チュートリアルをやるための前提知識を全く持っていなければ理解不能であるのは当たり前でしょう（もちろんこの進み方でもある程度の理解を獲得できるすごい人はいます）。

ただ（これはなにがしかの文化のようなものだと思っているのですが）「過酷なRailsチュートリアルを乗り越えた」という共通体験を持って繋がりを作っている人達はいるような気がしています。部活や仕事の体験を、酒の肴に「あれはキツかったよなぁ」ということを話して共感し合う人達っているじゃないですか。あんな感じではないかと思います。それはそれで文化という大事なものかもしれないと感じています。

とにかく、悪いのは誰でも彼でも「とりあえずRailsチュートリアル」という形に押し込めてしまうやり方だと思っています。Railsはベストプラクティスがギッシリ詰まった凄い道具です。そういうハイスペックな道具を使うには前提となる知識もたくさん必要ですし、それなりの経験を積んでからでなければ、なかなか使いこなせないと思った方がいいです。

Railsチュートリアル「だけ」ではダメなことが明らかになる瞬間

おそらく多くの先人がぶち当たったのは下記の二つのタイミングだと思います。

• 書いてある通りにやっても動かない
• 自分で機能を追加しようと思ったけれども、できない

「エラーメッセージが表示されるが、その先をどう対応して良いのか分からない」という形で現れることが多いと思います。エラーメッセージすら認識せずにただ「リロードしたけど表示されない」とか「赤い画面が出てそっ閉じしている」のような認識の人もいるでしょう。

エラーメッセージを読んだり、メッセージをコピペして検索すれば答えがあるようなものの場合にはそれだけでも解決できます。 実際に多く必要なのは「あるべき姿」への理解です。例を挙げましょう。

例: 画面のformから情報を登録しようとしたら、エラー画面になってしまう

表示された画面のHTMLのformタグのactionに書かれているパスが、サーバー側で受け取り可能になっていなければ、情報は受信できません（もちろんこれ以外にもエラーが発生する可能性がありますが、あくまで例として）。

そして下記のような具体的な行動をして確認していく必要があります。

1. form_for で生成された HTMLのformのactionを見なければいけない
2. rake routes で対象のURLが作成されているか確認しなければいけない
3. 思った通りの通信をサーバーが受け取っているか、ターミナルのログを見なければいけない

もちろんRailsチュートリアルでも、似たような対応 は載せてくれています。ただ、初学者の人がこの説明だけで把握することは難しいと思いますし、説明の内容があくまでも「Railsでどう考えるか」までになっています（これは対象読者を考えれば当然だと思います）。

私が先に挙げたような例の場合ですと、1の部分の誤りを見つけたら、HTMLのformで起きていることから Railsの form_for の記述へ逆算が必要になるんですね。「自分の望んでいるHTMLのformを作成するには、Railsでどう書いたら良いのか」というような思考になります。これは文書と逆の思考だと思うので、ある程度WEBシステム開発に関しての慣れがなければなかなか辿り着けないと思います。

とても簡易な体験で良いので、HTMLのformとサーバーの関係が腹落ちしている方がこういったトラブルシュートは遥かに早くなります。それがない人は闇雲にトライアンドエラーを繰り返すだけなので、ここでずっと足踏みしてしまうんですね。「Railsを学んだけれどシステムを作れない人」は、こういった部分の腹落ちが足りていないようです（これは私のところの勉強会に来ていただいている初学者の方を見て確認しています）。

同様のことはActiveRecordとSQLのようなところにもあります。

というわけで、RailsチュートリアルでRailsを繰り返す「だけ」では自力で開発するのは難しいです。HTMLやHTTP通信がどのように情報を交換し合っているかの理解や、DBからSQLでどのように情報を出し入れするのかというところの理解が必要になってきます（DBに関しては、効率が悪くなっても構わないのであれば最初の頃はある程度踏み込まずに進めることもできるでしょうが、最終的にはSQLが分からないとダメですね）。

悪いのは、誘導している側ですよね？

最初に相手の初学者の持っている性質や力量を考えずに「Railsチュートリアルをやれ」と押し付けてしまう人や、Railsチュートリアルを真似たようなカリキュラムを提供して適切なフォローをしないスクールや、「俺が苦労したんだから同じ道を歩め」と考えることを放棄する先輩など、そこに誘導する側に問題があると私は思います。

そして、チュートリアルで腹落ちできなければ初学者は「自分にセンスがないからだ」と去っていってしまう。こんなに悲しいことは無いですよ。ちょっと最後感情的になりましたが、日々少しずつ不満を抱えているところに件の記事があって言いたいことを吐き出してしまいました。

ちなみに私はRailsチュートリアルに達するまでのステップが不足していると思っているので、そういうところを埋めることをやったりしてます。吠えているだけで何もしてないんじゃ無いですよ、ってことで。

激務の話についたはてブを見ながら考えたこと

※画像はイメージです

はじめに

ms2sato.circlearound.co.jp

上記の記事に予期せずたくさんのコメントをいただき（若干ビビリました）、弊社のメンバーとも話題にさせていただきました。「クズになりやすい」などのコメントは私は文脈がとらえられなかったのですが、「仕事が終わっていないと見せかけて楽をする人がいるとかじゃない？」とメンバーに指摘されたりして、そういうことかーと思ったりしています。「余裕があるから怠ける」とかはありそうですね。

会話している中で「弊社の環境だから」できているのでは？という言葉を貰ったので、もう少し考えようと思いました。

現状

私のとこはコアメンバー3名、あとは業務委託やアルバイトでまわしている小規模な会社です。そのため基本的に私がそばにいる人を全て目利きして雇っていて、仕事に関して真摯な姿勢な人ばかりだと思っています。彼らがサボるとか全然考えていません。それは経営者としてはヌケヌケなんだと思いますが、まぁ、今の所問題なさそうです。 幸い良いお客様にも恵まれているのと、プログラマーのトレーニングを行うなど受託開発だけの事業ではないこともあり、仕事内容の調整はバランスできていると思います。

自分とこはそういう事情もあってある程度の余裕*1を確保しながら進められている（はず）だと思っていて、前回の記事にあったような私の思う*2成長路線に乗るように日々努力してもらっています。

実際に弊社2年目の社員が他社の2年目の社員に得意分野の指導をすることもできる（そして、2年目だと気づかれない）ので、初年度経験値を積ませたことがしっかり根付いていて、本当に良かったなぁと思っています。もちろん社員の素養があったからこそ実現できたのだろうということも多分にあります。

今の所弊社がヌルい方針である程度やれているのは上記のような会社の状況や幾つかの幸運、私自身が立てている方針が重なった結果起きているものだろうと思います*3。規模の大きな会社になれば、人間性のバラツキが起こったり価値観の浸透が揺らいだりするものだと思うので、同じことを実現するのが困難になるでしょう。

理想はありますが簡単なことではないと思うので、少しずつ近づいて行きたいです。一番ダメなのは会社が無くなって彼らが路頭に迷うことなので、メンバーの成長が会社の成長を引き起こしてくれるような流れをしっかりと作りたいものですね。

コメントいただいて考えたこと

成長について

そもそも「成長」とはなんだろうなと改めて考えさせていただきました。自分の書いていた文脈だと、プログラマーの場合であればより品質の高いコードを短時間に書けるようになることだと思っています。品質とは仕様変更に強い保守性の高さと、読む人へのわかりやすさで考えられるでしょうか。

もう少し大きな意味で考えると 「課題を解決する為の方法の引き出しを増やし（編み出せるでもいいですし、学習して会得するでもいいです）、それらを適切に使い分けることでより効果的な対応ができるようになること」 かなぁ。長い。

成長すれば判断が適切になる気がします。その結果はやくなるし、正確になるはず。

長時間残業へのストレス耐性を持つことや、会社内の人間関係を上手く利用できるというようなことは成長とは思っていません。集中力が長く持続するようになることは成長になる気がするので、ストレス耐性と少し矛盾するかもしれませんね。

仕事量と成長について

自分の場合、仕事ではなくて自身の作りたいものを丸1年ほど作っていた時間があるのですが、振り返ると仕事しているのと変わりないと思うのですね。ただ、熱中して自分のやりたいことをしているので、かけた時間の長さ、集中力の高さともに半端なかったと思います。書籍も読みまくっていたし、リファクタリングだけで月単位の時間を費やしたこともあります。

沢山仕事していたんですが、余裕はあったんですよ。沢山のことを調べたり試したりしていることをしてて「どうやるのが適切なのか」を探し続けていた時間だったんですね。結果自分の中の哲学がある程度固まった気がします。

これが社会に出た時の私を支えた原体験なので、余裕を持って考えることやより良い方法を考えることが大事になっているんですね。今はそれを会社の中で再現しようとしていて、それはそれで厳しい時もあったりなかったり。

コンフォートゾーン

コンフォートゾーンという言葉を知りました。なるほど。if文をただ埋め込むのは快適な選択肢なのですね。確かにそうかもしれません。成功すると解っている同じことの繰り返しからは離れていくようにした方が良いですよね。

www.lifehacker.jp

記事を読んで思ったのは、私がよく若い方にする「初めてを減らせ」というアドバイスです。誰でも初めてやることは緊張したり神経質になったりして、ちょっとした失敗をしたりするものだと思うんです。ただ、実際に通り抜けてしまうと「あぁ、こんなことか」と思うことって結構あるのではないでしょうか。

例えば少し大きめな飲み会の幹事になることを考えてみてください。お店を決めて電話をかけたり参加者のスケジュールを合わせたり、当日の段取りをしたりなど、やったことがない人にとっては結構なストレスだと思います。でも、一回やるといろいろなことが解って、二度目は少し上手になるし、何度かやるとそれほど神経質にならなくなるでしょう。別にこれは成長ではないような気がしていますが、結果的に物事を上手にこなせるようになるので様々な意味で童貞を卒業しておくのは良いと思います。

おしまいに

驚いたりもしましたが、色々と深まったこともあったので良かったです。

*1:その余裕を成長に全振りするので実際に余裕しゃくしゃくではないです。早くそれでも余裕な会社になりたいです。

*2:文字通り身勝手に「私の思っている」ものです

*3:その代わりと言ってはなんですが、お給料そんなに高く無いです。でもあと何年かしたら結構高い方に行かせてあげたい（願望）

「人は激務を経なければ大きな成長をしない」に対する意見。もしくは不連続な成長をする方法。

はじめに

よく目にしたり耳にすることに「成長するために激務をこなす」とか「追い込まれなければ成長しない」というようなことがありますが、私はこれに関して異なる意見を持っています。このエントリではそれを整理しようと思った次第です。様々意見ありそうですが「私の経験を振り返るとこういう意見にたどり着いているよ」という話です。そして私が人を育てる時の方針はこの考えに立脚しています。

言いたいこと

分類	成長度合い	きっかけ	備考
習熟	低い	同じやり方で同じことを繰り返して結果を出す	要領が良くなって短時間でこなせることを成長と感じている
概念獲得	高い	今までとは違うやり方でより効果的な結果を得る	新しい概念を獲得することで成果の質が大きく変わる

言いたいことはほとんどこの表の通りです。私は大きな成長は新たな概念を獲得することによって起こると思っています。だから、新しい概念を獲得できるような余裕ときっかけを上手に配することで、不連続な成長を生めると信じています*1。

激務の時の多くの人の思考

激務になって追い詰められた時、今までやったことのない方法に手を出せる人は稀です。それができる人はある意味博打打ちでもあるし、強い精神力か鈍感力、もしくは勇気を持っているのかもしれません。多くの人は「知っている確実な方法で成果を出そう」とすると思います。そのため激務が続くと、同じやり方の反復をしようとする傾向が強くなります。

結果、あるやり方に習熟していきます。人間は慣れるとはやくできるようになったり、正確にできるようになったり、ミスが減ります。これももちろん成長したと言えるでしょう。ただし「その程度は成長としては緩やかなものだ」と言うのが私の意見です。

高い成長のために必要な事

より高い成長を求めるには、ある程度の余裕が必要だと考えています。自身が塾考するための時間はもちろんですが、先輩に教えを乞う事（先輩にも余裕がなければもちろんアドバイスをもらう事が出来ませんね）や、書籍を読むなどすることにも余裕が必要です。ごく一部の優れた人は外部からの刺激無しに新しい方法を編み出すでしょう。しかし多くの人は他人や書籍など何がしかの「外部からの刺激」をきっかけに新しいことに気づくのではないでしょうか*2。

私も含めて多くの人は激務に追い詰められると上記のようなことができなくなってしまうようです。つまり何の助けもなく激務に放り込まれるだけでは多くの人は成長できないと考えています。

例

何がしか例示しないと伝わりにくい話をしていると思うので、もう少し具体化を試みます。

プログラミングでポリモーフィズムをうまく使えるようになる話

プログラマの人にしか通じないかもしれないので申し訳ないのですが*3、プログラミングの例がパッと浮かんだのでまずはこれで。Rubyでサンプル書いてしまいますが、他言語の方にも伝わるようにある程度 Rails じゃない感じにしています。また、作業を行っている人はオブジェクト指向について勉強中なものとします。

前提

クラウドソーシングを行うようなアプリを作っていることを想像してください。User、Projectというモデルがあります。

# Userのテーブル（users）に対応したモデル
# すべての人が受注できる能力を持っているが、is_employer が真の人だけは発注もできるとする
class User
  attr_accessor :name  # ユーザの名前が user.name で取得できる
  attr_accessor :is_employer # 真を返す人は発注もできるよう申請をした人
end

# Projectのテーブル（projects）に対応したモデル
class Project   
  def owner
    # projects.owner_id の値からSQLを発行してUserのインスタンスを得るコードがあると思いねぇ。
    # user.is_emplyer が真のユーザが必ず返ってくるはず。
  end
end

そして上記のクラスを表示するような、下記のようなコードが100か所くらい（作為的でごめんなさい。とにかくたくさん使われていると思ってくだされ）。

<div>プロジェクトの発注者: <%=project.owner.name %></div>

仕様の追加

今回新たに「発注者であった人が、発注者の権利を放棄することができる」機能をつけるとします。その際今まで発注者として表示されていた名前の後には全て「（休止中）」と付けます。ただし、受注者のアカウント機能は今までと変わらず残っているので、users テーブルの name カラムを直接書き換えてしまうことはできません。

Userモデルは下記のように変わりました。

# Userのテーブル（users）に対応したモデル
# すべての人が受注できる能力を持っているが、is_employer が真の人だけは発注もできるとする
class User
  attr_accessor :name  # ユーザの名前が user.name で取得できる
  attr_accessor :is_employer # 真を返す人は発注もできる
  attr_accessor :is_retired # is_employerが真の場合にだけ有効。真を返すとこの人は元発注者で、休止中の扱いにする。
end

激務に曝されている人が陥る考え方

先輩に相談しに行って簡単なアドバイスを受けるも、よく分からない概念を調査したり知ったりするコストが大きく思えて、期日に間に合うようには思えず、放棄します。 結果「if文、100個入れる」と判断をします。下記のようなコードのように100か所の変更をする判断です。

<div>プロジェクトの発注者: <%=project.owner.name %><% if project.owner.is_retired %>（休止中）<% end %></div>

1. 影響範囲もかなり広いので、テストも含めて何日かかかると考えて、見積もる。
2. Pull Request を送ると、レビュアーの先輩が時間をかけてレビューする。先輩はこの実装が微妙だとは思うが既に時間をかけて書かれてしまったコードを突き返すわけにもいかず、いくつかの抜け漏れを発見した後「とりあえず大丈夫じゃない？」とマージする。
3. デプロイ後、抜けに何点か対応して安定。
4. 上記のようなことを何回か繰り返して、影響範囲の考え方や、このシステムでの 落とし穴には詳しくなり、なんとなく成長したと思う。

余裕のある人にできそうな方法

先輩に相談しに行って簡単なアドバイスを受けます。ポリモーフィズムという言葉やデコレーターのような言葉を教わり、調査を始めました。書籍なども調べてデザインパターンを確認してみます。 どうやらそれらを使えば根っこの一箇所でうまくやるだけで全てを修正できるとわかりました。

class ReiredEmployer
  def initialize(user) 
    @user = user
  end

  def name
    @user.name + '（休止中）'
  end
end

# Projectのテーブル（projects）に対応したモデル
class Project 
  def owner
    # projects.owner_id の値からSQLを発行してUserのインスタンスを得るコードがあると思いねぇ。
    # user.is_emplyer が真のユーザが必ず返ってくるはず。
    if user.is_retired 
      # is_retired が真なら userをデコレートした`ReiredEmployer`を返す
      RetiredEmployer.new(user)
    else
      user # 通常はuserを返す
    end
  end
end

Viewの変更はありません。

1. 画面の簡単な確認で終わると判断し短期間で達成できると見積もる。
2. Pull Request を送ると、レビュアーがごく少ない変更コードを確認して、素早くマージする（この仕組みなら一箇所のView確認でうまく動くならほとんどがうまくいく想定ができるため）。
3. デプロイ後、抜けなどなく、安定。
4. 以後は同様の変更なら誤り少なく対応できる方法があると知る。以前に比べて確実な対応ができる能力の向上を成長と感じる。

ここでのポイント

前者は「抜け漏れがそもそも存在する可能性を残す方法」を、習熟によって正確さを増すように 頑張る アプローチ。後者は「抜け漏れがそもそも存在しない方法」を新しい概念として獲得するアプローチ。後者の方がはやく正確に作れる概念を身につけられました。 ある程度の余裕があったから、調査したり理解をして今回の仕事に導入もできました。先輩にも余裕があったため、アドバイスも適切に受けられたことでしょう。

言い訳

User#name に Viewの情報である （休止中） を教えてしまうことが気になってしまう人は、何か良さげな例を教えてくだされ。ただ、大事なのはそこじゃないことはわかっていただけるはず。ごめんなさい。

おしまいに

もうちょっと良い例もありそうなんですが、ちょっと力尽きてきたので、これくらいで。 新しい概念を獲得するために、よく考えたり試したりすることこそが大きな成長の鍵だと思います。それは激務だからできることではないと思うのです。なので、成長と激務を並列に並べて表現することには違和感を覚えてしまいます。もちろん、ある種の責任感によって成長が促進されることはあり、それが仕事の中によくあるというのは当然同意しています。

ちなみに今回出したコードの例は、内容を変えてはいますが似たようなものが実際に最近弊社の中でもあった事です。

*1:私が上手に配せるかどうかはまた別問題です。今も試行錯誤を続けています

*2:この気づきは無限の時間があれば、その人も辿り着ける感覚のはずですが、それを大きく短縮させるのに外部の刺激が役に立っていると考えるのが正確な表現だと思います

*3:私のブログをプログラマではない人が読むのは稀なので良いでしょう

量産型の話から思った老齢世代がやってこなかったことのツケ

medium.com

「『（コード）量産型』プログラマを撲滅したい」ですよね？「『量産型プログラマ（ジムみたいな）』を撲滅したい」ではなく。まぁ、いっか。 こちらを拝見して思ったことを書いてみます。

コピペプログラマって現場にそんなにいるんですか？

というのが最初の感想です。今の現場って「コピペはしないほうがいい」と知っている人の方が大多数だと思っていました。私の観測範囲が狭いからかもしれませんが、ガンガン積極的にコピペする人そんなにいない気がするんですよね。なのでこれが問題だという意識は私にはあまりありません。

※ 逆に初学者の人なら、私はコピペでも何でもまず動かして知ることが沢山あると思っています（どんなに綺麗に書かれていても、動かないシステムはダメだと私は思っています）。現場ではこれをやらせませんが、勉強している人はまずやってみるのも大事です。

今の課題って「一定以上の実力を持っている人が少ない」ではないでしょうか

現場の課題はこれだと私は思っています。「良い人いない？」とよく聞かれますし（そしてその要望に合致するような人はなかなかいない）、「Railsのスクールで勉強しました」だけではうまくいっていないのは言わずもがなでしょう。もちろんこの人たちの中に、数年後立派なプログラマーになる人がいる可能性はあります。今の要求には答えられないのかもしれませんが。

どうしてこうなった？

私たち老齢なプログラマ*1がやれなかったことのツケが今の時代に残り続けているのだと思っています。

現場目線では下記のような感じですかね。

1. 「職人だから」のような都合のいい理由をつけて適切な教育を行なってこなかった。
2. 上記のために、人が育つ文化を作ることも、仕組み化をすることもできなかった。
3. 育てるためのマインドやノウハウを持っていないチームばかりになった。

経営者目線ではこうかなぁ。

1. 普通に仕事をするだけで一杯一杯で、社員に余裕を作ることができない。
2. 新規に人を雇うにしても、育てる人材をアサインすることができない。
3. 結果、新人が来ても放置するので育たない。
4. ヘッドハンティングでしか有能な人材を獲得することができない。

ちょっと違う切り口だと、スタートアップのようなビジネスの考え方は「経営者より優秀な人をこそ雇え」なので、既に優秀である人にしか興味はなく、これから優秀になる人に成長時間をジックリ与えるようなことは難しいんですよね。それは事業のスタイルが「短期決戦で総力戦を常に展開する」からです。私が若い頃にはあまりなかった経営方針なのですが、こういう世の中の流れも影響しているでしょう。

もちろん上記は私の経験からの推察なので別の考え方もきっとあると思います。

過去、個人としては現場レベルでどうにかしようとしていて、自分の周りでは人が育つようにしたかったです。下記の話のイメージです。

ms2sato.circlearound.co.jp

ですが、世代としては負っていたはずの義務を怠ってきていたのだろうと感じています。特に今は経営者であって開発者でもあるので、どっち目線で考えても耳が痛いです。

じゃぁ、何をするべきなの？

文化を作ることじゃないでしょうかね。チームで仕事しながらメンバーが育っていくことが素晴らしいと思える文化。経営者ならそれを推進して社員に育てる余裕、育つ余裕を作ってあげることでしょうし、現場なら、まだ育っていない人のモチベーションを下げずに成長してもらえるようなフォローアップの環境とか。

さらっと書いていますがそんなに簡単ではないと思います。育てることは投資なので、短期的利益を目指したらできません。投資の回収見込みが立たなくてもできません。このケースだと、毎年の売上を至上命題にしていたらできないですし、入社した方が3年で辞めてしまうような会社でもできないんですよね。

つまり経営者としては長く居ついてもらえる会社を目指すことが最初のアクションになるはずです。それと「人を育てられる人」への評価を高くする必要があります。これでお給金を高くしようとか残業せずに帰れるようにしようとか考え出すと、もはや針に糸を通すような感じの話になるんじゃないでしょうか。私もまだまだ挑戦中で、十分なところまではたどり着いていないです。育てる時間に低下する売上をカバーするのに助成金探してみたりとか、ホント泥臭いことやっていると思います*2。

あとは育てるのを外注するのも短期目線では良いかもしれません。ただし、あまり外に依存してしまうと社内の文化やメンバーに馴染めない形ができてしまうので、特効薬として使うようなイメージでしょうか。チームビルディングと教育は繋がっていると私は思う為、異質すぎるものを導入するとかえってうまくいかないこともありそうです。

弊社だとトレーニングの事業をやっている都合上、人を育てるノウハウは持っていますし、先輩が後輩をトレーニングすることは本業の修行にもなるので、やるべきことだと位置付けることができます。あとはもう少し効率良くできたらいいなぁなどと悩む日々です。

おしまいに

ダメだダメだという前に、やれることをやっていきましょうよ。

*1:35超えたら定年と言われますからね（笑）40の私なんてもう定年退職なのに嘱託社員で働くお爺さんみたいなものです

*2:注意：助成金も売上にはカウントされないので、やはり短期的な成績としては下がってしまうことを受け入れないといけません。少なくとも会社が潰れたり、余裕が無くなる事を回避する手段としては有効だと思っています

確からしい内容を共有したいのです。できれば喧嘩せずに。

qiita.com 年明け早々こちらの記事がかなりバズっていました。記事の内容自体が「前提を共有せずに理由なしに斬って捨てる」だったのと、タイトルが「初級者のため」と付けながら内容が「中級者になろうとしている、もしくはそれ以上向け」であった為に、読んだ方の期待値との落差がかなり激しいものでした。

qiita.com

その後、私が上記の記事を書いたのですが、その裏側で私が考えていた事を記しておこうと思います。qiitaは技術を行う人同士が研鑽を積むために利用するべきと思うのと、こっちならあまり人目に触れすぎない安心感があるのでエモい内容はここに書いておくことにしました。

私の考えた事

私の見た目に、元記事は一定の良い内容が含まれる反面、通常の開発の想定では逆に落とし穴になること（ex. 全てをアロー演算子で書く）が項目に挙がっていたり、for文についての内容があまり推奨できるものでは無かったりするなど、「概ね良いが、良くないところも混ざっている」内容だと感じました。

普段こういう記事についてはそっ閉じして無かった事になるのですが、はてなブックマークを見ていると気になるものがあったんですね。ある種の諦めの混ざったような「JavaScript自体が難しい」という発言や「多数違反しているけれど、やったらまずいのか」という困惑です。ある程度修行した人なら「どんな前提ならどこまでを信じて良くて、どこまでが良くないか」がわかるのだと思います。

プログラミングは難しいかもしれないけれど、人が勝手に決めたルールに従おうとして苦労する必要はないし（意義のあるルールならもちろん従うべきですし、チームのルールは大事にすべきです）、一喜一憂する必要などないと思います。混乱したり諦めてしまうようなことが私はあまり好きではありません。そう促す外部の存在も好きではありません（この辺りの話とリンクしそうですね）。

そして嫌だ嫌だと言う前に何か行動するのが良いと思うので、言葉を発する前に何かをしようと決めました。

マサカリ？

こういう時に力のある人が「それは違うよ！」するのを マサカリを投げる （参考 ）と言ったりしますが、もともと何かを否定し合う関係って好きじゃないので、否定記事を書く気はありませんでした（私が権威も力も別にないということも、もちろんあります）。物事を好ましい状態に持っていく手段は、なにも否定したり戦ったりすることだけじゃないと考えたいからです。 そうでなければ何でも喧嘩したり権威に訴えたりしないと実現しない世の中になって、とっても面倒だと私は思うのです。

あと、年始から技術ライターさんのツイートに対して何か殺伐としていたりして、こんな心境だったんですね。

なんか年明けから殺伐としているなぁ。仲良くしようよ〜。

— 佐藤正志 (@ms2sato) January 3, 2017

なので補足記事を書きました

はてブを見るとかなり多くのコメントに「理由がない」を挙げています。ここに乗っかると色々とやれることがありそうに見えてきました。この時の私が考えたことは以下です。

• すでに私が背景を納得できているものに関しては噛み砕いた理由を示す。禁止ではなく判断の指針を示す。
• 可能ならより深い勉強のための参照リンクやキーワードを入れる（リンク先への感謝を忘れずに）。
• 私が別の考えをしているものや前提が曖昧なものには疑問を投げかけるか放置。無理に筆者に寄り添うことはしない。

あとは博識な方々が有効な情報をくださるだろうと考えていました。結果色々とご意見頂いて、ブラッシュアップしながら進めることができたと思います。元記事の作者さんは存じあげなかったので、どのような反応をされるかわかりませんでしたが、大変好意的に受け入れてくれたので助かりました。ありがとうございます。

ちなみに元記事の作者さんが「解決編」を用意している可能性があったのですが、コメントからそういう想定では無いと伺えたので、この行動に一定の自信を持って進めることができました。

答えを教える？

こういった文書について「考えさせずに答えを教える行為だ」と思う方がいるかもしれません。ただ、私は「何について考えるべきか」を重んじたいです。今回の内容の多くは「JavaScriptの処理系が昔から抱えている意外な落とし穴」や「最新に追いつくための手法」なので、一回どこかで目にして「あぁ、そういうことあるんだね」くらいで十分だと思っています。落とし穴が気になるならlintなりで抑制できることもあるでしょう。lint使うにもAtomのプラグイン入れるだけでも可能なので手軽さ優先ならこれでも良いはずです。

本当に考えることが必要なのは、概念の獲得だと思います。どう設計するとバグが少なくできるかとか、処理を分割する際にはどう気をつけると共通化しやすい処理になるかとか、抽象度が高い処理とはどのようなものかとか、バグの潰しやすいデバッグの方法はどういうことかとか。そういったことを考えるために、時間と脳のリソースを確保しておくべきです。

あくまで「何をよく考えるべきか」という切り口ですので、全く理解せずに記事を鵜呑みにせよと言っているわけではないとご理解ください。

記事・タイトルの書き方

よく記事のタイトルはバズらせるようにワードを仕込んだり表現を工夫するように提示されています。ただ、読者の期待値と食い違い過ぎるタイトルに価値があるのかは疑問です。今回のエントリも「中級者になりたい人向け」などとなっていたら、ここまで脊髄反射的にブックマークされることもなかったはずです。返信コメントも別の形になったことでしょう。 もしくは最初に前提とする読者像を書くべきだったかもしれませんね。

初級者という言葉

私が考えるのはこんな感じかな？上の方はどこまでも上があるでしょうが、概ねこんな感じかと思っています。

• 初心者: まだ内容が良くわかっていない。提示されている内容を鵜呑みにしてしまったり、本の内容を写してみたり、とにかく試行錯誤しながら何かやっている段階。
• 初級者: より良い方法はわからなくても、とりあえず自分の望む動くものが（仕様を自分で調整したりしながら）ある程度作れる。「何をしたら良いか」が判り始めている。
• 中級者: 基本的なことは身について、より良い方法を求めている。他人から依頼されたり、仕様を外から決められたものもある程度作れる。哲学を獲得しつつある。
• 上級者: ある程度自分なりの哲学を持ってメリット・デメリットを判断しながら進めることができ、外部からの怪情報に惑わされることはあまり無くなる。周囲の他の人が気づいていない考え方に気づいたりする。

その観点で行くと、元記事は「より良い方法を求めている」に近いことをやっていると思うので、中級者に思えるのです。

おしまいに

自分で率先して記事を書いていくよりも、誰かが投げかけたものにレスポンスする方がうまくできそうな気がするので、こういうこともたまにはやってみようと思います。できれば喧嘩せずにやっていきたいものです。