職業プログラミングと趣味プログラミングの違い

私は学生時代からデータ解析でプログラムを書いていたこともあり、システムエンジニアの仕事でもある程度通用するつもりでいました。

しかし、職業としてのプログラミングは、それまで私がやってきたプログラミングとは大きく違いました。

ここでは、私が教えられたこと、気づいたことで、職業プログラミングと趣味プログラミングにどんな違いがあるのかを書いていきます。

既にプログラミングスキルがあって、これからエンジニアになろうと考えている方は要チェックです。

何を書くかは書き始める前にほぼ決まっている

職業プログラミングでは、設計書に基づいて開発を進めていきます。

趣味でプログラミングを行う際は、プログラムを書いている途中で、あれも必要だったとか、これを書くならさっきのところ書き換えた方がいいなと行ったことを考えます。

しかし、職業でプログラミングを行う際はそのような行き当たりばったりなやり方では、複数人で開発作業を行う際に連携がとれなくなりますし、前の手順に戻る手戻りが発生してしまいます。

そのため、作成する前に必要な要件を確認し、実装する機能を洗い出します。

そして、それらの機能を実現するのに必要な設計書を作成します。

設計書は、他人が作成することを前提に作成するもので、誰が見て作っても同じプログラムができあがるようになっています。

システム開発の方法は、ウォーターフォール方式とアジャイル方式という２種類が有名です。

ウォーターフォール方式は、滝が上から下へ流れるように、要件定義→設計→製造→テストの順に進めていくやり方で、大規模システムの開発に多く用いられてきました。

アジャイル方式は、ウォーターフォールが途中で仕様変更できないという点を解消するために、短期間で小規模な開発を行い、それを繰り返すことで最終的な完成を目指すものです。

私は研修ではウォーターフォールで開発を行いましたが、実務はアジャイル風でした。

開発チームにはコーディング規約というものが存在するはずで、そのチームでプログラムを書くときの約束事が決まっています。

趣味でプログラミングを行う際は自己流の書き方で問題ありませんが、チームで開発する際には他のメンバーと書き方を揃えなければなりません。

仕事をするということは相手がいるということです。

利用者やチームメンバーがいるため、自分が分かればいいというものではありません。

ソフトウェアとは言え、製品として納品するからには品質評価を行わなければなりません。

趣味でやっているときには縁のない考え方かと思います。

開発チームには品質指標と呼ばれるものが存在するはずで、テスト結果などを品質指標と照らし合わせて評価を行います。

品質指標はテストのエラー件数だけでなく、開発した行数に対してテストの件数（テスト密度）が妥当か、テストがパターンを網羅できているか（coverage）、応答時間は許容範囲か、高負荷になっても耐えられるのか、などといった項目も存在します。

趣味としてのプログラミングと職業としてのプログラミングには様々な違いがあることを理解しましょう。