こんにちは
music.jp というプロダクトの開発運用を担当している矢吹です。
先日『DevOps実践企業の最新動向から学ぶ継続的な改善への取り組み方』
というマイクロソフト主催セミナーに参加してきました。
いいなって思ったプロセス、ツールの共有と、今後music.jpではこうしていこう！を考えたので書いておきます。
どんなセミナーか？
DevOpsの最新動向と各ツールの有効活用について紹介してくれました。
DevOpsとは？
~とは？ って書きながら、これっていう定義はないです。
セッションではこのように言ってました。
ビジネスを最⼤化する事を⽬標に、迅速にかつ柔軟にソフトウェアを開発し、本番へリリースするためのプロセスやツール、⽂化を実践する継続的な活動
う～ん、、、まぁ納得です。
DevOpsは広義の意味では全ての部門を含みます。でなければビジネスを最⼤化するという⽬標が達成されないから。技術者1人がパソコンに向かって一生懸命考えても、最適解は絶対に見いだせません。
→すなわち 各部門が、隔たりなく仲良くすることが大事！！
ためになったこと
Value Stream Mapping（VSM）
- 顧客に製品・サービスを提供するまでの流れを可視化、無駄を発⾒する作業
- 開発者、運用者、関係者、プロセス変更承認者が集まって議論をする
- システムの把握=>開発サイクルの把握=>全員でプロセスを書き出す=>⼿戻り率 を書く=>グルーピング(LT/PTの合計)=>無駄にマーク=>改善案を出す
| 用語 | 説明 |
|---|---|
| リードタイム : LT (Lead Time) | プロセスが次ステップに移るまでに要した時間の合計（PT+WT） |
| 実行時間 : PT (Process Time) | 実際にそのプロセスを実行している時間 |
| 待ち時間 : WT (Wasting Time) | プロセスで待機状態の時間 |
| プロセスグループ : Process Group | 各プロセスをグループにまとめたもの。 |
ここで洗い出される改善例
- ⻑いリードタイム(プロセスタイムとの⽐較、待ち)
- ⼤きすぎるタスク
- 承認プロセスの多さ、複雑さ
- コミュニケーションの多さ(受け渡し数の多さ)
- 複数タスクの切り替え(コンテキストスイッチのコスト)
- スーパーマンの負荷増⼤
- 余計な処理/機能
- マニュアルテスト/ベリフィケーション
- マニュアルデプロイ/構成
- 安全でないデプロイ
コミュニケーション
チームの稼働率が80％を超えると、チーム間のコミュニケーションにおける待ち時間が格段に増加すると言われています。これは実際の業務でも体験できるはずです。
Aさん：「ちょっとこの機能の仕様についてお聞きしてもよろしいですか？」
Bさん：「今手が放せないので、5分後でもいいですか？」
Aさん：待ち・・・
これはちょっと極端な例ですね。
チーム間（エンジニア同士とは限らない）のコミュニケーション内容も方法も様々あります。会話であればそれほど応答待ちというイメージはつきづらいかもしれませんが、チャットやメールはどうでしょう。相手の時間を拘束しないのが良い点ですが、その反面いつまでも待たせる事が出来てしまいます。そこで相手の稼働率が80％を超えると、返答する時間がなかなか取れなくなり、返答はどんどん遅くなっていく、という事をあらわしています。
（エンジニアの方は時間を拘束される会話より、チャットやメールを好む人が多いですよね）
開発手法
WaterfallとAgileについては、数年前から弊社内でも導入/評価が進んでいます。改めて簡単にまとめると以下の通りです。
| Waterfall | Agile | |
|---|---|---|
| 概要 | サービス開発プロセスが各工程で分離されていて、前工程のアウトプットが後工程のインプットになる。 事前に決定された細かい仕様に従って開発する。 スコープに応じて開発リソース、期日を調整する。 |
小さいストーリー単位で開発を行い、随時フィードバック/改善を回す。 リソース、期日に合わせてスコープを調整する。 もともと「俊敏な」という意味。 |
| メリット | スケジュールが立てやすい。 外部委託開発の場合、FTPが契約に入るので揉め事になりにくい。 |
変化に対応し易い。 ミニマムスタートできる。 |
| デメリット | 変化に対応しづらい。というかできない。外部環境においていかれる。 各担当者のコミュンケーションが最小限に抑えられるため、コラボレーションが起きない。 |
ゴールがあいまいになる。 スコープを調整するので開発者がサボる可能性がでる。 スケジュールの外部合意がしづらい。 |
サービス特性、開発組織によっても異なりますが、music.jpのようなWEBアプリケーションサービスならWaterfallの”変化に対応しづらい”というデメリットにおいてAgile開発手法を選択するはずです。
開発プロセスとツール
迅速かつ柔軟にソフトウェアを開発を実現するための、プロセス、プラクティスは幾つか存在します。全てを整える必要はないですが、揃っている方がDevOpsの目指す姿には近づきやすくなります。
GitHubの提唱するSocial codingは全ての土台になり、それぞれのプラクティスは積み重なっていくものです。しかしチームAではWaterfall型の開発手法でありながら、テストコードをしっかり書いて開発し、Jenkinsで定期的にビルド、テスト回しています。なーんてことは往々にしてあり得ることで、それが悪い事ではありません。 まずは今自分の組織、チームがどこに位置しているかを把握して、何が出来てなくて、何を優先してやるべきかを考える必要があります。
music.jpでは
これまでmusic.jpのIT技術部門は、システム開発部門とシステム運用部門が組織として分かれていました。2017年春からはDevOps推進のため組織を統合し、デプロイなど本番変更権限を人に紐付ける事をやめました。
「適切な承認プロセスが行われていれば実行者は誰でもよい」というわけです。
そもそもきっちりと権限を分けていたのは、マニュアル操作のデプロイや変更作業が多く、不慣れな作業者では事故が起きると考えていたからです。そこでmusic.jpではマニュアル作業を少しずつ減らし、デプロイ・変更作業の自動化を進めました。誰でも同じレベルでデプロイ作業ができるようにすることで組織統合が進められる。これがmusic.jpが始めたDevOpsの第一歩です。
こうしたらいいかな
今回のセミナーを聞いて、今後はこうしていけたらいいなってのを書いてみました。 自動化が進めば開発者がマニュアルでやらなくちゃいけない領域は、素の”開発”だけになるはずです。
現状の把握
DepOpsチェックリスト
| 領域 | 項目 | 現状 | 言い訳 |
|---|---|---|---|
| システム | インフラはコード化されている？ | △ | 一部だけ |
| システム | ビルドとテスト回り続けている？ | △ | していないシステムもあるかな |
| システム | 自動デプロイの仕組みは整っている？ | △ | 半自動的な・・・ |
| システム | CI,CDの通知は適切に拾える状態になっている？ | △ | 形骸化しがち |
| 文化 | チームの稼働は100%を超えてない？ | △ | 繁忙期もあるじゃないですか |
| 文化 | チャレンジを恐れない組織になっている？ | △ | チャレンジと無謀って違うやん |
| 文化 | 組織を良くしたいという気持ちはある？ | ◎ |
伸びしろしかないですね！！
GitHub Flowの採用
次にやることとして、開発フローをGitHub Flow、もしくは統一されたCDにつながるフローにしたいと思います。
詳しくはこちら(グラフィカルで見やすい)
人がやる領域
① masterブランチから説明的な名前を付けたブランチを切って開発
② 開発が終わったら、作成したブランチにローカルでcommitし、サーバー上の同名ブランチにpushする
③ アドバイスやFB、コードレビューをしてもらいたい時、もしくはブランチをマージする時にpull requestを出す
④ 必要があればコードを修正して再度commitとpush
⑤ 再度コードレビューをしてもらってOKなら、masterブランチにマージする
自動化されるべき領域
⑥ マージイベントをCIツールで拾い、自動build/testが動く
⑦ HubotがCIの結果を開発者に返す
⑧ CIが失敗したらpull requestとして開発者に戻す(GitLabでできるかはまだ分からない)
⑨ CIのテスト結果が正常であれば、自動デプロイが実行される
⑩ デプロイの結果を開発者に通知する
これができればよく言う「1日100回デプロイ」が可能になる
（やる必要があるかはさておき。。。）
想定される問題
■誰もレビューしてくれない。。
最初は得意なシステムしかレビュー出来ないかもしれませんが、百里の道も一歩からです。少しずつ知識を共有していく為にも情報をオープンにしていきましょう。
■こんな簡単にマスターマージされていいの？
いきなり全てをこのフローにする必要もないと思います。フロントエンドの変更、軽微な修正などと、決済、ログインに関わる変更など、変更内容によってプロセス・フローを使い分ければ良いと思います。
■Subversionですけどなにか？
OK！まずはGitLabにのせようか！！
これらを実現する為に必要なこと
・コードをレビューし合う開発文化があること
・テストコードがあり、確実に更新され続けていること
・CIが動いていて、異常を検知する仕組みがあること
・デプロイの仕組みが自動化されていること
・仲良くすることが大事！！(再掲)
まとめ
DevOpsってしょせん役割をつなげただけなんですよね。
その中にいるのは、これまで一緒に仕事をしてきた開発者や運用者やビジネス部門の『人』です。いままで通りの組織編成でもここで紹介したプロセスやツール、文化やマインドを実践することは可能だし、それによってマーケットリーダーになれればDevOps体制にしなくても、DevOps大成功だと思います。
ただこれまで世の中のDevとOpsは分業されすぎていたため、コラボレーションが起きずこのままではIT業界の荒波に飲み込まれていっちゃうよね。ってことで設けられた指標のようなものだと理解しています。
自分の組織でも、取り入れやすいDevOpsのプラクティスを実践していき、Dev、Ops以外の各部門とも連携が取りやすくなるよう、まずはごちゃまぜSlackを作り運用中です。
今後のmusic.jpにご期待ください！
参考
Agile versus Waterfall for CRM Software Success
