紀井 斎（制作部長）
新技術の導入、新商材の開発まで手掛け品質・運用管理を統括
食品メーカー内の情報処理部門における基幹システム運用管理・インフラ整備・Webサイト制作などで得た豊富な経験をもとに、Webサイト構築、品質管理、運用管理、新技術の検証・導入、新商材の企画・開発を行う。現在は、制作部門のマネジメントを担うとともに社員育成にも力を入れ、社内大学制度では自ら講師として教壇に立って人材の”人財化”を推進。企業価値を高められる人材創出に奔走している。
プログラミング人材育成品質管理
今日は、Webコンサルタント.jpの紀井でございます。
本日の記事は、ここから何かを学びとれたらと思い綴っていこうかと思います。
今年1月に見かけたニュースでは、相当インパクトの大きなものでした。
経済産業省発行の調査報告書（http://www.meti.go.jp/press/20100820003/20100820003.html）、100ページ近いですが拝見しました。
本件は、開発に至る前の設計のところまでしか進捗しなかったようです。
発足から6年も経過して、設計すら終わらないというのはどういう事なのかと思ったのですが、今回のプロジェクトの規模が大きすぎたというのがまずあると思います。
特許庁の業務に関わる部分は秘密事項に当たるためシステムの全容はわからないのですが、報告書の中にあった検査項目から規模感が垣間見えた気がします。
チェック項目だけで、数万点という規模。関わった設計関連の人員が1000名以上。
これだけでも、とてつもなく大きなプロジェクトだとわかります。
システムの設計という事で一般論で考えますと、お客様からご要望をいただき、そこから業務要件・利用者要件・機能要件をまとめた要求仕様書の策定。
要求仕様書から、概要仕様書・基本仕様書・詳細仕様書などをおこしていきます。
それぞれ仕様書の中では、ソフトウェアにあたる部分だけではなく、それらを取り巻く環境としてネットワーク仕様・ハードウェア仕様なども含まれています。
各々仕様書が仕上がってようやく開発コーディングに入っていくわけですが、開発の前段にある設計がしっかりできてないとシステム構築はできません。
家に例えると、家を建てたい施主とそれを仲介する不動産会社、施工する工務店の関係ややりとりに近しいのではないでしょうか。
施主は、どのような家にしたいかをイメージし、不動産会社で相談します。
そこから、住む場所や家の構造について大枠を決めていきます。
ここまでは、要求仕様書といってもいいかもしれません。
次は工務店へ相談します。
施主と不動産会社が打ち合わせして決めた要件から工務店は家の設計書を作ります。
工務店が設計書を作って一度家を作り始めてしまったら、施主が「あ、やっぱり、強度を高めたいから鉄骨にしてほしい」などと言っても最早手遅れなのは言うまでもありません。
だからこそ、それに至る要求の定義というのがいかに重要かがわかります。
冬ならストーブやこたつを設置したり、夏なら風鈴が奏でる音を楽しむ。
家族が増えれば、増築を行い居住空間を広げる。
数十年住み続けた末に、リフォームもしくは建て直す。
このように、シーンに合わせて変更をしていくを想定した場合、情報の骨格と鮮度を意識すると良いと思います。
Webサイトを構築した後に、家で言うと階段の位置を変更するような構造変更を行う事はまずしないと思います。
骨格を不用意に変えてしまうと、全体の構造に無理が生じてしまいます。
逆に、情報鮮度的にキャンペーン情報や、商品情報などこまめにメインテナンスした方が望ましい情報もあります。
Webですので気軽に修正を出来てしまう部分は多いですが、骨格部分には触れず情報鮮度を高く保つ必要がある部分だけに注力していく事で、効果的な運用が出来ると思います。
そうするためには、やはり初めの要件定義がもっとも重要となるわけです。
要件を的確にまとめ上げ、お客様の意に沿うように初めにしっかり設計する事が、Web戦略を成功させるポイントではないでしょうか。
掲題にあるプロジェクトでは、すべての要件を取りまとめられるだけの優秀な要求アナリストの存在が不可欠だというのが一般論かもしれません。
業務に精通し、コミュニケーションがとれて、技術にもある程度精通ししていなければ、成功は難しいでしょう。
また、その先にあるプロジェクトマネジメントも大きな要素を締めています。
1,000人規模のプロジェクトですから、誰が何をいつまでにどうやって作るのかなども詳細に把握する必要があるでしょう。
特許庁のプロジェクトが失敗してしまった原因の真相がどうなのかはわかりませんが、報告書を見る限りは設計部分で上手くいかなかったとありましたので、ここから学べるのはご要望をしっかりヒアリングし、設計をしっかりやる事や関係部門との連携は巨大なプロジェクト程、密に行う必要があるという事でしょうか。
弊社では、特許庁のような巨大なシステム構築はお受けしておりませんが、中小・ベンチャー企業様にお力添えできるよう適切なサイトの規模感やWeb戦略などをご提案差し上げております。
Webサイトの立ち上げだけではなく、リスティング広告出稿やFacebook、スマートフォン対応など、お客様に適したサービスも随時ご提案をさせていただいておりますので、Web戦略でお悩みの方は、是非当社へお声掛けください。
それでは、本日はこの辺で
この記事に関連するテーマ
2011年10月14日 開設10周年を迎え、歯科医院検索・診療予約ポータルサイト「歯科タウン」をリニューアルしました。（プレスリリース http://www.freesale.co.jp/news/release/shikatown10.html）
2010年5月に行ったリニューアルは、歯科タウンを支えてくださっている利用者様からいただいたご意見を元に全国約68,000軒の歯科医院様の情報を掲載しており、ポータルとしての使い勝手や安全性を強化すべくバックヤード側の仕組みの強化をメインに行っておりました。
今回のリニューアルでは、利用者様の利便性の向上や欲しい情報の見つけやすさなどを強化しており、プレスリリースにも掲載しておりますが検索機能の精度向上や「最近見た歯科医院」なども表示する機能を追加しております。
これにより、今までよりも快適に歯科タウンをご利用いただけるかと思います。
また、昨今新しいデバイスの登場による利用者様の閲覧環境が多様化したことにも対応させるため、FLASH非対応端末でも同じように利用できるような構造にいたしました。
歯科タウンスマートフォンは、2011年7月に既に公開しており、こちらもPC版・スマートフォン版を画面切り替えで自由にご利用いただけます。
利便性だけはなく、時流のソーシャル化という点においても配慮しており、いいね！、Twitter、Google+1の各ボタンも配置しておりますので、歯科タウン内の任意のページで情報を拡散していただくことが可能になっております。
これは、各ソーシャルメディアがGoogleなどの検索エンジンにインデックスされ始めている事を受け、SEO強化の点でも歯科タウンとしては重要な機能追加の一つになっています。
歯科タウンの本質的なところでは、お目当ての歯科医院様に行く前に診療方針が確認出来る事や、院内の様子も写真などで垣間見る事ができますので、安心して診療予約していただけるかと思います。
今後も、利用者様にとって価値の高い媒体でありつづけらえるよう様々な取り組みを行なっていきますので、ぜひ、歯科タウンをご利用いただきたく思います！
また、興味をもっていただけた歯科医院様は、まずはご連絡ください。
歯科タウン掲載ご希望の医院様向けのお問い合わせフォーム
お問い合わせ種別を「掲載に関するお問い合わせ」にしていただきお問い合わせいただけましたら幸いでございます。
それでは、本日はこの辺で
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
日本の中小企業では、低価格CMSとしてMovableTypeをCMSカスタマイズして利用するのが一時期は多く見られましたが、最近では欧米のようにWordPressを利用しているケースが多く見られるようになりました。
過去、何かのWebサービスを利用する場合、無料のサービスはもちろんありましたが、企業・エンドユーザー関係なく有料になるケースが多かったように記憶しております。
Mixi等に代表されるソーシャルネットワーキングサービスであるSNSが隆盛を迎える頃にはエンドユーザーはほとんどのサービスを無料で利用できるようになってきました。
それにつられるようにして提供側も原価を抑えるべく試行錯誤した時代を経て、現在に至っているわけですが……
CMS構築ツールはいくつかありますが、中小企業で多く利用されているのはシックスアパート社が提供しているMovableTypeがそうではないでしょうか。
管理画面こそ動的な作りになっていますが、サイト利用者はほぼ静的ページを閲覧できる仕組みになっています。
故に、サーバースペックは大きくする必要性が（もちろんサイト規模によりますが）低くなります。
となってくるとホスティング会社も低価格のサーバーラインナップを用意できますし、ニーズにマッチした商売が成り立つのだと感じています。
低価格CMS、低価格ホスティング、それでもなお原価を抑えたいと思う企業や、個人サイトを構築したい人は無料で且つ新しい機能を有したCMSを求めるのが市場原理。
そんな背景があってか、なかってか、欧米ではWordPressを利用するケースがMovableTypeより多いのではないでしょうか
日本でもWordPressの利用者が増えてきている傾向にあるのですが、導入に際して課題があるようです。
MovaleTypeのようにライセンス費用がかからない反面、ある程度のサイト規模になると動作が重くなり、そこそこのサーバーのスペックを要求されるという声も聞かれております。
そこで、当社でもそういったお悩みに答えられるよう、WordPressのウイークポイントを確認するための簡単なブラックボックステストを行い、回避策を検証してみました。
KeepAliveで遅延処理が適切な値になっているか、メモリのスワップ状況はどうなってるか、CPU、メモリの使用率等々を検証してみました。（上図は、検証過程のごく一部です。）
こういった検証の結果はそれだけではあまり意味がありませんが、もっと多方面からの検証結果を併せることで、課題解決のアイデアが生まれてきます。
単純にホスティングに割く費用を大きくすれば、それだけ高性能なサーバーで運用できるため、もろもろの心配は不要なのですが、「不用意に大きな費用はかけず、いいものを提供する」というのは商売の原点ではないでしょうか
これは検証のほんの一部ですが、当社ではこういった実験の中から、ロー～ミドルレンジ向けのサービスとして、オープンソースでも安心して利用できる検証を行っております。
オープンソースをご利用中でお困りの方は是非一度ご相談ください！
では、本日はこれにて
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
http://www.google.co.jp/ での検索結果画面の各サイトタイトル右側に「+1」が実装され始めました。
あれはいったいどのようなものなのか、首をかしげる人も少なくないと思います。
このサービスは、2011年3月末に本家、google.comで先に実装されており、公開当初はベータ版として試験運用的なものだったかと思います。
で、そもそも、これ何なのか？という話ですが、現状正式公開している（私が目視で確認できた）機能では
1 「+1」を押下したサイトのリストが、Googleプロフィール内の「+1」にリスト表示される
2 検索結果画面で、過去「+1」押下したサイトは、「+1」ボタンの色が青色に変化している
3 検索結果画面で、過去「+1」押下したサイトは、ページ概要下に「あなたが +1 を付けました」と表示される
でした。
google.comでは、
+1 を参考にする検索するとき、同じような情報を探して先に見つけた友だちの意見があればとても役立ちます。検索結果でこのようなおすすめ情報を手軽に参照できれば便利だと思いませんか？
友達がすすめていたホテルを探すときや、支援する慈善団体を探すときは、+1 が参考になります。なお、+1 を見るには Google アカウントにログインしている必要があります。
http://www.google.com/intl/ja/+1/button/
とあります。
可視的なところですと、3の「あなたが +1 を付けました」の部分に何らかの関係がある別ユーザが付けた、たとえば「小川さんが +1 を付けました」と出るようになるそうです。
パーソナライズ検索の一種ですが、この「+1」が及ぼす影響として、何らかの関係がある別ユーザが「+1」した情報が検索結果に反映されるとも言われています。
今後Googleでの検索結果が、純粋なSEO結果にパーソナライズされたデータが上乗せされて順位が変動していくような流れになるでしょう。
じゃ、SEO対策どうすれば？と思われたかもしれませんが、SEO対策はこれまでどおり行っていただき、そこに「+1」したユーザー、つまりサイトに興味を持ってもらえるであろうユーザーの訪問が増加するのではないかと思います。
ということは、質の高い見込みユーザーがサイトに訪問する事になるため、質の良いサイトを準備できていれば、よりコンバージョン（成約）につながっていくのではないかと個人的には感じています。
来るべき時にそなえ、新しく自社サイトをリニューアルするだけでなく、質（量・鮮度ともに）を継続的に高めた状態を維持しておく必要はありそうです。
弊社では、導入時のWeb戦略から、サイト制作、サイト納品後の保守・サポート、改善ご提案をワンストップでご提供させていただいておりますので、一度ご相談いただければ幸いです。
Webインテグレーション事業（http://www.freesale.co.jp/service/integration.html）
Webコンサルティング事業（http://www.freesale.co.jp/service/consulting.html）
Webコンサルティング（http://www.web-consultants.jp/service/consulting/）
Webサイト制作（http://www.web-consultants.jp/service/website/）
アクセス解析（http://www.web-consultants.jp/service/analysis/）
SEO（http://www.web-consultants.jp/service/seo/）
リスティング広告（http://www.web-consultants.jp/service/listing/）
映像制作（http://www.web-consultants.jp/service/movie/）
Webライティング（http://www.web-consultants.jp/service/writing/）
少々宣伝を挟みましたが、話を戻します。
Google +1 の影響は、グループユーザー（何らかの関係がある別ユーザー）が多いほど大きいといえます。
このあたりの概念をもってすると、TwitterやFacebookなど近年世界的な流行をみせているソーシャルメディアに代表されるものと近いのですが、いずれにしてもどのようにしてユーザーの輪を広げていくかというのが命題にあったのではないでしょうか
いいね！ボタン しかり、 つぶやく しかり。
ただ、パーソナライズされた情報ですので、検索結果に出てくる数字が大きく変動しているのを目にするのは幾分か先でしょう。
サイト内に設置できる「+1 ボタン」こちらは、検索結果に表示される「+1」とは少々様子が異なります。
サイト内に設置したものについては、「+1 ボタン」を押下した数だけ、累積的に数値が蓄積されていきます。
Facebookの「いいね！ボタン」に類似した仕組みです。
このボタンが与える影響は、サイト内を閲覧時に（所定のタグが記述されていれば）、Facebookやツイッターのように噴出しに現在のポイントが表示さます。
ようするに何人が「+1」したのかがわかるようになっています。
これ自体は、ソーシャルメディアの効果は直接的に関係しておりませんが、あった方がいい機能なのは間違いないですよね。
ワンアクションで波状的な広がりを見せるのがソーシャルの真骨頂ですが、TwitterとFacebookだけをとってみても、自分が望むユーザーをグループユーザーとして確保するのはたやすくありません。
ここで出てくるのが、「Google +」です。
まだ、こちらは試験段階で限られた会員ユーザーだけで試しているだけに過ぎないのですが、http://www.google.com/intl/ja/+/learnmore/ をみると自分が望むユーザーと関連性を持たせる可能性を多いに秘めたコンテンツが用意されています。
「Google +」はソーシャルメディアという資源を肉厚に利用する為のひとつの集合体だと個人的には捉えています。
どこまでも Googleの独壇場になりそうですが（笑）、Google + に一般企業がサービスを提供できる仕組みが出来れば相当面白い事になりそうです。
ここへの一般企業の参入は、これまでのパターンに倣って広告掲載になるのが妥当といったところでしょうか。あくまで個人的な見解ですが……
いずれにしても、専門家でない限りますます太刀打ちできない状況が生まれてきそうです。
お困りの際は、フリーセルまでご一報お待ちしております。
では、本日はこれにて
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
今月はTwitterのハッシュタグの活用について綴ってまいります。
＜ハッシュタグとは＞
”本来、ハッシュタグは、投稿したその内容がどの特定のトピックに関するのかを書き、同トピックの投稿をまとめて見ることができるようにするものである（Wikipediaに関する投稿は「#wikipedia」など）。”
[ 参照元 ]
http://ja.wikipedia.org/wiki/Twitter
とあります。
具体的には、つぶやきの後ろに半角スペースを1個入れてから、半角英数字で「#hoge」と記載します。
例） hogeとは、「意味がない」という意味を持つ単語です。メタ構文変数といいます。 #hoge
のような使い方です。
実際は、文中でも「#hoge」が独立していれば検索にHITします。
＜ハッシュタグの使い方＞
Twitterオフィシャルなら画面上の検索窓に「#hoge」と入力すると、関連したツイット一覧が表示されます。
ツイット内のハッシュタグをクリックする事でもタイムライン上に関連ツイットの一覧を表示できます。
また、ハッシュタグは任意で記載できますので、どのようなハッシュタグの付与も可能です。
＜ハッシュタグをつける意味＞
1 検索すればフォローしていない人のツイットを表示できる
2 ハッシュタグをつけると、自分のツイットが拡散しやすい
上記から、自身のツイットを拡散させる必要がなければ、ハッシュタグをつける必要がありますし、その逆もまたしかりです。
では、いったいどういう状況下でハッシュタグをつける必要があるのかが疑問となるのですが、コミュニティとして機能させる必要がある場合がそれに該当するでしょう。
例えば、USTREAMの右側などにツイッターのタイムラインが表示されているのをご覧になった事はございますでしょうか
フォロー・フォロワーに関係なく動画に関連したツイットだけをタイムラインに表示してくれています。
1 運営側のプラットフォーム準備の容易化
2 参加者の環境を整える必要がない（個々人のツイッターアカウントで参加）
3 個々人が持つアカウントのタイムラインには、自身がつぶやいたツイットが表示されるため、運営側プラットフォーム以外でも拡散効果が見込める
USTREAMではおなじみの機能ですが、コミュニティというのが一つのキーワードでキャンペーンなどでもハッシュタグがうまく利用されているのを見かけます。
「1/1Webセミナー 渋谷！ #freesale」とつぶやいた方、抽選で100名様に紀井のサイン入り書籍をプレゼント！
といような具合です。（※このようなセミナーは実施しておりませんし、私は書籍も発刊しておりません。念のため）
まとめてしまうと、
ユーザー毎に表示されるタイムラインは縦串、
ハッシュタグ利用のタイムラインは横串を刺すといったイメージです。
＜ハッシュタグのタイムラインを実装したい＞
どのようなものに実装したいかによりますが、USTREAMであれば管理画面からチェックボックスにチェック入れるだけで実装できますし、自前のサイトに実装したい場合などは、Twitterの公式ウィジェットでコードの取得が可能です。
運営側としては、非常にありがたい機能です。
http://twitter.com/about/resources/widgets
今日の話の内容を実現するには「検索ウィジェット」でコード生成すれば利用が可能のようです。
また、ハッシュタグ付きでのツイート数などを簡単に検索・分析できる無料サービスもあり使い手側のアイデア次第ではありますが、低予算でも大きな効果を期待できそうです。
では、本日はこれにて
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
まずは、3月11日に発生した東日本大震災により被害を受けられた皆様に、心よりお見舞い申し上げます。
また、震災の影響を受けて不安で慌ただしい毎日をお過ごしの中、弊社コラムをご覧いただき誠にありがとうございます。
さて、改めまして本日のコラムをおおくりいたいます。
メディアミックスとは、複数のメディアを通じて展開するビジネスモデルの事を指します。
複数のメディアとは、TV、ラジオ、Web（Webサイトやえメール）、紙（チラシやハガキ）などの事だといわれています。
メディアミックスという既出キーワードの頭にWebをつけた理由。
ここ数年でWeb内で活性化しており、先般発生した東日本大震災ではご活用された方も多かったのではないでしょうか
そうです、そのTwitterやFacebookに代表されるソーシャルメディアが活性化した事をきっかけに連想した言葉です。
通常、Webサイトの役割として、ブランド力強化、売上UP、業界活性化等々があると思います。
Webサイトが持つテーマはまちまちですが、利益を求める企業であればゴールは基本的には同じはずです。
競合に勝ち、No1になる事。
ですが戦う場所はWeb上である以上、条件は同じです。
勝ちを左右する要素はいくつかありますが、極論ユーザーの流入数とコンバージョン率が主なところでしょうか。
コンバージョン数を高める為には、母数となるユーザーの流入数増加が必要ですし、ユーザーの流入数を高める為には検索エンジンでの上位表示が必要です。
検索エンジンで上位表示させる為には、地道なSEO改善が必要ですが、知恵も時間も必要です。
お金がある場合、リスティング広告を打てばいいでしょう。
ただし、キーワード選定が難しく費用対効果を出す為にはプロに任せる必要があります。
人脈はあるんだけど、お金も時間もな～とおっしゃる方。
そんな方には、FacebookやTeitterのご活用をオススメします。
これらのソーシャルメディアは利用料はかかりませんが、多くのフォロワーやファンがいれば、それだけで大きな宣伝になる可能性が高いです。
特に、Facebookのファンは少なくとも自分に興味を持っている確立が高いです。
数が少なくとも興味を持っている層であれば、コンバージョン率は高くなるのではないでしょうか。
お伝えしたいのはこれからの時代、検索エンジンだけが戦いの場ではなくなったという事です。
ポータルサイトへの登録や、ソーシャルメディアの活用など、高いコンバージョン率を結果として出せる自分のUSPがいきるメディアで競合と勝負する時代だと感じています。
例えば、スマートフォンのネイティブアプリ開発には意味があるかどうか懐疑的になる方もいらっしゃる事でしょう。
ネイティブアプリをダウンロードできるサイトに自社のアプリが掲載され、上位をキープさせ続けられるとしたら、その効果はすごいのではないでしょうか
業態や状況によって違うでしょうし、それが常に最適解だとはいえませんが一つの選択肢としてはアリのはず。
Webメディアミックス時代だからこそ選択できる宣伝手法として
・Webサイトの公開
・Eメールマガジン
・検索エンジン上位表示（SEO）
・検索エンジン広告枠（リスティング）
・ポータルサイトへの登録
・ソーシャルメディア戦略（Twitter、Facebookなど）
・ネイティブアプリの公開サイトへの掲載
・モバイルサイトの公開
技術の発展で選択できる手段は多くなりました。
その手段を深堀すればきっと自社に適した戦略があるはずです。
いずれにしても、どの手段を講じる事が最もベストなのか今度はその選択を行うのが難しいですねｗ
ご検討の際は、弊社までお問い合わせください。
お問い合わせお待ちしております。
では本日はこれにて
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
最近、スマートフォン対応というキーワードを目にする機会が増えてきました。
スマートフォン対応とは、一体どういう対応なのか？
本日は、スマートフォン対応するため検討内容などをお伝えしていこうと思います。
スマートフォン対応するにあたり、おさえておくべき事項として
1 コストを抑えて、簡素なサイトにする
2 コストをかけて、リッチなサイトにする
3 ガラパゴス携帯対応をするか
を決めておく必要があります。
ターゲットユーザによって、3の対応までするかどうかの判断が必要です。
ここでお伝えしたいのが、ガラパゴス携帯対応とスマートフォン対応とは、開発面において全くの別物という事です。
PC向けサイトと、ガラパゴス携帯向けサイトが全くの別物だというのは、言うまでもありませんが、実はスマートフォン対応というのもさらに別物だったりします。
この違いに気がついていないと、思わぬ開発費用に驚いてしまう事になるでしょう。
これは、開発面において、それぞれ違う方法をとらざるを得ない理由に起因しています。
詳しくは、このコラムの最後の方でお伝えするとして、まずは、スマートフォン対応検討が必要か否かについては下記を参考にしてもいいかもしれません。
1 ターゲットユーザーが大学生以上
2 自社サイトのブランディング強化をしたい
3 ECサイトを運営している
4 ガラパゴス携帯対応しかしていない
現在、スマートフォンユーザーは、携帯電話ユーザ比率を見ると10％を超えており、まもなく20％に達するのではないかと思われます。
約20％ともなると、無視できない数値です。
ガラパゴス携帯にのみ対応させている場合、スマートフォンで確認すると殆どの場合、PC向けサイトが表示されます。
PCとほぼ同じように利用出来る為、致命的な問題はありませんが使いづらいのは間違いありません。
スマートフォンの画面サイズ（解像度）は、デスクトップPCのおおよそ1/3～1/4ですので、イチイチ拡大しつつ見る手間があります。
ブログ系であれば、そのままでいいと個人的に思います。見れなくはないので
ところが、EC系サイト、特化系サイト（サテライトサイト）、ブランドイメージを大切にするサイトでは少々まずいでしょう
何せ、通信回線はガラパゴス携帯と大差ないのですから
つまり、ガラパゴス携帯と同じ回線速度なのに、PC向けサイトを見ていることになります。
利用者としては、とてもイライラしてしまいますね。
離脱する原因のひとつです。
ですので、ガラパゴス携帯は簡素なテキストメインのWebページとなっているわけです。
過去と比較すれば通信速度は上がっていますが、画像が多数使われているサイトには向きません。
そこで出てくるのが、Webの最新技術であるHTML5とCSS3です。
PC向けのブラウザでも、部分対応しかしていなかったり、レガシーなブラウザがまだまだ存在する為、PC向けサイトではまだまだ利用されていません。
W3Cが正式勧告していないことや、現時点で検索エンジンが正当に評価するかはまだわからない（将来的には評価してくれるはず）ためだと思われます。
スマートフォン自体が新しいハードなので初めから対応している事やレガシーブラウザがない為、利用が現実レベルで可能になっている事などから、この最新技術を利用する事で通信速度が光回線並みでなくても何とかできるといったものです。
ここまででスマートフォン対応が必要だと判断した場合、以下をご覧いただければと思います。
スマートフォンでは、基本的にPC向けサイトで表現できる事は大体出来るようになっています。
一部、FLASHが使えないなど制限はありますが、携帯電話と比較するとその表現手法は雲泥の差です。
スマートフォンではPC向けのサイトであっても難なく表現してしまうのですが、それでは小さすぎて扱いづらいというのが正直なところ
つまり、スマートフォンの画面サイズにあわせつつも、PCサイトと遜色のないユーザビリティをスマートフォンの規格に合わせて表現しなおさなければならないところに難しさがあります。
スマートフォンの規格として考えると
1 画面サイズが小さいので、情報デザイン設計に工夫が必要
2 大容量通信が出来ないので、容量に配慮が必要
3 FLASHの利用ができないキャリアがあるので、代替機能の考案が必要
4 HTML5が利用できるので、セマンティックな構造に出来る
5 CSS3が利用できるので、画像を多用しない構造に出来る
6 縦・横の判定があり、それに併せた構造を考える必要がある
7 マウスがない為、マウスアイコンが重なった時にボタンを光らせるような手法が使えない
続いて特性をみてみると
ハードウェア側のユーザビリティの良さがあるのである程度縦長でもストレスが少ない
ページ遷移時に待ち時間が発生するので、離脱を防ぐ仕掛けが必要
画面の拡大と縮小が、エンドユーザ側で即座に出来る
などが、思い浮かびます。
対応が難しいもののひとつとしてナビゲーションの設計があります。
PC向けサイトと違い画面サイズが小さい為、左側にズラッと並べる事は避ける必要があります。
となると画面の下のほうに、ボタンを並べる事になるのですが、うまくデザインしないとサイト内で迷子になる確率が非常に高くなります。
ガラパゴス携帯向けサイト、PC向けサイトとは違った構造です。
通信速度においても、光回線と同じようには行かない為、写真素材などの容量を抑える事や、Ajaxを利用したページの先読みを行なったりなど、開発面において高度な技術・工夫を用います。
これら制限をクリアする難しさがあるのですが、それらをサポートしてくれるのが、最新技術のHTML5とCSS3です。
もちろん、ガラパゴス携帯向けサイトと全く同じでいい場合は、その限りではありませんが……
PC向けサイトが、MovableTypeやWordPressなどに代表されるようなCMSで構築されている場合で、デザインはそれなりでいい場合は、手間をかけずに導入する事が可能です。
テンプレートに従って、コンテンツのデータを流し込むような仕組みをもったプラグインはありますし、過去、このコラムで少しふれたjQTouchなどを利用すれば、比較的短時間で導入が可能です。
上記からスマートフォン対応はもうひとつサイトを構築するくらい手間がかかってしまう事がわかります。
近い将来、市場を占める割合が確実に増えるハードウェアに今から投資しておくのは、有効だと思います。
他、影響の裾野を広げて考えてみると、TwitterやFacebookに代表されるソーシャルメディアとの複合的なマーケティングを考えるのであれば尚更でしょう。
あとがき
個人的には、スマートフォンの通信速度をPocketWifiと同等な状態を標準実装として欲しいと思っています。
そうすれば、大容量コンテンツも容易に利用できますし、ワンセグを使わなくてもテレビCMなみの広告をもっとだせるのにと……
いや、開発側は大変なんですけど（笑）
子供は遊びの天才だといいますが、大人は仕事の天才でありたいなと
では、本日はこれにて
この記事に関連するテーマ
この11月1日に歯科専門Webコンサルティングサイトを新たに公開いたしました。
■2000サイト超の制作実績やノウハウでご提案
2000サイトを越える制作実績から、ただサイトを作るだけではなく、リスティング広告出向のサポートをさせていただく事や、専門のライターがコンテンツを作る事で効果的なページを実現しています。
■自費率UPからスタッフ教育まで、幅広くフォローする歯科関連セミナー
自費率UPセミナーやスタッフ教育セミナーについては、先生が技術を追い求める時間を増やす為にWeb戦略について共有させていただくセミナーに参加されるケースや、運用・サポートを専門に行なっている部門を有する弊社板谷が開催しているセミナーにスタッフ様が参加されるケースなどがあり、有効にご利用いただけております。
■1500医院の取材実績と全国約68,000軒掲載のポータル歯科タウン
過去、キャンペーンを行なう毎に寄せられるご意見・ご要望から、現在は更に利便性を高める為、全国約68,000軒の歯科医院掲載や、モバイルページのリニューアルに至っています。
これは、歯科タウンが利用者様のご要望に応える事で、ポータルとしての利用価値を高めるだけではなく、地域に根差した歯科医院様にも貢献できる媒体にしていこうという姿勢から実施しております。
また、会員医院様におかれましては、専用のページを設けてあり、FLASHによる院内写真の自動スライドが標準実装されていたり、ご希望の先生にはインタビュー動画の掲載などご提案させていただいております。
全国のユーザーにリーチしつつも、医院のUSPを専用ページ内で掲載し医院ブランティングにも一役買っています。
■専門スタッフによる歯科医院のWeb戦略を知り尽くしたご提案
ディレクション・ライティング・運用・コンサルテーション、それぞれの専門家が勝ち抜くためのホームページ作りや運用をご提案いたします。
上記は代表的な内容ですが、ホームページを作るだけではなく、そのホームページを効率よく運用する為のご提案から結果を出すためのサポート、ポータルへの掲載、果てはセミナーでの勉強会まで多角度からアプローチを試みています。
まずは、歯科専門Webコンサルティングサイトをご覧ください！
興味をもっていただけましたら、歯科専門Webコンサルティングサイト内からお問い合わせください！
先生のお時間を大切にしつつも、よりよいWeb戦略で効果的なWeb戦略をご提案いたします。
終始宣伝に徹してしまいましたが、せっかくのコラムですので、よもやま話をさせていただければと思います。
もう少しお付き合いいただければ幸いです。
今回、このサイトを作り上げる時に、実は一度ボツになった経緯があります。
それは、弊社が現在の歯科界に向けてご提案している内容や、今後の動向など事業全体における理解の深さが足りなかった為だったのですが、このプロジェクトに関わるメンバー間で理解の深さ・状況把握度を同じレベルに引き上げ、イメージにでき、行動にまで起こせるようになる為に幾度となく会議を重ねました。
当社では、よく「全体感」という言葉を用いるのですが、この全体感がなければお客様に本当にご満足していただけるようなサービスを提供する事は出来ないといえます。
だからこそ、一旦ボツになったわけです。
ただ、ホームページを作るのでなく、歯科専門Webコンサルティングサイトをご利用になる新規開業の方々、開業医の方々がご覧になった時に弊社がご提案差し上げているサービスを的確に把握できて、もっと聞いてみたい、もっと知ってみたい、利用してみたいと思っていただけるようにと徹底的にこだわりました。
また、歯科専門という看板を背負うに相応しい内容にすべく、ピースとして存在していた情報を分析、仕分けして、体系立てたサイトに仕上げています。
今回のプロジェクトメンバーは今まで弊社内の自社媒体に関わってきたメンバーとは違い、実は現場でバリバリ活躍している、実際に歯科医院の先生にご提案を差し上げている担当者です。
粘り強く取り組み、一度はボツになったもののただでは起き上がらないメンバーばかりで、最後には広い全体感も身につけています。
お客様に対する強い感謝の念を持って取り組んでくれているからこそ出てくる案も出てきたのですが、ノウハウをこのサイトで語りつくしてしまったら、実際にご提案する際に話す事がなくなよーという事でコンサルタントの担当からストップが入る程でした。
このあたりは、まだまだ全体感がないのかもしれませんね（笑）
しかし、全てはお客様の為という気持ちから生まれた行動でした。
新規開業の方々、開業医の方々のご期待に沿えるよう弊社専門メンバー一同邁進してまいりますので、よろしくお願い申し上げます。
それでは、本日はこの辺で
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
今月も技術よりな話で恐縮です。
皆様のWeb戦略にお役に立てるよう技術的な情報を公開できるよう意識しています。
という事で、普段はあまり意識しないであろうサーバーの話を少しお伝えしたいと思います。
多くのお客様のWebサイトに携わっていると様々なサーバーに出会います。
弊社がお客様にご提供差し上げていますサーバだけでなく、お客様側でご契約していらっしゃる場合や、時にはお客様自身の手で構築されたサーバーもあります。
Webサイトなどのデータをサーバーにアップロードをすると稀に時間がずれてしまう場合があります。
通常は、サーバーは定期的に自動更新を行い時間調整をしているはずです……
というのは、FTPツールなどで、確認できるファイルの更新日時は現地時間を取得している事が多い為、サーバーが日本国内にない場合、日本標準時を使っていない場合にずれが発生すると考えられます。
大規模システムを構築している場合、時間補正が必要になるはずで、設置されている国との時差を取るという方法も可能ですが、提供会社が変わるたびにシステムの修正も大変です。
そこで、協定世界時（UTC：Universal Time, Coordinated）を使います。
この協定世界時に、＋9時間すると日本標準時（JST：Japan Standard Time）となるので、サーバーがどの国に設置されていても安心です。
一昔前は、グリニッジ標準時（GMT：Greenwich Mean Time）を使っている時期もありましたが、より正確な時間にする為に原子時計を用いた協定世界時になっています。
説明が長くなりそうですので、正確ではありませんが、簡単に説明すると、協定世界時は原子の規則的な動きから計測している時間で、グリニッジ標準時が太陽と地球の相対的な位置から計測している時間。
前述した日本標準時は、日本国内においては、電波時計やNHKの時報などと同じ時刻だそうです。
上記は直接Webサイトの質を高める為に役立つ情報ではないのですが、時間が間違っているとECサイトやお問い合わせ時のタイムスタンプが狂ってくるのでサービス品質という観点では正しい対処が必要です。
SEOでも評価指標の一部だといわれている応答時間（Respose Time）はサーバーによっても変わってきます。
検索評価指標として、
「待ち時間なくWebサイトを利用出来るようになっている事は、価値だ」
といっています。
ところが、特別な場所、美味しい料理、ホスピタリティ溢れるスタッフ。
そんなサービスを提供する飲食店やホテルなどは、予約で一か月待っても利用したいと思う人もいるでしょう。
ターゲットに応じて、適切な対処、対応をしていくことがWebサイトにおいても大事な事です。
何をやりたいかによって、表示速度、デザイン性、機能性、Rank……何に重点を置くのかを決定し、方針を決める事
これが出来てから、サーバーの選定を行うべきかと思います。
では、本日はこの辺で
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
7月のコラムにiPhone・iPadアプリについて少し触れましたが、アプリ開発する事に多からず違和感を感じていました。
iPhoneやiPadでしか使えないアプリを開発してしまったら、他のスマートフォンはどうなるでしょうか
他のスマートフォンに対応したアプリを別途開発するか、もしくは切り捨てるしかないでしょう。
利用者をターゲッティングするのは当然なのですが、開発する側としてはなるべく多くのユーザーの手に取ってほしいという気持ちもあります。
利用範囲を狭める事で開発コストは抑えられ開発自体も楽ですが、これでは汎用的とは言えません。
逆に汎用的に開発すると、細かな部分で思い通りの機能を利用する事ができず開発コストがかさみます。
このバランスを考え、どこに重きを置くかが、利用者に満足していただけるか否かのポイントだと思います。
ただ、汎用的にするのであれば、通常のWebサイトの画面サイズ、各種パーツをスマートフォン向けに最適化したデザインをすればいいのですが、スマートフォン特有のフリップ・2本指タップ・回転などを駆使した構造にしようとおもうと敷居はあがります。
それぞれのスマートフォン用の開発言語では専用の関数が用意されているので、当然のことながら開発はスムーズに進むでしょう。
事業として取り組む上で言語を習得するのはやぶさかではありませんが、スポット開発で言語習得するのは割に合わないというのも事実。
しかし、慣れ親しんだWebアプリで実現するためには、それなりに遠回りする必要があります。
近道する方法もあります。
有名なプラグインであるSenchaTouchやjQTouchを利用する事で、その敷居はグッと下がります。
今回、サンプルのサンプル作りにiui.jsを使っていた手前、jQTouchの方が抵抗が少なかったので、サンプルをこちらで作成する事にしました。
一通り使ってみて、開発のポイントは……
1 全てのコンテンツは1ファイルにまとめる（実質、index.htmlのみ）
2 1から、ファイル分割しなくていいサイト設計にする必要がある。
3 もともと用意されているthamesのCSSは少しカスタムした方が使いやすい
4 ボタン等で用意されている素材は、色違いを追加しておいた方がよい
こんなところでしょうか
1と2が重要です。必須といってもいいでしょう。
通信速度において、3G回線の場合だとファイルをまたがる処理に時間を要します。
「ほんの数秒」
と侮ってはいけません。
以外とイライラするものです。
全て1ファイルで完結させられれば、初期読み込み後は、非常に快適な環境で利用が可能で、その読み込みもノンストレスにするための仕掛けは用意されていました。
画像が多い場合は、プリロード（事前読み込み）を行い、裏側でロードさせつつページ閲覧が可能です。
もう少し、気を利かすのであれば初めの読み込み時にロードアニメーションを作りこんでおけばいいかもしれません。
demoソースも豊富に用意されているので、新しいことはほとんど覚えなくていいのでiPhone用のサイト作りを考えている方はご参考にいただければ幸いです。
全体のソースが完成したところで、気が付くのがどのセクションも同じパターンだということです。
これってつまり、やろうと思えばページ構築自体をシステム化できるということです。
ページ名・ID・概要・画像とサイトマップを登録できる管理画面を用意すれば立派なCMSです（ざっくりすぎますが……）
世の中でこれで費用をいただけいる企業様のケースですと、PC用のサイトを自動でスマートフォン用に変換するツールとか、MTだとモバイル用に自動変換するプラグインもあります。
このように新しい技術を考え出すよりも、既出の技術を組み合わせて、新しい価値を生み出す方がよっぽど生産的だと思います。
技術者としてどうなのそれ？と指摘を受けそうですが、個人的には定義の問題だと思っています。組み合わすのも知識・センス・経験が必要です。
著作権侵害は問題外ですが、今までも技術を公開してきたことで、インターネットは高速で進化を遂げてきていると思います。
インターネットの世界では、どんなハードもソフトも、数年経てばレガシーだとされる世界。
だからこそ、表面的な技術に対して対価を得るのではなく、技術を価値に変え結果を出す事で対価を得るのが技術者の命題なんだと個人的には思います。
とはいいつつも、技術力ってそれだけでも価値なんですけどね（笑）
では、今日はこの辺で
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
前回お伝えした後で、さらに詳しく調べていった際にもう少し精度を上げれるという事に気がつきましたので、もう一度お伝えしようと思います。
前回、UTF-8で記述されたプログラムでShift_JISでコンバートする際に、旧字体を「髙→高」に置換処理するとお伝えしていました。
Web上で取ったログが文字化けていたのでそのような対応をとっていたのですが、ローカルでShift_JISにエンコードされたCSVファイルに「髙」と記載しても文字化けませんでした。
ここから、プログラムのコンバート処理の問題で上手く変換出来なかった為に、「高」にしなければならないような状況が生まれていたことに気がつきました。
この部分に着目して、文字化け対象文字にあたるIBM拡張文字300字強のリストをライブラリに頼らず自前のビットコードリストで対応させました。
例えば、「髙」は、UTF-8では、「100101111101010110011001」ですが、Shift_JISでは「1101111100111111」となります。
あらかじめShift_JISに対応したビットコードリストを用意しておき、UTF-8で該当の文字にマッチングした際にShift_JISビットコードに書き換え、文章全体をUTF-8からShift_JISへコンバート後に先ほどビットコード化した文字列を通常の文字に戻すと文字化けはなく綺麗に表示されます。
今回文字化け対象文字としたのは、①～⑨というような機種依存文字以外では、IBM拡張文字115区～119区に対応しました。
全部で300文字以上あるのですが、これらを配列として読み込み、順にunpackを行い、リスト作成後に対応文字にあてがうような流れです。
※以下、Shift_JISのビットコードリスト作った時のやっつけソース（笑）
# Shift_JISの全角バイト数
$enc_bite = 2;
# Shift_JISの全角ビット数
$bits = $enc_bite * 8;
# 対象文字の代入
$word = "～－纊\褜鍈銈蓜俉炻昱棈鋹曻……（省略）";
# ビット化
@str = unpack("b*", $word);
# カウンタの初期化
$x = 0;
$y = 0;
# 機種依存文字が400個くらいあるので繰り返す（代入した文字が区切りられていない為、ビット数で区切る）
for($i=0;$i<400;$i++){
# 表示用：機種依存文字郡を一文字ずつに分解
$kisyumoji = substr($word,$y,$enc_bite);
# 表示用：アンパック後の数値を所定の桁毎に切り出す
$moji = substr($str[0],$x,$bits);
# 確認用：packで戻した時の文字
$mototext = pack("b*", $moji);
# 行数
$j = $i+1;
# 表示
print "$kisyumoji $moji $mototext<br>\n";
# 所定の桁数をプラス
$x += $bits;
$y += $enc_bite;
}
HTML表示部分は端折りましたが、大まかにはこのような処理でリストを作り出しました。
このリストを元に本番のプログラムで文字に戻すわけです。
ところが、メール本文で取り扱っているエンコードがiso-2022-jpでこちらはメール送信モジュール自体に文字そのものが存在しない為、文字化けは免れません。
これに関しては前回記載（http://www.web-consultants.jp/column/kii/2010/08/post-31.html）した方法で置換処理を施す必要があります。
Webメールではどうしても文字化けが発生してしまいますので、Web上でログを保存する事で完全な内容を補完することができます。
とまぁ、プログラム内部では大袈裟な処理をしていますが、そもそもIBM拡張文字に関しては出現率も低いので、出現率が高い文字のみ対応するのでも大きな問題はないと思います。
では、今日はこの辺で
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
先日、弊社の制作物ではないWeb上でコンマ区切り（いわゆるCSV）データを蓄積するメール送信プログラムをテストする事があり、蓄積されたデータを確認しようとエクセルで開くとファイル内全てで文字化けが発生していました。
文字エンコードをUTF-8でセットしたファイルをエクセルがShift_JISで読み込んでしまった為に発生した事象でした。
この後、UTF-8を認識出来るテキストエディターで確認したところ正常に表示されたのですが、このように特殊なテキストエディターで確認する事でしか文字化けを回避できないのは、ローカルPCでの作業を想定するようなケースだと基本NGになります。
今回、CSVファイルをエクセルで活用するという事が条件だったため、最終的にはファイル自体をShift_JISにコンバートしました。
この時に気をつけないといけない事があって、UTF-8からShift_JISへの変換の場合、コード体系上の問題がありどうしても表示できない文字が出てきます。
それが、機種依存文字と呼ばれるものなのですが、例えば「髙」や「﨑」などが代表的な漢字です。
この漢字をお名前に持つ方々は、PCで携帯電話宛にメールを送った際に自分の名前が「??」（ハテナ）となったご経験が少なからずあるかと思います。
扱う範囲として、PCだけはなく携帯電話までを考えると元々旧字体がライブラリにないハードウェアも存在する中での折衷案は何処にあるかを考えねばなりません。
比較的、多く使われる旧字体に関しては、「髙⇒高」や「﨑⇒崎」のようにプログラム上の置換処理で対応するケースが一般的です。
これらの漢字をお名前に持つ方々は、特にメールのやりとりで文字化けに遭遇しているので、意識して自ら文字化けを起こさない文字に補正をしていらっしゃるのではないでしょうか。
・PC間でのメール（特にWebメール）
・PCから携帯電話へのメール
・Webを介したデータやり取りにおけるローカルPCの取扱い
・古いCMSツール（EUCにしか対応していないケース）
等々、他にもあるかもしれません。
最近作ったものはほとんど問題ありませんが、5年以上前に構築したようなシステムの場合は文字化けに注意が必要です。
今後、ハードウェアの発展と共に各種ライブラリも強化されていって不便なく使えるようになると思いますが、いつの時代もこの機種依存文字や文字化けに技術者は頭をひねる必要がありそうです。
それでは、本日はこの辺で
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
先日、iPhone・iPadアプリの開発有無は別として、どのような手順で行なうべきかを調べてみましたので備忘録という意味でもここに綴っておこうかと思います。
調べて気がついたのですが、アプリ公開に至るまでに立ちはだかる壁は意外に多いです。
- まず、開発環境ですが以下が必要になります。
１ intel Mac（Leopard）とOS X 10.5.3以降
２ Apple Developerへの登録
３ iPhoneSDKのインストール
４ iPhone、iPadなどの実機（エミュレータがあるので、テストは可能です。）
基本的には、Macで環境を整える必要があり、且つ、Macの中でも制限があります。
ハードウェアをただ揃えても、開発できない場合がある為、ハードウェア購入には注意が必要です。
私などは、Winユーザーですので個人的に環境揃えようとすると、Macの購入からスタートするわけで、場合によってはMacの使い方からスタートなどという事態に発展しそうです。（でも個人的にはやりたいんですよね）
つづいて、開発用のツール（無料）をインストールしたいところなのですが、こちらはApple Developerへの登録が必要です。
最終的に実機でのテストや公開をしない場合（だとするとアプリを開発する意味はほぼありませんが）、無料登録でOKです。
ところが、公開まで行いたい場合は、有料登録になります。10,800円／年の会費です（2010年7月6日現在）。
一般的に、プログラム開発用アプリケーションを購入すると100,000円～200,000円くらいはかかるので、年会費は納得出来る範囲です。
さらに、有償のiPhone・iPadアプリを公開するに至った場合、費用回収もapp store側で処理してくれるため、販売まで視野に入れている場合の納得度は高いかもしれません。
さて、上記でとうとう登録まで出来た事になるので、今度はiPhoneSDKのインストールです。
ダウンロードしてインストールするだけですので、本件への取り組みを行なおうとするくらいの気力のある方であれば技術的には問題はないでしょう。
さて、最後の難関です。
開発用言語がObjective-Cです。
C言語を継承しているため、C言語を知っている必要があります。
C言語なんて、十数年前に学校で習ったきり触っていませんから、はっきりいって自信はありません。
幸いWindows環境でもObjective-Cの環境がそろえられるようですので、そちらで少し開発を進めてからiPhoneアプリ開発に着手するかを検討してもいいでしょう。
とまぁ、こんな調子でアプリの開発にいくつかの解決すべき課題があるのはご理解いただけたかと思います。
ただ、私がこの調査を通して感じたのは、iPhoneアプリ開発の制限と依存性です。
確かに、iPhoneユーザーが増えており、世の中的には、アプリ開発の需要が高まっているとはいえ、iPhone以外のスマートフォンも多数発売されています。
iPhone・iPadだけに特化したものではなく、スマートフォンに対応したシステムを構築する事がユーザーを選ばない最良の方法かと思います。
PerlやPHPとは違い、サーバーを介さなくてもiPhoneやiPad実機にデータ保存出来るという部分は魅力的ですが……
個人的には、iPhoneやiPadに縛ってユーザーを囲うのは、開発者並びに利用者を制限してしまいますし勿体無いと思っています。
だって、せっかく丹精こめてつくったシステムの恩恵を受けれないユーザーがいるなんて考えると、本当に市場に価値を生み出せているか疑問が残ります。
Perl言語開発者のラリーウォール氏曰く、「There's more than one way to do it.」（やり方は何通りもある）
を胸にお客様によいサービスを提供していきたいですね。
それでは、本日はこの辺で
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
2010年5月24日（月）に、弊社が運営管理する歯科タウンが全面リニューアルしました。（プレスリリースはこちら）
- 今回のリニューアルでの変更点で
掲載医院数の増加 約1,400軒⇒約68,000軒
検索方法の多様化
読み物系のコンテンツを新設
が大きな部分でしょうか
8年前の公開当初から、歯科タウンは限られた会員医院様だけで構成していました。
近年、何度かキャンペーンをさせていただいているのですが、その際に応募者の方にお願いしているアンケートの結果によれば、「歯科タウンで検索できない医院がある」等のご指摘をいただいておりました。
当時は、限られた会員医院様の情報に価値があったとされていたのが、時代の流れと共にとにかく情報量が重要だというような価値観に変わってきたのだと思われます。
今から8年前ですと2002年ですから、光回線のインフラが浸透しだした時期だったように覚えています。
ADSLから光への乗り換えであったり、インターネットというものがより近い存在になったという印象があります。
「わからない事を調べる」や「自分の情報サイトを発信する」という関わり方から、コミュニティを作ったり、最近だと、Twitterで「つぶやく」という事に、インターネットを利用するくらいですから、情報の収集量や手法についてもニーズが変化しています。
大手検索ポータルのGoogleやYahoo!でも、検索順位表示のアルゴリズムがすごい勢いで変化しているのは、そのためでしょう。
やはり、時代の流れと共に変わってくるようです。
話を戻しますが、今回のリニューアルで掲載医院数が68,000軒にしたのは、歯科タウン利用者様がより質の高い情報を得れるように対応したわけです。
検索機能があるのに、検索する母数が少ないというのは、それだけで利用価値が無いものになってしまいます。
とはいいつつも、68,000軒の歯科医院様全てが会員医院様というわけではありません。
会員医院様は、現在約1,400軒あり、公開させていただいている情報も、患者様が情報収集しやすいようにと詳細に、且つまとめて。
つまりは、情報設計を行なった上で掲載しております。
医院トップでは、FLASHで医院内案内の写真を自動でプレビューしていたり、動画で先生から診療方針などを語っていただいていたりと、利用者にわかりやすいよう、よりリッチに作りこんでいます。
小学生くらいの時は、歯医者が怖いと思っていたのですが、歯科タウンの会員医院様を一軒ずつ拝見させていただいているうちに、無痛治療や審美歯科、インプラントなど、もはや昔に持っていたイメージはありません。
今の歯科医院は、とてつもなくハイレベルなのです。
そして、事前に気になった歯科医院の診療方針も確認できるわけですから、安心して通院できる歯科医院を見つけることがきっと出来ると思います。
今期は、歯科タウンの利用価値が高まるよう様々な取り組みを行なっていきますので、ぜひ、歯科タウンをご利用いただきたく思います！
まだ見ぬ未来の医院様には、ぜひ歯科タウンに興味を持っていただきたく思います。
歯科タウン掲載ご希望の医院様向けのお問い合わせフォーム
お問い合わせ種別を「掲載に関するお問い合わせ」にしていただきお問い合わせいただけましたら幸いでございます。
それでは、本日はこの辺で
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
今回は、ドメインについて少し書こうかと思います。
ドメイン名は、インターネット上の表札のような役割を果たしています。
例えば、www.web-consultans.jp がそうですね。
メールを送る場合は、hogehoge@web-consultants.jp（※このメールアドレスは実在しません。）となり、それぞれにドメイン名が記述されています。
しかし、ドメイン名とは、広義の呼び方で、厳密には詳細に名前がつけられています。
大きくは、分野別トップレベルドメイン：Generic Top Lebel Domain(以下、gTLD)と国別トップレベルドメイン：Countyr Code Top Lebel Domain（以下、ccTLD）とがあります。
gTLDから頻繁に目するのものを抜粋すると、com（商業組織）・net（ネットワーク）・org（非営利）・info（制限なし）などが有名でしょうか。
これらは、世界の誰もが登録する事が可能です。
ccTLDでは、jp（日本）・kr（韓国）・cn（中国）・us（アメリカ合衆国）等々があります。
日本では、属性型JPドメイン名として利用されています。
ac.jp（学校法人）・co.jp（株式会社・有限会社・他会社）・ne.jp（ネットワークサービス提供者）、go.jp（政府機関）、ed.jp（幼稚園・小・中・高学校等）、or.jp（医療法人等）
他にもまだあるのですが、ドメイン名を取得するといっても、TLDの種類も用途によって適切なものを選ぶ必要があります。
こうして適切な（運営組織にマッチした）ドメイン名が作られていくわけです。
また、TLDも近年では完全オリジナルで取得できるような取り組みもあり、まだ登録申請の受付はスタートしておりませんが、実現すれば、第2レベルドメイン名をどうするのか？といった問題は残りつつも、例えば、http://www.kii.web-sonsultants/といった（少々長いですが）URLが出来上がる日も来るでしょう。
メリットは、ブランド性が高いという事です。
今までは、TLDは運営組織にあわせてつけられていたので、2ndレベルドメイン（当サイトで言うところのweb-consutansの部分）を独自で取得する際に、TLDが「.jp」でしか取得していなければ、第三者に「.com」を取得されるなどして、独自性が薄れてしまいます。
ですので、ブランド力維持の為に場合によっては複数のTLDで取得するような事がありえるわけですが、TLDが独自になれば、それがなくなるということですね。
デメリットは、運営組織の種類の判別が出来なくなるという事ですが、特にブランドとも関係ありませんし、Webへのかかわりが深い人でもない限りTLDの種類からサイトの運営組織の種類を見るといった事もないでしょうからさほど影響はないのではないでしょうか。
非常に細かな部分ですが、「ブランド化」が戦略にある企業様にとっては多からず興味を持っていただけるのではないかと思います。
個人的には、今から施行が楽しみです。
それでは、本日はこの辺で
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
先日、お問い合わせや登録フォームで、利用者がイライラしたランキングという社内での共有をうけて、お問い合わせフォームの入力補助機能で、改めてEFOの在り方について話をしました。
EFOとは、Entry Form Optimization の略称で、入力フォームを最適にして、よりコンバージョン率を高める取り組みの事を指します。
WEBサイトの入力フォームに「イライラする！」7割 ～イライラの原因1位は「数字が全角・半角入力指定されていた」 らしいです。
確かに、決済が発生するサイトで、名前やメールアドレスは、最低限の情報として必要ですから問題ないのですが、住所、電話番号、商品番号、商品点数、色等、入力情報が多いサイトで入力後の確認画面で、必須項目が抜けているならまだしも、「半角数字にしてください」といったエラーで、前の画面に戻り、そして入力内容がクリアなんてされていたらとても辛いです。
よほど、その商品の必要性がない限り、その瞬間に、離脱してしまう可能も高くなるでしょう。
なるべく利用者ノイライラを軽減し、コンバージョン率を高める為に以下の点に気をつけています。
- 1 フリガナの自動入力
- 2 住所を郵便番号から自動入力
- 3 電話番号等の自動半角化
- 4 Enterキーで次の枠に進む
- 5 住所の中に記載されている数字・英字は全角に自動変換
- 6 日付指定がある場合は、当日日付が自動表示
- 7 ラジオボタン・チェックボックスのチェックは、テキスト部分のクリックでも判定あり
- 8 入力ガイダンスとして、灰色のサンプル文字を表示
- 9 必須漏れなどのエラー時は、確認画面に遷移させず、当該項目の入力枠を色を変えて誘導。
- 10 確認画面から前のページへ戻る際の値保持
3と5は最近実装させましたので、今後のご提供で標準実装されていきます。
この10項目の対応で、入力に関わる手間を大幅に軽減していますし、確認画面に遷移せずに訂正入力ができるようシームレスなつくりにしてあります。
入力の手間を軽減させる手法というのは、利用者視点で考えるといろいろ出てくるわけですが、もっと究極的には視覚障害がある利用者でも問題なく利用できるように、エラー時に音声ガイダンスを流す事も考えられます。
ただ、コンバージョン率を高める事だけではなく、ホスピタリティをもって作る事もこうしたEFOの取り組みの一環で重要になってきます。
コンバージョン率低下を防ぐためには
- 利用者に、迷わせない。
- 利用者に、間違い入力させない。
- 利用者を入力で疲れさせない。
- 利用者を余計な情報で迷子にさせない
を軸に考える事が大切です。
また、今回の更新では入力後のデータについても管理者様側で有効に使えるように、数字や英字は半角というのが通例ですが、住所の中にある番地やマンション名は全角に自動変換されるようにしてあります。
これは、送られてきた住所を宛名印刷ソフトで印字する際に半角ですと、縦書きで美しく中央ぞろえにならない事や、半角同士が横並びになる可能性への配慮。
利用者リストが出来上がった時に、見栄えが不揃いにならないように、そこにも配慮し、あえて全角を指定しています。
SEOの効果を高め、コンテンツとして正しいサイト構造を持ち、導線設計で利用者を誘導して最後にコンバージョンに繋がる美しいゴールを決めてこそ、結果を出すサイトだと思います。
興味をお持ちの方は、下記までお問い合わせお待ちしております。
それでは、本日はこの辺で
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
弊社では、Find Job！に掲載（6/8まで）などして現在Webの制作者の採用活動を行っているのですが、面接時に「XHTMLとCSSとを用いてコーディングをやっていました」という様に前職でのご経験にお話をいただく事が多いです。
その際に、何故XHTMLで記述する必要があるのかをお聞きするとまちまちな答えが返ってきます。
一般的に、XHTMLによる文書構造化とCSSによる装飾でWebサイトを構築するとSEOに効果的だと言われています。
では、何故、文書構造化と装飾に分ける必要があるのでしょうか？
それは、HTMLの歴史について、少し知っておくと分かり易いと思います。
元々コンピュータは数値演算につかわれていたのですが、それ以外の利用の理論を研究している人は幾人もいたようです。
その中で、テキストにリンクを貼ったり、画像を表示したりと考案したのが、ティム・バーナーズリー氏でした。
HTMLも歴史が移り変わる中で、HTML1.0からHTML5.0（予定）まで仕様が変更されてきています。
元々、文章をWeb上で公開させたいというところから始まっていたのですが、色を変えたいであるとか、大きくしたい、太文字にもしたいというニーズを取り入れてきている経緯があります。
他にも文字を動かしたいであるとか、点滅させたい等々、様々なニーズを取り入れるにつれて、ただ文章を公開するだけでなく、よりグラフィカルするという機能が追加されています。
この時点で、文章と装飾がごちゃまぜになってきています。
さて、近年では、WebサイトをYahoo！やGoogleなどのサーチエンジンで、検索上位にしたいというニーズがあり、だからこそ検索エンジンを最適化しようとするSEOという概念が存在しています。
サーチエンジンでの順位を決める為の要素というのはいくつもあるのですが、ではいったい誰がどのようにして決めているのか？
今現在は、クローラーと呼ばれるロボットがサイトを巡回して、情報を収集しているようです（昔は人海戦術だったらしいです）。
ロボットがWebサイトを見に来るというところで、では、一体何を見ているのか？非常に気になるところではあります。
実は、人間のように視覚から情報を得るわけでもなく、文章からその真意を理解できるわけでもありません。
ロボットはただ記述されたタグの意味と内容を照らし合わせているだけなのです。
つまり、視覚情報から得られる恩恵をロボットは得られません。
それどころか、不要な記述があれば理解に時間がかかったり、理解できなかったりする事があります。
だから、文書構造化と装飾とに分ける必要がでてくる訳です。
人間向けに装飾を効かせたグラフィカルなサイト。ロボット向けに理解しやすいように記述したソース。
題名になっているXHTMLが担う役目というのは、このロボット向けに理解しやすいように記述したソースな訳です。
ロボットというと、クローラーだけではなく、視覚にハンデをお持ちの方がWebブラウジングを楽しむ為に開発された音声ブラウザでも存在します。
音声ブラウザはタグの意味を理解し、見栄えではなく、文書として強調すべきところは男性の声で発音し、文書のタイトルやリンクでも区別してくれます。
だからこそ、文書と装飾を分ける必要があったんですね。
弊社では、そういった背景を理解し常に最適なものを提供できるよう日々取り組んでおります。
蛇足ですが、Find Job！掲載終了後も弊社採用情報ページでも引き続きアルバイトさんの募集を掛けさせていただいておりますので、興味をお持ちの方は、一緒にお仕事してみませんか？
今回のは2年くらい前に作った万年カレンダーです。
DEMO
万年カレンダー自体は何も珍しくありません。
PHPの場合は、pear::calendar等を利用すると簡単に作れるのですが、DEMOではPerlで作られたところがポイントです。
Perlは、文字列や正規表現には強かったりするのですが、トランザクション内で行う処理が細かに指定できる分、組み上げるのに非常に時間を要します。
カレンダー生成の流れ
1 当日日付を取得
2 当日日付から当月の月初日と月末日を算出
3 月初日からツェラーの公式を用いて曜日を算出
4 月初日の曜日からテーブルの位置を確定し、ループする処理を使って各枠内に日を当て込んでいく
というように、細かく算出を行う必要があり、かなり時間がかかってしまいます。
ツェラーの公式（年＋年／4?年／100＋年／400＋(13＊月＋8)／5＋日mod7）を知らなかったら、そのアルゴリズムを考えるのに苦労したことでしょう。
また、カレンダーの場合、気をつけるべき点は、うるう年計算です。
#1. 西暦が４で割り切れる年はうるう年
#2. かつ、西暦が１００で割り切れる年はうるう年では無い
#3. かつ、西暦が４００で割り切れる年はうるう年
これにより2月月末日が28か29で変わってきます。
2年くらい前だと、なかなかカレンダーって簡単に出来る仕組みがなくて苦労しましたが、現在はフリーソースなんかでもいくつか見受けられますし、便利な世の中になったなと思います。
本日はこれにて、失礼いたします。
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
今回は久々に技術的な紹介をいたします。
今までコラムに掲載してきたコンテンツは、コラム内に強引に挿入していた為
今回からは、別ファイルに作って掲載してまいります。
MovableTypeで複数ファイルのアップロードの手間にかなりの時間を要するので、既存のコンテンツは時間のある時にコツコツ直していきます。
で、今回ご紹介するのは、ガレージドアという機能です。
商店街のシャッターが上がるような動きで、中身が見えてくるというもの。
DEMO
Webサイト上での利用価値の大きさはさほどではありませんが、ナビ部分やバナー等、すこしギミックを使いたい時にいいかもしれません。
今期は頑張って技術紹介を毎月更新していきます！
本日はこれにて、失礼いたします。
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
最近見かけたコラムに、静止画を擬似的に立体化させる手法がありました。
ごく普通の静止画です。ところがこれに手を加えると・・・（※画面は部屋を明るくし、離れてご覧ください。）
なんだか目がチカチカしてきますが、右側辺りにある枝葉が浮き出て見えてくるかと思います。
実は写真を撮影する際に、右目から見た場合と左目から見た場合とで分けてあります。
二箇所から見る事で、距離感をつかむ人間と同様に、写真でもそれに近い現象が起こる事がわかります。
このケースの場合は足りない箇所である2枚の写真の「間」を脳内で補完している図式になります。
しかし、前述での画像ではWebサイトでの利用が大変厳しいです。
Webサイトでも利用できる品質で、且つ前述のような見せ方としては次のような例が使えそうです。 マウスカーソルを画像に乗せてみてください。
DEMO
上の画像加工は、手抜きして作りましたので、15分程度で完了させましたが、お仕事で加工を行う場合かなり工数がかかりそうです。
とは言いつつも、Webサイトトップに同様の仕組みを用いればかなりキャッチーになります。
例えば、バナーでも使えそうです。
ＦＬＡＳＨだけがリッチコンテンツだとは言い難い時代がやってきたようです。
では、本日はこれにて失礼いたします。
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
当社は、12月からW2C（日本Web協会）の正式会員となり、先日W2Cの森川理事長とお会いしました。
その際に、デザインについて改めて考える事となりました。
デザインは、単純に見栄えだけのことではなく、設計という意味も含まれるという事です。
バナーであれば、導線を作るというは当たり前なのですが、例えば、ナビゲーション一つにとっても「誰が使うのかを考える」という事です。
Webサイトを利用するのは、健常者だけではないというところで、見栄えの為にボタンを小さくしたりするのは良くない事であると。
例えば、ボタンの高さが30pxと10pxの場合、どちらが押しやすいか。
文字の入力も省略できた方が手に障害のある方にとっては、使いやすいというわけである。
他にも、画像として派手な効果をしようすると、画面上で何が起こったかわからずパニックになるらしいです。
いくらWeb標準といっても完全ではなく、どこまでホスピタイリティに溢れたサイトに仕上げられるかはやはり制作者にかかっているのだと、とても参考になったお打ち合わせでした。
では、本日はこれで失礼いたします。
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
今回は、昔からある技術 クッキーについて備忘録もかねて綴りたいと思います。
最近、社内向けのツールでフォームを設置したりする事があったのですが、ユーザビリティを考え久しく利用していなかったクッキーを用いる事にしました。
久しぶりに利用した為、かなり忘れている自分に驚愕。
クッキーの正式な名前はHTTP cookieといいます。Cookieなどと呼ばれたりもするのですが、ありきたりなセリフですが、「食べ物のクッキーではありません」のでお気をつけください。
クッキーの生い立ちは置いておくとして、クッキーの利用目的は、利用者の識別や接続状態の管理で、古くは掲示板やチャット等に用いられる事が多かったと記憶しています。
他にも買い物カートのような仕組みにも組み込まれているようです。
クッキーは、利用者のＰＣ端末の中にデータを格納仕組みになっているのですが、利用方法も2通りあります。
1 指定の情報をメモリに保存（次回アクセス時も利用可能）。
2 接続状態だけを仮想メモリに保存（ブラウザを閉じる事で情報は削除されます）。セッション管理といいます。
プログラムの作りについては、続きをどうぞ・・・
利用者の名前とメールアドレスを毎回入力してもらう手間を省きたいというニーズがありましたので、まずは全体像から
1 名前を入力 → 入力完了時に、cookieで保存 → メールアドレスを入力 → 入力完了時に、cookieで保存
2 ページリロード時に、cookieで保存されたデータを当該箇所に呼び出す。
3 次回アクセス時、1へ回帰。もしくは、もう入力しない。
ブラウザ上では、上記の流れで利用します。
今回、条件として入力フォームはHTMLファイルとなっていましたので、Javascriptで記述する事にしました。
用意するファイルは、HTMLとJavascriptの2ファイルだけです。
HTML側（index.html）
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<meta http-equiv="content-script-type" content="text/javascript" />
<script type="text/javascript" src="./js/cookie.js"></script>
</head>
<body>
<form action="***" method="post">
お名前 <input type="text" name="お名前" value="" id="user" onchange="set_cookie('user')" />
メールアドレス <input type="text" name="メールアドレス" value="" id="mail" onchange="set_cookie('mail');" />
</form>
</body>
</html>
※説明の為、簡素化してありますのでWeb標準に準拠しておりません。
javascript側で処理しやすくする為に、各inputにはidを割り振ります
値入力完了時にcookie保存する処理を実行したい為、イベントのonchangeを設定
処理名は、set_cookie()として、id名を渡しておきます。
Javascript側（cookie.js)
window.onload = function reload() {
this.read_cookie();//リロード時の処理内容
}
//-------------------------------------------------------------------
// クッキーへの書き込み
//-------------------------------------------------------------------
function set_cookie(str_id){//html側でonchangeされた時にid名が渡される
//-- 初期設定
var limit = 30;//保持日数
sday = new Date();//日付データ取得
sday.setTime(sday.getTime() + (limit * 1000 * 60 * 60 * 24));//保持日数を加味して、日付データの再生成
s2day = sday.toGMTString();//グリニッジ標準時刻形式へ変換
//-- クッキーデータの格納
document.cookie = str_id + "=" + escape(document.getElementById(str_id).value) + ";expires=" + s2day;
}
//-------------------------------------------------------------------
// クッキーから読み込み
//-------------------------------------------------------------------
function read_cookie(){
var scookie = document.cookie// クッキー情報を読み込む
var scdata = scookie.split("; ");//「; 」で分割
var scdata_num = scdata.length;//配列数を取得
for(i=0; i<scdata_num; i++){//配列数だけループ
scdata_str = scdata[i].split("=");//「=」で分割
document.getElementById(scdata_str[0]).value = unescape(scdata_str[1]);//該当箇所へ反映
}
}
となります。
クッキー利用でのポイントは
書き込みでは、「key=値;expires=保存の期限（グリニッジ標準時間）」で書き込まれるという事。
読み込みでは、「key=値; key=値; key=値; key=値; ・・・・」という形式で格納されているという事。
のたったの2点です。
あとは、要素数がふえれば、その数だけループさせる仕組みにすれば、汎用性も高くなります。
保存期間のところをブランクにすると、情報は仮想メモリにとどまるだけとなりますので、ブラウザを閉じた際には消失します。
その特性を活かして、接続状態の確認に利用するケースが多いと思います。
また、上記のプログラムは、完全なものではありません。解説しやすいように一部省略しております。
プログラム自体は、ご自由にご利用いただいてかまいませんが、自己責任にてお願い申し上げます。
以上、長文となりましたが、今回の記事を締めくくりたいと思います。
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
技術は日進月歩、日々進化しています。
目新しい物を取り入れることは時流に沿っていくという部分で大変重要な事ですが、果たしてそれらは本当に結果を創出しているでしょうか 写真を見せる手法だけでも、数多くあります。
単純に写真を並べる方法だと
写真の角を丸くして見栄えを良くすると
DEMO
クリックして拡大表示だと
DEMO
さらに、自動で見せる方法
DEMO
そのシーンに適した見せ方はあるはずです。 それによりターゲット層へのアプローチを行いコンバージョンへつなげていくべきです。 同じ写真でも、随分違った見え方になる為、場合によっては訴求力に雲泥の差が出てしまうケースもあります。
上記で掲載させていただきました手法の選定は、制作者が遊びの中から思いついたり、絵画の展覧会へいく事ででセンスを磨いたり、皆でデッサンしたりして楽しい発想をできるようにしているからです。
当社は、クライアント様の実現したい事に最適な手法を提案し、結果につながるよう最適化されたWebコンサルティングを行っています。 まずは、ご相談くださいませ。
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
全てのものに空間は必要だと思います。
決して、主にはなりえないのですが、主よりもその役どころとしては意味が深いです。
例えば、写真や絵画での空間。人物の横顔があったとして、その人物を真ん中に描くのか、端に描くのかで全く違った印象を与えてしまいます。
真ん中に描いた場合、もちろん人物が主役になりますが、端に描いた場合、横顔ですからその視線の先。つまりは、絵の外側の「何か」を見つめている人物が主役になります。
静的な空間が「視線の先に何かあるかもしれない」という動的な発想を持たせるという役割をはたします。
空間に役割と意味とが生まれる瞬間だと思えてならないです。
他にも漫才やコントで、ボケてからツッコミまでの流れの中に時間的ではありますが、確実に「間」があり、こちらも空間と言えると私は思います。
空間とは、距離だけでなく時間をも指し、黄金比のような関係が主と空間とで保たれているようです。
下記に設置しましたGoogle Mapも裏側では複雑なコードがセットされているのですが、xhtml側では、文書構造化に注意を払い記述します。
文書と装飾と機能をそれぞれに分けることで、それらの意味や役割をはっきりとさせています。
Google Mapの見栄えについて、さらに掘り下げますと、地図に落ちたバルーンの影を確認できますでしょうか。
一見平面的な地図ですが、バルーンの陰を落とすことで、あるはずのない立体空間を生み出しています。
デザインの奥深さを実感してしまいます。
誰も気がつかないかもしれないところまで品質を追及していく事がお客様に喜んでいただけるサービスの提供へと繋がる一歩だと私は思います。
地図を表示するにはブラウザの設定でJavaScriptをオンにしてください。
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
なぜ人は「デザインする」のだろうか
端的に申し上げますと「イメージを伝えたいから」になると思います。
ところが、つい最近「デザインする」事について少し考えさせられる事がありました。
仕事中に缶コーヒーを飲むの事が日常茶飯事の私なのですが、健康診断の直前というのは何故か本能的に健康になろうという意識が芽生えてしまいます。
そういうわけで、前日からコーヒーは一切飲まずにミネラルウォーターをがぶ飲みして少しでも身体の中を綺麗にしようと悪あがきをしていました。
こんな事がなければ普段ミネラルウォーターを飲まない私はきっと気付く事が出来なかったとと思います。
ミネラルウォーターを飲み干すその瞬間、空になりつつあるペットボトルに視線を向けると、ペットボトルの形状に沿って、這う様に流れ落ちてくる数滴の水が妙に新鮮に感じられまして、それが天然の恵みから生まれた水のようなイメージがふっと浮かびました。
ペットボトルの形状そのものが、水上で起こる波紋をコンセプトとして作られているようなのですが、それらの細かな溝にそって流れて落ちてくる水の動きが自然の恵みを感じさせるのだと思います。
飲み干す瞬間、ペットボトルが逆さになるのですが、その時の最後の水滴の動きまでをもデザインする企画を考えられた担当者様の想像力は並外れているんだろうと思いました。
ただのペットボトルと水という何の変哲もない組み合わせなのに、見惚れてしまっている自分に気がつき少し悔しく思いました。
そこには直接的に売上げやユーザビリティに関係していなくても、ただ消費者に美味しい水だということをイメージしてもらえるように注力したデザイナーが居たのだと思います。
顧客満足を生み出す事がリピーターを増やす事につながり、もっと裾野を広く考えると、ブランド価値の向上であったり、会社イメージにまで影響を与えていくケースもあります。
飲み干す瞬間の水の動きを気にかける人は少ないのかもしれませんが、先の先まで考えて細かい部分まで創り込む事がいかに重要か勉強になりました。
見る人に、こちらが
意図するイメージを感じ取ってもらえる様にデザインする事
の難しさや面白さを垣間見た瞬間でした。
この記事に関連するテーマ
今日は、Webコンサルタント.jpの紀井でございます。
新しい技術やプログラム等を制作し、クライアント様のサイトへ導入し品質を向上させる為に汗を流す事があるのですが、新しい技術というのは、その斬新さとは裏腹にバグという技術者の敵も同時に存在する事があります。 バグがあるとわかっているものはクライアント様に納品する事はもちろん出来ません。 ここで私が問題視するのは、潜在的なバグです。 一見、正常動作していてもブラウザによって挙動が異なっている場合があったり、選択結果によって意図しないデータが抽出されたりと、考えただけで胃が痛くなるようなケースもあったります。 潜在的なバグを見つける為の一番の解決策は、制作者意外のユーザが使用する事だと思うのですが、バグがある状態で納品は出来ませんから、ユーザ＝社内テストとなるわけです。 そこで、当社内部で利用するツールにその新しい機能を搭載させて、しばらく様子を見るという手段を取ります。 バグを探す為に通り一様のチェックは行いますが、それとは別にテストランニングさせ潜在的バグを抽出させるわけです。 経験上、非常に効果があります。 そして、そこであがってきた事例が技術にどっぷりと浸かってしまっている技術だと気がつきにくいものが多いです。 セキュリティ的にやってはいけない事が自然と身についているとテスト段階でチェックしなかったり、もしくはやらなくてもブロッキングされているからという慢心からチェック項目から除外していたりすることが昔はあった（まだ前職時代）のですが、テストランニングすると見事にポイントを突いてバグ報告があがってきます。 技術者としては恥ずかしいことであり、デバッグは当たり前なのですが、自身の物事の見方を変えるべきだとよく思ったものです。 そうやって、またひとつチェック項目が増えていきます。
他にも内制ツールで実験する事は多いです。 クライアント様のサイトに搭載するかしないかは別として、「こんな機能あったら面白いよね」であったり「この流れで処理したらすごく効率がよくならない？」といった立ち話レベルのものを試してみます。 それらの積み重ねがノウハウになりますし、また、場合によってはブラッシュアップさせて商品にする事もあります。 内制ツールの場合、致命的欠陥がない限りは大きな問題でもありません（ツールの重要度にもよりますが）ので、制作者は比較的に気を楽にして構えられますから自由な発想が出来ます。 商品にならなくても、ライブラリとして残すだけで財産にもなります。 一点だけ注意するのであれば、カテゴリー管理でしょうか。沢山開発すればするほど、データは氾濫しますから、カテゴライズを行いしっかり管理する事をお勧めします。
Justアイデアをドラフトで作ってテストしてみるというのは、＝投資だと思います。
しかし、実務は疎かにしないよう気を引き締めつつ会社に貢献＝クライアント様へ提案・提供に繋げていければと思います。
この記事に関連するテーマ
今日は、Ｗｅｂコンサルタント 制作課課長の紀井でございます。
どんな現場にも中核となる人物がいると思いますが、その定義と意義について綴ってみたいと思います。
Coreな技術者とは、様々な種類のスキルを保持しています。
中学校や高等学校での教科と科目を少し思い出していただきたいのですが、国語（現代国語・古典・漢文・・・）・数学（数I・数II・幾何学・・・）・社会（経済・地理・歴史・・・）等々、私などは恩師より教えを授かった覚えがあります。Webの世界も体系そのものは類似していると考えられます。
グラフィックデザイナー（文字デザイン・パッケージデザイン・Webデザイン etc）・イラストレーター（キャラクターデザイン・ペインティング・イラスト制作・挿絵 etc）・コーダー（HTML・XHTML・XML・CSS・JavaScript etc）・プログラマー（PHP・Perl・VB・JAVA・C etc）・撮影（写真・映像）・音工・映像編集・企画発案・要件定義 etcと挙げきれないくらい多岐に渡っています。
よほどの人物でない限りは、すべてを完全に網羅するのはやはり困難だと思われるのですが、いずれかのスキルについてスペシャリストになる事は不可能ではないと思います。
本コラムのタイトルで挙げさせていただいております「Coreな技術者」というのは、個々のスキルのスペシャリストであったり、複数のスキルを保持しつつも複合体としてシナジーを生み出し、新たな価値を創出出来る人物が定義のイメージです。
そんなCoreな技術者が言葉通り中核となって組織内の日々の指導や新技術の導入、品質向上等の貢献をしてくれているわけですが、特筆すべきは「その存在が周りを自然と牽引する」という事だと思います。
まだキャリアパスを描けていないような新卒新入社員であったり、途中入社者から見た時に、同じ技術者集団の中でも銅像と言うべき存在であるスペシャリストの存在は大きい意味を持ちます。
目指すべき、越えるべき目標があるというのはモチベーション（姿勢）を高く保つ事が出来ると同時に、技術的に水準を上げる事（一般的に見て高いレベルだったとしても標準とする事）で、全員がそのレベルを標準だと思って追いつこうとしてくれます。
ここにCoreな技術者の存在意義の大きさを私は感じてしまいます。
例えば・・・
- 新規コーディングをした際に属性としてのid値やclass値のネーミングの仕方ひとつをとっても、体系化する事の重要性に気がついている。
- 新規コーディングとしては、まったく問題がなかったとしても、その後のサポート体制を考慮にいれた構築を行っていく。
- バナーに配置されているテキストの位置が1ピクセル左にずれに気がつける。
- javascriptを利用した表現方法においても、スクリプティング方法により高速化が可能だと知っていて実行出来ている。等々
上記に挙げましたいくつかの例は成果物としては完成しているのですが、一歩踏み込んだ品質向上の為に必要になってきます。
Webサイトを制作し納品すれば終わり・・・なわけはなく、その後もWebサイトは存在し続けます。
品質を高めるという事は、納品時の品質だけのことではなく、運用管理がスムーズに行えるようにすることも含まれなければならないと考えています。
これらの事を当たり前の事として認識するには、普段から情報の共有であったり、指導であったりと中心になって指摘する、成果物に対してプロとしての視点を持っている人間がいなければ実現するのは難しいはずです。
技術力だけが高ければいいのかという問いに対してははっきりとNOと言えます。
ですから、私は技術力だけでなく、ビジネスセンス、さらにはカリスマ性も兼ね揃えた人材をCoreな技術者だと思います。
また、そのような技術者を社内に抱える為には普段からより難しいミッションを遂行させる事も必要ですし、人間関係について学ぶさせる必要もあります。
素晴らしい人材を創出する為に、私のミッションはまだまだ続きそうです。
この記事に関連するテーマ
