転職したので仕事の環境をGoogleの機能中心にしてみた

このたび転職しました。桜がちらほら咲いている中新しい職場に通う……というのは新卒でもないのになんだか不思議な気分です。
先週から勤務が始まり試用期間中でまだ仕事にも慣れず、知らないことは山ほどあり、要領がわからないことや初めて体験する状況に目の回るような日々です。

表題ですが、新しい会社は特に個人の仕事環境を指定はないので、メインはgoogleの各種機能中心で、社内連絡補助にチャットワークとしてみました。あれこれ設定の最中です。

目次

Googleの機能中心にした理由

下記の機能で一通り会社での業務がカバーできそうだと考えたため。使う機能は下記。

• Gmail
• Google連絡先
• Googleドキュメント
• Googleドライブ
• Googleカレンダー
• Google Keep

個々の機能ならGoogle製より使いやすいものも他にあると思うのですが、仕事に関する情報を分散させたくなかったので、『とりあえずgoogleにアクセスすればOK』という状態にすることを目指しています。

容量の問題について

クライアントからのメールに添付ファイルが多いため、容量が15G（2017.04.13現在）というのがネックではあります。
そため会社のPCのOutLookでもメールを受信して、いよいよとなったら容量が大きいメールは順次削除していくつもりです。
月額￥250で100Gまでの追加容量が購入できるので、どうしてもの場合はそれも検討に入れようかと。

チャットワークを補助とした理由

前任の方が使っていたという理由もありますが、社内でのやり取りでメール件数を増やすのも後々手間が増えるため、使い分けをすることにしました。
チャットワークは社内で頻繁に発生する「ここのURL／フォルダ見てください」など、メールで送るほどでもなく、しかし口頭で伝えると地味に手間がかかるようなことだけに使用する程度です。
ファイルは基本送らず、そういうものは社内サーバに置いてディレクトリのみ伝えるようにしています。

補足：skypeでない理由

前職では個別のプロジェクトの中では主にSkypeを使用していたのですが、実は結構問題がありました。

• 発言が流れてしまい、過去にさかのぼるのが難しい
• 既読やタスク完了という機能がないため発言が入り乱れてくると「依頼した作業が完了したか」の見落としが発生する
• 重要発言のクリップができない
• skype上でファイル送信をすると、社内サーバへのアップを忘れてファイルが行方不明になることが多い

など、大きく分けて履歴の参照・ファイルの共有と保存・タスクチェックにおいて問題が発生していました。

Googleの各種機能の運用について

Gmail

大きなメリットとしては下記です。

• 会社のアドレスを送受信アドレスに指定すればGoogle上で扱える
• メール内容の検索・ラベル分けが楽
• PCを起動しなくてもメールが受信できる
• PCを起動しなくてもメールが転送できる
• ネットアクセスさえすればどこからでもメールの確認ができる

『ネットアクセスさえすればどこからでもメールの確認ができる』というのは、社外からというより社内での恩恵が大きいです。
自分のPC以外を使う必要がある際でも、メールを参照したり送信したりができるので楽です。

特別な設定はこれといってしていないのですが、大体次のような設定をしています。

• 送受信メールに会社のアドレスを設定
• 署名の設定
• 返信時のデフォルトの動作:全員に返信
• スレッド表示：OFF
• 送信取り消し:30秒
• チャット:OFF
• （Lab）プレビューパネル：ON（垂直分割）
• スター:全色使用

メールを送ったあと「しまった」と思うことがときどきあるため、送信取り消し時間は最大の30秒取っています。これがすごく便利。
メールは基本的にブラウザ上で送受信しているのですが、普通のメールソフトと比較しても不自由は感じませんでした。

補助としてoutlook

Googleのメール容量は有限なので、いつかは容量いっぱいになる日がきます。
その場合は追加容量を購入するか、サイズの大きなメールは削除するかの二択になるのですが、古いメールに関してはoutlookを保管庫として削除をまずしようかと考えています。
また、outlookには既に届いているのにgmailには届いていない、あるいはその逆ということも発生するので、補助としての位置づけは出ませんがoutlookは常時起動しています。

Google連絡先

これに関しては、メールをよく送信する人から気づいた順に登録していっています。とはいえ相手のメールに返信すれば、その方が登録した名前がそのまま出てしまうし、所属が複数社に渡っていたり、苗字しかわからない、なんてこともままあるので、基本はメールアドレスで見分けている感じです。
現状だと、メールの署名から情報を拾ってる人も多いです。
補助としてわかる人はメモ欄にフルネームやちょっとした情報を書き込んだりもします。

Googleドライブ

• ファイルの共有がしやすい
• 検索機能が充実している
• 画像やpsdなどがプレビューされる（地味に便利）

……とはいっても会社で補完すべきファイルはきちんと会社のサーバーに置いておくつもりですし、なによりメールの容量に充てたいのであまり大きなものでは使う予定はないのですが。
手元に保管しておきたいちょっとしたものは基本的にここに入れておこうと考えています。

Googleドキュメント

• ファイルの共有がしやすい
• 検索機能が充実している

これに尽きるかなあと思います。自分用マニュアルなんか置いておくと、他の人のパソコンを使ったときとても便利です。
スプレッドシートは独自関数などもあってExcelと同じかそれ以上に便利なことも多いですし、なによりGoogleドキュメントは容量を使わないらしいのです。
今はローカルに散らばっている自分用メモも、徐々にドキュメントに集めていきたいと考えています。

Googleカレンダー

これはこまごました予定を入れると言うよりは、大体決まった周期や大きな予定を入れることにしています。
たとえば月初に毎回やる作業だとかそういうのです。
一日単位で終わりそうなものについては次項目の「Google Keep」に入れます。

Google Keep

こちらは用が終わったら捨ててしまうふせんのようにして使おうと思っています。その日やることをTodoでまとめるとか、ちょっとメモしておきたいとかそういう感じです。
画像も貼れるのでそういうところも合わせて活用していきたいですね。

職場での環境構築は何度やっても大変

転職に限らず、新しいPCに変えるとか、人のPCを使わなければならないとか、どうしてもハード面で環境構築がリセットされてしまうシーンはあるものの、必要な情報に問題なくアクセスできるのであれば割となんとかなることも多いです。
そのためにはとにかく情報を集約してしまうというのがひとつの方法ですが、今回はそれもあって試験的にGoogleに集約してみました。
冒頭で述べた通り個々の機能としてはGoogle製のものより使いやすいツールが世の中にはたくさんあると思います。しかしメールからファイル保管、スケジュール管理、メモ機能などが網羅されていること、という条件だとあまりないのではないでしょうか。

やってみた結果としては、まだ二週間弱ですがそこそこにうまく回っている感じです。
あとは業務の流れを覚えた頃合いでスプレッドシートでデータを関数処理をしたり、そういうことができるようになればいいなと考えています。

余談：実は一番苦労する暗黙のルール

なにしろ前の職場では静的なhtml・CSSコーディングのみしか組んでおらず、サーバ関係や複雑なプログラミングはエンジニアの方にお願いできたので……サーバ知識がないのにそういった設定やSNS運用など未知の業務も加わり、毎日ひいひい言いながら過ごしています。

今までは割とあっという間に日々が早く過ぎていましたが、新しい職場に行ってからは毎日「わからん！」の連続のせいか、勤務開始からまだ二週間も経っていないというのが嘘のよう……シャネーの法則なんでしょうか。

まあ、そんな風にそれぞれの会社でやり方がまったく違うのは当然ですが、中でも一番差が出るのは暗黙のルールの部分。
知らないととんでもない地雷を踏むことがあり、明文化されない分、一番厄介でもあります（理不尽なものやサビ残など法に違反していたり、社内外の政治にも関わっているので明文化できるものでもないですが……）。

正直なところ、私はこれを把握するのは非常に苦手な人間で……。
という訳で、入社してしばらくは下記を心掛けてなるべく暗黙のルールを見定めるようにしています。

• 勝手にやらない、触らない、使わない
• やるなら事前に確認を取る（これ使って良いですかなど）
• 電話やメールに注意を向けておく
• 早めにキーパーソンを見極める

こればかりは地道な情報収集しか手はないと思っています。

HTMLコーダーのリスクマネジメントの話

コーディングの仕事中、「あ、これはまずいな」と感じるときがあります。

しかしコーディングまで回ってきた段階では既に決定事項であったり、期限が迫っている等の理由で上流工程へのバックがきかない状況になっていることが少なくありません。

コーダーというのは実装――つまり下流工程に位置しているため、作業の遅れや上流工程での想定不足といった部分の煽りを食らってしまいがちです。

そういう場合どうやって危険を察知するのか、そしてリスク管理するのか、というのが今回の記事の主題です。

目次

リスクを察知する5つの方法

1. 危ないパターンに対する経験値を溜める
2. プロジェクトに関わる人の情報を把握する
3. 要素の目的を自分なりに推測して、その是非を考えるようにする
4. 視点を切り替えて考える癖をつける
5. 危険なワードのストックをする

危ないパターンに対する経験値を溜める

これに関して言うと、正直なところゲームで言う『死にゲー』みたいなものでして、何度も何度もプレイすることで死ぬポイントを体感で覚えるというそれに近いです。

しかし言っておいていきなりですが、

• 社内で運用のディレクター経験があり
• 同じディレクター・デザイナーと何度も組んだことがあり
• クライアントの業種も毎回ほぼ同じ

という条件が重なったことによるところも大きく、仮に他の業種のサイト制作を担当したらあまり役に立たないのかも知れません。

プロジェクトに関わる人の情報を把握する

人に基づくパターン把握と予測はそれなりに有用です。

情報収集の方法としては、

• クライアントとのやりとりのメールを見る
• 電話の声のトーンに意識を傾ける
• ディレクターやデザイナーの癖を蓄積する

といった具合です。

同じ人は同じことを繰り返す傾向があります。

癖を理解していれば予測も立てやすいですし、先手を打てる場合も。

また、コーダーは直接折衝することはありませんが、クライアントのタイプを大雑把にでも把握していると、リスク回避に役立つことも多いです。

要素の目的を自分なりに推測して、その是非を考えるようにする

デザインの勉強を少しずつしていく内に、サイト要素の配置は論理の積み重ねだということが少しずつわかってきました。

• このバナーがここに配置されているのは推したいコンテンツだろうか。
• 推したいコンテンツはこれで、だからこの配置なのだろうか。
• この部分のテキストの色が違うが別の部分より目立たせたいのだろうか。
• ボタンがこの位置にあるが導線をこう確保したいのだろうか。

などなど考えると大体の流れや目的がわかったりすることも多いのですが、そこに馴染まないものが紛れ込んでいて違和感を覚えることがあります。

違和感というのは私の場合、

• クライアントの発言から推測される目的が達成できそうにない
• 要素が整理されていない
• そもそも目的の推測さえできない謎の要素がある

という辺りから発生しているようです。

具体的な例を挙げると、

• コンテンツの順番や配置が不合理
• ざっと目を通しただけでもまとまりのない文章だと感じる
• リンク先指示さえない、押してなにが起こるか不明な謎のボタンがある
• 導線がはっきりしない
• デザインがしっくりきていない
• 項目が異様なほどたくさんあるが整理がされていない
• リストの種類などがいくつもあるが『その装飾はどういったときに使うのか』の基準がよくわからない
• 仕様がはっきりしない

といった、危険信号がいくつもあります。

一見小綺麗なサイトでもカンプを見てこういった嫌な感じがすると、やはり異様に修正や追加が多いなどの難航案件になることが多いです。

視点を切り替えて考える癖をつける

ロールプレイをするつもりで『若い女性だったら／年配の男性だったら／親だったら／クライアントだったら』……など、他人の視点でサイトを眺めます。

大体1～5分くらいでざっくりと（サイトは開いて数十秒しか閲覧されないケースも多いので）トップページを上から下まで眺めながら、ボタンや要素の位置をざっと見て『サイトを閲覧する目的を達成できるか？』を考えます。

ペルソナは大体下記のような感じで、サイトのコンテンツに合いそうな属性を適当に入れています。

• 23歳女性
• →社会人1年目、ネットはスマホメイン、趣味ネイル
• 28歳男性
• →社会人5年目中堅、ネットはじっくり見るときはPC、外出先はスマホ、趣味スポーツ

他、クライアントの視点作りには日頃からメールのやりとりなどを見ておいて、どの変にこだわりを持っているのかなどある程度の嗜好や性格を把握するよう努めておいたりもします。

こういう風に視点を切り替えて見ていると、年配の男性にはちょっとわかりづらそうだなとか、連絡先がすぐに見当たらないなとか、この部分はクライアントがあとで追加要望してきそうだなあとか細々気づくことがあります。

デザインカンプを受け取った際、あまりに各視点で使いづらさや見づらさを感じるもの、クライアントの目的に会っていなさそうなもの、性格的に好みそうでないものがあればあたりをつけおきます。

そういうところは高確率で後々修正が入ったりしますし、作業着手はしないまでも仮に改善するとしたら、と簡単にでも案と工程を考えておくと役に立ったりします。

危険なワードのストックをする

たとえば一般的なところでいうと、なるはや、優先、緊急対応などのワードが入り始めたら警戒を始めます。本当ならどれもあってはならないからです。

その他『この人の名前が出たら難航しやすい』という社内ローカルなものまで、これが出たら危険なワードというのをひっそりストックしています。

下流工程なりのリスクマネジメント

サイト実装という工程の最下流を担当していると、リスク回避の手法としてできることはそこまで多くありません。

冒頭で述べた通り、『既に決まってしまっていて上流工程にバックできない』という状況であることが多々あるからです。

これには締め切りが決まっていてバックする時間がないということも含まれます。

しかし手をこまねいていても仕方がないので、できる範囲で下記ようなことをしてリスク回避を試みています。

上流工程の動向を把握する

上流工程の部分で調整するのが一番効果が高いので、できる場合は以下のようなことをやっています。

• 上流工程の動向を見ておいて、違和感のある場合確認を入れてみる
• 何度も修正が来る場合は言われた修正をただ行うのではなく、再度依頼がきたタイミングで提案をする
• クライアントの依頼の原文を見て、依頼の内容との齟齬を確認する

コーダーまで情報が流れてこない場合も多々あるのですが、そもそもなぜやるか、どうしてそうなったのかを知っているのと知らないのとではだいぶ効率も変わってきます。

作業者が陥りやすいことですが、言われたことを理由や流れを理解せずに言われたままにやるのは、それ自体がリスクです。

時間や状況的にできないこともありますが、可能な限りは上流工程の動向を見ていると色々把握しやすくなります。

あえて作り込まない箇所を見極める

今はCSS3がかなり使えるようになってきているので、画像を使わずに再現できる範囲は広くなってきています。

メンテナンスしやすくなるので、特にテキストなどの変更が多そうな箇所は作りこんだ方がいいのです。本当は。

しかし、コーディングでの作りこみはそれなりに手間がかかります。

下手をすると単純にPC／スマホ／タブレットで別々の画像を準備するより時間が必要です。

しかも再修正依頼がきたら、作り込みに要した作業時間がそっくり無駄になってしまいます。

加えて『またやり直し』というのは精神的にも、時間的にもダメージが結構きてしまうもので……。

それを回避するために、下記のような箇所は、あえてコーディングでは作りこまず簡単な方法で実装するという手段を取ることがあります。

明らかに短期的にしか掲載しない箇所

たとえば突発的なイベントのバナーや、ちょっとしたお知らせや注意書きの付記などがそれにあたります。

こういう部分を更新が容易なよう作り込みしてもいずれは消えることがほとんどですし、htmlファイルから該当箇所を削除してもCSSにコードが残ったりと、CSSファイルを肥大化させる原因にもなります。

そういう場合は、

• 可能な限り汎用的なClassを組み合わせて対処する
• 単に画像を貼るだけで済ませる
• インラインCSSで済ませる

等の対処で『その部分』しかソースコードを残さないようにしています。

違和感を感じる箇所

依頼やデザインを確認して、サイトの構成として奇妙だと感じることがあります。

『とりあえず見たいから作ってくれ』と模索のために気軽に依頼してくるから起こることも多い問題なのですが、結果、何度も何度も修正に付き合わされることも少なくありません。

しかしながら、こういった『とりあえず』と『デザイン模索』全てに全力で応じていたら、残念ながらリソースが圧迫されてしまいます。

そういう訳で、違和感が残る内は*1コーディングでの作り込みはせず、画像を貼るだけなど一番楽な実装方法で済ませてしまいます。

どう考えても画像で掲載した方が良さそうな箇所

CSSでできる範囲は広がりましたが、残念ながら万能ではありません。画像で表現した方が良い場合というのは確実にあります。

そういう部分は無理にCSSで対処せず、画像での表現に任せることにしています。

修正内容を見越して準備しておく

来るとしたらどういう修正になりそうか、あらかじめ予測して準備しておきます。

量産フェーズに入る前に、特にコーディングの根底に関わりそうな部分はなるべく修正が楽なようにしておきます。

期限の調整

なるべく複数案件の締め切りを重複させない

複数案件の締め切りが同じ時期に重複するのは、それだけでリスク要因です。

Web制作はどうしても波のある仕事だと思います。波の発生原因は色々ありますが、いずれにせよ実装担当は遅れの吸収をしなければならないことが多い役割です。

また、締め切り間際に思わぬ作業が舞い込んだりすることもよくある話で。

なので依頼締め切りが重複した場合、期限の調整をお願いするようにしています。

ずらさなかったとしても普通に間に合いそうな場合もよくありますが、それでも可能なら調整を申し出ます。

いつでも最速・最短を見越して予定を立てるとトラブル時リカバリーがききませんので、余裕はできるだけもらっておくに越したことはありません。

状況によっては作業が完了してもあえて手元に置いておく

仕事が終わったらできるだけ早く報告すべきではありますが、あえてすぐ報告せずに手元に置いておくこともあります。

それは以下の場合。

• 五月雨で追加依頼が来る
• 『なるはや』や割り込みが常習化している

これは『割り込み頻度をこちらでコントロールする』ことを目的にしています。

作業はまとめてやった方が効率がいいし、割り込みが増えると単純に集中が切れやすくなって良いことがありません。

また、作業の『なるはや』や割り込みが常習化するのも避けるべき事態です。

本来ならディレクション側で行うべきことでもあるのですが、それが期待できないときは頭に入れておいても良い方法と思います。

ストックを増やす

ソースコードのストック

これは他の人もやっていることではないでしょうか。

コーディングをしていると、「前も似たようなことを書いたな」ということがかなりあります。そういう場合、部品別にソースコードを参照できるようにストックしておくと楽になります。

また、CSSで再現している見出しスタイルをまとめたサイトなどもストックしておくとそのままでは使えないとしても「こういうことはできる」というのはわかるので、有用です。

プラグインのストック

よく使うスライダー、入れてくれと頻繁に求められる機能は、すぐに入れられるように調整した上でストックしておきます。

また、使えそうなプラグインも暇を見てストックに入れたりもします。

調整まで済ませておくと、いざ追加や修正依頼がきたとき手早くできます。

案件終了後にテンプレートを見直して改善する

コーディングをする人なら、大抵基本のワンセットをまとめたテンプレートを作っているのではないでしょうか。

私の場合だと、

• 基本のひな型htmlファイル
• 古いブラウザ対応用のプラグイン
• リセットCSS
• 基本設定や部品を入れたCSS
• よく使うjQueryセット

……をまとめておいて、これを案件毎にコピーして使用します。

比較的シンプルにして余分な要素は省いています。

そして案件が終わったときに元々のテンプレートの使いにくかった点を細々修正して、マイナーアップデートを繰り返します。

地味なことですが、元のテンプレートをアップデートをしていかないと、使いにくい部分やミスが以降の案件でも発生し、また修正に時間を取られる……ということになってしまいます。

案件終了毎にテンプレートの見直しをするのは時間がかかりますが、長期的にはペイできているのではないかなと思っています。

つい最近大きく変えたことは、要素の横並びにflexboxを使用するようにしたこと。少し前はfloatで並べていましたが、それと比べると非常に楽です。

情報共有

弊社の場合基本的に案件は個人単位で完結してしまうのですが、担当中の案件の簡易な情報を共有メモに残したり、ファイルに関してはローカルに抱え込まず、他の人が見たときに最新ファイルがわかりやすいようにしています。

また、ソースコードには適宜コメントを残すように。

個人で仕事が完結してしまうことがほとんどなので、やらなかったとしてもあまり影響は出ませんが、万一ということがあるので習慣として行っています。

情報の記録・分析

やった作業やかかった時間、感想などを簡単にメモして残し、ときどき振り返っています。

上で述べたような、人の癖や傾向を把握する際役立ちますし、ストック作りのヒントや、そのほか全体として眺めると一定の傾向が見えたりします。また、自分の傾向を知るのにも役立ちます。

その際改善できそうな部分は改善に着手しますし、無理そうなら頭にだけ留めておくなど、記録を取っておくとなにかと便利です。

まとめ

フロントエンドエンジニアやコーダーは一体どうやってリスクマネジメントをしているのだろう、と思って調べた結果、あまりそういうことを書いている人がいないのがこのエントリーを書いた動機でした。

大体がコーディングを早くするとかツールを使うとかスキルを高めるとかそういう話ばかりで、確かにそれは大切なことなのですが、自分の求める情報ではないな、と思ったのです。

それで書いてみた結果、コーディングという枠にだけ閉じこもっていたらできることは少ないなあと感じた次第です。

ディレクションはディレクターの役目。

デザインはデザイナーの役目。

コーディングはコーダーの役目。

サイト制作の目標を決めるのはクライアントの役目。

……というのは分業化が進む昨今間違いではないのですが、それだと特に下流工程のコーダーは波に振り回されるだけになってしまいます。

職分を無理にはみ出すつもりはないのですが、リスクを察知する・回避するという視点に立った場合、『依頼をこなすだけ』という以上のことをどうしても考えざるを得ない訳で。

あれこれ本を読みながら、結局ディレクターのこと、デザイナーのこと、クライアントのことを知らないといけないのだなということに思い至って、拙いながら上記のことを考えながら仕事をしています。

余談：将来の仕事について

また将来を考えた場合、いずれコーディングの仕事は機械に取って代わられてしまうであろうと私は思っています。

現在でも既に（制限はありますが）直感的なUIによって部品を組み合わせるだけでサイトが作れるようになっていますし、この流れはもっと進むのではないでしょうか。

また、今のhtmlというもの自体ががらっと変わってしまうことも考えられます。

そうなると人間としてできる仕事は、『なにをするのか』『なぜそれをやるのか』『どうやるのか』を考えることがメインになると思います。

すぐという話ではないにしても、サイト制作というのは結局そういう方向に行きつくと思うので、リスクマネジメントとして『コーディングだけしかできない・しない』にならないように気を付けているという面もあります。

勉強用に読んだ本

HTML5/CSS3モダンコーディング フロントエンドエンジニアが教える3つの本格レイアウト スタンダード・グリッド・シングルページレイアウトの作り方

Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法

沈黙のWebマーケティング −Webマーケッター ボーンの逆襲− ディレクターズ・エディション

第一線のプロがホンネで教える 超実践的 Webディレクターの教科書

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

デザインの教室 手を動かして学ぶデザイントレーニング(CDROM付)

センスは知識からはじまる

問題解決に効く「行為のデザイン」思考法

*1:ただし提案できる場合は見本に作ることもある

【書評】沈黙のWebライティング はWebのコンテンツライティングに悩む人にイチオシの本でした

インターネットには日々大量のコンテンツが投稿されていますが、残念ながら見てもらえるのはほんのひと握りです。

「一生懸命書いた記事なのにPVが伸びない」

「長年サイトを運営してきたけれど拡散されたことはおろか、感想をもらったこともない」

「そもそも記事が読んでもらえていない気がする」

「読みにくい、見づらい文章だと言われるがどこをどう直していいのかわからない……」

「新しくサイトを立ち上げたいがアイデアが思いつかない」

仕事としてサイト運用を担当している方だけでなく、個人のブログやサイトを持っている方なら、一度はこのような悩みを抱えたことがあるのではないでしょうか？

この沈黙のWebライティングはそのような悩みをSEO（検索エンジン最適化）の観点から解決すべく、その根幹となるWebライティングの技法をわかりやすく解説している本です。

それでは以下、書評です。

今回の舞台は、客足が遠のいてしまった那須の旅館・みやび屋

前作の沈黙のWebマーケティングと同じように今回もストーリー仕立てとなっています。

今回の主人公は両親を亡くして旅館を受け継いだものの、運営がうまくいかずに悩む若女将・サツキとその弟ムツミです。

登場人物の知識が増える毎に項目も順序良くステップアップしていくため読みやすく、「これはどういうことだろう？」ということなく読み進めることができます。

SEO（検索エンジン最適化）とは、ユーザーのことを第一に考え、ユーザーに良質な情報を提供すること

作中何度も説明されるのは、主要検索エンジンのGoogleの方針についてです。

Googleが掲げる10の事実*1の最初で、Googleは次のようなことを言っています。

ユーザーに焦点を絞れば、他のものはみな後からついてくる

引用：Googleが掲げる10の事実

どういうことかというと、Googleはユーザーの役に立つように、そして使いやすいように検索エンジンのシステムを調整し続けています。それが回りまわってGoogleの利用ユーザー数が増えれば、Google自身のためにもなる、ということです。

よって、最高のSEO（検索エンジン最適化）は、ユーザーの役に立つコンテンツを作ることになります。

そうすれば自ずと検索エンジンに評価され、検索結果の上位になりやすい、ということになります。

そのことを踏まえて、

「じゃあ、ユーザーの役に立つコンテンツってどうやって作るの？」

という疑問への回答が、作中で様々なケースを通じて説明されています。

その他、競合分析の仕方、良質な記事の書き方、昨今のキュレーションメディアの問題点、オウンドメディアの立ち上げ方、そしてライターの育て方など、Webコンテンツの作り方に関する情報が盛りだくさんで、非常に充実した内容となっています。

まとめ：小手先の技術ではない、良質なコンテンツの根本的な作り方の指南書！

私自身Web制作に関わり、過去にはライターの勉強をして少し仕事をさせてもらったという経験もあって興味深く読ませていただいた本なのですが、とてもためになる本でした。

作中、文章を書く上でのちょっとした小技などは載っているのですが、結局のところ良質なコンテンツというのは小技でどうにかなるものではありません。

もちろん、文章を書く上で基本として押さえておくべきところは当然あります。

ただ、それと同じくらい大切にすべきことは他者への気遣いだと感じました。

ユーザーだけではなく、コンテンツを気持ちよく引用させてもらうためにすべきこと、またそれによって協力を得ること、相手の良いところを上手に引き出すこと……『コンテンツを作ること』を目的にしてしまうと、おろそかになりがちな部分です。

以上、Webでコンテンツを作ることに悩んでいる人にはぜひおすすめしたい本でした。

また、せっかくですので本の内容の実践としてこの書評を書かせていただきました。以前から無意識ながらやろうとしていたことがすっきりと整理・解説してあったので、かなり書きやすかったです。

少しでも参考になれば幸いです

関連リンク

前作と今作はWeb上でもかなりの部分公開してくださっているので、興味を持っていただけましたら、よろしければ併せてこちらもどうぞ。

www.cpi.ad.jp

www.cpi.ad.jp

沈黙のWebマーケティング −Webマーケッター ボーンの逆襲− ディレクターズ・エディション

沈黙のWebライティング ?Webマーケッター ボーンの激闘?〈SEOのためのライティング教本〉

*1:現在（2017.02.21の時点でページは消えてしまっている）