準委任の請け方

後でまた整理をしたいのですが、ちょいと喫緊で説明をしたほうがよい状況が出てきてしまったので、半ば私信に近いですが、一旦記述します。
「半ば私信」なので、身もふたもない記述も多いので、その辺はお目こぼしいただければ幸い。

さて。
請負は「発注側有利」ですが、準委任は「受注側有利」になります*1。
んで、ぶっちゃけますと。うちらのお仕事は「基本的には準委任のほうが契約的には安全なんじゃないかなぁ」と思う事しきり。

なんでか。
んと………請負で。「完了条件」が、クリアかつ明確かつMECEかつ計測可能で誤解の余地のない状態で存在するのであれば、本来的には「請負だろうが準委任だろうが金額は変わらない」はずなんです。

だって「同じ作業」なんだもん。

勿論、一方に「受注側(＝開発側)」の見積もりの精度、ってのはあるのですが。
もう一方で「どれくらいの"想定外タスク"が発生するか」ってのがありまして。
端的にぶっちゃけると、そもそもとして「完了条件をしっかりとクリアかつ明確に出す」のって、結構なスキルと結構なコストがかかるです。
だって端的に「一度、脳内で全部システムを組み上げないと」わからないわけだし。

もちろん、発注側としては大前提として「システムを完成させてほしい」ってのがありますし、ただ一方で「詳しくとか言われても専門家でもないのにそんなにクリアに明文化とかできるかい」ってのもあれば「"やってみて気づく"事だってそりゃあるよねぇ」ってのは、それはそれで理解できます。
だからまぁ「当初の具体的なお話には出ていないかもしれないけれどもそれがないと"完成したシステム"にはならなくて困るんだから当初想定のお見積もりで全部作ってよ」、と、まぁそうなるわけでございます。

その辺から、よくあるのが
・「仕様の明確化とか抜け漏れのない要求とか」そんな高コストは払ってられない
・からとりあえず「なんとなくこれくらい」で見積もって受注して欲しい
になって。
大体は
・大丈夫、ちゃんと配慮してあげるから無理無茶は言わないから後で美味しい案件も回すから
って言われるんだけどいざ作業が始まると
・あれも追加、これも変更、それも足りない、これも必要
になったうえで
・請負なんだから金額は増やさないけどこっちがOK出すまで全部やれ
って話になるです。………えぇもちろん「ごくまれに」ですが*2。

「過去に小さな案件でスムーズにいった」としても、次の案件とかで「先方に何かがあった瞬間」に豹変、とか、割とありがちなお話なので、気を付けたほうがよいです。
………まぁそもそもとして「下請法*3とか知ってるのかしらん？」 とか思ってみたりみなかったりするのですが、おいといて。

その辺の諸々を考えると
・準委任でお願いします
ってほうが、まだしも「マシ」なんですな。
受注側は「むやみな追加変更を避けられる」し、発注側も本来的には「がっつりした発注書を作らなくてすむ」ので＆予算が確保できるんなら「ある程度、我儘も言えるから」。
もし「あれも追加、これも変更」ってなったら、基本的には「作業時間が増えますんでお支払いが増えますまいどありチャリン」って会話が可能で、泣き寝入りせずにすみますし、受注者も(ある程度)気持ちよく変更を受け入れてくれます*4。

ここで「そんな事したらビジネスが回らないので(スコープは可変だけど)金額だけは固定でお願いしたい」とかいう方は「下請法で禁止されてるようなことをやらせたいんですね」で以上終了なのでお帰りくださいませ。

ただ、準委任って、ものすごく悪い見方をすると
・ダラダラとお仕事時間を引き延ばしてお金をもらいつつ
・やっている仕事の品質もめちゃくちゃで
・仕事を完成もさせずに途中でほっぽらかす
とか可能なわけです。
発注側としては、だいぶんと無視できないリスクなんじゃないかなぁ、と。

なので。
「準委任を、できるだけ発注者側にリスクの少ない形でご提案」とかできるとよいんじゃないかなぁ、とか思うわけですよ。
そうしないと、お互い疑心暗鬼だしね。

まず品質については、下限は「善管注意義務」あたり。
ただ「そこだけ」だとだいぶんと色々、アレがナニなので。「これくらいのスキル持ってて、これくらいの品質を担保しまっせ」ってお話はちゃんとしておいたほうがよいです*5。
個人的によくあってよくやるのが「Webアプリ作るときのセキュリティ」。「IPA準拠」は、わかりやすくも好ましい指針の一つかと思われます。

お次が「仕事の完了」ですが、これについてはまぁ「頑張ります」としか。
言い方を変えると「途中で逃げ出したくなるようなやらかしがなければやり遂げます」と。この辺はまぁ信頼関係ですな。

ラスト。一番大事なのがご予算。
発注側が「請負にしたい」理由の割と大きな一つがここで、つまり「この事案、おいくらかかるの？」ってあたり。
先方にしても「社内稟議とか通して予算をもぎ取ってきている」関係上「予算をオーバーされると色々と社内的にツライ」とか、事情はあると思うのです。
なので、その辺に配慮をしてあげると、色々とお互いに幸せになりやすいんじゃないかなぁ、と。
ちなみに、丁寧に設計しても「当初想定の1.4～1.6倍」くらいになる事が多いので、その辺を踏まえた上で予算を確保しておくとよいです。
「雑な設計」なら、1.6～1.8倍程度。2倍を超えるようだと「想定が甘すぎるか、要求仕様のツメが甘すぎるか、前提条件に誤りがあったか、途中でお話がコロコロ変わっているか」のいずれかである事が多いような。

でまぁこの辺。
やり方は色々あろうか、と思うのですが。おいちゃんは、以下のようにやることが多いです。
・まず「予算」を確認
・ある程度細かい目にマイルストーンを引いて「ここまでに何時間(＝おいくら円)」のスケジュールをざっくりとlocalで作成＆受発注者でスコープ*6を合意

って下準備をして。
あとは
・マイルストーンで「遅れそうな気配」がした時点
で、速攻でご連絡。
おいちゃんは
・「遅延確率20%くらい」で、一旦軽くご連絡：ちょっと不安がよぎったので、軽くご連絡いたします
・「遅延確率40～50%くらい」で、原因分析を含めてご連絡：この辺に起因して、遅れそうな気配があるのでご連絡いたします
・「遅延確率70～80%くらい」で、確認を含めてご連絡：このままだとほぼ確実に時間(＝お金)が伸びますが、どうしましょう？
ってな感じかなぁ。
この手の連絡は「早め早め」のほうが、先方も「寝耳に水」にならんですむので、割合と安心感があると思うのです。

とか、まぁまぁ。
フリーランスとかでお仕事をいただく時の「一つのヒント」くらいにでもなればなぁ、と。

*1:断言

*2:察しろ

*3:必須科目なのでちゃんと調べておきましょう

*4:受注側発注側とも「限度」はあるけどな

*5:これがあるから、発注側は「受注者のスキルレベルを判断する」すべを持ったほうがよいですし、持たないと色々と自殺行為だったり博打だったり

*6:「何を作るか」よりも「何を"作らない"か」の合意のほうが大切だったりもしますねぇ