The DevOps Handbookが2016年10月に発売になりました。これを読んで、SIerが開発対象とするようなエンタープライズ領域において、DevOpsは価値があるのかどうか、考えてみます。
The DevOps Handbookでは、DevOpsの目的を以下のように定めています。
開発者は生産性向上というとプロセスタイムの短縮にばかり目がいきがちだが、リードタイムをいかに短縮するかの方が、顧客にとっての価値であり、それがDevOpsの目的である。#DevOpsHandbook
— :SIer/kawasima (@kawasima) 2016年10月19日
リードタイムとプロセスタイムの違いは、以下のような定義です。
実際にDevやOpsのタスクを実行している時間は、プロセスタイムです。それ以外の時間も短くする努力が必要です。
SoRとSoE
SoRとSoEというシステム分類が、もとはSIerをターゲットとするソリューションベンダの間で使われていた用語なのに、なぜかWeb系エンジニアにも広まって、一般的なシステム分類みたいになっています。
SoEはDevOpsに適していて、SoRは固いウォータフォールでやるんだ、と捉えられがちですが、ものごとはそう単純ではない、と私は思います。
リードタイムを左右する要素
最大のキーファクターは、案件がビジネスとしての失敗が許される(失敗を前提としたプロセス)かどうかの度合いだと思います。
「ビジネスとしての」と前置いたのは、SoRであろうが、SoEであろうが、アプリケーション不具合によるシステム停止やデータ不整合が発生するのは許されないからです。
DevOpsを支える技術であるところのCI/CDやInfrastracture as Code、モニタリングもSoR/SoEに関わらず重要です。
ビジネスとしての失敗が許されないのであれば、案件が起案されてから、実際に開発着手にいたるまでに面倒な決裁ワークフローを回すことも、ピラミッド組織構造における責任のエスカレーション上、いたしかたのないことで、リードタイムも長くなってしまいます。
逆にあたるかどうか確信をもって言えないあたれば儲けもんな案件に、重厚長大な決裁プロセスを回すのはバカバカしいので、短いリードタイムでやることに注力するようになります。
プロセスタイムへの影響
というように、ビジネス面での案件の性質が、リードタイムを左右しますが、これがプロセスタイムにも影響するのは、ここに案件規模の話が比例するように関わってくるからです。
ビジネスとしての失敗が許されないので、重厚長大な決裁プロセスを踏むが、そうするとちょっとした案件だともったいないので、多くの要求を詰め込みたくなるのが人間のサガです。
そうなるとバッチサイズが大きくなるため、DevおよびOpsの総タスク実行時間も伸びます。したがって一般論として、案件規模大きい → リードタイム長い → プロセスタイムも長くなる、というだけの話です。
一律リードタイムが長いエンタープライズの現場の改善
まぁ、実際のところ"一律"で、案件の特性・サイズにかかわらず同じビジネスプロセスというのは、いまどき見かけませんが、改善の余地は各所にあります。
- 案件が失敗が許されないのか、失敗前提でいくのかを起案時にハッキリさせ、
- それに応じたチーム体制を用意し、
- バッチサイズに応じた開発〜リリースプロセスを設計する
というあたりの整理やルール・仕組み作りが、エンタープライズ領域でDevOps的なことに取り組んでくれ、って言われたときにやるべきことかと思います。
[閑話休題] ITILやSOX法あたりの開発と運用の分離への対応
これがあるから、SIerではDevOpsが出来ない(やる意味ない)し、スキルも身につかないという論調があります。
言わんとすることはわかりますが短絡的だとは思います。
The DevOps Handbookでも、FAQ的なところで、「開発と運用分けなきゃいけないから、ITILと両立できない」という論調についてはMythだと切り捨てています。
DevOpsのプラクティスはITILとも親和性高いし、ネックであるところの開発と運用(本番環境へアクセスする人)の分離は、Opsを自動化してしまえばいいんだ、という回答です。実際にデプロイの自動化や本番環境の監視・連絡の自動化、急激な負荷増ですら無人で対応できる技術が成熟してきているので、不可能な話では無くなっていますし、逆にそういうことが出来るようになったからDevOpsというムーブメントが起こっているとも言えます。
まとめ
DevOpsがバズワードだからSIerが追いかけているわけではないし、食い散らかすつもりもありません。
そのあたりの話を聞きに、ぜひ明日12/3のJJUG CCC 2016 Fall 『SIerもはじめる、わたしたちのDevOps』セッションに参加してみてください。
http://www.java-users.jp/ccc2016fall/