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

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

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

受託開発企業がDevOpsを実践していくためのポイント

――日本では受託開発のSIerが多いという現実がありますが、そうした企業がDevOpsを実践していくためのポイントはどこにあるのでしょうか。

長沢氏　受託開発の難しい点は、DevOpsを実践するためには事業会社からDevOps案件を請け負う必要があるということです。しかし現実には、DXやDevOpsの意義から提案する必要があり、提案してもDevOpsの導入実績を求められてしまう。受託開発の企業としては、DevOpsの導入実績を作りたくても作る案件がないという悩みを抱えています。そこで私は、DevOpsを自社導入して経験を積んでいくことを推奨しています。

　例えば、経理部門の交通費精算や営業管理システムなど、社員がよく使うアプリケーションをDevOpsで開発、運用する。この部分は、業績に影響を与えることなく、開発プロセスが社内で完結できることに加えて、ユーザーからのフィードバックも得やすいので、DevOpsの経験を積むには最適です。特に、営業系のアプリケーション開発でDevOpsを実践するためには、ビジネス層や営業部門を巻き込んでいく必要があります。

　こうした取り組みを通じて、社内で営業プロセスのリードタイムを短縮するなどの成果を挙げられれば、この事例を踏まえて事業会社に向けた提案においてもDevOpsの価値を示すことができると考えています。将来的には、単なる受託開発ではなく、事業会社とのレベニューシェアという形や、「共創ビジネス」を提案していくことも可能になると思います。

　また、こうしたDevOpsの運営体制は、固定のチームに依存するのではなく、組織全体として動いていけるようにするのもポイントです。プロジェクトの内容や規模に応じて、チームメンバーは変わっていくかもしれません。そのため、開発エンジニア、運用エンジニア一人一人が、共通の意識を持ってDevOpsに取り組んでいくことが必要になります。

――そうしたことを、日本で実践できるのでしょうか。

長沢氏　私が現在関わっている、IoT導入支援と受託開発を行うウフルの事例を紹介すると、受託開発を手掛けているデリバリーイノベーション（DI）事業本部において「ジャイロ・コード」という行動規範を掲げています。

私たちは

何をするかよりも、誰とやるかを
能力より、真摯さを
個人の利益よりも、チームの利益を
過去の成功体験よりも、未来の成功を

左記のことがらに価値があることを認めながらも、右記のことがらに価値をおき、全員がエンジニアであることを義務付けられた組織である。

　この行動規範の下、各スタッフがどんなメンバーでチームを組んでも同じ考え方でDevOpsに取り組むという「ジャイロ型組織」を実現しています。もちろん仕組みとしてCI/CDやパイプライン管理による開発の自動化、業務効率化であり、エンジニアが開発業務に追われることなく、クリエイティブなことにもチャレンジできるようになっています。

　この他に、プロダクトオーナーやスクラムマスターのバーチャル組織を作っているケースもあります。各チームのプロダクトオーナーやスクラムマスターがそれぞれのバーチャル組織に参加し、その中でチームの垣根を超えた情報共有や相談ができる仕組みで、問題やトラブルを一人で抱え込まないように組織でサポートしています。

エンジニアがCTOやCIOになってビジネスプロセスの変革をリード

――そうした体制を築くには、トップダウンとボトムアップ、どちらのアプローチが適しているのでしょうか。

長沢氏　経営層がトップダウンで進めていくのが理想的ですが、日本ではまだ難しいと感じています。特に事業会社では、DevOpsを理解して、開発状況を俯瞰（ふかん）的に見られる経営者は少ないのが実情ではないでしょうか。その意味では、経営層よりもテクノロジーに明るくて、経営的な視点を持っているCTO（最高技術責任者）やCIO（最高情報責任者）が、DevOpsの旗振り役に適しています。

――しかし日本では、CTOやCIOを置いている事業会社はまだ少ないのが現実です。

長沢氏　残念ながら、その通りです。日本でも、CTOやCIOを目指すエンジニアがどんどん出てきてほしいですね。本来、ソフトウェア開発のプロセスは非常に複雑なものであり、その中でエンジニアは、問題を整理して解決していく、いわば問題解決のスペシャリストです。その力を、プロダクトの開発ではなく、組織や業務プロセスにも向けられれば、CTOやCIOを担う人材になることができると思います。

　大手事業会社では、Web系の開発を経験したエンジニアがテクノロジー責任者になって、手腕を振るっているケースも出てきています。記事や発表などで注目した企業としては、例えば、デンソーやファーストリテイリング、LIXIL、SOMPOホールディングス、JapanTaxiなどでは、そうした人材がデジタル戦略の推進役を担っているのではないでしょうか。

――これからアジャイルやDevOpsに取り組み始めるエンジニアにメッセージを頂けますか。

長沢氏　今までウオーターフォールでやってきたエンジニアの意識を急に変えるのは難しいので、その企業の状況に応じて、ビジネス層も営業部門も含めて中長期的に焦らず、目的と相互理解を深めてアジャイルやDevOpsに適応してもらうようにしています。

　その中で、1つだけ理解してほしいことがあります。それは、今の時代には「正解がない」ということです。ウオーターフォールから前に進めない人は、過去の成功事例にこだわっている傾向があります。それは、もはや正解ではないかもしれません。同じように他社の成功事例も、正解ではないと思ってほしい。これからの時代は、自分たちで正解を導き出していくことが必要なのです。そのためには失敗を恐れずに、小さな失敗を繰り返しながら、新たなビジネスやプロダクトにチャレンジしていってほしいと思います。

特集：日本型デジタルトランスフォーメーション成功への道 〜“他人事”ではないDXの現実解〜

テクノロジーの力を使って新たな価値を創造するデジタルトランスフォーメーション（DX）が各業種で進展している。だが中には単なる業務改善をDXと呼ぶ風潮もあるなど、一般的な日本企業は海外に比べると大幅に後れを取っているのが現実だ。では企業がDXを推進し、差別化の源泉としていくためには、変革に向けて何をそろえ、どのようなステップを踏んでいけばよいのだろうか。本特集ではDXへのロードマップを今あらためて明確化。“他人事”に終始してきたDX実現の方法を、現実的な観点から伝授する。

特集：日本型デジタルトランスフォーメーション成功への道 〜“他人事”ではないDXの現実解〜