全ては要求の理解から始まる

みなさんはどのようなアプローチでサイト設計を開始していますか?
仕事でお客様のサイトを作る場合も、趣味で個人のサイトを作る場合も必ずサイトを設計しています。それが意識的であれ、無意識的であれ、サイトの設計を開始して、そして終了しているのです。すべての作業が個人で完結するのであれば、どのような進め方でも構わないと思います。しかし、クライアントのサイトを設計する際には、クライアントが求めるサイトへの要求を完全に理解した上で設計を行い、その過程を共有し、納得してもらうことでより円滑にプロジェクトを推進できるのでは無いでしょうか。今回はその過程の中で工夫していることについて書きたいと思います。

私はクラアイントのウェブサイトの情報設計やUI設計、フロントエンドの技術コンサルティング等をしています。数十ページぐらいの小規模なサイトから数千ページにもなる大規模なサイトまで、担当する仕事も様々ですし、クライアントの業種や業態も毎回異なります。このような日々の業務の中で最も気をつけている作業の一つとして「クライアントの要求を理解する」という過程があります。どんなに優れた情報設計や、どんなに優れたサイトであってもクライアントの要求されているものと違うコンテンツを作成しては意味がありません。そのためにもクライアントと一歩一歩認識を共有しながら設計を進めていく必要がありますし、何よりもクライアントの要求を完全に理解する必要があります。

みなさんは「要求を理解する」ためのアクションとして何をイメージしますか?
多くの方はヒアリングと答えると思います。もちろんこれも正解です。それほど大きくないサイトを設計する場合、この方法が最も効率の良い手段でしょう。しかし、大規模なサイトの場合だとどうでしょうか。各事業部にヒアリングの対象者様が数名おられる場合、すぐに数十名の方とヒアリングをすることとなります。その上、担当者ごとに要求のレベルに差がある場合がほとんどですので総論の要求と各論の要求でコンフリクトを起こすこともしばしばあります。これではヒアリングを行えば行うほど要求がぶれて、悩んでしまいますね。その上、担当者同士の認識のずれも明確化されないためサイト全体として間違った方向に進んでしまうかも知れません。
要求を可視化する

この問題を解決するために
|
1.
|
迅速に
|
|
2.
|
均質化された情報で
|
|
3.
|
要求を可視化する
|

必要があります。まず、担当者ごとの要求に差異があるため、均質化した情報に統一する必要があります。そしてこれらを可視化することでようやくサイト全体としての要求を洗い出せるのです。このように洗い出したサイトの全体像は往々にして矛盾点や重複部分を抱えているものです。これらは可視化された図を俯瞰すれば一目瞭然ですが、各担当者にヒアリングを行い、ドキュメントにまとめるだけでは直感的に理解しにくいし、担当者同士の矛盾や問題も表層化されません。こんな要望に応えてくれる夢のソリューションはあるのでしょうか。

最近参画したプロジェクトで私は上記の問題に直面しました。
そのプロジェクトはある大規模な情報ポータルサイトのリニューアル案件で、社をあげての取り組みでしたのでクライアントの社員全員が何らかの形でプロジェクトに参加されていると言う非常に大きなプロジェクトでした。またインターネットでのコンテンツサービスを事業とされている企業ですので、インターネット関連の技術や流行などについても非常に精通されているという特徴がありました。

最初は担当者ごとにヒアリングを行いすべての要求を理解しようと試みたのですが、あまりにも事業部ごとで担当者同士の認識のずれが大きかったため次第に悩むようになりました。しかし、よくよく話を聞いてみると事業部間でのコミュニケーション不足による認識のずれがほとんどであることに気づきました。つまりクライアント側もプロジェクトが巨大すぎるために、全員が要求すべき内容を理解しているわけでは無かったのです。そこで考えた結果、Wikiを使って要求を可視化するという試みを行いました。

このプロジェクトでは大きく3つのサイトが存在し、それらを共通したコンテンツによって橋渡しするという概念がありました。しかし、橋渡しのイメージが3つのサイトで全く異なっており、さらに3つのサイトに重複したコンテンツが複数存在するという問題を抱えていました。これらの問題を表面化させ、軌道修正を行うために以下の手順で要求を可視化しました。
|
1.
|
担当者様にヒアリングした内容を元に仮サイトストラクチャを作成
|
2.
|
仮サイトストラクチャにIDを割振り、これらのIDに紐付く形でWiki上にブランクページを作成
|
|
3.
|
仮サイトストラクチャ上で定義されている主導線をWiki上でリンクとして定義
|
4.
|
担当者にページ単位ごとに思い思い表示要素の洗い出しとリンクの定義を行ってもらう
|
5.
|
追加されるページ、削除されるページは都度、変更依頼を頂き仮サイトストラクチャを最新版に保つ
|

|
|
図: Wikiの作成手順イメージ
|
※クリックすると拡大されます
|
このようなアプローチを使って、私がWikiの状態を逐次把握しながらプロジェクトを牽引しました。作業期間は2週間、Wikiに担当者ごとの思いの丈を存分に記入していただくことでクライアントの総意としてのサイト全体を描くことができました。
結果、先に述べたような問題を表面化し検討することができ混迷を極めたプロジェクトを前に進めることができました。またこれら要求を洗いざらい出していただくことでクライアントが本当に考えている思いや課題を肌で感じることができ、設計指針を提示する際に非常に役に立ちました。システム設計担当にも「マックス状態でのプロジェクトスコープです」という注釈は付きますが、要求仕様のイメージとして情報を提供できたのでスケジュールをラップアップすることができました。
一方で、初めての試みだったので、いくつかの反省点もあります。
具体的には
|
1.
|
表示能力が貧弱なため、イメージがわきにくい
|
|
2.
|
ファイル管理コストが高い
|
|
3.
|
ラベリングの統一を効率的に行う方法が無い
|

上記の問題があると感じました。まず表示能力についてですが、通常のWikiの表示パターンでは淡々としすぎていて今ひとつイメージが伝わりにくいようです。またWikiと仮サイトストラクチャとの同期を人力で行っているため、間違いが発生する可能性があります。ラベリングについても統一させたい場合に一括で検索できるのですが、置換は都度手入力を行うため作業効率が悪く、間違いが起こる可能性があります。これらの問題を解決できればより迅速に要求を可視化することができるのでは無いかと思います。

今後はこの手法をよりブラッシュアップしていくことで、クライアントの要求を打合せの中で入力し、編集することができると考えています。現状抱えている問題を一つずつ解決していくことで、将来的にはより正確で効率的な要求の理解を実現できる可能性もあるでしょう。
さらに、その手法を受けて現在行っているサイトストラクチャやワイヤーフレームという設計手法に取って代わる方法を開発できる可能性もあると思います。このように私たちは既成概念に捕われずに様々な可能性に挑戦することで、よりクライアントの要求にあったサイトを迅速に構築できるよう日々取り組んでいます。