リソース・シェアリングでは、経営者の課題を解決する際に一番重要視しているのがプロジェクト・フローの中の「要求定義」です。
コンサルティングフェーズ
コンサルティングフェーズは、我々がプロジェクトに携わる最初のステップです。
このフェーズでは、クライアントと一体となってコンサルティング作業を実施することで、経営課題を明確にし、現状を把握し、プロジェクトで実現すべきゴールを要求定義で明確にします。
ヒアリング
リソース・シェアリングにお問合せをいただいたクライアントに対しては、まずはヒアリングを行います。
このヒアリングで重視をするのは、経営課題を明確にし、経営課題を解決する事によって得たいゴールがどこにあるのかを見つけだす事です。
弊社へのお問合せは、新規事業や新サービスの立ち上げから、Webサイトのリニューアル、ECサイト構築、CMS導入、システム開発など様々ですが、これらは基本的にソリューションの導入です。
しかし、ソリューションは、経営課題と到達するゴールが明確で、解決方法としてソリューションがはまる場合にのみ有効に働きません。
例えばWebサイトのリニューアルを行いたいという依頼であっても、実際の経営課題は、既存顧客の売上を増やしたい、新たな集客チャネルの構築をして新規顧客数増やしたい、顧客にダイレクトに販売をしていきたい、など多岐に渡ります。
また、もっと内部的な経営課題があって、システム導入や運用業務フロー改善による運用負担軽減、社内システムとの連携による運用負荷軽減や人員削減を目的としている場合もあります。
このようにヒアリングでは、単なるソリューションの提案ではなく、経営課題を明確にし、到達したいゴールを明確にしていきます。
現状分析
経営課題が明確になり、到達したいゴールが明確になっても、経営課題を解決するためには外部環境や競合の状況を含めた現状を把握をすることが重要です。
環境分析で行うのは、主に当該業界（及び関連業界）の現在及び将来に対して影響を及ぼす、政治・経済・法律・技術の趨勢といったマクロ要因、業界などの外部要因です。
また、競合調査で行うのは、クライアントの競合企業、また全く別の業界であっても競合となりうる企業が現在どういったインターネットを使ってどうのような戦略を行なっており、今後どういった影響を与えるのかを調査します。
自社分析では、競合他社の中で顧客の占める立場及び状況はどのような状況であるのか、クライアントの最大の強みはなんなのか、また有形資産、無形資産といったものは何がありどのように生かされているのか、現在保有しているWebサイトやWebサービスはどういったものなのか、といった観点から実施します。
この際には、マネージメント層や担当者へのヒアリング、担当部署へのグループインタビューや業務分析などを行います。
さらに、WebサイトやWebシステムの場合には、環境調査・競合調査やターゲット分析・ペルソナ設計、Web解析コンサルティング、Web Marketing Audit（Webマーケティング・オーディット）、Heuristic Assesment（ヒューリスティック監査）を行って、ヒアリングで明らかにした「課題」と「ゴール」が正しいか、具体的なデータによって粒度を上げて調査します。
要求定義
ヒアリングにより、解決すべき経営課題と実現したいゴールを把握し、現状分析により外部環境、競合の状況、自社の利用できるリソース、足りないリソースが見えてくれば、経営課題をどのように解決してゴールを実現するのかが見えてきます。
そこで、コンサルティングにより明確になった解決すべき経営課題と達成すべきゴールを実現するためには、どういったどのような改善方法や実施施策をとるべきかを、クライアントサイドの要求定義として言語化します。
要求定義は、クライアント自身がITを使ったプロジェクトで実現したいゴールを明確に定義するものです。
そのため、まずクライアント自身が経営課題を解決し、設定したゴールにたどり着くまでに必要な要件を、要求定義書にまとめることが、プロジェクトを成功させるためには大変重要であり、我々が重要視しているものです。
要件定義
要件定義は、経営課題を解決し、設定したゴールに到達するために実際に作るべき仕様をまとめる作業です。
要件定義は、ITを使ったプロジェクトで実際にシステムなどを構築するための仕様を定義したものであり、システムを構築するWeb制作会社や開発ベンダーが構築するシステムの内容を明確にするものです。
要求定義書の内容を具現化するため、コンサルティングで洗い出した業務フローと必要な要件をまとめて、要件定義書を随時作成します。
要件定義は、要求定義の後に行うのが望ましいですが、要求定義から要件定義が作成できない場合には、ベンダー選定後に行う場合に行う場合もあります。
RFP作成及びベンダー選定
この段階で開発ベンダーが決まっていない場合には、スケジュールや予算も含めたRFP（Request for Proposal）を要求定義書や要件定義書から作成します。
また、開発ベンダーを選定するために、技術力や実績などから開発を行ってくれる会社を複数選定し、RFPを展開して入札を実施します。
入札では、ベンダー選定に参加してくれた会社がRFPを元に行った提案内容や見積金額を元に検討して、実際の構築を行う会社を選定します。
構築フェーズ
構築フェーズでは、コンサルティングフェーズで決定した要求定義・要件定義の内容をITで具現化していきます。
また、WBS（Work Breakdown Structure）とRedmine等のプロジェクト管理ツールを組み合わせて開発を行うことで、短納期案件や大規模案件においても炎上のリスクを最小限にしながらの開発を可能にしております。
プロジェクト・マネジメント
「要件定義」の後、「基本設計」、「詳細設計」、「開発」、「テスト」とプロジェクトを具体的に進めていくためのプロジェクト・マネジメントを行っていきます。
この際、必ずドキュメントの作成とRedmine、Slack、Backlog、Githubといった、プロジェクト・マネジメント・ツールやチャットサービス、バージョン管理システムを使い、緻密なプロジェクト・マネジメントを行っていきます。
設計
設計においては、要件定義書で決まった仕様を満たす、開発計画の策定と詳細な機能要件の落とし込みを行います。
ここで実装段階におけるクライアントとの齟齬が発生するリスクを最小限にしていくために、基本設計、アーキテクチャ設計、アプリケーション設計、UI/UX設計などを行い、基本設計書や詳細設計書、画面設計書、機能設計書といったドキュメントを作成して設計を行います。
基本設計
「基本設計」は、「要件定義書」をもとに開発しようとするWebサイトやWebシステムが具体的にどのような機能を必要とし、どのようなユーザーインターフェイスを持つかを設計するもので、この際に作られるドキュメントが「基本設計書」になります。
「基本設計」では、「要件定義書」で求められる機能の詳細な要件や非機能要件、制約条件を、実際にプログラミングが可能な形にまで落とし込んでいきます。
そのため、「基本設計書」に記述されるものは大きく3つに分かれます。
アーキテクチャ設計
アーキテクチャ設計においては、Webシステムを載せるプラットフォーム設計（インフラ、ミドルウェア、プラットフォーム，フレームワークなど）、利用するアプリケーションやアーキテクチャ設計(アプリケーション全体の構造など)、開発標準やテスト方式の設計を行います。
アプリケーション設計
アプリケーション設計では、システム全体を機能単位、画面単位のモジュールに分割し、どのような画面機能がどのような遷移で必要かといった詳細な設計、データベースの設計、帳票類はどういったものを出力すべきかの設計、定期的に走らせる必要がある集計スクリプトはどういったものが必要か、といった事を行います。
UI設計・UX設計
UI設計・UX設計では、WebシステムでどういったUIやUXが必要なのかをアプリケーション設計と連動して設計します。
また、マルチデバイス対応を想定した画面設計やコンバージョンを実現するためのユーザー導線設計等もこの段階で行っていきます。
ただし、弊社のプロジェクトではシステムが絡まないものは非常に少ないため、ワイヤーフレームの作成だけを行う事は少なく、要素以外にも機能要件までドキュメントに落とし込んだ画面設計書として作成される事が多くなっています。
その他の設計
アーキテクチャ、アプリケーション、UI・UX以外にもセキュリティ設計、性能や信頼性の設計、リニューアルやシステム移行がある場合にはシステムや業務フローの移行設計や運用設計を、必要に応じて行います。
「基本設計」で作成される「基本設計書」は、案件の規模や予算に合わせて「要件定義書」と一体化した「機能仕様書」というドキュメントのみを作成する場合もあります。
開発
設計が終了すると、実際のシステムを作る開発フェーズに入っていきます。
まず最初に行われるのが、基本設計書に基づく開発環境の構築です。
通常、本番公開用の本番サーバ、本番サーバに載せる前にテストを行うステージングサーバ、開発に利用する開発サーバの最低3つの環境が用意されますが、フェーズ分けでのリリースを行う場合には、開発サーバやステージングサーバをさらに複数台設けるケースもあります。
実際のシステム開発にあたっては、基本設計で定められたパッケージ、開発に利用するプログラミング言語、開発フレームワーク、データベースで開発を行っていきますが、通常はさらに基本設計書の機能を具体的にどのように作成をするかを詳細設計書に落とし込む詳細設計を経て開発を行っていきます。
テスト
単体テスト
構築されたシステムは、各開発者毎での単体テストを経てリリースに向けて進んでいきます。
結合テスト・総合テスト
全ての開発が終了すると、結合テストと総合テストという二つのテストを行いますが、必ず設計者が機能要件を満たしているのかを確認するためのテスト設計書を作成し、それに従ってテストを行います。
テストに際しては、OS、端末、ブラウザなどを使った実機でのテストはもちろんのこと、業務フロー毎のテストケースを用意し、開発が行われたシステムが見た目上でも機能上でも正しく動いているかを結合テストでは検証します。
また、Webシステムがあらゆるところで利用されている現在では、社内システムとの連携や外部APIとの接続が行われるケースも多く、それらと正しくデータのやり取りができているかを、総合テストでは確認します。
データ移行・コンテンツ投入
システムリニューアルやWebサイトリニューアルでは、データ移行やコンテンツ移行で不具合を発生することが多いため、運用が行われているシステムだけでなくても、慎重に行う事が求められます。
また、オウンドメディアのWebサイト構築などの随時コンテンツが追加されるためサービスの場合には、弊社テスト後の受入テスト中にコンテンツの投入が行われるケースが多くなっています。
受入テスト
これらのテストで出たバグや障害に全て対応した後、クライアント側でもテストを行っていただき、要件定義で決めた通りのものができているかを受入テストで確認してもらいます。
公開・検収
WebサイトやWebサービスの場合はリリースやサービススタート、Webシステムなどの場合には運用開始がローンチとなります。
システムリニューアルの場合には、DNSの切り替えやサーバの入れ替えなどがありますので、最後まで気を抜けないところです。
無事にWebサービスやWebシステムのリリースができたら、基本的にはこれが検収となります。
ただ、ローンチは単なるスタート地点であり、運用の開始を告げる合図でしかありません。
運用フェーズ
運用については、情報システム部門だけ社内のサーバ運用やシステム運用だけを行っていた時代とは、今では大きく変わっています。
現在では社内向け以外にも外部向けのWebサイトやWebサービス、ECサイトの運用などが求められ、コンテンツ運用、ソーシャルメディア運用、Web解析、SEO、SEM、DSPといった広告領域の運用までを想定した運用が必要となっています。
そのため、公開後のWebサイトやWebサービスに対しては、SEO/SEMの運用とコンテンツ運用、Web解析の全てをワンストップで運用することで、コンサルティングフェーズで決定したゴールを実現するための運用が求められます。
また、基幹システムでもWebサービスのシステムでも、システムの基本は24時間365日稼働をし続けることが前提となります。
そのため、システムだけでなくインフラも含めた保守が求められます。
インフラ運用及びシステム運用
WebサービスやWebシステムがリリースされると、保守と運用が始まります。
ローンチ後のWebサイトやWebシステムは、サービスを止めずに24時間365日運用し続けるのが基本であり、セキュリティ対応やシステム障害に継続して対応し続ける事が必要です。
特にWebサイトの場合には、表示スピードの遅さは検索順位にも影響し、ECサイトの場合にはアクセス集中により表示ができないとなると、販売機会の損失を招くため高速化処理や大規模アクセス対応などにも対応していく事も求められます。
そのためには、WebサーバやDBサーバなどのインフラにおいては、セキュリティパッチを常に最新のものをあてて続けるサーバ保守が、システムにおいても開発言語やフレームワークに対するセキュリティ対応を行っていくシステム保守を行い、システム障害が出た場合には対応を行うという運用は必須です。
コンテンツ運用
Googleの検索技術が向上するに従い、コンテンツ自体の中身が評価されて上位表示を実現する「コンテンツ・イズ・キング」の時代が到来しました。
これにより、Webサイトの運用においても、WebマーケティングやSEOを想定したコンテンツ作成やソーシャルメディアを想定したコンテンツ作成が必要となっており、リソース・シェアリングではSEOを想定したコンテンツ運用、ソーシャルメディア運用についてもトータルでサポートいたします。
SEO・SEM対応
検索エンジンからの流入が重要な現在において、Webサイトの運用において、SEO（検索エンジン最適化）、SEM（検索エンジンマーケティング）を使った集客戦略をどう考えるかは大変重要となっています。
また、ただ単に集客するだけでなく、Webサイトで実現したい「ゴール」（コンバージョンやお問合せ）を実現しようとすると、集客施策だけでの最適化には意味がありません。
そのため、集客施策においてもWebサイト運用とWeb解析はセットでの運用を行なっております。
Web解析
Webサイトには売上拡大やお問合せの増加など、Webサイトを構築して運用を行なって上で解決したい「課題」と「ゴール」が必ず存在します。
「ゴール」が達成されているのか、達成されていない場合は何が課題となっているのかを判断するためには、判断を行うための指標と現状を分析するWeb解析が必要となります。
Web解析を行うと、「どこ広告が問合せにつながったのか？」、「どのようなキーワードで検索してユーザーが来るのか？」、「どういったユーザーが商品購入を行うのか？」、「どのページで閲覧終了しWebサイトから離脱されてしまうことが多いのか？」といった現状が明確になります。
この現状を基に仮説立てて、改善の施策を立案し、施策を実施して、その結果をさらにWeb解析で確認するという「Plan-Do-Check-Action」を回していくことがWebサイト運用においては非常に重要ですが、リソース・シェアリングは長年Web解析に携わってきた経験から、Web解析コンサルティングを行っています。