島までは遠い

佐藤正志@サークルアラウンドのことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる予定。しばらくは工事中。

何度も書き写すことに意味があるのか。もしくは理解の為に必要な要素について。

f:id:ms2sato:20180217003025j:plain

はじめに

こちらへのアンサー。なんだか長くなってしまう感じだったのでTwitterでは難しそうと考えて、一旦場所を変えさせてもらいました。ちなみに、この一言で私は色々な想いを巡らすことができたので、とても有難い言葉であったと先に感謝をさせてください。興味深い問いをありがとうございました。

この文脈において「理解する」とはどういうことか

まず前提として、私はプログラミングを学ぶ時に「理解する」というアプローチを重んじています。そうするとまず私の思う「理解」についてお伝えするのが最初に必要だと思いました。改めて考えた時、以下の二つの組み合わせではないかと今は結論しました。

  • 組み立てられた論理を脳に写像できている
  • 概念を合点している

特にプログラミング言語やフレームワークは人が作った道具なので、作者の思う「論理を表現しやすい構造」を持っていると考えています。つまり、少なくとも作者がある時点で考えた一定の整合性の下に成り立っているはずです(もちろん破綻している何かもあるのでしょうが、今は目をつぶってください)。

私たちが学ぶ時にすることは、この彼らが出力した論理構造を逆に入力しているのだと思えます。その結果「この道具はxxxの為に使う道具だ」とか「xxxという複雑なものを意識しない為に隠しているのだ」などと整理する事になります。逆に考えると、整理した結果は作者がそれを作成した動機に近いものとなるはずです。

「理解する」とはこの「作者が表現しようとしていた概念や、課題解決の動機や仕組みを脳に写像する」ことではないかと思われます。

無心に書き写す事によって論理を写像できるのか

私の答えは「ごく一部の人にとってはYES。その他多くの人にとってはNO」ではなかろうかと推察しています。これは統計を取ったわけではないですが、私が出会ったプログラマーの卵や、現場のプログラマーを見ていて感じた事です。

「何度も書き写す事で共通した部分に気づく」という事自体はパターンマッチングして一致している部分を感じ取る事と考えて良いと思いますが、それは上記のような「作者の意図を脳に写像する事にはならない」と、私の頭では整理されています。パターンマッチングでは浅いという表現でも通じる人がいるかもしれません。

物事の考え方に、演繹法・帰納法のようなものがありますが、理解する時に必要なのは演繹法の脳であり、帰納法の脳では無さそうだと感じています。繰り返しの果てに何かに気づく時でも、どこかで立ち止まって演繹して理解に至っているのではないでしょうか。

繰り返しで帰納的に獲得している場合の例

私の会社のトレーニングでこのことに近い例が過去にあったのでちょっと出してみます。最近ではRubyやRailsの基礎を学ぶ時に、まず動画教材( 無料版がCodingCastで見れます。解説の動画を全部カットしたので、ScreenCastを真似するものです。 )を提供して予習してもらうことが多くなってきました。この動画を本格的なトレーニングの前に提供したりすると、何パターンかのアプローチをしてくださいますが「時間のある時に何度も繰り返し見る」という形で行ってくださる方が一定数います。

そして、実際にトレーニングに入る際には何かを作ってもらうという事になります。通り一遍の仕様だとパターンマッチングの脳でクリアしてくれます(かなり優秀な場合も多いです。記憶力で素早く書けるんですね)。

少しずつ意地悪な*1実装をお願いすると「システムの中で何と何が繋がっているか」が問われ始めます。例えば、あるところのメソッド名や変数名をあえて変えてもらうようにお願いしたりもします。途端にエラーが出て、それがスッと解消できるかどうかというところ一つでも、理解の深さがわかります。ただ、エラーメッセージの読みが鋭い場合もあるし、概念理解で「あっちを変えるの忘れた」と気づく場合もあるので、その動機が行動からわからない場合もありますけれども。 パターンで脳に入ってしまっている人は、そういう時のエラー解消に大変時間がかかります。一箇所変えた時に、何が影響を受けるのかが整理できていないのですね。論理構造の写像がまだできていない為だと私は考えています。

パターン化されているタイプの人は多くの場合、こういうエラー対応に弱いようです。トレーニングではパターンでインプットされてしまったものを、エラー対応や実装を通じて論理構造を考えていただき、確からしい理解に辿り着いてもらおうとします。

では正しい理解をなるべく早く獲得するには

これを考えるには改めて先の列挙に戻ります。

  • 組み立てられた論理を脳に写像できている
  • 概念を合点している

前者について。コードの繋がりを理解することをしていくことですね。全てのステップを一行1行追わなくても、例えば

  1. 受け取った通信の内容はroutesに渡されてControllerとActionが判断される
  2. 判断されたControllerのActionがコールされる。
  3. 何も指定しなければaction名に対応したViewがレンダリングに使われる

というような、コードの呼ばれていく大まかな繋がりがわかるだけでもかなりのことに対応できます。

実は後者はとても難しい場合が多いです。それは使い方だけを見たとしても「それがどんな概念なのか」を昇華するにはかなりの経験や苦労を要する場合が多いからです。私自身も概念レベルまで何でもかんでも消化できているのかと問われたらNOと言わざるを得ません。ただ、この部分はたくさんの経験を要すると割り切って、既に獲得している他者からインストールされるのも近道だと思っています。実はこの辺りが先輩に教わることの価値だと思いますし、経験値を継承して大きく加速できるポイントの一つであると思います。例えばMVCという概念を考えた時、下記のようなポイントがあると思いますが、最初からこれに合点した人は物凄くセンスがあるのではないでしょうか。そして、これらはより良いコードを書くには大事ですが、そうでないならMUSTではありません。前者の時点できっと動くコードは書けているはずだからです。

  • Viewという表示を司る部分の変更が、大切なロジックの根幹であるModelへ影響する事をできるだけ防いでいる。
  • Controller/View はWEBの事を知っている層であるが、Modelはそれに依存しない。これによってModelだけをWEBのシステムではない部分でも呼び出したりすることが容易になる。

これくらいが良いのでは?

  • 一回真似してみて動くものを手に入れる。
  • 真似した内容をうまくアレンジしながら今度は自分のものを作る or 上記で出来上がったものを改造しながら理解を深める。
  • 難しいことがあったら文書のコンテンツを読んでみたり、最初に動かせたサンプルを弄ったりして確認する。
  • もしも自分でどんどん作れそうだと思ったら、立ち止まらずに進む。
    • コースに乗る必要はなくて、あとで分岐点に戻っても良いじゃないですか。ワクワクしてる時にガンガンやりましょうよ。
  • 次の壁に当たるので教材でも書籍でも人でも何かに当たって新しい情報を得る。
  • 上記を繰り返す。

真似を繰り返すのが回数という数字になって達成感を得てしまうのはソシャゲで何回もタップすると何か出てくるとか、レベルが上がるようなのと似ている感覚ではないでしょうか。本質的に得るべきものは得られてないかもしれない、と疑った方が良いです。

おしまいに

関連してすごく長く続くので一回バッサリカットしました。終わらん笑

既にかなり長くなったのでこのあたりでキーボードを打つのをやめますが、私が考えている「無心に繰り返すことにはあまり意味がない」ということの根拠とか考えをもう少し丁寧に表現してみました。

ちなみに、ツイートの方でも書いていますが、実は繰り返しが本当に必要な人が一定数存在するんですね。このケースはおそらく明文化することができないだけで、何かの形で感じ取ってやれている気がします。繰り返すことでパターンマッチングではないそれが作られるイメージ。私はこのタイプの人を理解してあげることがとても苦手だったりしています。まだまだ修行が足りませんね。

*1:とは言え実際によくありがちな事をやるわけですが

実家のPCデポの解約までの話

f:id:ms2sato:20180214000245j:plain 放っておくと記憶が風化してしまうのでとにかく書いておく。

はじまり

事の起こりは年末年始に実家に帰った時のこと。自宅のインターネットの契約が変わったことは前に伝えられていたのだけれども、相手が悪いことに気づいた。

調べると二年前からPCデポに乗り換えてしまっていたらしい。以前この会社には注意するように伝えていたのだけれども、まさかそうなっていたとは。親父はPCに詳しかったりはしないけれど、営業職でずっと過ごしてきたので契約や商売には敏感だし、そういうことは無いだろうと思っていたがそうもいかなかったようだ。契約内容など諸々確認すると、なるほど噂通りの対応をする会社であるとわかった。

さすがに年明け一日二日に連絡してもどうかと思ったので、その間に家にあった資料を全部写真に収めたり、世間の動向を調べたり(以前あれだけ叩かれたのに、まだほぼ変わらずに営業しているっぽいので、面の皮の厚いことだと思ったが)して、色々と備えた。

ゴールを決める

まず、両親にはどういう形が良いかを相談して合わせた。これが私のゴールになる。

  • 家にインターネットは不要
    • 近所のインターネットカフェで資料を作って印刷している(たまにしか必要ないので、ずいぶん前からこの運用とのこと。今では店に慣れて顔馴染みなのでその方が楽だということだった)。
  • 電話も元の通り使えれば良い
  • 一瞬でもテレビが見れない状態になるのは嫌(テレビ大好き母談)

下準備

まず考えたのが、以前のプロバイダに全戻しするということ。その為に以前のプロバイダのサポートへ電話した。そこでわかったことが下記、驚愕の事実である。

  • NTTの光回線とプロバイダを分けずに、一緒になっている契約をしている場合、解約すると電話番号が変わってしまう。
  • 番号を変えない為には一度アナログ回線に戻し、光が必要ならさらにそこから再契約しないといけない。
  • 今はそれしか方法がないらしい。

結構な人が今って一緒にしているのではなかろうか。安いから乗り換えるだろうがそういうデメリットがあるらしい。

ただ、冷静になって考えると、実家にはインターネットも不要なのだし、そもそも光回線など不要では?という考え方があると気づいた。もしも必要になったらWimaxなどを導入すれば全く問題ないことは以前確認済みの地域でもある。

作戦

というわけで以下のように進めることを決定し、両親とも打ち合わせた。

  • テレビは先に光回線から外してアンテナ繋ぎかえの工事をする。
  • 電話回線はその後アナログに戻す。光から脱却。
  • インターネットは無くなるので全て綺麗さっぱり解約。特に次を決めることもしない。

過去に全て戻る気がするが、顧客たる両親の幸せを考えるとこれが一番良い考え方だと至った。

というわけでテレビは早速両親に手配させ、アンテナつなぎ変えをさせる。どうやら電気屋によると最近こういうケースが多いらしい。 なんとなくわかる。若い人が出て行くタイプの都市なので、残された老人には光回線など不要なのだろう。本当はこの時点で電話回線のアナログかもしてしまいたかったのだが、PCデポ側からやらないとダメだとわかり、全てを決めに行くしかないと至った。

繋がらない電話

そういった諸々の準備をしてから本丸のPCデポへ電話。 1回目は繋がって、色々と顛末を伝えると、別の部署から電話があると言う。それを待つことにしたが、平日の昼間にかけてしまったので返電を取ることができなかった。それから暫く音信不通だったので、こちらからまたタイミングを見てかけたところ、同様に電話を待てとのこと。その日11時までオフィスで待機していたが電話は来なかった。

その次の日朝にかかってきても、仕事の最中で電話を取ることはできず、結果その晩に再度かかってきた。

電話での話し合い

おそらくこういうトラブル的なことに対応する担当の方なのだろう。控えめな口調でこちらを伺うように話す人だった。こちらも特に感情をこめることはなく、静かに趣旨を確認して進める。

最初は通り一遍の解約料金を計算され提示されたが「エスカレーションされているはずの内容についてはどう考えるのか?」という形でこちらの主張を伝えた。

  • 父は新しく買ったPCが家のインターネットに接続できなかったので相談に行っただけだった。そして、自分の家にネットワークがあることくらいは話せる程度に父はわかっているはず。
  • PCデポ側にインターネットを任せるように言われてそれに従った。
  • 家には一台しかPCが無いのに、3台サポートする契約をさせられた。
  • iPadはいらないと言ったのに「とにかく持って帰ってくれ」と言われて持たされた(結局一度箱は開けたが、すぐ閉じた様子)。

こちらとしては「不当に高い契約を誘導されて契約させられている」という点を主張。また、私も電話口の担当者も当事者では無いため「確からしい落とし所を一緒に探る」という形で合意を作った。彼も私も当事者への説明義務があるものの、一方的に自身の主張を通せる立場では無いのだ。

そして落とし所を以下のように決めた。

  • サポートサービスの解約料金は一台分の契約のものと同額にする
  • そのほかの解約料は全て無料とする。

訪問

電話のあとE-mailのやり取りで訪問の予約を取った。必要な返却物を準備して店舗へ行く。最初に電話の内容がエスカレーションされていないと思われることはあったが、その旨伝えると確認されたらしく全て滞りなく済んだ。電話に関してだけはNTT経由で連絡が来るとのことで両親が対応することにした。

先日それも済んだ旨が伝わってきたので全てことなきを得たと思う。

おしまいに

私は彼らのサービス自体がひどくまずいとは思っていません。ただし解約料金については別ですし、契約のやり方が顧客に寄り添っていないのはよろしくないと感じています。また、自身が応援していない企業のサービスを使うのは、結果的に加担していることと同じだと思っているので、今後も応援したくない会社のサービスは使わないようにしていきたいです。

極論応援されない会社はなくなった方が良いのです。自社がちゃんと顧客から(たとえ全ての方からではなくても)愛していただけるように頑張ろうと改めて思った次第です。

オッサンが吠えてもいいイベントがあったので吠えてきました

f:id:ms2sato:20180210233624p:plain

peraichi.connpass.com

こんなイベントがあって、オッサンのLT募集していたのでやらせていただいてきました。

5分LTと聞いていたので「突っ走って5分」くらいで仕上げて行ったら、まさかの質疑含めて10分枠。つまり5分で終わると5分質問攻めという企画らしい。みなさん10分終了狙いの様子なんですね。というわけで、自己紹介をかなり長めに紹介して(自己紹介だけでかなりいける口ですし、いい感じにみなさん盛り上げてくれたので助かりました)。残り5分で走り切りました。

ビアバッシュなのもあって現場ではウケ狙いで盛った言い方をしてしまったり、言いたいことが伝えられたのかあんまり自信が無くなっているので、文章で補足していこうという次第です。資料は下記。

speakerdeck.com

  • エンジニアとして生きる時に生きやすいのはやはり技術がある程度シッカリしていること。
  • 熱中できるものを大切にしよう。
  • 熱中できるものがまだない人は、たくさんの体験をしていこう。そして、心の動いたことを大切にして、少しずつそれに向かえるようにしていくこと(このへんウケ狙いに走り過ぎてちゃんと言えてなかった。反省)。
  • 成長が鈍化した時は、多分新しい哲学を手に入れることでもう一段登れる。
    • 鈍化したと感じるのは世界が狭いためにルーチンになったのと近い。枠を広げないともう一つ上が見えない。
  • 哲学を手に入れる方法はいくつもあるが、もしも師匠的な人がいるなら背中を追うのが最も良い。
    • その人が鍛えてくれる気持ちのある人なら、ガッツリ食いついて全部啜るくらいで良い。
    • それくらい鍛えてくれる人はこの業界で稀有なんだと思う。出会えたら奇跡。師弟関係最高。
  • 人間は変わる。他人のコードを読むのが大嫌いだった私でも、今は毎日喜んで読んでいる。
  • 人間は変わる。だから今の自分を基準に将来の自分を悲観することにはあまり意味がない。

蛇の足

自分の場合、20代に作った技術貯金をベースにフラフラと社会に寄生していた時期があり(世捨て人とか自由人とかそういう感じが近いです。山奥にこもって皿焼いてる陶芸家とかも近そう)、30代半ばで起業してから方向性が初めて定まって(遅かったねぇ。仕方ないけれど)、今は目標に向かって一歩ずつ進みたいと思っているところです。

ただ、やはり元々のユルユル思想から抜けることはできず、会社の中身も色々と緩いですし(厳しくしたら私が会社嫌いになってしまう為。それでいいのかというツッコミは私の会社なのでお許しください)、私自身の行動も脇が甘かったりするので、メンバーに助けられつつ会社が維持できています。

ちなみに20代の時の技術貯金は今のレベルからしたら本当に大したことのないことです。

ただ、IT業界のオープン化の走りの時期に、当時の組織でLinuxを使ってPerl等を利用してWEBサービスをある程度適切な設計で作れる人がとても少なかったです。しばらくしてJavaが業務用WEBサービスの中心になってきたタイミングでStrutsをベースにしたフレームワークを作るプロジェクトに参加したり、EJBのフレームワーク作成チームのメンバーになれたようなことが最初の技術人生をかなり支えています。それまで独学で熱中してやってきたことが存分に発揮できるフィールドだったんですね。

その頃の私はコードリーディングやデバッグ能力は大したことない癖に、クラス設計やオブジェクトの分割、共通化の目なんかが極端に突出していたタイプです。それを人生のその後の時間を使ってだんだん平均的に慣らしてきたと思います。程々のフレームワークを作る技術など今の世の中を見れば残念ながら大して役に立たないのです。OSSの素晴らしいフレームワークを皆で学ぶことでコストを削減する時代だと思っています。

蛇の足2

弟子の弟子という方にお目にかかれて、私のことを彼がまだ師匠と呼んでくれると知って嬉しかったし、彼もまた師匠と呼ばれるようになっているのは素晴らしいなと感じました。そうやって伝承していくのが良いなと。後から来る人はもっと前の人をブッチギリで追い越して欲しいです。そしたら僕もその人に教わったりしていきたい。

コードレビューの仕方は一定ではないと思っています

f:id:ms2sato:20180113201511j:plain little-hands.hatenablog.com

とても素敵な切り口で好きです! 多分表明されていない文脈として存在していると思うのですが「レビューによって育てる」という目線が強くなっていると感じました。

私はプログラマのトレーニングを生業としつつ、受託の開発にも参加しています。トレーニングは「現役のプロが全てのコードをレビューする」という触れ込みなのでレビューしまくる形になります。受託現場でもコードを書くよりもレビューする立場にあることは多いです(たまにそれがストレスになるくらいです。もっと私にコード書かせて!w)。

同じ私個人ですが、実は上記の二つのパターンでレビューの仕方、アプローチは異なります。

トレーニングの場合(育てたい)

  • 問いかけが中心。
  • 直して欲しい場合には勿論、正しい場合にも理解の確認をする為に問いかけることがある。
  • 考えてもらうきっかけを作ることをレビューの中で意識している。座学で教えらえるのではなくて生の学び。

受託の場合(バランスよく進めたい)

  • 指摘が中心。
  • 今の締め切り感などと合わせて指摘の深さが変わる(「まぁ、いっか」の程度が違う)。レビューの為に開発者が進捗遅延のストレスを感じないようにしたい。
  • こちらが「どうして欲しいか(直して欲しいのか、意見を求めてるのかなど)」を明確に示すことを意識している。曖昧だとレビューの突き返し回数を増やしてしまう。
    • 最近は場合によって「提案PR」をすることもある。コードで示す方が早い時もよくあるので。

共通

  • 相手にあまり冷たく見えるような表現は避けています。文意は明瞭でも、表現方法はある程度考慮します。
    • 「xxxしてください」よりも「xxxにしましょう」的な表現が多い気がします。
  • その為もあって「どうしてもここは大事」というところはあえて無感情な指摘の仕方にすることがあります。
  • 罵倒・嘲笑などはもってのほか(なんか世間にはそういうレビューする人もいる様子なので念のため)。

余談ですが

プログラマにとって、コードレビューの学びの効果は絶大だと思っています。コード品質を上げながら同時にメンバーを成長させることができるとすれば、長期目線だとコードレビューの費用対効果はすこぶる高いのではないでしょうか。

たまにまだこれからなチーム/プロジェクトのコードを見せていただくこともありますが、そういう場合はメンバーに安心感も与えることができるようです。そういう意味でも先達にコードを見てもらえることは大事にした方が良いと思います。もしも見てもらえる人いないチームがあったら、弊社なら声かけもらえれば何かお役に立てるかもしれません(と、ちょっと宣伝)。

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

f:id:ms2sato:20171229205849j:plain

はじめに

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

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

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

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

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

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

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

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

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

f:id:ms2sato:20171229205308j:plain

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チュートリアルに達するまでのステップが不足していると思っているので、そういうところを埋めることをやったりしてます。吠えているだけで何もしてないんじゃ無いですよ、ってことで。