プログラミング入門以前

これは昔ダラダラ書いてた怪文書。存在すら忘れていた。

下記の通り、年末年始に『プログラミングに取り組む人間』に関する話題がちょっと盛り上がってて良かった。
これらの盛り上がりについて何か感想文を書こうと思ったら、この怪文書を見つけたので、公開してインターネット空間を汚染する。

https://note.mu/kotofurumiya/n/n31d401fce782

http://kirimin.hatenablog.com/entry/2019/01/04/221132

https://note.mu/fromdusktildawn/n/n1aa62bb8d584

私自身、絶望的にプログラミングに向いてない人間でした。
上のブログに書かれてるような人間で、画面睨みつけてましたから笑

あれね、思考がループしてて実質思考停止してるんですよね。
『…なぜ動かないのか？ロジックは○○だろ？だから、それを実現するためにコードを書いたけど、動かない…なぜ動かないのか？ロジックは○○だ…』
こんな感じ。
さっさとエラーコード読めよ笑
と、思うのですが、そういう発想がそもそも無いんですよ。
自己中心的なんですよね。
エラーメッセージを吐いてるコンピューターとの対話を拒否してる。

絶望的にプログラミングに向いていない私が、次にとった行動はprint文デバッグね。
いや、エラーがメッセージ読めよ笑
ロジックが記述されてるコードをprint文で擬似的にステップ実行（せめてデバッガ使えよ笑）して、ロジックの破綻がどこで発生するのか調べるわけです。
自分にとって都合のよいコミュニケーションの仕方で残念ですが、ようやくコミュニケーションを取る行動ができました。

で、しばらくはprint文デバッグでやっていくのですが、自分側のコードでは問題ないけど（実際はあるんだけどね）ライブラリ側でエラー吐くケースはキツい。print文を仕込もうにも、そもそもライブラリがどこにインストールされてるかも知らないし笑
そもそも、どのライブラリが悪さしてるのかすら知らない。
まあ、使い方間違ってる自分が悪いんだけどね。

で、どうにかしてprint文デバッグする方法はないかといろいろググります。
絶望的にプログラミングに向いてない人がやりがちですよね、無駄に難しい解き方を見つけようとするムダな行動。
で、その過程でデバッグ用のライブラリとか見つけるんだけど、英語まともに読めないし、ライブラリの使い方学ぶの億劫だ、って無視するわけです。

しばらく調べても見つからねえ…ってなるので、ライブラリを使うのやめようとなります。
いや、エラーメッセージ読めよ笑

そう、ここでようやくエラーメッセージを読むのです。
だって、それ以外情報がないから。

まあ、でも読んでもよく分からない。

例えば、ライブラリの処理を呼び出すときに使ってる引数が間違ってるから、芋づる式におかしくなって、ライブラリ側でエラー吐いてる。とする。

でも、気がつくわけがない。

『引数2つを想定してるのに、1つしか渡してない？どういうこと？知らんよ。このライブラリ、クソだな』

って、そのライブラリと似たことができるライブラリを探したりするわけです（絶望的にプログラミングに向いてない人間のムダ行動）

もうね、自我が無いんだよね。だから思い通りに動かなくてイライラする。
他責・自己中心的な振る舞いを客観視して欲しい。
…と、過去の私に伝えたい。

たくさんテスト書かれてるライブラリと、絶望的にプログラミングに向いてない自分が書いたテスト無しのプログラム、どっちがバグを含んでそうかと、ちょっと考えれば、自分のコードの方がバグ含んでるだろ、と分かるはず。

チームギークという本に『HRTの原則』ってのがありますが、これは『謙虚・尊敬・信頼』の英単語の頭文字を取ったヤツですな。

謙虚は、自我の目覚めで、他者を認知することです。（新興宗教っぽい）

『コードは書いたとおりにしか動かない』といった高尚なありがたい言葉では、絶望的にプログラミングに向いてない人間の傲慢さを打ち砕けないと思っています。

『絶望的にプログラミングに向いてない人間の書いたコードはクソだし、コードが思い通りに動かなかったのはお前は絶望的にプログラミングに向いていない人間で、お前の書いたコードがクソだったから』って感じの強めな自戒の念を唱え続けると良いのかなと思います。

でも、他人に向けてはダメです。

自分対する批判の目を向けてばかりだとプログラミングが嫌になるので、自己成長に対して称賛を送る行為も積極的に行うと良いでしょう。

====== 本文 ======

最近、プログラミングに関わる人が増えてますね。
Twitter上で『#駆け出しエンジニアと繋がりたい』とハッシュタグを付けて呟いてるエンジニアやっていきな人たちが日々増えてる印象です。

プログラミングが義務教育化しますし、これからどんどんプログラミング人口が増えてゆくことでしょう。
素晴らしいですね。

プログラミングをやっていく理由は人それぞれ。
フリーランスになって年収をあげたい、自分でサービスを作って起業したい、なんとなく将来が不安だから、競技プログラミングで名をあげたい、義務教育化するので親として知っておきたい、非エンジニア職だけどエンジニアと対話する機会増えたから仕事に支障をきたさないように…他にもたくさんあるでしょう。

どんな動機であれ、何かに取り組むことは良いことです。

プログラミングをやっていく心構えや、プログラミングで何ができるのか、といった点をダラダラ書いていきます。

プログラミングは難しいモノだと諦める

いきなり面食らわせるようで申し訳ないのですが、プログラミングは難しいです。
RubyやPythonといった比較的使うのが容易なプログラミング言語でも、プログラミングという世界観に慣れるまでが大変です。
やっと、世界観に慣れたと思ったら、データベースだの、フレームワークだの、MVCだの、オブジェクト指向だの、コンテナだの、オーケストレーションだの、カオスエンジニアリング…よく分からない単語が色々出てきます。

で、実際に手を動かして、ちょっとした簡単なスマホアプリやWebアプリでも作ってみると分かると思いますが、まあーよく分からない。
自分で作りたいモノは分かってるけど、それをどうやって書けばいいか分からない…と不甲斐ない自分にイライラするはずです。
そもそも環境構築すらマトモにできないなんてこともザラです。
『Twitterの○○さんが、RailsだったらWebサービスなんかサクッと作れるって言ってたけど、全然できねえよ(泣)』と嘆くはずです。
ほんと、大変なんですって笑

先ほどから難しいだの大変だのと言ってますけど、無闇に脅かしたいわけではないのです。
『プログラミングは難しいものだ』と良い意味で諦めてほしいです笑
気長に取り組んで欲しいのです。

中にはプログラミング言語でハックするために生まれてきたような人がいて、こういう人は無経験だったとしてもあっという間にモノにして、業務を効率化するツールを作ったりして、github（分からない人はソフトとかを世界中の人に共有するWebサービス、ってくらいの理解でとりあえずOKです）とかで公開しちゃったりします。
まあ、こういう人ってどんな分野にもいますし、彼らに嫉妬しても仕方ないというか…笑
嫉妬を糧にやっていける人はそれで構わないのですが、他者との比較で自分自身に発破をかけるようなスタンスだと『あの人はあんなにできるのに私は全然ダメだ』みたいな負のループに陥りがちです。（もちろん、悔しさ駆動で上手くヒトもいます）

プログラミングを嫌いにならない付き合い方を見つけられると最高なんですよね。
これはプログラミング以外の、楽器やら、将棋やら…あらゆる学習対象にも通じる話だと思います。

短期間でそれなりに書けるようになりたいとか、GAFAで働きたい！となると、当然ですが時間あたりの学習量が増えます。
結果的に『詰め込み』という学習体験になってしまうかもしれませんし、それによって学習対象が嫌いになる可能性もあります。

そもそも『詰め込み』にならないようにやってくださいって話になります。

・目的を明確にする
・現状との差分を明確にする
・差分を埋めるためにやるべきことを計画する
・嫌いにならないように『無理』をできるだけ排除する

自分に合った学び方を知る

初学者はプログラムの性質やアプリ開発の生態系を知る時間を作るとベターと思っています。

プログラミング初心者に対するアドバイスでよく目にするのが『プログラミングの勉強をチマチマやってないで、作りたいものを作ろう。作る過程で必要なことは学べるから』というモノです。
私自身もこの方針は良いと思っています。
全然興味のないシステムを作るより、自分がほしいと思う、興味のあるシステムを作る方が楽しいですから。

一方で、プログラムの性質やアプリ開発の生態系を知っておくと、プログラミングの習得時間は短縮されると思っています。

例えば…

• プログラムでどんなことが実現できるのか
• プログラムはどんなことが得意で、どんなことが苦手なのか
• スマホアプリはどのようなパーツから構成されるのか
• WEBアプリはどのようなパーツから構成されるのか
• 自分でアプリ開発して公開するまでにはどんなことが必要になるのか
• ネットで通信するとはどういうことなのか
• ネットで通信するとき、例えば個人情報はどのようにして保護されてるのか
• パソコンはどのような仕組みで動いてるのか

あくまで一例ですし、他にも挙げだしたらキリがないのですが…このようなことを理解できると、なんとなくRailsでWEBアプリを作るより、Railsとはどんなことをするモノなのか、Railsで作るWEBアプリはそもそもどんなことができるのか、WEBアプリとプログラミングとの関係はなんなのか、といったことを理解して作れるようになると、不測の事態が起きたときに思考停止状態に陥らなくなります。
思考停止してお先真っ暗な状態になると、モチベーションは急激に落ちます。
結果的にプログラミングが嫌いになります。

なにか問題が起きたとき、メンターをつけて解決するという手は有効です。

一方で、自分の頭で考えて問題解決することも大事です。
仮に自己解決できなかったとしても、問題の状況を他者に共有するためには、自分の行ってることや自分が考えたことに対する理解が必要です。

共有される側としても、エラー画面を見せて『分からないです』と言われるより、どういう状況で発生したのか、どういう挙動が望ましいのか、問題に対してどのような仮説を立てて調査を実施したのか、となるべく詳細な情報を共有してもらったほうが問題解決へのアタリがつけやすくなりますし、問題を整理する過程でエラーになる原因が分かることもあります。

また、プログラミングや、周辺領域の原理がある程度分かってると『Railsから入門してみたけど、やっぱ機械学習やりたいからPythonやろうー』と思ったときにスンナリ転向できますし、Golangがイケてるからマイクロサービス作ったろ、と思ったときにもスンナリ転向できます。

そんなわけで、座学も大事だし、実践も大事と思うのです。
当たり前過ぎてつまらない意見であることは承知しています。
最強のアーキテクチャは何？という問いに対する『ケース・バイ・ケースです』という返答くらいに無意味なモノでしょう。

単なる感想ですが、人が何かを学ぶときの行動って一方に偏重しがちだなと思います。
ずっと座学やってたり、ずっと既存の知識だけで案件をこなしたり。

人によって何かを体得するときの最短経路みたいなものってあると思ってます。

自分の興味のあることだけをやってるうちに、周辺領域も巻き込んだ知識をつける人もいるでしょう。
体系的に学んでゆくうちに、自分の興味を発見して深掘る人もいるでしょう。
あちこちつまみ食いしまくってるうちに、体系的かつ興味ある分野の知識を得る人もいるでしょう。

この学び方の好み、得意が完全に分かってて、かつ成果が出てるのであれば今のやり方で全く問題ないと思います。
そうでもないなら、いろいろ足掻いてみると意外な発見があるかもしれないのでオススメです。

機械学習でもグラフ理論でも何でもいいんですが、パラメーターをいい感じに弄って、無数の解から最適な解を引っ張り出す問題ありますよね。

いろんな山がある中で一番高い山を見つけてくださいってヤツ。

局所的最適解ってのがあります。日本のどこかからスタートして一番高い山探してたら富士山見つけて満足してる状態です。この局所的最適解に陥ったときに、敢えてパラメーターを悪い方向にズラす手法があるんですよ、正しい名前か分からないのですが、むかし私が勉強していたときは『摂動』という名前でした。悪い方向にズラすと局所最適解から抜けちゃうのですが、別の解を探ってくれるんですよ。一回富士山から下山して、ユーラシア大陸とか行っちゃう。モンゴルの平地とか彷徨って、やっぱさっきの山の方が良かったやん…って後悔するんだけど、気長に歩いてたら4000メートルを超える山見つけたりする。で、また下山して彷徨ってたら、9000メートル近いエベレストを見つけたりする…

こういう足掻きをやってると自分のスイートスポットが分かってきて楽しいと思います。

とはいえ。
繰り返しになりますが、両者に対する興味の濃淡や、得意不得意は人それぞれです。

作りたいものが決まっていて、情熱が漲ってる人はひたすらサービス開発に邁進していただければと思います。
一方で、そんなに作りたいものがないのであれば、プログラムの性質やアプリ開発の生態系といった座学的なアプローチに特化するのもアリだと思ってます。

他にもプログラミングコンテストで人と技術を競い合ったり、稼働してるWEBサービスのセキュリティホールを見つけて懸賞金を稼いだりと、サービス開発以外にもプログラミングを楽しんだり、興味を掘ってゆく方法はあります。

プログラミングに対して興味を持ち続けられるポイントをいろいろ探ってみてください。

プログラミングを学ぶ目的を明確にする

個人的に、プログラミングの勉強の仕方より大事だと思うことはプログラミングをする理由を明確にすることです。
乱暴ですが、プログラミングはHowでしかないわけです。
自分は何がしたい？、どんなふうに生きたい？といった問いが大事です。

別に『世界平和を成し遂げたい』といった高尚なゴール設定する必要はないです。もちろん本気でそう思うなら設定すればいいです。
もっと下世話なゴールでもいいでしょう。無いよりはいいと思います。

例えば『今の仕事がブラックでシンドいので、未経験だけどWEBエンジニアになって楽したい』とかね。

楽な職場で求められるエンジニアリングのスキルを身につける必要がありますし、未経験のWEBエンジニアがどうやって楽な職場と出会うか考える必要がありますよね。

フリーランスであれば割と簡単に仕事見つかります。ただ、契約更新のタイミングで切られる可能性があります。

楽な職場でかつ、長く安定して過ごしたいなら正社員になるという手があります。
日本では『使えないからクビね』なんて出来ません。
それから『試用期間で様子見たけど使えないからクビね』って理屈も『使えないとはどういうことなのか』を示すのが面倒すぎます。
簡単に炎上する世の中ですから、企業としてはこういう面倒事は避けたいわけです。
そうすると企業側はリスクヘッジとして未経験者だから…とか難癖をつけて賃金をなるべく抑えるという行動を取りたくなります。
楽で安定な生活を送るためなら生活水準を下げても良い場合は『給与は下がってもいいので雇ってください』と交渉してみるのもアリでしょう。
本当に楽な職場かどうかは調査してください。（フリーランスで関わって職場を見極めてから、正社員として登用してもらえるよう交渉するなど…）

まあ、最悪辞めればいいんですけどね。

プログラミング言語と私

私自身もプログラミング書いてます。
ようやく、人に迷惑をかけない程度には書けるようになってきましたが、ここに至るまでに何度挫折したことか…

それでも続けてこれたのは、プログラムによって人間がやるにはシンドすぎる作業を一気に終わらせたり、大量のパーティクルを描画することで人の心を動かすようなインスタレーションができたり、なかなか解決されず困っていたことがあるWEBサービスのおかげでアッサリと解決されたり、好みのアダルトビデオを推薦してくれたりと、プログラムの強力さに魅了されたからです。

最初に勉強したのがC言語。
意味不明すぎて一瞬で挫折しました。
『ポインタ？構造体？malloc？は!!？』って感じｗ

次に勉強したのがJava。
クラスとか、ポリモーフィズムとか、インタフェースとかデザインパターンとか意味不明で挫折しました。

次に勉強したのがActionScript（今は亡きFlashで使えてたプログラミング言語）。
イベントリスナーとか、ネットワーク通信とか、スレッドとか意味不明で挫折しました。

中学生の頃にゲームを作りたくて、C言語と出会って５秒で挫折。
そこから６年くらいやって、こんな状態でした。。笑

当時はようやくネットが普及しはじめた頃で、今のようにYoutubeやドットインストールでプログラミングを勉強できる環境は無かったし、本屋に売ってる本も不親切というか、硬派なモノばかりで読んでも全く頭に入ってこない。
と、学習環境も悪かったですが、私のアタマの作りも悪かったと思います笑

ポンコツな私でしたが、興味を持ち続けて気長に取り組んでいると、分かる瞬間がいくつか出てきました。
この瞬間に何度か立ち会うと、理解の加速度が増してゆく感覚があります。
私の場合は連続的な成長ではなく、非連続な成長の繰り返しでした。（できる人からすると大した成長幅ではないが…）
意味不明だった単語が繋がって、脳の神経回路網のようなグラフが増殖してゆく感じです。

だんだんプログラミングという行為をパターンとして捉えられるようになってきます。

ただ、分かってきたなーと思ったら分からなくなるのがプログラミングでして、今でも分からない単語や考え方と沢山出くわします。
その膨大さに辟易することもあります。
一方で、未知の領域を小さく分割して理解してゆくのが楽しかったりもします。

この楽しいと思える感覚を大切にして、これからもプログラミングやっていきたいですね。