The Doppler Quarterly (日本語) 秋 2017

DevOps とプロセスレガシープロセスがかかわるほとんどすべてのエンゲージメントで見られる 1 つの共通の失敗は、自動化を進める前にこれらのレガシープロセスに十分に注目し、分析しないことです。その結果、企業は無駄な自動化を実行してしまい、期待していた俊敏性の利益を実現できません。たいていの場合この失敗の原因は、サイロと、サイロ間のインセンティブの不一致です。開発者はそれぞれ自分のサイロで作業し、 CI/CD を実装します。構築プロセスにおける時間と品質の面では劇的な改善が見られますが、通常、市場投入時間のメトリクスにはほとんど変化がありません。これはなぜでしょうか。それは、半年に 1 度の間隔でリリースしていた時代に作成された 20 ∼ 30 年物のレガシーの変更制御プロセスがあり、それに対処していないからです。私はこれまでに、自動構築を実行できるようになる前にお役所仕事によってプロセスが数週間から数か月も膠着状態となる事例を多数見てきました。さらに、自動構築の後にコードを本番に昇格するには、さらに数週間から数か月の膠着状態があるのです。それでも、チームはまだ CI/CD を完成させることのみに焦点を当てています。エリヤフ・ゴールドラットの『The Goal』( ザ・ゴール - 企業の究極の目的とは何か ) を読んだことがある人ならば、誤ったボトルネックに対処してもシステム全体の流れを改善できないことを理解しているはずです。それでは、ボトルネックをシステムの別の部分に移しているだけなのです。企業がシステム全体のバリューストリーム評価を実施せずに CI/CD の実装のみを実行する場合、ボトルネックを構築プロセスからシステムの別の部分に移動するだけになってしまいます。したがって、望み通りの俊敏性は決して達成できません。エンジニアは、システムの 1 つのコンポーネントのみを自動化することに焦点を当てるのではなく、システムを 68 | THE DOPPLER | 2017 年秋号

The Doppler Quarterly (日本語) 秋 2017 | Page 70