この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
中山（順）です
今回は、インフラ運用（？）勉強会としては老舗のssmjpに参加してきました。 そのもようをお届けします。
なお、今回は「Outputする人だけが参加出来る」という縛りがあります。 その掟に基づき、本記事を執筆します。
ssmjpとは
一応はインフラ運用（？）勉強会と銘打たれていますが、一言で言うとなんでもありの勉強会です（個人の見解）。 私が聞いたことあるプレゼンの中で一番インフラ関係なかったのはカリオストロの城の話でしょうか。 ガチでカリオストロの城の話でした。 そのあたりの詳細は勉強会冒頭の @tigerszk さんの前説を聞けばわかるので、是非参加しましょう。
本日の会場提供
本日は虎ノ門ヒルズにある NHN Japan 様のオフィスでの開催でした。ありがとうございます！
CloudGarageとは
冒頭で NHN Japan 様より、CloudGarageのご紹介がありました。
以下のような特徴を持ったIaaSサービスとのことです。
- 定額制
- 1380円～
- 高速、高性能
- ストレージはローカルSSD
- 簡単に利用できる
- シンプルな料金体系とUI
ブログでの情報提供も行っているとのことなので気になる方はご覧になってはいかがでしょうか。
前説
ssmjpでは、初参加の方が一人でもいると前説が行われます。
本日はアウトプット縛りなので全員参加経験あると思われていましたが、一人だけいました！ ということでビットがたったので、本日も前説が行われました。
内容については割愛します。 気になる人は参加しましょう。
「@tigerszk先生のクソコラが見られるのはssmjpだけ！」
突然のLT
で、本編に入るかと思いきや、ここでtigerszk 先生によるLTが始まります。 タイトルは「クソコラ3分間クッキング」。
ご本人は「このLTはアウトプットいなくていい」とおっしゃっていましたし、割愛します。
「@tigerszk先生の(ry」
本日のセッション
本日は以下の4セッションが繰り広げられました。
「JAWS-UGコミュニティ運用とSSMJPとの比較あれこれ」 - @Typhon666_death
概要は以下の通りです。
JAWS-UGはAWSのユーザーグループコミュニティです。JAWS-UGには全国に複数の支部が存在しますが、このうち、私がメインで運用に携わっているSecurity-JAWSとX-Tech JAWSの運用で気をつかっていることや、SSMJP勉強会の運用について、個人的主観であれこれ比較してみます。比較してみたものの、正解を導くことのできない課題については、ぜひアウトプット頂く皆様にもご検討頂きたいところです。
@Typhon666_death さんは OWASP Japan などの運営にも関わっていて、ssmjp での登壇は7回目とのこと。
JAWS-UGの紹介
まずはJAWS-UG自体の紹介です。
- 多くの支部で構成
- 都道府県別
- 海外支部も（シンガポール、オランダ）
- 専門支部も多数
- JAWS DAY
- 年1回の大型イベント
- 今年はOWASP Japan のメンバーで登壇した
- Slackもやってる
Security JAWS
@Typhon666_death さんが運営に関わる支部の1つであるSecurity JAWSの紹介です。
- 文字通りセキュリティがキーワードの専門支部
- 第1回目は40人のキャパでキャンセル待ちが150人
- @tigerszk 先生も登壇（AWS上のシステムに対するペネトレーションテストについて）
- 明後日もやる
X-Tech JAWS
@Typhon666_death さんがリードするX-Tech JAWSの紹介です。
- Fin Techなど、特定の業界での活用などがテーマ
- X-Tech（クロステック）とxTech（エクステック）の違い
- ASCIIでも取り上げてもらった
ssmjp
比較のため、改めてssmjpについても紹介。
- 「愛されてる」勉強会
- Slack活発
運営比較
非常に多くの観点で3つのコミュニティを比較されていました。 個人的に気になった点を太字にしています。 詳細は公開されている資料をご確認ください。
- 参加者数
- 一番若いX-Techでも600人強
- リーダー
- 開催頻度
- JAWSの勉強会を月一はしんどい（参加者多いし）
- １回の登壇者
- ジャンル
- 配信
- X-Texh JAWSではChimeでやってる
- 地方の方には喜ばれる
- 海外から視聴されているケースも！
- 前説担当
- 前説内容
- Security-JAWSは名刺交換とかやってる
- 運営メンバー数
- メディア
- JAWSでは、主にアスキー（大谷さん）さんに声かけてる
- 創設の歴史
- Slack
- コラボ回数
- ssmjpは運営メンバーの持ち込み企画
- コラボの決まり方
- 登壇者オファー方法
- 仕事や展示会、他の勉強会などで知り合った方を誘う
- オファー時の観点
- 過去最高収容人数
- ドタキャン率
- JAWSはssmjpより高い傾向
- すごく課題
- 良い解決/改善案があったら知りたい
- JAWSはssmjpより高い傾向
- 困ってること
- X-Techは登壇のオファー先探し
- 金銭問題
- X-Techで無償／有償でやるべきか揉めたことあり
- マニフェスト
- JAWSは用意されている
- GitHubで公開
- ssmjpも登壇者向けのガイドラインはある
- JAWSは用意されている
- 大規模参加者
- JAWS DAYS
コミュニティに関わって変化したこと
当初は参加するだけだったが発表したくなって知的な便秘が解消、コミュニティ運営も行うようになってからは以下のような効果が得られたとのこと。
- 登壇者の調整で先の情勢を知ろうとするようになった
- 仕事にも生きるようになった
- Give & Takeの連鎖
- Giveする力がOutputへの連鎖へ
- 知名度アップ
- 社内で知られる（だが、俺はおまえを知らない！）
- DevRelやっていきたい
まとめ
「（コミュニティの）マネジメントするとむしろ快便やん？」
宣伝
今年度のJAWS DAYSは2019/2/23@五反田とのことです。
質疑応答
- Q：適正な参加者人数ってどのくらいなのか？
- A：（主観だが）80-100くらい
- レトロゲームのコミュニティーは20-30くらい
- 「JAWS -UG CLI専門支部は？」※ハンズオン中心の専門支部 > 10-20人くらい？
- 「40代のおっさんが参加者の顔を覚えられるくらいがちょうどいい」by はたのさん
- 初期のJAWS-UG東京は参加者が200－300位で、運営大変だったらしい
このほか、少人数ならではの双方向なやりとり（というかほぼ会話）が行われていました。
資料
感想
名刺交換の時間を設けている点がすごくありがたと思いました。 私はかなりコミュ障なのでこういうのは本当に助かります。 実際、参加して話を聞いているだけでは得られるものって少ないですよね。 本当に知りたいことは、失敗談やいまいちな仕様の話（とそれをどう乗り越えたか／躱したか）ってこととかだと思うんですが、それをプレゼンテーションだけで聞けることって希だと思います。 参加者や登壇者と直接コミュニケーションを取れないと聞けないことは多いと思うので、こういった施策をきっかけにしていろいろ聞けるといいですね。
登壇者探しも共通の知り合いがいれば頼みやすいですが、そうでないとなかなか難しい課題だろうなーと想像できます。 弊社クラスメソッドのお客様には先進的な取り組みをされているところも多いので、（エンジニアを採用して内製したい場合は）積極的にアウトプットしたら採用にもつながるかもしれないと思うんですが、実際どうなんでしょう？
あと、ドタキャン問題は難しい問題ですね。 弊社で主催するAKIBA.awsでも同様の問題が発生していて、無償の勉強会が飽和している首都圏では割り切るしかないのかなーと思ってしまいました。
Promotion of SphinxCon JP 2018 - @usaturn
次はSphinx Conの紹介セッションでした。
Sphinxユーザ会会長であるusaturnさんがSphinxConの宣伝をします。
- Sphinx とは
- ドキュメンテーションツール（メンテナはコンバーターと呼ぶ）
- reST （プレーンテキスト）などをインプットとして、各種フォーマットに変換できる
- 例：reST > HTML
- マルチインプット、マルチアウトプット
- 各種ツールのドキュメントの生成でよく使われている
- 現在、メンテナは日本人が多い
- Sphinx のデモ
- sphinx-quichstart
- テンプレートを生成
- reSTを編集
- make html
- 指定したフォーマットへ変換
- テーマの変更
- sphinx-quichstart
- Sphinx Con
- 年1回のカンファレンス
- 今年で6回目
- 昨年はDeNAさん会場提供
- SphinxCon JP 2018
- sphinx-users.jp
- 本の執筆や翻訳ハッカソンなどのいろんな活動を継続中
感想
クラスメソッドにジョインしてからは使う機会がなかったのですが、以前は手順書の作成に利用していました。 体裁はテーマにお任せでコンテンツの作成に集中でいたので、すごく好きなツールです。 クラスメソッドにジョインする前にSphinxで作った運用手順書は「メンテナンス」されてるかなーと、ふと思いました。 弊社内でもお客様向けのマニュアルや仕様書の作成で利用されているので、機会があればまた業務でも使いたいなーと思いました。
「正しい」運用手順書を作る - @tcsh
ssmjpではお馴染みの波田野さんによる「正しい」運用手順書についてのLTです。
- 問題提起
- みんな大好き「運用自動化」
- でも、みんな「運用手順書」は苦手
- 運用自動化と運用手順書
- 運用自動化とは「運用業務を定型化して実装すること」と定義した
- 定型化と自動化には大きな壁がある
- 自動化には高い実装能力が求められる
- 定型化をスキップすると仕様バグががが
- 定型化＝手順化が重要
- 今回の資料は「ネオ運用手順書友の会」の議論でブラッシュアップされた
- 正しい運用手順書とは？
- 論理的に正しい（論理的）
- 実質的に正しい（合目的的）
- 読み手にとって正しい（伝承的）
- 論理的に正しい（論理的）
- 論理矛盾や欠陥がないこと
- 分岐や共通のパーツを使用していないとシンプル
- これらが多いと、論理矛盾を生みやすい
- ITは物理制約の影響が少ないので、抽象的な概念の適切な利用や論理的な推論ができる組織は強い
- ツール
- 三段論法
- 演繹的推論
- 集合論
- ヴァリデーターやlintツールは論理的な正しさ／形式的な正しさをチェックしてくれる
- 実質的に正しい（合目的的）
- 手順書通りに実行すれば、目的を達成できること
- 前提条件と完了条件の定義が明確になされていること
- ツール
- 形式手法（難易度高い印象）
- ホーア理論
- （ここまでは比較的容易に習得可能）
- 読み手にとって正しい（伝承的）
- 読み手が記述の真意を容易に把握できる
- これが難しい
- できていないと、作業ができるけど意図がわからない
- 引き継ぎできない（意図が伝わらないと、修正できない）
- はたのさん的にも論点整理中
- 読み手が記述の真意を容易に把握できる
まとめ
以下の要素を十分に満たしているかを考えるとよい
- 正しい手順書の要素
- 論理的に正しい（論理的）
- 実質的に正しい（合目的的）
- 読み手にとって正しい（伝承的）
おまけ
- 手順書と自動化
- 共通項「論理的に正しい」
- 論理的なひとがコーディング能力を身につけたら自動化できる
- 論理的でないひとが自動化したら破綻（する可能性・・・）
- 運用手順書の隠れた役割
- ノイズの除去
- 手順書作成の過程で、不要な分岐、曖昧な条件、無意味な確認などが洗い出せる
- ストーリーの保持
- 宣言型のツールで自動化すると失われやすい情報
- Ansibleなどの宣言型のツールを「引き継げた」人の話を聞きたい
- Sphinxはドキュメントの構造化ができておすすめ
資料
感想
このLTを聞いて、これまで見てきた手順書は論理的／合目的的な手順書が比較的多かったような気がしたのと同時に、伝承的なものは相対的に少なかった印象です。 修正やメンテナンスができるメンバーが限られるってシーンが時々あったような気がします。 しかし、メンテナンスできない原因が手順書の書き方の問題ではなくて要員のスキル／知識の問題じゃないかって思われるケースもあると思うので、そこは区別したほうがいいのではないかと思いました。
ちなみに、クラスメソッドではドキュメント管理システムとしてConfluenceを利用しています。 一部を除いて全社員に閲覧／編集権限があるため、何か修正すべき点があればかなりカジュアルに編集が行われています。 こういった文化や習慣が引き継げるドキュメントを書けるようになる一因になっている気がします、なんとなく。 とりあえず、たくさん読んで・書いて・編集すればいいんじゃないでしょうか、最初は不細工でも。
自動化の是非についてですが、 サービスの仕組みや原理をわかってない／慣れてないAWSサービスを使ったCloudFormationテンプレートを作ったとき、 「ほんとにこれで正しいのかなー（動くけど）」って思うことが私もあります。 自動化したものを手順化できるくらい仕組みを理解していればそんなこと思わないと思いますし、何かトラブルが起こっても自信をもって対処できると思うので、 時間的な余裕があればその域に達してから自動化の仕組みを本番環境に投入したいとは思います。 とは言っても、時間的な制約もあると思うので、思い切って自動化の仕組みをぶっ込む決断も時には必要かと思います。
あと、手順化するとノイズが除去されるってところはすごい同意しました。
技術書典5 当日のレポート - ssmjp同人部
最後のLT×2は、ssmjpの同人誌（非公式）についてです。
技術書典5にてささみのほん2を頒布いたしました。そのときのことを発表します。
まずは売り子をされていた方のLTです。
- 同人活動歴
- 基本的にコミケに参加
- BL小説書いてた
- エロゲ流通会社で働いていたときにグッズ販売の売り子
- このとき、売り子の楽しさに目覚めた
- 人の目線とか探るの楽しい
- 以降、友人のサークルで売り子として参加
- 今回
- ささみのほん2の売り子をやった
- ssmjpの紹介や本の概要を書いた紙を用意
- 「アウトプットしないのは知的な便秘」に反応する人もいれば、イラストに反応する人、なんとなく立ち読みする人、関心なさそうな人、など多様な反応
- 必要以上には声かけしない
- 反応に応じて声かけの仕方は分岐
- 結論
- 「アウトプットしないのは知的な便秘」はssmjpを知らない人には難しい
- 技術書典は技術同人誌より技術書が求められている傾向ある？
- コミケのほうがあってる？
- ということで、めもおきばさんに委託する（直近のコミケ）
後半は執筆者の方のLTです。
- 技術書典5
- 非公式の活動としてささみのほん2を書いた
- 5人で執筆
- 6記事、前説、あとがきで構成
- Re:VIEWを活用
- GiuHubにプッシュ
- CircleCIが走る
- DropboxにPDF
- 締め切り直前までだらだらやってしまった
- 3週間前になってやっと焦る
- 締め切り10/3 12:00
- 終わったのは当日の04:33
- Re:VIEWの環境が立ち上がったのが10/1
- 実質3日で本ができた
- サークススペース作り
- テーブルクロス
- ポップスタンド
- おつりや売上管理用のメモ - 残りを持って帰る方法は事前に確保
- 売上在庫管理 - 時間毎に現金と在庫をチェック
- 振り返り
- なんとか作れた
- 販売目標50冊はクリア
- GitHubとCircleCIは強力
- Re:VIEW便利
- 値段を気にする人はいなかった
- ssmjp知らない人の購入率は半分くらい
- 女性が4人買ってくれた！すごい！
- 決め台詞「アウトプットしないのは・・・」を目立つようにしたのはよかった
- 技術書典におけるssmjpの知名度は低い
- （目当てが）同人系と技術書系の参加者の割合は半々くらい？
- 勉強会に来る層と本を買ってくれた人の層は全然違う
- 改善点
- サークルスペースでの見せ方
- 目立つような掲示やPOPでの説明など
- 買わない人にも何か渡したかった（名刺とか）
- 商品
- 「ささみのほん1はないのか？」 > PDF化しておけばよかった？
- おつりのことを考えると800円が効率よい（今回は500円だった）
- 売り子
- 買わなかったひとのフィードバックほしい
- 6に向けて
- 制作フローの高度化（Re:VIEWを使いこなしたい）
- 部数増やしたい（今の部数では赤字）
- 品質（余裕を持ったスケジュールで）
- コンセプトや目的を添えてわかりやすくしたい（記事の寄せ集めで終わらないように）
- もっと多くの人に執筆してもらう
- サークルスペースでの見せ方
感想
同人活動のモチベーションとして売り子が楽しいからってのは初めて聞きましたが、そういうパターンもあるんですね。 個人的には新鮮でした。
Re:VIEWはすごく便利そうですね！今度ブログにしてみたいって思いました。 あと、締め切りが迫るまで動かないのわかりみ深すぎる・・・。 次回の改善ポイントに挙がってますが、これを乗り越えるの至難な気がしますががんばって頂きたいですねｗ
まとめ
今回はアウトップットする人のみが参加できるということで参加者が少数で、 普段はあまりない質疑が多くありましたし、その質疑も完全に会話で大変濃いものでした。
はじめてアウトプット縛りのある勉強会に参加しましたが、 小並感しか持てない私は勉強会のレポートを書くのが非常に苦手です。 初見では要点をつかめないこともありますし、まとめを書いても「資料と同じことを書いても意味ないしなー」と思って公開しないことも多かったです。 わりと時間が経過したとき／お仕事で類似した課題にぶつかったとき、「あ、これはあの勉強会で聞いたこと応用できそう！」となって理解が深まる感じです。
しかし、聞いて終わりだと聞いた内容を忘れてしまうことも多いため、こういったまとめをすぐに行うことは有意義だと思います、たぶん。 ということで、今後も無理せずまとめを書いていければなーと思っております。
現場からは以上です。
14
