フリーランスのコーダーが見積もりするときにチェックするべきポイント

フリーランスでコーダーが見積もりする時にチェックするべきポイントをまとめておきました。自分の実体験をもとに作っています。

「俺のしかばねを超えていけ」系の記事です。自分の体験と反省を元に書きます。

WEBに限らず、IT系の仕事において何よりも大事なのは「事前確認」そして「認識のすり合わせ」です。

受注者と発注者でお互いがハッピーになるように、「事前確認」そして「認識のすり合わせ」はしっかり行いましょう。

この記事を読んでいただくことで、次のことがわかります。

フリーランスのコーダーが確認と認識合わせを行わないとどうなるか

人によっては知人から受けた案件で、ちょうど仕事が空いた時期だったりして、嬉しさのあまり、

契約書もなくサクッとWEB制作やコーディングをはじめてしまう人もいるかもしれません。

ただ、あらかじめ受注者と発注者の範囲を決めておかないと、特に受注者は以下のような状態に陥りがちです。

これらを回避するために、フリーランスのコーダーが案件の話をもらった際に確認すべきことを挙げていきます。

スポンサーリンク

フリーランスのコーダーが案件の話をもらった際に確認すべきこと

フリーランスのコーダーが案件の話をもらった際には以下のことを確認するようにしましょう。

詳細をみていきます。

デザインカンプの有無

まず、案件着手前に現時点でデザインカンプがあるかないかを確認しましょう。

photoshop、illustrator、XDなどのファイルで送られてくることが多いですが、

それらのファイルが今回コーディングをするページ分全て揃っている状態なのか、

それとも段階的に後日上がってくる場合があるのかということですね。

案件話をもらった時点でデザインカンプが出揃っていない場合はいつまでにもらえて、納期はいつ頃になりそうかを確認しましょう。

本来だと、コーディングを依頼された時点で全て揃っていることが理想的です。

全体の構成や仕様・デザインを見た上でCSSを共通部品化し、なるべく冗長なCSSになってしまうのを避けたいものです。

スマホ・タブレット版のデザインカンプが全ページ分用意されているか

デザインカンプがすでにある場合は、スマホ・タブレット用のデザインカンプも各々全ページ分存在するかどうかを事前に確認しましょう。

PC版のデザインカンプしかないけど、レスポンシブ対応をしてほしいという場合や、

一部スマホ用デザインカンプはあるけど、一部作成してないから空気を読みつつそれっぽくしてほしいは結構あるあるケースですが、

この対応をする場合、スマホ用のデザインをコーダーが担当することになります。

概ねこのパターンは「レスポンシブ対応をしたは良いけど、クライアントの意向に合わない」という状態が発生しやすいです。

つまり、正解がない状態で無限に修正する恐れがあります。

スマホ用のデザインカンプは必ずもらうか、スマホ用デザインの費用をいただくことが可能なのかを相談しましょう。

デザインカンプの詳細確認をしましょう（特に動きの部分）

デザインカンプの有無というところでもちょっと触れましたが、デザインカンプをもらった場合は詳細をくまなく見ておきましょう。

各々のページのボリューム感によってはすぐ終わるページだったり、一般的なページの４倍の長さだったりと様々です。

規則的な並びをしているシンプルで作りやすい１ページもあれば、規則的だと思わせといてイレギュラーな要素がある、ということもあります。

規則的な並びをしている中の１セクションだけのイレギュラーは要素がある場合は、

そこだけ要素を追加してクラスを持たせるなどしなければならないですし、そのイレギュラー要素に合わせて他の要素も調整しなければならない場合も出てきますので、

ちょっと手間がかかるということは用意に想像つきますよね？

またデザインカンプからはイメージしにくいCSSのアニメーションやJS処理で工数がかかることもあるあるです。

ハンバーガーメニューやトップページボタンなど、一般的によく見るアニメーションで実装経験があるものであれば良いですが、

そうでない場合は作業工数が伸びますので、事前に確認しておきましょう。

追加仕様の費用発生条件

デザインや仕様が変更になった場合、追加費用をもらえるのか否かということを確認しておきましょう。

画像や文言変更、パスの変更は無料で対応されているコーダーの方も多い印象ですが、

デザインの位置やJSの動きを追加・変更する場合など当初の仕様と違う要望が発生した場合の取り決めをしておきましょう。

基本的には発注者都合で仕様が変わる場合は、追加費用をいただくべきで、いくらぐらいかも取り決めをしておければベストです。

追加費用に応じてもらえる人が大半なのですが、

応じてもらえない場合は、いろんな追加要望をあれこれと無料で対応してくれないか（もしくは追加・変更ではなく修正的なノリで）とお願いされる場合もあるので、

案件自体をお断りするのがベストかと思います。事前のフィルタリングをしておきましょう。

固定ページ作成やテキストデータ流し込み作業が含まれるか否か

WordPress案件の場合、デザインをコーディングするのはコーダーの仕事ですが、

同一デザインの固定ページで数十ページ分のテキスト流し込み、などのコーディング以外の作業が必要そうな場合はその分の追加料金となるのか、

そうでないのかを確認しましょう。

こちらも先ほどの追加仕様の費用発生条件と同様に一度無償で対応してしまうと、「前は対応していただいたと思うのですが」という話になるので

基本的には事前確認が必要です。繰り返しですがこちらの作業負担分が増えそうであれば、断るか追加費用をいただくべきです。

納品条件の確認

何ファイルをいつまでにどこに提出すれば納品になるのかを確認しましょう。

この確認がないとゴールのないサッカーも同然です。

html/cssファイルでいいのかzipファイルかサーバアップか、などなど。

また提出して、誰からのOKがもらえれば納品となるのかも把握しておきましょう。

例えば制作会社からコーディング作業を受注している場合、担当者の検収で良いのか、担当者経由のクライアント検収なのかなど様々です。

コーディング規約の確認

コーディング規約をよく確認しましょう。

html/cssでも会社によっては書き方の基準があったり、使用できないフレームワークがあったり、会社で共通に使われているcssなどが存在する場合があります。

例えば、cssのフレームワークであるbootstrapを使わないでほしいということを認知せずに使ってしまった場合、

書き直しの手間がかかりますよね。

デザインカンプの内容が再現されていても、コーディングの方法をあとから変更してほしいと言われることもあるので、

コーディング規約はあらかじめ受領しておくようにしましょう。ない場合は過去の指摘事例などでも良いかと思います。

また会社で用意されているcssを読み込む場合、自分のクラスと競合して!important祭りになってしまうことも少なくないので、

制作会社さんのルールは熟知した上で着手しましょう。

ブレイクポイントの確認

どこで表示を切り替えるか、というブレイクポイントの確認は必ず着手前に確認しておきましょう。

これは客先とビジネス要件によって大きく違いますので、一概にどこが正解とは言えません。

デザインによって、画面幅1024pxでデザインを変えることもあれば、768pxで変えることもあります。

また、768pxだけの場合もありますし、768pxと480pxという場合もあり、様々です。

この確認がない場合、後からブレイクポイントの修正がきてしまうと苦しいですね。

一般的には既存サイトのユーザーのデバイス比率などを確認しつつ、ビジネス要件として設定されているべきかと私は思いますが、

まぁ設定されていないことが多いので、事前に確認しておきましょう。

画面伸縮時の表示の確認

例えばPC版のデザインカンプが1920px、主要コンテンツがサイズの内1000pxの範囲で作成されている場合を想定します。

この場合、ブレイクポイントの要件とも関連してきますが、例えば768pxで画面の表示を変える場合、

そこに到るまでの伸縮時（1440pxの時や1024pxの表示）はどうなるのか、ということです。

サイトによっては左右の余白を縮ませたり、ブレイクポイントを細かく設定したり、相対的な指定（％、vw、emなど）をしたりなどでリキッドレイアウト(例：https://www.apple.com/jp/)にするか

あるいは固定幅（mix-width:◯◯px）などで、親要素がある一定の幅以下にはならないようにして、

固定幅以下の時は画面が横スクロールできるようになる（例：https://dotinstall.com/）

など。どちらも一長一短があり、工数も当然違います。これはデザインの時点で確定されているべきことですね。

本来はWEBサイトのメインターゲットに合わせて、どういう風に画面を表示していくか、を予算制約に合わせて考えるべきかと思います。

どの画面幅にも対応できるリキッドレイアウトは理想ですが、当然工数は固定幅の場合よりもかかります。

ファイル構成・フォルダ構成・スラッグの確認

ページ内部リンクなどを後から設定する場合も多いですが、

後の修正をできる限り減らせるように、ファイル構成やフォルダ構成、Wordpressの場合は特に、

スラッグの命名規則などはあらかじめ確認しておきましょう。

これも後から修正となると地味に辛い作業です。また抜けやモレの出やすい部分なので、要注意です。

CSS設計方針

これは案件を受けてからでも良いかもしれませんが、例えば10ページのコーディングが必要な場合、

10ページの中でも使いまわせそうな要素、共通部品などをあらかじめピックアップしておきましょう。

全体の特徴（偶数番目の要素は必ず背景が灰色になるなど）を掴んで、共通法則・共通部分を洗い出した上でのコーディングが理想的です。

CSSが冗長にならず、メンテのしやすい記述になるような方法を考えましょう。

例えばhoverで画像が変わる場合は一つ一つ:hoverと記述していると辛いので、いっそJSで処理してしまうとかですね。

自分の平均的なコーディングスピードと照らし合わせて納期にバッファが取れそうか

これらの諸々を確認した上で、自分のコーディングスピードと照らし合わせて見て、かつスケジュールに予備日が取れることが理想的ですね。

どんなに確認をしまくっても、何かしら予期せぬ自体や認識のずれは起こりうるので、自分が最低限必要な日数＊1.2~1.5ぐらいの時間があると手戻りにも対応できるかと思います。

くれぐれもデザインを見ずにページ数だけ聞いて「やります」と言わないように。自分も大変ですし、発注者も辛いです。

検証範囲の確認

どのバージョンのブラウザか、何種類のブラウザか、の他、各種端末の検証の範囲をあらかじめ確認しておきましょう。

また、https://validator.w3.org/などで記述におかしい箇所がないかの確認など、

検証レベルによっても工数が変わってきますので、事前に確認しておきましょう。

スポンサーリンク

フリーランスのコーダーと関係者が仕事をしやすくするために

情報が整理されており、ゴールが明確、ルールが明確であると受注者も発注者も作業がしやすいですよね。

クライアント、デザイナー、ディレクター、コーダー、と関わる人数が増えるほど、コミュニケーションコストが発生していきますので、

前方よしとなるためには十分な事前確認と認識合わせが必要かなと思います。

ということで今回はここまでです。