午前の部からの続き。ここからは飛ばしていくぞ！
午前の部（Part1）はこちら
dskst9.hatenablog.com
- Value Stream Mapping
- Monoliths, Myths, and Microservices
- Case Study: Using terraform and packer to deploy go applications to AWS
- Cloud Foundry: Putting the Dev back in Devops
- DevOpsの導入に有効だと思われるプラクティス達
- まとめ
Value Stream Mapping
VSMとは？
DevOps の最初の一歩としてしておすすめ。無駄なものを目に見えて洗い出される。
- アイデアを思いついてからリリースまでの流れを書く
- リードタイム、プロセスタイムも必ず書く
- Developer, Opsだけではなくマネージャー、権限者も連れてきて書く
VSMの効果
- 改善ポイントを見つけやすい
- 自動化するポイントを見つけやすい
- プロセスの共通認識を持つ
- 誰にでもわかりやすく「価値」を示せる
- 現場のモチベーション向上（自分たちから意見を出すから）
- …結果としてリードタイムを削減できる
VSMの段取り
- チームビルディング
- プロセスのディスカッション
- VSMの記述
- バリューストリームマップの検証
- 無駄を発見する
- 無駄をソリューションで解決
実際に書いてみる
- プロセスの流れをリストアップ
- VSMを書き始める
- バックワードモデリング
- 後ろから（価値を届けるというところから）書いていく
- 同じ人がやる作業は実践、違う人だと点線
- ツール使っているところとかも図に書き込む
- プロセスグループ
- production, stagingなどで分ける
- 各プロセスグループで LT, PT を記載する
- スクラップレート S/R
- 手戻りの割合を書き込む
- 例えば S/R 30% だと問題がありそうとかわかったりする
プロセスのディスカッション
コードをプッシュする プルリクエストを作成する レビュー/マージする ・ ・ といった粒度でまとめていく
バックワードモデリングで書く
下記のような感じ。
- cutomer
- Azure サーバ
- swap
- ops:1
- LT:2h
- pT:2min
- 探索的テスト
- dev:3
- LT:4h
- PT:4h
- デプロイ
- LT:6min
- PT:6min
- 承認会議
- LT:2week
- PT:30min
Monoliths, Myths, and Microservices
www.slideshare.net
DevOps をやるならマイクロサービスのクロスファンクショナルチームだとやりやすい。
DevOps とマイクロサービスは当然つながってくる。
Case Study: Using terraform and packer to deploy go applications to AWS
www.slideshare.net
asics が PaaSに乗せ替えた話。
120 のWEBサイトが全てアウトソースで作られていたが、 PaaS や Terraform などを駆使して大幅に削減できたおかげで、夜はパーティーができるｗ
Json構成のスライドにセンスを感じる。
Cloud Foundry: Putting the Dev back in Devops
スライド発見できず。。
Pivotal Cloud Foundry の紹介。Yahoo!JAPANでも採用されているので、どれくらい使えるのか興味津々。
DevOpsの導入に有効だと思われるプラクティス達
Speakers:
Seiji Kawakami, Scrum Master, KDDI, Japan | ConfEngine - Conference Management Platform
※スライドは会社的なあれで非公開の模様。なので、メモ頑張った！
Biz Dev Ops が協力してプロダクトを作っていくもの。
そのためには自律的なチームであるべき。
自律的なチームとは？
- 明確なゴール、明確なルール
- 書くチームメンバーが0.1秒で
- ゴールに向かうために何を行えばいいか理解し、行動できる状態
ゴール とは ビジネスのゴール。
共通認識を作る
- ユーザーストーリーマップ
- ドメインモデル
- インセプションデッキ
ユーザーストーリーマップ
- Max9人くらい
- いろんな部署の人を呼ぶ
- 便宜上システムもユーザとして整理する
- 必要応じてアクティビティ図やシーケンス図を使う
- 時間をかけすぎない
ドメインモデル
- ドメインモデルを書いてみる
- 天ぷらってどういうモデル？
- ドメインモデルで概要を知れるようにsる
- Entity:もの・紙・データ
- Boundory:人・ロール
- Contoller：行動・行為
インセプションデッキ
- なぜ私たちはここにいるのか？何がゴールなのか
- プロジェクトの背景とゴール
- 当プロジェクトを実施する背景・理由
- ＊のシェアが低下している
- ＊のコストが負担になっている
- 当プロジェクトの目標・ゴール
＊を向上させることによって、＊を削減させる
- 開発対象とするスコープ
- 絵にして見せることで理解してもらえる
- 文字では伝わらない
- トレードオフスライダー
- 優先事項の確認
- 開発時に優先する要素、トレードオフの確認
- 具体的な例を出してすり合わせをする
- リリース直前、機能がほっと足りない、お金もない、人も限界まで動いているというときには効果的
- スケジュール
- 予めフィードバックを受けるタイミングを設定しておく
- コミュニケーションプランも組み込んでおく
- フィードバックイベントなども
- プロジェクトリスク
- 夜も眠れないことはなーんだ？
- 主に人事の話と、組織の話。
- 書いてもどうしようもならないことが多いので、予め断っておく
どう使うか
- 作る人：チームメンバ
- 承認者は部長だったり、本部長だったり、ひっくりかえされないように
チーミング
- プロジェクトルーム
- そこに行けば同じゴールを見ている仲間がいる という安心感
- 紙、張り者を気兼ねなく使える
- Daily/Weekl/Monthly Event
- リズムを作って型にはめてしまう
- 型にはめられることで、周囲が安心する
- アジャイル何をやっているのかわからんという時の対策
- ハーマンモデル
- 利き脳診断
- チームメンバーの思考の癖を明確にする試み
- 事前にやっておくとチームメンバー間がギスギスしない
QA
困っているところから巻き込む。
話せばわかる かどうかは分からないが、 話をしないと絶対にわからない
Q.誰が責任をもってやるのか
A.責任はチームしかとれない（謝罪 は各ヒエラルキーの上位になってくるが）
Q.ロケーションが外れている場合はどうするか
A.最初は同じロケーションでやる。ロケーションが同じでできないならやらない。同じロケーションでやった後に、デイリー会議などやったりする
まとめ
DevOps Days Tokyo 2017 楽しかった！
良くも悪くも期待とは違うものが多かったのは良い学びになったと思う。
Develop と Business と Operations が合わさって DevOps というのが印象的だったな。
組織の無駄をなくしていき、そのための取り組みが DevOps へとなっていくのかな。
やるべくしてやるのではなく、組織に合わせた最適解を見つけ出すこと、それが大事。
