Wantedlyを支える技術をギュッと１冊の本にして技術書典に出展しました

技術書典というイベントに、社内の技術的ノウハウを集約した”WANTEDLY TECH BOOK”という本を作り、それを出展してきました。

技術書典とは

6月25日(土)に秋葉原の通運会館にて「技術書典」という、技術書オンリーイベントが開催されました。技術書というと一般の書店に流通している出版社の書籍が思い浮かぶかも知れませんが、このイベントでは自分たちの持つ技術を世に広めたい人達や共有したい人達の技術系サークルやコミュニティの技術書が数多く出展されました。頒布される書籍や冊子を見に来た来場者の方も多く、出展者と来場者を合わせると約1400人という大きなイベントでした。

公式サイト：技術書典

頒布した書籍

私達は”WANTEDLY TECH BOOK”という本を150部頒布させて頂きました。内容は社内の技術的ノウハウ、いわばWantedlyを支える技術をまとめたものです。

世の中の移り変わりは早いもので、たくさんの開発手法、プラットフォーム、フレームワーク、ライブラリなどの技術が日々産まれています。しかし、それらは新しいものを学んで、ただ取り込んで行けば良いというものではありません。自分たちのビジネス規模や組織規模などを考えて適切に取捨選択をしなければプロダクトを成長させることはできません。そんな中で、社内の個々のエンジニアが技術について何を思い、何を信じ、どのようにシゴトに活かしているのかを一冊の書籍という形にまとめました。

内容は次のようになっています。

表紙(@yanAoym)

インフラチームが大事にしていること(@koudaiii)
1 Wantedly の文化 ~ Wantedly Culture ~
1.1 なぜやるのか
1.2 Wantedly Way
1.3 インフラチームの文化 ~ インフラチーム / 仕事の進め方 ~
1.4 何を実現するか
1.5 どう実現するのか？
1.6 どう計測するのか？
1.7 仕事の進め方 ~ オフェンスタスクとディフェンスタスク ~
1.8 インフラチームの挑戦
1.9 仕事の進め方 ~ GitHub ~
1.10 技術スタック

Docker 入門(@koudaiii)
1 Wantedly で Docker を Production で使い続ける理由
1.1 Docker を Production で使うのはなぜ？
1.2 コンテナ（Docker） vs VM
1.3 Wantedly ではどこまで Docker を使っている?
1.4 Docker を使い続けるのはなぜ?
1.5 Wantedly では実際にどのくらいやりたいことを実現できているのか?
1.6 これからも Docker を使い続けるのか？
1.7 何があったら Docker をやめる？
1.8 まとめ
2 Docker 入門
2.1 Docker の基本
2.2 Docker を動かしてみよう
3 Docker Compose を使ってみよう
4 Kubernetes を使ってリリースしてみよう
4.1 kubectl を install してみよう
4.2 manifest File を書いてみよう
4.3 実際に Release してみよう
4.4 Release できたか確認してみよう
5 まとめ

実例で学ぶ Microservices(@awakia)
1 はじめに
2 募集検索のランキングで考えてみる
2.1 SQL 世代
2.2 Elasticsearch 世代
2.3 自前の分散エンジン世代
3 フェーズの移行はどうなっていればスムーズか
3.1 どういう API であればよいか
3.2 共通の API の作成
4 おわりに
4.1 実装を関数でなくサーバーに置き換える
4.2 分散エンジンを実装すること
4.3 まとめ

プロダクトマネジメント(@kubonagarei)
1 プロダクトマネジメントとは
2 プロダクトマネジメントを行う上での必要な 6 つの要素
3 なぜプロダクトマネジメントを行う文化を作るか
4 プロダクトマネジメントの文化を育てるために行っていること
5 まとめ

Wantedly で行っているデータ解析と可視化(@tan_z_tan)
1 Code wins Arguments!
2 なぜデータを可視化するのか
2.1 みんながデータを見る習慣がつく
3 Wantedly のデータの流れ
3.1 Rails → TreasureData
3.2 Rails、TreasureData → DOMO
3.3 TreasureData → Rails
4 事例紹介 -MAU-
5 おわりに

アプリのグロースハック(@cattaka_net)
1 グロースハックとは
2 サイクル
2.1 施策を考える
2.2 実施する施策を選ぶ
2.3 施策を実装する
2.4 リリースする
2.5 結果を確認する
3 素早くサイクルを回すためのノウハウ
3.1 データの取得と可視化の構成
3.2 データを取るためのノウハウ
3.3 デザインチームとのやりとり
4 まとめ

なぜ出展したのか

プロダクトの開発をしていると様々な技術に関わります。Wantedlyがこれまでやってこれたのも、それらの技術に支えられてのことでした。個別の技術の設計や実装や使い方は個々の作者やコミュニティの方々がドキュメントを書かれています。でもそれらの技術をプロダクトに適用し、どのように運用しているかは、実際にプロダクトを開発し運用している私達でなければ書けないと思いました。それらの関わった技術の作者やコミュニティの方々に、実際にプロダクトを創って行く中で私達がどのように利用させて頂いているのかフィードバックをしたいと考え、執筆と出展を決めました。

なぜ書籍なのか

現在ではインターネットが普及し、今では沢山の情報が容易に得られるようになりました。開発作業をしていて困ったことがあっても、サーチエンジンで検索すればStack OverflowやQiitaで直ぐに答えが得られる時代です。しかしインターネットで得られる情報には、メンテナンスされてないドキュメントがあったり、それらの間で整合性が取られておらず矛盾していることがある問題があります。それらの問題を踏まえると、まとまった情報を一貫した形で矛盾無く伝えるには１つの書籍という形が良いと考えたため、一冊の書籍という形を取りました。

どうやって書いたのか

Re:VIEW(https://github.com/kmuto/review)という書籍執筆支援ツールを使用しました。MarkdownやWiki、Texのようにテキスト形式で書き、それをビルドするとEPUBやPDF(LaTeX)、InDesign(IDGXML)、Markdownなどの形式で出力できるというものです。Re:VIEWでは本文を複数のファイルに分割できるため、１人１章１ファイルで分担して書きました。

エディタについてはメンバーごとに異なるのですが、私はAtom+language-reviewプラグインを使用しました。language-reviewプラグインを使うと文章中の単語などにWarningを出せるようになるので、文体や文字の統一作業が楽になります。

文章の内容についてはメンバー内でレビューし、修正内容やコメントをPull Requestで送るということも行っていました。

Re:VIEWの詳細な使い方についてはTechBoosterの「はじめてのReVIEW」によくまとめられています。

文章作成のフロー

Re:VIEW自体はRubyのGEMという形で配布されており、Rubyが入っている環境なら"gem install review”コマンドでインストールできます。PDF化するにはこれに加えTeXが必要で、UbuntuやDebianの場合はapt-getでインストールしたり、Macの場合はMacTeX.pkgをインストールする必要があります。

ビルド環境を構築するのが手間な場合は、vvakame氏がDockerイメージ(https://hub.docker.com/r/vvakame/review/)を作成してくれているので、そちらを使用することもできます。

WANTEDLY TECH BOOKのリポジトリでは、文章をPushするとWerckerというCI上で前述のDockerイメージを使用してPDFをビルドし、PDFを入稿用のグレイスケールに変換し、そしてDropboxにアップロードするところまで自動化していました。

Wercker上でビルドに使用しているwercker.ymlは次のようになっています。DROPBOX_TOKENはWerckerの環境変数として渡しています。

box: vvakame/review
# The steps that will be executed in the build pipeline
build:
  steps:
    - script:
      name: build pdf
      code: |
        cd article
        review-pdfmaker config.yml
        gs -sDEVICE=pdfwrite -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray -dOverrideICC -o TechBook-gs.pdf -f TechBook.pdf
    - script:
      name: Archive artifacts
      code: |
        cp article/TechBook.pdf $WERCKER_REPORT_ARTIFACTS_DIR
        cp article/TechBook-gs.pdf $WERCKER_REPORT_ARTIFACTS_DIR
    - script:
      name: upload dropbox
      code: |-
        cd article
        FILE_SUFFIX=`echo $WERCKER_GIT_BRANCH |sed -e "s/\//_/g"`
        mv TechBook.pdf TechBook_${FILE_SUFFIX}.pdf
        mv TechBook-gs.pdf TechBook_${FILE_SUFFIX}-gs.pdf
        sh ../upload_dropbox.sh TechBook_${FILE_SUFFIX}.pdf ${DROPBOX_TOKEN}
        sh ../upload_dropbox.sh TechBook_${FILE_SUFFIX}-gs.pdf ${DROPBOX_TOKEN}

このようにしてできたPDFと表紙のAIファイル(Adobe Illustrator)を日光企画様（印刷所）に入稿し、イベント当日に現地に納品して頂きました。

イベントを終えて

当初、印刷部数をいくつにするのかを非常に悩んでいました。コミックマーケットでは初参加のサークルは50部頒布できれば御の字と聞いていたので、残っても社内メンバーや会社に遊びに来た人に配れば良いかと思い、150部に決めました。しかし蓋を開けてみるとブースの前を通りがかった多くの人が興味を持って頂け、150部全て頒布まで持っていくことができました。興味を持って頂いた方がこれだけ多くいたということは、私達が試行錯誤してることに同じように頑張ってる人達がいるんだとわかり、嬉しく思います。

Twitterの声

さくらのナレッジ様のレポート：日本の技術書コミュニティは熱いぞ！「技術書典」レポート

おわりに

この本には社内のエンジニアには勿論のこと、新しい技術を作り出している人達、プロダクトを創ろうとしている人達、成長させようとしている人達に伝えたいことを書きまとめたつもりです。読者の方々のプロダクト開発において少しでも参考になれば幸いです。また本の内容を実践して「こういった問題があったよ」とか「こうやって解決したよ」とか「こうしたほうが良いんじゃない」などあれば、勉強会などでお会いしたときにお酒でも飲みながらお話ができればと思います。

当日は残念ながら品切れとなり手に入らなかった方が出てしまったことを心苦しく思っています。現在、達人出版会様から電子版をこちらから入手できるようになっています(http://tatsu-zine.com/books/wantedly-tech-book)。ご興味を持って頂いた方には是非手に取って頂ければと思います。