アマチュアプログラミングと仕事としてのシステム開発の違い

昨今はプログラミングブームなんかもあって、まずは興味本位で（趣味として）プログラミングをはじめてみました。なんて人も多いのではないでしょうか。

（現職がシステムエンジニアという人も含めて）プライベートの時間を利用してプログラミング技術を向上させるのはとても良いことですが、アマチュアプログラミングと仕事としてのシステム開発は、明確に別物として考えた方がよいでしょう。

アマチュアプログラミングと仕事としてのシステム開発の違いや、それぞれに求められるものについて、話をしていきたいと思います。

最大の違いはお客様がいるかどうか

マチュアプログラミングと仕事としてのシステム開発の最大の違いは、お客様がいるかどうかです。お客様から金銭をいただく以上は、プロとしての仕事が求められるということです。

請負契約での開発の場合は、瑕疵担保責任などのリスクも発生するので、より一層高いプロ意識が求められます。
※瑕疵担保責任とは（簡単に言うと）、そのシステムに何かしらの欠陥があった場合、作った側が金銭補償や無償対応などのリスクを負う責任のこと。

そうした意識の違いがどうしたところに現れてくるのか、すなわちアマチュアプログラミングと仕事としてのシステム開発との違いを、以下に記していきましょう。

アマチュアプログラミングは自分本位で楽しめばいい

アマチュアプログラミングとは趣味の世界です。言ってしまえば自己満足という表現でもよいかもしれません。

自分が欲しいツールをつくったり、興味のある言語を学習したりと、一人称で完結する世界です。ときには友人・知人のためにシステムを構築するかもしれませんが、無償対応である限り、そこに責任は生まれません。

開発の工程においても、設計書などを用意する必要もありませんし、アマチュアプログラミングとは自身の技術面だけに目を向ければよいのです。

仕事としてのシステム開発に求められるもの

対して仕事としてのシステム開発となると、あらゆる要素が必要になってきます。職業としてシステムエンジニアを目指しているとか、就いているという場合は、以下のようなポイントを意識するようにしましょう。

プログラム規約を遵守する

仕事としてのシステム開発だって、もちろんプログラミングをします。ただし自分一人の世界で完結するアマチュアプログラミングとは違い、同じソースを複数メンバーで共有したり、自分が書いたソースを別エンジニアが保守していくなんてことは、よくある光景です。

そうするとプログラマ個々人のクセのようなものは排除して、できるだけ誰が読んでも理解できるようなソースコードにするのが合理的な考え方と言えます。

そこで登場するのがプログラミング規約という存在。どこまで厳格な規約が定められているかは各プロジェクトや各現場で異なりますが、変数名の付け方からローカル関数の使い方まで、プログラミングをする上での一定のルールに則り、ソースコードを書いていく必要があります。

チーム連携とコミュニケーション

一人でものづくりをするのとは違い、仕事としてのシステム開発となると、多くの場合はPM・PL・メンバー（SE・PG）といったチームで一つの開発に取り組むことになります。
※それぞれの役割は「プロジェクトチームにおけるPM、PL、SE、PGそれぞれの役割」をご参照ください。

システム開発とは言っても、チームとして動く以上、人と人とが接することになりますのでコミュニケーションが求められます。そうなると新入社員1年目で教えられる「報告・連絡・相談」といった要素がとても大事。むしろプロジェクトが炎上するときは「報告・連絡・相談」といった基本が、上手くチーム内でできていないことがほとんどだと思います。
※コミュニケーションについては「システム開発も結局一番大事なのは技術力よりコミュニケーション力」をご参照ください。

 

また先のプログラミング規約にも通じる話ですが、複数のチームメンバーでファイルを共有するという考えで言えば、バージョン管理も気をつけたいところですね。

個人で管理している古いバージョンのプログラムファイルを、テスト環境・本番環境問わず適用させちゃったりすると、原因究明にも多くの時間を要しますし、無駄な労力を割くことになり精神的にも疲れます。

あともっと言っておくと、DBなんかも共有するわけですから、誰かがテスト中に勝手にマスタデータを更新しちゃったなんてこともあるわけで、あらゆるリソースを共有しているということを、しっかりと頭に入れておきましょう。

工程管理・遵守

お客様システムを構築する以上、お客様が求める納期があります。そしてその納期から逆算して、工程が組まれていきます。

この工程を管理し・厳守していくことが、仕事としてのシステム開発を成功させる上での要になってきます。

PMやPLであればもちろん管理能力が必要になりますし、メンバーであっても管理される能力が求められます。スケジュールの管理や厳守については、以下の記事をご参考ください。

• PMの仕事はマネージメント。工程遅れはPG・SEのせいにするな
• 開発チームのメンバーとしての”管理される能力”の大事さと磨き方

品質管理

品質に対する考え方も、アマチュアプログラミングと仕事としてのシステム開発の大きな違いのひとつになります。

開発の対価として金銭をもらわないシステムであれば、バグがあっても後から対応すればよいか、で済んでしまうかもしれませんが、仕事としてのシステム開発であればそうはいきません。

もしバグが原因でお客様業務がストップしてしまったり、製品の大量リコールなんて話になれば、先に話した瑕疵担保責任の通り、損害賠償という話にまで発展しかねません。

だからプログラムは作って終わりではなく、徹底的にテストを行い、品質を高めていきます。納品前にバグをゼロにする意識で、単体テスト・結合テスト・システムテスト・受け入れテストなど、複数のテスト工程をこなしているのです。

 

おわりに

プログラミングでも仕事としてのシステム開発となると、ただ技術力が高ければよいとか、納期に間に合えばよいというわけではなく、今回ご説明したような多くのことに意識をまわしていく必要があります。

仕事してのシステム開発という面で評価するなら、そうしたことへどれだけ意識高く業務に取り組めるかが、SEとしての能力にも直結するところにもなるのです。