当社ではWebサービスを運用しているせいか、受託制作においても、よくWebサービスの制作を依頼されることがあります。

社内制作で実績があるので、技術的には問題ないといえば問題ないのですが、制作を進めていくうえでは、自社サービスをやるのと大きく異なります。
社内サービスではさくっとやってしまえることが、受託だと出来なかったり、想定していないところでクレームに繋がったりします。
BtoCというWebサービスの特性上、ただの制作ではなく、制作会社に求められているものがちょっと違うような気がします。


社内で作る時よりも勉強になることも多いですし、社内で作る時よりも難しいことも多々あります。
コーポレートサイトや社内システム開発の受託制作とは大きく異なります。

そこで、Webサービスを受託制作で請ける際に、気を付けた方が良いところを私なりの経験で書こうと思います。
毎回毎回、クライアントによって、つまづく所も違いますし、毎回注意しつつ反省すべき点が多いです。

これからWebサービスの開発を請け負われようとされている方の参考までに。

 

エンドユーザー目線を、目の前のクライアントを納得させることが先決。

Webサービスを自社で運営しようとしているような会社の場合、担当者の方もそれなりに意識が高いです。
担当者なりのこだわりとかサービスに対しての思い入れが強い方が多いです。

よく制作では、発注者よりエンドユーザーの方向を見て(ユーザー目線)、ということが言われます。
しかし、実際にエンドユーザーの方向を制作会社が見て提案していたとしても、それのどこが良いのか、を発注者に納得させることが出来なくてはいけません。

その担当者の好き嫌いや、操作の感覚、Webサービスをどのくらい使い込んでいるのか、などその担当者の属性によって提案を受け取る感覚が変わってきます。まずは目の前の方を納得させるのに時間を使うことになるでしょう。

会社にも依りますが、自社サービスの場合は比較的、決定権のある人がどんどん決めて制作を進めることが可能です。
しかし、受託制作の場合は、発注者に了承を得る必要がある、というのが社内サービス制作との大きな違いかと思います。

 

そのサービスの良いところを探す。

正直なところ、受託制作ではいまいちピンとこないWebサービスの依頼もあります。
自分自身の生活圏に関係のない、日常必要と感じたことのないサービスであればサービスの良し悪しというより、当然のことです。

でも、実際に請け負ったら、ただ作るだけ、という訳にはいきません。
Webサービスの特性上、必ず制作会社、Webのプロとしての意見や提案は求められます。

そのサービス自体を否定してしまっては、どうしようもないので、良いところやもっと良くなるところを探すように意識して制作を進めていけると、クライアントとも良好な関係を築けるのではないかと思います。

興味ない分野だからこそ、客観的な意見を出せる場合も多くあります。
無機質にただ作る、というだけではWebサービスのクライアントは納得しない、ということだけは念頭に置いておいた方が良いかもしれません。

 

取りあえずやってみる、というノリには注意。

Webサービスがヒットするかどうかは、実際にやってみないと分かりません。
自社サービスであれば、どんどんリリースして試しながら運用していくことも出来るでしょう。

しかし、これをやられてしまうと、受託制作においては自分たちの首を絞めてしまいます。

本当のところ、運用していく過程でリリース前には見えなかった問題や改善点が出てきます。
そこを制作を請け負う制作会社として、どこまで請け負うのか、という部分が非常にネックになってきます。

私自身、毎回これに苦しめられるのですが、運用しながら改善していく、という雰囲気で制作を進めてしまうと、検収期間と称して、かなりの修正対応をしないといけない事態に追い込まれます。
ここが自社サービスやコーポレートサイトの制作などとは大きく異なるところです。

通常のシステムなどであれば、バグを取ればそれで検品完了だったりしますが、Webサービスの場合は、実際に使ってみての使い難さの改善なども含めて検収と主張される場合も多いです。
実際に運用してみての改善点をどこまで仕様変更として線引きするか、に毎回悩まされます。

これについては私自身毎回課題になっています。

 

事前に考えうるリスクについてはすべて説明と確認を。

Webサービスは実際に運用してみると、色々なことが起きます。
予想していないトラフィックによって表示が重くなったり、ユーザーからの問い合わせや、荒らしのような迷惑行為、注目されればされるほど、色々な対応が増えます。

何か運営上不都合なことが発生した際に、真っ先に制作した制作会社へ

「制作の段階で予想できなかったのか」
「なぜ、そういうリスクに対して相談が事前になかった」

などなど責任の瑕疵を問われます。

想定されるユーザー数や扱うデータ量などについても、事前に検討のうえ、リリース時に保証できる範囲のことを定義しておくことが重要です。SNSのAPIを使っている場合なんかも、仕様変更がある可能性もゼロではないので、その辺りのことは要件定義などに記載して、念入りに確認しておく必要があります。

実際に運用してみないと分からないことだらけなのがWebサービスなのですが、あくまで受託制作で請けているうえでは、リスクについては考えうる限りピックアップして認識していただくことは、クライアントにとっても悪いことではないはずです。

 

管理機能(CMS)にも配慮が必要

実際には、クライアントにWebサービスを運用してもらうわけですが、自社と異なるのは管理画面を充実させておかないといけないこと。
自社でも大人数で運用する場合は、必要ですが、少人数で運用する分には、そんなに豪勢な機能がなくてもphpMyAdminとかでちゃちゃっと色々できたりします。

しかし、クライアントが運用するとなると、ユーザーの管理やその他のデータの管理も分かりやすい管理機能が必要になります。

運用上想定できるあらゆるトラブルを回避・対処できるよう、管理機能の機能面についてもきちんと考慮しないといけません。
自社だけユーザーエンド側のみに意識が向かいがちですが、そこも自社サービスとはちょっと異なる点です。

 

最後にお金の話

着手金をいただくことと、制作期間が長くなる場合はフェーズ分けして請求できるような交渉はしておいた方が良いです。

特に自社サービスの開発で自社持ち出しの筈なのに、着手金は支払えない場合は注意が必要です。
サービス自体が出来てから、費用の交渉や支払い条件の交渉などを持ち出されることもありますので、受注すること自体ちょっと考えた方が良いかもしれません。

=====