どうも、進捗とかスケジュールって言葉が大嫌い苦手なフリーランスのたけです。
面白いエントリが話題になってたので、いっちょかみしてみます。
フリーランスに仕事を頼むなら、多少値が張っても「仕事が早い人」に頼む。
1週間・1ヶ月で80万とか270万とか、プログラマの方を想定されてるのでしょうか、80万の見積を書いただけでもビビる零細フリーランスとしては、羨ましい限りです。
元エントリを読んで、どうも微妙な感じがしたので、制作者側からの意見を述べてみます。
もくじ
そもそも見積の時点で相手のスキルを判別するには？
そもそも正確なスケジュールを出すには、正確な工数の見積が必要で、正確な工数の見積には、ひっくり返らない仕様が必要です。ひっくり返らない仕様を屏風の中から出してください。
発注前に、どれだけガチガチに仕様が決まっているのでしょうか。見積の段階で出したスケジュールがどれだけ速いか、それでスキルがわかるかというと、制作者側としては「そこで見られてもなー」となります。どちらかというと、スケジュールを決める段階でのヒアリングで、「どれだけ仕様を詰められるか」こそが、制作者の実力が見える所だと僕は思います。仕様を詰める＝どういったものを作ればいいかを具体的に考えているわけで、それによって工数も予算も当然変わってきます。また、今までの経験や知識から細かい所まで詰められるので、スキルも必然的にあがってくると見ていいでしょう。
正確なスケジュール＝正確な工数の見積＝正確な仕様です。
そして正確な仕様を出すには、密度の高いヒアリングが必要になります。
仮に仕様がガッチリ決まったとして、オンスケで進行するためのネックは？
さて、仮にヒアリングを元に仕様がガッチリ決まったとして、それが本当にオンスケで行くのでしょうか。
「2.仕事が早ければ、プロジェクトは早く進み、結果として投資対効果が良い。また、手戻りがあったとしても対応が早いので、プロジェクト全体への影響が少ない。」とありますが、ネックはここです。手戻りがどれだけあるか。
デザインだと相手の好みに振り回されてしまう場合もありますし、担当者レベルではOKでも、いざ上司に見せたら・・・的などんでん返しはよく耳にすると思います（これをうまくこなすのがディレクションの腕の見せ所ですが）。
プログラムでも、仕様変更や追加の仕様があれば、工数が増えるのでスケジュールが延びて当然・・・だと思うのですが、なぜかスケジュールが延びないことが多いです。もしくは追加の仕様を諦めてもらえなかったりします。おとなのせかいはふしぎですね！！！ぼくよくわかんない！！！あたらしいこくりつきょうぎじょうのやねはどうなるの！！！
スケジュールを守らなければいけないからこそ、バッファをとる
というわけで、正確な仕様が決まっても、必ずしもオンスケで行けるとは限りません。「3.仕事を早く終わらせる約束をするのは、相当の責任感を伴う。」とありますが、だからこそ、スケジュールはゆるめにとります。
作業工数＝スケジュールではありません。少なくとも「実際の工数＋お客さんのチェック期間」が、スケジュールです。
オンスケでやるには、お客さんの協力も必要になってきます。
ガッチガチにスケジュール組んでもいんですが、デザインなら修正回数を明確に切ったり、お客さんの返事もきっちりスケジュール通りに頂く必要があります。が、お客さんとしては、少なくはない金額を払ってるから、少しでも納得できる成果物が欲しいでしょうし、そもそも自分ではできない・忙しいから、他社に頼んでるわけで、本来の業務で忙しい時には、「ごめん、ちょっと待って」となるのが現実ではないでしょうか。
スケジュールは、制作者だけが守るものではなく、資料の提出やチェックの納期など、お客様側にも守って頂かなければ成り立たないものです。
逆に、スケジュールを厳守するために、追加の仕様や仕様変更があっても徹夜続きで対応というのは、こちらがシンドイだけです。
何より、web制作では、他社の引継ぎだと思わぬトラップが紛れ混んでることが多々あります。ぶっちゃけゼロから作り直した方が速いなんてこともあるわけで、そうなるとスケジュールも余裕をもって見積もらざるを得ません。「普通にやればこれくらいでできる」と思っていても、想定外のトラブルが潜んでいるなんてことは、よくあります。
経験があるからこそ悲観する
森博嗣は『創るセンス 工作の思考』にて、こう述べています。
第一のセンスは、やはり「悲観」あるいは「心配性」という基本姿勢である。優れた技術者に共通する感覚といっても良い。（中略）
どうして悲観的になるのかといえば、これまで多くの失敗を実際に見てきたからだ。奇跡的に上手くいくこともときどきあるが、普通は必ずなんらかのトラブルが起こる。だから、そういったものを見越してプロジェクトに臨む、というのが技術者の基本である。（100P）
さらにこう続きます。
こういう話をすると、「いや、トラブルが起きないようにするのが本来あるべき姿だ」と言う人がいる。しかしそれは「言葉だけの理想論」であっって、まったくリアリティがない。そんな言葉をいくら重ねても、失敗やトラブルを根絶することはできない。（101P～）
と精神論をバッサリ切っています。
そのまま次の節はまさに「時間的余裕を作る」とあり、
トラブルは起こる。だから、怒った時にどうすれば良いのか、というバックアップの方策を事前に立てておく。最も簡単で万能な対策は、「時間的に余裕」を見ておくことである。ギリギリのタイムスケジュールは、ものを作ることを限りなく困難にする最悪の条件だ。(102P)
と続きます。
さて、ここで優秀な技術者と、そうでない技術者が出すであろうスケジュールの根拠を見てみましょう。
優秀な技術者は密な要件定義に基づいて、
・制作側の工数＋お客さんの工数（と都合）＋トラブル対応＝スケジュール
となります。
そうでない技術者は、
・制作側の工数＋お客さんの工数＝スケジュール
くらいしか見てないかもしれません。蓋を開けてみたら、仕様も変更になるかもしれないし、トラブルだって起きるかもしれない。そうなると、スケジュールだけでは、相手のスキルはわかりません。
余裕のあるスケジュールが組めればそれに越したことはありませんが、まあ世の中いろんな事情があるわけで、なかなかそうもいきません。フリーランスとしては、納期が延びると入金も延びるわけで、スケジュールが緩い案件バンザイ！ともいえません。制作者とお客さんが協力し合って、仕事が進めていきたいものです。
ダラダラ書いてみましたが、まあルーズなフリーランスの戯言だと思って頂ければ。。。
ちなみにバッファをとってスケジュールを組む僕は優秀な技術者かというと、ケアレスミスが多いので正直手戻り多いですごめんなさい｡ﾟ(ﾟ´Д｀ﾟ)ﾟ｡
お目汚しいたしました。