こんなフリーランスとは一緒に働きたくない5つの特徴

はじめに

はじめまして。フリーランス IT エンジニアの人見琢也です。
最終学歴は東京大学大学院情報理工学系研究科創造情報学専攻修士で LISP の神様竹内郁雄先生の研究室出身です。

私のプログラミング歴は 20 年以上になりますが、IT エンジニアとしてのキャリアは、学生の時に起業した会社のサービス開発からスタートしました。その企業は泣かず飛ばずですでに精算しましたが、それ以来、フリーランスITエンジニアとして複数の企業のプロジェクトに参画し、一度も就職したことはありません。

フリーランスITエンジニアになって 10 年以上経ちましたが、その間私は次の 2 つのことを心がけてきました。

1. プロダクトへの貢献を通して企業の成長を手助けする
2. 仕事の成果はこれからプロダクトに関わる人を含めて全員にわかりやすい状態で共有する

この考えを基に仕事をしていると、他のフリーランスITエンジニアの仕事の仕方が気になることが多々ありました。
この記事では、私が一緒に働きたくないなと感じたフリーランスITエンジニアの特徴を 5 つあげたいと思います。私の考えに賛同してほしいわけではなく、読者のみなさんがこれから仕事をする上での働き方を考えるきっかけになれば嬉しいです。

こんなフリーランス IT エンジニアとは一緒に働きたくない

ソフトウェアテストを書かない

ソフトウェアテストが書かれていないプロダクトを前に、リファクタリングをしないといけない状況は絶望しかないです。

テストが書かれていることはプロダクトを通して企業の成長を手助けする上で非常に重要です。

プロダクトにテストが書かれていないと、保守性の低下、開発効率の低下、セキュリティリスクの増加、開発者体験の悪化などを通して間違いなく企業の成長に対して負の影響を与えます。

テストを書くことの重要性が認識されるようになって久しいですが、未だにテストを書かないプログラマーが一定数います。

プログラマー歴が浅い方であればテストの書き方がわからないこともあるでしょう。しかし、一定の経験を積んだフリーランスITエンジニアが、企業のプロダクトにテストを書かないのは論外です。

既存のコードにテストが書かれていない場合も、自分が書いたコードに対しては最低限テストを実装するようにしましょう。
どういうテストをどのように書けばいいかわからない人は[単体テストの考え方/使い方]が大変参考になります。企業の成長の足を引っ張るのではなく、品質の高いプロダクトを開発して、企業の成長を後押しできるエンジニアになりましょう。

プロジェクトの進捗状況をオープンにしない

フリーランスの立場で仕事を一人で抱え込んで突っ走る人は、プロジェクトが失敗したらどう責任を取るつもりなのでしょうか。怖くて一緒には働けません。

フリーランスITエンジニアは企業の成長を手助けする上で黒子に徹するべきです。
合意形成や開発の過程は常に他のチームや経営者に対してオープンにし、チームとして仕事を進めることを意識しましょう。それが責任の所在を会社全体にし、あなた自身や開発メンバーを守ることにもなります。
過去に自分と意見の合わない人はどんどん MTG から外して、自分の意見に従う人だけのプライベートチャットで MTG をするプロダクトオーナーがいました。彼は、他社のプロダクトの UI がとてもかっこよかったので、新規開発するプロダクトもそのような「見た目」にしたがっていました。

当然、機能やドメインモデルの設計をすると UI と齟齬が発生するのでデザインを変更するように言いましたが、UI デザインを頑なに変えようとはしませんでした。

そんな状況なので、複数のメンバーが心的なストレスで抜けていき、私もしばらくして会議に入れてもらえなくなりました。最後まで見届けることはできませんでしたが、プロジェクトが上手くいかなかったら、自分のやりたいことを会社のお金とリソースを使ってやったと判断されて損害賠償を請求されても仕方のない仕事の進め方でした。

プロジェクトの進捗状況は常にオープンにすることを心がけましょう。

ドキュメントを残さない

いなくなったメンバーがドキュメントを残さずに書き散らしたコードを引き継いだ経験のある人は全員共感できると思います。
仕事の成果はこれからプロダクトに関わる人を含めて全員にわかりやすい状態で共有する必要があります。ドキュメントはそのための非常に有効なツールです。どういった背景でアーキテクチャやライブラリを採用したのかなど、最終成果のプログラムだけではなく過程も含めてドキュメントとして残すようにしましょう。その情報はリファクタリングする際や、運用の際に必ず役に立ちます。

ドキュメントが無いと、リファクタする際に変更や削除をしていいのかすぐに判断ができず、最初にコードを書くためにかけたのと同程度の労力と時間を調査にかける必要があります。結果として、あなたが企業のためにした貢献以上の負債を残すことになります。

コードだけではなくドキュメントもしっかり残して、企業に負債ではなく資産を残しましょう。
ドキュメントの重要性については[スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ]が参考になります。

公式ドキュメントを読まない

実装の方法がわからない、エラーの原因がわからないと相談を受けたときに、公式ドキュメントのここに書いてありますよと答えた回数は数え切れません。
Web のフロントエンドフレームワークや、バックエンドフレームワークをプロダクトに採用している場合は、そのフレームワークの公式ドキュメントを一度は最初から最後まで一通り読みましょう。フレームワークにはフレームワークの開発者が想定する標準的な使い方があります。

その標準的な使い方を把握せずに、動けば何でもいいと独自の方法で開発することは、不必要にプロダクトに対する認知コスト、メンテナンスコスト、学習コストなどを高めます。さらに、開発中に遭遇する多くの問題は公式ドキュメントにすでに解決方法が書かれていることが多いです。公式ドキュメントに書かれている内容は自己解決できるようにしましょう。

特に Rails エンジニアのようにフレームワーク名を指定して採用されたエンジニアは、定期的に公式ドキュメントを見直して、いつも最新の知見を提供できるようになると喜ばれると思います。

俺の考えた最強の〇〇をプロダクトで試す

企業のお金を使って、プロダクトで遊ばれたら困ります。

自分が一番興味のある技術や言語を使ってみたいという動機から、プログラミング言語やフレームワークを選択する人がいます。CTO や正社員などその企業に長くいて、選択の責任を取れる人がやる分には全く問題ないです。

一方で、フリーランスITエンジニアの立場で決定に携わる場合には、その企業の既存プロダクトの整合性や、正社員の技術スタック、エンジニア採用のしやすさやメンテナンスコスト、フレームワーク自体やそのユーザーコミュニティの成熟度などを鑑みて最も合理的な選択をしましょう。参画企業のプロジェクトはフリーランスITエンジニアに成長の機会を与える場所でもなければ、（PoC 案件を除き）実験対象でもありません。試したい技術があれば自分自身の個人プロジェクトでやりましょう。
あなたがいなくなったあともそのプロダクトは開発・運用され続けることをイメージしましょう。

おわりに

この記事では私がフリーランスITエンジニアとして働く上で大切にしている考え方を基に、こんなフリーランスITエンジニアとは働きたくないと思う特徴を 5 つ提示しました。考え方に共感できる部分に関しては明日からの仕事に是非取り入れてください。読者のフリーランスITエンジニアの方にも、仕事をする際の考え方や哲学を共有してもらえると、私も他のフリーランスITエンジニアの考え方に興味があるので嬉しいです。

現在学生の方や、正社員のエンジニアの方は考え方の違いや気付きはありましたでしょうか。今後の働き方を考える上で、参考になれば嬉しいです。経営者の方にはフリーランスITエンジニアの考え方を知ったうえで、うまく開発に取り入れていただけると嬉しいです。