こんにちは。
フリーエンジニアのアルト（alse0903)です。
僕が最初にフリーエンジニアになったとき、1年だけ正社員としてIT企業に居ましたが、業務でのプログラミング経験は、ほぼ0でした。
というのも、エンジニアであれば100%の人がプログラミングをしているわけではないです。
そして、僕の業務はプログラミングとは無縁の仕事だったので、業務ではプログラミングを全くしていませんでした。
つまり、入社してからの1年間はプログラミングを経験することは全くできませんでしたが、自宅で独学でプログラミングを勉強することで1年でフリーエンジニアになることができました。
業務でのプログラミング経験なしにフリーエンジニアになれたのは良かったのですが、当初全く壁がなかった訳でもなく、いくつか困ったこともありました。
今日は、独学でフリーエンジニアになってみて困ったことについて、書きたいと思います。
設計書の書き方
まず、最初にぶち当たった壁はここです。
独学でWebアプリケーションを作って勉強していたときは、ある程度は基本設計や詳細設計はしましたが、わざわざエクセルに資料をまとめたり、誰かにアウトプットしたりすることはありませんでした。
なので、基本設計書や詳細設計書を書いたことがないという状態で、フリーエンジニアになりました。
正直なところ、上流工程やリーダーポジションでの案件に参画しない限りは、設計書を書くということはあまりないですが、僕の最初に入った現場では、当時の僕からしたら少しレベルの高い現場に入ったこともあり、また人手不足だったこともあり、設計書も少し書くことになりました。
なので、特に現場で設計書を書いた経験のない状態でフリーエンジニアになる場合は、その旨をエージェントに伝えた上で、「開発工程以降」を担当するという条件で案件を探してもらうことをオススメします。
基本的なシステム開発の流れは以下の通りです。
① 要件定義
↓
② 基本設計
↓
③ 詳細設計
↓
④ 開発工程
↓
⑤ 単体テスト
↓
⑥ 結合テスト
↓
⑦ 運用テスト
↓
⑧ システム移行
↓
⑨ 運用・保守
テストのやり方
テストとは、プログラムを実際に動かした際に、不具合やバグ、意図しない動作はないかということをチェックするためのものです。
しかし、独学でプログラミングを勉強する際はテストもそこまで徹底的にやならいですし、テストした結果をエクセルにまとめたりすることは、まず無かったです。
そのため「テストをお願いします」と言われても、そのように資料を作成していいかという点が分からずつまったことがあります。
スポンサードサーチ
「チームで開発をする」という概念
また、僕が最も困ったのはここです。
まず、根本的に言えるのは “個人開発とチーム開発は全くの別物である” ということです。
もちろん、プログラミング言語の知識であったり、基本的な考え方は同じなのですが、僕が伝えたいのは以下の3つです。
1. 個人開発は好きにコードを書けるが、チーム開発は規則を守ってコードを書く必要がある
2. チームで一つのシステムを開発するときは “競合” が発生することがある
3. 最悪の場合、デグレしてしまうとバグを作ってしまうことだってある
個人開発では好きにコードを書けるが、チーム開発では規則を守ってコードを書く必要がある
趣味や独学でプログラムを書くときは、ソースコードを自分しか触らないので、好きなようにコードを書くことができます。
また、自分でファイルを作成するので、どこにどのファイルを保存するかも自分だけが把握できていれば特に問題は起きません。
しかし、複数人でチームを組んで開発を行う場合は、全員の認識を合わせる必要があります。
また、プログラムもある程度の規則を決めた上でコーディングしなければなりません。
（そのような理由から、チーム開発ではよくフレームワークを導入し効率的に開発を進めるのです。）
チームで一つのシステムを開発するときは “競合” が発生することがある
チームで開発する場合、各機能毎や画面毎などの単位で作業が割り振られることが多いです。
そのため、一つのファイルを同じタイミングで二人の人が編集してしまうと、作業内容がバッティングしてしまうことがあります。
これを競合といいます。
そのため、極力は競合が発生しないようにチーム内でコミュニケーションを取る必要があったり、競合が発生した場合でも、そのまま上書きしてしまわないように、多くの開発現場ではGitやSVNなどのバージョン管理ツールが導入されています。
しかし、個人で開発を行う場合は競合が発生することもないので、バージョン管理ツールを導入して開発を行った経験がありませんでした。
そのため、実際に初めて現場に参画したときは、結構戸惑いました。
最悪の場合、デグレしてしまうとバグを作ってしまうことだってある
これも開発現場であるあるなのですが、デグレという言葉があります。
これは、複数人で同じシステムを開発していると、Aさんが持っているファイルは最新だけど、Bさんが持っているファイルが古いまま作業を行ってしまっている場合に、Aさんがファイルを更新した後、Bさんが再度ファイルを更新してしまったせいで、Aさんの作業内容が全て消えてしまうといった現象です。
僕も参画当初、古いファイルのまま更新をかけて、やってしまったこともよくありましたｗ
ちなみに、古いファイルにバグがあった場合に、そのままシステムがリリースされると、運用を開始してから思わぬバグが生じたり、脆弱性によってシステムが破壊されたりすることもあるので、注意が必要です。
まとめ：実務経験を積むのは1年くらいでもいい
僕は実務経験は0でフリーエンジニアになりましたが、正直、上記のような壁にぶち当たることも多いので、1年くらいは実務経験を積んだ上で独立することをオススメします。
一番大きな理由としては “プログラミングスキル以外のスキル” を身につけることができるからです。
正直、プログラミングのスキルだけで言えば、十分に独学でも習得することが可能ですがそれ以外の、基本設計やテスト、バージョン管理ツールなどの知識は、実際に現場で経験を積まなけれあば身につきにくいので、そっちのスキルを身につけるための実務経験を積むのはとてもメリット大きいと思います。
しかし、チーム開発の概念などを学ぶのは1年で十分ですし、その間に会社でもプログラミングを業務で行い、家でも独学で勉強を進めれば、1年でフリーエンジニアになって年収を2倍にすることは可能です。
また、実務経験を積む際は、大企業とベンチャー企業の2つの選択肢がありますが、確実にベンチャー企業をオススメします。
理由としては、大企業はプログラミング以外の雑務や無駄な飲み会などが多いのに対して、ベンチャー企業であればプログラミングやチーム開発に特化して学ぶことができるからです。
これが定年まで働くとかなら、逆ですが、あくまで1年で独立することが目的なら、ベンチャーで経験を積むほうがコスパが断然いいです。
（正社員でもベンチャー企業であれば、多くのスキルを短期間で身につけることができるのでアリです。）
