組織は手段、大事なのはそこに込めたメッセージ--さくらインターネット田中氏がクラウドネイティブ時代の組織論を語る

なぜDevとOpsのコミュニケーションが重要になってきたのか

新野淳一氏（以下、新野）：今までの議論の中で、アプリケーションの開発の人たちと運用する人たちは密接にコミュニケーションしなければいけないという話がありましたが、今の藤原さんのお話だと、設計にまで踏み込んでやらなければいけない。たぶんさくらインターネットの中でもそういうことが起きているような気もするんですけど、そういう人は意識的に育てていますか？

田中邦裕氏（以下、田中）：それで言うと、現場任せというのが実情なんですね。とはいえ、やはり最近はラックの設計をする人とか、サーバの選定をする人とか、オーケストレーションのシステムを作る人とかが一緒に仕事し始めていますね。

以前はウォーターフォール型の開発みたいなものが整備されていたと思うんですよね。「こういうことなら、こういうサーバを用意してください」というように、それぞれの人が要件を決めてやる。それは悪い話じゃないんですけれども、「なんで自社で全部持っているのに、まるで外注のように仕事をするんだろうか？」ということ。

なので、今もコミュニケーションが重要だけど、実は過去からコミュニケーションが大事だった。それをやるのが面倒くさいから、みんなちゃんと定義書を作って……定義書が悪いというわけではないんですけれども、それにコミュニケーションまで頼ってきていたんだと思うんです。

なので、昔もダメだったのが今は顕在化しているだけなんだろうなと。本当は昔からもっとDevOpsをやらないといけなかったんだけど、昔はやらなくてもなんとなくできたものが、今はちゃんとすり合わせないとできなくなったというだけの話だと思うんです。

新野：なぜできなくなったと思われますか？

田中：それで言うと、粒度が小さいし、いちいち細かいことを定義なんかしていられないですよね。だから横にいて一緒に設計をしないといけないのかもしれないし、いろいろな理由があるので、このあとディスカッションの種になるとは思うんですけれども。

昔だと、ラックやサーバなどは粒度が大きかったので定義しやすかったけれども、先ほどの局所最適化がしやすくなったという話の裏返しですよね。局所でやらないといけないことが多いので、手を携えてやらざるを得なくなっている。ほかにもあると思いますけど、そういうことも1つあると思います。

新野：局所が大事になってきたのは、やはりアプリケーションごとにマイクロサービス化というかサービスがはっきりしてきたからですか？　あるいは、動かすアプリケーションのアーキテクチャが変わってきたからですか？

田中：それもありますけど、コストが下がったのが一番じゃないですか。昔は高かったので大きなものをドーンとやらざるを得なかったんですけれども、今はもうポチッとボタンを押したら数秒でサーバが立ち上がってくるわけなので、それを前提とするのは当たり前だと思うんですよね。

我々は提供する側だからサーバを買いますけれども、なぜいまだに一般のお客様がサーバを買ってるんだろうって……というか、最近はもうサーバを買えないらしいですけどね。5年ぐらい前は売っていましたけど、最近は一般の企業がサーバを買うのは大変なんじゃないかと思いますね。

新野：ほとんどデータセンター向けになっている？

田中：完全にデータセンター向けです。サーバ向けCPUですらもうデータセンター向けに供給されています。

現代のOpsに求められるスキル

新野：ありがとうございます。では藤原さんにもうかがいたいと思います。田中さんがおっしゃったようにどんどんユニットが小さくなっていってOpsとDevが緊密にコミュニケーションするときに、Opsにどういうスキルを要求していて、どうやって育てていますか？

藤原涼馬氏（以下、藤原）：難しいですね。1つ言えるのが、少なくともハードウェア的な作業は自分の現場では消滅しているので、そうなったときに、もちろん上のほうに染み出していかなければいけないです。そうなっていくとやはりソフトウェア的な素養が必要になってくるので、コードを書いていくということが必要になってきます。

コードは、例えばTerraformであったり、Ansibleであったり、いろいろあると思うんですけど、そういったものをインターフェースにしてDevの人とコミュニケーションをとりながら実際に作っていくというかたちになることが多いですね。

新野：コードといってもそこがちょっと違うところですよね。プログラマの人はRubyを書いたりJavaScriptを書いたりするかもしれないけれども、今おっしゃった運用の人たちのコードは、AnsibleのコードだったりYAMLの設定ファイルだったり。同じコードといっても、運用の人のスキルに求められるコードの種類が違うという理解でいいですか？

藤原：そうですね。あともう1つ、大きく変わってきた部分で言うと、ストレージは高いですから、以前はそれをストレージの専門家が負い、ネットワークはコアスイッチなどを管理するネットワークチームがいて、それぞれが守るみたいな世界だったと思いますが、パブリッククラウドを使っていると、コアスイッチやストレージの世界は全部ソフトウェア化されているので、そういう専門家がユーザー側に徐々に必要ない世界になってきている。

そうなってきたときに、もっと幅広く、コードベースで記述できる人、面倒を見られる人、全体のアーキテクチャの絵を描ける人というのがOpsに徐々に必要になってきているのかなと思います。

新野：ちなみに藤原さんは、どちらかというと運用に近い人だとして、ご自身はどうやってそういうスキルを身につけてこられました？

藤原：たぶん私の場合は経歴が特殊で、もともと前職でインフラエンジニアとして仕事をしていて、研究系だったんですが、そのなかでアプリケーションパフォーマンスマネジメントという、「AppDynamics」という製品のプリセールスやポストセールス、技術サポートをやっていました。

そのなかで、インフラも見るけれども、アプリケーション全体で見たときにどういうボトルネックがあるのかとか、その上でデータベースとなったらOracleのチューニングもやらなきゃいけないよねというところで、けっこう幅広いお仕事をさせてもらったなというのは感じているんです。そのなかでけっこう培った感覚かなと思います。

新野：運用監視でも、インフラだけ速く動いていればいいというものではなくて、アプリケーションが速く動かなきゃいけないんだから、アプリから順にレイヤーを辿って下まで見るスキルが求められているフェーズでもあるということですよね。

藤原：そうですね。逆を言うと「インフラは何か異常を出していても、アプリケーションとしてユーザーが使えているんだったら逆にいいじゃん？」という極端な話もできちゃうんですよね。たぶん自分のもっているこの感覚はインフラのエンジニアの中ではかなり異質な感覚だと思うんですけど。

アプリケーション側の運用もみられる人材になるには

新野：青山さんもすごく頷いていらっしゃいます。やっぱりそういうものですか？

青山真巳氏（以下、青山）：そうですね。最近SREの運用を考えなければいけなくなってきているなかでは、インフラの監視をしてインフラがどうだったかというよりは、サービスの継続性を監視しなければいけないという考え方だと思うので、どんどんそっちにいっていますね。

確かに、その裏でもしインフラのどこかが壊れても、サービスに影響がなければ、ユーザーから見たら、サービスの継続性という観点ではぜんぜん問題ないと思って。

新野：運用監視でいうと、先ほどの藤原さんのお話ではストレージ担当やデータベース担当と人も分かれていましたけど、今もツールが分かれていたりするじゃないですか。インフラがちゃんと動いているか監視するツールとアプリケーションがちゃんと動いているか監視するツールと、それぞれスキルが違いますよね。

でも、それを統合的に見なければいけないとすると、アプリケーション側の運用も見られる人になるにはどうすればいいと思いますか？　藤原さん、どうですか？

藤原：自分の経験の話しかできないんですけど、オンプレミスのシステムをやっているときに、最後にVMwareのインフラの上にちょっとAWS的なものを作ろうということで、仮想マシンやストレージをUIから切り出せるツールの開発をさせていただいたんですね。

そういうところって、インフラのエンジニアやオペレーションのエンジニアでないとわからない部分があって、そのなかでけっこう素養を磨くことができたなというのは感じていますね。

新野：田中さんはどうですか？　データセンターを運用するエンジニアとか、ミドルウェアレイヤーぐらいまでを見ているエンジニアがおそらくいらっしゃるじゃないですか。

田中：そうですね。

新野：そういう人たちはどうやって学んでいて、これからクラウドネイティブ的なことを進めていくにあたり田中さん自身はどうやってそういう体制を築いていこうと考えていらっしゃいます？

田中：実際にコードに触れないとどうしようもないところがあって、ラッキングをすると言っても別にラックのマウントだけしているわけではないので。現場の社員の方々は、例えば障害が起きたときの分析をしたりいろいろするわけですけれども、そのプロセスの中で絶対コードを書くはずだと思うんですね。

あとは、もうサーバは設置してQRコードを読んだだけで全部セットアップまで終わるようになっているんですね。いまどきモニターにつないでCDを入れる、ということはしないので。

新野：それは、要するにソフトウェア自動化されているわけですね。

田中：そういうシステムを誰が作るべきなのかという話はけっこう本質的だと思うんですけれども、今まではそういうプロビジョニングをするための仕組みやオーケストレーションをする仕組みの延長線上で作られていたんです。でも、本質的にはデータセンターでオペレーションする人が一番身近なわけですよね。課題もわかっているし、実際に障害が起きたときのオペレーションも組み込めるわけです。なので、実際に開発をその人たちがやるかどうかは別としても、近くにいないといけないのは間違いないわけです。

新野：要するに、データセンターを動かすソフトウェアそのものも実際に運用する人の近くで作られなければいけない。

クラウドネイティブは手段ではなくカルチャー

田中：そもそも論として、我々の社内ではデータセンター自体もソフトウェアで動いているので、例えば空調の制御もそうだし、IDカードを当ててフラッパーゲートが開くやつもそうじゃないですか。受付管理などもありますし、オペレーションって多岐にわたるわけです。

実際、受付管理のシステムは紙でやっていたんですけれども、最近はやはりアプリケーションエンジニアが一緒に作って、今は別に普通にオンラインで申請してバーコードで入れるようになっています。

そういうことも含めてすべてがコードで書かれている時代に、ソフトウェアを学ばなくていいわけがないんです。そこすらも嫌うエンジニアの方って多いですから、そこから変えていくのがスタートですね。

新野：だからインフラエンジニアも、プログラミングまでは期待されなくても、アプリケーションエンジニアとコミュニケーションをとってある程度システムを構築・設計できる。

田中：できれば自分で書けばいい。そんなに難しいものでもないですからね。ただ、やっぱり最近入ってくる社員もそういう人が多いですから。

何年か前までは、上司が悪かったんですね。最近すごくみんながんばってくれて、現場でコードを書くのが普通に当たり前に出てきているわけなんですけれども、何年か前までは「いや、そういうの仕事じゃないから」みたいなことがあって、潰してきていた時期がある。そもそも6年ぐらい前までは「そんな仕事しなくていいから」みたいなところもあったんですよね。

だから、本当に現場のエンジニアも重要ですけど、ちょっと話が広がると、クラウドネイティブもインフラエンジニアがやれと言われてほとほと困り果てるなんてこともよくあって。上司が悪いと言うと身も蓋もないんですけれども、もっと言うと、もっと上の人ですよね。なんならそこの社長が決めるぐらい、方針として「クラウドネイティブなんだ」とやらないと。

手段ではなくて、テクノロジーでもなくて、もうカルチャーみたいなものだと思うんですよね。だから、現場がボトムアップでやるような話ではなくて、やはりリーダーが「クラウドネイティブだ」と言って、それをサポートして、社内でクラウドネイティブをやらないような人に関しては「こっちの方向ですよ」というのをアラインしていかないといけない。

DevOpsに関しても、「Devが言うことを聞かない」みたいな話がありますけど、それではダメなので、基本的に「こういうカルチャーに変えますよ」という宣言から始めていかないと、先ほどのご質問の趣旨にあった「学んでいくためにどうすればいいか？」というスタートには立てないので、まずはリーダーがやっぱりそういうふうに変えるんですよと。

「ソフトウェアファースト、コードファーストですよ」という話もそうだし、「DevOpsなんですよ」とか「SREなんですよ」とか、あれは手段だけではなくて、カルチャーです。とにかくリーダーシップをとらないといけないと思っています。

これからのインフラエンジニアの価値

新野：大事なお話ですよね。でも、青山さん、お客さんと面したときに「まず組織を変えてください」ってなかなか言いにくいですよね。

青山：そうですね。

新野：とはいえ、お客さんからやりたいと言われたときに「こうしたほうがいいですよ」というアドバイスをされると思うので、何かよくアドバイスされる話とか、あるいはお客さんからよく聞く悩みがあれば教えていただけませんか？

青山：1つは、クラウドネイティブという世界で、Dockerや、Kubernetes、OpenShiftなどを使うときに、例えばIBM Cloudだとマネージド・サービスがありますけど、自分たちで自前で作らなければいけない場合、以前はインフラのエンジニアはハイパーバイザーや、OS、ストレージ・ネットワークまでで、その上にアプリが載っていたと思うんです。

でも、その間に、そこのDockerやKubernetesを管理しなければいけないという仕事ができたじゃないですか。そこの境界が曖昧だというのもありますけど、お客様が持っている非機能要件をもとにどう作って運用管理していけばいいかというノウハウをそこに活かして、Kubernetesなどで管理する層を運用できるようになるのがインフラエンジニアの価値であり、これからの使命なんじゃないかと思っています。

なので、そういうところを伸ばしていくのがいいんじゃないですかというお話もしますし、うちの会社でもそういうところを伸ばしていかなければいけないというエンジニアはたくさんいると思います。

新野：今の時代では、Ops担当の人が仮想マシンよりさらに上のコンテナの管理、場合によってはKubernetesかもしれないですけど、そこまで見たほうがOpsの価値が出るというお話でした。

一方で、僕が時々取材先で聞く話は、「そのコードを書いたアプリケーションエンジニアが運用まで見なさい」「障害が起きたらそのコードのせいかもしれないんだから、何かあったら開発者が自分で責任とるぐらいの運用監視までしたほうがいい」という話も聞くんですよ。それってどちらがいいと思います？

青山：正直どちらでもいいとは思います。ただ、そこをやるべき人は全体を俯瞰して見られる人である必要があるなとは思います。

なので、私見ですけど、先ほど言ったように、インフラエンジニアが今まで全体を滞りなく動かすために非機能要件などをもとに考えてきたデザインをそこに活かすべきなんじゃないかと思います。

アプリケーションの人でも、もちろん全体を見ている人もいると思うんですけど、やはりアプリケーションの動きに集中しがちなところはあると思うので、その下で動くインフラ全体を見ていた人たちがその部分を見られるといいんじゃないかなとは考えています。

DevもOpsも目指す方向は同じ

新野：藤原さん、いかがですか？

藤原：自分の場合、少し視点を変えて、「Devの人とOpsの人がそれぞれ持っているミッションってそもそも何なんだろう」というところから掘っていきたくて。

Devの人は「こういうサービスを実現したい」「こういうビジネスをやりたい、儲けたい」というところに対して全力でコミットする人たちじゃないですか。それに対してOpsの人たちは、Devの人たちの作ったものを確実かつ安定に運用するというミッションを持っています。

この2つは要求されるスキルやメンタリティがぜんぜん違うので、もちろん向き・不向きがあります。100パーセントDevとか100パーセントOpsということはないんですけど、ある程度人によってバランスを変えていくのはあるんじゃないかなと思いますね。

新野：実際に藤原さんが関わっていらっしゃるチームでは、どういう責任分担になっていらっしゃいます？

藤原：自分のチームはOpsですけど、一般的な感覚でいくと「いや、これDevのチームじゃない？」と思われるようなことのほうが多いと思います。

新野：先ほどのお話でも、Opsの人がアプリケーションのアーキテクチャにまでアドバイスしたり提案したりすると考えると、かなりDevに食い込んでますよね。

藤原：そうですね。

新野：そういう意味ではKubernetesの設計やアーキテクチャ、場合によってはネットワークの設計なども十分に詳しくないと、クラウドネイティブ時代のOpsとして高い価値を出しにくい感じがするんですけど、青山さん、それで合っていますか？

青山：そうですね。

新野：言い切りましたね。かなりハードルが高そうですね。

青山：やはりこれまでとはスキルのエリアがぜんぜん違うと思うので、コードを書かなければいけないという話もありますけど、そういったスキルをつけていかなければいけないんじゃないかと思います。

新野：そういう意味だと、田中さんの会社が提供するサービスの価値も変わってくるかもしれないですよね。

田中：そうですね。本質的に言うと、結局お客様が満足して使えるかどうかということに尽きると思うんですね。なので、Devの人もOpsの人もインフラの人も、いろいろなステークホルダーがいますけれども、極端な話「何かが止まっていてもお客さんが使えていたらいい」という話で、そこが本質だと考えると「結局、みんなの目指している方向は一緒だよね」ということでSREなどの考え方ができたと思うんです。

実際、さくらのレンタルサーバでも、昔は「落ちているか・落ちていないか」というのが中心的な議論でしたけど、最近はお客様のサイトのレスポンスを測り始めています。そんなの10年前からやっとけって話なんですけど、僕自身も気づいていなかったんですよね。お客様が快適に使えるということが本質的には重要なのに、「今日はサーバ落ちてません」みたいな話だと違うんです。

そこのメッセージはリーダーがちゃんと言っていかないといけないし、やはりお客様にとって使えるかどうか、もっと言うなら、快適に使えるかどうかというところなんだとは思います。

クラウドネイティブ時代の組織論

新野：なるほど。やはりそういう意味でOpsの役割とスキルが変わってきている感じがしますので、そのまま次のアジェンダ3にいこうと思います。

これまでの話にあったように、ストレージ担当・データベース担当というよりはもう少し上のレイヤーで能力を発揮したいという議論になってくると、組織のあり方、運用部門みたいな組織のあり方ももしかしたら変わってくる。アプリケーションごとに分けたほうがいいのかもしれないし、それをもう少し横串にしたほうがいいのかもしれないという考え方も出てくると思うので、どういう組織がいいのか。クラウドネイティブ的なものがいいか、あるいはDevOps的なものがいいか。

それから、今日の中心的な議論では出てこなかったんですけど、セキュリティも一緒に維持していかなければいけない。セキュリティは可用性と脆弱性の両方があると思うんですけど、それも見ながら運用していかなければいけないとすると、そういう組織はどういうものがいいんだろう、というのを3番目のアジェンダとしてみなさんとお話をしていきたいと思います。

青山さんから聞いていきたいと思います。いろいろなお客さんの組織がいますし、IBMの社内の組織もあると思いますが、組織論についてどう考えていらっしゃいます？

青山：先ほどからお話に出ているとおり、アプリとインフラの境界がないなかで、組織としてそこが分かれているというのはもはやナンセンスなんじゃないかとは感じています。なので、やはりSRE的な動き方をする上でも……。

新野：SREについて、注釈してもいいですか？　Site Reliability Engineeringでしたっけ。

青山：SREとは、パブリッククラウドそのものを運用するときの考え方として、お客様のサービス継続性などを指標にして測るというところやエラーバジェットの考え方、それとサービス継続性の考え方のときに、先ほど言っていた「インフラが何分止まったという話ではなくて、サービスの継続がどれだけできているのか」というところに重点を置いて考えていくという。

あとは、運用の部分を自動化などをして効率化して、いかに運用に関わる部分の負担と運用コストを減らして効果を出していくかみたいな考え方だと思うんですけど、そういった考え方で運用していくときに……組織論ですよね？

さっきからアプリとインフラの話ばかりしているんですけど、アプリケーションのお客様を相手にしているチームとインフラのお客様を相手にしているチームがいたとして、そこが分かれてはいけないなと思います。両方と会話ができるチームになって、アプリとインフラのそれぞれがどう改善していってどう運用ができているかということを考えられないと、SREとしての運用というのは回らないと思うので。

お客様側がそこ（アプリとインフラ）が一緒になっていたら、それに合わせてこちら側も一緒にお話ができる体制をとっていかなければいけないし、逆にお客様が徐々にアプリとインフラが統合してどんどんDXを進めていく途中にいたら、私たちもその途中の段階と一緒に会話をしていく。とにかく分けて話していくというのをずっと続けていてはいけないなと私たちも思っています。

新野：なるほど。議論としては、アプリと運用を分けていると、組織の断絶ってコミュニケーションの断絶にもつながると思うので、一緒にしたほうがいいというのはわかりやすい。でも、開発者のスキルを伸ばしたい人と運用のスキルを伸ばしたい人が同じ組織の中に混ざっていると、コミュニケーションはしやすいと思うんですけど、どの先輩を見習えばいいのかとか、どういう方向に向かって自分のスキルを伸ばしていったらいいのかということを見失いがちになるような気もするんです。そのあたりはどうですか？

DevとOpsが混在する組織はどうあるべきか

青山：やはりスキルという観点だと、もちろんフルスタックという……どこまでできればフルスタックなのかというところはありますけど。

新野：フルスタックエンジニアは、ある意味理想形ですよね。

青山：なんでもできればいいんですけど、やはりどこかしらに軸を置く。例えば自分だったらインフラに軸を置いていくし、そこから少しでもアプリのほうができるように、ということを意識していかなければいけないと思うので。

その中で、どれだけ自分の世界を広げていけるか。軸は深く持っておいて、幹にある周りの部分はどんどん広げていっていろいろなスキルをつけるという考え方で、ミックスしている中でも何か自分が輝けるところを探していくのがいいのかなとは思っています。

新野：藤原さんはどうですか？

藤原：少し話を前段階に戻してもいいですか。組織の話なんですけど、答えがないと思っていて、時期によって変わってくると思うんですよ。

例えば、新規プロダクトを私がやっている段階であれば、そのプロダクトの売上を伸ばすとか、そのサービスがちゃんとビジネスとしてうまくいくようにするのが第一なので、局所最適化に向かって徹底的に走るんですね。

それがある程度ビジネスとしてうまくいって、そういうサービスが横並びにいくつかあるというタイミングでは、その運用コストって局所最適化しているので絶対に高いはずなんです。そうなってきたときに、少しリアーキテクトして横串でその面倒を見る組織を用意しなきゃいけないということになる。

専門性が高い組織とフルスタック的な組織があって、それが定期的に入れ替わったり変化したりしていくのを前提で考えたほうがいいんじゃないかとは感じていますね。

新野：そういうなかで、先ほどの問いに戻るんですけど、開発指向の人とOps指向の人ってうまく混在できると思いますか？　あるいは、混在させるとしたら何かうまくいく秘訣はあると思いますか？

藤原：それは結局チームで働くということなので、それぞれに強みと弱みがあると思うんですよ。

私は、例えばサーバサイドのアプリだったら少し書けるかもしれないけど、フロントエンドはまったく手が出ません。でも、「フロントエンドが強いけれども、インフラはさっぱりわからん」という人もいるわけじゃないですか。そういう人と一緒に仕事をすれば、もちろんチームとして成立するので。

それが組織としてやっていくということなので、「それぞれが全員フルスタックエンジニアである必要はなくて、コミュニケーションをとって言葉が通じるぐらいの最低限のラインをお互いに確保できれば、それでいいんじゃない？」とは感じていますね。

新野：そのときのコミュニケーション手段としてコードが大事になってくるということで、先ほどの話が出てくるわけですよね。田中さんにも同じ質問をしたいと思います。

組織は手段、大事なのはそこに込めたメッセージ

田中：やっぱり、どこまでいっても組織は手段だと思うんです。なので、組織を変えたらうまくいった、なんてことはなくて、組織を変えたときに何かも変えるからうまくいってるんだと思うんです。

そこが実は本質だと思っていて、組織を変えるにあたってのメッセージングですよね。例えば「DevOpsを充実させるために、このような組織しました」という。管理者が管理しやすくするために組織があるわけじゃなくて、やはり現場の人たちが動きやすいように組織を設計した上で、「何のためにそうしたのか」ということがメッセージとしては重要なんだろうと思います。どんな組織でも動きやすければいいと思うので、こういう組織が良いという正解がない理由はそこなんだと思うんです。

ただ、気をつけないといけないのは、コンウェイの法則ってあるじゃないですか。

新野：「組織のアーキテクチャがソフトウェアのアーキテクチャを規定する」みたいな。

田中：はい。それは事実としてあるわけなので、「こういうソフトにはしたくない」、逆に「こういうソフトにしたい」というのを基準に組織設計をしないといけないのは必然だと思いますけれども。

新野：なるほど。

田中：とはいえ、しつこいですけれども、組織は手段であって、そこに対して込めたメッセージングや方針・ビジョンとか、そういうことのほうが重要なんだろうなとは感じますね。

新野：そうしたなかで、田中さんは社長なので、Opsをやる人とDevをやる人をうまく組織の中に混在させていくとき、組織の設計にあたって気をつけていることはありますか？

田中：我々の会社の社是が「『やりたいこと』を『できる』に変える」というもので、「自社の社是は知らんけど、さくらの社是は知ってる」と言ってくれる人を増やしたいんですけど。

新野：（笑）。

田中：やりたいこと・やりたくないこと、できること・できないこと、これって4象限あるはずなんですよね。「やりたくて、できること」は一番良いわけじゃないですか。やりがいもスキルもある。でも、「できないけど、やりたいこと」があると、スキルが上がるわけですよね。ということは、組織の箱というよりも、その中でどうアサインしていくかというと、やはりその人が何に関心を持っているかということなんですね。

運用と開発だと少しわかりにくいんですが、維持が得意な人もいれば、新しいものを作るのが得意な人もいるわけですよね。それが好きか嫌いかというのも含めて。ということは、開発の中でも新しいコードを立ち上げる人に関しては、ある程度新しいことが好きな人のほうがいいわけです。

ただ、ソフトの中でもリファクタリングがあるじゃないですか。リファクタリングって軽視されがちなんだけれども、組織にとってすごく重要なのは、維持してくれている人が大事だというメッセージをいかに出していくかだと思うんですよね。

なので、それを踏まえた上で、どんな組織でもいいですけれども、新しいことをやりたいのか維持をしたいのか、それを見極めていってちゃんとそこにアサインしていって。加えて言うと、先ほどおっしゃったように、チームは凸凹でもうまく組んでいかないといけないわけなので、その人が何が好きか嫌いか・何が得意か不得意かを踏まえた上でチームビルディングをするのが一番重要だなと思っています。

DevSecOpsへの取り組み方

新野：なるほど。この議論を踏まえて、最後にセキュリティをどう保つかということについて触れて、議論を収束に向かわせていきたいと思います。

これは青山さんに聞きたいんですけど、アプリケーションやシステムのセキュリティを考えたときに、DevもOpsも両方責任があるわけじゃないですか。DevSecOpsという用語がありますが、これにどうやって取り組めばいいと思いますか？

青山：コンテナやクラウドネイティブの世界でも、コードの脆弱性を見たりイメージの脆弱性を見たり、あとは本番環境が改ざんされていないかといったところを見ると思うんですけど、監視のときと同じで、脆弱性チェックや改ざんチェックをしたあとの結果としてのアクションが今までとは違うでしょう。

今まではサーバの脆弱性があったら、ログインしてパッチを当てるとか、何かファイルを修正するというのがありましたけど、イメージだったらイメージを作り直すし、本番の改ざんが検知されたらそれも作り直すというふうに、そこの運用が変わるということを受け入れて、それに慣れるのがまず必要なんじゃないかと思います。

IBM Cloudの「IBM Cloud Pak」というものがあって、改ざんや脆弱性を検知するツールがあるんですけど、ほかにもいろいろあるじゃないですか。そういったものをうまく使って、それを検知した結果どう動いていくかをOpsも考えて、そこに従って動けるようにならないといけないのかなと。

新野：そこは基本的にはDevOpsの動き方とあまり変わらないという理解でいいですか？

青山：私はそう感じています。

新野：藤原さん、どうですか？

藤原：そうですね。DevSecOpsという言い方自体は自分は何も思うことがないんですが、そもそも、DevOpsの黄色いハンドブックがあるじゃないですか。あれを読むと、すでにセキュリティの考え方が入っているんですね。

その上で、Secが入ってきている理由は何かと考えたときに、セキュリティの重要性がすごく増しているのに加えて、これまではすごく専門性が高い領域だったけれども、いろいろなマネージドサービスが出てきて脆弱性を洗い出したりとか検知するところまではある程度できるようになっています。その上でどうするのかということを、我々はOpsとしてDevの人も巻き込んで考えていかないといけないんですね。

たまたま弊社の場合はすごく強いセキュリティチームが揃っているので、そこからのトリアージも含めてやれる環境ができていますけど、普通の規模の会社だったらそれはなかなか難しいと思うので、少なくともどんなリスクがあるのかというところまでは洗い出しておきましょうと。まずは、自分たちが何を使っていてどんなリスクがあるのかという把握が大事かなと思います。

その上で、「なんかこれ、やばそうじゃない？」というところを見つけたときの相談先をちゃんと確保するとか、そういったことが大事になってくるのだと思います。

作るところからセキュリティを考える

新野：やはり専門性が高いというのは1つの取り組みにくさではありますよね。本当は分業したいところだけれども、一緒に取り組まないと解決できないという問題の難しさはあるような気がするんですよね。

田中さん、何かこの面でご意見ありますか？

田中：これはけっこう難しくて、日本はもう間に合わないんじゃないかと思うこともあるんですけれども……。要は、セキュリティは専門性が高いですが、標準で考えないといけない。でもエンジニアが少ないんですよね。

当社の場合、グループ会社に専門の集団があって、彼らは非常に優秀だし、リクルートやIBMも当然そういう組織を持たれているわけですけれども、それを持てていない会社はどうするのかということは、かなりリスクが高いので経営者が本気で取り組まないといけないだろうと思います。

重要なのは、作ったアプリケーションに脆弱性があるかどうかというより、作っている段階から常にテストをしながら、かつ、プログラマもその知識を得て作っていかないといけない。最近はセキュアコーディングみたいな話がありますけれども、とにかく作ったあとに公開してから「はい、どうぞ」というのではもうダメだということをどう啓蒙していくか。危機感を煽っているわけではなくて、本当に公開した時点でもう攻撃される場合もあるじゃないですか。

新野：そうですね。

田中：なので、自分のところは大丈夫だと多くの人は思っているんですけれども、やはり当社で関わっているところでも、常にお客様は攻撃されていますから、上流において対策をする必要性をひしひしと感じながらも、どうしたらいいのかと。

ただ、最近ISACがすごく増えてますよね。Software ISACというのがコンピュータソフトウェア業界で作られましたし、Telecom-ISACもあるし、ICT-ISACなどいろいなISACがあるので、まずは情報収集することからでもやらざるを得ないのかなと思います。

とにかく、作るところからセキュリティが入り込まないといけないということですね。

新野：ありがとうございます。