新規案件を請ける時に気をつけていること
今回は、フリーランス専業になって数ヶ月経過した僕が、新しく案件を請ける時に気をつけた方が良いな、と思っている事を書いてみます。
おそらく、フリーランスに限らず、社内プロジェクトに新しく参加した場合とかでも一緒なんだと思います。 普通の会社に在籍したことがないから良く知らないけど。
よくこの手の記事では、契約の範囲や賃金などについて語られますが、ここではそういった事には殆ど触れていません。（僕も詳しくないんだ、すまない。）
ちなみに、請け負うプロジェクトが以下のことに当てはまる場合、特に顕著に効いてくると思います。
- 在宅/リモートワークである
- 今まで一緒に仕事をしたことのある人が少ない
- 緊急の案件である
1. プロジェクトの状況を把握する
プロジェクトが完全に初期の空白状態、という事は稀です。どんなにまっさらなプロジェクトでも、以下の様な事が決まっているはずです。
- ターゲットとなる顧客
- 与えたいベネフィット
- 大まかな規模感
もし、これら決まっていない場合、まずはそこから決めないとプロジェクトが失敗するのは明白なので、促しましょう。
また、もう少し詳しいものだと、他の人がプロトタイプを作ったことがあったり、既にデザイナーへの発注などによって画面の基本構成が決まっていたり、まぁ多種多様です。
とにかく、現状把握には多少の時間がかかります。
必要以上に情報を隠したがる方とは仕事をしない、というのも視野に入れて良いと思います。 仕事しにく過ぎるので。
1.1. 人的な現状を把握する
既に参加している人に、プロジェクトに関係する人と担当範囲を列挙してもらいましょう。
スキルセットや契約の形態まで聞けるとベターです。 他にやっていることがあって片手間の人かもしれません。 あなたより経験の浅いエンジニアかもしれません。
ちなみに、発注者がプロジェクトに関する全容を知らなかったりするケースは、嫌な予感がぷんぷんするので、慎重に掘り下げて聞いていく必要があります。
1.2. 技術的な現状を把握する
プログラムやサーバー構成について、なるべく広い範囲にわたって把握しておいた方が良いです。
後から聞くのは面倒臭いので、一気に構成図とかを書けるぐらいまで聞いてしまうのがベターです。
2. これからの動きを明確化する
監査にきたのではなく仕事をしにきたのだから、現状が分かったら、これからの動きについて計画を立てていく必要があります。
2.1. 連絡手段・頻度を明確化する
Skypeが良いのかメールが良いのか、定例で事務所に行くのか、常駐なのか。
常駐だとしても、ミーティング頻度はどうなのか。 他のメンバーも常駐なのか。
そういった事もハッキリさせておくと良いです。
2.2. 担当する作業の範囲・期間を明確化する
ここまで出来てやっと、自分が担当する作業の範囲や納期を見積もることが可能になります。ここの順序を間違えないでください。おそらくは金額的な見積もりが出来るのもこの段階まで来てからです。
また、だいたいプログラマーは自分の能力を過信するので、自分の作業量はほどほどにしておきましょう。 1日のうち集中して作業出来る時間は3〜4時間程度だと思っておくと良いです。（実際そうだろ？えっ、そうじゃない？お前みたいなデキる奴のことは、知らん！）
2.2+. 周りと協調して動けるか想像する
担当作業をやっていればプロジェクトは完遂するでしょうか？以下の様な類いの落とし穴に気をつけてください。
- モバイルアプリを作っているなら、サーバーサイドのAPIはどうするのか。
- 追加機能開発なら、以前の機能や設計に問題があった場合にどうするのか。
- 完全に新規の開発だとして、仕様の変更はどの程度、出てきそうか。
- 現時点での不明瞭な仕様は誰が明確にするのか。自分？発注側？
- 今後、自分が抜けた後で誰がメンテナンスするのか
- ドキュメントをどのくらい整備すべきなのか
プロジェクトを完遂する
あとはプロジェクトを完遂しましょう。
3.1. プロジェクトが動き出したら、積極的に動く
自分の動く範囲は確かに明確化した通りなのですが、多少は「おまけ」しても良いでしょう。
自分が参画したプロジェクトが失敗に終わるよりは、成功した方が箔がつきます。
ついつい自分の作業範囲を小さく見積もりたくなりますが、先方の期待とはズレている可能性がありますから、動かしながら意識の摺り合わせをするのが良いでしょう。
おわりに
駆け足でしたが、数年間、いろいろなプロジェクトをやってきて思う所をざっとまとめてみました。
おかげさまで9月末までは、ほとんどイッパイイッパイですが、何かお仕事の相談などありましたら、お気軽にどうぞ。
