はじめて開発を委託するクライアント様へ
はじめに
このnoteはお取り引きのある、あるいはこれからお取り引き予定のクライアントに対して書かれたものとなります。
一般論として語った内容ではなく、私個人とのやりとりに言及したものとなります。
開発手法、見積り算出法は諸説あります。
トラブルなく開発を依頼するために
クライアント＝お客様が開発をベンダー(開発者)に依頼する場合、どういったことに注意すればいいのでしょうか？
よくある事例を踏まえてまとめましたので最後までお読み下さい。
要求定義: クライアントがやるべきこと
最初にクライアントは「なに」を「どのように」して欲しいかという要求を定義する必要があります。要件ではなく要求です。
「なに」が「やって欲しいこと＝要求」で、「どのように」が、それを実現する「方法＝仕様」です。
例えば、自社ホームページを作りたいとします。それをベンダー(開発者)に伝えても「ホームページ」を作りたいということしか伝わりません。
実際には、PCだけではなく、タブレットやスマートフォンでも見られるようにしたい、会社紹介だけではなくお問い合わせフォームから見積りを受けたい、といったニーズがあるかもしれません。
掘り下げてみると「どのように」といったニーズがあるはずです。
ベンダーは開発スキルがあったとしても、クライアントの「なにをどのようにしたいのか？」までは分かりません。
また、勝手に想像して許可なく機能を追加し、見積り金額を上乗せするべきでもありません。
ここで注意して欲しいのは、クライアントが要求を定義できなかったものについては、絶対実現しないということです。
要求しなかったものは実現しない
とても単純なルールです。
例えば、飲食店へ食事に行き、オーダーしたにもかかわらず料理が出てこなくてお金だけ取られたらトラブルになりますよね。
また、オーダーしてもいない料理が出てきてお金をとられてもトラブルになりますよね。
ところが、オーダーしていない料理があり、料理が出てこなくてお金も請求されなかったにもかかわらず、料理が出てこないと怒るクライアントがいます。
意味が分かりませんよね？
どうしてこのようなことが起きるのかというと、開発においてはクライアント自身がどのくらいお腹が空いていて、なにを食べたいのかを分かっていないことがあるからです。
要求定義をできないクライアントは多い
実はあの機能が欲しかった
実はこうして欲しかった
やっぱりこうなるべきだった
ということはよくあります。
ただ、そうは言ってもあとの祭りです。
飲食店に行き、頼んだ料理を食べている途中でやっぱり気に入らないから別のものに変えて欲しい、料金はそのままで追加でもう1品頼みたい、というのは通用しません。
オーダーは先入れ先出しが基本です。
開発におけるトラブルの多くはこの手のことです。
これを後知恵バイアスと呼びます。
簡単にいうと後出しジャンケンです。
委託開発において後出しジャンケンは悪だと覚えて下さい。
要件定義: 開発者がやるべきこと
では、一方でベンダー(開発者)が最初にやるべきことはなにかというと、クライアントが出した要求定義を実現するために「要件定義」をすることです。
「要件定義」は「なにを」と「どのように」を具体的に検討することです。
例えば、自社ホームページをPCだけではなく、タブレットやスマートフォンでも見られるようにしたい、としたら、具体的に画面幅をどの程度にして、どの機種までを対応すべきかを決めます。
スマホのiPhone7までは対応して、ガラケーには対応しない、といったことを定義していきます。
建築であればクライアントのヒアリングから設計図を描き起こすようなものです。
この時、「要件定義」の精度はクライアントが提出した「要求定義」が元になります。
要求定義が曖昧であれば、要件定義も曖昧＝ベンダー任せになります。
現実的にありとあらゆることを定義することはできないため、クライアントは多くの部分をベンダーにお任せします。
トラブルが起きるのはお任せしたにもかかわらず、実はそうではなかったという解釈の違いです。
解釈の違いを防ぐには、クライアントが要求定義の中でこのことについてだけは「こうして欲しい」と要望を伝えることです。
それ以外については、ベンダーへ丸投げする形となり、あとでそうではないと言ってもクライアント責任となります。
例えば、飲食店へ食事に行き、料理の中に自分のアレルギー物質が含まれていたら入れないようにして欲しいと伝えることです。
伝え忘れれば当然、アレルギー物質が含まれていても文句は言えません。
日本の悪しき商習慣で、「丸投げ」があります。
「丸投げ」には2つの意味があります。
1つは、全てを任せてどのような結果になっても責任を自分が持つ
1つは、全てを任せて悪い結果になれば口を出し責任もとらせる
後者が忌み嫌われるのはご存知のとおりで、クライアントの要求定義が甘くベンダーにお任せした結果が意図しないものだったとしても、クライアントの責任となります。
ベンダーに丸投げは危険
それを回避するためには、要求定義をしっかり作り込むことです。
一方で、文章の文字数などは細かく定義し始めるとキリがありませんから、それはベンダーに任せるべきです。
見積り: 要求定義＝約束ではない
クライアントの要求定義とベンダーの要件定義が終わると、いよいよ見積りとなります。
ここで注意して欲しいのは、要求定義＝約束ではないことです。
見積り前の要求定義はあくまでも「こうしたいなー」というレベルのものです。
それをやるかどうかはまだ決まっていません。
実際には、予算、納期、技術的可能性、採算性といった側面から検討する必要があります。
なにより、見積りに含める必要があります。
たまに、クライアントで見積りに含めていないにもかかわらず、雑談ベースでした将来的な構想をやる前提として覚えていて、プロジェクト後半で「できてないじゃないか」とおっしゃる方がいますが、見積りに含めていないものは基本的にやりません。
逆に言えば、見積りに含めていない作業を勝手にやって追加請求をしないということです。
見積り後のこうして欲しいとこれできる？ は追加オーダー
見積りが採用され、いよいよプロジェクトが始動したとします。
ところが、クライアントの要求定義が甘く、やっぱり「こうして欲しい」と「これできる？」と訊かれる場面があります。
もちろんこれは見積り後の新規要望となるため追加オーダーとなります。
逆に、プロジェクトの途中で「こうして欲しい」と「これできる？」に無限に応えていると、そもそも見積りをした意味がなく、ベンダーにとっては割引要請でしかありません。
もちろん、お互いの作業が楽になる提案については歓迎ですが、基本的に作業工数が増える要望については追加オーダー扱いとなります。
飲食店で自分でオーダーした料理を食べ残しておいて返金を要求するのはおかしなものです。
また、追加オーダーでもう1品、2品と頼んでおいて、お会計で無料にしろ、というのもおかしなものです。
そうならないためにも、要求定義をしっかりする。すべて丸投げをしないことです。
日本企業に多い見積り後の後出しジャンケン問題とバイキング方式
数多くの企業と個人とお取り引きさせて頂き感じたことは、日本企業は後出しジャンケンとバイキング方式が大好きだということです。
後出しジャンケンについては前述しましたが、バイキング方式というのは、料金定額でオーダーし放題というサービス形式です。ビュッフェ方式とも呼ばれることがありますよね。
確かにこの方法は開発を委託する側にとってはとても楽です。
しかし、実際の開発ではバイキングやビュッフェのように時間制ではありません。
ある一定の期間が経過したら、成果物ができていなくともプロジェクトが終了し、清算できるというものでもありません。
開発においてバイキング方式というのはあり得ないのです。
ではどうして、日本ではバイキング方式が好まれるのかというと、日本企業に残業文化とご奉仕精神があるからです。
社員はサラリーといういわゆるサブスク形式で雇用を結んでいます。
この雇用形態では、一般的に誰でも出社し労働し就業日数分働けば月給がもらえます。
安定している一方で周囲より頑張ったところで即給与に反映するものではありません。
そのため、多くのサラリーマンにとって給与を増やす手段は主に2つしかありません。
1つは残業をして残業手当をもらう
1つは真面目に働きできるだけ長く雇用関係を維持し役職が付くのを待つ
こうした背景があるせいか、仕事を個人の技量に任せ丸投げする文化があります。
また、個人も任されることに反発し辛い雰囲気というものがあります。
個人が個人の技量と責任だけで職場が回っている場合、属人化傾向が強くなります。
属人化傾向は年齢層の高い職人・匠の現場や、組織がフラットで単純作業強労働の職場で多く見られます。
分業化、分担化、外注化が進まず、個人の技量と責任だけで回っている職場をブラックな環境と呼ぶこともあります。
当然、個人が倒れると引き継ぎがないためブラックボックス化し、ビジネスは衰退の一途を辿ることになります。
話は長くなりましたが、こういった企業文化があるせいか、クライアントの担当者がベンダーになにをどうしたいのかをうまく伝えることができないことが多々あります。他人に仕事を振るのが下手な社会です。
ベンダーは外部組織であり、見積りベースで動くため、後出しジャンケンとバイキング方式では絶対的にうまくいかないのです。
言わなくてもプロがいいようにやってくれるでしょ
は大変危険です。
特にフリーランスを自社社員と同様に多少無茶な要求でも残業してでもやってくれるでしょ、と考えるのは危険です。
作業範囲と責任は見積りベースだからです。
なにをどうのように頼んでいいか分からなければ作業内容を分割し、つど清算する
ここまで読んで、要求定義の重要さ、見積り後のやってはいけないことについて理解されたと思われます。
しかし、そもそも素人のクライアントにとって精度の高い要求定義ができるか、というとおそらく無理でしょう。
業務についてはベンダーよりも詳しい担当者も、それを外部の門外漢に説明する、ルールを明確化するとなると、途端にうまく行かないことがあります。
例えば、ある工程に関しては現場の経験知と担当者の政治力が強く、それをシステムとしてルール化できない、といったこともあります。
社外に情報を出してみてはじめて自社の問題点について気が付くこともあります。
開発はやってみてはじめて気が付くことが多い
のが普通です。
ただし、ビジネスとして見積りと契約がある以上、そのブレは追加請求という形で現れます。
ではどうすれば良いのかというと、私個人の経験からの提案ですが、同じものを二度作ることです。
二度作るというのはまったく同じものを作るのではなく、例えばプロトタイプを作った上で、本番(プロダクト)を作るといったことです。
プロトタイプは試験用です。建築でいえば模型(モックアップ)です。
本番の前にプロトタイプを作ることで、予算を節約でき、かつ次回に精度の高い要求定義を行うことができます。
しかし、大抵のクライアントはなぜかワンストップが好きで、一気にフル予算でフル開発をしたがります。
ワンストップでうまくいくのは、よほどのベテランが揃っているか工数が小さい場合だけです。
クライアントは現場のプロであっても要求定義のプロではありません。
プロジェクトはプロトタイプと本番のツーステップに分割することをおすすめします。
次に、見積りについてもプロジェクト途中の追加オーダーを考えて、フェーズ(作業内容)ごとに分割してください。
1から10までを一気に合算見積りをするのではなく、フェーズ(作業内容)ごとに分割することで、フェーズの途中で変更があっても再見積りによって軌道修正がしやすくなります。
例えば、プロトタイプを3つのフェーズに分けて、3つの見積りを出し、フェーズが完了するごとに清算をします。
本番ではプロトタイプを踏まえて要求定義と要件定義を見直します。
同様に本番を3つのフェーズに分けて、3つの見積りを出し、フェーズが完了するごとに清算をします。
フェーズごとにブレを見直し清算することができます。
こういった方式をマイルストーン(指標)方式と呼びます。
小さく分けてもまだブレが生じる場合はさらに細かく分割して見積りする必要があります。
あれと同じものを作ってくれはダメ
クライアントのあるあるなのですが、要求定義が難しいから「とにかくあのサイトと同じものを作ってくれ」という要望があります。
いわゆるコピーサイトを作りたい＝市場にライバルとして参入したい、という意図だと思いますが、これは絶対ダメな要求です。
ウェブサイトの場合、大きく分けてデザイン系とシステム系に分かれますが、表から見えるのはデザインパートのみです。
それがどのような仕組み＝システムパートで動くのかまでは外からでは分かりません。
つまり、クライアントはどのような仕組みで動いているのかは分からないが、コピーしてくれ、というわけです。
設計図も内部構造もわからない状態でコピーしろというのは、自動車を外から観察しただけで設計図を描き起こすようなもので無理があります。
因みにデザインを丸パクリするのは著作権侵害で訴えられる可能性があります。
いやいやそうではなく、「アレっぽいものを作って欲しい」ということをおっしゃりたいのは分かります。
ただ、それであってもどの機能のどの部分を参考にして欲しいといった定義はできるはずです。
「アレと同じに」だけでは要求定義とは言えません。
完全にコピーする訳では無い以上、どこかに違いがあるはずです。
それらを明文化しないとあとあとトラブルになります。
例えば、仮に参考にしたいサイト＝まったく同じ機能をもったサイトを作りたいという要望だったとします。
見積り後、プロジェクト開始後にその参考サイトに新機能が追加された場合、開発のゴールが延長する可能性があります。
クライアントはあの参考サイトと同じに作ると約束したのだから、見積り価格内で新機能にも対応するべきだと主張するかもしれません。
どの機能をどのように作るかといった作業ボリュームが明確ではない場合、このようなトラブルが発生します。
このロジックが間違っていることはすぐに証明できます。
仮に参考サイトがなんらかの理由で閉鎖し消滅したら、参考にするものはゼロなわけですから、成果物は提出せずお金だけ請求できることになります。
それは困りますよね。
参考サイトのなにをどのようにどこまでを参考にすべきかを定義しないことは、後出しジャンケンと同じです。
後出しジャンケンはトラブルの元です。
他には複数の参考サイトの指定でのトラブルもよくあります。
例えば、複数のサイトを参考にしたい場合、複数のサイトすべての要素を取り入れることはできないし、意図はしていないと思います。
なにを参考にして欲しいのかをきちんと明確にする必要があります。参考にするレベルも工数に関わります。
参考サイトがまったくダメというわけではなく、参考にしたいサイトがあるのであれば、機能なのかデザインの雰囲気なのか詳細を明確に定義してください。
必要であれば、手描きで良いのでラフを描いて説明してください。
また、参考サイトの提示は要求定義とはなり得ず、開発を約束するものではないことにご注意下さい。
あくまでも見積りの資料に利用することはあっても、同じものを作る約束にはならないと覚えておいて下さい。
たまにメルカリやランサーズとおなじものを作って欲しいというクライアントがいますが、上場企業の数千万円を費やして開発されているプロダクトをたった数十万円で作ろうとするのは正気の沙汰ではありません。
無視できない納品後の保守費用と最近の開発事情
最近のプロダクトは保守費用が高額になってきました。
作っておしまいということはなく、納品後もコストが掛かることがあります。
その理由としてバージョンアップとオープンソース問題があります。
納品したプロダクト自体に問題がなかったとしても、プロダクトに使用しているフレームワークやライブラリが更新されることがあります。
例えば、WordPressは本体が定期的に機能追加と修正のためにバージョンアップしています。
バージョンアップは基本的に良いことではありますが、同時にバージョンアップによって切り捨てられるものもあります。
古くてセキュリティ的に危険になった機能などはバージョンアップによってリストラされます。
一方でずっと使える機能もあります。それを後方互換性と呼びます。
プロダクトの宿命として後方互換性を維持し続けると陳腐化します。
古い規格や機能をいつまでも維持し続けるとコストが掛かるわけです。
どこかで機能を刷新していかないとユーザー離れが起きることになります。
バージョンアップによって後方互換が失われると、それらに付随する機能が動かなくなります。
納品されたプロダクトを3年使っても問題がなかったが、4年目に更新をしたら動かなくなってしまった、なんていうこともあり得ます。
WindowsやWordPressはかなりギリギリまで後方互換性を保証してくれますが、個人開発のオープンソースは見切りも早いです。
例えば、開発が盛んなnode.js関連は個人開発のオープンソースによって成り立っています。
オープンソースというのは大抵は使用も改変も自由で無料です。
逆に言えば、なにかトラブルが起きても開発者は責任を負わないということです。
そして、オープンソースなしでは、もはやプロダクトをリリースすることは困難なほど技術は複雑になっています。
オープンソースを使うことで開発者は開発コストを低く保つことができ、クライアントは安く開発を依頼することができています。
と、同時にオープンソースを使わなければ開発を継続できない宿命を背負うことになります。
オープンソース開発者は個人、企業と様々いますが、あっけないほど開発が停止されることが多々あります。
その理由は様々で、開発する情熱がなくなってしまった、そのプロダクトよりも良いものが現れてユーザーが離れてしまった、大手企業に買収されてしまった、開発者の本業が忙しい、などなど。
理由はどうあれオープンソースは後方互換の責任はないため、あっけないほど突然動かなくなります。
現在ウェブの技術はたくさんのオープンソースに支えられているため、2年、3年放置すると間違いなくなならかの不具合が起こります。
オープンソースは個人の情熱とボランティア精神に支えられ、そして無料ですから、文句のつけようがないのです。
お金を出すからなんとかしてくれ、といっても無駄です。
個人開発者の情熱の終わりが大企業のビジネスの終焉を招くこともあります。
オープンソースは便利である反面大きなリスクをはらんでいます。
ウェブ開発においてはオープンソースを最低でも大小合わせると2000以上は利用することになります。
そのうちのひとつでも不具合が起きると障害が発生します。
1つのオープンソースが機能しなくなると関連するオープンソースが機能しなくなり、さらに関連するオープンソースが機能しなくなるといった連鎖が起きます。
では、オープンソースを自社開発に置き換えるとどうなるかというと、開発工数が爆上がりすることになります。
例えば2000年台ではクレジットカード決済機能をもったネットショップを開発するだけで、数百、数千万かかることがザラにありました。
現在は、オープンソースによって1/1000、1/100と大幅にコストが圧縮できています。
今さら自社開発で巨額を投じて開発に成功しても、ライバルがオープンソースで開発していれば、採算分岐点で負けることになります。
人工衛星や銀行の基幹システムなど、絶対にトラブルがあってはならないシステムに関しては独自開発を行う意味がありますが、大抵のウェブ系開発はオープンソースに頼らないと採算がとれないのです。
なにが言いたいかというと、クライアントは依頼していた開発が成功しローンチして終わりではないということです。
予算を開発完了のギリギリのコストで見積もっている場合、その後の保守費用や、マーケティング費用をペイできずに詰みます。
自動車にはガソリンの給油やオイル交換、ブレーキパッドの交換が定期的に必要なように、プロダクトにもメンテナンスコスト(保守費用)が掛かると知って下さい。
概算ですが、年間の保守費用は開発費の2割を計上しておけばいいでしょう。
不思議なことにオープンソースによって開発コストは増大している！？
オープンソースは便利であるがリスクをはらんでいる、という話をしましたが、不思議なことにオープンソースによって年々開発コストは増大しています。
一度は開発費が下がった時代もあったのですが、現在はオープンソースが乱立し開発コストは増大しています。
なぜ無料のものを使っているのに開発費が増大するのかというと、人間が憶えていられないからです。
例えば、オープンソースにはバージョンがあります。2系とか3系といった系統があったりします。
あるオープンソースは他のオープンソースのバージョン2系では動くが、3系では動かないといった相性＝組み合せがあります。
基本的にバージョンは高くなっても低くなることは(グレードダウン)はあり得ないため、いずれかの時点で後方互換性が失われ、バージョンアップをせざるを得なくなります。
バージョンアップしたらしたで、別のものが動かなくなることがあります。
こういったパズルのような組み合わせが存在します。
担当者はそれらを憶えておいて、無闇にバージョンアップをしたりしないように慎重に管理する必要があります。
ところが、時間の経過とともにそのパズルの点数は数百、数千と指数関数的に増えていきます。
担当者が技術者でこまめにバージョンアップをして、動かない箇所を自分で修繕(パッチ)をあてているうちはいいのですが、2年、3年して何も知らない担当者が担当すると時限爆弾は目を覚まします。
特にサーバー関連は一度設定した後、次に触るのが数年後ということもザラにあるため、事故が起きやすいです。
※インフラエンジニアの年収が高額な理由にもなっています
そうすると、こういった複雑な仕組みを理解するための専任者が必要になります。
日本では1人の人間にデザインからプログラム、サーバー、マーケティングまでやらせたいというワンオペ＝謎文化がありますが、もはや1人の人間で管理できるレベルではなくなっています。
サーバーであればインフラエンジニア。
デザインであればウェブプロデューサー、ウェブディレクター、UI/UXデザイナー、HTMLコーダー、ロゴデザイナー、フォトグラファー、イラストレーター、コピーライター。
プログラミングであればフロントエンドエンジニア、バックエンドエンジニアなどがあり、その中でも言語別、ウェブサービス系、スマホアプリ系、データベース系と細分化します。
他にもたくさんあります。
専門職が細分化した結果、現場の雇用人数も増え人件費が増えていったのです。
日本ではIT人材不足が問題視されています。
少子高齢化で労働人口不足もありますが、一番大きな理由は現場がカツカツで人材育成どころではなかったツケが回ったことです。
複雑なウェブ系技術をリアルタイムで経験してきた世代は学習する余裕があったかもしれませんが、新卒採用で現場に放り込まれた若者は、学習すべきことが多すぎてついていくのが難しいのではないでしょうか。
経営者の中にはウェブビジネスはリアルビジネスよりも格段に安い、という意識を持つ方がまだまだ多いかと思います。
しかし、もはやそのようなことは言ってられないほど開発コストは増大しています。
常識をアップデートしてください。
トラブルになったらどうするの？
開発においてトラブルになった場合は、話し合いをします。
新規追加要求のトラブル
もっとも多いトラブルです。
見積りに含まれていないけど、やっぱりこうして欲しい、これをやっぱり追加して欲しいはすべて有料となります。
文字列を数文字程度置き換えたいといった軽微な変更には対応可能ですが、大きな変更は追加のオーダーとなります。
見積り前に要求定義がされており、私の方で要件定義として約束したにもかかわらず達成できていない場合は、無償で対応しております。
中には有料であっても対応できないものもあります
一見簡単なようでいて、使用しているオープンソースやAPIの仕様でできないことがあります。
その場合は、できない根拠を説明した上でお断りさせて頂きます。
ご了承下さい。
いちばんまずいベンダーとの付き合い方
悪気はないと確信していますが、いちばんやってはいけないベンダーとの付き合い方があります。
それは、見積り確定後に作業の途中経過をみて要求定義を修正することです。
クライアントはどのようなものができるか想像が追いつかない場合があります。
ベンダーが途中まで作業をしたものを見て、あらたなインスピレーションが湧くこともあるし、要求した内容が間違っていたと気が付くこともあります。
そして、そのブレとズレをベンダーとの話し合いの元に解決すれば良いと考えていることです。
一見、共同作業をすることで同じゴールに向かいWin-Winの関係を築けるような気がしますが、問題は既に見積りが確定していることです。
見積りはクライアントの要求定義を元に構成されているため、その前提が崩れると見積金額にズレが生じることは当然として、連携する機能やデザインにも影響を及ぼすことがあります。
にもかかわらず、クライアント側は良いアイデアを出したのだからプロダクトの品質が高まった＝追加支払いも発生しないだろう、と考えているパターンです。
悪気がないということは分かっているのですが、本来であれば見積りの前段階で提出しなければならない情報を後出しされると困ってしまいます。
2回、3回と続くと大抵のベンダーはブチギレます。
その責任は誰がとるのか？
明らかな新規要求であれば、その要求を伝えきれなかったクライアント側にあります。
しかし、悪気があるわけではないため、責任を言及し辛いのです。
覚えておいて欲しいのは、見積り後の話し合いや交渉はいっさいできないことです。やるならば追加見積りする必要があります。
相談をしながらステップ・バイ・ステップで作りたい気持ちはよく分かるのですが、その場合は見積りをフリー予算にして頂く必要があります。
当然フリー予算は割高になります。
プロジェクトを見積り予算内に収めたい場合は、要求定義を出し切った上で、発射された弾丸を見つめる気持ちでいてください。
あとで相談すればいいや、ふわっとしているけど見切り発車でいいでしょう、という気持ちではトラブルになります。
何卒ご協力をお願い致します。
この記事が気に入ったらサポートをしてみませんか？