【個人開発】勉強方法と開発手法、そのスピード感について【勉強方法】

今年の年始に今年の抱負メーカーというアプリを開発しました。（宣伝）
【個人開発】新年早々、今年の抱負をつぶやくWEBアプリをつくってみた（記事）
実は主だった周知はしていませんが、他にもたくさんのアプリを開発しています。

同じようにこの業界にサラリーマンとして働き始め、独学を中心に曲がりながらやってこれました。

この中で、自分でうまくいったと思う開発手法・勉強方法とそのスピード感について（今回は特にこちら）記事にしたいと思います。

特に技術に関係していませんが、開発に関係すると思うので、大目に見てやってください。
では、綴っていきたいと思います。

また、この記事は完全に僕の主観です。
異論は当然認めます。

兵は拙速を尊ぶ

何事も早い（速い）ほうが良い。
ことわざにも早さを重視するものが多いことから、歴史的に見ても開発開始は早ければ早いほど良く、開発期間は短ければ短いほど良いと思います。
これはイメージが着きやすいですよね。リリースが早くなればユーザーの満足度も高くなりますし、不具合対応も早ければ早いほど鎮火がスムーズです。

その中でも特に勉強はスピードを重視せよ

スピード＞正確性。これは僕の持論です。
昔のインターネット黎明期ならまだしも、現代のプログラミング界隈は

• 情報が多く
• 移り変わりが早く
• 透明度が高い（公開しやすく、指摘されやすい）

です。
去年正しかったものが今年間違っていることはよくあることですね。
その中、僕が陥ったのは

• 情報が多すぎて正解がわからない
• 頑張って正解を調べた結果、いつの間にか古くなってる
• 結果、それは違う(古い)と指摘される

結果、モチベ低下する。
この解決策を考えた結果、考えるのをやめました
ひたすら目の前のしたいこと、作りたい自作アプリの開発をしまくりました。
すると気持ちのいいくらいに知識が入ってきます。

なんでだろう？これにいくつかの答えを出しました。

失敗するまでが早い

これは一番最初に思いつきました。
知らないことを検索するより、やってみてハマったところを少し勉強して実装する。
少し勉強しての少しがキモです。ここでガッツリ勉強するとハマった（完成しない）ままです。なぜそうなるかというと情報が多すぎて、情報の取捨選択をしているうちに刻々と時間が過ぎていくからです。ぶっちゃけなんとなくでいいとすら思っています。結果100%とは言えないまでも、60%くらいの知識がそこで付きますね。

単位あたりの勉強量が多くなる

勉強量/時間が当然増えます。
だって

• たくさん書いて
• たくさん失敗して
• たくさんやり直して

いますから。

成果が出るのが早い

これは感じている人が多いのではないでしょうか。成果が出ないと面白くないです。
早いほど成果が出て、楽しいですよ。

スピードは歳とってからはつかない

スピードがないまま年をとると鈍くなってしまいます。ディスってるわけではありません。PC使えない世代、スマホ使えない世代のように新しい技術を噛み砕く力がなくなってしまいます。
逆に昔からスピード重視の方は、70歳プログラマーなど噛み砕くのが速いです。
この訓練だと思いましょう。

つまりここで何が言いたいかというと、

とにかく

• これであってるの？間違ってないの？指摘怖い・・・
• 最初からコードを美しく、完璧なものにしたい。

この考えを捨て、今すぐ勉強ないしはコーディングを始めてください。
リファクタリングという考えもあります。
完璧でないコードを書いてしまったら「リファクタリングの勉強できるじゃん」とポジティブにとらえてください。

早く始めないと勉強している間に歳をとってしまいます。

「正確性を軽視せよ。」という意味ではない

ユーザーがいないアプリならまだしも、いるアプリでバグがあれば当然直しますし、そもそもバグを出すな。これは僕もそう思います。

僕が言いたいのは最初から正確性を追究するなということです。
皆さんアジャイル好きじゃないですか。勉強方法もアジャイルにしましょう。(もしかしてアジャイルももう古いですかね？)

それ・・・ユーザーに関係ある？

次は開発の方のお話をしたいです。

実はこれ実話でありました。
リリースが迫っているのに明らかに間に合わない修正をしたいという話でした。
処理としてのバグはありませんが、ソース上では確かに読みにくいものでした。
説得してマイナーバージョンで対応しましたが、完璧を求める過ぎるあまり自分しか見えていないエンジニア結構いると思います。（ちょっと偉そうですかね？）

これは僕も陥ったことがありまして、あるレガシーコードを修正していたのですが、あまりにレガシーなのでイライラしていたんだと思います。
このときこう言いました。
>早く修正させてください！リスク（時間的な）を冒してでも対応するべきです！

デザインや処理系は確かに古いですが、問題なく使えてるシステムでした。
>それ、ユーザーに関係ある？修正するのは良いけど、リスクは取らないよ。

今考えるとまさに自分のことしか考えていませんでしたね。
完璧を求めすぎて、周りが見えなくなるというのはこういうこと。

逆バージョンも見たことがあります。
>ユーザーに頼まれてこの処理をこう変えたいんだけど・・・

といわれ、
>え、この処理をこう変えるとコードが汚くなるのでやりたくないです。

• コードの美しさ
• 処理系の完璧さ
• 使用言語

いろいろなこだわりがありますがユーザーがいる以上、できるだけ捨てられるようにしたほうが良いと思います。

ユーザー＝神様ではない

でも、ユーザー＞コードですよね。

まとめ

• 自分のエンジンの最高回転数を上げるために、多少荒くていいのでスピード重視で勉強する。
• ユーザーを相手にするときは、ユーザーを労って運転してあげる。

コーディングなんて割と適当で良いと思っています。
大事なのは最後までコードのお世話をすることです。

ちょっと挑戦的な記事でしたでしょうか？
去年いろいろあって、思うところがあり記事にしてみました。
また加筆修正すると思いますので、そのときはよしなに。