スポンサードサーチ

大企業から中小企業、ベンチャーまで様々なクラインアントとのお付き合いの中で、良く感じるのはWebサイト構築やWebシステム開発のコストが思ったよりも高いと感じておられる点。

これについては、我々がやっている工程が見えないので、「よくわからないものにお金を払っている」という点で高いと感じる、というのはわかります。

前回、リソース・シェアリングのコンサルティングからローンチまでのプロジェクト・フローでご紹介したのは、こういった不明点をできるだけ無くしたいという思いからなんですが、これを見ていただくとわかるように、プロジェクトではかなりの工程を経てローンチまで進んでいるのがわかります。

しかし、プロジェクト・フローの中で開発コストを下げるポイントが実は7つあります。

今回は、そのポイントについて見て行きたいと思います。

かける「時間」を減らす

まず、最初に確認をしておきたいのがWebサイト構築やWebシステム開発において「コスト」が上がる要素というのは、コンサルタントやプロジェクト・マネージャー、デザイナー、技術者を拘束する人件費、つまりこれらのメンバーが拘束される「時間」が長い、という点です。

つまり、「コスト」を下げようと思えば開発メンバーの「時間」を減らすことが重要。

では、どうやればWebサイト開発やWebシステム開発における「時間」を減らす事ができるでしょうか?

例として企業Webサイトのリニューアルのプロジェクトで考えてみましょう。

企業Webサイトに必要な要素

企業Webサイトを作る上において、一番最小の構成としては以下の4ページでしょう。

  • トップページ
  • 会社概要
  • 事業内容、提供商品又はサービス
  • お問合せフォーム

しかし、今はこれだけの構成しかない企業Webサイトってあまり見ないですよね。

そこで、追加して以下のページが作られる事になります。

  • 新着情報一覧
  • 新着情報詳細
  • 事業詳細、提供商品又は商品の詳細

SEOを考えた場合、これに提供商品やサービス、業界などの情報発信を行う機能が追加されます。

  • ブログ一覧
  • ブログ詳細

企業Webサイトとしては、この構成が今は一番多いのではないでしょうか。

構成としてはこのようにある程度固定化はできるのですが、企業Webサイトを構築する全ての会社が同じデザイン、同じ情報構成、同じコンテンツということは絶対ありえません。

そこで、コンサルティングを実施しない場合には、クライアントのご担当者とその企業の課題を解決するために最適な内容をまとめた「要求定義」を行って、具体的に作るべき詳細を詰めていくことなります。

「要件定義」や「設計」の時間を減らす

クライアントの「課題」を解決するための要望をまとめた「要求定義」ができたら、「要求定義」を実現するために必要な機能を洗い出した「要件定義」を行い、「要件定義」を具現化するための「設計」に進みますが、Webサイトのリニューアルが成功に終わるか、失敗するかはこの「要件定義」と「設計」にかかっているといっても過言ではありません。

それゆえ、「要件定義」と「設計」においてクライアントとのコミュニケーションに膨大な時間がかかるというのが、「時間」がかかる一つ目の要素としてあります。

クライアントのご担当者は、プロジェクトを進めて行く中で「要件定義」フェーズにおいては、弊社からドキュメントで提示するWebサイトの構成、デザイン、必要な機能を記した要件定義書の確認などを行っていただきます。

次に、ベンダー選定のためのRFPの確認、ベンダーの提案書と見積確認、ベンダー選定、開発予算と契約の確認、既存システムとサーバの環境や運用状況、新サーバやその他開発ツールの契約、運用開始後の業務フロー、運用体制、外部への連携や社内システムとの連携がある場合には、担当部署と仕様の確認や連絡と調整、といった様々な業務にご対応いただき、社内外への確認をしていただくことになります。

「設計」フェーズに入ってくると、機能仕様書や画面設計書、詳細設計書といったWebサイトを形作るためのドキュメントが作成され、「開発」フェーズに入ってくると、Webサイトで必要な写真や流し込むためのコンテンツといった素材集め、「テスト・受入テスト」においてはこちらで用意したテスト仕様書通りに実際のものが正しく出来上がっているのか、公開前に対象となる端末やOS毎の動作チェックを行う必要があります。

さらに、「ローンチ・検収」においては公開日に正しくサーバの切り替えが行われたのか、機能が正しく動いているのか、といった最終的な動作チェックをして検収を行います。

しかし、Webサイトに詳しい専門の方がリニューアルプロジェクトにアサインされるケースはとても稀であり、広報や企画、場合によっては営業といった普段は全く違う業務を担当されている方が担当されるプロジェクトが大半です。

この場合、スケジュール通りにプロジェクトを進めていこうとすると、弊社側で出来るだけ数多くのドキュメントを用意し、コミュニケーションの頻度を上げて、弊社主導で「要件定義」や「設計」を進めていく必要があり「時間」を減らす事が難しくなってきます。

これに対し、ITリテラシーが高く、Webサイト構築やシステム開発の知識がある方を担当者としてアサインしていただけると、プロジェクトにおいて共通認識を持って進めることができ、「要件定義」や「設計」についても、クライアントのご担当者主導で行えると、プロジェクトの成功率は格段に上がりますし、コミュニケーションコストという「時間」を減らす事が可能になります。

機能をカスタマイズしない

次に「時間」がかかるのが、「設計」、「開発」、「テスト・受入テスト」において問題となる機能のカスタマイズです。

先ほどの企業Webサイトをリニューアルするプロジェクトで引き続き考えてみましょう。

企業Webサイトに新着情報やブログの機能を付ける事が、SEO対策の面で必要とされるため、最近ではCMSとしてWordPressを導入するのが非常に多くなっています。

WordPressは、基本機能として固定ページとブログの機能の両方を持っているため、全くカスタマイズをしなくても、企業Webサイトを構築することはできますし、WordPressを利用する際のメリットである無料で豊富なPlugin(プラグイン)を使えば、様々な機能を追加することができます。

しかし、WordPressの基本機能やPlugin(プラグイン)で対応できない機能を実現しようとすると、カスタマイズのための「設計」と「開発」を行う「時間」が必要となります。

ここで、社内の業務フローや運用フローをWordPressの基本機能やPlugin(プラグイン)に合わせるという事ができれば、カスタマイズを行わず「時間」は大幅に減らせるのですが、担当者ではなく意思決定権者による鶴の一声が出てしまったりすると、必要かどうかの判断の前にカスタマイズを行う必要が出てきてしまいます。

また、新サービスや新規事業においては、「競合が持っている機能」についてどうしても追加したい、という事でカスタマイズが加えられるケースもあります。

しかし、その追加したい機能が「課題」の解決につながらないと思い切って切り捨てることができれば、カスタマイズによって増える「時間」を減らす事が可能になります。

パッケージやフレームワークを使う

世の中のプロジェクトにおいて、どんなにユニークに見えるものあっても、機能を分解していくと世の中にあるパッケージやフレームワークで提供されている機能を組み合わせて実現できるものが殆どです。

もちろん、UI(ユーザーインターフェース)やUX(ユーザーエクスペリエンス)がビジネスモデルに大きな影響を及ぼすようなサービスの場合、ただ単に機能を作ればいいというものではないのは確かではありますが、「課題」の解決に機能がそこまで影響するものというのは、一部の例外を除いてそんなに多くありません。

そのため、作りたい機能がビジネスモデルの根幹にかかわったり、その機能を新たに作らなければ「課題」が解決できないというのでない限り、「競合が持っているから」、「競合との差別化のために」ということだけで、オリジナル開発を選択するのは望ましくありません。

機能だけ見た場合、ASPでまずはスタートする事がふさわしいケースすらあります。

そのため、開発手法を選択する際には、出来るだけパッケージやフレームワークを使うことができる方が「課題」を解決するためのリソースを最適化でき、全体の開発コストを大幅に減らせる可能性があります。

ターゲットユーザーを明確にする

「課題」を解決するためには、ターゲットユーザーを明確にするのは当然ですが、これはWebサイトやWebシステムの利用ユーザーの環境についても当てはまります。

利用ユーザーの環境をあまりにも幅広く取ってしまうと、対応端末やOS、ブラウザなどの利用環境が増える事になります。

以前、ガラケーと今では呼ばれる端末は、au、docomo、Softbankの携帯電話会社の違いだけでなく、メーカーや発売時期によって全て仕様が異なり、それに対応する事は大変な時間とコストがかかっていました。

同様に、スマートフォンは様々なメーカーから発売がされており、AndroidとiOSという違いだけでなく、OSのバージョンもブラウザのバージョンも画面サイズも発売される時期によって大幅に異なり、対応端末の幅を広げる事は対応に「時間」がかかることに繋がります。

PCにおいては、メジャーなブラウザとしてChromeやFirefox、Safariが挙げられますが、大手企業の社内においてはいまだにInternet Exploreが使われているケースもあり、これに対応しようとすると通常の開発よりも「時間」がかかることになります。

また、最近のユーザーの利用状況など考えると、スマートフォンでもストレスなく利用できるデザインをメインで考える「モバイルファースト」で「設計」を考えるのが望ましいですが、Internet Exploreを対象ブラウザに含めてしまうと、かなり制限が出てしまう事になります。

このことから、Google AnalyticsのWeb解析データなどから利用環境を絞り込んだり、ターゲットユーザー層から利用端末を選定したりすることで、対応「時間」を減らす事ができます。

意思決定権者を複数にしない

プロジェクトが失敗する多くの原因は、「要件定義」と「設計」の失敗で発生します。

しかし、この原因となるのが一度決めた決定事項が変更となる「仕様変更」であり、これにより炎上するプロジェクトは山ほどあり、この状況が発生するのは、意思決定権者が複数になるケースが大半です。

ご担当者がWebサイトの各種事項に対する意思決定権者、例えば担当役員自らプロジェクトに積極的に参加をされて、「要件定義」と「設計」を理解しながら進める場合は、一度確定した「要件定義」と「設計」が変わる事は非常に稀です。

しかし、ご担当者と意思決定権者が異なる場合、実際の意思決定権者の思いと担当者の考えが違っていた場合や、複数のステークホルダーが意思決定に入ってきて決定事項を覆す、上長が人事異動で変わったり急に変わってしまい意思決定の方向が大きく変わってしまう、という可能性があります。

こうなると、全ての事項に対して意思決定権者への確認が必要であったり、決定事項自体が覆ってしまった場合には、改めて「要件定義」と「設計」をやり直す必要があり、膨大な「時間」のロスが発生して予算が膨らむ原因となります。

実際、大手企業のプロジェクトにおいては、こういった事が発生しがちです。

そのため、ご担当者の方は社内調整が必要な場合や上長に承認を得なければならないといけない場合、プロジェクトの引き継ぎをする場合などには、必ずプロジェクトの背景から経緯を含めてお話していただく事が重要であると同時に、プロジェクトの担当者をアサインする意思決定権者の方は、プロジェクトにこういった事態が発生する事がないように気を付ける必要があります。

新しい運用環境を用意する

リニューアルプロジェクトの場合には、現在のWebサイトやWebシステムが稼働しているサーバが必ず存在しますが、リニューアルをするにあたっては新たな運用環境を用意する方が「時間」を大幅に節約できますが、これには以下の三つのメリットから明確です。

まず、一つ目として既存サーバは現在のWebサイトやWebシステム導入された当時のサーバであるために、OSやミドルウェアのバージョンも当然のごとくその当時のものであり、かなり古いものになっているはずですので、古いOSやミドルウェアは既にサポートが切れている可能性や今後のバージョンアップが見込めないために、セキュリティリスクが高く今後の保守費も独自対応が必要となると高額になってきます。

一方、全く新たなサーバに切り換える場合、最新のマシンスペックやOS、ミドルウェアが利用できますので、脆弱性などによる各種バージョンアップなどがあった場合にも対応が可能ですし、新たに導入するWebサイトやWebシステムは、最新のサーバで動かすことが前提となっている場合が殆どですので、サーバのOSやミドルウェアが古すぎて動かないという問題もなく運用ができます。

二つ目のメリットとしては、今ではクラウドで提供されるサーバのコストが現状システム導入時点よりもかなり下がっていますので、前回よりもハイスペックでOSやミドルウェアが最新のマシンを、コストを下げた形で導入できる可能性が高いというのがあります。

三つ目のメリットとしては、複数システム共存によるサービス停止リスクを減らせるという点です。

リニューアルプロジェクトにおいて、開発用サーバは別で用意したとしても、既存サーバを利用する場合には最終的に既存システムが動いているサーバで新しいWebサイトや新システムの運用を開始することになります。

しかし、サーバは基本運用し続ける事が前提となるため、新システムの設定を行う間も現状のシステムは稼働した状態となりますが、障害が発生すると既存システムにその影響が出る可能性があります。

また、新システムを稼働させるために、サーバのOSやミドルウェアなどをアップデートしないといけない可能性もありますが、その際に現状システムが逆に動かなくなってしまう可能性もあります。

このように、運用環境については新たなものを導入しない事の方がコストを押し上げる要因となります。

移行するデータを減らす

どのプロジェクトにおいてもクライアントは意識をあまりしていませんが、意外と「時間」がかかるのがデータ移行作業です。

WordやEXCELのように、元々バージョンアップが想定されているパッケージであれば、過去のバージョンのデータがそのまま利用できる事がありますが、基本的にWebシステムのデータがそのまま次に利用できる方が少ないのが現実です。

例えば、ECのオープンソースのパッケージである「EC-CUBE」は、3系と4系ではデータ構造が全く異なっており、データ移行を行うにはかなり手間がかかります。

CMSで世界的にシェアの大きなWordPressでも、更新が止まったPlugin(プラグイン)が利用されていたり、データのカスタマイズを行っている、データの見せ方や検索の方法を大きく変える必要がありカテゴリーやタグを大きく変更する、となればデータ移行の作業が必須となります。

そもそも、別の商用CMSからの移行や独自構築されたCMSからの移行の場合には、データ変換を行うことが前提となってきますし、CMSはデザインのデータがDBに入っているケースも多く、画像も含めて過去のデータを綺麗に表示できるようにするためには、かなりの工数がかかってきます。

作業量はデータボリュームにもよりますが、特にページボリュームのある大規模なWebサイトの場合には、見積りの大半がデータ移行作業という事もありえるので、過去のデータについてどこまでのクオリティで移行を行うかにより、対応コストが大幅に変わってきます。

「課題」を最適な形で解決するために

弊社ではフルスクラッチでの開発からフレームワークを使った開発、パッケージやオープンソースを使った開発、ASPでの開発まで幅広い開発プロジェクトに携わってきました。

もちろん、湯水のごとく予算を湯水のように使えて、ローンチまでの期間も十分取れるという幸せなプロジェクトであれば、「コスト」について気にする必要はありません。

しかし、どのようなプロジェクトにおいても、実現したい機能に対して予算とスケジュールは大抵少ないのが普通であり、実現したい機能と予算を鑑みてどこに機能と予算を割り当てるかを選択する事が求められます。

しかし、上に挙げた7つのポイントに意識を持って、プロジェクトにあたっていただければ、もっと低コストで最適なWebサイトやWebシステムが実現できる可能性が上がります。

是非、ITを使ったプロジェクトを検討されるのであれば、こちらに意識をしてみていただけると幸いです。

スポンサードサーチ