エンジニアがCTOやCIOになってビジネスプロセスの変革をリードするのは難しい話ではない：特集：日本型デジタルトランスフォーメーション成功への道（7）（1/2 ページ）

「アジャイル」「DevOps」「CI/CD」「パイプライン管理」はエンジニアの働き方や役割にどんな変化をもたらすのか。日本IBM、日本マイクロソフト、アトラシアンでさまざまな開発ツールのエバンジェリストを務めた、エバンジェリズム研究所 代表 長沢智治氏に聞いた。

[唐沢正和，ヒューマン・データ・ラボラトリ]

　テクノロジーの力を使って新たな価値を創造するデジタルトランスフォーメーション（DX）が各業種で進展している中、重要なキーワードとして注目されているものに「アジャイル」「DevOps」「CI/CD」「パイプライン管理」がある。ITがビジネスのコアになっている昨今、企業は重要な顧客接点となるWeb／モバイルアプリケーションを迅速に開発、改善するために、アジャイルやDevOpsを取り入れざるを得ないという認識が広まりつつある。そして、その仕組みとして、CI/CD（継続的インテグレーション／継続的デリバリー）、パイプライン管理に注目が集まっている。

　こうした新しい仕組みは、エンジニアの働き方や役割にどんな変化をもたらすのか。日本IBM、日本マイクロソフト、アトラシアンでさまざまな開発ツールのエバンジェリストを務め、アジャイルやDevOps、CI/CD、パイプライン管理などに詳しい、エバンジェリズム研究所 代表 長沢智治氏に聞いた。

日本企業におけるアジャイルやDevOpsの現状

――アジャイルやDevOpsに対する企業の取り組み状況をどう見ていますか？

長沢氏　「アジャイルソフトウェア開発宣言」から20年近く、DevOpsが話題になり始めてから10年近くたちますが、まだ本格的に取り組んでいる企業は少ないと感じています。事業会社の状況としては、「DevOpsとは何なのか」といった相談は増えてきていますが、その先に進んでいる企業は少ないのが現状です。DevOpsを実践できている企業は、全体の1割程度ではないでしょうか。

　アジャイルやDevOpsの前にそもそもDXが「働き方改革」というキーワードで語られることが多く、残業時間の削減や業務効率化の手段として捉えている企業が少なくないのではないでしょうか。DXが「働き方改革」の文脈で語られるために「省力化」「業務改善」などと同義に捉えられ、本来の「ビジネス活性化」「イノベーション」につながるDXに結び付いていないため、アジャイルやDevOpsも地に足がついていない傾向があるように感じています。

長沢氏による「DevOps、DX関連技術の変遷」

　極端な例では、役員からトップダウンで「DevOpsが重要みたいだから導入してみろ」と、開発チームのリーダーが指令を受けて、どこから取り組めばよいのか分からず、私のところに相談に来るケースもあります。こうしたケースでは、役員に直接会って、アジャイルやDevOps、そしてDXの理解度や、導入する意図を確認するようにしています。

　理解度という意味では、私が、従来のビジネスモデルや開発の仕方と、DX時代での違いを説明するのによく使うのが、映画とドラマの違いです。従来は、莫大な予算と準備期間を使って、公開と配給で1リリースとするサイクルを数年単位で回す映画の製作に似ています。DX時代は、最小の予算と準備期間をもって、大体3カ月単位のサイクルを回すドラマの制作に似ています。ドラマは、映画のように製作と放映（リリース）は分離しておらず、シームレスに連携し、1週間単位で見直しが行われています。こう例えると、従来の開発と、DX時代の開発との違いをすぐに理解してもらえます。

　その上で、DevOpsやDXの本来の目的を確認し、その事業会社が開発しようとしているプロダクトタイプをチェックします。この時には、4つのプロダクトタイプを表したチャートを見せています。このチャートから、既存ビジネスモデルを守るプロダクト（SoR）なのか、新しいビジネスモデルの攻めるプロダクト（SoE）なのか、意思決定はどこが主導するのか、重視する品質は何かなどを判断し、アジャイルやDevOpsが本当に必要なのかどうかを見直してもらっています。

長沢氏による「4つのプロダクトタイプ」（年代は、そのタイプが主流だった時を表す）

　Web系のスタートアップやベンチャー企業からの相談では、そもそも少人数で反復的かつ漸進的な開発に取り組んでいるので、DevOpsに関する内容よりも、リリースしたプロダクトをより多くのユーザーに使ってもらうためにはどうしたらいいのかなど、マーケティング関連の相談を受けるケースが多いです。

CIは広まりつつあるが、CDまで見据えている企業は2〜3割

――そうした中で、開発現場からは、CI/CDやパイプライン管理に対する関心が高まっているようですが、よくある誤解と正しい理解をあらためて教えてください。

エバンジェリズム研究所 代表 長沢智治氏

長沢氏　特に、CIについてはここ数年で「Jenkins」などのツールが成熟してきたので、開発環境にCIツールを導入しようという機運が高まりつつあります。ただ、私の感覚では、CIツールを導入した企業の5割以上が、それだけで満足してしまっているように思います。中には、周りの企業がCIツールを使っているから、取りあえず入れてみただけで、CIを導入する目的を見失っている企業も見受けられます。

　そもそもCIは、現場の効率化ではなく、成果獲得までのリードタイムを短縮することを目的に、開発チームがプロダクトのリリースに備えるためのプラクティスです。今までは、開発チームにそれができる余裕も時間もありませんでした。従来の開発サイクルでは、コードを変更した後のビルドやテストなどが後回しにされがちで、これが負債のようにたまっていくことで、プロダクトのリリースまでに時間がかかっている状況でした。CIを導入することで、コード変更からビルド、テストまでのサイクルを自動化することができ、リリースまでのリードタイムを短縮することができます。

　要件と成果物をひも付けて、その先のCDにつなげていくためのステップとして導入することが重要だと考えていますが、現状では、CDまで見据えてCIツールを活用している企業は2〜3割くらいだと感じています。

――無理してCI/CDをセットで導入するのではなく、CIからCDへと段階的に導入する方が現実的ということですね。

長沢氏　そうですね。出すべきプロダクト自体に問題があったら意味がないので。まずCIを導入することによって、プロダクトをリリースする上での、現状抱えるさまざまな問題点が見えてきます。例えば、コードを変更してテスト結果にエラーが出たら、「要求項目が甘かったのではないか」「開発チームがドメインや技術に対して未熟なのでは」など、その都度、問題点が顕在化するので、改善していくことができます。

　少し時間はかかるかもしれませんが、開発チームがCIのサイクルをしっかり回して、質の高いプロダクトをコンスタントにリリースし続けていけば、ビジネス層もその価値を理解して、CDの導入へと進んでいくはずです。「CIによって、セキュリティ含め品質の高いプロダクトができているので、デプロイ、リリースがいつでもできる」という、タイミングやビジネス計画の話ができます。ビジネス層や運用部門は、プロダクトをデプロイ、リリースできる段階になって初めて、関心事になってくるのです。開発チームがCIやプロダクトのコードの話をするだけでは、ビジネス層や運用部門と議論することもできないでしょう。

長沢氏による「ビジネス、運用、開発の関係性」

　一方で、CIとCDをセットで導入した方が良いケースもあります。それは、オンラインコンテンツやWebサイトの改修など、より早く出すことに意味がある、SoE領域の開発プロジェクトです。この場合は、業務系に大きな影響を与えるものではないので、CIからCDまでのサイクルを一気に回して素早くリリースすることが重要になります。問題が発生したときに、素早く対応したり復元したりしやすいからです。

――CI/CDの導入に当たって、運用チームに求められることは、どういったことでしょうか。

長沢氏　運用チームは、プロダクトの安定稼働とともに、状況に応じたさまざまな調整や自動化、パイプライン管理を行っていくSREのような役割を担っていくことになります。自動化やパイプライン管理によって、リスクを管理し、問題が起きたときに、瞬時に改善の優先順位を判断できるようになり、開発側も迅速かつ効率的に改善作業に入ることが可能になります。MTTR（Mean Time To Recovery：平均復旧時間）の短縮など目標を持って取り組むとよいでしょう。