DevOpsのテキスト研修
DevOpsを導入していないIT部門にはどんな課題があるか
DevOpsのないITの現場では、開発チームと運用チームが対立しがちです。顧客が求める機能や便益の品質を全体で確かめ始めるころには、開発チームはまったく別のプロジェクトに取りかかっています。情報セキュリティと本番稼働の準備状況の監査は、予定された本番展開の前日です。この重要な段階になってソフトウェアの問題に対処すること、特に8か月前に見つけて修正しておくべき設計上やセキュリティ上の欠陥を直すことは、ITだけでなく、事業を継続するうえでも問題になります。疲れ切った開発者、非協力的な運用部門、縦割りのテスト部門と情報セキュリティ部門、要求は多いものの追い詰められたプロジェクトマネージャーとプロダクトマネージャー、怒っている経営陣、不満を抱えた顧客とITのステークホルダー。これでは付加価値はほとんど生まれません。
あらゆる方向に作業の引き継ぎや依存関係が張り巡らされ、調整されず、手作業で、中身が見えない作業が無数にある。IT部門では、それがいつもの一日です。
どんな作業にも長い時間がかかりますが、少なくとも今は、よりよい選択肢がありません。生活のためにこの仕事が必要なこともわかっています。
ついに本番当日がやってきます。問題が相次ぎ混乱したデプロイにより、事業に大きなダウンタイムが生じます。既存の本番機能が壊れていないか心配になり、本番システムで実際に何が起き、何が影響を受けたのかを示す明確な情報も具体的な証拠もないことに気づきます。
それでも、大きなIT部門の廊下ではすでに本番稼働を祝う声が聞こえます。あなたも一杯飲んで、眠れなかったつらい夜から気持ちを切り替える頃です。昨夜あなたが本番環境で壊したものは、どうせ誰か別の人の問題になります。大したことではありません……。
これほど悲惨で行き詰まった状態に陥ったプロジェクトが、なぜどうにかして終わるのか、不思議に思うかもしれません。その答えの手掛かりは、 無限の猿定理にあります。簡単に言えば、猿がタイプライターのキーを無作為に無限の時間たたき続けると、いつか必ず、たとえばWilliam Shakespeareの全作品のような、ある決まった文章を打つという定理です。冗談ではありません。
これと同じように、いつ作業が終わるかは予測できなくても、ITチームが十分に予定を延ばして時間を確保すれば、いずれそのプロジェクトを届けられます。
開発と運用の慢性的な対立
IT組織の数多くの重要な責任のうち、主な使命が二つあります。
- 開発チームは、顧客と自社が事業を展開する市場の変化する要求に応えるため、すばやく成果を届ける必要があります。
- 運用チームは、顧客と市場に、安定した予測可能で安全なサービスを継続して提供する必要があります。
IT組織がこのような構造だと、開発チームと運用チームは使命も動機も相反します。この対立により、生産性、サービスの品質、顧客満足度、IT部門の成果、そして最終的には事業全体の業績まで低下します。
気がつけば技術的負債を抱えている
その場をしのぐために火消し、回避策、計画外の対応を繰り返すと、技術的負債は増えるばかりです。開発と運用のパフォーマンスだけでなく、アーキテクチャ、情報セキュリティ、テスト、製品管理、リリース管理、事業側のステークホルダーなど、他のすべての部門や関係者にも悪影響が出ます。
技術的負債は、金銭的な借金にたとえられます。借金が増えるほど、目標を達成するための選択肢は減ります。最終的には、望む結果を得るために正しい判断を下すことがほぼ不可能になり、さらに借金を重ねる可能性が高まります。
技術的負債も同じです。負債が増えるほど、適切な解決策を構築し、届けるための選択肢が減ります。やがて回避策の上に回避策を重ね、トランプの家の上に、またトランプの家を建てることになります。すべてが崩れるのは時間の問題です。すでに身に覚えがあるはずです。
最も壊れやすいシステムが事業の収益を支えている
驚くことではありませんが、事業に欠かせず収益を生むシステムほど、エラー、クラッシュ、ダウンタイムが起きやすいのは、気がかりな事実です。
通常、これらのシステムは事業の中心にあり、どの会議でも何らかの形で話題に上ります。ほぼすべてのプロジェクトが影響を与える、最も重要なシステムです。事業への影響が大きいため、継続的な作業、緊急変更、計画外の修正が必要です。それでも優先度1のインシデントは後を絶ちません。
一つの約束を破ると、さらに大きな約束をする
IT組織が何度も約束を破ってステークホルダーを失望させると、関係者は過去の埋め合わせを求め、さらに厳しい要求をします。もっと良い仕事が決まってでもいない限り、あなたや上司にできるのは「いいですよ」と答えることくらいです。
そうしてソフトウェアの開発・デリバリー組織は、いつもより大きな課題を任されます。重要なシステムもITアーキテクチャも、指定された「緊急」の期限内に要件を満たせる状態からは程遠く、既存の回避策にまた新しい回避策を重ねることになります。
仕事が楽しくなくなる
やがて全員が少しずつ忙しくなります。自分が雇われ、報酬を受けている本来の仕事に、途切れず1時間取り組める余裕が予定表になくなります。メールは雨のように届きます。会議の生産性が低い時間を使って、不明瞭で要領を得ない受信メールを確認し、片付けます。メールの使い方と書き方を教える必須研修が、なぜ組織にないのか不思議になります。
自分の仕事を進めるには、たいてい他のチームの力が必要です。それでも、数週間前に伝えた要望は相手チームの視野にすら入っていません。壊れやすいソフトウェアが引き起こした優先度1のインシデントを9件解決しながら、新しい「Horizon 2400」プロジェクトを始めたばかりなのです。
自分の作業を進めるため、相手チームの唯一の窓口に指定された担当者から回答が必要で、あなたは少しずつ焦り始めます。
待ちきれず、依頼の念押しのメールをもう一通送りました。今度は担当者の上司をCCに入れ、最初の依頼からそうするべきだったと考えます。
数秒もたたないうちに、不在通知が二つ表示されました。相手チームの窓口は今週末まで「Horizon 2400」のワークショップに参加中で、その上司は今日は病欠です。
まとめ
この章では、ほとんどの企業とITプロフェッショナルが直面する課題を解説しました。ほぼすべての企業とプロフェッショナルが、こうした悪循環と負の連鎖の中で仕事をしています。
Gartnerの推計では、世界の企業は収益を生むITシステムの稼働を維持するため、予算にも計画にもないIT保守に年間約6,000億米ドルを浪費しています。数字で書くと、$600,000,000,000.- です。
ここまででおわかりのとおり、情報技術のように高度な思考を要する専門分野で、これほどのムダが生じることは簡単には理解できません。
取り組む価値のある課題です。DevOpsは、いくつかの企業に答えをもたらし、あなたの企業にも役立つかもしれません。もちろん、実験し、学び、適応する準備ができていることが条件です。
