はじめに

（まず忘れないうちに）前回のエントリに関して内部事情に詳しい方から scaffold については誤解があるので訂正をするようにご連絡を戴きました。既に対応済みです。誤った内容を広めてしまうことになり、失礼致しました。

佐藤正志です。普段はてブされるような記事を書いていないので、ブックマークの予想外の多さにハラハラしながら拝見させていただきました。思いの外好意的な内容が多かったので良かったです（メンタル強くないので叩かれまくっていたりしたら数日仕事できなくなってしまいそう）。

「炎上に乗っかった宣伝」と称してくださった方、本当にその通りですね。後半に向けてドンドン自社の活動紹介になっているあたり、どこのセールスマンかと改めて読みなおして思いました。腹黒さが隠せない感じでホントすみません。もちろん腹の中は真っ黒です。

アクセス過多で弊社サーバが午前中落ちていた時間があり、失礼しました。まさかコーポレートサイトのブログにこんなにアクセスが来ることが無いと思っていたのです。慌てて対応させていただきました。「ブログは外部に切り離すほうが良い」と周囲からアドバイス戴きました。確かにそうですね。検討します。

そもそもどの段階で、どのような指導を受けるべきか

当該エントリに反応して書いてくださった方の記事も何件か拝読しております。SideCIの角さんのエントリなど、俯瞰している目線の良記事です。数字に関しても普段あまり意識しにくい点から分析してくださっています。

指導を生業にしているにも関わらず、私も盲目的に指導を受けようとする事には若干抵抗があります。「自分でできるか試してみよう！」というのは成長を志向する人の多くが持っているべき性質だと思うのです。

ただ「それ程に時間を切り詰めなければいけない状況である」ことが理解できれば考えてみようと思っています。

私のところは上記の記事にある中の

「作りたいサービス・アプリみたいな目的がうまれたら、講座」

の「こういった物を作ってみたい！」に対応するものです。

実際に作りたいサービスの開発をしながら学ぶことがモチベーションの維持としても大事なことで、その中で真剣に考えて学べることが数多くあると思うのです。

完全オーダーベースのカスタマイズ型です。

雰囲気としては卒業生紹介である程度伝わる気がします。Vol2 を近いうちに公開予定です。

ちなみに金額感についてよく思うのは
「プログラマーになった人にとっての技術獲得費用 10 万円と、一般人のそれには大きな価値観の差がある」
ということです。プログラマーになれば技術にかけるお金の価値が変わってくるのですが、まだなれていない人にはそれが見えないのです。未来は見えないので、当然のことなのでしょうね。

引用：
受けようと思っている方は、一度落ち着いて、今の自分の状態と見合わせて、考えなおしたほうが良いと思います。

間違いないです。安くない額のお金を支払うのですから、意味があると納得した上で行動されるべきです。

フレームワークの提供しているものと仲良くなること

こちらの記事も良かったです。サラッと読めますが scaffold の感想が「怖い」というのはとても良くわかる心理です。著者の方がその怖さと向き合うために中で何が行われているかを理解していった過程が書かれています。そして言及ありがとうございました。

元々 MVC や SQL に関する理解のあった方の様子なので（はじめてのプログラミングだったわけではない）、この学び方で良いと思います。私自身も似たような流れで理解していった記憶があります。既に実装や概念を理解しているので、このやり方で時間が掛かり過ぎることは無いはずです。

読んでいて私自身の似たような体験を思い出していました。

VisualC++の MFC がそれにあたります。ウィザードで雛形を作ってくれていきなりウィンドウが出たりするのですが、どうカスタマイズしてよいか全くわからず、何か弄るとエラーで落ちるし、継承の仕組みのおかげで関数を呼んでいないのに勝手にどこかの処理が動き出すし、もう何が何やらでした。
結局「C++という言語を理解していないからだ」と感じて、付録の C++入門（角さんの記事で言うペラペラ本）を読んだり似たような処理を書いたりすることから始めると
「MFC はクラスライブラリの一種で、ウィザードが作成してくれているのはその実装クラスの雛形だ」
ということがやっとわかりました。

理解する頃には C++で自前の Windows 用クラスライブラリが作りたくなっていて、オレオレフレームワークを作り続けていた事があります。

そうやって中身を理解していきながら自分で作ってみることで、何が起きているか知るのは良い事だと思います。

どこまで掘り下げるのか

この辺りについて言及されていた方が多かったので、私なりの見解を一つ出させてください。こんな考え方はいかがでしょうか。元記事が Rails の話だったので、あくまで WEB システムの話をさせて下さいね。

掘り下げても掘り下げても「誰かが作ったものを使っている」状態から抜け出せることは殆どありません。フレームワークもライブラリも、言語も誰かが皆のために用意してくれた道具です。
最終的には電流が一定以上流れるか否かというところまで掘り下げられるでしょうが、そこまで意識していたい人は稀でしょう。だとすれば一定のレイヤーを決めて（例えば WEB なら WEB のレイヤー）、そのレイヤーの理解を深めるように舵を取るほうが最初は迷わないと思います。

もう一つの大事なことは、自身で自由に WEB のシステムを作成しようとする時に、このレイヤーの理解が無いと上手にシステムを作っていけないという事です。下の下まで掘り下げても、WEB システムを構築する際にはあまり役に立たないこともありますよね。というわけで、いたずらに抽象度を下げて具体化するべきと提案しているのではないとご理解ください。

「WEB のシステム開発を学ぶ」ということに限って言えば、下記のような概念が把握しやすいものが良いという感覚が私にはあります。

• HTTP のメソッドの種類（最初は GET と POST）
• URL はファイルやディレクトリ構造に対応するものではなくて、サーバに送信される文字列であること（その文字列の解釈がサーバ側の実装に任されていること）
• リクエストパラメータやリクエストボディで情報を送れること
• そして、上記 3 つの組み合わせでサーバサイドの処理を操ることが基本であること

例えば Chrome の開発者ツールの Network タブで「ブラウザからリクエストしている Header」を確認すると下記のように見えると思います。初期はこの「ブラウザの送信と、サーバサイドでそれを受ける口を合わせてあげないといけない」ということが見えやすい方が良いという切り口です。

• Request URL:
  https://www.xxxx.com/\_/chrome/newtab?espv=2&ie=UTF-8
• Request Method:
  GET

さらに「将来 Rails がやりたい」ということも合わせて考えると、ruby でプログラミングできて、bundler や gem の扱いまでステップアップしながら学んで行けるほうが良いと考えました。前回 Sinatra を引き合いに出したのはその為です（先述の概念がベタッと書きやすいイメージ）。私は ruby や Sinatra 推しというわけではなくて、今回の目的に合致していたのが Sinatra だと認識したのでそう表現しました。実際にこれから一歩目を踏み出す方に PHP や JavaScript 等他の言語や環境を薦めることも数多くあります。

そうして最も大切なのは上記のようなことを
「自分は理解していて、その上で思ったように改変していける！うおお！」
と受講した方自身に開眼していただくことです。

また、抽象度を上げるのは「作れる人」になってからで十分ではないでしょうか。

• 抽象的な思考ができるけれど動くシステムを作れない人
• 動くシステムを作れるけれど抽象的な思考ができない人

私は最初に目指すのは後者で良いと思う派です。あくまで「最初の入り口のハードルを低くしたい」のです。プログラミングは特殊技能ではなくて、時間をかけて取り組めば誰でもある程度まで辿り着けると思っています。

あまりに長くなってしまったのでこの辺りで一旦キーボードから手を離そうかと思います。オチはありません。毎度長い話にお付き合いいただきありがとうございました。