概要

先日、Tech Night @ Shiodome # 4というイベントに参加して、LTをしてきました。

どんなイベントか

「DevOpsと自動化」をテーマに、事例・知見を共有する場でした。

もとはソフトバンク様の社内勉強会で「外部ゲストを呼ぶ → 公開イベントになった」とのことです。社会にシェアする姿勢が素敵だと思いました。

他の参加者の発表

あたりまえのことをあたりまえにやる難しさ
AWS ECS （EC2 Container Service）を用いた AWS へのDocker コンテナデプロイ
自動化におけるコード管理
送信メールサービスをユニットテストしてみた
DevOps、本当のところ

こちらのConnpassのページに資料が上がっています。

どんな話をしてきたか

こちらが当日の発表資料になります。

ざっくり説明すると

DevOps（全体最適化）の前に、業務標準化（ドキュメント化）しよう！
レガシードキュメントを予防・解消するために、ソースコードと同じように扱おう！

という話になります。

最適化をはじめるまえに標準化（ドキュメント化）

広義のDevOpsとは、開発・運用の協働による全体最適化の取り組みだと（私は）解釈しています。

自動化は、作業時間（プロセスタイム）を短縮するための打ち手の1つにすぎません。

ちなみに、トヨタ方式を確立した大野氏が最初にやったことは、ドキュメント化（業務標準化）です。

まず業務標準化があって、その次に最適化がなされるのです。

しかしドキュメントは「書きにくい」「探しにくい」という問題がついて回ります。

ドキュメントをコードのように扱おう

これらの問題はレガシーコードと全く同じです。ならば、予防や対処にもシステム開発のパターンを適用できるはずです。

例えば、MVCモデルによるドキュメント間の依存関係の整理。

例えば、GoFのIteratorパターンによる繰り返し処理の一元管理。

こういった合計15のパターンを現場で試してみました。Appendixに書いています。

現場で業務に携わるソフトウェアエンジニアこそが、ドキュメント（業務）を適切に設計・運用することができるはずです。

という内容を圧倒的アジリティで話した

DevOpsとドキュメントデザインパターンの話#テクシオ
— ぷーじ (@YuG1224) 2017年7月3日

#テクシオはえーｗ
— Jun Ohtani (@johtani) 2017年7月3日

超早口ｗｗｗ#テクシオ
— ぷーじ (@YuG1224) 2017年7月3日

#テクシオライトニング感がある
— 💪邑💪 (@nhiro78) 2017年7月3日

LTだなぁ(白目) #テクシオ
— かしゅーなっつ (@kashew_nuts) 2017年7月3日

これが本当のライトニングトークだったかｗ#テクシオ
— ぷーじ (@YuG1224) 2017年7月3日

早口ツボったｗ #テクシオ
— higassy325 (@higassy325) 2017年7月3日

PyCon で Docker が発表されたときを彷彿とさせる早口 LT :-) #テクシオ
— Taisuke 'Jeff' Inoue (@jeffi7) 2017年7月3日

早送りで聞いているみたい #テクシオ
— sawa (@kanaisawa) 2017年7月3日

いいテンポなのキタ #テクシオ
— Takayoshi Kimura (@nekop) 2017年7月3日

あまりの早さに思わず笑ってしまうLT #テクシオ
— Mikka (@mikka_tech) 2017年7月3日

早いｗｗｗ #テクシオ
— kuntao@9/18-20Ruby会議 (@_iamkuntao) 2017年7月3日

この早口でちゃんと聞き取れるように喋れてるのすごい。 #テクシオ
— Taisuke 'Jeff' Inoue (@jeffi7) 2017年7月3日

3分の鐘いい調子ですね #テクシオ
— のぴぴ (@noppymagus) 2017年7月3日

4分の鐘大丈夫です。#テクシオ
— のぴぴ (@noppymagus) 2017年7月3日

#テクシオ見事にぴったり5分間
— 💪邑💪 (@nhiro78) 2017年7月3日

お見事！ #テクシオ
— みぃや (@udendows1994) 2017年7月3日

質問の回答も早口ー。 #テクシオ
— Taisuke 'Jeff' Inoue (@jeffi7) 2017年7月3日

ききとれなかったｗ #テクシオ
— Jun Ohtani (@johtani) 2017年7月3日

結論「ドキュメントもソースと同様に扱おう」それだけわかった:-) #テクシオ
— Taisuke 'Jeff' Inoue (@jeffi7) 2017年7月3日

「レガシートドキュメント。人工言語が自然言語になっただけ。コードと同じ。」 #テクシオ
— Taisuke 'Jeff' Inoue (@jeffi7) 2017年7月3日

ドキュメントをコードと同じように扱う。
MVC アーキテクチャとか#テクシオ
— おれたま (@AHA_oretama) 2017年7月3日

ドキュメントにMVCモデル当てはめるって面白いな#テクシオ
— ぷーじ (@YuG1224) 2017年7月3日

ドキュメントもソースコードの様に管理しような話し #テクシオ
— Takuya (@HelloTakuya) 2017年7月3日

これおもしろいー #テクシオ
— kuntao@9/18-20Ruby会議 (@_iamkuntao) 2017年7月3日

レガシードキュメントの直し方は、レガシーコードと同じというメッセージがすごい良かった #テクシオ
— shiroica (@shiroica) 2017年7月3日

3分の1倍速くらいで聞きたいし、これLTじゃなくてちゃんと聞きたい。とりあえず資料みる #テクシオ
— Mikka (@mikka_tech) 2017年7月3日

さっきのLTの資料87pもあったw #テクシオ
— kAZUYA tAKEI (@attakei) 2017年7月3日

ゆっくり見ます。https://t.co/OM5SlzJ6pa
#テクシオ
— sawa (@kanaisawa) 2017年7月3日

懇親会で話したこと・感想

ドキュメントデザインパターンQ&A

Q1. MVCを適用させるのは斬新ですね！

A1. MVCだけでなく15のパターンがあります！！！（Appendix参照）

Q2. 周りのメンバーにはどうやって意識付けするのですか？

A2. そのためのパターンもあります！！！
　「コードレビュー」パターンです！！！（Appendix参照）
　コードレビューを通してソフトウェアの設計思想は徐々に浸透しますよね！？
　ドキュメントでも同じことをやります！！！

Q3. どういう発想で思いついたのですか？

A3. SREやアーキテクトな仕事をやっていました。
　システム横断の設計や技術的負債を考える機会が多かったのです。
　なのでドキュメント整理の際に、自然とこの発想になりました。

組織とか開発フローとかツールとか

ここからはイベントのメインの話題。皆様の悩みの声。

社内で「DevOpsをやるのだ！」「自動化するのだ！」という話になって「どうしよう……」という相談が多かったように思います。

組織：人事評価制度をどう設計するか、偉い人や現場にどう意識付けするか
技術：GitやJenkinsをどう導入するか、コードレビューをどう始めるか

内製部隊の立ち上げ時に、同じような議論・経験をしたので「そういえば大変だったなぁ」と思い出しました。機会があれば、手持ちの事例を共有したいものです。

話したかったなぁ！

新プロセス・ツール導入のベストプラクティス

この観点での提案がなかったので。

毎週KPTをしてみては？という提案

偉い人にKPTのサマリーを毎週レポートし続けると

心配して「運用が楽になるツールないの？」と向こうから聞いてくれるようになります。
むしろ「XX部署が上手くやっているらしいから紹介するよ」「予算を確保しておいたよ」と動いてくれることさえあります。

メンバーも、KPTを一緒に繰り返しているので

「いいツールないですかね」「これとかどうですかね」と話しかけてくれるようになります。
導入時には「このProblemに対してXXXを導入します、使い方はこうで、メンテはこうやります」を話すと「ようやく楽になるのか！」と歓迎してもらえます。

皆が困っているなら、解決策があれば適用する方向に動きます。困っているという実感が共有されていないから、話がややこしくなるのです。

この「Problemを可視化させる」作業こそ、最初に自動化・仕組み化すべきです。

Problemがまだ共通認識になっていない場合

プロセスやツールだけ入れようとしても、誰もついて行けません。

チームにはチームの進化のペースや方向性があります。問題意識が醸成されていない中で、無理に歪めても仕方ないのかなと。

むしろ、ボトルネックの可視化と対処に専念した方が良いのでは？というのが個人的な意見です。

それでも、成長痛を覚悟で、望む方向に早く進化させたい場合

あの手この手を使って「これがあると助かるね」「やりたいね」の声が上がるように仕向けることになります。

機を見て少しずつメッセージングしたり
研修に参加してもらったり
輪読会を開いたり
外部勉強会の内容をシェアしたり
該当ツールやプロセスを採用している競合企業のインタビュー記事をシェアしたり
自分で小さく試して成功事例を作ったり

水を売るには喉を乾かせる作戦です。服を脱がせるには北風よりも太陽です。

DevOpsを「導入する」ことの違和感

（広義の）「DevOps」は、最終的には「ビジネス価値を最大化する」取り組みだと思っています。乱暴に言ってしまうと「きちんと経営しましょう」と同義。

例えば、リリース回数が重要ではないビジネスなら、CI/CDよりも、マーケティングの自動化や機械学習活用が最適解かもしれません。ビジネス構造を俯瞰すると、製品の機能追加よりも集客の方がインパクトが大きい、というのはよくある話です。

「開発・運用だけでなくビジネスまで広げて考える」という言葉がありましたが、行き着く先は「経営する」ということになります。（そんなこんなで、私も、Biz/Dev/Opsの取り組みとして、最近はいろいろな部署で使えるデータ基盤を作っていたりします！）

結局は「全体像を把握した上で、ボトルネックを継続的に可視化・解消できるようにしましょう」ということでしかないのかなと。という考えに基づいて、私がチームの立ち上げ・立て直しに関わるときは、まずはKPTから始めることが多いです。

ソリューション（Gitやコードレビュー）は、イシュー（管理コストや内部品質）に依存します。そしてイシューは現場にあります。何よりもまず可視化です。

なので、導入という言葉には違和感を覚えます。

という話をもっとしたかったなぁ！

最後に

運営の方々、発表者の方々、参加者の方々。全員が一緒になってイベントを盛り上げている感じが、お祭りみたいで楽しかったです。とても素敵な会だったと思います。本当にありがとうございました！

あとだれかLTじゃなくて20分枠で呼んでくださいネタは山ほどありますお願いします。

The DevOps　逆転だ！究極の継続的デリバリー

作者: ジーンキム,ケビンベア,ジョージスパッフォード
出版社/メーカー: 日経BP社
発売日: 2014/08/12
メディア: Kindle版
この商品を含むブログ (1件) を見る

リーン開発の本質

作者: メアリー・ポッペンディーク,トム・ポッペンディーク,高嶋優子,天野勝,平鍋健児
出版社/メーカー: 日経BP社
発売日: 2008/02/07
メディア: 単行本
購入: 6人クリック: 141回
この商品を含むブログ (67件) を見る

下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・試行錯誤の瓦礫の記録

#テクシオで「DevOpsとドキュメントデザインパターン」の話をしました＋α

概要