システムソリューション事業 2019.05.09

DevOps研究メモ vol.1「DevOpsとは何か?わたし達の解釈」

事業企画・サービス開発ディレクターの高谷です。

ここ数年、Tech系のブログ等でDevOpsに関する記事をよく見かけるようになったかと思います。わたし達の事業部でも少し前から研究会を立ち上げて調査・検討・ディスカッションを行っています。

ひとによって解釈や定義の揺れが大きいDevOps。

なんとなくの理解にはさほどブレはないと思うのですが、具体的な話となると本当に人によって話す内容・粒度・アプローチが違いますよね。私たちも研究を進める過程で大いに悩みました。時には灰皿や怒号が飛び交うなか喧々諤々(?)殴り合いながら議論をしました。ただ、研究のかいあって、現時点でのわたしたちの一旦の共通見解がまとまりつつあります。

今回は整理がてら、それを書いてみました。

何か役に立つことがあれば嬉しいです。

 

DevOpsとは?

ファーストステップとしてDevOpsが何のか調べましたがここから苦労しました。Devops関連のブログや文献をみると、次のような表現が見かけれらました。

よくある定義/説明①

DevOpsとは、開発(Dev)と運用(Ops)が協力して、ビジネス価値を高めようとする取組み。あるいはその文化・働き方。

よくある定義/説明②

DevOpsが何かを議論するのはナンセンス。色々な使い方がなされるので、意味についてあまり深く議論してもリターンは薄い。議論に時間をかけるよりも広くとらえて実践していくのが大切。

よくある定義/説明③

DevOpsでやるべきことは企業によって異なる。ビジネスの競争力を高めるための取組みがDevOpsなのだから、各社、状況・環境・資産・人材リソースが異なるから、一概に定義できない。

…これでは話が進められないです。

DevOpsについて話をしよう!というのに、共通見解がつくれない。ここで最初の壁にぶちあたりました。でも、調べてみるとそれぞれDevOpsを違った観点から表現している、合点のいく定義/説明でした。

DevOpsの起源をたどる

DevOpsの起源は「Velocity 2009」というカンファレンスでのFlickrの+10 deploy per dayというセッションにあるとされています。

市場のビジネススピードが高まり、従来の開発手法では競争力が維持しづらいなか、開発のリードタイムの短縮を目的にFlickerが当時取組んだのが「Dev(開発)とOps(運用)の対立解消」でした。これを解消し1日に10超のデプロイを実現し、人々に驚きを与えました。

でも、「Dev(開発)とOps(運用)の対立解消」が有効だったのは、彼らの課題がそこにあったから。例えばわたしたちは別にDevとOpsでチームを分けていなかったりします。じゃあDevOpsは不要なのかというともちろんそんなことはなかったりします。そうなるとDevOpsとは何なのか。

 

 

わたしたちの考えるDevOps

目的から立ち返っていまはDevOpsを次のように考えています。「新しい機能・コードをよりはやくユーザーに届ける為の取組み」。これはこれでばっくりしているなぁと思いながらも、一方でDevOpsの性質・特徴をそれなりに正しく捉えているのかなと思ったりしています。

一方で、これだけだと抽象的すぎるので、具体的に取り組みべきことも定義したい。

これも色んな定義がありますが、様々な文献や有識者の話を聞いてみて、一旦大きく次の4つの取組みに分けられるのかなと考えています。

1.ひとつひとつの開発をより早く進められるようにする
2.複数の開発を並行できるようにする
3.それぞれの開発で得たナレッジを相互活用して、より高いパフォーマンスの組織をつくる
4.開発をしながら人を育てる

 

以下、それぞれの詳細です。

1.ひとつひとつの案件を早く進められるようにする
✓ 開発の進め方を変える
アジャイルな進め方へのシフト。時間をかけて、考えに考えて、変更
も極力折り込みながらリリースする形から、そうでない形に。
・スコープを固定して動かす *3ヶ月、6ヶ月…
・ やることを絞る
・ スクラッチ開発のボリュームを減らす
・ 致命的な不具合は防ぐが、事故がある前提での作りにする
→ 範囲を絞って考えて、考えてリリースする

✓ 効率化、自動化をどんどん進める
スピードがあがると人の手で全部やっていたのでは追い付かない。
また、リソース効率も悪い。エンジニアのリソースはビジネスの
成果が大きく上がるところにのみ投下する。
・ CI/CDなツール、フローの導入 *作業自動化、プロセス自動化
・ クラウドサービス等の活用

✓ 少ない人数で開発を進められるようにする
パフォーマンスが最大になるチームのサイズを維持する。
・ 5~7人ぐらいのチーム
・ PJやシステムの規模をチームに併せる
・ スコープ設定
・ システムサイズ *大きい場合は分離
・ 5~7人で回るように環境を整える
・ スクラッチ部分を減らす

2.複数の開発を並行させられるようにする
✓ システムを分離する
開発チーム間の連携/調整が極力発生しないつくりにする。
・ 例えばマイクロサービスアーキテクチャの導入
・ 本格的な導入は難しくても、とある機能単位ごとに分離する

✓ 新しく開発に入ったメンバーが数日で立ち上がるようにする
開発チームをどんどん増やせるように。経験しないと分からないこと
を極限減らす。
・ 開発環境の汎用化、開発手法の標準化
・ 業務知識、サイトの基礎仕様の見える化

✓ チームに裁量を渡す
「待ち」によるロスを減らすため。チームで学びながら開発を進めて
いけるようにするた。チームを超える承認を極力減らす。

3.それぞれの開発で得た知見/資産を活用し、より高いパフォーマンスの開発組織にする
✓ R&Dを開発チームごとに行う
✓ 開発物の汎用化、API化

4.開発をしながら人を育てる
✓ レビュー文化
✓ 責任を追及しない
✓ ポストモーテム *問題が起こったらすぐ反省する、共有する

 

この記事をシェアする
事業について詳しく知る

システムソリューション事業について詳しく知りたい方はこちら

RECOMMEND

おすすめ記事