第9回： デザイン思考、DevSecOps–単なる開発を超えて（後半）
今回は「第9回： デザイン思考、DevSecOps–単なる開発を超えて（後半）」についてご紹介します。
関連ワード （不確実性の時代に、アジャイル開発で向き合っていこう、開発等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
現代社会は多くのものがソフトウェアで成り立っており、絶えず変化するニーズに応じられる柔軟でスピーディーな開発が求められています。その一方、何が正解（ゴール）なのかが分からない、という不確実性の時代でもあります。不確実性に対処するには「アジャイル開発」が最も有望ですが、その成功裏の実践には、従来の常識の解体と再構築が必要です。エンタープライズにおけるアジャイル開発の実践が待ったなしの状況の中、理論、課題、近年の動向も踏まえ、実例を交えながら幅広く解説します。
前回の「第8回：デザイン思考、DevSecOps—単なる開発を超えて（前半）」から少し時間が空きましたので簡単におさらいします。前回は、開発の前後の活動も含めたライフサイクル全体の最適化のうちの前半部分、すなわちIT化を行う以前に、「そもそも解決すべき問題は何なのか？」を識別する手法である「デザイン思考」について解説しました。そこでは、自分たち（自社）が持っている能力や技術を前提に製品やサービスを設計する「プロダクトアウト」の考え方から脱却し、ユーザーが求めるもの、すなわちユーザーへの配慮を優先した「マーケットイン」の考え方へシフトすることが絶対条件であり、そのためにはインタビューや行動観察を通してユーザーの視点を理解し、そのニーズや課題を把握する「共感」のプロセスが何よりも大切であると指摘しました。
後編となる今回は、ライフサイクルのうちの後半部分、すなわち実際に作り上げたソフトウェアやシステムを運用していく上で、必ずしも同じ目標を共有しているわけではない開発チームと運用チームがいかに協業し、安定稼働させ、スムーズに市場へ投入するか、俗に「DevOps」あるいは「DevSecOps」と呼ばれる、図1の赤枠で示す領域について解説します。
筆者はITの世界に長く身を置いてきた者として、さまざまなイノベーションを通じて生まれる新しい用語や概念（例えば、クラウド、IoT、メタバースなど）に頻繁に遭遇してきましたが、「DevOps」ほど説明に難儀する用語もほかに思い浮かびません。ざっと検索してみても、DevOpsは「開発方法論である」「ソフトウェアの開発手法である」「ビジネスプロセスである」「ソリューションを早く配信するための文化的な基本方針、プラクティス、ツールの組み合わせである」「継続的に価値を届けるために人、プロセス、テクノロジーを1つにまとめることである」などなど、語り手の立場や文脈、狙いによってさまざまな定義が溢れています。今でも鮮明に記憶している出来事として、15年ほど前にはじめて「DevOps」の講釈を受けた際、その場に居合わせた全員の顔に名状しがたい困惑の表情が浮かび、しばしの沈黙のあと、着地点の見えない大ディスカッションに突入していったということがありました。
思うに、私を含め多くの参加者が「開発（Development）」と「運用（Operations）」という用語を二元論で捉え、組織や活動としての両者の利害対立に必要以上にフォーカスしてしまったのでしょう。最近ではそのDevとOpsの間に、両者に深く係わるSec（セキュリティ）が追加され、DevSecOpsと表記されることが増えました。これについてはOps理由よりもSec理由のほうが予算確保しやすいといった現実的なメリットを指摘する声がある一方、DevとOps両方で行う活動は他にも多く存在するため、「*」（ワイルドカード）を用い、まとめてDev*Opsと表現することもあります。
DevとOpsの二元論に話を戻すと、こうしたあつれきが「NoOps」（一言でいうと、クラウド全盛の時代を迎え、自動化やオーケストレーション技術が進展するにつれ運用作業は自動化もしくは開発チームで賄えるようになり、運用チーム、つまり、Opsはいずれ必要なくなっていく）といった少々極端な主張と、それに起因する一連の騒動につながっていったように思います。ただし、その議論の中身は、開発・運用双方のプラクティショナー（実践する者）ならではの示唆に富み、筆者自身の経験と照らしても双方の主張ともに頷ける点が多くあります。以下では、その引き金となったインフラの世界の技術革新を踏まえつつ、NoOps騒動の要点を整理することで、登場以来バズワードであり続けたDevOpsの正体に迫ってみたいと思います。
2000年代から2010年代半ば頃までに登場したインフラ関連の技術やサービスは、1990年のインターネットの商用利用の開始以来の大きな変革であったと言えるでしょう。その本質を一言で表せば「インフラのコード化（Infrastructure as Code：IaC）」です。それまではサーバー機やネットワーク機器などさまざまなハードウェア、各種ミドルウェアを調達し、インフラエンジニアたちがデータセンターで手作業によるキッティングやインストールを経て構築されていました。対してIaCの世界では、インフラをコード（プログラム）で記述し、そのプログラムを実行することで構築作業を行います。
クラウドにおけるIaaSを例に取ると、サーバー、ストレージ、ネットワークなどのコンピューティング資源を注文すると、裏ではあらかじめ用意されているプログラムが実行され、注文書に記載されている通りに資源を払い出し、ネットワーク越しに利用できるように組み上げます。さらには、バージョン管理やテストなどもあらかじめ用意されたプログラムによって実行され、構築された環境に問題がないことの確認が裏で行われています。このように、アプリケーション開発の世界で有効であると既に立証されているプラクティスをインフラにも同様に適用することで、その恩恵が受けられるようになっていったのです。