エンジニア・ディレクター陣含めて合宿に行ってきました！（エンジニア編）

こんにちは。エンジニアの志村です。 小川くんがブログ書いてくれたように、先月、弊社設立初となる開発合宿に行ってきました。 エンジニア：3名, ディレクター：3名で日光に行ってきました！ 今回は開発編ということで、その模様と、具体的な内容、反省等を書いていきたいなと思います。

開発合宿開催への経緯

多くの企業が開発合宿に関するブログを書いているのを拝見し、度々合宿行きましょう！という話は出ていたのですが、皆の日程や移行タスク等の理由から中々開催出来ていませんでした。 そのような中で色々な企業のブログを読んでいく内に一回やっておくのもいいだろうという社長の鶴の一声で合宿開催が決定しました。

志村: そういえば合宿ってやるんですか？ 高橋: え、合宿行きたい！

大濱: 1回やっとくのもいいかもね。行きましょう！

こんな感じです。軽い。

合宿までの事前準備

今回の手配は清水ディレクターがほとんどやってくれました。 本当何から何まですみません…

宿

開発合宿で必要なものを考えると

  • 延長コード
  • Wi-Fi（安定していてなるべく高速）
  • 6人が利用しても十分な広さがある会議室
  • 何時でも使用出来る会議室

上記のような感じでしょうか。 上記の条件が揃っている宿は中々探すのが難しいので、色々な企業さんが使用している宿をピックアップして今回の宿に決めました。

スケジュール

合宿とは言え、遊んでいたのでは意味がありません。酒を飲みまくっても意味がありません。と何故か僕だけ大濱に念押しされたのできちんとタイムスケジュールを組みました。

概ね、下記のようなスケジュールを事前に立てました。 今回の合宿ですが、開発メインというよりも、ビジョンの再共有、また将来のキャリアパス等を考えたりと、コミュニケーション周りがメインになる合宿でした。

1日目

10:00 集合&出発（3時間程度で到着）
13:00 チェックイン
14:00 自由時間（5時間）
19:00 夕食
20:00 自由時間（4時間）

2日目

08:00 起床&飯
09:00 自由時間（3時間）
12:00 昼食
13:00 理念会議(6時間) 
19:00 夕食
20:00 UTAGE

3日目

08:00 起床&飯
11:00 チェックアウト&出発
15:00 東京着
16:00 オフィス業務

上記のスケジュールから開発に充てられる時間は下記のようになりました。

開発に充てられる時間

  • 1日目: 9時間
  • 2日目: 3時間
  • 合計: 12時間

と、開発合宿の中ではかなり時間が少ないですね。 というのも2日目の理念会議が今回のメインテーマになるからです。 会社として初の合宿なので、エンジニア・ディレクター双方にとって有用な合宿にしたいという理由でこのようなタイムスケジュールとなりました。

実際にやる内容

さて上記のように開発に充てられる時間は 12時間となりました。 この時間でやれることは結構限られてくるので、何をやるかは結構慎重に議論を重ねました。 今回の合宿において重要にしていたのは下記の3点です。

  1. 合宿中にやりきれる
  2. チーム一丸となって取り組める
  3. 改善した内容が見える化出来るもの

特に大切なのは1.かなと考えています。 というのも初の合宿なので、合宿中に何かを達成した！という感覚を皆に持ってもらいたかった為です。

テーマ決めですが、上記の条件を考慮したテーマをアドバイザーの露木さんから幾つか提示して頂きました。

テーマ案

  • Sentryのエラーをxxx%減らす
  • NewRelicのレスポンスタイムをxxx%早める
  • CoffeeScriptをES6化する
  • 開発環境をdockerにする
  • テストカバレッジをxxx%高める

上記のような案を出して頂きました。

この時点でのチームの課題はテストカバレッジでした。 今まで、旧サイトからの移行、またそれに伴う機能の拡充を急いだ結果、チーム全体としてテストに対する意識が低いのが前々から問題でした。 ちょこちょこは書いていたのですが、最低限のユニットテストのみでE2Eテストをほとんど書いていない状況…。 最近mamanokoも規模が大きくなってきており、目視だけで完全に動作を把握することが難しくなってきております。 その為、テストカバレッジのUPが急務でした。

ということで、 今回はテストカバレッジを95%に上げる！ というテーマに決定しました！

1日目

  • simplecovを使用し、現状どれくらいのテストカバレッジとなっているか調査。 → この時点で80％前後
  • 開発開始前に30分程度話し合い、どの部分を担当するか決める。その際に、自分が実装していない機能部分を割り当てることにしました。
  • テストごりごり書く。1日目は朝方5時まで3人で書き、どうにか92〜3%まで到達

f:id:cluex-developers:20160330215523j:plain

2日目

  • 95%もう少しだねと楽勝ムードが出てくる。
  • しかし、朝の時点で93%近くをウロウロ。
  • ここから上げるのがかなりキツかったです。テストの経験値が少なく皆悪戦苦闘…。
  • どうにか理念会議終了後に95%達成！！

f:id:cluex-developers:20160330220431p:plain

まとめ

上記のように紆余曲折ありながらも何とか、目標となる95%超を達成することが出来ました！ 現在でも97%前後をキープ出来ている状態です。

良かった点

  • 数値で目標設定出来るのが良かった
  • 合宿ならでは（？）のやってやるぞ感が楽しかった
  • たまには違うところでやると捗る
  • エンジニア同士は勿論だが、ディレクター陣とコミュニケーションを深くとれたのが非常に良かった
  • 割り込み等が無かったので集中して作業に取り組めた

問題点

  • 1日目飛ばしすぎて、2日目本当眠かった
  • 2泊3日は短かった。3泊出来るともっと出来ることが広がりそう
  • テストも良かったが、次回は新しい物をチームで作るというような取り組みも行いたい
  • 夕食時に酒飲むと眠気が半端なかったので次回は禁止でも良いかも…
  • 腰が…
  • 事前準備をもっとしておけばすぐに開発に取り掛かれた

エンジニア・ディレクター陣含めて合宿に行ってきました！in日光

こんにちは、人事兼ディレクターの小川です。

先日、社員・インターン生含めて6名で2泊3日の開発合宿に行って参りました！ f:id:cluex-developers:20160312215204j:plain たまたまネットサーフィンをしていた時に見つけた、某インターネット関連の大手企業さんにあやかって日光にあるペンション「はじめのいっぽ」さんにお邪魔してきました！その時の合宿の様子をレポートにしてみました。

なぜいったのか

今回の開発合宿では、ただコードを書くというものではなく、エンジニア・ディレクター陣含めて「理念会議」を行うことがメインでした。個人の課題、会社の課題をエンジニア・ディレクターの双方向から話しあい、お互いの思いや考えを共有しよう、というものです。

「理念会議」とは？

メンバーが将来目指すビジョン、今現在抱えている思いなどを共有する場を「理念会議」と名づけています。日頃話せないようなことを赤裸々に語ることにより、チーム全体の士気を高める場となっています。

さらに、この開発合宿の各チームの目標は以下の通りです。

  • ディレクター「サービスの改善点を洗いだす・洗いだした改善案をタスクまで落としこむ」
  • エンジニア「テストカバレッジ95%以上」

それでは、合宿の様子を振り返ってみたいと思います！

1日目

  • 10時:出発

f:id:cluex-developers:20160312191557j:plain

みんな朝から元気ですね。「社長の顔が凄いことになってる・・」初日の元気は合宿最終日まで持つのでしょうか？

  • 13時:チェックイン

f:id:cluex-developers:20160312191910j:plain

大手製薬会社の営業マンからエンジニアに転身した志村さん。日頃はムードメーカーとして場を盛り上げてくださっています！

  • 14時:作業タイム

f:id:cluex-developers:20160312190751j:plain

「あれ？黄昏れてる？」

ペンション内は、静かな環境で落ち着いて仕事に取り組むことができます。

1日目は、ディレクター陣は「よりユーザーにとって価値のあるサービスにするためには？」をテーマにして会議を行いました。より会議を質の高いものにするため、スマートフォンのUI/UXにテーマをセグメントしました。数値を元にページ単位のミクロ分析とサイト全体のマクロ分析の2つから徹底的に問題点を洗い出しました。洗い出されたデータを元に必要となる機能のみ具体的なタスクに落とし込んでいきました。

  • 20時:夕食

f:id:cluex-developers:20160312191252j:plain

一日目は「すき焼き」でした。ペンションの方の粋な図らいで大量のお肉を用意していただきました！

f:id:cluex-developers:20160312213443j:plain

メンバーと鍋を囲んで美味しく頂きました！

美味しいお肉ってボリューム感凄いんですよね。食べ過ぎました。。この後の仕事はかなり眠かったです。

  • 21時:作業タイム

f:id:cluex-developers:20160312192130j:plain

エンジニア陣は朝4時までテストカバレッジ95%を達成するべく必死に格闘していました。

2日目

  • 9時:作業タイム

f:id:cluex-developers:20160312213129j:plain

変な人がいる・・。 あまり寝ていないので、テンションがハイになっているみたいです。

ディレクターは各々が担当する業務を進めていました。エンジニア陣は引き続きテストカバレッジ95%に向けて黙々とパソコンに向かっています。

  • 14時:「理念会議」

f:id:cluex-developers:20160312213237j:plain

2日目の午後は、いよいよ理念会議です。今回の開発合宿の一番のテーマですね。

理念会議で行われた議題は主に2つです。

  1. 自己分析(個人の今の課題と、将来の目標)
  2. 会社の現状課題を話し合う

①自己分析(個人の今の課題と、将来の目標)

事前に準備してきた個人の課題や将来の目標をみんなの前で発表。その後でメンバーから発表した内容のフィードバックをもらいます。フィードバック中に普段では聞けない会話がいくつも出てきました。特に幼少期にどんな人間だったのか、という話になった時はメンバーの意外な一面を聞くことができました。

②の会社の現状課題を話し合う

今後の経営戦略などの話も出ましたが、会社の衛生面強化など日頃の一面を見直すキッカケの場になりました。それぞれが思う問題点を一度に聞くことができ、今後の仕事への取り組みがより一層引き締りました！

  • 20時:食事

f:id:cluex-developers:20160312213423j:plain

2日目は、「炭火焼き」でした。みんな満腹状態の中、社長は「食事を残すものは経営者になれん」という思いから残りの食材を食べつくしました。この後、強烈な眠気が襲ってきたのは言うまでもないですね。

3日目

  • 9時:仕事

f:id:cluex-developers:20160312213527j:plain

「おっ、イケメンポーズ？」

いよいよ合宿最終日です。ディレクターもエンジニアもラストスパートを掛けます！

  • 12時:チェックアウト

f:id:cluex-developers:20160312214355j:plain

3日間濃い時間を過ごすことができました。ちょっとお疲れ気味の方も・・？

f:id:cluex-developers:20160312213614j:plain

合宿の最後に日光東照宮へ観光にきました。

f:id:cluex-developers:20160312213625j:plain

翌日に筋肉痛の人間も・・

f:id:cluex-developers:20160312213721j:plain 記念写真

「見ざる、言わざる、聞かざる」のつもりがシャッタータイミングが合わず聞かざるだけに・・

終わってみて・・

f:id:cluex-developers:20160312214812j:plain

落ち着いた環境の中、会議などもスムーズに進んでいき充実した3日間でした。温泉に浸かって仕事以外の会話をすることもとてもよかったですね。温泉の時の写真もあるのですが、自主規制とさせていただきます。今回の合宿の目的であった「理念会議」はチームとしてより結束力を高めることになったのではないか、と感じています。日頃から業務の会話や雑談はされていると思いますが、中々自分の将来についての思いや考えを話すことは少ないのではないでしょうか？是非みなさまも「理念会議」、試してみてください。

長期の休みにはまた開発合宿を行いたいと思います。

以上です。 最後まで読んでいただき、ありがとうございました！

良かった点

  • 静かな環境で集中して仕事ができた
  • ペンションの方がおすすめの温泉を教えてくれたり、とてもあたたかみを感じれる
  • 環境が変わってリフレッシュしながら仕事に取り組めた
  • 料理が美味しい(炭火焼きおすすめです！)
  • アットホームな雰囲気でチーム全体として結束力が高まる
  • 会議のテーマを事前に決めたいたこと

問題点

  • 近くにコンビニがないので、車を使わないと移動ができない
  • 長時間イスに座っていると、腰が痛くなる
  • 2泊3日だとちょっと短い
  • 平常の業務を行ってしまい、達成感が少なかった(ディレクター陣)

次回に向けて

  • 1週間ほど時間をとって行いたい
  • 合宿が終わった翌日を休日にしたい
  • 近くにコンビニがあるところ
  • 昼に温泉に入らない
  • チームとして達成感のある作業があるといいかも

scss-lintの導入方法とその紹介

エンジニアの井戸田です。

今回は自分たちが導入した scss-lint についての実装方法を紹介したいと思います！ scss-lint とはCSS拡張メタ言語 scss のRuby製解析ツールで、 scss のコードが設定に違反していた場合、警告をしてくれるツールです。 ついfatになってしまいがちで、１度書いてしまうと中々修正しにくいcssですが、 scss-lint を使用することにより、統一感を持ったコードになり、リファクタリング時にも修正がしやすいと思います。

インストール

$ gem install scss_lint

また Gimfile に以下を入力して bundle install でインストールすることができます。

gem 'scss_lint', require: false

実行方法

スキャンするディレクトリまたはファイル名をコマンドラインに渡すことによって、scss-lint を実行することができます。

$ scss-lint app/assets/stylesheets/

$ scss-lint app/assets/stylesheets/base.scss

またオプションで -v/--version でバージョンを確認することができます。 様々なオプションがあるので、上記のURLからご覧ください。

$ scss-lint -v/--version

実装

scss-lint はデフォルトで下記のような設定になっています。

scss/config/default.yml

この設定の中で、自分たちが不必要だと思う設定に対して、ホームディレクトリに .scss.yml をいうファイルを作成し記述することで、その設定を無効化していきます。

.scss.yml の記述例

exclude: 'app/assets/stylesheets/plugins/**'

linters:
  ColorVariable:
    enabled: false
  • exclude : スキャンして欲しくないディレクトリまたはファイルを記載します。
  • linters : linters: 以下に無効化したい設定を記述していきます。
    • enabled : こちらには linter を実行するかどうかを true または false で記述していきます。上記の設定は ColorVariable を enables: false と記述しており、ColorVariable という設定を無効化させています。

設定の紹介

下記のURLに各設定の内容が記述されています。 ここで自分たちが重要だと思った設定をいくつか紹介していきたいと思います。
https://github.com/brigade/scss-lint/blob/master/lib/scss_lint/linter/README.md

EmptyLineBetweenBlocks

個別のルール、機能、@mixin宣言の後に空行をいれるという設定です。このようにすることでコードが一気に見やすくなります。

// Bad

div {
  margin: 10px;
  a {
  
    ...
  }
}
p {
  margin: 0;
}
// Good

div {
  margin: 10px;
  
  a {
    ...
  }
}

p {
  margin: 0;
}

EmptyRule

空のルールがある場合警告するという設定です。つい見逃してしまいがちですが、この設定で気付くことができますね。

// Bad

p {
}

HexLength

短い又は長いスタイルオプションを設定することすることができます。

color: #ffffff;
color: #fff;
設定オプション 項目
style short 又は long （default: short）

ImportantRule

!important を使用しないという項目です。 つい使ってしまいがちの !important ですが使用することで、脆いコードになってしまいます。なので弊社では使用しないようにしています。

// Bad

p {
  color: #f00 !important;
}

MergeableSelector

同じ深さで２度同じプロパティを使わないという設定です。

// Bad

h1 {
  margin: 10px;
}

.baz {
  color: red;
}

h1 {
  text-transform: uppercase;
}


h1.new {
  color: #000;
}
// Good

h1 {
  margin: 10px;
  text-transform: uppercase;
  
  &.new {
    color: #000;
  }
}

.baz {
  color: red;
}

PropertySortOrder

記入するプロパティの順番を決めます。自分の好きな順番にカスタマイズすることもできますが、下記のように記載することで元々設定されている smacss の順番にすることができます。

  PropertySortOrder:
    order: smacss

また smacss　以外にも concentric , recess などがありプロパティの順番については以下のURLからご覧ください。
property-sort-orders

Shorthand

サポートするプロパティに可能な最も短い表記で書くという設定です。

// Bad

margin: 1px 1px 1px 1px;

margin: 1px 0 1px 0;

margin: 1px 1px 0 1px;

// Good

margin: 1px;

margin: 1px 0;

margin: 1px 1px 0;

UnnecessaryParentReference

不要な時に親セレクタ（ & ）を使用しないという設定です。

// Bad

div {
  & > a {
    ...
  }
}

// Good

div {
  > a {
    ...
  }
}

ZeroUnit

値が0の時には単位を省略するという設定です。

// Bad

p {
  margin: 0px;
}
// God

p {
  margin: 0;
}

最後に

今回は「scss-lintの導入方法とその紹介」でした。 scssを使って実装されている方がいましたらぜひ導入してみてください。開発が複数人いる企業にとって統一感をもったコードを書くのは難しいですが、こちらを導入することで、皆同じ記述で実装ができレビュー時も見やすくなると思います。紹介した設定の他にも scss-lint には様々な設定があるので、ぜひ調べてみてください。 最後まで読んでいただきありがとうございます。　井戸田

参考文献

SEO初心者がチェックしておきたいブログサイト8選

ディレクターの小川です。

今回は、僕たちがマーケティングの一環で行っているSEO施策について紹介していきたいと思います。 SEOの施策は効果が出るまでに最低でも1ヶ月程かかると言われていますね。すぐに結果が出ない為、どのように進めていけばよいのかと迷っている方も多いのではないでしょうか。

僕自身も初めてのメディア運営ということもあり、サイト開設当初は手探りで進めてきました。そこからサイト運営に力を入れ、10ヶ月程が経過しました。試行錯誤のを重ねた結果、オーガニック検索からの流入数だけで、月間120万人を超えるところまで成長できました。その試行錯誤の結果の一部を紹介しつつ、同じような立場であるSEO初心者や初心者マーケッターの方に向けて、少しでもお役に立てる情報をお届けできれば幸いです。

まずは今回、僕が参考にしているSEOブログサイトをご紹介したいと思います。

「SEO初心者がチェックしておきたいSEOブログサイト8選」

SEOブログサイトのチェックはSEO初心者には重要な情報元となってきます。根拠がないままやみくもにSEOの施策をしていけば、決して数字には表れません。しっかりとした情報をインプットした上で、自社サイトで効果が見込める施策をランク付けしていくことが重要です。

ではさっそく、ご紹介していきます。

⑴ バズ部

http://bazubu.com/category/seo

SEOの基礎から応用まで網羅的に情報がそろっています。記事は基本的には長文なのですが、コンテンツがしっかりとしているので、読者を飽きさせません。記事を読み進めていくうちに気が付くとSEOの知識が頭の中に入っていた、と実感できる良質なコンテンツが魅力的なサイトです。

僕がオススメするこれだけは読んでおきたい記事

・「SEOとは検索ユーザーに120%の価値と満足を提供すること」

⑵ SEO HACKS

http://www.seohacks.net/blog/

SEOの情報をただ記事にするのではなく、様々な事例をわかりやすい図や絵を用いながら紹介してくれます。また、記事のテーマの切り口に独自性があるのも特徴の一つです。SEOを学んでいる人が楽しめるテーマを提供してくれますので、常にチェックしておいて損はないと思います。

僕がオススメするこれだけは読んでおきたい記事

・「検索ボリュームがないキーワードでSEOを行う必要があるのかという話」

⑶ ferret

https://ferret-plus.com/

Webマーケティングに携わるコンテンツが幅広く用意されています。特にニュース系の最新情報を取り扱う記事は手軽にトレンド情報をゲットすることができます。また、それぞれの記事の最後には簡単な問題が用意されており、その記事の簡単な復習をすることができます。WebデザインやIT企業情報などSEO担当者以外のマーケティングに関わる全ての人が参考にしたいサイトです。

僕がオススメするこれだけは読んでおきたい記事

・「コンテンツマーケティングでやりがちな失敗事例5選」

⑷ LIG

http://liginc.co.jp/web/seo

サイトのデザインがとても綺麗でおしゃれです。エンタメ系の記事が人気を博したことでも有名です。ライターさんが沢山いらっしゃるのですが、それぞれの方の個性が記事に表れています。お気に入りのライターさんを見つけてチェックすることも楽しみ方の一つになると思います。

僕がオススメするこれだけは読んでおきたい記事

・「マジで使える無料のWebサイト分析ツール&サービス8選」

⑸ Web担当者Forum

http://web-tan.forum.impressrd.jp/

長い間サイト運営をされていて、過去のSEOのことについても学ぶことができます。海外のSEO情報も豊富に取り扱っていて充実したサイトです。Web関連の著名人へのインタビュー記事が人気で、様々な企業の方の知見を得ることができます。

僕がオススメするこれだけは読んでおきたい記事

・「ズバリ、検索で1位になる方法をこっそり教えてください！／グーグルの金谷武明さんに聞いてきた」

⑹ 海外SEO情報ブログ

https://www.suzukikenichi.com/blog/

Kenichi Suzukiさんが運営する海外seo情報ブログです。今回初心者向けブログとして紹介するかどうかで迷いましたが、SEO担当者の方なら海外に目を向けて最新情報を知りたいという方も多いと思います。各記事にはレベルが設定されているので、まずは初級~中級の記事から読み進めていくと効率よく勉強することができます。

僕がオススメするこれだけは読んでおきたい記事

・「Google社員がアドバイスする2016年に取り組むべきSEOの秘訣」

番外編

下記に紹介する2つの記事は、個人的に勉強になる点が多かったものです。常にブログサイトをチェックすることが億劫と感じる方は下の記事に目を通すだけでも、SEOで重要なポイントが掴めてくると思います。

⑺ プロモニスタ

https://promonista.com/

僕がオススメするこれだけは読んでおきたい記事

・「【Googleアルゴリズム完全分析 1/4】プラスに働く”内部SEO”要因74項目」

シリーズ4回に渡って、内部と外部SEOについてまとめてある記事です。プラス要因の記事ばかりではなく、マイナス要因を知っておくことも大切だと思います。知らないところでGoogleからペナルティを受けているかもしれません。

⑻ 儲け学

http://moukegaku.com/

僕がオススメするこれだけは読んでおきたい記事

・「検索アルゴリズム完全リスト200：Google検索順位要因」

「Googleの検索アルゴリズムは200以上あるらしい。」そんな噂を耳にして色々な文献を漁ってい時に発見した記事です。200のリストで初心者の方には少々小難しい内容もありますが、検索アルゴリズムを徹底的に勉強したい方にオススメの記事です。

最後まで読んでいただきありがとうございます！

Googleのアップデートに伴いseoの動向は日々変わっているので、時間を見つけてチェックしてみることをお勧めします。 今後も機会を見つけて情報を発信していきたいと思います。

アナリティクス(GA)とスプレッドシートを使って記事ごとの分析を自動化する方法

こんにちわ。ディレクターの清水です。 今回は、｢アナリティクスのデータをスプレッドシートに自動抽出してKPIを効率的に計る方法｣を紹介したいと思います!
今回はAPIやGAS(googleAppScript)に関する知識が全くない方でも簡単に自動で抽出できる方法をご紹介するので、ディレクターの方々の参考になれば幸いです。

(2015/11/22 【使用ツール】 : スプレッドシート(spread sheet), アナリティクス(Google Analytics) )

【かわいい＆長持ち＆絶対喜ぶ】1歳の誕生日におすすめプレゼント25選 | mamanoko（ままのこ）

最近の僕達のSEO施策

最近弊社ではサイトのリニューアルを行ったのですが、さらにユーザービリティ向上に何かできなかなと思っておりました。そこで、記事内にリンクを貼ることで、ユーザー様のニーズにあった記事をレコメンドしてユーザビリティを上げたいと考えました。今回はKPI(Key Paformance Indicator)として、直帰率の下げ幅を設定しました。

検索上位でトラフィックの多い50記事に的を絞って、リンクを手動で追加して変動を見る、みたいなことを行いました。ただ、リンクを追加した記事を毎回アナリティクスでみて、直帰率の変動を見るみたいな単純作業は少し効率が悪いと感じ、じゃあ自動化しようとこれから紹介するようなことを行いました。 Spreadsheetにアドオンの取り込みから、アナリティクスのデータの取り出し方法、取り出したデータをKPIとして観測しやすいようにシートにまとめる、といった順番で最初から説明したいと思います。アドオンの使用方法を知っている方は、手順5からご覧いただければ良いかと思います。

取ってくる情報

アナリティクスの記事ごとのデータ(記事IDで絞込み)
ユーザー数, 直帰率, 離脱率

手順1. アドオンの導入

まずはスプレッドシートを開き、ツールバーの上部からアドオンを導入する。(無料)

f:id:cluex-developers:20151122184842p:plain

｢アナリティクス｣などで検索をして、下(画像で◯の付いている方)を選択する。

f:id:cluex-developers:20151122185313p:plain

その後承認を求めてくるので、｢承認｣を押して下さい。
ダウンロードが完了したら、下記の画像のようにアドオンを起動。

f:id:cluex-developers:20151122185937p:plain

手順2. アナリティクスのデータをスプレッドシートに抽出する。

create new reportを押したら、下図のようにシートの右側にエディット画面が出るので、 name には適当に名前を入力(あとで自動的に記事のURLになるようにします。)
Matrics には Pageviews(PV数) % Exit(直帰率) Bounce Rate(離脱率)を選択し、
Dimensions には Date を選択すると、下記のようになる。 もちろん他の指標も抽出できるので、コンバージョンなどを設定している場合はそれも指標にいれると良いかもしれないです。

f:id:cluex-developers:20151122210605p:plain

これで、Create Reportをクリックします。すると新しいシートが作成され、下記の｢Report Configuration｣ページが表示されます。このシートを｢シートno.1｣とします。

f:id:cluex-developers:20151122211730p:plain

ちなみにこのままデータを抽出すると、すべてのページの合計のPV数や直帰率を図れるのでKPIの観察に便利です。(アナリティクスでいうと、｢ユーザーサマリー｣の情報が抽出できます。)

手順3. 記事ごとのデータに絞っていく。

今回では、サイト全体のデータではなく、記事ごとのデータが欲しいので、ここからさらに検索の範囲を絞っていきます。
｢Filters｣と書かれてある列に、ga:pagepath==記事ページのユニークID を入力します。例えばmamanokoの場合だと、記事URLは、https://mamanoko.jp/articles/◯◯という形をとっているので、/articles/◯◯の部分がページのユニークIDです。

f:id:cluex-developers:20151122212227p:plain

これでこの記事のデータを取ってくることが可能になりました。ちなみに、Filtersの部分には記事IDではなく、ga:sourceMedium=@organicと入力すると日毎の｢オーガニック検索｣流入数が、ga:sourceMedium!@organicと入力すれば、検索以外での流入数(ソーシャル、リファラル、ダイレクト)を計ることもできます。このfilterの使い方に関しては、下記の記事が参考になるかと思います。この記事はアドオンの使用方法の基礎をしっかり書いてくれているので、かなりおすすめです。 Googleアナリティクスの分析はスプレッドシートのアドオンで全自動化しよう

手順4 抽出

再び上のツールバーのアドオンより、アナリティクスを選択し、Run reportを押すと、ついにフィルターに掛けた記事に関するデータが表示されます。

f:id:cluex-developers:20151124020358p:plain

直帰率と離脱率は、少数で表示されているので、列を選択して左上の%を選択すれば、アナリティクスと同様に32%などと表示されます。 残念ながらアドオンの機能では、同時に複数の記事のデータを表示することはできません。しかし、複数のデータの変化を測れないとスプレッドシートで管理する意味がないので、手順5からが大事になってきます。

手順5 複数の記事のデータを同時に取得する方法

冒頭で紹介したように、今回我々は流入数の多い50記事にリンクを追加しました。そこで50記事すべての直帰率･離脱率の変化を計る必要があります。さらには、今後も他の記事にリンクを追加していくので、今ある記事だけではなく今後追加されるであろう記事も自動でデータを抽出できるようにしたいと思います。結論から言うと、すべての記事に関して手順1から手順4をやる必要があるのですが、ここを自動化してみます。

KPIの施策からReportシートへの自動追加のポイント

弊社ではこのような形で、KPIの施策を行なう度にどんな変更をしたかを記述しております。このシートを｢シートno.2｣とします。 f:id:cluex-developers:20151123001205p:plain このシートno.2のA列に記事URLが追加される度に、シートno.1に自動追加されるようにします。(ちなみにシートno.2のB列は空列、C列には変更日、D列には｢変更日前1週間の直帰率の平均｣(の自動で追加)、E列には｢変更日後1週間の直帰率の平均｣、F列には｢変更内容｣を記述するようにしました。最初に入力が必要なのでは、A･C･F列です。)

さて自動抽出のポイントは4つあります。
①必要なデータは、URL全体ではなく、｢/articles/◯◯｣の部分だけであること
②シートno.2には縦にデータを追加していくが、シートno.1では横向きにデータを追加していかないといけないこと
③取ってきた記事IDを受けて、それに応じたfilterとその他の項目も自動的に設定されるようにすること
④設定されたデータをRun reportをしなくても自動でアナリティクスのデータを取得すること
の4つです。それぞれの順に解説します。

①入力されたURLの/articles/◯◯の部分だけ取得する

シートno.2の空白のB列に下記のように関数を入力します。
f:id:cluex-developers:20151123003300p:plain midは、指定したセルから部分的に文字を抜き出す関数です。=mid(A6,20,15)ですと20文字目から15文字を抜き出すという意味です。同じ列全部にコピーして完了です。これでA列に記事URLを添付したら、B列に自動的に記事のIDが抽出されるようになりました。ちなみに、最初の列に=ArrayFormula(mid(A6:A100,20,15))などと入力すれば、下のセルにはコピーしなくても自動で記事IDを取得してくれます。Arrayformulaはかなり汎用性の高い関数なので、かなり便利です。詳しくはこの記事を参考に。
ARRAYFORMULA - ドキュメント エディタ ヘルプ

②縦のデータを横にする

シートno.1の18行目に、①で取得した/articles/◯◯を抽出します。まずは18行目以降のセルが結合されているのでこの結合を解除しましょう。その後に、下図のように関数を入力します。 f:id:cluex-developers:20151123005112p:plain transposeは配列の行と列を入れ替える関数です。=transpose('シートno.2'!B6:B100)とすることで、シートno.2の列Bの6行目から100行目を、シートno.1の18行目に取り出すことができました。(シートno.2に変更が加わったら、この値もきちんと変更されます。)ちなみにシートno.1の17行目の文字とURLはテンプレで表示されているだけなので、消しても問題ないので、削除しましょう。

③取り出した記事IDに応じたデータから、自動的に他の値も入力されるようにする

手順2ではcreate new reportsからデータを抽出しましたが、エディタを経由しないでシートに直接入力してもでアナリティクスのデータを抽出できます。 f:id:cluex-developers:20151123012042p:plain ただコピペではReport NameとFiltersを毎回書き換える必要があるので、以下の関数を入力する。 f:id:cluex-developers:20151123013142p:plain ここで、ifで指定しているのは、｢シートno.1の18行目に何かしらの値があるときにはデータを表示し、何も書かれていない場合には何も表示しない｣ということである。これを指定するのは、新しい記事URLを追加したときにも自動的にレポートのデータが入力されるようにし、何もないときは空白にしておく必要があるからです。3行目から9行目の値は一緒なので、ifを使わずそのままコピペでも良いように思えますが、シートno.2に記事URLを追加した時にまたコピペする手間が増えますし、逆に全部の列にコピペをしておくと Run Reportsをする際にReport Nameがないのでエラーが発生します。そのため記事IDがないときは、他の行も空白でなければなりません。ifで指定したら、同じように右にデータをコピペします。arrayformulaを使用すれば他に入力する必要はありませんが、もちろんこのif関数をコピペしても問題ありません。 f:id:cluex-developers:20151123020216p:plain これですべての記事のデータを取得する準備ができたので、早速Run Reportsを押してデータを取得。(データが多いと取得にすこし時間がかかります。50記事で約30秒程です。) ここでエラーがでる場合や、記事のデータが取得できていない場合は、スペルミスの可能性が高いので、もう一度チェックしてみてください。特に空白が入っているなどのミスは多いので気をつけましょう！

④設定したすべてのデータを毎日自動で取得する

毎回Run Reportsをするのは手間なので、Schedule Reportsより毎日自動で更新されるように設定します。ただし1日に一回更新なので、すぐにデータが欲しい場合はRun Reportsを押してください。

f:id:cluex-developers:20151123021552p:plain ここまでで、｢手順 6 KPIの施策からReportシートへの自動追加関数｣は完了です。ここからは、アナリティクスから抽出した記事ごとのデータをシートno.2に表示させます。

手順7. 抽出したデータをシートno.2に取り出す。

いままではLast N Daysの部分に30と入力し取得日から過去30日のデータを取得していた。毎日のKPIを計るにはこれでも良いのだが、今回は変更日を基準として変更前1週間と変更後1週間のデータが欲しいので、手順6のシートを下記のように変更します。19行目にシートno.2の変更日の情報をtransposeで取り出し、それを受けて変更日の1週間前をデータの開始日時に、変更日の1週間後を終了日時に指定する。(こうすることで、表示データの日付が固定されるので、あとでデータを参照する際にセルの位置情報を指定すれば、変更日の前後の情報を取得できるので汎用性が高いです。)ちなみに1週間の平均を出そうとしているのは、1日だけを選択してしまうと数値にばらつきが生じ、正確なデータがとれないからだ。 f:id:cluex-developers:20151123025053p:plain

これでもう一度Run Reportsをした後に、シートno.2のD列とE列には下記のように入力します。これで変更前1週間前の平均(=average(indirect(B6&"!c16:c22")))と、変更後1週間後の平均(=average(indirect(B6&"!c24:c30")))が取得できます。 f:id:cluex-developers:20151123030606p:plain indirectは、文字列で指定したセル参照を返せる関数です。 しかしindirectとarrayformulaの相性が悪いので、今回はオートフィル(連続データのコピー)をします。 f:id:cluex-developers:20151123184805p:plain これで、ついにすべての記事の直帰率を計ることに成功しました! f:id:cluex-developers:20151123185321p:plain

手順8. 最後直帰率が下がっている記事には色をつけます

E列を選択して、｢条件付き書式｣を選択する。 f:id:cluex-developers:20151123184433p:plain 一週間前の直帰率から1週間後の直帰率が下がっているものには、色をつけるように、下記のカスタム数式を設定します。条件式をカスタムするこで色んなデータを場合分けして色付けできるので、便利機能です。 f:id:cluex-developers:20151123184548p:plain

☆完成☆感想

以上、｢アナリティクスのデータをスプレッドシートに自動抽出してKPIを効率的に計る方法｣でした！長いこと、書いてしまいましたが、わかりづらいことあったらすみません!!スプレッドシートやアナリティクスは奥が深いので、とても楽しいですね!

アドオンで取得できる情報は他にもたくさんあるので、応用すれば色々なデータが自動で抽出&分析ができると思います。今回は直帰率のデータを取得しただけなので簡単でしたが、今後もさらに発展させて複雑なデータ分析をおこなっていきたいと思います。

読んでいただきありがとうございます。同じような境遇の方達の参考になれば幸いです。 清水

データベースの社内勉強会を実施しました！

はじめに

こんにちは、ディレクターの清水です。 現在、cluexにてインターンを始め半年が経ちました。日々の業務としての編集の仕事は一通り身につき、最近では「毎日仕事を改善していく」ということが身についてきた頃であります。

社内勉強会の開催

・mamanokoのリニューアル

mamanoko.jp

mamanokoは10/24にサイトのリニューアルを行い、それに合わせて開発陣、ディレクター陣ともに忙しい毎日を過ごしております。

・忙しさも落ち着かぬころ、

そんな忙しい毎日が落ち着かない中ではありましたが、「社内勉強会」と称して、データベースに関する知識の共有をしてもらいました。 具体的には、posticoを使用した「データベース」の操作について講座を開いてもらいました。

なぜやったか

社内勉強会には２つの良い効果があると思います。

  1. 社内勉強会によって知識の共有を行ってことによるcluexの開発力が底上げされる。

  2. ディレクターも同様に技術的な知識をつけることで、開発とディレクターのリレーションが図りやすくなる。構造や機能に関してある程度の知識があることで、スムーズなコミュニケーションでにサイトの改善点を開発に伝えることができる。

社内勉強会の概要

f:id:cluex-developers:20151101203405j:plain ツール:postico
場所:オフィス
時間:１時間程度
人数:６人
すること:データベースから自分の欲しい情報を呼び出す (今回は、mamanokoにある何万もの記事の中から、View数（閲覧数）の少ない記事を抽出する作業を行いました。 )

学んだこと

今回の勉強会で３つのことを学びました。
f:id:cluex-developers:20151101203620j:plain

1. データベース上で行える行動

SQLという言語で書かれたデータベースでは４つの行動ができます。CRUD(Create, Read, Update, Delete)と呼ばれ、それぞれ「データの作成（Create）、読み出し（Read）、更新（update）、削除（Delete）」を表しています。

今回私たちが行っていくのは、「読み出し（Read）」です。

2. 実際のデータベースの構造

私たちがウェブサイト上で見ている、記事のタイトルや説明文、本文、ユーザー情報から口コミ情報まですべてデータベースに格納されています。実際にposticoによってデータベース内を閲覧し、デーブルの数やテーブル名、その中身が、実際のサイト上での表記とどうやってリンクしているをイメージすることができました。

DB> テーブ >情報 といった感じですべての情報が格納されており、それぞれの情報はエクセル表のように構成されています。行をレコードといい、列をカラムと呼ぶそうです。弊社でインターンを始めてから「カラム」という言葉を３００回くらい聞いてきたのですが、その言葉の意味がやっと分かり、すっきり感が半端なかったです^^

3.データの呼び出し方

select (カラム名)　from (table名)

このようなデータを呼び出すときの文字列（コード）をクエリと呼びます。これは「要求」という意味で、呼び出す行動は「クエリを発行する」と呼びます。これであるtableという集合から、あるカラムの情報を呼び出すことができます。例えば select id from articles とすれば、articles(弊社の場合は、記事情報のtable)から、id(弊社の場合は、記事の番号情報のカラム)を呼び出せます。

さらに select (カラム名)　from (table名) where(カラムについての条件文)

とする条件式を加えることで、取り出した情報をさらに絞ることができます。例えば、　select id from articles where (id < 4000)　とすれば、先ほどのデータから記事番号が4,000以下のものに絞られます。

条件分岐式はいろいろな方法で書くことができます。下記にその基本的な例を２つ紹介します。

① where( id like %5%) これは曖昧分析といって、idに5が含まれるものを抽出することができます。「％」は任意の文字数の任意の文字という意味であり、「54」「2354」「435」など５を含む数字がすべて該当します。

②where( id like %5% and id < 4000)) これはもうおわかりだと存じますが、複数条件を「and」によってつなぐことができます。これによって得られるのは、記事番号が4000以下のもので番号に5がつくものです。またand以外にもorやbetweenなどで複数条件を指定することができます。

今回は上記の条件などを複数組み合わせたクエリを発行し、記事一覧からView数の低い記事をひっぱることができました。

その後

勉強会の後、実際に自分ひとりで「タイトルに”体験談”と付く記事」を洗い出してみました。簡単なものでしたが、その際に使用したコードを以下の通りです。

select * from articles where (title like '%体験談%' )

まとめ

データベース構造をイメージできたのが一番良い経験でした。今後は開発の知識を増やしていくことで、ディレクションの幅も増えてくると感じます。

まだまだ初歩的な内容の紹介になってしまいましたが、社内勉強会様子を紹介させて頂きました！ 同じよう境遇の人たちの役にたったら幸いです。

清水

自己紹介 山田

皆さん始めまして， Cluexでエンジニアとしてインターンを行ってる山田と申します．現在，電気通信大学の学部4年です． 今後，他のメンバーに混ざりながら，少しづつブログを書いていきたいと思います． 何卒よろしくお願いします．

IT大好き大学生

僕はITが好きです． 日常を便利にするスマートデバイスやWebサービスから，アルゴリズムやアーキテクチャをはじめとする計算機科学の体系まで， どれもITの持つ魅力の一つだと思っています． もっとITについて知りたいという思いから，大学では計算機科学を先行しています．
学業の他に，大学のメンバで自作ゲームコンテストに参加したり，スタートアップでエンジニアとしてインターンを行ったりしてます． Cluexは4社目のインターン先になりますが，今まで務めてきた中で，一番，初期段階化から携わらせていただいている会社です． 多くのことを１から行わなければならず，大変ですが，同時に充実したエンジニア生活を送れています．
現在は，CluexをMicrosoft, GoogleのようなTech Companyにするために日々奮闘中です．

ITで世の中をより良くする

CluexのTech Company化と同時に，「ITで世の中をより良く」しようという目標も持っています． 僕は田舎で生活を教育や経済の格差を感じる事が多くありました．日本国内であっても格差はあるのだから，世界であればなおさらだと思います．
しかし，近年はIT技術の進歩から，このような格差が少しずつなくなってきているとも感じています．弊社の運営するmamanokoもまた，そのようなIT技術の１つだと言えます． mamanokoを通して，僕自身も「ITで世の中をより良く」できるよう頑張りたいです．