何を自動化するか厳選し、テストは可能なものから先行する
第3の事例は「Opsから変えて見たら」というアプローチだ。この会社は開発と運用が分離しており、上層部から「ビジネスの変革が必要では」という問題提起がなされた。
運用部門の課題はコスト削減であり、多くの部門から依頼されている作業をいかに効率化できるかが焦点となる。一方、開発部門に求められているのはリリース時期の死守で、いかにスケジュールを守り、さらに前倒しできるかだ。
ここでもやはり、最初に考えたのは自動化、特に運用に関わるデプロイの自動化だ。運用部門が主体的に動いて、開発部門が作成した手順書の手作業を自動化し、運用部門の人員ゼロを目指す。これで開発部門も自動化してくれれば、リリース作業をスピードアップできる。
ここで「気づいたこと」は、アプリ、チームごとのデプロイ手順がバラバラで、標準化、パターン化しにくいということだ。さらに運用部門と開発部門が対話するなかで、色々なギャップが明らかになった。例えば、同じ用語でも両者の意味合いが違うことや、ITIL的な考え方と開発的な考え方の対立が見られた。
運用側にもスキルフルな人員が多くいるが、コードは読めるにも関わらず開発経験が少ない、という気付きもあった。そのため、何か自動化する仕組みを作ろうとしても、プロジェクトをマネジメントする、要件をまとめるといった観点では無理が生じた。そもそも要員をゼロにするのは無理。デプロイ以外にも様々な運用業務があるからだ。
そこで「陥ったこと」とは、薔薇色の計画を立て、そこそこの実践をした結果は無残なものということだった。半年の予定が倍の1年かかり、開発部門から要員を追加した結果、コストが3倍になった。しかも効果は限定的。
そこで、「見直すべきこと」。コードは誰もが書けるわけではない。個人のキャリアや興味が違ってくるので、全員がコードを書けるというのは中々難しい。では、コードを書ける開発部門と運用部門を合体させれば良いのかといえども、その場合はどのように統合するのかが中々難しい。また、開発と運用の両部門がそれぞれ、相手が何をしているのか、理解していないことも多い。
それぞれの壁をどう乗り越えればいいのだろうか。まず壁が何かを知り、どう壊せばいいかを考える。川瀬氏は「今後、運用環境が変わり、プロセスなどを見直す必要があると考えている」と語った。
もう一つの観点は、何から始めるのかということだ。すべてを自動化するという方法もあるが、やはり効果があるものを洗い出し、棚卸ししてやっていく必要がある。「80：20」の法則ではないが、川瀬氏の経験では2割程度をきちんと標準化すると、8割ぐらいの効果が出てくる傾向がある。
川瀬氏は最後にIBMのDevOpsソリューションを紹介した。数多くある中で今回選択したのは「IBM DevOps Solution for Shift Left」。
このShift Leftは、作ってから受け手に届けるまでの距離／時間を短くするという考え方に基づいている。たとえば最終的に統合する複数のアプリを開発している場合、最終ゴールの統合テストに直進するのではなく、左にシフトして速い時期から可能になった部分の統合テストを先行しておく。3つのアプリの接続数は3だが、9のアプリでは36、12倍になってしまう。
Shift Leftのポイントをまとめると以下の3つになる
- より速い時期での統合＆テスト
- 今の工程よりも一つ前の工程の見直し
- 前部門による次部門業務の理解
IBM DevOps Solution for Shift Leftは、DevOpsの実現に寄与すると期待できる。
川瀬氏は最後に「デブサミ」にかけて以下の4節を披露し、セッションを閉じた。
- デ：デプロイだけでなく
- ブ：部分最適でもなく
- サ：最初から最後までを
- ミ：皆仲良くやっていきましょう
