趣味と実務は何が違う？ | プログラミングが好きならエンジニアとして通用するのか

プログラミングって楽しいですよね。

慣れてきて自分の思い通りに機能が作れるようになると、「プログラミングを仕事にしたい！」「実践を通してもっとレベルアップしたい！！」、と感じませんか？

僕もプログラミングの楽しさに取りつかれ、独学で学んでエンジニアに転職しました。

実務レベルのプログラミングは刺激的で楽しいですが、趣味とは大きく異なる面もあり、最初はあまりの違いに苦労しました。

この記事では、僕が実感した違い、そしてIT業界を目指すなら前もって意識しておくべきことをまとめてみました。

趣味の延長線上に実務は無い

いきなり結論ですが、僕は日曜プログラマーの延長線上にエンジニアレベルのプログラミングは無いと感じています。

理由は、自由に作りたい機能を開発していた「趣味」と、エンジニアとしての「実務」では、求められる技術力、制約、プレッシャーに大きなギャップがあることを痛感したためです。

そして、これらはただ趣味でコーディングを続けるだけでは身につかないもの、目的意識を持たなければ実感しづらいことだと感じるためです。

しかし一方、趣味としてのプログラミングを楽しめなければ、エンジニアとしての実務はやっていけない可能性が高いのも事実。

次の章で、具体的にどのように違うのか、比較していきます。

趣味と実務を比較

僕は最初は趣味としてプログラミングを始めましたが、それが高じてエンジニアに転職しました。

エンジニアとして実務でプログラミングを担当するようになり、個人でやっていた頃との感覚の違いに苦労しました。

以下に、僕が実感し、始めのうちは苦労した違いについてまとめてみました。

開発内容

趣味でのプログラミングは、開発内容も自由自在。

HTMLとCSSで自分のウェブページを作るもよし、C#.NETで普段している作業を自動化するツールを作るもよし。

Pythonで機械学習をしたり、Unityでゲーム作成をしたり、やりたいことに何でも取り組めますよね。

一方、業務となると、案件（お客様）あってのプログラミングです。

開発内容はお客様の意向に沿う形になりますし、必然的に使用する言語や技術も案件ごとに固定されます。

言語や技術

個人開発であれば、使用する言語や技術は自由に選べます。

「自分の得意な言語を使う」「勉強のためにあえて未経験の言語にチャレンジしてみる」「膨大なOSSの中から好きなものを選ぶ」等、一切の制約はありません。

一方、実務での開発は、プロジェクトごとに使用言語やOSS、さらに開発ツールに至るまで、使用が許可されるものが厳密に決められています。

お客様の指定から、ライセンスの都合まで、理由は様々。

仮に使いたいものがあったとしても、プロジェクトで許可されていない限り使用は許されません。

また、知らない技術を求められたとしても、別のもので代替することもできません。

勉強して使いこなせるようになる必要があります。

開発体制

趣味でプログラミングを楽しむ範囲だと、基本的に作業は一人で行うことが多いです。

開発内容、手法、完了時期、すべて自由に決められますよね。

一方、実務レベルのプログラミングは、開発規模が膨大です。

大きな構想のうち、個人が開発するのは特定の機能であったりメソッドであったりと、限定的。

数人～数十人が開発チームとなり、分担＆協業しながら大きなプログラムを組み上げていきます。

ソースコード管理

個人でプログラミングを行う場合、ソースコードの管理は基本的にローカル（自分のパソコン上）で行うことが多いでしょう。

一方、実務は前述のようにチーム開発のため、メンバー間で以下を共有する必要があります。

これらを可視化するため、ソースコードの管理はバージョン管理システムを用いて行われます。

代表的なのはGit。

専門的な知識が要求され、かつ全ての操作履歴が残っていくので、慣れるまではちょっと大変です。

コード基準

一人で開発をしていると、コーディングのルールに気を配ることは少ないでしょう。

エラーが起こらなければどのように書いても特に問題ないですし、変数名や関数名も自由に付けてOKです。

一方、実務の開発現場では、コーディング規約が設定されています。

場合によってはコメントアウト部分の書き方も厳密に定義されており、それに従ってコードを書いていかなければなりません。

コード品質

趣味として自分用のプログラムを書いている範囲では、ぶっちゃけ動けばOKです。

誰にコードを見せるわけでもないですし、多少不要なループがあったり、まどろっこしい書き方だったとしても特に不都合はありません。

一方、業務では以下が求められます。

なぜなら、エンジニアの開発は、成果物ができて終わりではないからです。

いったん完成してリリースした後も、お客様要望に応えての二次開発、また運用上で発覚した不具合への対応など、随時メンテナンスが発生します。

その際に読みづらいコードだと、作業が大変になってしまいます。

また会社は組織ですので、人事異動や配置転換が行われる可能性もあります。

突然別プロジェクトに異動となり、後任者が開発を引き継ぐとなってもスムーズに概要把握および作業に入れるよう、ソースコードやロジックは綺麗に実装していく必要があります。

開発スピード

趣味でプログラミングを行う場合、開発スピードを意識することはほぼないはずです。

作っているものに納期はないと思いますし、完成までにどれだけ工数をかけても問題ない場合が多いと思います。

一方、業務はお客様の都合が絶対優先。

案件受注時に運用開始時期をふまえた契約となっているので、指定された要件を納期内に仕上げることは必須です。

また、意外と見落としがちなのが、予算。

納期さえ守れば残業や休日出勤をいくらしてもいいんでしょ、というわけではありません。

時間外労働の人件費は、プロジェクトに計上されます。

人件費がプロジェクトの予算を超えれば、会社としては赤字です。

ドキュメント作成

個人開発では開発仕様書を作成しなくても、開発を進めることはできます。

ただ、個人的には趣味のちょっとしたプログラムでも、仕様書を書いてから着手したほうが思考がクリアになって作業しやすいとは思います。

一方、業務では資料作成は必須です。

Koki

というか、コードを書いているよりも資料を作っている時間のほうが長いかもしれません。

前述の通り業務での開発はチームメンバー同士だけでなく、チームを超えた連携が必要不可欠です。

必要な情報を理解できるよう、実装内容からデータベース構成、クラスやＡＰＩの一覧などを、都度資料として整理していくことが求められます。

検証作業

趣味の開発において、明確に「テストフェーズ」を意識することは少ないかと思います。

たいていの場合、自分で作りたいものを作る→思いつくパターンを動作確認→OK、という流れではないでしょうか。

一方、実務ではテストも厳格に行う必要があります。

入力値および想定される結果を様々なパターン用意し、テスト仕様書を作成。

さらに、テスト結果はエビデンスとともに報告書にまとめる必要があります。

運用において不具合が起こった際には、すべてのメソッドを確認していくには膨大な時数がかかるため、テスト報告書をもとに、怪しいポイントの絞り込みを行っていくためです。

プログラマー志望なら意識すべきこと

前述のように、趣味の日曜プログラマーと、プログラミングが仕事のエンジニアでは、同じプログラミングでも作業手順やプレッシャーに大きな違いがあります。

僕は日曜プログラマーとしての開発作業が楽しいと感じたことをきっかけに、本格的にプログラミングを仕事にしたいと希望し、エンジニアに転職しました。

転職してみると最初はあまりの違いに戸惑いましたが、現在は楽しく作業に取り組んでいます。

将来的にＩＴ業界を考える場合、入った後のギャップを軽減するため、エンジニアに求められる作業をイメージしながら勉強を進めておくと良いです。

事前に知っておくことで、業界に入ったときに知らなかった、大変だ、と感じるリスクを下げられるからです。

特に次の4点は、プログラミングの勉強過程から意識し、習慣として刷り込んでおくのがおすすめです。

ハードコーディングをしない

ハードコーディングとは、コード内に直接、値やリテラルを埋め込むことです。

変数や定数を使用せずに、直接コードに具体的な値を書き込むこと、とも言えます。

例えば、円の面積を計算する場合、ハードコーディングすると以下のようになります。

using System;

class Program
{
    static void Main()
    {
        int radius1 = 5;
        double area1 = Math.PI * radius1 * radius1;
        Console.WriteLine($"半径が{radius1}の円の面積は: {area1}");

        int radius2 = 8;
        double area2 = Math.PI * radius2 * radius2;
        Console.WriteLine($"半径が{radius2}の円の面積は: {area2}");
    }
}

半径の値が直接コードに散りばめられています。

radius1 と radius2 の値が変更される場合、該当する箇所を探して、それぞれ変更する必要があります。

このようなアプローチは冗長であり、変更が生じた場合にコード全体を更新する手間が発生します。

一方、ハードコーディングを避けると以下のようになります。

using System;

class Program
{
    static void Main()
    {
        // 変数で半径を保持
        int radius1 = 5;
        int radius2 = 8;

        double area1 = CalculateCircleArea(radius1);
        double area2 = CalculateCircleArea(radius2);

        Console.WriteLine($"半径が{radius1}の円の面積は: {area1}");
        Console.WriteLine($"半径が{radius2}の円の面積は: {area2}");
    }

    static double CalculateCircleArea(int radius)
    {
        return Math.PI * radius * radius;
    }
}

メソッドを使用して円の面積を計算する処理を切り出しており、2つの異なる半径に対して再利用されています。

これにより、コードが簡潔で保守性が向上し、同じ計算を複数回書く必要がありません。

ドキュメント作成の癖をつける

開発現場では、実装内容からデータベース構成、クラスやＡＰＩの一覧など、様々なドキュメントを作成しなければなりません。

学習過程からこれらを作成する習慣をつけておくと、実務に入った際に困らないだけでなく、プログラミングの学習効率が上がるというメリットもあります。

まとめ

この記事では、趣味と実務でプログラミングは何が違うのかを紹介してきました。

実務ではメンバー間の連携や保守性の観点から、趣味レベルよりもランクアップした実装が求められます。

これらはただ趣味でコーディングを続けるだけでは身につかないと感じたので、個人的には趣味のプログラミングの延長線上に業務レベルのコーディングはないと考えています。

ただ、趣味のプログラミングを楽しめなければ、ＩＴエンジニアとしてはやっていけないことは事実。

もし転職やフリーランスなど、ＩＴ業界も視野に入れながらプログラミングを学ぶ場合、綺麗なコードを実装していく、という視点を強く持っておくことをおすすめします。