2022年1月17日
DevOps
このeBookの抜粋では、開発者体験における実験の重要性について解説しています。イノベーションの核となるのは、繰り返し、調整、最適化することです。
ビジネスの世界では、昔から実験が行われてきました。クレジットカードのベンダーが特定のカードの与信ルールを変更したり、小売店での商品の配置を変更したりと、ビジネスにおいて実験が行われることは想像がつきやすいでしょう。しかし、デプロイ時の痛みや恐れ、また影響の大きさが想定できない(例えば、全てのユーザーに影響する)ことから、開発の世界では、本番トラフィックやユーザーに対する実験はかなり長いサイクルで行われ、時には完全に避けられてしまうこともあります。
実験する能力は、素早く反復する能力と密接に関係しています。イノベーションの核となるのは、繰り返し、調整、最適化することです。さまざまな工夫や実験から得られたデータがなければ、改良はやみくもになりかねません。開発者にとって、ローカルや開発環境での実験は実施速度が速く、変更・実験の範囲が限定されており、素晴らしい経験になります。しかし、実際の生産データを取得し、重要なフィードバックループを提供するために、フィーチャーフラグが実験における開発者体験をサポートするための鍵となります。実験する能力は、開発者体験へのUXマッピングには当てはまらないかもしれませんが、より本質的な経験、例えば、製品の方向性を決め、型取りしていく能力なのです。
この記事は、eBook「One Developer Experience - Build, Deploy, and Experiment」からの抜粋を含んでいます。もし内容が気に入ったなら、最後までお付き合いください。無料です。
科学的手法の教えのように、実験を行う際には、データを取得し、ベースラインとコントロールが必要です。あるアプリケーションが正常か退行しているか判断するのも課題です。過去に遡っても、1つのアプリケーションの開発に一生のキャリアを費やす人は普通いません。
この記事は、eBook「One Developer Experience - Build, Deploy, and Experiment」からの抜粋を含んでいます。もし内容が気に入ったなら、最後までお付き合いください。無料です。
開発者にとっての共通の課題は、分散アプリケーションの正常なパフォーマンス動作について明確なイメージを持つことです。エンジニアが自然と最適化に長けていることから、プロジェクトを開始時、パフォーマンスや安定性を改善するという一般的な包括的目標が、通常、何らかの形でバックログに含まれています。
アプリケーションの「パフォーマンスは誰のものか」という問いは、まるでホットポテトゲームをしているようなものです。運用エンジニアからパフォーマンスエンジニア、そして機能を書いた開発者に至るまで、誰もが専門知識を持っています。開発者の立場からすると、開発者が本番環境やオンコールを担当していない限り、この情報を広めることは難しいでしょう。
本番前の環境であっても、変更を導入する場合、パフォーマンスへの影響や回帰は、本番環境に近づくまで見過ごされることがあります。「遅いことはシステムダウンと同じ」という格言は、内部顧客と外部顧客に共通して、正しいものです。以前は簡単にアクセスできなかった情報を発信することは、開発者体験の見つけやすさと信頼性の中核をなすものです。
見つけやすさと信頼性の両方をサポートする開発者体験において、最後の難関の1つは、コストと密度の最適化を解決することです。
システムの分散化が進むと、分散開発をサポートする本番前環境や、イテレーションの手間が増えます。解決すべき問題は2つに分かれます。本番前環境をどのように最適化するか、そして本番環境をどのように最適化するかです。最適化と情報発信を支援する機能を提供することが、より良い開発者体験を育みます。
エンジニアジョークの真髄のひとつに、「オフは簡単だが、オンに戻すのは難しい」というものがあります。開発インフラや分散環境のサポートには、かなりのコストがかかります。一方、リソースをシャットダウンすると、もう1つ遅れが生じます。最終的には、開発者がリソースを再稼働させる必要があります。コンピューティングとコンテナ技術の進歩により、この作業は数年前より若干早く行えるようになりました。開発環境は一貫して、分散したインフラを横断して立ち上げることができます。ワークロードを自動停止し、また自動起動する機能は、「もしまた必要になったら」という視点をサポートするのに役立ちます。
特定のアプリケーションやサービスに関連するパブリッククラウドの使用に関する明確で簡潔な情報を得ることは、データ集計や数学的計算の練習になることがあります。パブリッククラウドのワークロードに関する使用率、密度、コストの情報を公開することで、全てのエンジニアが最適化を行うことができます。シフトレフトされた現代のパラダイムと同様に、開発者は入手可能なデータに基づいて最善の決断を下すことになります。一般的に、コスト情報は財務部門によって秘匿されますが、この新しいFinOpsの方法論では、情報が共有され、最適化が適用されます。
Harness Platformは、これらの柱を全て提供し、アイデアから製品化までの開発者体験を向上させ、開発スピードに見合った多くの反復サイクルをサポートすることができます。
優れた開発者体験をサポートすることで、Accelerateの4つの主要な指標(展開頻度、変更のリードタイム、MTTR、および変更の失敗率)は全て改善されます。
開発者体験は、次世代のソフトウェアとプラットフォームを構築し、維持するための鍵です。テクノロジーが私たちの生活に浸透するにつれ、外部の顧客は機能がどのように製品化されるかに関心を持たなくなります。しかし、内部の顧客はそれらの機能の源であり、彼らの経験を向上させることは、イノベーションのパイプラインを改善し、育成することにつながります。また、エンジニアが短期間で生産性を向上させることは、学習とイノベーションの文化を育みます。
One Developer Experience eBookの実験に関する最後の抜粋を楽しんでいただけたでしょうか。全部を読みたい方は、今すぐeBook「One Developer Experience」をダウンロードしてください。無料です。
この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。