次世代型統合開発プラットフォームの構築・活用によるDevOps実践事例（前編）
～　DevOpsが生まれた背景と最初に取り組むべき課題　～

2018/03/30

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

市場の変化に対応するために生まれたDevOps

顧客とのつながりを重視するSoE（Systems of Engagement）。昨今のITシステム開発では、このSoEが注目されています。SoEでは、顧客との継続的な関係性を重視し、フィードバックを俊敏に取り込むことができる開発技法、すなわち、アジャイル開発が必要になってきます。しかし、アジャイル開発のように機能を逐次段階的にリリースしていくと、ある問題が発生します。それは開発から運用への引き継ぎ、引き渡しにおける問題です。

従来ならば、開発したITシステムのリリースに伴い、システム操作ドキュメント、運用操作ドキュメント、運用者による運用テストなど、開発から運用への引き継ぎ、引き渡しが行われますが、新しい機能や操作が頻繁に提供されることになれば、開発も運用も、この引き継ぎ、引き渡しへの対応が困難になってきます。

このトレードオフを解消するために、「開発者も運用作業の一部を担えるようにすれば、それこそ１日に10回でもデプロイできるのではないか」というアイデアが生まれました。しかし、運用部門はシステムの安定稼働を顧客に保証するのが命題ですから、開発部門にはシステムを触らせません。そのハードルを越えて、「開発と運用が互いに尊敬、信頼しあうことで市場の変化、そのスピードに対応していこう」とする試みが、DevOpsの始まりといえます。

現代DevOpsは開発と運用の協力にとどまらない

なぜ1日に何回もデプロイしたいのか。バグが多くて1日に何度もプログラムを入れ替えたいというわけではありません。お客さまの導線が良くなるならすぐにリリース、お客さまから要望されたらすぐにリリース、ページビューが増えるならすぐにリリース、レーティングが上がるならすぐにリリース。このように、お客さまが自社のITシステムを利用することで得られる価値を最大限に高め、そして常に発展させる。このシーケンスの繰り返しによって日々のデプロイが増えていくのです。

アジャイルが機能要求の顧客体験を俊敏に取り入れるように、DevOpsはビジネスの顧客体験を俊敏に取り入れるフィードバックサイクルを形成します。

ですから、「開発と運用が互いに尊敬、信頼しあうことで市場の変化、そのスピードに対応していこう」とする試みに加え、「ITシステムが提供する価値を最大限に高め、それを日々実践することでビジネスを継続的に発展させていく」。これこそが現代的なDevOpsといって良いでしょう。

DevOpsの真のゴールはビジネスの広がり

顧客体験のフィードバックを俊敏に取り込もうとすれば、開発・運用・企画といった多くの部門が１つの循環サイクルを形成することになります。このように目標も文化も異なる複数のグループが、システマチックな業務フローでは表現できない浅からぬ接点を持つようになると、ここに、さまざまな課題が顕在化してきます。これらの課題は、これまでのビジネスのために形成された最適形態、いわゆるサイロ型組織の弊害といえます。

それら課題の解決こそがDevOpsの本質であると、NTTコムウェアでは捉えています。そして我々の目指すDevOpsは、ITシステムが生み出す価値に顧客体験を還元することで、ビジネスの広がりを見いだそうとするものです。この考え方は、この先迎えるデジタル・トランスフォーメーション時代にも通じるものです。

DevOpsの実践は、すなわち、お客さまのために、組織と人と情報と技術にまつわる課題を解決することに他なりません。

続いて、どのような企業でもDevOpsの導入にあたって立ちはだかる課題について、自身の経験に基づいて説明します。

まずDevOpsに取り組む意義を理解する

最初の課題は、DevOpsに関する「目線合わせ」です。これまで「個人の考えで進めず、作業標準に従って進めろ」と指示されていたのに、ある日突然、「これからの時代はSoEだ。お客さまとの関係性を重視して各人が考えて動け」と言われても、すぐに切り替えられるはずがありません。まずは、「自分たちがなぜSoEやDevOpsに取り組まなくてはいけないのか」、それを全員がしっかり認識するところから始めます。

次は「行動特性の改革」です。DevOpsを実践するには、開発、運用、企画といった所属部門を問わず、全員が顧客体験を肌で感じる必要があります。極論を言えば、「それを感じない人は、遅かれ早かれDevOpsの妨げになる」可能性があります。そのために、DevOpsチームメンバーがお客さまと接する機会が平等になるよう、ペアリングやスケジューリングには常に注意を払っています。

通常、バックヤードのメンバーは、お客さまと接する機会が少なく、トラブルが起こっても矢面に立つことはありません。しかし、お客さまと一度でも会って話したことがあるのとないのとでは、同じ意見を言われても、受け取り方がまったく変わってきます。面識があり、お客さまの考え方が理解できている場合は「なるほど、言っていることは間違っていないな。努力して要望に応えよう」と奮起するでしょう。さらにお客さまと接する機会が増えれば、やがて「お客さまの潜在的欲求」なども自ら考えられるようになります。

このような変化が、どんな自動化ツールの導入よりも重要であると思うのは、私だけではないはずです。

＜後編では、DevOps導入の具体的な進め方に関する課題と解決策について紹介します＞