【イベントレポート】開発と運用「DevOps」視点から考える、プロダクト開発やデザイン、新規事業とは？

2021年5月26日にオンラインイベント "Build.Lunch Session" - 開発と運用「DevOps」視点から考える、プロダクト開発やデザイン、新規事業とは？- を開催しました。

"Build Lunch Session"とは
DXの概念論や理想論ではなく、現実的に課題を解決するためのノウハウ、メソッドや国内事例に注目し、国内リーディング企業とともにDXの実現に欠かせないポイントについて対話するランチトークセッションです。

【登壇者】

神原 宏行（CTC Buildサービス推進チーム長）
2003年入社。大手の電機メーカーをSEとして担当し、その後、様々なソリューションやサービスの開発に携わる。昨年度から、Buildサービス推進チームの責任者を務める。

中島　健　 Cloud DevSecOps (Buildサービス推進チーム)
CTCに1999年入社。ソフトウェアプロダクトのプリセールスエンジニアを経験後、オープンソースプロダクトの案件支援とトラブルシュートを担当。その後、プライベートクラウドの基盤を作るOpenStack を担当後、パブリッククラウドを担当するようになり現在に至る。

伊澤 和宏氏　（㈱グッドパッチ／デザインストラテジスト）
ハードウェアのデザイナーとしてメーカーとコンサルティング会社に従事後、グッドパッチに入社。
現在は、デザインストラテジストとして、ビジネスとデザインを繋ぐ役割の仕事をしている。主に新規事業開発や、既存事業の改革支援協力を担当。

DevOpsとは

(参考：https://ja.wikipedia.org/wiki/DevOps）

中島：インターネットで「DevOps」と検索するとWikipediaに引っ掛かり、上図が掲載されています。片側にDevという開発アクティビティが、右側にOpsという運用アクティビティが書いてあり、開発者と運用者をうまく繋げていくことを表しています。
基本、開発者と運用者は、各々の観点が違うんですね。開発者の方はビジネスから要求された新しい機能を作り投入することを重視し、運用者の方はビジネスを支える基盤を安定的に運用する事を重視しています。新しい機能を投入すると、今までのものから少し変わる。変わるということは、何か問題が発生しやすくなる。そうすると、安定運用を目指している人たちからしたら、「急に変えて大丈夫なのか」という感覚を持つので、変更したい人と変更したくない人との境目が出てくることとなるわけですね。

今までの開発者と運用者の考え方や目的が重ならないため仕方がないことなのですが、しかしより視座を上げると、両者にはビジネスの成功に向けて業務をしているという共通の目的があり、このビジネスの成功に向けた改善活動を行っている状態がDevOpsだと捉えています。

神原：
変更したいと変更したくない人の普段相入れない人たちが、両方成立している状態で、より視座の高い共通目的に向かって改善活動ができるのがDevOpsということですね。

伊澤：
なるほど。DevOpsは状態を指すことなのだと理解しました。昨今のデジタルプロダクトには頻繁なアップデートが必要なものが多いので、考える人と作る人がある程度最初からタッグ組んでチーム運営していくというマインドや考え方に似ていると思いました。

DevOpsな状態はサービスのファン獲得につながる

中島：
DevOpsではない状態のシナリオ（上図）から説明します。この図では、アジャイルな開発環境において、開発者が様々な機能を実装し、まずはα版が完成し、次にβ版が完成し、最後にリリース可能な状態と判断したら、サービスとしてリリースして、ユーザーによる利用が開始した状態を表しています。

中島：
リリース後も、ユーザーの要望に応えるために新機能を追加していくこととなり、（上図）開発者が新機能を作ります。プロダクション環境はすでにユーザにリリースされていますので、さすがに開発では使用できません。そこで開発者が、自身が開発する機能を動作させて確認するための環境を用意してしまうことになり、結果として環境が乱立することになります。また、各新機能のテストを実施しますが、既にリリースされた分を含めてはテストを実施しないことが多いです。新機能を追加した結果、既存のサービスが動かなかったりと、統制に欠け、新たなバグを生んでしまったりする状態になります。

また、新機能が出来上がり、クラウドサービスに乗せて動く状態にする工程が必要になりますが、手作業で実施すると、ミスが生まれやすくなります。そして元に戻そうとして再び手作業すると、またミスが発生する。結果としてサービス停止時間が長くなり、顧客に対して悪い体験を提供してしまい、解約増加に繋がります。それに、昨今のアプリやサービスのユーザは「すぐに改善される、すぐにバグが直る」が当たり前の感覚になっているかと思いますが、トラブル対応や開発以外の色々な手作業に忙殺されることによってエンジニアの開発にかける時間がなくなり、結果として、ユーザーの「あって当たり前感覚」についていくことができなくなって解約を招くことに繋がっていくかと思います。

続いて、DevOpsな状態のシナリオ（上図）を説明します。DevOpsな状態にするためには、初めに以下のことを考えます。本番環境、検証環境、開発環境などの環境を整えます。さらに、開発者がプログラムを作り動かす状態するプロセス（ビルドからデプロイまで）を自動化し、テストの自動化を組み込むことで、プログラムを作りながらテストできる状態にし、ユーザーが使う本番環境で動かすというのも自動化します。そうすることで、例えばリリースというボタンを押すと、新機能がリリースまで自動的に実行される環境が整います。結果、開発者はリリース後の新規機能開発に集中し続けることができます。

神原：初めからテストやデプロイの自動化をすれば、つまり、いろんな開発者がいろんな環境で開発するのではなく、統制された一つのプロセスで作ると、安定的なリリースができ、途中でミスがあっても防ぐことができる環境ということですね。

伊澤：手作りで始めると延々と手作りが続き、その先にはヒューマンエラーが待っているということで、確かに、と思いました。私たちも「アジャイルでやりましょう。考えたらまずはスクラッチでやりましょう」というアプローチを選択することが多いので、もしかしたら、こういうことがあるのかなと。また、DevOpsの状態というのは、最初の作業はボリューミーだと思いつつも、自動化することで後々の運用では、ヒューマンエラーがなくなるので、実はファンの繋ぎ込みができ、ファンを増やす面でもビジネス面に役立つと思いました。

神原：なるほど、DevOpsな状態にすることで、ユーザーの要求値や当たり前のUI/UXに応える反応が速くなり、ファンを増やすことができるから必要だと。

DevOpsな状態がユーザー体験の把握＆改善につながる

中島：ファンを増やすという意味では、Opsの取り組みの話になりますが、関連するものがあります。今までのITシステムの監視の取り組みには、CPUのリソースやメモリの監視をしたり、エラーがでたらアラートが出るよう設定したりする取り組みがありました。しかし、これらの監視方法では、例えば「アプリの動作が遅いのに直らない」といった良くないユーザー体験の状態を検知ができないケースがあると思っています。

そのため、ユーザーが快適な環境でアプリを利用しているかを応答時間で測ったり、応答時間がユーザーの増減によって影響を受けているか傾向値を測ったりなど、今までのCPUやメモリ等では測れない部分も監視できるように取り組んでいます。

伊澤：よくないユーザー体験の早期検知の取り組みはいいなと思います。私たちは、生の声を泥臭く拾うのは得意なのですが数字に関してはなかなか拾うのが弱いということもあります。どちらがいいという話ではないが、どちらも合わさってこそよくないユーザー体験を紐解く鍵になるので、裏の自動化といったアプローチも重要なんだと感じました。

〜視聴者からの質問〜

DevOpsを組み込むタイミングとは

神原：ビジネスが成長するか不明な状態にもかかわらず、自動化を組み込む導入タイミングを判断しなくてはいけないという、難しい状態ですが、いかがですか？

中島：正直、コストは本当に無駄ではないのかと言われることに、数字的に反論できないということはあります（苦笑）。かといって後回しにすると、じわじわ効いてくる話なんです。後から取り組む意志があるのであれば、最初から取り組みたいです。そうでないと、一回安定させた仕組みを変更する事にはどうしても恐怖心があるので、結局取り組まない判断をしがちです。導入のタイミングを検討をするのであれば、初めから、もしくは大幅な刷新のタイミングがベストです。

神原：お客さんの中には、今使っているシステムはもはや運用を変えられないので、次に大幅刷新する時にはクラウドネイティブな環境にしよう、というケースがありました、もしくは、やはり本気でこのビジネスを進めるぞ、とPOが覚悟した後からは入れた方がいいということですかね。

伊澤：プロダクトマーケットフィット前であれば、運用状態を想定できるかが判断基準になる気がします。どのようなユーザー体験をモニタリングすべきか議論できていたら可能性がありそうです。

神原：ある種この方法でいけそうだと自信を持つことができれば、DevOpsの状態にしておくべきだと考えることができるかもしれませんね

自動化以外のDevOpsの取り組み

中島：エンジニア観点から見た時は、DevOpsとしての業務は自動化がメインとなります。他にも、今ではデータベースやプログラムを動かすための機能をコードを記述するだけで作れるため、必要なものを全てコード化していくことも取り組みます。専門的には「インフラのコード化」と呼びますが、自動化だけでなく、プログラムで全て完結できるような状態にすれば、より生産性の向上に効果がでてきます。

DevOpsは、取り組む分野は多岐にわたります。エンジニア観点ではない部分も取り組みポイントがあると思います。

視点が違うからこそ、チームで話し合いながら開発する

神原：開発者と運用者のコミュニケーション促進という観点だと、アジャイル開発でプロダクト開発すれば、チームで朝会や振り返りをスプリントごとで実施します。そうなると、開発者と運用者が別れているわけではないですよね。

中島：そうですね。アジャイル開発体制では、作ってから動いているものの運用面までもみる体制になっていますから。

伊澤：私たちは顧客が喜ぶものを作るという前提をビジネス側もエンジニア側も共有したあとでプロダクト開発を進めているので、リリースした後でもビジネス側もエンジニア側も議論し続ける状態を作れています。ビジネス側がお客さんの要望に答えようとし、エンジニア大変だから譲らないという状態だと折衝が生まれるので、前提の線引きが大事かなと。

神原：つまり、全員が一体となれる状態が重要だと。それぞれが責任を押し付け合う状態ではなく、ある程度のバランスを保つためにも、プロダクトオーナーが「よしやるぞ」という一致団結しやすい環境を作り、全員でプロダクト開発に集中できるようにすることに尽きる気がします。

DevOpsエンジニアが不在の場合

中島：スクラム開発手法を採用している場合、専任のDevOpsエンジニアは通常不在であり、今まで述べたようなDevOpsに関わる業務は、スクラムマスターが開発チームに「これこれの取組が必要ではないか」という気付きを与えながら、開発チーム全員で検討して取り入れていくことになるでしょう。専門スキルを持った要員が開発チームにいなければ、チームとして技術を習得しながらの導入になるので、立ち上げに時間がかかる場合もあるかもしれません。

Build サービスの開発チームですと、前回のセミナーに出演した品質担当のエンジニアやCDSという、専門性が高い業務を担当するエンジニアが開発エンジニアと分業していますので、プロジェクトの初期段階から品質や自動化に関する取組を取り入れる、結果として、プロダクト開発を早くするめる、といったこともあると思います。

DevOpsのビジネス側の理解を促進するために

伊澤：自動化という言葉は効率化のイメージを持ちやすいかと思うのですが、私も最初はそう思っていました。システム効率化の話でしょという認識に止まるので、理解されないのだと思います。DevOpsという状態にすることで、ファンを増やす。ビジネスに直結するのだと伝えることで、理解を得られるのではないかと思います。

最後に

中島：普段漠然と考えていたこと、当然的に考えていたことを噛み砕いて説明することを通じて、自分の考えを見直す良いきっかけになりました。

伊澤：DevOpsは決してエンジニア側だけの話ではなくて、ファンを作るために必要なことだと認識できましたし、これからサービス開発する際に、このアプリを作る際に、この数値は取得した方がいいのでは、という新しい議論のタネが出てきそうだと感じました。

神原：DevOpsを組み込むか否かは、ビジネスとして総合的に判断するべきです。プロダクトの頻繁な変更がないのであれば、必要ないかもしれませんし、お客様の変化に合わせて当たり前に変えていくのであれば、DevOpsを導入すべきだと思います。

※現在、Buildサービス推進チームでは、下記ポジションを募集中です。ご興味のある方は、ぜひこちらもご覧ください。
・ソフトウェア開発エンジニア
・ソリューションオーナー
・ソリューションアーキテクト
・クオリティエンジニア