最高のWebサイト開発リーダーになるための五ヶ条【第二回】

f:id:ChigusaSatoh:20200807162113j:plain

 

みなさまこんにちは。佐藤千草です。
「最高のWebサイト開発リーダーになるための五ヶ条」連載第二回目です。
今回のテーマはこちら。

あなたは、クライアントのためではなく、サイトを訪れるお客さまのために開発をすべきである

ケーススタディ

例えば、あなたの担当するCMS開発プロジェクトで、ワークフロー機能(コンテンツの作成から公開までの業務フローをCMSシステム上で実現する機能)を実装することになったとします。
クライアントと担当ディレクターで取り決めたワークフロー設計書には、以下のように定義されていました。

  • CMSを利用するユーザは、コンテンツを編集できる「編集者」と、コンテンツを公開できる「承認者」の2種類の権限が必要。
  • 「編集者」がコンテンツを作成・更新し、「承認者」に承認依頼を流す。
  • 「承認者」がコンテンツのサイト表示をプレビューで確認し、承認操作を行うことで、コンテンツがサイト上に公開される。

担当ディレクターはあなたにこの設計書を渡し、こう伝えました。

「クライアントと仕様を詰めましたので、この設計書の通りに実装をお願いします。」

そこであなたは実装にとりかかろうとしましたが、ふとひとつの疑問が生じました。

「承認者」は、本当に「コンテンツを公開できる」権限だけを持っていればよいのか?
承認前に自らコンテンツを微修正してから公開したいケースもあるのではないか?
そもそも「承認者」が自身でコンテンツを作成・更新して、そのまま公開するケースはないのだろうか?

この疑問をディレクターに投げかけてみたところ、返事はこのようなものでした。

「クライアントからはそういう要望は特になかったですね」
「この設計書でクライアントに承認もらっちゃってるんで、この通りの仕様でお願いします!」

さて、あなたならどうしますか?

対応A

クライアントと直接やり取りをしているディレクターがそういうならと、「承認者」には「コンテンツを公開できる」権限しか付与せず、「コンテンツを編集できる」権限は付与しなかった。

対応B

ローンチ後にクライアントが運用に困ることがあるかもしれないと考え、クライアントにもう一度仕様をご確認いただくようディレクターに依頼をした。

対応Aを選択したあなたへ

ここであえて対応Aの是非を論じることはしませんが、起こりうる事態を推測して仮説を述べます。

あなたが対応Aを選択した理由は以下のようなものです。

「クライアントも特に要望しなかったって言うから、『承認者』にコンテンツ編集権限を持たせないのは、クライアントが本当に望んでいたことかもしれない」
「そもそも仕様を決める役割なのはディレクターだし、万が一あとでクライアントが困ったって自分のせいじゃない」

さて、サイトが公開され、実際にCMSをさわりはじめて、クライアントは初めてその運用のしづらさに気づきました。
そのクライアントは、あなたの会社に対して

「確かに取り決めた設計通りにはなってるけど、あまりにも気がきかなさすぎじゃない?」
「仕様の再確認や、改善提案をしてくれても良さそうなものなのに…」

と不満を抱くことになってしまいました…

ここであなたの会社に対して明確にクレームを入れてくれるクライアントなら、わざわざ時間を割いて「不満を持っている」ことを教えてくれているのですから、まだよいほうだと思わなければなりません。
制作者にとって一番怖いのは、クライアントの「声なき不満」に気づかないことです。
その不満は蓄積され、結果的に大きな仕事の受注機会を失うことだってあり得ます。

対応Bを選択したあなたへ

あなたは自分の役割だけにとらわれず、担当外のことでも「自分ごと」に考えることができているようです。
そんなあなたには、是非もう一歩先に進んでいただきたい。

実は、選択肢に挙げなかった「対応C」が存在します。

対応C

コンテンツの微修正に至るまで差し戻しが必要な運用であれば、それによってコンテンツの公開が遅れる可能性もある。
CMS運用が滞れば、サイトを訪れるお客さまに対して最適なタイミングで最適なコンテンツを提供することができない。
従って、是非とも改善しなければならない旨、ディレクターに説明のうえ、クライアントへの説明と仕様変更の承認を依頼した。

「クライアント最適化」を超えて「お客さま最適化」へ

ディレクターに対してアクションを起こすという意味では、対応BとCは同じです。
しかしながら、対応Bは「クライアントのため」の行動、対応Cは「サイトを訪れるお客さまのため」の行動です。

「改善しないと運用が不便になります」

ではなく

「改善しないとサイトを訪れるお客さまへのコンテンツ提供が滞ることになります」

と伝えることができれば、クライアントへのインパクトもより大きく、理解と承認を得やすくなります。

こういった対応の積み重ねによって、「クライアント最適化」を超えて「お客さま最適化」されたCMSが完成します。

この「お客さま最適化」実現のためには、第一回でのべた

  • プロジェクトの目的・目標を意識する
  • サイトがお客さまに提供しなければならないコンテンツ、サービス、ソリューションを意識する

が大前提となります。

Webサイトのすべてのコンテンツ、サービス、ソリューションは「サイトを訪れるお客さまのため」に存在しています。
お客さまのニーズを把握してはじめて、ひとつひとつの機能について、何をどのように実装すべきかの方向性が明確に決まってきます。

そのことを忘れずに日々の仕事に取り組むことで、クライアントは「あの会社は常に我々のお客さまのことを考えて対応してくれる」と認識し、あなたの会社の価値を高めてくれることでしょう。

それではまた次回お会いしましょう。

まとめ

なぜ、あなたのチームが開発するシステムはクライアントに喜ばれないのか?

サイトを訪れるお客さまにまで意識が向いていないから

  • クライアントやディレクターの認識がぶれていても気づかずにそのまま実装してしまう
  • 改善を提案したとしても、必要性へのインパクトが弱く、提案を通すことができない

お客さまに最適化されたシステムを実現するためにやるべきこと

  • 「クライアント最適化」の一歩先「お客さま最適化」を意識する
  • クライアントやディレクターの指示や設計がそこからぶれていれば指摘し、お客さまのためにどのような実装をすればよいか提案する