0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

フリーランスエンジニアとして案件参画するかどうか判断するためのチェックリスト

Posted at

はじめに

今年(2024年)からフリーランスエンジニアとしてのキャリアを始めました。

新卒で入社した2017年から2023年までは正社員として会社に所属しながらエンジニアをしており、その当時と現在のフリーランスエンジニアとで働き方や気をつけるべきことが違ってきているように感じています。

この記事ではフリーランスとしてエンジニアで働く際に気をつけるべきこと、特に案件を受諾するかどうかの時点でチェックしておくべきことを自分の経験に基づいて書かせていただきます。

チェックポイント

エンジニアチームの組織体制

ソフトウェア開発に対して理解を示している人間が会社の中に存在しているか、という観点となります。わかりやすい具体的な指標としてはエンジニアの数と言っても良いかもしれません。自分1人だけで開発業務を担う場合、非エンジニアからの非現実的な納期要求に対して論理合戦を行う手間が発生してきます。

また、エンジニアとは別に要件定義書の有無や機能要件を確認できるドメインエキスパートが周りに存在するか、その人物との連絡をとりあえるかもあらかじめ確認しておきましょう。

エンジニア組織内で、開発の納期間も正しく共有されているかも確認しておきましょう。非開発部門で納期が設定されていた場合でも、エンジニアチームにまで正しく情報が降りてきていて、可視化されている状態が好ましいです。

ポイント

  • ソフトウェア開発に対して理解を示している人間が会社の中に存在しているか
  • エンジニアが何人いるのか。自分が着手する業務に対するフォロワーなどはいるか
    • いないと、無茶な要求を無茶な納期で突きつけてくる人に対して自分自身だけで工数感を説得する必要がある。屁理屈のやりとりに時間を食われてしまう
  • 要件定義所orドメインエキスパートの存在、または要件の確認を行える人物がいるか
  • 納期が共有されているか

業務内容の確認

契約時に提示された業務内容と参画した後の実際の業務内容に差異がないか、あらかじめ確認しておきます。例えば、クラウドインフラ領域の業務を任される予定だったのが急にモバイルアプリの開発を任されるといったことが可能性としてあり得るかの確認をしておきましょう。基本的には得意ではないor未経験でいきなり別の領域を任されることはないと思いますが、クライアント側が開発に疎い場合、ソフトウェア開発の領域を理解せずに、丸投げで依頼されることがあるため念の為注意しておきましょう。

ポイント

  • 契約前に提示された業務と実際に行う業務内容にズレがないかどうかの確認
  • 安請け合いせずに、得意な領域を案件で引き受けたほうが事故は少ない

開発環境

開発を行う上での環境がどれくらい整っているのかも確認しておきます。PC、対象となるプロジェクトのgitリポジトリが閲覧できるか。各種リポジトリなどの権限を依頼すれば付与してもらえるかどうかなど確認しておきましょう。

また、実機上でのテストを実施する必要がある際には、対象となる端末をどのような形式で貸与してもらえるかも確認しましょう。端末数が少ないので、オフィスまで出社する必要があったり、自前の端末を利用しなくてはいけないのかなど、あらかじめ確認しておきます。

ポイント

  • 開発環境がどれくらい整っているのか
  • モバイルアプリなど、実機の種類が多い場合に、会社側で実機を十分に担保できているか
    • デバイス数が不足していて、その都度会社に出社するなんてケースもあり得るので確認しておいた方が良い

開発計画・見積もりの意識

自身が担当するプロジェクトの納期感が健全であるかどうかもあらかじめチェックしておきましょう。あらかじめ納期だけは確定しているものの、機能要件が不確定であったり、自動テストや、性能テストなどといったところまでの時間が考慮されていない現場は要注意です。一度減らされた工数を後から復活させるのは何かと理由づけが必要であるため、工数を伸ばすための工数が発生するという状況になってしまいます。

ポイント

  • 納期までに品質担保されたものが現実的に間に合うか理解できる人間が自分以外にも存在する現場であること(エンジニアのリーダー層以上の人物が好ましい)
    • 無茶な納期感のプロジェクトに一度契約してしまうと、その契約期間内で無理やり実装することを要求されて、品質の悪いものを納品することになってしまう
  • 調整係のプロジェクトメンバーではなく、エンジニア自身が見積もりをする文化があるか

エンジニア文化

継続的に開発を進めていく上での環境が整っているのかもあらかじめ明らかにしておきましょう。特に自動テストの有無や社内wikiのようなドキュメントを作成する文化があるかどうかは良い指標となるでしょう。

ポイント

  • 自動テストがあるか
  • esaやnotionなど、引き継ぎ、ドキュメント、共有の文化が存在しているか

さいごに

自身が案件を受けるかどうかを判断する際のチェックポイントを書かせていただきました。

これ以外にも、ライフワークバランスの重視やどの開発領域を担当するか、などといった様々な判断基準があると思います。

フリーランスの場合、契約更新のタイミングではなく自身の意思で案件から撤退する際には基本的にクライアント側の同意が必要となるため、正社員よりも手続きが面倒になりがちです。

不本意なトラブルや手間に遭遇しないためにも、契約する前に本案件がいわゆる「地雷」案件ではないか正しく把握することを心がけましょう。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?