アメリカでは自動車・金融・流通など大企業にもすでにDevOpsが浸透
加藤：DevOpsの先行市場であるアメリカでは、現在どのようにDevOpsが実践されているのか、その傾向をIDCではどう把握していますか。
入谷：アメリカでのDevOpsの変遷を振り返ると、2009年にDevOpsという考え方が登場し、そこから4～5年間は多くの人がどう実践したら良いのかを考えていた時期です。2013～2014年ごろから、Webサービス、ソーシャルサービス、クラウドサービス、ゲームなどのエンジニアたちが、自分たちのサービスや製品の開発でDevOpsに取り組み出しました。ここ2～3年の傾向では、製造業や金融機関、流通業など、いわゆる大企業がDevOpsを実践しようと取り組み始めています。
加藤：ベンチャーやスタートアップだけではなく、製造業や銀行など、ある意味お堅い仕事の巨大企業までがDevOpsに真剣に取り組んでいるのは、少し驚きです。
入谷：例えば、自動車だとゼネラル・モータース、金融だとシティグループなど、トラディショナルな大企業がすでにDevOpsを進めています。私は2017年5月にアメリカでのDevOpsの事例を調査してきましたが、製造、流通、金融機関のIT担当者が、当たり前のようにDevOpsの実践経験を話していて、その浸透度に驚きました。
加藤：すると、DevOpsの成功事例でも目を引くようなものが出てきていますか。
入谷：DevOpsで有名な事例は、全米でトップのディスカウントチェーンであるターゲット・コーポレーションの事例です。そこでは最初、4人程度のエンジニアが自分たちで勉強会やハッカソンを開き、サービス開発の工数を減らす取り組みをしていました。その取り組みからデプロイが多くなったというような「小さな成果」が積み重ねられていき、一緒に参加したいという人たちが社内に次々に増えていったと聞いています。現場からDevOpsというムーブメントが生まれ、その成果をトップに示すことによって、最終的にはトップダウンでDevOpsが全社的な戦略となったのです。DevOpsのベストプラクティスとしてよく知られています。
DevOpsの根本は「人と人の取り組み」コミュニケーション・スキルが求められる
加藤：ボトムアップ型でのDevOpsの成功事例を伺いました。現実的にはボトムアップ型でDevOpsを実践しているケースが圧倒的に多いようですね。その一方で、DevOpsについては、従来の開発プロセスの改善運動とは異なり、経営要請から来ているという見方もあります。だから、「トップダウンでやるべきだ」という考え方です。DevOpsサイクルの構築でトップが果たすべき役割は何であるとお考えですか。
入谷：DevOpsの事例を見ると確かにボトムアップ型が多いです。その視点で経営トップが果たすべき役割は、ボトムアップ型で走り始めて小さな成果が見えてきたときに、その成果を正しく評価することです。これはDevOpsが成功するかどうかの大きなポイントになると考えています。もう1つ、トップの役割として重要なことは、DevOpsを現場に考えさせるきっかけを作ることです。
加藤：一方で経営側がDevOpsサイクルの実現のために現場に求めているのは、どのような人材なのでしょうか。
入谷：ある金融サービス会社が新サービス開発のためにDevOpsを実践するにあたって、その担当者と必要となる人材について話をしたことがあります。人材に求める要件は、「アプリケーションを開発できること」、「DevOpsのツールを使えること」、さらに「金融の業務を理解していること」でした。その要件で募集したら「応募が一切なかった」そうです（笑）。しかし、企業の経営側はDevOps推進のために、「スーパーマン的」な人材を求めがちです。
加藤：自社での育成には時間も費用もかかるということですか。
入谷：しかし、実際には「スーパーマン的」人材を探す方が、時間がかかってしまいます。とりわけ自社のサービスを熟知しているのは、当然ながら自社の人材です。社内にいるから教育がしやすい環境にもある。つまり、「スーパーマン的」人材を外部に求めるのではなく、教育していくことが求められていくのです。
加藤：一定規模以上の企業になると、自社のすべての業務を経験し理解している技術者は非常に少ないと思います。ツールの使用に長（た）けている技術者が業務を知っているとは限らないのです。断片化している業務知識やスキルをうまくつなぎあわせながら、ツールも活用してDevOpsとして「まとめ上げていく」ことが重要になると感じています。その一方で、「DevOpsは概念なので、技術者に求められるスキルセットが変わるわけではない」という考え方もあります。DevOpsの実践で必要とされるスキルとは何か。さらには、お客さまのビジネスを支えるという観点で新しいスキルセットが必要なのか、そのあたりをどうお考えでしょうか。
入谷：DevOpsを部署や部門の垣根を越えて「協力するプロセス」と考えると、サービス開発など目的達成のためにさまざまな人材が関わってくることになります。その上でDevOpsをいかにスムーズに進めていくかが大切になる。そうなると、すべてのことを一人の人材が理解している必要はなく、それぞれが「自分の役割をきちんとこなす」ことのほうが大切になります。DevOpsを進めていく人材にもっとも重要なのは「コミュニケーション能力」だと考えています。プロセスはツールで自動化できたとしても、DevOpsの根本は「人と人との取り組み」です。
DevOps成功のポイントは小さく始めて大きく育てる
加藤：当社では2017年7月20日に開発環境クラウド「SmartCloud DevaaS 2.0」（以下、DevaaS 2.0）をリリースしましたが、この開発の中で、私自身がDevOpsを実践・体験しました。その経験からDevOpsを実践する課題も体感しました。私は当時、開発にいましたが、DevaaS 2.0の本格開発着手と同時に運用に移りました。運用からも同様に開発へ人材が移り、開発・運用合同の「DevaaS 2.0」プロジェクトが始まりました。そのプロジェクトの過程で、私は「自分が思っていた以上に開発の言葉は優しくない」と感じました。自分も開発側にいたときはきっと同じことを言っていたのだろうと、複雑な心境になりました。例えば、開発側はなるべくシステムが複雑化しないようにしたい。でも手順の複雑性は考えずに、「それは運用側のサービスオーダーで対応してくれ」と言ってくる。それでは運用側の負荷が大きくなってしまう。そう、自分自身の考え方がいつのまにか運用にシフトしていたのですね。でも、私と同時に開発から運用に異動したメンバーは、開発とうまくコミュニケ―ションを取っていました。もともと開発にいたから開発側と話が通じることを利用し、組織間を取り持つファシリテーションがとてもうまくなりましたね。人材の入れ替えには、少なからずマインドの変化を引き起こす効果があり、やはり意味はあると感じました。DevOpsの実践で必要なことは自動化や省力化だけではないことを、身を持って感じました。
図2：DevaaS（Development as a Service）とは
入谷：お互いの作業を経験することも重要ですが、お互いに顔を合わすこともとても重要です。アメリカの大手航空会社がDevOpsをやった事例では、開発と運用をコラボレーションさせるための基盤を作りました。どういう人が何をやっているかをコラボレーションのツールで分かるようにして、しかも顔だけでなく趣味までも分かるようにしたのです。ようするに「Facebook」みたいなものをDevOps実践のために導入した。コミュニケーション基盤を作り、DevOpsを推進したら、コミュニケーションが非常に活性化されて助け合いが生まれたそうです。
加藤：開発や運用のリーダーがお互いに自身の仕事ではないと突っぱねたとしても、現場の担当者同士が理解し合えていたら何とかしようと動くでしょう。「目に見えない円滑さ」は、コミュニケーションからしか生まれないと思います。そういったことは頭では理解していても、組織や体制にメスを入れるのは、企業としては勇気がいることです。一定規模以上の企業で、DevとOpsが同じ組織になるということは実際にはありえないのではないかと思います。こういうケースで、DevOpsサイクルをうまく構築するには、どのようなことに注意をしたらいいのでしょうか。
入谷：大きな組織だとDevOpsも大きなサイクルになって、すべての人が関わろうとすると、逆にうまくいかなくなります。できるサイズの組織からDevOpsのサイクルを作っていくのがベターです。プロジェクト単位でDevOpsのチームとサイクルを作って、小さく始めていく。いくつもできあがってくると関わる人が増えてくるので、少しずつ大きなサイクルになって回しやすくなります。
DevOpsサービスプロバイダーとしてNTTコムウェアが提供する価値とは
