もし武蔵野の若手社員が『Infrastructure as Code』を読んだら

この記事は，武蔵野 Advent Calendar 2017 の17日目の記事です．
@takuma0121，@a_szk と共同で書いた記事です．

TL;DR

• Infrastructure as Code の輪講勉強会をきっかけに，武蔵野のある若手メンバーが勉強会の開催方法そのものを見直した話をつらつらと書いています．
• 先に断っておくと，『Infrastructure as Code』の考え方を勉強会に適用したのではありません．
• 勉強会を始めた当初は，これまでの文化・経験にもとづいて勉強会を開催・運用していましたが，『Infrastructure as Code』の輪講を進めるにつれて，文化・経験に基づく行動が必ずしも最適ではないことに気づき始めました．（はじめから気づけよ，という話ですが）．
• 日々の業務に『Infrastructure as Code』の考え方を応用していくことはもちろん大事ですが，何事にもより良い形があるはずだと考え，手始めに勉強会の開催・運用方法自体に一石を投じてみたお話です．
• 結論としては，下記のような変更を行い，勉強会開催を効率化することに成功しました．
  • 連絡：メール ⇒ チャット（Mattermost）
  • 共有：共有サーバ ⇒ GitLab
  • 資料：パワポ ⇒ .md + HackMD
  • マージ：手作業 ⇒ cat + pandoc

従来の勉強会の進め方

武蔵野では，若手社員が自発的に集まり，論文や書籍の輪講などの勉強会を開催することが良くある．
よくあるパターンでは，本の各章ごとに担当を決め，担当者が資料を作成し，毎週定例で勉強会を開催する．
最後は，全ての資料を閲覧用にマージして，pdfに変換して保存する．
このような作業は，勉強会を開催する際に良くある話だと思う．

• 連絡方法
  • まず，開催メンバー・開催内容が決まったら，キックオフを行う．
  • キックオフでは，会議室を取って，勉強会の進め方，定例開催の曜日・時間，各自の担当する章などを決める．
  • その後は，基本定例で，何か変更があればメールで連絡を取り合う．
• 資料の作り方
  • 資料の作成は，基本的にパワポ(PowerPoint) を使う．
  • 資料作成はパワポ，これは世界の武蔵野の常識である．
• 資料の共有方法
  • 資料が完成したら，共有サーバにアップする．
• 勉強会中の作業
  • 発表者は，パワポ資料で発表する．
  • 聴講者は，説明を聞き，質問する．誤字脱字やミスがあったら適宜指摘 する．
• 資料のマージ作業
  • 最後まで勉強会が進むと，章の数と同じ数のパワポ資料が共有サーバにアップされたことになる．
  • マージ作業としては，全てのパワポ資料を1つのパワポファイルに結合した上で，書式，ワーディングの統一を行い，表紙・目次・所感（まとめ）などを資料本体の前後に追加する．
  • 最後に，pptxをpdfに変換する．

従来の勉強会の進め方の課題

文章にすると，上記の作業は簡単そうに見えるが，実際にやってみると非効率な部分が多い．
『Infrastructure as Code』を読む前の我々が，いかに非効率な方法で勉強会を開催していたかを反面教師として見てほしい．

連絡が辛い

結局，定例通りに開催できるのは，数回に1回．

メンバーの誰かが別の会議が入ったり，年休で休んだり，出張が入ったり，忙しくて資料が間に合わないなど，予定通りの時刻と場所で開催できないことは日常茶飯事．

結局，スケジューラは信用ならない．

予定変更の際は，とりあえず共有のスケジューラから空いた時間にリスケ先を探す．
勉強会は通常業務と比べれば優先度が下がる分，スケジューラで勉強会が会議で上書きされることが良くある．
しかし，共有スケジューラ上で空いているからと言って，本当に予定がないとは限らない．
XX会議（仮）みたいなスケジュールの取り方もあり，本人に聞いてみないと本当に予定が空いているのか分からない．
そもそもスケジューラのUIとUXが．．．

結局，メールする．

スケジューラが信用出来ないので，メールで連絡を取り合ってリスケ先を探す．
ところが，メールでスケジュール調整が出来るのは，頑張っても 2枚のピザで足りる人数 が限界．それ以上は指数関数的に難しくなる．

文章ベースの資料作成にpptxは向かない

説明資料は，基本的に文章中心

少数の図や数式があるだけで，それも原著の図をスキャンすることが多いので，オリジナルな図を作る必要はあまりない．

資料のページが増えやすい．

パワポでは文字サイズが18pt以上になるため，必然的にスライド枚数が増えていく．
各章が20スライド程度だとしても，マージ後の完成した資料は500ページを超える．
スクロールで腱鞘炎になるレベルで，後から誤字脱字をチェックするのも辛いし，お世辞にも読み直そうとは思わない．
作者でも読み返さないとしたら，第三者は絶対に読まない．

pptxは共同編集ができない

誤字脱字修正・加筆は後で絶対にやらない

人間なので，各章に1つ以上は誤字脱字があるが，それを逐一説明中に指摘しても，都度全画面表示を解除して修正するのは非効率で説明のテンポも悪くなるため，現実的ではない．結局，後で治すことになる．
しかし，人間なので，だいたい，発表が終わった10分後には全て忘れる．

学びが共有されない

質疑応答や議論は当然生まれ，それは有意義なものであるが，それがその場限りとなる．そのため，詳しいメンバーの補足情報や知見なども，当然のように資料に残らない．
本来，輪講や勉強会は，質疑応答や議論の内容にこそ，価値がある（本は一人でも読める）．
最後のマージ作業の際に，所感を追加しようにも，勉強会で何を話し合ったかあんまり覚えていない．結局，作成した資料を改めて全部読むことになる．

マージが辛い

マージ作業が一番辛い

例えば，O'Reillyの本は少なくとも20章以上あることが多く，最終的に20個以上のpptxをマージする必要がある．
全てのパワポ資料を開きながら，コピペを繰り返す作業を行う．
共有のテンプレートなどは使用するものの，全員が微妙に違う資料を作成してしまう（例えば，2章：Hoge，3章 Hoge，4. Hogeなどなど．）．作業中に気になりだして，ドツボにはまる．

誤字脱字が見つかる

前述の通り，誤字脱字は放置されるのため，あとで手分けして修正する必要がある．
500ページ以上のスライドに絶望しながら，四半期末の一番忙しい時期に泣きながら校正作業をすることになる．

目次の作成は温かみのある手作業

例えば，23章が何スライド目から始まるは数えるしかないので，温かみのある手作業で確認して，目次にページ番号を手入力することになる．（もっと良い方法はあるとは思う．）

OS依存性

WindowsとMacで図の形式が合わないなどの微妙な差が生じ，温かみのある手作業で再確認 することになる．Mac側でPDFトリミングで貼り付けた図は，Windows側でもれなくずれるので気をつけてほしい．

最低なバージョン管理

共有サーバで競合が発生し，読み取り専用で開くかどうかを毎度のように常に聞かれる．
そうこうしているうちに，誤字脱字チェックをしたファイルと修正したファイルがどちらか分からなくなる．もちろんファイル名でバージョン管理するが，絶望的な状況（2章_xx_marge_ver.3_誤字脱字チェック済み_r2.pptx）にならないはずがない．図は実際の状況だが，まだマシな方だと思う．

現在の勉強会の進め方

連絡方法

• 基本的にチャットサービスのみを使用．
• 社内情報を共有することもあるため，slackではなく社内サーバにたてられるmattermostを採用した．
• 組織全体でスケジューラの運用を統一かつ徹底すればよいのだが，勉強会以外のメンバに運用などを徹底することは難しいため，個人間の連絡手段は必要である．
• 連絡するときは必要最低限の情報，定形メンバへの情報共有であるため，件名・署名・アドレスなどが必要（または自動付与）されるメールは適切なツールではない．

資料の作り方

• 全てmarkdown形式で作成．
• ほとんどが文章であるため，テキストベースの情報を共有するファイル形式が望ましい．
• テキストベースの情報であるが，画像を入れることもあるので，.md形式を採用した．
• .pptxはテキストベースの情報を共有するファイル形式ではない．
• テキストベースでないと，バージョン毎の差分が分からない．

資料の共有方法

バージョン管理もしたいので，gitlabを採用．

mattermost連携も容易なので便利．

勉強会中の作業

• hackmdを使った共同編集．
• 同時編集機能があり，かつ.md形式と親和性が高いhackmdを採用した．
• 誤字脱字などの細かいミス，質疑応答の内容，知見や気づきなどは気づいた聴講者が適宜加筆・修正する．
• これまでの勉強会は発表者が資料を作り，発表し，誤字脱字などの指摘事項を直すという方法を取っていたが，聴講者も口出しだけでなく手を動かす形で勉強会に貢献できるのではないかと考えた．

資料のマージ作業

• 実はここまで改善した内容でマージ問題は全て解決している．
• 勉強会の各章の最新バージョンをcatして，pandocでpdf変換．

改善効果

スケジューラ＋メール ⇒ チャットサービス

• チームメンバ全員から，スケジュール調整の負荷がなくなったとの声をいただいた．
• 副次的な効果として様々な情報共有，質問などが活発になった．
  • 技術アイデアを共有しやすい．
  • 参考URLや関連資料も簡単に共有．
  • 勉強会に関係なくても，仕事のことを質問・相談しやすくなる．
• このカレンダー執筆のアイディアも，チャット中に生まれた．

pptx ⇒ md形式+hackmd

• 数式，資料の構造化，引用，URL，．．．全てにおいて早い．
• 資料作成中に，パワポが落ちて泣くこともない．
• windowsで作成して，macで見てもオブジェクトがずれたり，フォントがおかしくならない．
• 発表しながら全員でリアルタイムな誤字脱字修正，ディスカッション内容を追記することで，各章の勉強会資料は勉強会終了時に完成するようになった．
• 発表者は発表に集中できるようになった．

pptxマージと履歴管理 ⇒ cat, pandoc, gitlab

• LuaLaTeXを経由させて，勝手に目次も作れる．
• コマンド1つでマージできるため，何度マージしても苦にならない．
  • CI回せばマージ作業も自動化される．
• 最新版がすぐにわかる．

PDF作成コマンドはこれ．catもpandocがやってくれる．

pandoc sre_*.md -o sre.pdf --latex-engine=lualatex -V documentclass=ltjarticle -N --toc

GitLabのGraphはこんな感じ．コンフリも勝手に処理してくれるので楽ちん．

最後に

• 用途に応じて適切なツール，考え方を取り入れることが重要である．
• 個人の仕事の進め方を変えるのであれば，個人でツール等を導入すれば良いが，組織全体で仕事の進め方を変えるのは難しい．
• 今回の勉強会で進め方を変更できた理由は，
  • 2-pizzaチーム以下の人数だったから．
  • 初めから有るべき論を語るのではなく，ミニマルスタートから少しずつ成功体験を積み上げたから．
  • 最初から使用するツールを決めるのではなく，開催しながらツールや進め方を柔軟に変更していったから．
• おそらく，今後も進め方やツールは随時変わっていくと思われる．