  |
まずは、いま自分の置かれている状況から、どの言語を選ぶべきかを考える。
複数の要素があるなら、優先順位をつけること。
参考として、僕の考える優先順位は以下のようになる。
まずは目の前のことをきちんと片付けられるひとになろう。
焦燥感などあるかもしれないが、雑誌やブログは必要以上に煽る傾向がある。なぜならそれで稼ぐひともいるからだ。
他人が進める技術はポジショントークだと思って問題ない。自分とは立場が違うからと、参考程度に読むべき。
流行は過ぎ去るのが早い。習得したが流行が次に移る可能性もあるので、博打すぎる。
仕事で使われている言語は、採用された経緯が絶対にあるので聞いてみるべき。
「ハードやOSの都合」「パッケージソフト」「社内に有識者が居る」「お客様の指定」のように、だいたいは大人の事情であることが多く、選定される言語は会社や現場によって違う。
また、仕事でソースコードを書く場合は、作成後「保守」「運用」と言った、作ったものに手を加えることが必ずと言っていいほど発生する。保守運用は実装者以外が担当することも多い。それらを想定した引き継ぎや改修のコストも考慮され、言語の選定が行われている。
そのため、仕事で使用する言語はだいたい似たような作りになっている。あまりかけ離れたものだと技術者の確保が難しく、教育のコストも馬鹿にならないからだ。
つまり、ひとつの仕事で使用する言語を「高いレベルで」習得すると、他の言語になっても多少の違和感レベルで移行ができるようになる。繰り返すが、まずは目の前の仕事で使われている言語を修得することだ。
そして次のステップで、余裕ができたときに自分が実現したいものを制作しよう。
まず、実現したいものの要件定義をしよう。どんな環境で動くものなのか。ブラウザ必須？アプリがよい？どんなライブラリを使ったら楽になるのか。データベースは必要なのか。グラフィックは凝る必要があるか。
と、考えていくと、自ずと言語は見えてくるはず。
はじめての場合は、使用ユーザが一番多いものを選ぶとよい。ユーザが多いということは、情報がたくさんあるということ。ググったら出てくるのは素晴らしい。
そして、使用者が多いとバグも少なくなっているということだ。知らない分野であると、自分のミスなのかバグなのかの判断がとても難しい。
着手する前に、作りたいものの技術をどう実現できるかを前もって調べて、詰まって投げ出さないように予防線を張ろう。
部分の理屈は解っていても手を動かさないと見えてこないものがある。
意外に準備が必要だったり、素材作りやデータ入力での反復作業、部品を結合したときに気づく設計の重要性、リファクタリング、テストの観点だったりと。
最初から最後まで見通すことができると、他人から作業を振られた時に、どの部分をやっているかが見えてくるようになる。振られた内容に不備不足を見つけてプロジェクトに進言できる人は、プロジェクトで重宝されて居心地がよくなるのでオススメ。
ということで、まずは規模が小さいものを作るとよいと思う。大きいものにチャレンジしても、社会人になると時間も少ないので途中でやめてしまう危険もある。例えば、仕事中で感じる何か1手順を楽にするようなものとか、ある個人の作業が楽になるようなものなどが、要件が把握できる規模なので、ちょうどよいと思う。先ほど考えた「自分が実現したいもの」は、その後でもよいと思う。僕の経験から、大きいものを作っていると知識が溜まっていくに従って最初から作り直したい病が発生するからだ。
簡単に要点をまとめます。
以上。着手前の心構え的な部分を書いてみました。
14
