執行役員 VP of Engineering 兼技術部長の @hsbt です。先週発売したモンスターハンターストーリーズ2をプレイしながら、「ティガレックスじゃなくてナルガ亜種出てよ〜」という感じにオトモンの卵探しに時間を費やしています。
今回は「ペパボさんには〜はありますか?」シリーズの第二弾として「ペパボさんではテックブログの執筆方針などはありますか?」という質問をもらったので、GMOペパボ(以下、ペパボ)でのテックブログの運営方針をこのエントリで紹介したいと思います。(第一弾は GMO ペパボでの Slack の使い方 2021 - ペパボテックブログ です)
運営方針
ペパボテックブログは 2015年11月17日にスタートしました。当時の執行役員CTO、現取締役CTOの @kentaro が書いたテックブログ開設の目論見について引用します。
日々の業務から得られた知見を少し立ち止まって振り返り、より一般化して考えてみる、その結果としてアウトプットするということが、エンジニアとしての成長には必要です。そのため、業務ロジックから一般化したライブラリをOSSとして公開すること、社内外の技術イベントで発表することなどを推奨しています。 このテックブログもまた、そのような活動の場となり、エンジニアの成長の一助となることを期待しています。
スタートから約 6 年が経過した今も上記の方針は変わっていません。テックブログを読んだ方がペパボの一員になりたいと採用につながるための窓口となれば幸いですが、それ以上にエンジニア一人一人が毎日の業務の中で得られたインプットを社外に向けてアウトプットを行い、そのフィードバックをインプットとしてより良いアウトプットを生み出す循環装置として、現在もテックブログを運営しています。
質より量
テックブログの運営にあたって、他社の事例を見ていると継続して書き続けることについて運営担当としては不安が多いように思います。ペパボでは、執筆担当を恒久的な交代制としたり、上司からの指示として書かせるということは行っていません。テックブログはアウトプットを通した自主的な活動の結果としてのエンジニアの成長を支援する場とし、読者にとって何かしらの学びを与える記事を書くということだけを、技術的なクオリティ確保の最低限のルールとしています。
また、テックブログの執筆に関しては、「こんなことをテックブログに書いてもいいんだろうか」という質問を社内からよく不安の声として聞くことがありますが、その度に私は「質より量!とにかく書いて」と後押ししています。エンジニアのような専門職は誰もが最初からシニアレベルではありません。例えば、単純な CSV をパースする方法のような、言語に添付されているライブラリを使えばおおよその問題は解決できるというようなものであっても必要としている読者はいるはずです。シニアレベルにとって役に立つ記事だけを書く、というわけではなく誰か一人でも役に立った、勉強になったというように行動を変えることができるアウトプットをしていこうという方針をとっています。
業務として書く
テックブログの執筆については、社内では業務扱いとしています。ただし、我々エンジニアはテックブログのエントリを書くだけが専門職としての専門性ではないので、プロダクトを開発したり、目の前の課題を解決することを前提として、業務時間中に裁量を持って執筆を行っています。
しかし、質より量、という前提であっても、業務として書く以上は手元のメモ書きというレベルではなく、日本語や技術記事として相手に伝えるように書く必要があります。そのために私やシニアエンジニアリングリード、またはエンジニアリングリードがレビューを必ず行っています。幸いなことに、ペパボには商業誌への寄稿経験があるエンジニアが多数在籍しているので、その際に本職である編集者の方からもらった技術記事の執筆ルールを踏襲して記事のクオリティアップを図っています。なお、私は技術評論社の稲尾さんから教えていただいた執筆ルールをベースとした指摘をすることが多いです。
徹底的に自動化する
ペパボテックブログは SAML を用いた SSO サービスの認証を必要とする GitHub Enterprise Server 上のリポジトリに Middleman を用いて原稿を管理し、pull-request を用いて原稿のレビューを行い、master ブランチへマージ後に github.com の GitHub Pages として公開されるという執筆ワークフローを用いています。
Middleman を選んだ理由はスタート当時に Jekyll にするか、WordPress などにするか複数の選択肢の中から選んだ結果ですが、Ruby を用いてやりたいようにできる点が 2021 年現在でもメリットのため特に変更せずにそのままにしています。記事が増えてきてビルド時間が長いという気もしますが、CI でビルドに要する十数分よりも執筆や推敲に使う時間の方がはるかに長いので気にしていません。気になるようになった時点で、別のソフトウェアへの置き換えやワークフローの見直しを行おうと思います。
文章校正の自動化
今現在は 校正支援 - Yahoo!デベロッパーネットワーク の API を用いて機械的に指摘する方法を GitHub Actions の CI と連携して行っています。今後は ことばのデザインが体験を形づくる｜mewmo｜noteで紹介されているような Kindaichi プロジェクトの成果物との連携や他社から出ている textlint ルールセットを組み合わせて使っていく予定です。
画像最適化の自動化
画像ファイルを入れるときに数MBのサイズの画像を手元でサイズ調整をするのは、執筆のモチベーションが高まっているときには巨大なブロッカーになります。そのために執筆に集中できるように以下のような GitHub Actions のワークフローを用意して、コミットされている画像ファイルを 1200x1200 ピクセルの長辺に合わせるようにリサイズした上で画像サイズの圧縮化を行なっています。
name: Optimize image size and quality
on: [pull_request]
jobs:
image_optimize:
runs-on: self-hosted
container: xxx # poetry, zopflipng, jpegoptim を含む Docker のイメージを指定する
steps:
- uses: actions/checkout@v2
- run: poetry install --quiet
- run: |
URL="https://xxx/api/v3/repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files"
FILES=$(curl -s -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" "$URL" | jq -r '.[] | .filename')
echo "$FILES" | grep "(jpg)|(png)" | xargs poetry run imgp -x 1200x1200 -w
echo "$FILES" | grep png | xargs -I{} zopflipng -y {} {}
echo "$FILES" | grep jpg | xargs jpegoptim -q
- uses: EndBug/add-and-commit@v7
with:
message: "Optimize image files"
上記の方法はプロトタイプに近い雑な作りなので、コミット毎に画像圧縮が実行されることに先日気がつきました。コミットされた最後のファイルリストに画像ファイルがあったら、というように条件判定を変える予定です。
まとめ
前述した画像の最適化はいい例ですが、他にも数年前に導入した AMP 対応など、「これをやるとアクセスが増えるらしい」「表示が速くなるらしい」というような技術を雑に試す場としてもテックブログを活用しています。AMP 自体はそろそろ役目を終えようとしていますが、発表当初からいち早く導入したことが功をなしたのか、「テックブログ」で検索を行うと検索結果上位には登場するようになりました。
現在、毎週1-2記事を投稿することを目標に、自分自身が率先して記事を投稿していますが、社内では「これテックブログに書くといいよ」というような後押しや、テックブログにこういう反応があったというような共有も積極的に行なっています。技術を用いて課題を解決し、その内容をアウトプットすることで、自分以外の人にも学びを共有し、自分も新しく学ぶ、繰り返しになりますがこのようなサイクルを高める場として今後もペパボテックブログを運営していきたいと思います。