コーポレートブログ前回は、実際のプロジェクト開始前までの事を書きましたが、今回は、実際のWEBサービスをつくりはじめる。
といった時に重要なポイントを記載します。
ロードマップの作り方
まず、はじめに全体のロードマップをつくります。
これは詳細なスケジュールとは違い、1か月単位などでよいと思います。
前回も記載しましたが、WEBサービスの構築は、1か月や2ヵ月ではできません。（本来は）
ロードマップをつくるときに、リリース日から逆算してしまう事が多いと思います。
それは、正しい事だと思います。
WEBサービスの構築自体、営利目的であることがほとんどですから、6か月でつくれるものをつくる。といったようにフェーズ分けを行う事が非常に重要です。
最初から、100点のWEBサービスをつくることなど、できません。
それは、Googleをはじめ大手企業のサービスでも同様です。常にバージョンアップしていますよね？
バージョンアップのロードマップを先につくっておく。のは、非常に重要です。
システムエンジニアにとって、先々の拡張が、最初から見えているのと、そうでないのでは、後々にかかる負担が、大きく異なってきます。
よくある例として、
「DB（データベース）に項目を一つだけ追加したい。
一つくらいなら、ちゃちゃっといけるでしょ？」
これ、システムエンジニアに怒られるケースです。
エンジニアにとっては、データ構造の改修は、非常にナーバスになる内容です。
改修前と後で、不整合が発生する可能性など、不具合の発生する可能性が非常に大きいからです。
１つの項目追加でも、最悪、最初から全てのシステム設計を見直さないといけない。といった事もあります。
残念ながら、エクセルのセルを一つ追加する。といったようにはいきません。
実際のロードマップの作成は、
１．機能単位でフェーズ分けを行う。
２．フェーズ毎の各作業を洗い出す。
３．リリースポイントから逆算して表に落とし込む
ここまでが、ロードマップの作成になります。
スケジュールは、あってないようなもの。
次に、スケジュールの作成にはいります。
ロードマップは、あくまでWEBサービスのリリースまで、リリース後の指標的なものです。
ロードマップに対して、それぞれの担当者に作業を割り振る作業がスケジュール作成です。
実は、WEBサービス開発においては、このスケジュール作成が、大きな落とし穴だったりもします。
前回、システム受託開発とWEBサービス受託開発の違いについて書きましたが、システム受託開発では、つくるものが定義されているので、よほど大きな問題が起きない限り、スケジュール通りに進みます。
しかし、WEBサービス開発においては、そうはいかないのです。
一番多いのは、環境問題です。
これは、実際にあったことですが、AppleのiOSのバージョンがアップされ、想定していたことが、技術的にハードルが上がってしまった。ということが、ありました。
このバージョンの予定が公開されたのが、システム設計時でした。
もう、プロジェクトも進んでいるし、後戻りもできません。
システム受託開発の場合であれば、システムを完成させることが目的なので、納品後、再度対応を検討することになりますが、WEBサービスの場合、そうはいきません。
それが、WEBサービスを利用する人にとって、どの程度の影響なのか？を含め、調査し、対応を考えるだけでも、1週間以上かかります。
これは、どんなに経験を積んだエンジニアやPMでも、完璧に行うのは、至難の業です。
結果として、スケジュールは再検討となります。
プロトタイプの重要性
スケジュールの再検討で、次に多いのが、最初のＲＦＰから、市場の状況が変わったなどにより、方向性が少しブレる事があります。
例えば、画面デザインなども、その一つです。
そのため、弊社では極力、プロトタイプをつくるようにしています。
プロトタイプの作り方や、どこまでつくるか？については、また別の機会に書きます。
実際にプロトタイプが出来上がり、全員で使ってみると、色々と意見がでます。
これは、当然のことです。
最初に意思疎通を行っていても、【人と人】ですから、多少の行き違いはあります。
そして、それが【人と人と機械】だったりすると、大きなズレになってしまうケースもあります。
そのための、プロトタイプの構築です。
ただし、プロトタイプをつくるということは、リリースに向けては多少、回り道になってしまうケースもあります。
昨今、アジャイル開発と呼ばれる開発手法を用いることで、意思疎通のズレをなくしていく。
といわれていますが、実は、アジャイル開発の場合も、一般的なシステム開発（ウォーターフォール型）に比べて、費用も時間をかかってしまいます。
個人的には、アジャイル開発を用いるのであれば、最初からプロトタイプ構築をロードマップに組み込んで、ウォーターフォール型で構築する方が、リスクが少ないと思います。
残念ながら、アジャイル開発には、そこに参加する全員の高度なエンジニアスキルが、求められます。それは、受注側だけでなく、発注側にもです。
そういった、プロジェクトは、非常に稀であり、アジャイル開発という名の、単納期ウォーターフォール型開発になってしまっていることが、ほとんどです。
PM（プロジェクトマネージャー）の大切さ
WEBサービスの開発においては、様々な紆余曲折がつきものです。
これらを全てコントロールするのが、ＰＭの役目です。
ハッキリ言って、システム受託開発のＰＭとＷＥＢサービスの構築のＰＭでは、全く異なります。
後者をキチンと行える人を、私はあまり見たことがありません。
ＷＥＢサービス構築におけるＰＭに必要なスキルや経験としては、
・ビジネス構築経験
・エンジニアスキル
・プロモーション・マーケティングスキル
・ＣＳ構築経験
・営業経験
・そして、もちろん、システム受託開発のＰＭ経験
は、最低でも必要です。
更に、
・利用規約をはじめとした、法的リスクの把握
・売上や費用に関する会計上のルール策定のためのスキル
こんな人、いるの？って思うかもしれませんが、います。
私自身も、一応全ての経験を積んできたからこそ、自社でＷＥＢサービスの構築を行えています。
終わりなきゴール
サービスリリースを迎えるところまで、来たとしましょう。
実は、ここからが、大変なのです。
どうしても、
リリース＝ゴール
というイメージが強いのですが、WEBサービス構築の場合、ここからが本番です。
実際に、サービス提供を開始してみると、様々な問題点が見つかります。
ユーザーというのは、想像をはるかに超えた使い方をするものです。
私自身も、様々なWEBサービスを使っていますが、サービス提供側からしたら、嫌な客なんだろうなーって、たまに思います。
ここで重要なのが、顧客離れを防ぐか？です。
不具合やサービスの限界などにより、顧客からのクレームなどは、多々あることです。
しかしながら、ここで登場するのが、CS（カスタマーサポート）です。
WEBサービスにおいて、CSチームは、神様です。
海外のWEBサービスは、割り切っているところが多く、問い合わせなどもメールしかない。
更には、返信さえ、いつくるか？解らない。といったことが、多いです。
そして、日本国内のサービスも、それを良かれと思って真似をしているWEBサービスを目にします。
サービス提供って、なんでしょうか？
私は、このCSの対応を含めて、WEBサービスの良し悪しだと思います。
どんなに優れた機能やサービスでも、顧客は離れていってしまいます。
さて、もう一つ重要なことがあります。
それは、バージョンアップです。
これは、WEBサービスである以上、避けて通れない事です。
ブラウザやOSなどの環境のバージョンアップに伴ったものが、一番多いと思います。
それ以外にも、個人情報や税率の変更など、法的な変更によるものや、トレンドの変化によるもの。
最後に、一番大切な事です。
弊社にも、よく既存のWEBサービスの改修の依頼がきます。
ハッキリ言って、通常では、お受けしていません。
なぜなら、元々のシステムの調査だけでも1か月以上はかかるからです。
そして、既存のＷＥＢサービスの改修の依頼の理由のほとんどが、運営側のコストの問題です。
コストの問題があるところに、システム調査だけで1か月以上かかるといっても、そのコストさえない。といったケースがほとんどです。
これは、最初のビジネス構築からして、失敗しているということです。
【ベンダーロック】というのを、悪い事だと考えている人も多いです。
しかし、それは安定したサービス提供においては、とても重要な事であり、ベンダーをロックできるという、考え方に意識を変えたほうがよいと思います。
ＷＥＢサービスも、システム開発も、HＰ制作なども同様ですが、つくることが、ゴールではないのです。
ＷＥＢサービスを構築するうえで、この運用の体制と費用をどれだけしっかりと計画できるか？
が、サービス構築成功のポイントです。
ＷＥＢサービス開発を外部に委託する場合は、必ずリリース後の作業についてと、作業に対する費用について、しっかりと確認しておくことをお勧めします。
2回にわたって、ＷＥＢサービス構築について書かせていただきましたが、クラト株式会社では、自社サービスをはじめ、多くのＷＥＢサービスの構築実績がございます。
クラト株式会社では、【共に創る】ということを大切にしておりますので、是非ご相談ください。