プロフィール

フリーランスのJavaエンジニアです（エージェントから案件を紹介してもらい客先に常駐）
フリーになってから今年で4年目
業務系Webアプリケーションの開発が得意です
最近はECサイトの開発も多いです

以下、業務系アプリの開発に携わる人向けに書いています。ご了承ください。

休みすぎない

フリーのエンジニアに多いのが欠勤。午前半休です。
聞くところによると本当に多いらしく、普通に休まず出勤し続けるだけで評価されるそうです。

現場の文化になじむこと

どこでも通用する知識（プログラミングスキルなど）を持つことは確かに大切ですが、その現場の文化を知ることも大切です。

どんな顧客？（SIer？エンド直？）
自社の位置づけは？（自社は○次受け？　他社と分業で開発を進めている場合、自社はどの部分の開発を担当しているのか？）　
どんなプロジェクト管理をしているのか（JIRA? Backlog? Redmine? Trac?）
どうやってソース管理しているのか（SVN? Git?）
各開発メンバーの役割分担
メンバー内のコミュニケーションの取り方は？（Slack? IPMessenger? チャットと対面どっちが多い？）
コーディングルールは？

現場の文化に馴染むことができなければ、どんなに汎用的な知識を持っていても、聞く耳を持ってもらえません。
文化にうまく馴染めずプロジェクトを去るのは、人それぞれ向き不向きや好き嫌いがあるので仕方ないことですが、馴染もうとしないエンジニアはこの先ツラいと思います。

いろいろ質問できる人を確保しておく

参画して最初の頃は、マンツーマンで教えてくれる人を１人確保していくと良いと思います。参画前の面談で、現場への要望として挙げておくのもアリでしょう。
できれば、その人の隣の席で作業できるとさらに良いです。

余談ですが、席の場所って意外と重要です。場所が悪いせいでコミュニケーションに支障をきたしているエンジニアも多いです。

そして、一度聞いたことは付箋アプリなどで、いつでも目につくところに細かくメモしておきましょう。
とにかく何でもメモること。そして一度聞いたことはあまり何度も質問しないこと。

メモったことは他のエンジニアのナレッジにもなるように、Backlogのwikiなどにまとめておくと良いです。

環境構築は迅速に

初日でアプリを起動、各画面の遷移、動作確認くらいまで終わるくらいのスピード感を目安にしておくと良いと思います。
環境構築が早く終わると、周りの人からの期待値が上がり、エンジニアとしてのスキルを信頼されます。

システムの全体像を早くつかむ

とにかくいろんな画面、機能を触って遊んでみて、システムの全体像を掴みましょう。
全体像をつかむとはどういうことかというと、

システムが導入された目的を理解している（何のために必要なシステムなのか）
システムフローをある程度把握している
業務フローとシステムの機能の対応関係を理解している

全体像を掴んでおくと、

機能追加、バグ改修の時にその目的がすぐに分かるようになる。
「こうしたらもっと良くなる、使いやすくなる」といった提案がしやすくなる
「ここを修正するなら、この部分にも影響がある」といったリスクをすぐに洗い出せる

結果的に余計なバグ・手戻りが発生しにくくなります。

また、遊びまくってシステムが動かなくなると困るので、いつでも元に戻せる手順は知っておくこと。（DBのダンプ＆リストア、必要なマスタデータなどをメモしておく）

他のソースをうまく流用する

いろんな意見はあると思いますが、まずはその現場の文化（=コーディングルール、アーキテクチャ）に溶け込むのが良いかと思います。
他の画面、機能のソースを流用した方が早く実装でき、品質も十分なものができるのであればなるべく流用します。
変に独自のソースを書こうとせず、可読性を重視すること（他の人が読みやすいコードを書くこと）。

DBの知識は必須

基本的なSQL（SELECT, UPDATE, INSERT, DELETE, JOINなど）が書ければ十分です。
要は、自分が探したいテーブルのデータを難なく引き出せるかどうかです。

いろんな現場を経験していると、テーブルのカラムをざっと眺めて、「このカラムはこういうことに使われそうだな。。。」という予想ができるようになり、仕様の理解をサポートしてくれたりします。

また、個人的にはER図（これが用意されている or メンテされている現場はあまりないかも…）と画面遷移図を照らし合わせながら、システム全体の仕様が読み解けるようになるとさらに良いです。

ユーザーの気持ちになって実装する

ユーザーが使いやすいように機能を実装すること。
ラクな実装ができるかを一番に考えるエンジニアは多いですが、結局ユーザー側の仕様変更によって覆ることが多いです。そして面倒な実装をせざるを得なくなってしまうことも多いです。
そこで、面倒になりそうだけど何とかしてラクに実装できないかを考えます。ここがエンジニアの腕の見せ所な気がします。
独りよがりにならないように、他のエンジニアにも相談してみましょう。

汎用的なテスト観点はストックしておく

業務系のWebアプリであれば、どの現場でもテスト観点は似たようなもの。
汎用的なテストケースは自分の中でストックしておき、どの現場でも使えるようにしておけば、それほど時間をかけずに単体テストケースを作ることができます。

できれば結合レベルでテストケースが作れると良いです。
システムフローの前後の機能との連携を意識してテストしておくと、結合テストでの手戻りが発生するリスクが減ります。

自動化、効率化するツールを作ってシェアする

個人的には、マスタだけダンプ＆リストアするツールとか重宝してます。
自分が役に立つと思ったツールは積極的にシェアしましょう。
環境構築・テストの自動化もガンガンやっていくと良いと思います。

フリーランスのITエンジニアとして生き抜く方法