無駄なホームページやブログ制作に関しての矛盾と葛藤

一般財団法人日本そうじ協会掃除道認定講師 IT掃除道のザック（雄大）です。

ホームページやブログなどの制作を受けることが多いです。
一つ葛藤していたことがあります。

どんなに綺麗で格好いい、SEO(googleやyahooなどの検索エンジン対策)の効いたホームページやブログを作っただけでは無駄ということ。

重要なことは、その後のシステム開発の更新や運用、メンテナンスです。
ブログであれば、定期的な更新が鍵です。

その定期的な更新に関しても、その人やその会社のサービスに応じた戦略を元に、更新しなければなりません。

お金をいただいても、ほぼほぼ、使われないホームページやブログがあり、本当にに悲しい思いをしました。徹夜で仕上げて、納期を守り、戦略などもあーでもない、こーでもないと考えながらの納品。それが有効に使われていない。

これは私のような作り手の問題でもありました。作成後の活用方法など、ヒアリングして、本当に最低限の機能だけにするなど、選択できたはずだなと。

また、開発後、ブログでのブランディングなどの価値や戦略を指導することで、続ける仕組みを構築できたなとも思っています。

よくあるWEBサービスの話。

システム開発が始まって、納品または、サービス拡張について。

Webサービスの場合は、まずは世の中に最低限のサービスを作り出し、日々更新やカスタマイズや機能追加などしていき、少しずつ、サービスを向上させていきます。伸びている会社は確実にそうしています。だからこそ、Webサービス系の会社は内製化にこだわっている会社が多いです。

内製している場合はそれでいいのですが、外注している場合は大変です。

1機能作るために、外注。
1機能追加するために、さらに外注。
その面倒さがわかっている人は、今度逆に、一度にたくさんの機能を盛り込んだサービスを作ろうとします。そうするとどうなるのか。

ほぼほぼ、使われない無駄な機能で溢れた状態になりやすいです。そして、長い工数がかかるので、開発していたころには、いらない機能になったということも多々あります。

Webサービスは手軽で始められるのがいいですが、日々更新するとなると、なんだかんだで、時間を取られます。

そうすると、ブログをお願いして作っても、運用されずに、終わってしまうということもよくあります。

また、要件定義やヒアリングをして、お客様の要望を100%満たしたとしても、運用していく段階でやっぱり違ったということもあります。

では、どうしたら、いいのだろうとずっと考えていたら、下記の書籍に出会いました。

「納品」をなくせばうまくいくソフトウェア業界の“常識"を変えるビジネスモデル

作者: 倉貫義人
出版社/メーカー: 日本実業出版社
発売日: 2014/06/12
メディア: 単行本（ソフトカバー）
この商品を含むブログ (3件) を見る

下記、引用します。

最初に何を作るかという要件定義に関して

要件定義という形で未来を予測することは難しいと言わざるえません。
そのため、要件がきまらないまま、無理やり見積りをして開発に入ったり、要件定義で決めたないようでは本当の要件を満たすことができず、
途中で仕様変更とそれに伴う、追加費用が発生。さらには、納品後は開発会社とそこで関わった人達は別のプロジェクトに移ってしまい、
メンテナンスも容易にできなくなるというケースもあります。

納品を目指す請負はディフェンシブな開発だ。

私は、「納品」を目指す一括請負におけるソフトウェア開発を、保守的、守りの姿勢という意味で「ディフェンシブな開発」と呼んでいます。一括請負では最初に要件定義と見積りをして、作るものと金額を決めてから開発を始めるので、開発会社が利益を確保するためには、当初に見積もった予算の範囲に収まるように、なるべくコストを抑えることが大事になってきます。

実はSI屋さんはダメなエンジニアのほうが儲かる！？

受託案件を主にやっている会社は人月という単位を使っています。
例えば、何人のエンジニアが何ヶ月稼働したかを計算するときの手法です。
1人月100万円としたら、できるエンジニアは半月でつくったら、50万円、できないエンジニアであれば、１ヶ月かかり、100万円というケースもあります。
50万円も差がでます。

本の著者はこれらの問題を解決するため、納品のない、月額定額の受託開発にすることにしました。要するに、顧問弁護士や顧問税理士のように、顧問エンジニアという形になります。

これだと！！

自社に置き換えた事を考えると、ホームページやブログなどを開発するだけでなく、その後の保守だけでなく、Web戦略やマーケティングなども一緒にやってあげればいいのかと。

今までだと開発はA会社、Web戦略はB会社と分けて考えると、AとB会社にお願いする、C会社はA会社にもB会社にも自社のサービスの説明をしないといけません。また、B会社の提案をA会社に理解させ、サービスを作ってもらうという、コミュニケーションコストも発生します。

ということで、今後の案件は、月額制にしたシステム開発及び、コンサルティングに少しずつシフトしていこうと思います。

旧来型は旧来型で、長短所があります。それと同様に、顧問型の開発にも長短所があります。私はSI屋さん出身ではないので、このような仕組みのほうがしっくりくるなと。

長短所に関しては、また次回以降で書いていきたいと思います。

メールマガジンを毎週火曜日、発行しています。このブログでは書いていない情報をまず、こちらのメールマガジンからのせています。ぜひご登録ください。