「ブログ」の記事 - Crieit

自作アプリをバズらせるために８年間やったこと

2023-07-05T08:29:04+09:00

モーショングラフィックスアプリ9VAeをはやらせようと８年間実施したことをまとめました。
https://qiita.com/danjiro/items/3004b6993d3e93e0d3fb

Hugo + GitHub Pages + GitHub Actions で独自ドメインのウェブサイトを構築する

2020-12-10T00:55:08+09:00

はじめに

Zenn や Qiita, note など様々なウェブサービスで記事を書くにつれて、ふと雑多な内容で自分の好き勝手に記事を書いて公開できる自分のブログが欲しくなりました。そこで、自分のブログを作ろうと思い調査したところ、SSG で作るのが手っ取り早そうだったのと、その中でも一番ラクにウェブサイトが構築できそうな Hugo を採用しました。

また、デプロイは簡単に行いたかったので、デプロイ先として GitHub Pages を採用しました。
独自ドメインの割り当てから HTTPS 対応まで無料でできるかつ、使い慣れている GitHub をデプロイ先に使えることが決め手でした。

Hugo で自分のブログを構築して GitHub Pages で公開できるようになったのですが、ブログ内容を更新したり記事を書くたびにビルドしてデプロイをするのが、意外と面倒なことに気づきました。そこで、GitHub Pages action を用いて、ビルドしてデプロイするという作業は自動化しました。

上記までの作業をすることで、自分のブログを書いたり更新することだけに集中できる環境を整えることができました。ウェブサイトを作りこむ以外は、簡単ないくつかの作業をするだけで Hugo で満足のいく自分のブログを書く環境が整えられたので、その手順についてまとめてみました。

ちなみに本記事の手順で実際に作成した私のブログは下記です。
https://nikaera.com/

Hugo を PC にインストールする

私は Windows には Chocolatey、Mac では Homebrew で Hugo をインストールしました。Chocolatey や Homebrew を利用したインストール方法については公式サイトの手順で公開されています。

# Mac で Homebrew を使って Hugo をインストールする
brew install hugo

# Windows で Chocolatey を使って Hugo をインストールする
choco install hugo -confirm

# Sass/SCSS を用いてウェブサイトのデザイン改修を行いたい場合は
# 下記で Chocolatey を使って Hugo をインストールする
choco install hugo-extended -confirm

Hugo で自分のウェブサイトを構築する

Hugo プロジェクトを作成する

下記コマンドで Hugo のプロジェクトフォルダを生成できます。

hugo new site <プロジェクトフォルダのパス>

Hugo のコンフィグファイルのデフォルトフォーマットは TOML 形式なのですが、hugo new site <プロジェクトフォルダへのパス> -f json のように -f オプションを付与することで JSON フォーマットでもコンフィグファイルを生成可能です。

後述しますが、一部の Hugo のテーマはコンフィグファイルのサンプルが JSON ファイルで書かれています。その場合は、新規で設定するコンフィグファイルのフォーマットも JSON で統一しておくと各種設定項目の調整が楽になりそうです。

もしくはこちらのようなコンバーターを使用したり、こちらのようなウェブのコンバーターを使用して、設定ファイルを JSON から TOML フォーマットに変更しても良さそうです。

ウェブサイトのテーマを探す

テーマとは、ウェブサイトのデザインテンプレートのことです。テーマは Hugo Themes で公開されているので、この中から自分の好みを選びます。Hugo ではテーマの内容をカスタマイズしたり差し替えることもできるので、あとから一部デザインを自分好みに修正できます。

Hugo Themes にアクセスした時のページ

お気に入りのテーマが見つかったら、Download ボタンをクリックしてテーマの GitHub URL を控えておきます。

Kiera というテーマのページ

ウェブサイトを作り込む

各テーマには exampleSite というウェブサイト作成の参考になる Hugo のプロジェクトフォルダが存在します。 最初は exampleSite フォルダ内に存在する各種ファイルを自分のプロジェクトにコピー&ペーストして、改変しながらウェブサイトを作り込んでいくとスムーズに作業が進められます。

exampleSite フォルダは大抵 GitHub プロジェクトのルートに存在しているのですが、GitHub のブランチで管理しているものもあります。 私の採用した PaperMod は GitHub の exampleSite ブランチで管理していました。

上記のような詳細は Hugo のテーマページに記載があるはずなので、事前に exampleSite フォルダが配置されている場所や設定可能な項目等をチェックしておくことをオススメします。実際のウェブサイトの見た目を確認するには、Hugo のプロジェクトフォルダのルートで下記コマンドを実行します。

hugo server

hugo server 実行中に、ウェブサイトの設定を変更したり記事を追加すると、自動的にビルドが実行されるので常に最新のウェブサイトの見た目を確認できます。また、その際にエラーもコンソールに出力されるので、適宜修正しながらウェブサイトの作成を進めていくことが可能です。

GitHub にデプロイ環境を整える

ウェブサイトの構築が出来ればあとはデプロイするだけです。今回は GitHub Actions でデプロイするため、残りの作業は GitHub 上で進めていきます。一応 GitHub Actions を使わずに手動でデプロイする手順については、Hugo の公式サイトの手順にて紹介されています。

GitHub Actions を用いてデプロイできるようにした際の利点としては下記があります。

デプロイ時に毎回手動で複数コマンド実行する手間が省ける
自動化することでデプロイ時のコマンドミスを防ぐことが可能
常に統一した Hugo のビルド環境が利用可能

最初のうちは私も公式サイトの手順通りに Mac で手動デプロイしていました。しかし、Windows 環境でデプロイ作業した際、本番環境デプロイ時に SRI 関連のエラーが発生してしまい、ウェブサイトに stylesheet が適用されないバグが発生してしまいました。

結局原因はよく分からなかったのですが、GitHub Actions 経由でデプロイするようにしたところ直りました。CI 経由でデプロイできるようになると、こういった実行環境の違いによる挙動も気にする必要が無くなります。

一応 Windows 環境で発生した SRI 関連のバグは Hugo で該当するテンプレートファイルを layouts フォルダを利用して差し替えて、integrity の設定内容を空にすることで、本番環境でも stylesheet が適用できるようになったことは確認しました。詳細はこちら。

自分のウェブサイトをデプロイするためのリポジトリを作成する

GitHub の公式サイトの手順に従って、自身のウェブサイトをデプロイするためのリポジトリを作成します。また本記事では、Hugo プロジェクトのリポジトリはデプロイ用リポジトリとは別で扱うため、Hugo プロジェクトのリポジトリも新たに作成します。

本記事では Hugo プロジェクトのリポジトリ名は hugo-blog という名前に設定した前提で進めていきます。また作成したリモートリポジトリの情報は、下記コマンドで Hugo プロジェクトに登録しておきます。

# Hugo プロジェクトフォルダのルートで Git リポジトリを作成する
git init

# Hugo プロジェクトのリポジトリ情報を登録しておく (hugo-blog の GitHub URL)
git remote add origin

GitHub Actions で Hugo のビルドからデプロイまでを自動化するための環境を整える

今回は hugo-blog という Hugo プロジェクトのリポジトリから、デプロイ用リポジトリへデプロイしたいため、まずはデプロイ用リポジトリでデプロイキーを登録します。公式サイトの手順に従いデプロイキーを登録したら、秘密鍵を hugo-blog リポジトリのシークレットに登録します。

シークレットは公式サイトの手順に従って登録します。今回は秘密鍵をシークレットに登録する際の名前に ACTIONS_DEPLOY_KEY を設定した前提で進めていきます。

次に GitHub Pages action を導入して Hugo のビルドから公開までを自動化する環境をセットアップします。

hugo-blog リポジトリに GitHub Pages action の Getting started を参考にワークフローファイルを追加します。- name: Deploy の項目のみデプロイ用リポジトリへデプロイするために設定内容を変更します。

# .github/workflows/gh-pages.yml
name: github pages

on:
  push:
    branches:
      - main  # Set a branch name to trigger deployment

jobs:
  deploy:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true  # Fetch Hugo themes (true OR recursive)
          fetch-depth: 0    # Fetch all history for .GitInfo and .Lastmod

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: '0.78.2'

      - name: Build
        run: hugo --minify

    #   - name: Deploy
    #     uses: peaceiris/actions-gh-pages@v3
    #     with:
    #       github_token: ${{ secrets.GITHUB_TOKEN }}
    #       publish_dir: ./public
      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}
          external_repository: nikaera/nikaera.github.io
          publish_branch: main
          cname: nikaera.com

- name: Deploy の項目で設定した各種パラメータは下記になります。

キー	説明
deploy_key	デプロイ時に使用する秘密鍵
external_repository	デプロイ先のリモートリポジトリ
publish_branch	デプロイ先のリモートリポジトリのブランチ
cname	設定するカスタムドメイン名

deploy_key にはシークレットに登録した秘密鍵を設定します。external_repository には Hugo をビルドした際のデプロイ先リポジトリを <ユーザ名>/<リポジトリ名> のフォーマットで指定します。publish_branch はデプロイ先として使用するブランチ名になります。cname には自分が設定したいドメイン名を指定します。cname の詳細はこちらからご確認いただけます。

カスタムドメインで設定した内容で DNS 設定を書き換える

GitHub Pages にカスタムドメインを利用する際は、該当するドメインの DNS レコードの設定で CNAME レコードもしくは A レコードを設定する必要があります。公式サイトの手順に従って設定します。

また、カスタムドメインの設定後は特別な理由がない限りは、デプロイ用リポジトリで HTTPS 強制の設定をしておくことオススメします。

ちなみに GitHub Pages で利用している証明書は Let's Encrypt のものになります。

設定作業はこれで完了です。あとは実際に Hugo プロジェクトを更新後、hugo-blog リポジトリに push することでビルドからデプロイまで GitHub Actions で行われるようになったかを確認していきます。

Hugo プロジェクトの更新時に自動でデプロイが行われるか確認する

Hugo プロジェクトには既に hugo-blog リポジトリの GitHub URL が origin として設定されているはずなので、下記で実際に hugo-blog リポジトリへ push してみます。

# Hugo プロジェクトを hugo-blog リポジトリに push する
git add -A
git commit -m "initial commit"
git push origin main

次は実際に GitHub リポジトリの Actions タブから、GitHub Pages action のワークフローが実行されているか確認します。

GitHub Pages actions の実行に成功した様子

無事ワークフローの実行に成功したことを確認したら、デプロイ用リポジトリの様子を確認します。

デプロイ用リポジトリに Hugo の最新ビルドが push されていることを確認する

最新コミットのメッセージに deploy: <ユーザ名>/hugo-blog@<コミットハッシュ> のコメントが表示されているはずです。コメントのリンクをクリックすると、hugo-blog リポジトリの最新コミットの確認画面に遷移するはずです。

ここまで確認できれば、あとはローカルで hugo server して確認していたウェブサイトと同じように、GitHub Pages 上でもウェブサイトが見えるか実際に確認してみます。

デプロイ用リポジトリ名が <ユーザ名>/<ユーザ名>.github.io であった場合、https://<ユーザ名>.github.io でウェブサイトにアクセスできます。私の場合は https://nikaera.github.io になります。その際、カスタムドメインにリダイレクトすることも確認できれば、カスタムドメインの設定も正常に反映されています。

ページが正常に表示されていてカスタムドメインでアクセスできた様子

アクセス時に意図したページが表示されていることが確認できれば大丈夫です。これで自分のウェブサイトを更新したら hugo-blog リポジトリに Hugo プロジェクトを push するだけで自分のウェブサイトを自動更新できるようになりました。

おわりに

今回は Hugo を例にしましたが、本記事内で紹介した GitHub Pages action は様々な SSG に対応しています。そのため Hugo ではウェブサイトのカスタマイズに限界が来たなと感じたら Next.js や Gatsby に乗り換えるといったことも可能です。

また Hugo では何も考えずとも、マークダウンで記事が書けてビルドも高速なので、手っ取り早く自分のウェブサイトを構築してみたいという用途にはピッタリだと感じました。

関係ないですが、Hugo でウェブサイト構築する際の知見も記事に含めてしまったせいで、文章量が意図した倍近い量になってしまいました。。簡潔で分かりやすい文章が書けるようにならなきゃ。。

参考リンク

今年書いた記事で検索流入が多かった順に考察

2019-12-18T07:24:06+09:00

この記事は write-blog-every-week Advent Calendar 2019 の18日目です。

ということで何かブログっぽいことを書こうと思います。何かアウトプットに関するポエムっぽいことを書こうと思いましたが最近書いたor今後書く記事とかぶりそうなことも多いため、今年書いた記事で検索流入が多かったものをランキング形式にして考察してみることにしました。

アクセス数も書いていますが、検索流入の値です。

ちなみに今年は116記事を書いているようです。平均週2くらいなのでしょうか。自分的には頑張りました。

1位

adbでdevice unauthorizedになって実機デバッグできない場合

トラブルの解決系ですね。しかもこれって原因がひとつではなかったりするので、改善しなかったら次、しなかったら次、と調べていくパターンだと思われます。そのためこういうのは自分がハマった時に書いておけば検索で見つけてもらえる可能性が高いのかもしれません。

書いてから半年くらいで2800アクセスほどです。

2位

Laravel 6 でVue.jsやReactを使う

今年Laravel6がリリースされて、多分元々Laravel Mixを使っていた人が最初に「あれ？」と思って検索するやつですね。新鮮な情報だったからかもしれませんのでそのうちアクセスはなくなるかもしれません。

書いてから３ヶ月くらいで800アクセスほどです。

3位

TypeScriptでVueのクラスを継承する

なんとなくみんなに必要な情報というよりは、ちょっとした時に気づいたチップス系みたいな感じになってきました。アクセスも1月に書いて600くらいとなので3位の時点でだいぶ少なくなっています。

4位

VSCodeのRemote DevelopmentでDocker内のNodeでデバッグしてみた

こちらは半年で500アクセスほどですので、3位のものよりは頑張ってくれているようです。内容はさほど大したものではないのですが、VSCodeはやはりジャンル関係なく皆が使うものなので需要が高いのかもしれませんね。

5位

TypeORMを使ってアプリケーションを作ってみての雑感

こちらは3月に書いて500アクセスほどです。TypeORMはあまり情報がないので気になる人がちょこちょこ見てくれたのかもしれません。

6位

BitBucketからGitHubの無料プライベートリポジトリに引っ越した

1月に書いたもので1年かけてアクセスは500ほど。GitHubのプライベートリポジトリが無料化したのがこの時なんですね。懐かしい。今は完全にGitHubの利用だけになりました。マイクロソフトがGitHubを買収してからガンガン株が上がっていっていますね。

今年GitHubをはじめた人にとっては何の役にも立たないのでどんどんこの記事の需要は無くなっていきますね。

7位

Nuxt.js 2.9をちらっと触ってみた

タイトルの通りの記事です。ほんとにちらっと気になったところを試しただけなのでさほど役には立ちません。アクセスも8月に書いて300ほど。まあニュース的なものなので伸びないでしょう。

まとめ

ということでとりあえず検索流入100位までで調べてみました。Crieit上の記事のため他の人の記事や、あとは去年の記事のほうが強かったりするようです。

というか、こうやって見返してみると全然良作を生み出せていない感がすごいので、ちょっと焦りつつ頑張らなきゃな……、と思いました。

バズることを意識して書くのは疲れるのと上手く行かないことが続くと心が折れてしまうのでとにかく書きたいと思いついたものをどんどん書いていった１年だった気がします。それはそれで気軽に書けて良かったので、無理せず継続して記事を書く、という意味では良かったのかもしれません。

今年はわりとTypeORMとA-Frameで見つけたチップスをどんどん書いていました。多分あまり需要は無いのですが、Qiitaにもほとんど情報がないため勢いを付けて増やせばその情報があるサイトのNo1になれるのでは、みたいなノリで楽しみながら書いていました。

とにかくこの記事の内容はともかく、書きながら色々考えることができたので１年のまとめとしてよい機会となりました。元々全然乗り気じゃない感じで書いたのですが、書いて良かったです。もしよければこれを見た方も年末にまとめの解析をして考察してみると良いと思います。

GatsbyJSで次の記事、前の記事へのリンクを生成する方法

2019-10-08T08:41:01+09:00

オリジナルの記事はこちら

こんにちは。mono（@mono7555e）です。

記事ページで他の記事へ行く術がなく直帰率が高くなっていたので他の記事への遷移を追加することにしました。

ちょっとひと手間かかりますがGatsbyJSでも実現できましたのでご紹介したいと思います。

ページ生成時に前後の記事情報を渡す

exports.createPages = async ({ actions, graphql }) => {
  const { createPage } = actions
  const template = path.resolve(`src/templates/blog.tsx`)
  await graphql(`
    {
      allMarkdownRemark(
        sort: { order: DESC, fields: [frontmatter___published_at] }
        limit: 2000
      ) {
        edges {
          node {
            fields {
              slug
            }
            frontmatter {
              title
              image
            }
          }
        }
      }
    }
  `).then(result => {
    if (result.errors) {
      return Promise.reject(result.errors)
    }
    const pages = result.data.allMarkdownRemark.edges
    pages.forEach(({ node }, index) => {
      const prev = index === 0 ? null : pages[index - 1].node
      const next = index === pages.length - 1 ? null : pages[index + 1].node
      createPage({
        path: node.fields.slug,
        component: template,
        context: {
          slug: node.fields.slug,
          prev,
          next,
        },
      })
    })
  })
}

重要なのはconst prev = ～とconst next ～の部分と、contextでそれを設定している部分です。
それ以外のところは自由です。

設定された前後の記事情報を元にリンクを生成

ちょっとごちゃごちゃしてしまったので前後の記事用のコンポーネントに分割しました。

import React from "react"
import { Box, Card, CardActionArea, CardContent, Typography } from "@material-ui/core"

import Image from "../atoms/image"

const PrevNext = ({ prev, next }) => {
  return(
    
      { prev == null ? null : _link(prev, `prev`)}
      { next == null ? null : _link(next, `next`)}
    
  )
}
export default PrevNext

const _link = ({ fields, frontmatter }, direction) =>{
  return(
    {{ width: `40%` }}>
      
        { direction == 'prev' ? '前の記事' : '次の記事'}
      
      {{ width: `100%`, height: `100%`}}>
        {{ display: 'flex', alignItems: `stretch`, height: `100%` }}>
          {{ width: `35%` }}>
            {{ height: `100%` }} />
          
          {{ flex: `1` }}>
            
              {frontmatter.title}
            
          
        
      
    
  )
}

このブログはMaterial-UIを使っているのでちょっとややこしい感じになりますが、単純にリンクをするだけであればもう少し簡単に書けると思います。

あとは作った前後の記事用のコンポーネントをテンプレートから呼び出すだけです。

// importなどなど
export default function Template({ data, pageContext }) {
  // 中略
  return (
    
      
        {/* その他コンポーネント読み込み */}
        
      
    
  )
}

まとめ

やってみると結構かんたんでした。

今はイメージとタイトルだけですが、タグや日付など各記事が持っている情報を利用できるのでよりリッチな前後の記事へのリンクが設置できると思います。

個人開発したWebサービスをリリースした後にやったこと / やり続けていること

2019-09-02T20:07:33+09:00

どうもきらぷかです。

最近、積んでる本の総額がわかる読書管理サービスをリリースしました!!

リリース後のプロモーションはいつも困っているんですが、
いろいろ試していることをまとめてみました。

これから何かを作ろう、リリースしようとしている人の一助になれば。

やったこと/やっていることまとめ

ざっくりとリリースしてからこんなことをしています!

登録サイトに投稿/依頼
いろんなとこで記事書く
進捗をつぶやく / 使い方とかTipsをつぶやく

1. 登録サイトに投稿/依頼

まずは、いろいろあるWebサービスを登録できるサイトに投稿!!
このあたりに投稿や掲載依頼をしています♪
全部で21サイト...大変なので、すこしずつ...

サイト名	URL
開発会議	https://devtalk.jp/
Service Safari	http://www.service-safari.com/
NewAppPlace	https://www.newappplace.com
SeekUps	https://seekups.seekgeeks.net/
startapp	http://startapp.jp/
Applishow	https://applishow.com/
ツクログ	http://creators.eightbit.jp/
Webサービス集めました	http://webatume.net/
放課後アプリ部	http://houkago-no.appspot.com/
Eggineer	https://www.eggineer.com/
makepost	https://www.makepost.net/
LITFIRE	https://litfire.jp/
NewLaun.ch	https://newlaun-ch.com/
ロケットリリース	https://rrws.info
Apps Times	https://appstimes.jp/
creive【クリーブ】	https://creive.me/
APPLA	https://www.appp.la/
WebFolio	http://websv.info/
WebService Love!!	https://webservice.love/
GOODINNO.press	https://goodinno.press/
WEBサービスまとめてみた	http://webmatome.info/

特に、開発会議には、アップデートを投稿できる機能もあるので、
更新したら登録しておくと、公式アカウントでツイートしてもらえる(´ω｀)
さらに、褒めてももらえる(´ω｀)

積読ハウマッチさん( @MemoryLoverz )さんが読了率/積読率ランキングや、検索の文言を変更しました！少しずつ、気づいたところを改善、機能追加している開発者としての姿勢が素晴らしいです！！ #開発会議 https://t.co/Efn30aFw1h
— 個人開発のコミュニティ『開発会議』 (@devtalkjp) September 1, 2019

各サイトで掲載されるので、それぞれからの流入や検索でヒットすることを期待。

2. いろんなとこで記事書く

主に以下のところでリリース記事や関連記事を書いている。

Qiita: 技術記事
note: 技術じゃない記事
Crieit: 技術記事 / 個人開発記事 / クロス投稿

積読ハウマッチ自体がいまのところ、エンジニアの多いサービスのため、
Qiitaでの記事からの流入が多い。

Qiitaで書いてみて

Qiitaは技術的な記事を書く必要があるので、開発時に困ったことや
開発時に得た知識をまとめておくと、実例としてWebサービスを見てもらえるかも?

また、APIも整備されていてトレンドなどに乗るとTwitterボットが拡散してくれたり、
タグで記事を収集しているボットもいるので、拡散しやすい気がしている。

noteで書いてみて

noteはエンジニア以外の人が多くいるため、新着記事やタグから、
エンジニア以外の愛読家の流入を期待している。

Qiitaに比べ、拡散されにくいが、違う業種の人へ届きやすいと気がしている。
(AbemaTVのときもnoteを見ていただいたっぽいし...)

Crieitで書いてみて

プログラマー、クリエイターが何でも気軽に書けるコミュニティのCrieit。
Qiitaよりラフに色々書けるので、とても書きやすい。ポエムっぽいのでもよさげ。

また、個人開発のユーザが多いため、拡散されやすい傾向がある気がする。
(リリース記事書いたら、いろんなひとが拡散してくれた(´ω｀))

他にはない利点として、カノニカルURLを設定できるので、別のサイトで書いた記事も投稿できる。
はてなブログやQiitaなどをCrieitにも投稿できるので、併用して記事を書くようにしている。
(クロス投稿ばかりがいいのかわからないけど...(-_-;))

3. 進捗をつぶやく / 使い方とかTipsをつぶやく

進捗をつぶやく

開発前も進捗や悩みをTwitterでつぶやいていたけど、
リリース後も引き続き、つぶやいている。

つぶやいていることで、
「これからこんな機能がでますよ!」とお知らせすることで、
開発継続していることとリリース前にコメントもらえることを期待している。

OSSライブラリでもほかのWebサービスでも開発が止まっていると使わないだろうし、
いまは興味なくても、「いま作ってる機能ができてたら使ってみようかな」と思ってくれたらなと。

あとリリースする前に、いい/悪いなどの反応がわかるとリリースまでに反映できるかも知れないなと。

使い方とかTipsをつぶやく

進捗だけでなく、使い方やTipsなども動画つきでツイートしてる。

説明が不足していたり、ぱっと見わかりにくい部分も多いので、
その点を補足する意味合いで使い方を説明したり。

こんな使い方もあるのでは？と思ったこともツイートしてみている。
サイト名だけだと積読がある人しか使えないように見えるけど、
まったくそんなことないので、ログインしなくても積読なくても、
たのしめることを発信していけたらなと。

おわりに

たぶんこれでもまだまだ足りないと思うので、
継続していきながら、いろいろ手を打っていかないと...(-_-;)

個人開発、リリースしてからもやることいっぱい( ﾟдﾟ)!!

とはいえ、定期的にやっておくと、かなり違いが...
いままでは全然やってなかったので...全然...

【PR】積読ハウマッチ! リリースしました!

最近、作った積読用の読書管理アプリはこちら!!
積読ハウマッチ
よかったら遊んでみてください!!

ぜひいっしょに積み比べをヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで〜

プログラミング系ブログがGoogle砲を本気で狙った結果と方法【SEO対策】

2019-08-26T11:29:44+09:00

*この記事は、私のブログでGoogle砲を狙った結果と方法についての記事です。記事自体の内容はプログラミングや個人開発ではなくブログですが、個人開発の方も自分のブログを運営されている方が多いのでクロス投稿しました。

【概要】
プログラミング系ブログがGoogle砲を獲得するために取った戦略とその結果についての記事です。個人的な観点からどうすればGoogle砲が狙えるかの戦略も書いています。

Google砲とは？

Google砲とは、Google Chromeのアプリのオススメ記事の通称です。ブロガーが言っています。スマホで表示されるニュース記事一覧のようなものです。

Google砲で載ると普段の何倍ものアクセスを獲得できるので、アクセス数を獲得したい人には喉から手が出るほど欲しいものです。

Google砲を狙う方法

Google砲の基準は公開されていません。ですからまずはどうやってGoogleがGoogle砲に載せる記事をチョイスしているか考える必要があります。

Google Chromeのオススメ記事を見ると、記事の書かれた日付は新しいものばかりです。そして、多くは企業サイトの記事になっています。早い記事では公開されて数時間で載っています。

ここから推測される仮説は以下のようなものです。

仮説：Googleは記事公開の浅い鮮度があるアクセスが急速に伸びている記事（情報）を載せている

この仮説はGoogle Chromeのアプリ記事がヤフーニュースのような速報性と個人用にカスタマイズされる形であることからもしっくりきます。

そして、この仮説に基づけばGoogle砲の対象記事は

Google Search Consoleに登録されて間も無く
ある一定のアクセス数を超えるサイト記事

となります。

今回は、この１と２の条件を満たす記事を書いてGoogle砲に載ることができるかを実験しました。

Google砲を狙う手順と経過

ここからは私が行ったGoogle砲を狙うために行った手順と経過です。

アイキャッチ画像を設定

Google砲に掲載される記事は、観察するとどれもアイキャッチ画像があります。

ですので、アイキャッチ画像がないサイトは弾かれている可能性が高いです。必ずアイキャッチ画像を設定します。

Google Search Consoleに登録（インデックス）する

もし仮説通りなら、サイト記事のURLをGoogle Search Consoleに登録（インデックス）しないとバズったとしてもGoogleが認識せずにGoogle砲を逃します。

ですから、Twitterなどで宣伝する前に必ずGoogle Search Consoleに登録します。

記事をTwitterで拡散

Google Search Consoleに登録したら、記事をTwitterに投稿します。短時間での集中的なアクセスを個人レベルのブログが獲得するにはSNSしかありません。

あとはフォロワーの皆様に記事が気に入ってもらえることをひたすら祈ります。

今回はこのCrieitからツイートさせていただきました。

Crieitにクロス投稿させてもらいました！#crieit #vue #spa #SEO https://t.co/vAJFnJuWHj
— かとのぼ (@katonobo1) August 21, 2019

経過：はてなブックマークのテクノロジー新着に載る

Twitterでリツイートやはてなブックマークに登録してくれた方がいたおかげで、はてなブックマークの新着にエントリーすることができました。

お！久しぶりのはてなブックマークのホットエントリに載ったぞ。どうやら結構ニーズがあったようだ。Vue.js(SPA)でhead要素のtitleとdescriptionはページ別に設定しよう【SEO対策】https://t.co/74mp78bSiQ pic.twitter.com/wpbLwqcBKl
— かとのぼ (@katonobo1) August 22, 2019

はてなブックマークのホットエントリーに載ったことで、一気にアクセス数が伸びました。

その後も順調にアクセスとブックマークを伸ばします。

そこからはてなブックマークのテクノロジー人気と、総合の新着へ登録されました。

Google砲にエントリーされる

そしてついに、Google砲にエントリーされました。

やりました！

もちろん、仮説が正しいとは言い切れませんが、狙って載ったことは大きいです。

実際どのくらいのアクセスで載るのかの推測

さて実際、Google砲に載るためにはどのくらいのアクセスが必要なのか？ということです。

実は私はこの記事以外にも過去2つGoogle砲に載った経験があります。
(ちなみに、最近も同じ方法でグーグル砲に載りました。
個人開発でアプリやWebサービスをリリースするために必要な知識と技術)

その時のデータも含めて観察した結果ですが

グーグル砲は、Googleアナリティクスで短期間に該当記事に対してユーザー数500を超えた辺りから登録されています。

これは私の技術系ブログのジャンルがこのラインなのか、それとも一般的にこのラインなのかはわかりませんが、私と似たジャンルのブログの方は一つの目安にはなるはずです。

そして、このユーザー数500というのは、テクノロジーのカテゴリーでは、はてなブックマークの総合人気にランクインすると達成される場合が多い数字となります。

つまり、グーグル砲を狙う場合は、まずは短期間ではてなブックマークの総合人気に載ることを目指すと良いと言えます。

以上です。ぜひ参考にしてみてください。

宣伝
ブログ書いています！ブログ
Vue初心者向けのサンプルコード集作っていますサイト

ターゲットを考えてタイトルを考えよう

2019-05-07T21:04:23+09:00

タイトルは文字数も少ないですが、人はそれを見てまず記事を読むか読まないかを決めてしまうため奥が深く、考えるのには意外と時間がかかります。色々とタイトルを決める考え方はあるためいくつかあげてみます。

伝わるかを考える

エンジニアが記事を書くとなると、やはりプログラミングや何らかのソフトウェアやライブラリなどの、人によっては良くわからないワードなどが出てきます。

例えば僕が過去に書いた記事で、Puppeteerについて書いた事がありました。具体的にはPuppeteerでスクリーンショットをとる記事なのですが、例えばそのものズバリのタイトルにすると「Puppeteerでスクリーンショットを撮る」となります。

しかし一つ考えておきたいのが、Puppeteerを知っている人がどれだけいるのか、ということです。

知ってる人からすると「お、面白そう」と感じて見てくれるかもしれませんが、知らない人は「ふーん、なんかのデスクトップ用のよくあるようなフリーソフトかな」と思ってしまう可能性もあると思います。

このように、専門用語や固有名詞をタイトルに入れてしまうとそもそも何の記事なのか、ぱっと見で伝えられない可能性が出てきます。そのため上記の例でいうと僕は「Node.jsでChromeを動かしてスクリーンショットを撮る」のようなタイトルを付けました。PuppeteerよりもNode.jsとChromeを知っている人の方が多いと思ったからです。

ちなみにこの記事はあまり興味を持たれなかったようでさほど閲覧されませんでしたが、とはいえ、適当にタイトルを考えるよりは一度「本当に伝わるのか？」という疑いを持ってタイトルを見直すようにした方が良いのではないかと思います。

誰に伝えたいのかを考える

上記の例で、Puppeteerを知っている人だけにこの情報を伝えたい、ということであればそのものズバリPuppeteerをタイトルに入れる形でも問題ないと思います。Puppeteerを知っている人には有益な記事でも、知らない人には全く価値のない記事の可能性もあるためです。

かならずしも全ての記事が幅広い層に見てもらう必要のある記事ではないと思いますので、ターゲットがあるのであればそちらを優先してタイトルを決めてしまっても良いと思います。

文字数

色々な場所に表示されるタイトルの文字数というのは決まっています。大体30文字までにしておくとどこでも尻切れにならずに表示されますのでそれを意識してみましょう。

また、どうしても長くなってしまう場合は重要な内容を最初の30文字くらいに入れておいて、あとはまあ切れてしまって読まなくても伝わるし、読んでから伝わればいい、みたいな形にしておけばさほど支障はないと思います。

Crieitでは記事入力画面でタイトルの文字数を表示しているので是非参考にしてみてください。

いろんな技を使う

その他、タイトルの付け方は色々なバリエーションがあります。めちゃくちゃ草をはやして気になる感じにしたり、「～～の７つの方法！」のようなものなど、世の中にあふれている多くの記事を参考にしてみると目を引きやすいタイトルの作り方がわかってくると思います。ただ、エンジニア向けのものであればさほどそのようなタイトルの決め方をする必要もないのでは、と個人的には思います。僕は結構余分な装飾をせず、短いタイトルの中になるべく必要な情報を詰め込みたいタイプですので、そういったことはしません。

そのあたりは個人の色や読者のターゲットによるものになりますので、適宜自分にあった形を決めていくと良いのではないかと思います。

すぐに決めなくても良い

記事は最後に投稿する時に決めればよいので、記事の書き始めなどで無理に決める必要はありません。なかなか決まらなければ空欄にしておいて、最後に記事を読み返してみて、そこで考えてみるのも良いと思います。どちらにしろ、決めていたとしても最後に見直して見たほうが良いと思います。

概要を意識しよう

2019-04-26T09:29:15+09:00

記事を書くときは概要、つまりメタタグのdescriptionがどのようになるかを意識しましょう。昔は検索結果に表示される内容としての用途が主でしたが、現在は記事をTwitterなどでシェアした際に本文の一部として表示されるということもあり、有用さが増してきていると思います。みなさんもよく見ると思いますが具体的には下記のようなものです。

画像の下に表示されているのが分かると思います。

Googleの検索結果は人が能動的に探しに行くものですので「実際にページを開いてみるため」の判断材料なのですが、Twitterの場合は「全く考えもしなかったところに興味をもたせる」というところで役割も異なっており、非常に有用なものです。ここに興味を持たせるための内容を詰めておくことがわりと重要だと思います。

長さ

通常、descriptionの長さはGoogleの検索結果に合わせて300文字程度とかがいいという情報があります。もちろんそれはそれで重要なのですが、さらにシェア用の60文字程度には、記事に興味を持ってもらうための内容を詰めておくことがベストだと思われます。

概要の書き方

どの部分が概要として使われるかはブログやサービスによって異なります。

一般的なブログや記事投稿サービスの場合

一般的なサービスの場合、記事の先頭がdescriptionとして使われることが多いと思います。当サービスもその様になっています。この場合、記事の書き出しに自己紹介や最初の一ネタを書きたい場合などがあると思いますが、それだとツイートなどには内容と関係ない概要が表示されてしまいもったいないです。

我慢してまずはdescriptionに載せたい部分を書き、その後に補足として書くようにしましょう。

WordPressの場合

WordPressの場合はプラグインを使ったり改造したりすることで直接設定したりすることができるようになります。そのようにしている場合は本文は自由に書いて問題なさそうです。

困っている人がたどり着ける記事にしよう

2019-04-21T23:42:56+09:00

もしせっかく記事を書くのであれば、その記事を必要としている人がたどり着きやすいような記事にしておきましょう。せっかく問題解決の記事を書いても、その問題で困っている人がその記事にたどり着けなかったり、有用な考察を書いたとしてもそれを参考にしたい人がたどり着けなかったらもったいないです。

エラーメッセージはなるべく書いておきたい

なにかの問題が起きた時に表示されるエラーメッセージは共通言語のため、ブレが少ないです。行番号や変数名がエラーメッセージ内に含まれていれば多少のブレはありますが、それ以外のところは固定文言のため検索で非常にひっかかりやすいです。そのため困っている人がたどり着く可能性が非常に高くなりますので可能な限り記事中に書いておきましょう。

どのように検索されるか想像する

ある記事を書いた場合に、その情報を必要としている人がGoogleでどのように検索するかを想像しましょう。例えば、エンジニアがブログを書きたくなった時、どのように検索するでしょうか？

「ブログサービス」で検索するかもしれませんし、エンジニア向けのものを探す場合は「エンジニアブログ」や「エンジニア記事書く」、「技術記事」かもしれません。「コード書けるブログ」とか、「Markdown ブログ」のように機能を重視して検索するかもしれません。

どれもそのあたりのワードが記事中になければ検索に引っかかる確率が減ると思いますので、記事中でそれぞれについて言及しているのであればきっちりそれらのワードを入れておきましょう。

正式な記事であれば表記揺れをなくしたほうがよいという方もいるかもしれませんが、個人的には問題解決系の記事であれば表記揺れは無視し、むしろ時々言い回しを変えてどんな類似ワードの検索でもたどり着けるようにしてあげた方が親切だと思います。（ある程度はGoogleが吸収してくれますのでやりすぎる必要はないと思いますが）

よくSEOで重要なワードを記事中に何度も出現させてSEO力を高める、のような話も聞きますが、個人的には全く重要ではないと思っています。普通に人と話して問題を解決してあげる時でも、相手が意味を理解していなかったら「どういう意味？」と聞いてくると思いますし、それに対して言い回しを変えて教えてあげると思います。しかし、検索ではそんなインタラクティブなやり取りはできませんので、あらかじめ必要な言い回しは記事中に用意してあげる必要があるのではないかと感じています。

まとめ

とにかく、検索する人のことを考えてあげて、検索する人にとって優しい記事にしましょう。検索している人は、探しているものにたどり着きたいのです。

記事を書くネタの探し方（日常のプログラミングから）

2019-04-15T22:26:25+09:00

いざ記事を書こうと思うと、当然書くためのネタが必要になります。一番簡単なのは自分が普段書いているプログラムからネタを見つけることです。仕事であっても趣味のプログラムであっても、そこで書いたり調べたりしたことは記事のネタになることが多く、一番身近で、且つ既に自分で書いたもののため記事にしやすいです。

つまづいた点を書く

思いがけずエラーが出たりすればそのエラーの内容や、解決方法を書けばあっという間に役に立つ記事が出来上がります。

更に具体的にどういった理由でそのエラーが起きたのか、なぜその解決法で解決できるのか、もしくは現時点では解決方法がないとか、その上で自分で試しに行ってみた方法で一応は動くようになったとか、そのあたりの一部始終を書くことでそれなりの記事になっていきます。

しかもつまづいた点は他の人も困っている可能性があるため需要があります。検索流入を増やす可能性も高くなります。

新しいものを使ってみた話を書く

プログラムを書いていると、実装する機能のために今まで使ったことのないライブラリを使う必要出てくる場合があると思います。特に最近出てきたばかりのライブラリ等だったりすると、まだ世の中に使ったことのある人が多くなかったりします。そういったものは興味を持たれる可能性が高くなります。

普段はあまりそういったものに触れる機会はないかもしれませんので、記事を書くために寄り道をしてプログラムを書いて試していったりすることになるとは思いますのでちょっと大変にはなりますが、どうしても直近で書けるネタが無いときや、自分の趣向的に気になって使いたいと思っていたライブラリだったりする場合にこの方法を取ると良さそうです。

ライブラリだけでなく、クラウドのサービスや、アプリなど、色々なものを触ってみて書くこともできます。

当たり前のネタでも書いてみる

普段のプログラミングの中で、「これは当たり前のことだしいまさら書いてもなぁ…」ということがあると思いますが、それでもどんどん書いてみることをおすすめします。

というのも、自分にとっては当たり前のことであっても、まだその技術に達していない人や、少し普段使っているプログラミングの方向性が違う人からすれば、それはまだ知らない技術だったりすることもありますので、必ずしもそれは「当たり前」とは限りません。

むしろ、世の中の熟練度ピラミッドから想像すると難しいことを調べるよりも当たり前のことを調べる人の方が多いはずですので、気にせず書いてみることが重要となります。

すごく短い記事でも大丈夫

2019-04-12T23:51:45+09:00

記事を書く時、必ずしも頑張って長文の記事に仕立て上げる必要はありません。例えばそもそも、あるエラーに対しての対処方法を書くような記事の場合、無駄に長々と関係のない説明を書いても読むのが辛いだけで本質的ではない場合もあります。ですので例えば、こんな構成の短い記事でも問題ないです。

～～をしていたら下記のようなエラーが出ました。

Error: This is a special error code E2234 (aewfew is undefined)

原因として、～～のライブラリを使っている場合は～～の設定を書いておかないとエラーが発生してしまうため、下記のような設定を追加しておきます。

  setting: true,

こんな感じでも十分です。とにかく書きのこしておいた方が良いかな、と思ったことは短くてもいいのでガンガン記事にしてしまいましょう。もっと深く掘り下げた情報も追記したい、参考となる関連情報も書いておきたい、などがあれば、後で思いついたときにでも追記はできますので。

とくにエラーメッセージはそのものズバリで検索されることもあるので、それと改善方法さえ書いておけば困った人が検索でも引っかかりやすいです。実際に、僕も自分で書いた記事と同じエラーを出して検索し、自分の記事にたどり着いたこともあります。ですので自分のためにも他の人のためにも、とにかく書き残しておきましょう。

プログラムのコードを書こう

2019-04-11T22:44:15+09:00

やはりエンジニアが記事を書くとなるとプログラムのコードを書くことが必要になってくると思います。Markdownであればだいたいコードハイライトに対応しているため、簡単に色付けを実現することができます。

具体的にはバッククォート３つを並べた行で囲まれた行はコードとして扱われます。

1 | ```javascript
2 | function test(a) {
3 |   console.log(a)
4 | }
5 | ```

上記のように書くと（行番号部分は不要です）下記のようになります。

function test(a) {
  console.log(a)
}

最初のバッククォート３つのあとには言語名を書くことでその言語の色付けに対応しています。例えばphp, ruby, javascriptなどです。他にも色々ありますので必要なものがあれば調べてみてください。

注意点

間違えてパスワードや鍵などをそのままコピペして投稿してしまうと危険ですので、そのあたりは適当な文字に置き換えておきましょう。

基本的な体裁 - 見出しと段落

2019-04-10T23:57:02+09:00

Markdownで記事を書く場合、最も基本的であろうという体裁の作り方が二つあります。それは「見出し」と「段落」です。

見出し

↑のように、見出しというのはHTMLでいうh1タグとかh2タグで表現されるもののことです。Markdownの場合、# を使って書くことができます。

# h1
## h2
### h3
#### h4

一般的なブログサービスの場合、h1は記事のタイトルに使われたりします。そのため、記事中ではh1は使わずh2から使い始めたほうが良いでしょう。（ただしサービスによっては自動的に変換してくれたりするものもあるようです）

無駄に改行せず段落を使う

昔は改行をたくさん使って改行芸のようなことをする風習がありましたが、最近はPCとスマホ両方で表示できるようなレスポンシブ対応が標準となってきている関係で、あまり改行は望ましくないものになっています。

そのかわり、Markdown等の場合も改行を二つ連続で書くことで、段落わけを行うことができるようになっています。HTMLで言うところのpタグになります。そのため無駄に改行を使わず、キリの良いところで段落分けして読みやすくする、という書き方にしていきましょう。

とりあえずこの見出しと段落さえ覚えておけば基本的な文章は書けると思います。

プログラム言語やフレームワークのバージョンを書こう

2019-04-09T23:40:31+09:00

技術的な記事を書く時、まずは使ったプログラミング言語やフレームワーク、ソフトウェア等のバージョンを忘れずに書くようにしましょう。

なぜバージョンが必要か

例えば同じPHPでも、PHP5.6とPHP7.3ではそもそもできることが異なっていたりします。

「PHP＋Laravelでこんなライブラリを使ってみました！」という記事を書いていたとしても、それが最新のPHP7.3＋Laravel5.8でしか動かないライブラリだった場合、記事を見た閲覧者が同じことを試して見ようとしても、PHP5.6＋Laravel5.5とかだったらそもそも動きません。なんでだろう…と悩んで時間を無駄に浪費してしまうことになります。

また、「こんなエラーが出たので解決した」という記事を書いた場合も、バージョンによってはそもそも発生しなかったり、解決方法が異なっていたりする可能性もあります。

「何の問題もなく簡単にできました！」と書いたのに、他の人が試してみるとエラーばかり出て全然進めない、GitHubのIssueを見てみると最新のバージョンだとエラーが報告されていてまだ解決していない…なんてこともあります。

どのように書けばいいか

プログラミング言語の話だけであれば最初に「PHP7.3を使っています」とでも書いておけば良いと思います。言語、フレームワーク、ライブラリと、色々なものを使っている場合はリスト表記で書いておくと良いでしょう。Markdownの場合リスト表記は下記のようにアスタリスクやハイフンで記述できます。

* PHP7.2
* Laravel5.8
* Bootstrap4.3

このように書くと

PHP7.2
Laravel5.8
Bootstrap4.3

のように表示されます。

記事は滅びぬ。何度でも蘇るさ。

2019-03-25T08:56:19+09:00

自分のブログにしろ、何かしらのサービスにしろ、記事を書く事の何かしらの経験は多少あるけど、書いてもバズるわけでもないし、そもそも誰かが読んでくれているのかもよく分からなくて全然モチベーションがあがらないという人は結構いるのではないでしょうか？　そのせいで余力やアイデアはあるけど全然書く気が起こらない…みたいな。

僕がCrieitに書いた記事のデータを元に、とりあえずどんどん記事を書く、ということにどういうメリットがあるのかという事を書いてみます。

Crieitはトップページにアクセスランキングがあります。こちらは検索流入のアクセス分も含んでしまっておりそのうち修正したいと思っているのですが、とりあえず現段階でそのランキングの常連になっている記事を参考にしつつ話を進めていきます。
（修正したので今はちょっと変わってしまっています）

コンスタントにアクセスを稼いでくれる例

下記はCrieitリリース前のブログからずっとやけにアクセスされる記事です。グラフはSearch Consoleのもの、つまり検索流入のみの部分です。

CakePHPとLaravelの比較2018

この10ヶ月くらいずーっと同じくらいのアクセスがあり、合計で3,000クリックくらいされています。記事上のアクセス数は検索流入以外も含まれるため、3,600ちょっとになっています。

この記事はバズった事がありません。はてなブックマークもなんだかんだで合計６くらいしかありません。ただ、検索流入では上記くらいのアクセスを稼いでくれています。3000くらいというと、はてなブックマークで軽くバズった時のアクセス数に近いものがあります。また、自分のQiitaに書いた記事のアクセス数を見てみたところ、だいたい20～30いいねくらいで1000～3000アクセスくらいだったため、それ以下のいいねがついている記事よりはアクセスを稼いでいるということになり、そこそこ健闘してくれているようです。

徐々にアクセスが増えていく例

下記は徐々にアクセスが増えていっている記事です。同じくSearch Consoleのものです。

WebエンジニアがPCを買った時に考えたことをまとめてみた

この記事も思いつきで書いただけで誰も読まないと思ったので宣伝もほとんどせず、バズった事がないどころかブクマも全くされていないのですが、なぜか最近アクセスが増えてきて不思議に思っています。検索流入で2,000ちょっと、合計でもうすぐ3,000アクセスくらいになりますので、同じくちょっとバズったくらいのアクセスは稼いでくれています。

古い記事が急にブクマされた例

QiitaがやっているSEO対策を調べてみた

上記は書いた当初は全然読まれなかったのですが、他の方のバズった記事からリンクされることで急に読まれ始めある程度ブックマークしてもらえた記事です。

書いた記事はどういう人が読んでどう使われるかというのが全く想像できないため、場合によってはこういう事も発生するようです。

全ては書いたことからはじまっている

いくつか例をあげましたが、共通しているのは「書いた」というところです。書いていなかったらどの例も発生していませんでしたし、アクセスも合計0です。

書く前に「どうせ読まれないし…」と思わず、とにかく書きたい気持ちがあるのであれば書いてみることが重要だと思います。

バズらせようと思って時間をかけて渾身の記事を書きあげたあとにほとんど反応が無かった時の悲しみは非常に大きいと思います。ただ、諦めずどんどん記事を書いていけば良いと思います。渾身の力で良い記事を書いたのであれば、きっと誰かにとって大切な記事になると思いますので、将来的なアクセス数合計を考えるとバズったくらいのアクセス数になる可能性もあります。

もちろんマイナーな問題解決記事などはあまりアクセスは伸びないと思いますが、それでも同じ問題にぶつかった誰かの役に立ってくれると考えれば感無量です。

記事は一度書いたら死ぬことはありません。ずっと一緒に歩み続けてくれる仲間として共に成長していきましょう。

今年は110記事アウトプットした

2018-12-13T07:08:39+09:00

この記事は write-blog-every-week Advent Calendar 2018 の13日目です。

前日の記事はid:kidani_aさんの#AWS re:Invent 2018 ダイジェスト東京テクニカルセッショントラック2で気になったアップデートの話とかでした。

write-blog-every-week Slackというのは週に１回はブログを書こう、というグループです。そのため今年の自分のアウトプットについてまとめてみました。具体的にどの程度やったのか、どうやってやったのか、どういう結果が出たのかをまとめています。

アウトプット数まとめ

2018/12/9時点で下記のようになりました。（テスト投稿のようなものは含めていません）

Crieitでの記事数…94
Qiitaでの記事数…16

…なんと合計110！？　この記事も含めると111。なかなか頑張ったようです。

純粋な技術系記事の他に、僕の場合ポエム系も多いのでそちらの数もまとめてみました。

Crieitでのポエム数…47
Qiitaでのポエム数…2

ほぼ半分くらいはポエムだったようです。

どうしてできたのか

とにかく気合いです！！

…とまあそれは事実ではあるのですが、大事なのはどうやってその気合いを入れるか、というところになると思います。

僕の場合、2018/5月末にこのCrieitという投稿サービスを公開したのですが、とにかくSEO対策と、書いた記事をツイートすることで集客力をあげ、Crieitを発展させたいという思いから、必死になりとにかく記事を書き続けました。月に大体15記事前後は書いていたと思います。実際にCrieitの記事数のうち、80記事ほどはCrieit公開後の半年ほどで書いたものです。

今年はちゃんと個人開発やった元年だったという記事でも書いたのですが、とにかく僕は集客力もバズ力も恐らく普通の人より弱く、何をやっても全く人が集まりません。そのため、その前例を打ち破り、集客を成功させるにはとにかく努力して育成を行う必要がある、というチャレンジが必要でした。そのためとにかく必死になったことが気合いを入れることができた原動力になりました。

どんなペースで書いたのか

月15記事程度というと、だいたい２日に１回は書いている計算になります。正直、思い出してみてもほんとうにそれだけ書いていたのか、と言われるとあまり覚えていませんし、自分ですらそんなこと無理なのでは？　と思います。できている想像ができません。

恐らく、とにかく思いついたことは全部すぐ下書きをはじめるのではないかと思います。そして、可能であればそのまま一気に書き上げる。そんなに時間をかけて書くということはあまりないと思います。見直しも最低限で、流れもざっと読みにくいところがないかを確認する程度で、かなり雑です。

でも育成ということが第一なので、まずはその記事がない状態からある状態に持っていく、というところが最優先となっています。足りないところや、時間の経過に伴い記事が古くなってしまうところについては後で書き直す、もしくは新しい記事を書く、というスタンスでとにかく雑に、量を増やすことを重視して書いています。

もちろん、その合間にしっかりと書いて公開したい記事なども出てきたりするので、そういったものはちゃんと時間をかけて書いています。

どういうことを書いたのか

主に技術系の記事と、ポエム系の記事です。

技術系の記事

Qiitaにあるような、技術系の記事です。なるべく検索流入が増えそうな、モダンな開発について書いています。

自分が開発中に気づいたりハマったりしたことはとにかくどんどん書きます。技術系記事は調べる事が多いのですが、一度自分で解決したことはもう調べなくても書けるようになっているので、忘れる前に書きます。そして忘れた頃に自分で検索して役立てることもできます。

そのため、普段個人開発で利用する技術も書きたい記事の技術を使うことが多いです。自分がそういうものを使っていくのが好きだから、というところもあります。そんな感じのいわゆる「アウトプット駆動開発」を行っています。

ポエム系の記事

とにかく勢いです。思ったことを、なるべく伝わりやすい文章になるよう一気に書きます。技術系の記事に比べ調べることも少ないので、あっという間に書けます。

とにかく、道を歩いていたり、洗い物をしていたり、寝かしつけをしていたり、思考することだけは自由な時にだいたい色々な考えを巡らせているため、その流れでポエム系記事のネタは無限に生まれてきますし、大まかな構成もだいたい書く前には決まってきます。このサービスはポエム系の内容もどんどん増やしたいため、とにかく思いついたことは時間があればどんどん書くようにしています。

実際に効果はあったのか？

正直まだわかりません。育成が必要なサービスの特性上、短絡的に結果は得られないという認識ですので、多分年単位で頑張っていく必要はあるのではないかと思っています。ただ、目に見える効果は出ているような気がします。

たとえば下記はCrieitを公開してからのSearch Consoleのクリック数、表示回数のグラフです。（Google AnalyticsだとTwitterからの流入のせいで成長度がよく分からなくなるため、そういった流入を省いた検索空の流入のみのグラフ）

このように一応徐々に効果は出ているような気がします。（目盛りは小さいです）

前のブログとの比較

Crieit公開時には、以前はてなブログで書いていた記事を全部Crieitに移動させました。そのため徐々に評価も移り変わっているので、どこかの時点でSEO的な評価は同じになりそこから真のスタートが始まっていると思います。

以前のブログはユーザー数がだいたい１日平均50くらいでした。Crieitは記事の特性上土日にアクセスががっつり落ちるのですが、それでもだんだん100を切ることはなくなってきました。そのため結果から判断する限り、恐らく記事の有用性もそれに伴う集客力も以前よりは上がっているのではないかと感じています。

というか皆さん土日にも外出なんてしてないでプログラミングしましょう！

良質な流入キーワードの増加

最近流行りのJavaScriptフレームワークなどの記事を集中して、もしくは継続して書いたりしているため、それ関連のキーワードによる流入が増えてきています。とはいえLaravel VS CakePHPの影響で、CakePHPのキーワードの需要が高く強すぎるようなので、Crieitのトップページのマンスリーアクセスランキング等を見ると根強く上位に乗ってきます。

今のところの目標としてはこのキーワードが出てこなくなるように、余裕で勝てるキーワードをガンガン増やしていきたいと思っています。

まとめ

よくツイート等でも流れてきますが、とにかくブログで失敗している人の原因というのはほとんど「途中止め」だと思います。そりゃ物理的にも止めてしまって成功というのは不可能ですよね…。とにかく自分のためにも、人のやくにもたつよう、コツコツ継続していくことは重要だと思います。

やる気はあっても本当にこのまま続けていていいのかと迷ってしまうこともあると思いますし、やめてしまうキッカケは多いと思います。正直、やめる時というのは、自分の中で、自分の人生において、それが必要なくなった時なのではないかと思っています。そのため、やめるのは全然問題ないと思います。むしろ、やめて次に本当にやりたいことに向き合うことの方が重要です。

でももし続けることが自分の中で重要なことだと思っているのであれば、なんとか頑張って続けていけたらいいな、と思っています。

明日はid:tadaken3さんです。

書いた記事がバズった時に気をつけていた事まとめ

2018-08-20T08:28:53+09:00

Crieitの7月のまとめでも書いたとおり、7月に等サービスで書いた下記の記事が幸運にもバズってくれました。その時いくつか気をつけていたことがあるので念の為まとめてみます。もし記事を書いてみたい、という方はよろしければ試してみてください。

Vue.jsとHTMLとCSSで3Dアクアリウムを作ってみた

注意

あくまでも気をつけていたことのまとめであり、必ずバズらせる方法ではありません。そもそもちょっと力を入れた記事を書く時はいつも同じことを気をつけていますし、それでもさほどアクセスのない記事がほとんどです。

僕の場合はTwitterで拡散するだけなのでバズるかどうかはほとんど運ですし、その運はTwitterでフォローしていただいている方々の気まぐれがまたたまたま連鎖して呼び寄せた運に他なりません。自分自身に何か記事を広めるための力もTwitterアカウント力もありませんので、同じような境遇の方はやはり同様にほとんど運任せになると思います。

その中で最低限できることをやる、という意味の内容となっています。

あとは全部僕の想像となっており、必ずしも正しいとは限りません。

月曜日に投稿する

記事はとりあえず下書きで書いておき、投稿は月曜日に行います。なぜかというと１週間のうち、下記のような流れが存在している（と勝手に思っている）からです。

金曜日…みんな夜は飲みに行っており、Twitterが過疎っている
土曜日…みんな１日中予定があったり飲みに行ったりしていてTwitterが過疎っている
日曜日…みんな１日中予定があったり平日に備えてゆっくり休んでいたりしてTwitterが過疎っている
月曜日…金～日とみんなTwitterをサボって情報収集も怠っていたので非常に情報収集しごたえがありみんなガッツリTwitterしたり記事を読んだりする

他の平日でも良いかもしれませんが、とりあえず金曜日～日曜日はおすすめしません。

朝早くから投稿する

僕の投稿した記事を見ていただけるとわかりますが、だいたいどれも6:30頃に投稿しています。朝起きて子どもにご飯を上げる前にちゃちゃっと下書きを本投稿してツイートします。ツイート分も前日のうちに作っておきます。

本当は５時くらいがいいです。投稿したらあとは要所要所でツイートしたりして宣伝していきます。５時の過疎っている時間、６～９時くらいの通勤時間、11:30～14:00あたりの休憩時間、このあたりは絶対に外せません。１日の中で一番読んでくれる人が多い時間帯だと思います。恥も忘れてガンガン宣伝していきます。

可能であれば昼休みが来るまでにはてなブックマーク３以上ほしいところです。３以上になればどんどん流入が加速していきます。ただしこの辺は運なので難しいところです。Twitterのフォロワーさんやファンが数千人等と多い方は、こういった流れを作りやすので良記事であればほとんどの記事をバズらせられるのでは？　という気がしています。

上記の時間帯でうまくいかなくても諦めてはいけません。夜もみんなだらだらしていると思いますので、仕事が終わる７時頃、９時頃、１１時頃あたりも狙ってみましょう。日が変わった直後等も良いと思います。

実際前述のバズった記事は、１日目ははてなブックマークも10くらいしかついていなかったと思います。ところが深夜0時くらいの寝る前にちゃちゃっと宣伝しておき、朝起きたらブックマークの増加速度がすごいことになっているという、２日がかりでようやくバズってくれたという流れだったためビックリしました。

とにかくバズるためには加速度が重要ですので、１日を長く有効活用しましょう。夜に適当に投稿して、誰にも読まれないまま終わった…というのは非常に寂しいですしもったいないです。

みんなが興味のある記事を書く

これは当たり前なのですが、やはり自分で思いつく記事を書きたくなるので、結構みんなが興味のあることというよりは、自分が興味を持っていることを書きがちです。なるべくみんなが興味のあることを書くよう意識して考える必要があります。

それにそもそもまずみんなが興味のあることというのは何か、というのがなかなか難しいところだったりします。

興味あるだろうと思って書いても全然反応がない時もあれば、こんなの誰も読まないだろう、というものに反応があったりします。これはどんどん書いて経験を積まないと分からないところな気がしています。

それに技術系の記事であれば、新しい情報は普段からキャッチアップして、実際に使ったりしてみる必要も出てきます。どんどん学習していきましょう。どんな情報が出てきてもすぐに使える、くらいの感じで色々な事になれておいた方が良いです。プログラミング言語含め、サーバーサイド、フロント、インフラなど、より好みせず一通り色々身につけておくと記事を書く幅が広がりますし書く速さも変わってきます。

興味をひくツイートする

記事を書いたらツイートをして拡散しましょう。

簡単なまとめを書く

単にそのままツイートするだけではなく、ちょっとしたまとめを書いておきましょう。そのまとめを読んで全部わかった気になってしまうと記事にアクセスしてもらえない可能性がありますので、微妙に続きが気になる感じにしておくと良いと思います。

画像や動画をツイートする

通常のブログであればあまり記事にも関係のない適当な画像がよく使われていたりしますが、プログラミング系の記事というのは結構記事の内容に関係のある重要で興味をひく画像を貼りやすいです。積極的にぱっと見で興味をひく画像を使っていきましょう。

Crieitの場合、記事内で一番最初に貼り付けられている画像がツイートに表示されます。

あとはツイートに動画を貼るのも良いです。ただ、動画はRTなどには貢献するかもしれませんが、動画がいい感じだとそれだけで満足してしまい記事へのアクセスが減る可能性もありますので、十分事前にどういった形が良いか検討してみましょう。こちらも画像にしろ動画にしろ、続きが気になる感じが良いと思います。

はてなブックマークする

自分ではてなブックマークをするのは問題ないのでやっておきましょう。僕も自分の記事はつけています。

（ただ、運営者の僕が他の人の記事にもつけてしまうとスパムになってしまいますのでどれだけ記事が気に入っても僕はブックマークしません）

追記）
はてなブックマークの新着エントリーに表示されない場合の対処
でも書きましたが、場合によっては表示制限が起こる可能性があります。多分月１程度とかで適当にブログを書く場合には良いのですが、ほぼ毎日ガリガリ書いて全部ブクマをつけていく、とかの場合は自動的になにかの判定をくらう可能性もあるので気をつけてください。

個人的にはブクマ１で大きく何かが変わる事はありませんので、今は付ける必要もない気がしています。

記事をたくさん書く

これが最も重要です。とにかくたくさん記事を書きましょう。常時バズるのはたくさんのファンがいない限り無理ですので、基本的にバズるのは全部運だと思っておいた方が精神衛生上にも良いです。

たくさん書けばそもそも記事を書く練習にもなりますし、前述したような宣伝の仕方含め、色々なことが身につきます。自分にもっと必要なことは何か、日々見えてくるようになります。そして練習を積んでいけば単にたくさん書くよりもバズる確率は上がっていくと思います。そのためたくさん書くというのは何よりも一番大事なことになります。

「練習だからどんどん書かなきゃな～」と普段からツイートしておけば、記事がバズらなくても全然恥ずかしくありませんので！！！

まとめ

以上のように、普段から気をつけていることを色々とまとめてみました。

Crieitで記事を書いていただければ僕も宣伝に協力します。もし自分のブログではあまり集客力に自信がない、という方は、自分のブログに投稿し、CrieitにもカノニカルURLを設定してクロス投稿してみてください。大きな力にはなれませんが、僕も宣伝に必ず協力しますので一人で宣伝するよりはほんのちょっとだけはアクセスが増えると思います。

その際、曜日や投稿時間を前述のような形にしていただければより宣伝効果も大きくできると思います。なんなら下書きだけ書いた状態で予め僕にDMで相談していただいても大丈夫です。

というか、そもそも「記事書いてみたいんだけどどうしたらいい？」くらいの適当な感じで相談を送って頂いても大丈夫です！　僕のできる範囲になりますが協力します。

エンジニアが記事を書くためのブログやサービスまとめ

2018-07-18T06:35:41+09:00

エンジニアがアウトプット等の目的のためにIT系、テック系のブログを作ったり、サービス上で記事を書きたい、という場合があると思います。色々と選択肢があると思いますが、どういったものが良いのでしょうか？　僕自身実際に色々と使ったことがあるので、考察してみました。2020/9時点での考察となります。

特に下記あたりを考察しています。

使い勝手
集客能力

はてなブログ

使い勝手は？

はてなブログは恐らくブログサービスの中ではエンジニアに一番人気のものになると思います。僕も以前使っていました。

markdownで記事が書け、プログラム等のコードもちゃんと書けるので、技術系の記事を書くのには非常に適していると思います。デザインもカスタマイズ可能で非常に使いやすかったです。

有料ですが独自ドメインも使えますし、現在はSSLにも対応しています。

集客能力は？

特別なにか大きな集客能力は無いと思います。基本的には頑張って自分で集客が必要となります。

はてなブログは「スター」があり簡単に「いいね」みたいなことができますが、基本的には何の意味もありません。はてなブックマークボタンも別にはてなブログだけの機能ではなく他でもどこでも使えますし、特別はてなブログだから何か優れている、というところはないように思います。

ただ、記事がヒットすると提携しているSmartNewsにも掲載されたりすることがあるので、自分でうまく集客できる場合には相乗効果で大きなアクセスが見込める場合などがあります。

何にしろはてなブログは色々なところから注目されているブログではあると思いますので、独自でブログを作るよりは集客能力は大きいと思います。

SEO的に良いらしい

SEOで有名な辻正浩さんが下記のような記事を書いていました。

SEOに最適なブログとは？WordPressからはてなブログにした理由 - web > SEO

ざっとまとめると下記のようです。

特に他と比べて異常なまでに優れているということはない（そもそもそういうSEOは今は無いでしょう）
ただしちゃんと最新のSEOの対策に追従しているため、安心できておすすめ

サービスとして運営しているブログだからこそのメリットだと思います。WordPressのような自分で設置する形のブログだとこれはできませんし、上記記事でもSEOのメンテナンスのために時間を費やすことが難しくはてなブログに移行したということが書かれていました。

エンジニア向けの技術系の記事は実際にプログラムを動かしたりして正しいコードか確認したり、色々情報を調べつつ書かなければならないので記事を書くのにも時間がかかると思います。ですのでやはりこういったメンテナンスコストを無視できるというのは大きなメリットであると感じます。

色々総合すると、迷ったらとりあえずはてなブログを選んでおけば良いかな、という気がします。

引っ越しは？

独自ドメインで運用している場合は引越し先のURLを合わせるか302リダイレクトするかできっちり引っ越しできます。はてなブログのドメインで運用している場合はやめたくなっても引っ越しはできません。一生骨を埋める覚悟で使うか、あきらめて記事を残して引っ越す必要があります。

Qiita

Qiitaはプログラミングに関する技術系の記事を書くためのエンジニア向けのサービスです。ブログではありません。

自分が書いた記事をQiitaとして発信する、ということになりますので、全て寄稿する形になります。ただしその分導線がしっかりしているため、自分に集客能力がなくてもそこそこ記事を読んでもらうことができます。

また、ちゃんと記事を書ければわりと「いいね」も付けてもらえ、「いいね」がつくとさらに導線が増えアクセスが望めます。

ブログではないので引っ越しなどもできませんが、特にSEOも考えたくないし、自分の集客力に関係なく記事を誰かの役に立ててもらえたり、気軽にどんどん書いて自分の認知度を広めたりしたい、という場合にはおすすめです。

note

noteは特にエンジニア向けではなくて決まったジャンルもなく、何でも記事を書けるサービスです。有料記事が書けるため、記事を売りたいのであればここ一択だと思います。集客も考えるのであればどんどん自分の記事を増やしておいた方が良いと思いますので、無料記事も普段からnoteで書いておいたりした方が良さそうです。もちろん自分の集客力があるなら有料記事だけnoteで他は他で、でも良いと思います。

エディタは特殊ですが、わりと深く考えずにどんどん文章を書けるので、あう人には非常に書きやすいと思います。プログラミングのコードも一応書くことができるようになっています。

あとは有料ですが独自ドメインのプランもあるようです。

あとはバズったりすると公式のおすすめ記事などで紹介されたりするので、さらにアクセスを増長することができたりします。

Zenn

こちらは2020/9にリリースされた個人開発サービスですが、いくつもの有名なサービスを作った方が開発された、プログラマーのための情報共有サービスです。Qiitaとnoteの良いところを組み合わせたようなサービスで、記事、本が投稿でき、本は有料販売できます。記事についても販売はできませんが、サポートを受け取ることが可能です。

Markdownで記事を書きますが、CLIやGitHubと連携することで好きな環境で執筆することもできるようになっており、まさにプログラマー向けという感じがします。

WordPress

WordPressは自分でサーバーにインストールする形のブログです。とにかく自分でガンガンカスタマイズしたり、遊びつくしたい、改良したい、という場合にはWordPress一択になると思います。

一般的なサービスではないため、集客も100%自分で行う必要があります。また前述の辻さんの記事の通り、何かSEO的に改善が必要な場合自分で調整しなければなりません。WordPress自体のプログラムをいじるか、対応するプラグインを探すか、という形になるのでメンテナンスコストは高いと思います。あとはバズった時にサーバーがしっかりしてなければ止まってしまう恐れもあります。

ただ、やはり「記事を書いて集客する」という目的がメインになると思いますが、そのメイン以外のことに時間を費やさなければならないため個人的にはあまりおすすめできません。何かしらのサービスを使うことがベストだと思います。

本当にカスタマイズが好きな人のみが利用した方が良いと思いますが、真剣に書き始めていき段々と記事を書いたり調整することがメインになっていった場合、あとで後悔する可能性も出てきますのでそのあたりも考えてみてください。

ただ、302リダイレクト等も自由ですので、引っ越しはきっちりできる、というメリットはあります。

Medium

使い勝手など

Mediumは海外製の記事投稿サービスです。自分のブログのように使うことも可能です。結構日本の方も利用しています。

ジャンルは何でもOKです。とにかく見た目が美しく、僕も何か用途があれば自分でもメインで使ってみたいと思っています。そういう部分でファンも多いと思います。

独自ドメインの利用や、最近ではnoteのような収益化の方法もいくつかあるようです。

集客方法は特に無く、適当に記事を書いても一切アクセスはありませんので、自分で頑張る必要があります。

noteは結構Mediumを参考にして作られていると感じます。日本の場合記事を書いた時の集客力はnoteの方が多少大きいと思いますが、Mediumの方が規模が巨大でSEO的にも優れていると思いますので、サービスの集客力に頼らず検索流入なども利用して長期的に自分のブログを育成したい、というのであればMediumの方が良いと思います。

ただ、noteの方が日本でユーザー登録済みの人が多く有料noteの購入頻度は高そうな気がしますので、日本で自分で集客してガッツリ売りたい、という場合はnoteの方が良いのかもしれません。

カノニカルURLの利用

Mediumは記事にカノニカルURLを指定でき、SEO上重複記事とならない形で自分のブログとまったく同じ記事を投稿することができます。ですのでブログは他で書き、記事が目に触れる頻度を増やしたい、という場合はこういった使い方もアリです。

dev.to

こちらも海外のエンジニア向けのコミュニティで、記事を投稿したりできます。一応日本の方も投稿されているようですが、ほぼ英語メインのように思います。

ただ、こちらもカノニカルURLを指定してのクロス投稿が可能ですのでとりあえず自分のブログの記事を投稿しておくのもアリだと思います。

Crieit

Crieitは当サービスです。Qiitaのように記事を書けるサービスです。

作成した意図としては下記になります。
次に作りたいQiita、dev.toの様なサービスについて

Qiitaは基本的にはプログラミング関連の記事のみしか書くことができません。実際にはかなり多くの方が関係ない記事も書いていますが。当サービスはエンジニアが興味のあることであれば何でも書くことができ、質問、議論なども自由に気軽に書けることでQiitaとの差別化を目的として開発しているコミュニティです。よろしければ是非何か投稿してみてください！

また、当サービスも日本ではめずらしくカノニカルURLの設定を採用しており、自分のブログの記事をクロス投稿することができます。とりあえず自分のブログの記事への流入機会を少しでも増やしておきたい、という場合はどんどん投稿していただいて大丈夫です。

個人でやっているためパワー不足ではありますが、開発者や公式ツイッターアカウントにて可能な範囲で記事をツイート等で拡散したりしています。

Qrunch（閉鎖）

こちらも個人の方が運用されている、当サービスと同様のコンセプトを持ったサービスです。ただ、こちらはブログという形態での運用となっています。寄稿形式ではなく自分のブログをちゃんと持ってアウトプットしたい、という方はこちらのほうがオススメです。

まとめ

色々とエンジニアがIT系の記事を書くためのブログやサービスを紹介してみました。どれも少し特徴が違うので、丁度自分にあったものを使ってみると良いと思います。何も決まらなければはてなブログ、記事を売りたいならnote、自分で頑張って育成するのでブログにしてマネタイズもしたいならMediumがとりあえずは良いかな、と思います。無料プランだと記事の価値が各サービスのドメインに行ってしまいもったいないので、有料プランにして独自ドメインでの運用がおすすめです。

これにかぎらず、書いた記事は自分の大事な資産ですので、独自ドメイン運用ができるものはできるだけそのようにしておいた方が良いと思います。そしてカノニカルURLを設定してクロス投稿できるサービスにも投稿しておく、とするとベストだと思います。自分が書いた一つ一つの記事を大事にして価値を高めていきましょう。

追記）
最近エンジニアのブログの書き方の連載を始めてみました。フィードもありますので、これから始めてみたい、という方はぜひ購読して追ってみてください。

連載 - エンジニアのブログ始め方