DX時代の今、経営層やエンジニアに問い直す、「セキュリティ対策」と「セキュリティバイデザイン」の意義とは：特集：継続的に儲けるための「セキュリティバイデザイン」入門（1）

近年の複雑化、多様化するサイバー攻撃を迎え撃つセキュリティ対策は、迅速なサイクルを回す開発が求められるデジタルトランスフォーメーション（DX）の阻害要因になるのではという意見もある。その中、DXとセキュリティの両立に有効なのが「セキュリティバイデザイン」だ。では、企業がセキュリティバイデザインに取り組む上で、どのような課題があるのか。

[高橋睦美，＠IT]

　デジタルテクノロジーをあらゆる業務に活用し、生産性や創造性を向上させ、自社の価値を高めていくデジタルトランスフォーメーション（DX）の流れが確実に広がっている。だが、DXに向けて迅速に開発サイクルを回す上で、セキュリティ対策は阻害要因になっているのではないか――＠ITの記事では時々こうしたテーマを提示してきた。

　だがアスタリスク・リサーチ CEOの岡田良太郎氏は、一連の話の所々に「異議」があるという。そもそもDXの本質とは何か、その中でセキュリティはどのように織り込まれていくべきか、そしてDX時代のセキュリティバイデザイン（SBD）はどのような形になっていくのかなどについて、岡田氏に尋ねた。

「うちもDX頑張っています」言いたいだけ症候群？

――今、国内のユーザー企業にDXが求められる「背景」について教えてください。「DXレポート」にあるような「2025年の崖」問題、もしくは、デジタルディスラプションなどでしょうか？

アスタリスク・リサーチ CEOの岡田良太郎氏

岡田氏　レガシーシステムを捨てて、いろいろなものをペーパーレス化し、プロセスも変えることによって、これまでのボトルネックをなくして物事がクリアに進むようになる。逆に、昔と一緒のやり方を続けてきたばかりに、急に市場に参入してきた他社との競争に負けてしまう。そうした事態を避けるために、リスクを取ってでもデジタル化していかないといけない――それが最近言われているDXです。

　このトレンドを最初にけん引してきたのは、自社の戦略に基づいて「このボトルネックを解消したい」といった強い問題意識を持ち、既存の組織やプロセスをぶっ壊してでも実現したいと思っている企業ですね。

　けれど、今それに続いているのは、そういうのを横目で見て「おいおい、うちもうかうかしていられないぞ」「あれをやるには何をしたらいいんですか、誰か引き抜けませんか」という具合に、何を目標にするのかが空洞のままツールとポーズだけまねしている、そんな企業もあるんじゃないかなと思います。DX担当役員も置かず、情シスに任せるだけではうまくいくはずもありません。

　例えば「今まで数日かかっていたことを数分、数秒にしたい」といった明確な目標や戦略がないまま、今やっている方法をそのままコピーしてクラウドに持っていっただけ。例えば「わが社もオンプレからクラウドにしました！　DXを頑張っています！」と言いたいだけなんじゃないかと。

　及川卓也さんが『ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略』（日経BP）でも述べられている通り、DXとはデジタル技術を利用した変革のことであって、単にアナログなものをデジタル化して多少見てくれが良くなる程度の話ではありません。私は、DX戦略は事業の「スピード」「連携性」そして「可視化」、この3つに集約できると思います。新しい技術やツールをうまく活用することによって、この3つの戦略が実現しやすくなる、そこが肝心なところだと思います。なのに経営層は、こうした手だてを社内に取り入れることで「どんな事業上のメリットがあるのか」「どんな戦略を満たすのか」といった事柄がマッピングできていないんじゃないでしょうか。

DXを阻害するのは既存のシステムではなく、既存の体制

――経済産業省が出したDXレポートについて、どのように見ていますか？

岡田氏　DXレポートを読むといろいろ面白いことが書いてあるし、よくできているなと思うんですが、気になるのは「ボトルネックがあるのはシステムのせい。今あるシステムがダメだからDXが進まないんだ」という具合に書いてあるところです。

　けれど、それはDXの本質ではありません。「成長の阻害要因の解消」「成長に向けた新機軸の導入」など、事業側の戦略こそが本質であり、それがあって初めて「現状のシステムは、こういうアーキテクチャになるべきだ」という話になります。システムの乗り換えとDXをごちゃ混ぜにしていいのかと、ちょっと疑問に思います。

　「セキュリティ対策システム」を例に、レガシーシステムの刷新について考えてみましょう。例えば今までの「ファイアウォールに守られたLAN」というシステムをモダンなアーキテクチャに変えようと思うと、まず「LAN」という存在をなくすことから始まります。代わりに防御の要になるのは「認証」基盤です。自宅にいても会社にいても、何らかのITリソースにアクセスするには必ず認証を受け、その上でしかるべきリソースにアクセスして仕事をするという姿です。

　つまり、1990年代から2000年代くらいにかけて構築してきた「社内のネットワークは安全だ」という前提に立って構築した仕組みを捨てて、認証基盤を使う仕組みに乗り換える必要があります。これを実現するには、「ファイアウォールで守られていたら大丈夫だ」という考え方を改める必要があります。

　そのとき阻害要因になりがちなのは、既存のシステムを構築しメンテナンスしてきた情シス部門や、それを支援してきた役員の「プライド」だったりします。阻害要因があるとすれば、レガシーなシステムそれ自体よりも、既存の体制の、中でも“変化”に同意しない人たちでしょう。

丸投げから共同、協調に、重厚な計画から柔軟な変化に

――「変化に同意しない人たち」というのは「リスクを取ることを恐れる人たち」ともいわれますね。

岡田氏　これまでの伝統的なリスク回避方法は「慎重であること」でした。けれど今のリスク回避の仕方は「迅速かつ柔軟であること」です。間違ったらできるだけ早く訂正することでリスクを回避するわけです。

　過去、慎重であることによってリスクが回避できたのは、周りのスピードも、コンシューマーの声が会社に届くスピードも、頑張りが業績に反映されるスピードも遅かったからです。その慎重さによって、浅はかな進め方を邪魔することにより、きっちり開発することができました。

　けれど今は、慎重に開発を進めたところで、リリースしたときにはもう状況が変わっています。やり直しや切り戻しを許容できないほど、スピードのプレッシャーが高まっています。

　ですから今は、迅速な意思決定、迅速なプロトタイピングでとにかくドラフトを出し、ラフコンセンサスをとって開発を進め、おかしければすぐ直すことでリスクを回避すべきなんです。いわゆるPDCA（Plan→Do→Check→Act）サイクルからOODA（Observe→Orient→Decide→Act）サイクルへの移行が求められていると思いますね。

OODAサイクル（出典：アスタリスク・リサーチ）

　今起きている事柄を観察し、「何がボトルネックになっているか」「何が見えていないため機会損失が起きているのか」といった分析をかけて、その問題を解消するためにリソースを投入し、「実施した結果、状況はどうなったのか」を観察する。これに最もフィットするシステムを構築するのは、会社が主体的な戦略さえ持っていれば、重厚長大なプランを立てて、SIerを呼びつけなくても、割と小さなチームでできるはずなんです。小さくチームを組んで、今ある課題を特定して、リーダーシップをとりながらアジャイルを回す方がフィットすると思います。

　なので、僕がちょっと思っているのが、実は再び「アジャイルブーム」が来ようとしているのではないかということです。

　今から10年くらい前にも、みんながアジャイル、アジャイルって言っていた時期がありましたが、あんまりうまくいかなかったですよね。けれど、今は何が違うかというと、PaaSがあり、FaaSがあり、サーバレスがある。ポチポチっと入力するだけでシステム基盤が整備され、何かが動く。こうした技術の進歩のおかげで、アジャイルの方法論で進めても、1週間くらいのスプリントの中で形や成果が出せるようになってきました。自由に適切な技術を選択しやすくなりました。

　その中で経営、企画、開発に求められる役割を考えるわけですが、経営はやはり「いかに目標を持つか」が大事になります。「どんな阻害要因を取り除きたいのか」「どのボトルネックを解消したいのか」「何を可視化したいのか」「何と何を連携させたいか」を決めるわけです。企画側は、それらにプライオリティを付け、さらに仮説を立ててモニタリングしていくという、仮説検証の責任を負います。そして開発にとっては、それを実現する道具をいかに柔軟に扱えるようにするかが鍵になってきます。

　システム構築を、丸投げスタイルからアジャイルによる協働、協調に。重過ぎる要件定義や設計よりも、段階的な開発サイクルに、という具合にシフトする必要があるということです。

「デザイン」の変容に伴う「セキュリティバイデザイン」の変化

――その経営、企画、開発から敬遠されがちだったのがセキュリティ対策であり、「迅速なサイクルを回す開発が求められるDXの阻害要因になるのでは」という意見もありますが、いかがでしょうか。企業がSBDに取り組む際の課題について教えてください。