【レポート】Developers Festa Sapporo 2016「基礎からわかるDevOps」 #devfesta

吉江健斗

2016.11.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんばんわ、吉江です。
11/11(金)に札幌コンベンションセンターで行われた「Developers Festa Sapporo 2016」に参加しました。
そこで受講した「基礎からわかるDevOps」についてレポートを作りました。 ※久々にコンベンションセンターへ向かったので、写真がありません。

スピーカー

吉羽龍太郎 (Ryutaro YOSHIBA)
Twitter:@ryuzee

スライド

現状の整理

現在のビジネス状況

2006年と2016年に発表された時価総額ランキングにランクインしている企業が大きく変わっており、
ITの技術を利用してソフトウェアによって収益を受けている。

ビジネスの変化がどんどんはやくなっている
VUCA
- Volatitity(不安定)
- Uncertainty(不確実)
- Complexity(複雑)
- Ambiguity(曖昧)
現在ではソフトウェアがビジネスによって非常に大きい重要な要素になっている
開発の競争力の差別につながっているというのがランキングから見て取れる
ITはビジネス上の成果達成のための重要な要素になる
そして、多くのサービスが登場したことでビジネスモデルに影響を与えている

システムに実装されている機能の利用割合について

多くのシステムを集めてどのぐらいの機能を利用しているかを調査した結果、
64％の機能は使われていないことが分かる
この数字から、開発の無駄が多々ある
この64%を作らなければ、1/3の期間も工数も削減につながる
この無駄を日々の開発からなくさないと、楽にならないし、儲からない
DevOpsやアジャイルに関係してこないが、いかにこういうことを無くすことがよい開発となる
だからといって、1チームが作成出来る量が増えることはプラスだけではなく、
たくさん作れるようになったからたくさん作ると使われない機能も作られる(≒無駄な機能)につながる可能性がある
例として、調整さんは機能として、週100パターンやっている
事前に正しいことを知るのは難しい
正しく予測する能力よりも、仕様変更などの素早い変化についていける能力を持つことが重要

何が大事なのか

フィードバックサイクルを作る
- いかにに早く回せるか
- 今のIT組織において重要な課題になる
ウォーターフォールについて
- 要件定義から受け入れ試験までに時間がかかりすぎて、引き渡したときの要求が変わっている、又は頼んだ内容を誤認して誤ったものを作成する、これが有りがちなパターンになる
- 変化の早い領域でのウォーターフォールは機能しない
- 変化がない領域だとウォーターフォールは機能する
- ITのように競合が多く、ソフトウェアが多くある現状だと変化が早い領域でのソフトウェア開発だと、ウォーターフォールは厳しい
- ソフトウェア手法は領域別の特性によって、適宜変更しなくてはならない
多様性は改善を加速する
- 書く担当者のスキルマップを作成する

DevOpsとは？

全員一致の共通定義は存在しない
アジャイルの場合、アジャイルマニフェストがある(共通理解がある)

DevOpsの構成要素

CLAMSが構成要素として言われるようになっている。
- Culture(文化) ・・・文化
- Lean(リーン) ・・・無駄を省く
- Automation(自動化) ・・・自動化
- Measurement(測定) ・・・測定
- Sharing(共有) ・・・共有

しかし、上記はよく言われる要素で全ベンダーに適用されるものではないので、よくある定義になる

DevOpsは銀の弾丸ではない

Devopsを導入することでみんなの仕事や生活が激変するものではない

DevOpsとは文化とツールを活用してビジネスの成功を目指す

ビジネスのためのアジリティ(俊敏性)を向上させ、リスクを低減させるもの

Culture(文化)

DevとOpsは仲良くしましょう
DevはOpsのように考え、OpsはDevのように考えましょう
しかし、Dev(開発)とOpe(運用)でコンフリクトがある
- 各立場でミッションの違いがある
  - 開発・・・新機能を作らなければならない
  - 運用・・・安全にサービスが落ちない稼働率がたかいシステムが欲しい
それは私の仕事じゃないとミッションが違うことで声が上がる
役割毎に分かれている部門が分かれていると縦割りになると、コンフリクトが多くなる(加速する)
組織間のコミュニケーションに時間コストが発生する

プロジェクトで起こる問題は技術ではなく、人間系の問題で引き起こされる

サイロによるオーバーヘッド
サイロ化すればするほど、手続きが増えて時間コストが発生する
結果、お客さんへの提供する価値に時間が使えなくなる
原則、開発チームは他部門に引き継ぎをせず、ソフトウェアを直接お客さんに届けられる能力を持っていたほうが良い
可能であれば、組織構造を買え、密結合な組織間関係を疎結合にするべき
Amazonなどは「You build it, You run it」と、自分が作ったものは自分で運用する
自分たちで責任を持ってやる
例として、製品を作っているチームの人が自分で運用すると、夜間コールを持ち回りでやる
これをやると落ちたりして、呼び出されるのが大変なのでAPを落ちないように作ろうと考える(OPEの考え)
チームの人数が増えるとコミュニケーションコストが高くなるので2ピザルールを設けて、チーム人数を満たしている

AWSのお話

AWSが出来た時、Amazon.comでは年末などのイベントでアクセス数増のときにサーバーを増やす際、 Amazonもインフラに申請を出していた経緯があった。
これだと時間がかかりすぎるので、APIに置換えることで解消した。
これにより、調達のコミュニケーションオーバーヘッドが減る
部門単体を疎結合の方がやりやすい
2ピザルールをやったことですぐに機能するわけではない。

チームの進化について

知らない人を8〜10人集めてもすぐに機能しない
タックマンモデル
形成器
- 人が集まっている状態
混乱期
- 意見を言うようになるが、意見に示すようになる
統一期
- 混乱期をすぎると、異なる意見も受け入れるようになる
機能期
- よく機能するチーム、一体感もあり、自立性が高い
解散期
- SIプロジェクトでいうと解散にあたる

形成期から統一期にチームが成長する前の時間

早くても3ヶ月、遅くて半年1位年かかる
いいチームを作るのには時間がかかる

統一期、機能期に至ったチームの重要性

気軽にいいチームを解散させてはいけない
海外のスタートアップは、プロダクトは要らないからチームメンバーが欲しいという目的がある
すごいチームを作るには多様性があったほうがいい
これを把握するためにはスキルマップを書く
- 毎月一回更新する
- このスキルマップを人事評価に使用すると、チーム全体がエースになる(★や◎が付く)
- こうなると正確なスキルマップから外れてしまうので人事評価では絶対に使用しない

Lean(リーン)

無駄をなくしてスリムでいること
組織をまたがるバリューストリームに注目する
- 要求が来てから出荷するまでの流れに注目する
- チームがサイクルタイムを減らとしても必ず全体のリードタイムが短くなるとは限らない
- ボトルネックが存在する可能性がある
- 制約理論(ToC)を学ぶと良い
ファイルサーバーにたまった大量のドキュメントで考える
- 古くて不要なもの、作りかけのもの、複製されて改変されたもの、本当に必要なのに更新されていないもの
- あるドキュメントに「この記述を見つけた人にビール奢ります」と書いた所、誰からも連絡が来なかった上記のようなドキュメントがある場合は無駄が多いと考えられる。
継続的な改善を続ける
- 改善とは自分たちの仕事を「安全」、「簡単」にする
  - これが実現できなくてプロセスに手を加えるとチームが辛くなるだけ
- 強制的に立ち止まれる仕掛けを作る(人間は停止するのが苦手)
- 問題を防ぐところにいきなり効率を求めない(まずは穴をふさぐ)
  - とにかく問題を治す、効率は求めない
春の大カイゼン運動
- 一時的にカイゼンが加わることで生産性が向上するが、時間経過で期間が終わるとに伴いカイゼン数が少なくなり生産性がもとに戻った
- 改善運動ではなく、改善活動の意識を持って継続的にカイゼンを行う必要がある
ビックバンでやるとどうなるか？
- これまでの作業などに対して大きくカイゼンを加えると、不具合によって作業が進まなくなる危険性がある
- そのため、少しずつやっていくことが大事
カイゼンパターン(ECRS)
- 工程を無くす(Eliminate)
  - そもそも工程を無くす
- 工程を統合する(Combine)
  - 一つに纏める
- 順番を変える(Rearrange)
  - 後工程で手戻りがある場合は、手戻りの工程を先に持ってくる
- 単純化する(Simplify)
  - 複数の選択肢を一つに纏めて単純化する

Automation(自動化)

自動化にはコストがかかる
基本ができていない場合、達成までに時間がかかる
作業でやった場合と比較してどちらが安いのか
実行回数や問題が発生した場合の対処コスト等を含めて考える
ただし、損益分岐点は思った以上に早い
- バグがあると再テストが必要、それを加えると損益分岐点が早い
顧客が要求するスピードやAPのライフサイクルを踏まえる
自動化それ自体は「ゴールにはならない」
どのツールから始めるか
- バージョン管理
- テスト自動化
- 継続的インテグレーション
上記3つの基本的な技術要素から始める(上記3つが出来ていなかったらやらないほうがいい)
バッチサイズを小さくして、ビジネスのニーズに合わせて頻繁にデリバリーしようとすると何が必要か？
- 継続的な品質保証、確実なデプロイ、影響範囲の局所化・・・
- 作業を「安全に」「簡単に」
テスト自動化のグラフより、自動化した場合としない場合でのテスト工数は3回を超えてから大きく変わってくる
ビジネス視点だと実装が進むに連れて肥大化する回帰テストによる速度低下とコストを負担したいはずがない
バージョン管理、テスト自動化(単体・受け入れ)、データベース自動マイグレーション、継続的インテグレーションが出来るようになれば、デプロイの自動化が可能になる
毎回同じ手順で、頻繁にデプロイ出来るようにする
成功・失敗を人による判断に委ねない(自動で判定する)
失敗したらすぐにロールバックできるようにする
きれいなアーキテクチャはデプロイのしやすさにつながる
Infrastructure as Code
- APを動かすためのインフラをコードで記述すること
- コードで書くことで再現性を高められる
- コードで書くことに寄って、ソフトウェア開発のプラクティがインフラにも適用可能
- 領域はサーバー内部(OS設定、MW設定)だけに限らない
- サービスを動かすインフラ全体(ネットワークやそもそものサービススタック全体)が対象になる得る
- インフラなのかアプリなのかの境界がなくなっていく(ビジネス視点だとインフラとAPのそれぞれの区分けに対して関心がない
ツール導入の原則
- ツールが組織構造の問題を解決するわけではない
- なぜそのツールを導入するかの理由
- メジャーなツール
- 同時にたくさんのツールを入れない
- 利用者を教育する
- 自分たちでメンテナンスする