はじめに

独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログを読んだときに、僕自身もまた不安定労働から、ある程度「これだったら自分できそうだ」という気持ちで取り組み、独習のつもりで幾つものプログラムを書いたりしていた。だから、ニートからプログラマを目指して、社員として今頑張ってます、というのはすごく仲間意識を持ってしまうし、同じように頑張ってほしいという気持ちはある。

確かに、上の記事の趣旨自体、つまり「独習で学ぶことは、実務上でカバーできない部分がある」という側面があることは認めつつ、しかし、自分自身は独習したことが案外実務上で役に立っている部分もあり、その部分は明確にしたほうが、今後同じように独習して、今度プログラマを目指す人々において役に立つのではないか、と思うので、この記事を書こうと思う。

この記事で扱う「Webアプリケーション開発の独習」の範囲について

とはいえ、上記のブックマークコメントを見たときに、まず「独学」の範囲が明確ではないのではないか、という指摘が書いてあった。自分なりに、「Webアプリケーション開発の独習」ということを考えたときに、下のようなことが一通り出来るということが、「Webアプリケーション開発の独習」にといて求められることだと思う。

• 対象のプログラミング言語に対しての一通りの理解
• MVCフレームワークを利用し、モデル・ビュー・コントローラーの切り分けができる
  • これに該当しないものも最近多いので、一概には言えない
• データベースと連携してアプリケーションのデータを永続化することができる
• 何らかの形で他人がアクセス出来る環境に、自分が作ったアプリを公開することができる
• それらに対してテストを書いて機能が意図通りに動いていることを確認できる
• 一ヶ月程度の継続的なアプリケーション改善を行うことができる
• できるならチケットを切って、何が問題なのかを書きながら出来るとよい
• できるならパフォーマンスネックになっているところを調べられるとよい

僕もよくやりがちなこととして、まずプログラミングといったところで、例えばネイティヴアプリ、組み込み、業務システム、コアシステム開発など、様々な分野に分かれることが多いと思う。そのため、今回の記事では上記は、Webアプリケーションの独習のスコープに入っているという前提で、記事を書こうと思う。

自分の盲点その1: 見積り

業務の場合、納品の関係であったり、そうではなくても継続的な改善の場合、ある程度「この実装については、これだけの労力がかかる」ということについて目星がついておく必要がある。独習の場合、どちらかといえば「習得」という観点に重点が置かれる気がするので、「それにどれだけ時間がかかるか」よりも、「それをどうやったらできるのか」という側面のほうが重要になるというのは事実だろう。

しかし、業務の場合だと、そのような「それをどうやったらできるのか」ということよりも、「それにどれだけ時間がかかりそうなのか」ということのほうが重要な場合が多い。もちろん、これは単純には定まらないものであり、ある程度の相対的なものであるとも指摘されている。

この辺りは、どのような開発手法を用いるかによってブレがあるかもしれないけれど、どんな職場にいくにしろ、「この機能はこれだけかかるっぽい」というのを意識するといいのかもしれない。自分の場合は、この辺を下の本で考えたりしていた。

改善策としては、普段からPomodoroテクニックとかで、時間を記録しながら作業するというのは効果的かもしれない。

自分の盲点その2: わかりやすいドキュメント

これも自分の場合は結構盲点で、確かにある程度ドキュメントを残す側の人間だとは思うのだけれど、どちらかというと「ドキュメントツール」の習得に目を向けがちだったりする。でも、ドキュメントというのは、「形式」という側面を除くとするならば、開発者同士がスムーズにコミュニケーションするためのものである、ということを忘れがちになったりする。

もちろん、自前で書いているときは、頭の中である程度把握しているからいいじゃん、ということになるんだけど、複数人で書いているときは、そのような「他人にとって自分の知りたい情報が載っているドキュメント」というのを考えないといけない。そのとき、向き合うのは、自分ではなく「相手」だ。

モバイルアプリのAPIを実装しているときに、それを実感した。相手にとって、如何に必要な情報をドキュメントに落とし込むかは、自分で開発しているときには見えないことだと思う。

自分の盲点その3: 大規模システム開発

自分のサービスというのは、基本的にはスケールアウトしないものだ。もちろん、幸運にも自分で開発しているときのサービスが当たって、ある程度スケールアウトできるように変更しなければならないというインフラのこととかに頭が回らなかったりする。

もちろん、そういうのが専属にいるという場合だったりすることが多いと思うし、また個人でも結構大きなシステムを作ることも出来るかもしれないけれど、しかしそういうものは、個人ではなかなか思いつきにくいし、思いついたとしても、なかなか実際に挙動を見てみないと、ピンとこなかったりもする。

例えば何らかのサーバーをこういう風に構成するといいとか、あるいはどこらへんを抽象化するとかネックになるとか。そこはやはり、ある程度まで大規模に動いているものがあるのとないのとでは、実感の質が違うかなと思う。

自分の盲点その4: 局所最適化

自分とかだったりすると、逆に頭でっかちになって、それだと上手くいかないとか、あるいは余計時間がかかるとか、あるいは自己満足に終わるとか、そういう判断ができなかったことがままあった。また、一部のところに局地最適してしまって、全体を見渡せなくなってしまったり、あるいは設計の過程で、「ここは汚いけど、悪いけど目をつぶらないといけない」みたいなことが出来なくなるところがある。悪い意味で視野が狭くなるのはよくはない。

もちろん、後々になると全体に不利益になるような、例えばセキュリティ問題についての妥協は避けるべきだけれども、そもそものアプリケーションの問題として、そこに力を入れるべきではないという部分に関しては、とっと切り上げたりするといったことが必要になる。

問題は、全体を見渡しながら、どこに力を入れるべきで、どこに力をいれるべきではないのか、あるいは、どこがミッションクリティカルでどこがそうではないのか、という問題があり、大抵自分の場合だと、割とその辺りの優先順位が弱くなってしまうことがままあった。

自分の盲点その5: 断片化

基本的には、独習だったりすると、手っ取り早く何かを済まそうとしてしまうため、個々の知識が断片化することがある。例えば、自分自身はCSSとかも趣味では書いたりするが、ではfloatは具体的にはどうものなのか、ということを尋ねられたら説明できないだろう。

もちろん、これが悪いこともあれば、よいこともある。今回は悪いことに焦点を合わせるとするならば、それは応用が効かなかったり、あるいは少し事例が違うと途端に調べなおしになってしまうことだ。調べなおしになるならいいんだけど、「あれ、あれってどうするんだっけ?」みたいになってしまう。

僕は本当に趣味でUbuntuのデスクトップを使っているし、このブログの記事もUbuntu上のEmacsを使って書いているのだけれど、じゃあ自分がLinuxの知識が強いかというと、まったくそんなことはない。本当は、この辺りも体系的に理解して、理解すると、よりぐっと応用力が上がる気がしている。

例えばTCPについても、そうなので、下の本で勉強したりしている。

まとめ

多くの人が指摘しているように、独習部分に関して、大変になるのは、基本的には

• 個人では手に入りにくい環境下における体験
• 多人数でのチーム開発におけるコツ、振る舞い
• 全体を見てどれくらいの時間を使えばいいのか

という部分になると思う。チーム開発に関しては、自分はたぶんマネージ層は事務能力が壊滅的に下手なので苦手だけど、自分なりに考えるところもあってそういう本も、一応読んでいる。定番だけど、下の本とか。

あとは、やはり時間と労力を意識する部分で、やっぱりプロジェクトにとって時間は無限にあるわけではなく、できるだけ最大限の効果を発揮できるようにしていく必要はある。個人だと、どうしても自分の興味によって注力する部分を決めることができるけど、そういうものではない、というのは実感としてもある。その辺は経験でしかなく、ある意味において、この辺をちゃんと理解して開発できるということが、「達人プログラマー」への道なのかもしれない、と思う。