零細業者・フリーランスがいかにして仕事を請け負うべきかについて
Twitterでこういうの回ってきまして。
鍵アカの後輩が「こんな、わけわからん相談してるようじゃダメでしょ」という趣旨の感想を述べており、それもまあそうだとは思うんですよね。会社で請負仕事やってたって、人が動く仕事の報酬に対する金銭感覚が１～２桁おかしい人、自分の要求を曖昧に言うことで無茶なことを言っていないような気に自分でもなっちゃう人を相手に立ち回ることが必要でして、サラリーマンだってそれに対処してやっていってる方々がいらっしゃるわけですから、仕事のそういう面をご存じないということは、いかに現実から隔離されたところに配されているかということではあるでしょう。
ランサーズやクラウドワークス、少し期間をさかのぼればさぶみっとのようなマッチングサービスで、「こんなの、お客さんまるでお金払う気ないでしょ。案件として成立しないでしょ」というようなものが山のようにあって、しかもそれがなんだか受注成立しているように見える、ということに、以前から強い疑問を持っていました。
ああいうところで仕事をこなすプログラマはおれの３倍速くてストイックなのでおれの思う額の５分の１でも請けられるとか、さもなければ、マッチングしたあとで常識的な案件内容に話し合って修正しているとかであればいいと思うのですが、もしかしてあんな無茶苦茶なオーダーを「案件」として突撃していって、まんまと燃やして倒れ伏してゆく副業プログラマとかフリーランスとかがいるのだとすると、なんか、こう、どうにかなんないのかなあという気がします。
零細・個人レベルの受託開発には、それなりの案件管理が必要です。多人数のチームが受ける場合とも違います。それについてちょっと書いてみたいと思います。
殿、それではまず屏風から要件定義を追い出してください！
何をしたらこの案件は完成で、お金を払ってくれるのか明らかにすること。これが、仕事の金額と期日を約束する前に必ず明らかにしなければならないことです。要件定義と言った方が業界的に通りがいいですが、敢えてこういう言い方をします。
要件定義はソフトウェア開発の重要な工程です。本来、全体の費用の数割がここに掛かってもおかしくないものです。しかし、総予算規模が数十万円であるような事案では、そういう理解はできません。本来、要件を精細に明らかにして初めて総費用と期間を言うことができるわけですが、小さな案件ではその要件定義にお金を払ってもらえる保証がないのです。
継続的な取引がある関係において、毎月の費用の範囲内で顧客が必要とするシステム改修等の見積・要件定義を行って、個別の開発案件とする場合は別途費用とする...というような場合には、（顧客が望めば）丁寧に要件を詰めてからGoサインが出るという開発も可能ですが、初めての見込客が持ち込んだ案件に対して、「それではまず要件定義に20万円」とかいった話が通ることはまれだと思います。先方は、まず見積りをとって、他社に相見積を...と考えているものです。
受注前の営業活動として、受注に至らなかったらタダ働きになってしまっても構わない範囲で要件聴取をして、そういう精度での見積もりを出さざるを得ないのが、小さなお仕事の特徴です。
何をしたらお客さんはゴールにたどり着けるのか
「何をしたらお金を払ってくれるのか」と「何をしたらお客さんは目的を達せられるのか」は、表裏一体です。なんとかという新しいサービスを公開したいのか、どこそこのサービスをこういう環境に移したいのか、いろいろあると思いますが、その目的を押さえることは最重要です。当たり前ですけど。
『簡単なキャンペーンサイトの実装です。』
キャンペーンサイトを公開するならサーバとURLが必要です。いつからいつまで公開するのでしょうか。その切替や公開中のサーバ運用は。サイトのランディングページが要るかもしれません。応募されたデータは最終的にどこに集積するのでしょうか。それは誰の手でシステムから抜き出して整理するのでしょうか。キャンペーン期間中の問い合わせにはどうやって対応するのでしょうか。
十分に要件を詰めていない状況でも見積もりの金額を言わないといけないという制約下でも、顧客のベーシックな目的を最低限満たすために必要な要素が何かは洗い出し、それらを誰が用意するのかを確認し、自分が提供するなら見積もりに費用を乗せなければなりません。
私たちは、見積りの時点において、この案件が完成するまでの全ての作業を精細にリストアップして値付けすることが土台できません。さっき述べたように、充分な要件定義を行ってもその費用が出るかわからないという段階で見積もりを出さないといけないからです。
それでも案件として成り立つように、工夫して大雑把な見積りを書き、進め方を交渉する必要が出てきます。しかし、交渉と言っても、顧客は、その目的の核心の部分だけは、妥協をすることができません。
「キャンペーンサイトを公開したい」という要求に対して「キャンペーンサイトの開発を８０％でやめて今回は公開しない」という妥協はあり得ません。開発の途中で「見落としてたけど、これがないとキャンペーンサイトが公開できない」という要素が見つかったら、絶対に「やってくれ」ということになります。
調整・交渉できればいいわけですけど、絶対やらないといけない追加要素という難しい要素ができてしまうわけですから、見積りの時点で足りない労力を振り絞って考えるべきことはここだということになります（あるいは、費用が取れないかもしれないとしても掛けておかないといけない労力がこれだということ）。
そして、細部にわたって要件を記述することまではできなくても、見積り対象のシステムに存在する部品（画面やモジュールなど）のリストは想定しましょう。「私たちが合意した見積もりにそんな部品は存在しなかったですよね」というレベルの認識違いではさすがに揉める余地がない見積もりを目指そうということです。こういうと我々請け側の目線に思えますが、言い換えれば「これらの道具をお作りしたら、お客様の目的がちゃんと果たせるか確認していただくことで、失敗しないようにしましょう」ということです。これは、事実であるし、私たちの本心のはずです。
確かにゴールまで行くとは言いました。が。
費用が少ないこと・品質が高いこと・開発期間が短いことからなる三角形の大きさは変えることができない（トレードオフの関係である）、といいます。また、いまから作ろうとしているものがどれくらい困難で、その三角形がどのくらいの大きさになるのかは、開発をする前においては予測をするしかなく、特に要件定義が完全でないときには変動幅が大きくなります。
案件の目的を果たすうえで必要と見積もった要素のリストを見せられれば、お客さんも「これで間違いなくお客様の目的が果たせると断言できますよねと言われても、心配ですよね。後になって、あ、これも必要だったとなるかもしれないですよね」ということを、理解してくれるはずです。（「それはお前らの責任である」と一方的に言ってくるような相手であれば、請けるのをやめましょう）
そこで、案件をちゃんと着地させるための仕掛けを話し合います。
- 開発過程で要件定義を労力をかけて行って、開発範囲を合意し、費用を修正する
- 開発期間中に判明した追加要件や改善事項、要望の変更を随時取り入れる代わりに、開発対象の要素のうち＋α的なものを対象から外して調整をする
おおむね、このどちらかか、その混合です。
我々は何を売っているのか
フリーランスの心得的なことをいう人には、期日を守るみたいなことの重要性を説く向きがあるようです。それはもちろん、約束したこと・予告したことを遂行するという原則論として重要なのに異存はないのです。ただし、我々のような零細な業者が提供する価値というのは、高い精度で予定が立って、それがつつがなく遂行されることではありません。そういうのは、中規模以上の企業が提供します。彼らは、十分な資源を投下して、案件をカタい仕事にして、つつがなく遂行することにたけています。
我々は、それはできないので、案件状況に柔軟に対処することで、状況によって変更が生じはするけれども、期待値では安価に開発ができたり、費用の割には技術的に少し気の利いたことにチャレンジしても乗りこなしたりできる、といったところを売りにしています。そこで重要な誠実性というのは、予告を厳密に守るというよりも、状況を密に伝える、きちんと説明するといった方向性であると思います。
我々に仕事を頼むのは、大中企業にも相見積をとってみて、目ん玉が飛び出た状態で我々のところに来た顧客であったり、どこの会社も「やったことがないので無理っス」というんだけど、やってみたら紆余曲折があるかもしれないのは分かったから、調整に応じるから、やろうよという顧客だったりします。
私たちは、ガチガチに踏み固められた橋ではないところを、うまくバランスをとって渡り切る能力を売っています。明瞭に与えられた仕事を勤勉にこなせばオッケー（勤勉にこなすのがポイント）という人種では、ないのです。そこを間違えて泳ぐと、泥水にむせて、おぼれます。
