次世代型統合開発プラットフォームの構築・活用によるDevOps実践事例（後編）
～　IT企業の在り方をボトムアップでひっくり返すDevOps　～

2018/05/24

2018年3月2日、特定非営利活動法人 itSMF Japan主催の「itSMF Japan 第65回セミナ」が開催されました。今回は「DevOps」にフォーカスしたこのセミナで、NTTコムウェアにおけるDevOpsの取り組みと、導入や実践に伴う課題と解決策について講演してきました。

何を獲得したいのかという本質的なKPIを定める

続いて、進め方に属する課題に移りましょう。
「何でもいいから、とにかくDevOpsをやれ！」このようなことを、部下に言ったり上司から言われたりした経験はありませんか。そんな命令が飛びかう現場では、さぞかしDevOpsは迷走することでしょう。

「DevOpsとは何なのか？」と同じように、「どうあればDevOpsを実践できたといえるのか」というのも重要です。プロジェクトが今どの位置にいて、次はどこを目指すのか。つまりDevOpsの成長と達成条件（KPI）をあらかじめ設定しておくことが大切です。

ただし、「どのような解釈をしてでも数字の上でKPIを満たせばいい」というような指標は、もうこの先のビジネスに通用しないでしょう。表面上の数字ではなく、「この取り組みで何を得るのか」という本質的なKPIをプロジェクト自身が設定し、メンバー全員がアグリメントする。そして、その約束をメンバー全員がコミットしていくことが重要です。

長期・大規模開発ほど重要なポートフォリオ

エンタープライズの大規模システムをアジャイル開発する場合、ただひたすらスプリントを積み上げていくだけでは、いずれ無計画と大して変わらなくなってきます。そこで、開発ポートフォリオというものが欠かせません。

SoR開発が根付いている企業でSoE開発を上手くコントロールするには、開発上のマイルストーンと、企業に必要な計画や手続きであるビジネスイベントを紐づけて、短期から中長期視点で考える必要があります。このためには、タスク実行の単位、プロダクトリリースの単位、ビジネスプランの単位でそれぞれ検証を行うタイミング（区切り、節目）を設けます。

例えば、私のプロジェクトでは、次のようにフレームを定義しました。
・Sprint（スプリント） - 3週間（タスクの実行周期、最短のリリース可能周期）
・Season （シーズン）- 3か月（標準リリース周期、品質評価単位、資産計上単位）
・Vision （ビジョン）– 12か月（投資計画等予算単位、開発計画策定、中期ビジネス戦略）

これはMicrosoft社の考え方を参考に、自身のプロジェクトに合わせて再定義したものです。個々の企業やプロジェクト、さらには置かれている環境などによっても異なってくると思います。私のプロジェクトでは、3週間のスプリント、3ヶ月のシーズン、12ヶ月のビジョンという設定が、開発マイルストーンとビジネスイベントとの親和性が最も高いと判断しました。

継続的リリースにおける運用の解決

継続的リリースを開発部門と運用部門でどう解決するかはDevOpsの根幹にかかわる重要な課題です。継続的リリースが行われないアジャイル開発では、一括リリースか、ステージング環境への継続的デプロイになると思います。いずれも悪いという訳ではありませんし、その目的をもって（例えばBlue-Green Deploymentなど）実践しているケースもあるでしょう。

しかし、継続的リリースの本質は、お客さまが切望するものを何よりも優先してかなえる、というのがポイントです。お客さまが「いつまでに世に出さなければ市場で勝てない」と願うものは、緊急でリリースできるようにしておかなければなりません。

重要な機能だけは、作ったらすぐにリリースできるプロジェクトであれば、もしかしたら、スプリントごとにリリースをしなくて良いかもしれません。緊急以外は、シーズンごとに一括リリースすることもできるかもしれません。それによって、運用への引き継ぎ・引き渡しは今のままでも、運用負担を軽減できるかもしれません。
「そういうのはDevOpsじゃない」そんな声が聞こえてきそうですが、それでビジネスの広がりを見出すという目的が達成できるのであれば、外形的な論争に加わる必要などまったくありません。

気軽には変えられない「組織」

組織構造がサイロ型、というのが組織課題の中心にはありますが、気軽にメスを入れられるものでもありません。やって成功する保証もなく、やらないで済むならやりたくない、まさに、そんな課題でしょう。

当初、私のプロジェクトは、企画部門を中心に、インフラ構築を手掛けるインフラ運用、カスタマサポートを行うシステム運用、そして開発部門の四部門で構成されていました。各部門にはそれぞれPMが存在する典型的なサイロ型組織です。この組織構造で企画部門がすべてのハブを担ったため、当然スキルと稼働が足りなくなり、開発部門から人員を異動させて対応しました。すると、開発が進むにつれ開発部門の人員不足が顕著となり、今度はインフラ運用から有識者を異動させて対応することになりました。

きっと次に訪れるのは運用部門の人員不足です。このように、付け焼刃でその場を乗り切っても、いずれ限界が来るのは明らかです。どうだったら良かったのかといえば、最初からDevOpsに必要な人員を一部門として編成してしまえば良かったのです。しかし、それは企業全体の環境を無視した利己的な結論にすぎません。

エンタープライズでDevOpsがなかなか定着しないのは、単一事業で会社が成り立っている訳ではないからです。ひとつのシステム開発が終われば、開発プロジェクトにとってそのシステムは閑散期になります。このためプロジェクトは新たな収入源となる別システムの開発案件へ移ります。DevOpsの数だけ無尽蔵にリソースを注ぎ込めるなら別ですが、現状では、開発部門が運用を担うためにいつまでも同一案件に残るのはナンセンスな話です。

つまり、エンタープライズにおいては、組織体と組織機能を変えずにDevOpsに有効なコラボレーション形態をとれるか、これが成功の鍵になります。

SoEに最適化したルール「DevOps特区」

これまで企業内のありとあらゆる仕組みはSoRに最適化されていました。そのような状況でSoEを実践しようとすれば、もっとも面倒なのは社内ルールへの適合です。しかし、どんな会社でもすべてを一斉に変えることは、さすがに難しいでしょう。やはりSoEは少数派ですし、大多数のSoRは残ります。

このような場合、大多数が適応している全社の基本ルールを変えるよりも、少数派であるSoEのルールを別に作るほうがはるかに合理的で無理がありません。いわば「DevOps特区」を作るのです。NTTコムウェアでは、SoE開発でもSoRと同等のコンプライアンス・ガバナンスだと評価できる代替案を社内関係各所で誠実に話し合い、DevOps特区の合意に至りました。現在、可能なプロジェクトからSoEへの移行を精力的に行っています。

企業でこういう事を言い出すと、「無法地帯を作りたいのか」と勘違いされ、敬遠されるかもしれません。しかし、その意義を理解してもらう事から逃げたり、手を抜いたりしてはいけません。社内に敵を作ったままでは、お客さまとの関係性を深めることもできません。

IT企業の在り方をひっくり返す力

これまでも、開発効率化、品質向上やコストダウンを焦点にしたムーブメントは何度かありました。しかし、DevOpsは「ボトムアップで企業の在り方をひっくり返す」可能性を秘めた、ITでは初めてのムーブメントではないでしょうか。　NTTコムウェアではDevOpsの意義を、「お客さまのビジネスのために活用し実践することで、お客さまと共に自分たちも勝つためのもの」と考えています。目先のコストダウンのためにDevOpsを捉える向きもありますが、お客さまと一緒に勝ち続けるDevOpsのほうが、ずっとエキサイティングではありませんか？