A Day In The Boy's Life -48ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

コンセプトのつくりかた/玉樹 真一郎
¥1,575
Amazon.co.jp


コンセプトというのはアイデアを具体化する上で重要な要素になってきますが、なかなかそれを考える機会というのはありません。

「何をどのように」という方法論や手段ばかりに気を取られて、そもそもそれを通して何を実現したいのかという信念が無かったりもします。

これでは、すばらしい物ができたとして、その用法が正しく人に伝えられたとしても、その人の心にはなかなか響かないでしょう。


私がこの本を本屋で見つけて買うきっかけになったのは、自分自身がWebサイトの運営において、何かよいアイデアというものが無いかという漠然とした悩みを持っていたからで、そもそもアイデアとコンセプトというのは異なるものですが、コンセプトという言葉を見たときにもっと根本の部分から考えないといけないことがあるのではないかと感じたからです。

この本で紹介されているのはコンセプトの見つけ方や作り方で、著者が任天堂に勤めていたという経歴があるため、新しいゲーム機を作るという命題の中でWiiというハードを作るためのコンセプトの作り方を方法論を交えて詳解しています。

当然、ここで書いてあるようにとんとん拍子で見つけていったわけではなく、かなりの試行錯誤があったのだと思いますが、そこに迫っていく過程は1つのストーリーとなっていてかなり読みやすくスッと頭に入ってくる本でした。


まぁ、この本を読んだからすぐにコンセプトというものが何なのかを理解することは難しいですし、そもそもコンセプトは自分自身の仕事や生活の中に千差万別で隠れているものでしょうから、その時々で考えていかないといけないことではあります。

コンセプトは大義名分でもありますから、その言葉によってそれを実現する仲間や組織を突き動かす原動力とならなくてもいけません。

1人で作ることや実現できることには限界がありますし、その製作に深く携わっている近い仲間であれば作ろうとしているものにあるコンセプトは理解できているものの、上司や外部の協力者、そしてそれを受け取る利用者の人にもすぐに理解できる概念が必要です。


自分がWebサイトのアイデアを考えるという、何かよい機能やサービスがあればよいという偏重した考えから、そもそもその機能やサービスというのは何を実現したいのか、そしてそれができたことで使う人に対してどういう幸せをもたらすのかという点を考えるきっかけになったのはよかったと思います。

そして、コンセプトを作ることで仲間がそれを理解し、ともに共有することで大きなエネルギーを生み出すきっかけになることは、アイデアが無いと悩んでた自分にとっては、それを実現する方法は自分の頭の中にだけあるものじゃないんだよ、という新たな気づきと励ましを与えてくれるものでした。



目次


第1部 おりていく コンセプトとは何か
01 霧の中から コンセプトとものづくり
02 勇者の登場 コンセプトのコンセプト
03 冒険の仲間 ものづくりのステップ
04 旗を掲げる コンセプトのかたち
05 悪魔のささやき 「良い」ということ
06 翼を授かる ビジョン
07 始まりの約束 アイテム
08 何を以て何を成すか コンセプト

第2部 のぼっていく コンセプトをつくる具体的なプロセス
09 産声は泣き声 悪口から「すきになる」
10 いたずら者の知恵 ズラして「かわる」
11 星座を見つける まとめて「わかる」
12 語り継がれるもの 「できる」ための物語化
13 影との戦い コンセプトの完成

第3部 すすんでいく コンセプトをどう活用するか
14 願いを込めて コンセプトから仕様へ
15 そして勇者は コンセプトの宿命



存在しないページへアクセスした際に表示する404ページをカスタマイズしているサイトはよくありますが、自分が担当するサイトでも同様にうまく設定していたはずのこの Not Found用のページが全然HTTPステータスコードとして404を返していないということがありました。

しかも、何故か大量にカスタマイズをした404ページへのアクセスログが出てたり。


A Day In The Boy's Life-Apache404error-1


上記のように、存在しないページ(/test)にアクセスした際に返されるHTTPステータスが302(Found)に、そしてカスタム404エラー用のmissing.htmlページが、ステータスコード200で返ってきています。

想定していた動作としては、/testのHTTPステータスコードが404で返ってくるというものです。



ApacheのErrorDocumentの設定を見直す


結論から言えば、ApacheのErrorDocumentの設定が誤っていました。

というか、設定ファイルの書き方次第で挙動が大きく異なります。


ErrorDocument 404 http://www.example.com/missing.html


上記のように、URLとしてエラードキュメントのパスを指定すると、該当のURLへ”転送”されます

正しくは、下記のように相対パスで指定します。


ErrorDocument 404 /missing.html

これで、再度アクセスしてみると・・・。


A Day In The Boy's Life-Apache404error-2


きっちり、404が返ってきています。

また、先ほどはURLバーに表示されているのが、missing.htmlでページが転送されていますが、今回は/testでユーザーがアクセスしたURLがそのまま表示されています。


設定したはずなのに、なんで404が返ってこないんだろうと少しはまってたのですが、Apacheのドキュメント を読めばちゃんと書いていました。


リモート URL (例えば、頭に http と付与した方法) を ErrorDocument に指定するとき、 たとえ文書が同じサーバにあろうとも、ドキュメントがどこにあるかを通知するために、 Apache はリダイレクトをクライアントに送出するということに、注意してください。 これにはいろいろと関連して起こる問題があります。 中でも最も重要なのは、クライアントは元々のエラーステータスコードを受け取らず、 代わりにリダイレクトのステータスコードを受け取るということです。 これにより、ステータスコードを使って URL が有効であるかどうかを決定しようとする ウェブロボットやその他クライアントを、混乱させるかもしれません。


書いてある通り、自分が混乱をしてしまっていたわけですが。

大量のカスタム404ページ(missing.html)がログに出ていた理由は、上記の設定の誤りから404ページへ転送されて正常なページアクセスと変わらないリクエストの状態となり、Apacheのアクセスログに出ていたわけですね。

ちなみに、404が大量に発生していた理由は、faviconによるものです。

これは余談ですが、以下のように設定すれば、faviconの404エラー出力を抑制することができます。

Redirect 404 /favicon.ico





自分は、社内ポータルの開発や運営をしているので、その中で色んな部門やプロジェクトの専用サイトを作りたいという要望を受ける事はよくあります。

で、サイトを公開したけど中には鳴かず飛ばずのものもあったりして、アクセス数を伸ばすためにはどうすればいいのかみたいな相談を受けたりもするのですが、そもそもイントラネットのサイトにおいては、アクセス数を伸ばすというのは結構無理があるものが多かったりしています。



インターネット上のサイト運営とイントラネット上のサイト運営の違い


そもそも、イントラネットは社内LANに限定されていたりしますので、アクセス数を伸ばそうにも母数が限られてきます。

インターネット上に公開したサイトのPV数を目標値に設定して、「月間100万PVを目指すぞ!」というのは興味を持ってくれるユーザーや客層というのはそれを大きく上回る数がいて、全然集客次第でどうにかなりそうな話ではあるのですが、イントラネット上では少なくともアクセスできる人のUU数で言えば社員の数を上回ることは無いわけです。

どんなにサイト運営者側が息巻いたところで限度があるわけで、それを無理に伸ばそうとすることに意味があるのかという風に思ったりもします。


もう1つは、アクセス数の多さがサイトの利用価値に直結するかというとそれも微妙で、要はサイトへアクセスするのは仕事上の時間になるわけなので、仕事しなくていいからこのサイトを見てねって事が公になっていればまだしも、そんな馬鹿げたお触れが出ることも無いので、興味があるものしか見ようとしません。

社内のサイトにおいては情報がダブるようなことはあまり無いので、そのサイト自体は絶対的優位な地位を築くことができるはずなのに、そんな状態であればよっぽどコンテンツに問題があるんじゃないかと思ったりもするのですが、何せさっきも書いたように興味を持ってくれないと見に来てくれないという状況の中で、その興味の対象は、イントラネット上に限らずインターネット上にもあるわけなので、なかなか素直に社員の人が社内のサイトへ興味を引く導線を作るのは難しいところでもあります。


ということで、そもそもPV数が劇的に伸びてものすごい数がアクセスされてきた状態で、「このサイトの認知度も上がりプロジェクトへの注目もあがってきている!」と素直に喜んでいいものなのか?という疑問も出てくるわけです。

そんなことよりも、社内サイトで伝えたい情報の核心というものが、社員に正しく伝わっていることの方が重要なんじゃなかろうかと思うのですが、それはなかなか目に見えにくいものなので、単純なPV数のような指標で短絡的な評価をしていても何にもならないのではないかと思います。


あとは、社内サイトの情報は読まなくても困ったときに聞ける人がすぐ近くにいたりしますし、必要なときに情報へのアクセスがしやすいことから、定期的にアクセスするリピーターというのが発生しにくい気がしています。

Googleの検索のように結果のサイトがころころ変わることは少ないですし、そもそも仕事の時間にアクセスすることから、結構シビアに必要なときに必要な情報としてしか見てくれないのではないかなと思います。



社内サイトのアクセス分析の難しさ


社内サイトのアクセス分析は、インターネット上にあるものと大して変わりはないものですが、サービスやツールが自前になることが多かったりして、なかなか見えづらくなる点があります。

外部のサービスが利用できなかったり、Webサーバーの生ログを解析するツールとかはあったりもしますが、あまりそこへの重要性というのは、サイト運営者以外では注目されなかったりもします。

ある情報を、決まった母数の人に対して均等に満遍なく浸透させるということが目的であったりしますから、その過程としては重宝されるでしょうけど、最終系のみんなが見ているという状態になればアクセス解析もそれほど必要性がなくなってきます。


そして、先に書いた例のように「必要な人に届いている情報」かどうかというのはアクセス分析の中ではなかなか見えづらいところでもあるので、単純なアクセス数というものでサイトの評価というのは計りきれません

そういったものを頼りにするよりは、アンケートでも取って生のユーザーの声を聞いたほうがよっぽど効果が見えてくるんじゃないのかって思ったりもします。

また、そのサイトを立ち上げた主目的であるプロジェクトや活動の内容を伝えることで、例えば事件や事故の件数が減ったのかとか、提案件数が上がったとか、お客さんからのクレームの数が減ったのかとか、多角的な分析の方が、最終的なゴールへの結びつきとしては重要になってくるでしょう。


こういったことを忘れて、単にアクセス数は多い方がいいというような感じで受け取られているのが疑問に感じるわけです。

個人のブログとかであれば、それがモチベーションにつながったり、サイトが広告媒体としての魅力を引き上げるというようなことはあるかもしれませんが、社内のサイトにおいては主目的や活動の内容を忘れがちになっているのではないかと感じることが多々あります。

まぁ、サイト運営にもコストがかかっているわけなので、そのサイトの制作費や運用費用というものが、割に合っているのかという評価としては必要になってくると思います。

それさえも忘れると、サイトの改善改善に工数を取られて、効果が出ているのかもわからないまま多くのコストと時間を浪費することにはなってしまいますので。


ただ、社内サイト(特に情報系のサイト)に関しては、売り上げに直結するようなものは難しかったりもしますので、単純な注目度としてのPV数はサイトの定量的な効果としては見えやすいものではあったりしますが、アクセス数の多さという定量的な指標がそのサイト運営にどういった効果をもたらしているのかというのはしっかり分析した方がよいのではないかと思うわけです。