趣味のプログラミングと仕事のプログラミングの違い
「趣味のプログラミングするのは楽しいけど、仕事だと楽しくない」
「仕事でプログラミングするだけで大変なのに趣味でなんてやらないよ」
私は趣味でも仕事でもプログラミングしていますが、趣味と仕事ではやり方を変えています。
趣味でコード書くのは楽しいけど、仕事でやるとつまらないという方も、取り組み方を工夫すれば、仕事と趣味で違ったプログラミングを味わうことができます。
そんなわけで「趣味と仕事のプログラミングの違いと、その切り替え方法」を紹介します。
Contents
何を作るか？
趣味の場合、自分が作りたいものを作れる！
趣味では自分が作りたいものを自由に作れます。
作ってる途中で仕様を変えたくなったら自由に変えられますし、作るのが面倒臭くなったら未完成のままやめることもできます。
仕事の場合、要求されたものを作る！
仕事では要求された仕様のソフトウェアを開発しなければなりません。
より良い仕様を思いついたとしても、勝手に仕様を変えることはできません。
「絶対こっちの方がいい！」と思って提案しても受け入れてもらえないこともあります。
そんな時は割り切りが必要です。仕事とはそういうものであり、良い提案をできた時点でベストを尽くした時点で成功です。ベストを尽くした上で意に沿わない結果が起きた場合は、淡々と仕事として処理をすれば良いでしょう。
理想を追いすぎず、現実に流されすぎず、淡々と最善を尽くす、これが正しいスタンスなんだと思います。そうしていれば、
- 理想と現実のギャップに苦しむ
- 仕事に嫌気が差して、無関心になる
といったことにもならないでしょう。
とはいえ、IT業界には根本的問題があります。
IT業界なのにIT素人が多すぎる
きちんと考えられたビジネス要件で仕様が決められているのならいいのですが、プランナーや顧客の勘でなんとなく仕様が決定されておかしなソフトウェアができ上がる場合もよくあります。
プランナーや顧客のITリテラシーが低い場合にこういうことが起こりがちです。
この問題に取り組んでいる企業もあります。
楽天では英語の公用語化の後、プログラミングも公用語化することが発表されました。プログラマーではなくてもプログラミングをある程度分かっていないと良いITサービスを設計することなどできないという考えからだそうです。
私もこれには賛成です。プログラミングをやることによってわかるコンピュータの特性があります。コンピュータは命令した通りにしか動かないから厳密な手順を明確にする必要があるということです。プログラミングをすると、これが肌感覚で分かります。知識としてわかるのと肌感覚でわかるのとでは全然違います。
ちょうどよいことに、小学校でプログラミング教育が必修化されるので、今後は改善されていきそうですね。
利用技術・言語
趣味の場合、使いたい技術・言語を使えばいい
「使いたい」といっても、いろいろあります。
- よく知っていて得意だから使いたい
- 使ったことないからどんなものか使ってみたい
どのような理由でも構いません。自分が使いたい技術・言語を使うことができます。
仕事の場合、指定されたものか、要件に合ったもの
プロジェクトの途中から参加するプロジェクトの場合、利用技術・言語は決まっているのでそれを使うしかありません。
プロジェクトの立ち上げから参加する場合、利用技術・言語を決めるフェーズに参加できる場合があります。
その場合にも、自分が使いたいという理由だけでは不十分で、その技術を使うことで、
- システムに求められる要件を満たせる
- それらの技術を使える要員を集めやすい
などの説得材料が必要です。
アーキテクチャ
趣味の場合、好きなアーキテクチャを使える
趣味で作るソフトウェアの場合、実験的なアーキテクチャを採用できます。
うまくいかなくても困るのは自分だけですからね。
仕事の場合、指定されたものか、要件に合ったもの
大抵の仕事はアーキテクチャが指定されています。
アーキテクチャは以下の２つに大別できます。
- OS・ミドルウェア等のシステムアーキテクチャ
- ライブラリ・フレームワーク等のアプリケーションアーキテクチャ
システムアーキテクチャは決まっているけれどアプリケーションアーキテクチャはプログラマーが決めていいという場合もあります。
そういう場合にも、自分が使ってみたいという理由だけで選ぶのではなく、利用技術・言語と同様にシステム要件や要員の集めやすさ等の条件を満たしているものを選びます。
コードの書き方
趣味の場合、好きな書き方をすればいい
趣味なので自分の好きなスタイルで書くことができます。
仕事の場合、コーディング規約や他人の書き方に合わせる
コーディング規約がある場合はそれに従った書き方をします。ない場合も他のメンバーのスタイルに合わせるようにしています。
私が趣味でC#のコードを書く場合、
if (a == 1) {
Debug.Log("Hello");
}
と書きますが、
if (a == 1)
{
Debug.Log("Hello");
}
のように中括弧の前に改行を入れるスタイルのプロジェクトの場合は、プロジェクトの書き方に合わせます。
他人のコードを読み、まねすることで学べることもたくさんあります。
ただ、あまりに変なコーディング規約の場合は変更を提案します。
あるJavaを使うプロジェクトのコーディング規約に
「static変数、staticメソッドは使ってはならない」
と書かれていました。
「static変数なしでSingletonをどうやって実装すんだよ？」と思い、あまりにおかしな規約なので、「この規約はおかしくないですか？」と聞いたら、「あー、あれ別プロジェクトから適当に持ってきた規約だからおかしな所は変えていいよ」と言われました。
なので、ただ合わせるだけでなく、おかしな所を見つけたらルールを改善する提案して良いと思います。
趣味と仕事で手法の使い分けをしよう！
趣味と仕事では、それぞれに特性があり、できることできないこと、向き不向きがあります。
趣味の方が自由度が高いから全て良いってことでもありません。仕事という制約があるから、優れたソフトウェアを作ることができる面も多々あります。
- 趣味では → 新しいものを試す。好きな技術を使う。
- 仕事では → 求められた技術を使う。人のやり方を学ぶ。
というように、手法を使い分けることで、異なった知見が身に付けられると思います！