もしあなたが、将来インテリジェントエッジで動作するデバイスやシステムのソフトウェアを開発する予定があり、DevOpsが価値ある取り組みであるという考えをお持ちで、開発を次のレベルに引き上げる方法を知りたいと思っているのであれば、この記事は正しい場所です。
Google DevOps, Research, and Assessment (DORA) チームが発表した最新の「State of DevOps」レポートによると、パフォーマンスの低いDevOpsチームは、ソフトウェアの本番環境へのデプロイ頻度が6ヶ月に満たないということです。その場合、おそらく16%～30%の割合で変更に失敗しており、コードから本番環境に移行するには最大で6ヶ月のリードタイムが必要となります。変更の頻度が低く、何かを壊すリスクが比較的高く、次の更新に6ヶ月かかっているのです。
これを、973倍の頻度でデプロイすることができ（基本的に1日に何度もオンデマンドで行う）、コミットからデプロイまでのリードタイムが6,570倍速く、インシデントからの回復も速く、変更の失敗が30％少ない、パフォーマンスの高い優秀なチームと比較してみてください。
この数字は素晴らしいものですが、少し抽象的かもしれません。失敗を金額に換算するとどうなるでしょうか。
Consortium for IT Software Quality（CISQ）が発表した2018年のレポートによると、米国における品質の低いソフトウェアの総コストは2兆8400億ドルでした。これは、失敗したプロジェクト1件あたり、平均で約5000万ドル（約55億円）に相当します。この金額は大袈裟かもしれませんが、本当にそれだけのお金を失う余裕があるのか、考えてみてください。
なぜ、高品質のソフトウェアをリリースすることは難しいのでしょうか？
お客様の要望を理解し、それにタイムリーに応えることは、組織にとって難しいというのが一般的な認識です。アジャイルやその他の最新の開発プロセスはリスクを減らすことを目的としていますが、組織全体でどのようにして関連性のあるスピードで価値を提供し続けることができるのでしょうか。
つまり、DevOpsを行うことは良いことであり、それをより良く行うことで真の利益が得られるということです。
では、何が必要で、どのように行えばいいのでしょうか？
DevOpsの基本はすでに実証済みであると仮定します。
あなたのチームはおそらく、よりアジャイルで、より連携が取れ、コラボレーションが改善されていることでしょう。もしかしたら、以前よりも早く、より質の高いコードを本番環境に投入できるようになっているかもしれません。あなたがその実現に一役買ったのであれば、大変すばらしいです！
しかしこの時点で、改善効果が安定しているかもしれませんが、経営陣の期待値に達していない可能性があります。その場合、次の一手を考える必要があります。
ROI を証明する必要があるという問題があります。次の変化は、初期のフェーズで見ることができたような深遠なものにはならないかもしれないという懸念もあります。では、DevOpsの効果を加速させるような漸進的な変化は、どのように行ったらよいのでしょうか。変更を行う際、おそらく次の問題のいずれか、または両方に遭遇するのではないでしょうか。
1. 抵抗の克服：新しいDevOpsプラクティスを導入したいとチームに提案しても、チームではすでに現在のプラクティスを中心にワークフローを設計してしまっているケースがあります。特に、前回の変更に慣れてきたところで、変更を求めることは難しいものです。
2. 経営陣の過大な期待：経営陣の期待は非常に高く、作業がどれほど複雑なものであるかを理解していないのではないかと思えることがしばしばあるという経験があるのではないでしょうか？常に革新的でなければならないというプレッシャーもあります。「より迅速に」は、現実的には良い問題かもしれません。しかし、問題はそれについていけるかどうかです。
抵抗とプレッシャーという2つの問題に対処する方法が１つあります。「care abouts（関心ごと）」を特定し、変更したい指標を見つけることです。誰も、「ソフトウェアを悪くするためにプロセスを変えろ」とは言いません。しかし、単に「より良く、より速く」というのも、問題解決には有用ではありません。
ROIの構築方法やDevOpsへの投資を増やすためのケースを検討する際の測定可能なことと不可能なことを見てみましょう。
ほとんどの企業は、顧客から報告された不具合を解決するために、どれだけのコストがかかるかを試算することができます。自動テストが増加すれば、不具合はより早く発見され、より低コストで修正できます。もし、出荷時の不具合を5%～10%減らすことができれば、それは現在持っている（あるいは見つけることができる）データに基づいた見積もり可能な価値となります。
不具合を修正する作業が必要ですので、節約分を二重に計上しないことに注意してください。
測定は難しいけれども、時間とともに変化し、追跡する価値のあるものもあります。そのよい例がレピュテーション（評判）です。企業の評判を測る方法はさまざまです。ウインドリバーでは、ネットプロモータースコア（NPS）、または、お客様が当社を誰かに推薦する可能性がどの程度あるかという尺度を使用して測定しています。あなたの会社では、別の測定基準を使用しているかもしれません。重要なのは、この指標を使用して市場での評判を追跡することができるということです。品質が向上したためなのか、あるいは他の市場の力によってなのか、評判の因果関係を証明するのは難しいことです。しかし、この指標を長期的に追跡すれば、肯定的または否定的な傾向を特定できます。
評判は売上に影響を与えるものであり、そのデータにアクセスできれば、傾向を知ることも可能です。満足度の高いお客様の契約更新の増加、既存顧客の他プロジェクトへの横展開、あるいはポジティブな報道からもたらされるリードなどは、営業チームやマーケティングチームが追跡可能なものです。繰り返しになりますが、因果関係を証明することは困難ですが、追跡する価値はあります。
そして、最終的な収益を向上させるコスト削減を中心に、良い例を作ることができます。また、経営陣に改善を示すために、貴社がすでに追跡している測定しにくい指標を強化することができます。
さて、何を求めたらよいのか、そしてDevOpsを改善することでどのようにそれを実現することができるのかを理解したところで、悪い知らせがあります。
インテリジェントエッジ向け開発のハードウェア問題です。しかし、シミュレーションがその問題を解決してくれるとうい良いニュースもあります。
次回は、ハードウェアが引き起こす可能性のある問題の具体的な例と、それを解決するためのシミュレーションについてご紹介します。
また、このトピックスを紹介する動画を作成しました。以下でご覧いただけます。
https://www.windriver.com/resources/webinars/devops-with-simulation-can-solve-your-hardware-problem
Wind River Simicsについての詳細は以下をご覧ください。
https://www.windriver.com/japan/products/simics