ソフトウェアデリバリーの最先端のベストプラクティスと管理方法

この記事では、Chrisが最新のソフトウェアデリバリーを実践する方法と、ソフトウェアデリバリーのベストプラクティスとは何かについて解説しています。

Marc Andreessenが「ソフトウェアが世界を食べている」と言ったのは有名な話です。ソフトウェアとは、もはや静的なウェブサイトや、コンピューター上で動作するいくつかのプログラムだけではありません。現代のソフトウェアは、車を走らせ、医療を向上させ、猫のトイレの後始末までしてくれるのです。そう、最後の１つは映画で予言された未来ではありませんでしたが、現実になりました。話がそれました。この記事は、最新のソフトウェアデリバリーと、ソフトウェアデリバリーのベストプラクティスの２つの部分から構成されています。さっそく本題に入りましょう。

最新のソフトウェアデリバリー

ソフトウェアが日常生活の重要な構成要素となった今、リリースサイクルはより速く、ソフトウェアの品質はより高く、そしてセキュリティー（特にデータセキュリティー）は後回しにすることはできないのです。ニュースでは、毎週のようにこれらの各分野での失敗が報道されていますが、この新しい世界で成功するのは、適応できる企業です。

このように、最新のソフトウェアに対する要求は譲れないものであり、ビジネスのあり方にも変化を迫られています。老舗の技術系企業はソフトウェア開発ライフサイクルを完全に再設計し、ITが事業のコストセンターだった企業はソフトウェアに投資し、ヘルスケアから宇宙開発まで、長年の課題に対してソフトウェアを提供しようと大志を抱く何百ものスタートアップ企業が市場に溢れかえっているのです。

つまり、誰もがソフトウェアを提供する方法を改善する必要があるということです。わずか５年前のベストプラクティスは、既に時代遅れになっています。技術的な変化、イノベーション、市場の変化により、チームは常に需要に対応することに追われています。クラウド化、デジタルトランスフォーメーション、DevOps、DevSecOps、カオスエンジニアリングなど、近年、開発チームの注目を浴びているものは、ほんの一例に過ぎないのです。これらの課題にどのように取り組み、世界をより良い場所にすることができるのか、お話ししましょう。

目標から始める

データやベストプラクティスに飛びつく前に、成功とはどのようなものかを知る必要があります。各企業は、顧客ベースのニーズに基づいて、さまざまな目標を掲げています。Harnessでは、毎年数百社の企業様にお話を伺っています。その結果、一般的な目標は、この４つのカテゴリーのいずれか、または複数に分類されることが分かりました。そして、多くの場合、その全てに当てはまっているのです。

速度

ソフトウェアをより早く提供することは、私が話をするほぼ全ての企業にとって最重要課題です。市場の動きは速く、顧客の手元に届くまで何週間も何カ月も待つわけにはいきません。さらに、デリバリーサイクルが長いということは、実世界からのフィードバックが得られない新機能に、より多くの時間と資金が投資されていることを意味します。

ガバナンス

ほとんどの組織では、セキュリティー監査や業界特有の規制など、監査に対処する必要があります。全ての監査データを手作業でコンパイルすることが成長と速度に対応できないアプローチであると気づいたら、トレーサビリティー、文書化、ロギングをソフトウェア配信プロセスの設計に組み込んでおけば、将来の頭痛の種を減らすことができるのです。

品質

全ての組織がスピードにこだわり、高度な規制を受け、拡張のために最適化が必要なワークロードを持っているわけではありません。しかし、品質は全ての業界や業務に共通する目標です。人は、良い経験よりも悪い経験の方をよく覚えているものです。ですから、品質はソフトウェア開発のあらゆる側面に組み込まれなければならず、エンドユーザーが最新の機能を目にする直前に行うものではありません。

効率性

効率はしばしばスピードと密接な関係にありますが、上記のような他の考慮事項を加えると、効率不足はしばしばスピードを低下させる可能性があります。機能を迅速に市場に投入するためのプロセスには、トレードオフが伴うことが多く、こうしたプロセスを拡張すると、そのバランス感覚の悪さが増幅されることがあります。このような課題には、手作業による労力、クラウドにかかるコスト、メンテナンスなどが含まれます。 

ソフトウェアデリバリーのベストプラクティス

データ駆動型アプローチ

何を達成したいのかが分かったら、その成功を数値化する方法を検討し始めます。 効果的なソフトウェアデリバリーとメトリクスに関する文献は数多くありますが、筆者が選んだのはJez Humble、Gene Kim、Nicole Forsgren共著のAccelerateです。Accelerateの簡単な要約です。 高い業績を上げている組織には多くの共通点があり、それはデータによって証明されています。 余談ですが、Accelerateの指標に関する記事もありますので、ご興味のある方はぜひご覧ください。

現実の世界では、製造に対する定量的なアプローチによって、より高いレベルの生産性が引き出されていますが、ソフトウェアも同じです。ソフトウェアチームの生産性を示す指標については激しい議論がありますが、このデータを測定し、プロセスの改善に取り組むことについては異論がないでしょう。

アジャイルアプローチの活用

ソフトウェア開発プロセスを評価し、改善するために使用するのと同じ原則を、ソフトウェアに適用する必要があります。管理しやすく、測定可能な目標を設定し、素早く反復することで、顧客により迅速に対応することができます。ソフトウェアを提供することは、絶え間ないプロセスであり、フィードバックは最後まで残すべきものではありません。

新機能の提供は、フィードバックを迅速に提供できるような成果物を計画することから始まります。フィードバックを得る前に何カ月もかけて製品を作り上げると、要件が必ずしも意図通りに満たされず、コーナーケースが表面化せず、不要なトレードオフによって技術的負債が生じる可能性があるため、無駄が生じます。

データにもよりますが、およそ３分の２の組織がアジャイルを実践していると言われています。ということは、あなたも既にそうなっている可能性が高いですね。では、どうすればレベルアップできるのでしょうか？ １つは、このテーマについてよく研究された記事が一杯あることです。 

他には？よくぞ聞いてくれました。手前味噌ですが、フィーチャーフラグです。自作システムは何年も前から存在していましたが、開拓時代から数年で開発者、DevOpsチーム、製品管理者にまたがるユーザーベースを持つツールの本格的なエコシステムへと進化しました。フィーチャーフラグツールを使えば、実運用環境でのテストにつきもののリスクなしに、より速いイテレーション、より小さなコミットでのコードのマージ、アルファおよびベータ機能に関するフィードバックの収集が可能になるのです。

モノリスを捨てる

マイクロサービスは、数年前にバズワードのピークを迎えましたが、その宣伝文句は本物です。疎結合の異なるサービスを持つことで、チームはソフトウェアをより速く、より高い品質で提供することができます（実は、このブログでモノリスからマイクロサービスまでの道のりをお話ししました）。マイクロサービスアーキテクチャーでは、あなたのサービスはある役割を果たすことに責任を負います。他のサービスや組織の残りの部分は、あなたがどのように彼らが必要とする目的を達成するかには関心がなく、ただあなたがタイムリーに、正しい方法でそれを果たすことに関心があります。

このアプローチにより、ソフトウェア開発チームは、特定の言語、フレームワーク、デプロイメント戦略、および全てのサービスに適合しないその他のパターンへのコミットメントから解放されます。

ソースコントロールプロセス
 

コードは製品です。ソース管理の下流にあるものは全て、ブランチ処理、コードレビュー、マージ処理で行った決定によって影響を受けます。あるコードベースに触れるソフトウェア開発者が多ければ多いほど、マージの衝突やその他のロジスティックな問題が発生する可能性が高くなります。

レビュープロセス。ピアレビューのカルチャーを確立するために、慎重を期してください。変更点を検証し、フィードバックを提供することは、面倒なことではなく、品質のゲートとなります。これは、新しい開発者のための学習メカニズムを提供します。

頻繁にマージする。長期間のブランチは避ける。マージ時のコンフリクトや適切な統合の欠如は、納品速度を低下させ、品質を低下させる可能性があります。  生産までのリードタイムを最短にするための戦略として、トランクベース開発の利用を検討してください。

テスト

堅牢なテストは、高品質のソフトウェアを提供するための基礎であることは言うまでもありません。現在でも、アプリケーションのテストの大部分が納品時のQAフェーズで行われることは珍しくありません。シフトレフトの考え方の一環として、テストを書き、実行することは、ソフトウェアエンジニアリングにとって、アプリケーションのソースコードを書くことと同じくらい重要なことです。

頻繁な本番稼動は、厳格なテスト計画に依存しています。開発中は、ユニットテスト、異なるパーツを組み合わせるための統合テスト、そしてエンドユーザーエクスペリエンスが期待通りであることを検証するための機能テストを構築していきます。

自動テストの利点は明らかですが、大規模な導入に伴う新たな課題も浮上しています。主に、リソースと時間がどんどん消費されていくのです。

Harnessでは、まさにこの問題を解決するためにテストインテリジェンスを導入しました。

最後に、本番環境でのテストは、もはや第三のレールではありません。前述の機能フラグは、新しいものを試す際のコントロールレベルのパラダイムを変えました。ある機能が実際にどのように機能するかを見ることで、一般的なリリースに先駆けてより洗練されたものにすることができるのです。

CI

CIプロセスでは、複数の開発者が１つのコードベースに貢献しながら、一貫性のある、よくテストされた最終製品を維持することができます。ビルドプロセスに含まれるべきものとして、ユニットテスト、セキュリティースキャン、依存関係管理、コンパイル／ビルド、パッケージングを挙げることができます。

継続的開発・CD・継続的検証

ソフトウェアの配布は、長い間、手作業やスクリプトに悩まされ、コードを本番環境に導入するのに無駄な時間を費やしてきました。一般に、リリースプロセスには、インフラのプロビジョニング、テスト環境での検証、QAによるサインオフ／承認、そして最終的に本番環境へのデプロイといった、長いタスクのリストが含まれます。自動化されたソフトウェアデリバリは、プロセスの再現性と持続性を高め、監査時の責任を回避することができます。2022年の今こそ、デリバリーのためのスクリプトを捨てる時です。 最新のソフトウェアデリバリーツールは、デリバリープロセス全体を自動化するための豊富なツール、統合機能、オプションを提供します。

スピードと品質の両方の目標を達成するためには、デプロイメントの自動検証が必須です。これは、単にアプリの起動を確認したり、ヘルスエンドポイントがHTTP 200を迅速に提供したことを確認したりするだけではありません。検証は、メトリクスをパイプラインに結びつけ、一定期間アプリの健全性を評価し、デプロイ後すぐに発生する有害事象を見逃さないようにすることです。これは通常の監視体制に加え、Harness Continuous Verificationでは、AI/ML分析を用いて、パイプラインでそれらの既存ツールを使用する方法を提供していますが、それに加えて、このような方法もあります。

CIと協力する一方で、CDは別個の問題として解決されていることは注目に値します。私たちはこの素敵なブログで、CIとCDの細かいニュアンスについて多くの文章を費やして説明してきました。

セキュリティー

テストがQAチームだけの責任でないのと同様に、セキュリティーは全員の責任です。セキュリティーはソースコードの開発から始まり、成果物管理を含むプロセス全体を通して追跡され、最終的には環境への各デプロイメントまで行われます。

どの組織でもできる基本的な対策としては、CI/CD パイプラインでのセキュリティースキャンの要求、コード分析、SBOM（ソフトウェア部品表）の管理、リリースプロセス全体で実施される適切に設計された標準化などがあります。
 

プロセスに組み込まれたセキュリティーにより、開発者が正しい行動を取りやすくなる

シフトレフト

アジャイルアプローチでは、フィードバックと応答性が最も重要です。シフトレフトの考え方は、最終製品のあらゆる重要な側面に対するコントロールを、ソフトウェアチームの手に委ねることです。 セキュリティーを例にとって考えてみましょう。安全でない可能性のあるコードや依存関係を、チームが別の取り組みに移ってしまった後ではなく、ソフトウェア製品の構築中に認識することができれば、最終製品の安全性がどれほど高まるでしょうか。

チームがセキュリティー、テスト、Infrastructure as Codeとして管理するためにわずかな時間を前もって費やすだけで、顧客満足度やビジネス目標達成のための俊敏性が向上し、長期的にはリソースを節約することができるのです。

Source

ソフトウェア開発の効率的な管理

ツール

ソフトウェア開発の加速は、その課題に対応するために多数の優れたツールを生み出しました。Jenkinsのようなオープンソースプロジェクトは最新のCI/CDソリューションへの道を開き、GitLabのような製品はバージョン管理にファーストクラスのCI体験をもたらし、Jira Boardはソフトウェアデリバリーの定番であり、忘れてはならないのはHarnessが最初の最新のCDソリューションを市場に送り出したことです。 

ソフトウェア開発のための最新のソフトウェアソリューションは、MVP（実用最小限の製品）ソリューションからホワイトグローブソリューション、そしてフルプロダクトスイートまで多岐にわたります。コスト、買うか作るか、開発者の経験などをめぐる議論では、常に押し問答が繰り広げられています。優れた組織は最適なツールに投資します。なぜなら、ツールの問題に取り組んでいる全ての開発者は、顧客の問題に取り組んでいるわけではないからです。

カルチャー

ソフトウェアは人にまつわる仕事です。しかし、技術、ツール、トレンドの嵐の中で、このことはしばしば忘れ去られがちです。ソフトウェアは、家庭を持ち、仕事以外のことに興味を持つ人間によって書かれます。生産性の高いチームを運営するためには、人とその時間を尊重するカルチャーが必要です。さらに、仕事と機会の急速な拡大に伴い、多くの開発者は、有害なカルチャー、悪いマネージャー、不十分な開発ツールやプロセスに対処するくらいなら、退職するでしょう。キャリア開発、オフィスの真ん中に卓球台とドリンクサーバーを置くことに留まらないチームビルディング、そしてフィードバックに耳を傾けることに時間とリソースを投資してください。

継続的改善

ここで最も重要なポイントは、これは旅であるということでしょう。どんなに優秀でクリエイティブな人材を採用しても、全てを解決した組織はありません。自分の成功を、業界全体、同僚、そして最も重要な自分自身に対して評価してください。あなたのソフトウェア開発プロセスは、昨日よりも今日のほうがより良くなっているはずです。

最後の振り返り

Harnessでは、世界最大手の銀行からアーリーステージのスタートアップまで、さまざまなお客様とパートナーシップを結んでいます。このような企業様のパートナーとして、開発プロセスを最適化し、デリバリー目標に合致させるための正しい方法を見つけるお手伝いをすることが、私たちの重要な役割です。ソフトウェアのデリバリーを成功させるには、プランニング、カルチャー、そしてツールの３つが必要です。

ツールはソフトウェアデリバリープロセスをサポートするものなのか、それともあなたの作業を遅らせるものなのか？CI、CD、フィーチャーフラグなど、当社のソフトウェアデリバリープラットフォームについてお話しましょう。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。