SE時代は、すでにクライアントのビジネス課題が存在し、それを解決するために構築するシステムへの「要求事項」がある程度整理、具体化されていることを前提に、その「要件」を定義するところから、または定義された要件を具体化するところからプロジェクトがスタートしていました。
したがって、クライアントの要求事項に対し、システム設計・開発者の観点から、
- どの範囲を
- どういったレベル感で
- どのように構築するのか
を定義し、システム構成や各業務を実現する機能を設計に落とし込むという流れで進みます。そこでは、あくまでも自分の担当業務内、且つシステム目線での関わり方での仕事の進め方でした。
ところがイントリックスでは、クライアント自身も実現したいことがはっきりしていないため、情報が全く整理されていない曖昧な状態からプロジェクトが始まることがほとんどです。
そこで、クライアント及び競合他社とのWebサイトの比較や、アクセス解析などを通じたクライアントWebサイトへの理解、また、ヒアリングなどを通じたビジネスモデルの理解などを踏まえ、こちらから課題を定義し、提示しなければなりません。
また、課題について共有したのち、今度は改善の方向性として、Webサイトを通して、
どのように構築するのか
- 誰に対し(ターゲットユーザー)
- 何をどういった表現で伝え(コンテンツの内容や形式)
- 何を実現するのか(ゴール)
などのWeb活用のあるべき姿を、クライアントと議論し具体化する必要があります。
SCは、これらの課題やあるべき姿の具体化に、システム視点でコミットすることはもちろん、そのあるべき姿を実現し、かつそれが継続的に運用されるよう、システム面の構想を立てます。
例えば、
- 運用体制やフローについて、クライアントの企業規模や社内体制を加味した場合、どうあるべきか
- コンテンツの拡張を含むWeb活用の3年先を見据えた場合、継続的・効率的な運用を助けるために最良のシステムは何か
- コンテンツの更新頻度から、システムを導入し更新すべき適切な範囲はどこまでか
など、クライアントのビジネス全体の俯瞰視点に加え、社内体制や、Webの運用者目線など、様々な目線で考えなければなりません。
やはり、「要求事項」が具体化されていたSE時代とは、同じ「システム」と言っても、それに対する視点、考え方は大きく異なると感じています。