第16回itSMF Japanコンファレンス/EXPO
SCSK講演「体験！イノベーションを加速するDevOpsの能力」～原理編～

DevOpsは未開拓だけで適用すべきなのか？

DevOpsは既存側へも適用すべきである

はじめにDevOpsのスコープについて考えてみます。
DevOpsはバイモーダル IT でも、既存（Brown Field）であるSoRではなく、未開拓（Green Field）であるSoEの手法として定義しています。
しかし、DevOpsはゼロからはじめられるプロジェクトだけを対象にして本当に良いのでしょうか？昨今、話題になっている「2025年の崖」では、問題は既存側にあり、これがデジタルトランスフォーメーションの足かせになるとされています。
そのため今回は、DevOpsは既存（Brown Field）へも適用すべき、という問題提起からはじめたいと思います。

DevOpsの原理

DevOpsの原理

DevOpsとは、IaC（Infrastructure As Code）による自動化のことかと思われるかもしれませんが、自動化ツールが重点を置くのは「継続的インテグレーション（CI）」と「継続的デリバリー（CD）」です。

リーン生産方式とは？

DevOpsとは、リーンの生産方式の原則をITバリューストリームに応用した結果です。
※ITバリューストリームとは...ビジネス上の仮説を立案してから、顧客に価値を送り届ける技術サービスを生み出すまでの間に必要な活動すべてのこと

リーン生産方式とは、トヨタ生産方式をアメリカ人が体系化したもので、リーン（lean）とは「ぜい肉の取れた、ムダのない」という意味です。
まずは顧客に提供する価値、製品サービスにおいて、それを生産するために必要な活動すべてをバリューストリーム「価値の小川」として定義します。その定義に沿ってムダを取り除くことによって、よどみない流れを構築する手法です。

リーンで体系化されるムダ

DevOpsが単なる自動化ではないことをご紹介するために、リーンからアプローチをしてみましょう。リーンでは、徹底的にムダを省くために「散乱」「手渡し（分業）」「希望的観測」の3つのムダに分類します。

まず「散乱」とは、知識が必要な場所に届くのを妨げる組織改正や負荷変動のこと。組織改正や増員は人が換わることにより情報の伝達を妨げますし、督促や交渉による緊急対策は本業以外の負荷が発生します。距離、スキル、階級などのコミュニケーションの障害も情報の伝達を妨げます。
続いて「手渡し（分業）」とは、責任、知識、行動、フィードバックの分離のこと。アプリケーション、インフラストラクチャー、顧客、SIer、上流設計者、プログラマー...など、各専門領域において組織プロセスが分離していることで、多くの待ちや無用な情報を生み出します。
「希望的観測」とはデータなしに意思決定をすることです。ウォーターフォールの場合、初期に期待利益を予測し、一通りの仕様を確定しなければなりません。特に外部環境による影響を大きく受けるため、儲けが不透明なプロジェクトにおいては手間暇のムダが発生します。今後読まれることもないドキュメントを作成することも、希望的観測のひとつです。

DevOpsに関わるデプロイパイプラインのムダ

DevOpsに関わるデプロイパイプラインのムダは3つです。

最も取り除くべきムダは「手作業」で行われる、環境の構築、ビルド、テスト、デプロイのムダです。そして、影響範囲の認識や関係者の調整・承認に多くの時間を費やす「密結合なアーキテクチャ」、本番環境に変更が反映するまでのリードタイムが長期化したり、休日に敷かれる緊急体制によってムダが生じる「長期化するデプロイ」も挙げられます。

技術的負債

ITバリューストリームのムダは、以下のような技術的負債を引き起こします。

• ・障害が続き本業が手につかない（過負荷）
• ・変更が恐く許可しにくい（回避策中心）
• ・超人的なエンジニアがいる（属人化）
• ・緊急体制が頻繁に敷かれる（コスト増）
• ・変更が長期間凍結されている（生産性低下）
• ・デプロイ結果が毎回悪い（品質低下）

これらの状況がひとつでも当てはまれば悪循環の疑いがあります。また、時には無力感を感じさせたり、システムに囚われていると感じたりするような、人的損失を引き起こすことも考えられます。
DevOpsにおける流れの原則は、こういったITバリューストリームに潜む多くのムダと技術的負債を取り除くことを目標としているのです。

リーン思考におけるプルとバッチサイズ

リーンの流れに則ると、「バッチサイズ」「プル」がムダを取り除くための重要な考え方となります。
旧来の生産における効率化の考え方は、大バッチにおけるプッシュでした。ウォーターフォールがこれに当てはまり、例えば仕掛品が多くなる、リードタイムが長くなる、エラーの発見が遅くなる、手戻りが増える、といったデメリットが挙げられます。完成にかかるまでのリードタイムが、仕掛品の数、各工程のスループットによって決まるためです。また、大バッチは各工程の生産管理を複雑にしますから、多くのボトルネックが生まれ、リードタイムがさらに伸びることになります。
これに対し最も効率的な流れは「プル」による受注生産、一個流しです。仕掛品はなく、リードタイムが最小化され、エラーの発見が早くなり、手戻りを減らすことができます。

リーンの組織

ムダを省くために重要なのが「組織」と「文化」です。
従来の「官僚主義的分業組織」では、他人が決めた価値に従ったり、与えられた専門作業に集中したり、開発者の進捗報告を信用することで管理が行われていました。情報はプッシュによる手渡しで、フィードバックをしなかったり、現場にいない責任者が最終承認をします。
これに対してリーンの「責任と信頼の組織」では、全員が製品サービスの価値向上を目標とし、多方向で全体の流れに集中し、状況を常に把握して自己組織化します。そしてオープンな情報の場から、自らプルで情報を取得して、現場のリーダーが承認します。

慢性的な対立

では、なぜこれほど多くのムダが生まれるのでしょうか。その背景には、Dev（開発）とOps（運用）の慢性的な対立があります。

開発（アプリケーションの組織）の関心事は「競争地図の急速な変化に対応する」こと。それに対し、運用側（インフラストラクチャーの組織）の関心事は「顧客に対して安定して信頼できるセキュアなサービスを提供すること」です。
同じ原理であるアジャイル開発は開発プロセスに焦点を当てますが、DevOpsでは運用側にも注目し、この対立を解消するための文化と役割の制約に焦点を当てます。

3つの道

それでは次に、リーンを応用したDevOpsの3つの道＝原則を示します。

「フローの原則」は、リーンの流れと同じです。開発から運用、それからお客様に仕事の成果を送り届けるまでの流れを加速する方法として、継続的デリバリーを取り入れて実現します。
「フィードバックの原則」では、後工程に不具合を流さないために、早い段階で問題を収集して可視化し、開発側へフィードバックします。
「継続的な学習と実験の原則」は、日常の業務の一部として、改善のリスクを組織的に引き受けるための高信頼マネジメントの文化と科学的アプローチを奨励することです。つまり、事故や失敗から学び、実験と学習を繰り返し、学習する文化を組織に根付かせる活動のこと。例えば、本番環境にエラーを注入し、システムの回復力を鍛える、などです。
DevOpsのビジネスバリューとして、デプロインの頻度は40倍以上、デプロインリードタイム復旧の早さは200倍をゆうに超えるといわれています。