開発プロセスおよび手順の概要

この文書では、Leading2Leanの開発プロセスおよび手順の概要を説明します。このプロセスでは、本番サービスおよびインフラストラクチャーに変更を加える際にLeading2Leanが従うべき責任、ポリシー、手順について説明します。すべての従業員はこのポリシーに従う必要があります。

Leading2Leanのテクノロジーチームは、お客様に安定した信頼性の高いITインフラストラクチャーを提供する役割を担っています。開発プロセスの目的は、データセンター環境におけるサービス中断を最小限に抑え、システムの可用性と完全性を促進することです。最高技術責任者（CTO）は、必要に応じて開発プロセスおよび手順を維持・更新する責任を負います。このプロセスは、AICPA SOC 2 Type 2コンプライアンスプログラムの一環として定義された組織的統制によってさらに管理されています。これらの統制は、外部監査人によって毎年監査されます。

開発プロセスは、開発者がチケットを確認し、同僚とアーキテクチャおよび設計について調整し、コードを記述し、QAチームからフィードバックを受け、最終的にソフトウェアをお客様にリリースするという流れで始まります。 

範囲

この文書では、機能リクエストとバグのライフサイクルを定義します。また、各リリースで適切なテストと検証が確実に行われるようにするためのプロセスおよび手順についても説明します。この文書では、当社の変更管理ポリシーの概要で定義されている変更管理プロセスについては説明しません。

定義

バックログ：開発が開始されていないバグと機能の集合。バックログには、優先度の低いすべてのチケットが存在します。 

バグ：意図されたとおりに動作していない機能。バグの重大度は、軽微なものから非常に重大なものまでさまざまです。バグリストには、優先度の低いすべてのバグが存在します。チケットはトリアージ会議中にバグリストに登録されます。チケットはバグリストから開発チームのメンバーに割り当てられます。

機能または機能強化：ソフトウェアにまだ開発されていない動作。既存の機能の変更や、新しい機能の作成を指します。

プロジェクトまたはエピック：バグと機能の集合。プロジェクトはロードマップ上で管理されます。 

ロードマップ：プロジェクトの集合。ロードマップは、大規模なプロジェクトの計画ボードです。ロードマップは大小さまざまな新機能の開発を推進します。 

トリアージ：新しいチケットの収集。トリアージリストでは、すべての新しいチケットが作成されます。その後、トリアージチームがチケットをバグリスト、ロードマップ、またはバックログのいずれかに移動します。

概要

各開発チケットには、主に3つのフェーズがあります：1. 計画、2. 開発、3. 品質保証テスト。各フェーズについては以下で説明します。

計画

私たちは、計画プロセスにおいて、複数分野にまたがるトリアージアプローチを採用しています。サポート、開発、品質の各チームは定期的にトリアージミーティングを開催し、新しい問題、機能リクエスト、拡張機能を評価します。重大度に応じて、これらの問題は、高優先度の項目やサービスの低下が発生した場合にサービスを復旧するため、エスカレーションされたブレーク／フィックス対応サイクルを開始することがあります。それ以外の場合は、初期優先度が設定され、追加の計画、優先順位付け、スケジュール設定のためにプロダクトチームへ引き渡されます。

機能は通常、少人数の意見を取り入れて計画されます。これには、プロダクトチームのメンバー、専門分野の担当者、顧客などが含まれる場合があります。これはプロダクトマネジメントチームが主導します。

機能リクエストの大半は、ロードマップ計画ミーティングで話し合われます。このミーティングでは、プロジェクトとエスカレーションされた機能リクエストについて議論します。プロジェクトは他のプロジェクトとの比較で優先順位が付けられ、機能リクエストは確認されたうえでバックログに移されます。機能リクエストは、ロードマップ上のプロジェクトにリンクされる場合があります。

開発

計画プロセスが完了すると、この作業は開発チームに割り当てられます。開発チームには、本番環境をミラーリングした独自の開発環境があります。これは私たちの品質プログラムに不可欠な要素です。開発ライフサイクルの各段階（開発、品質保証、ステージング、生産）で、個別のインフラストラクチャーを維持し、完了した作業が生産環境に入る前に適切にテストおよび検証されるようにしています。

私たちは、リビジョン管理、自動テスト、静的コード解析、コードのクリーンネスを目的として設計された、業界標準の開発ツール一式を導入しています。これらのツールは、開発者に早期かつ頻繁にフィードバックを提供し、可能な限り高いコード品質を確保します。また、開発ブランチを適切に分離して、異なるプロジェクト、タスク、コードベースの要素に取り組む開発者間の相互汚染を防ぐのにも役立ちます。これらのツールは、ピアコードレビューと承認プロセスの標準化された方法を提供し、品質保証テストの準備が整ったコードが、すべての自動テストおよび検証チェックに合格していることを確実にします。

当社の開発者は、チケットの実装方法について疑問が生じた場合、サポートチーム、プロダクトチーム、または他の開発者と直接コミュニケーションを取ります。UIの変更にはすべて、プロダクトチームの承認が必要です。UIの変更は顧客に影響を与え、トレーニングが必要になる場合があるため、顧客、サポート、プロダクトチームと協力し、顧客への影響を最小限に抑えるため、UI変更の設計に適切な配慮がなされるようにしています。また、すべてのUI変更は、品質保証テストの段階でサポートチームによってレビューされ、適切な機能が存在すること、そして顧客に適切な通知とトレーニングが提供されることを検証します。

開発者は、通常の運用手順の一環として、変更を加える際に自動テストスイートを正常に実行することが求められます。チケットがこれらの自動テストに合格すると、開発者以外の誰かによるレビューを受ける準備が整います。このイベントにより、主要なチームメンバーはフィードバックを提供する時期であることを把握できるとともに、チケットがリリースに近づいていることも示されます。

すべてのコードは、QAチームに渡される前に、別の開発者によるピアレビューを受けます。これにより、複数の人が何が変更されたのか、そしてなぜ変更されたのかを把握し、理解していることを確実にできます。コードレビューの目的は、変更の全体的な目標について考え、単純なエラーがないかコードを確認し、非効率な部分がないかコードを調査し、何か正しく見えない場合には説明を求め、コーディング標準とベストプラクティスとの一貫性を維持することです。 テスト段階でのフィードバックにより、元の開発者がコードをリファクタリングすることがあります。これによってコードに大幅な変更が生じた場合は、追加のレビューが実施されます。 コードレビューの合意が記録および文書化されると、コードはQAチームにリリースできる状態になります。

品質保証テスト

自動テストスイートがエラーなく正常に完了し、コードレビューも正常に完了すると、QAチームは品質保証テストのプロセスを開始できます。

テストプロセスに関わる主な活動は、自動テストスクリプトの実行と手動テストの2つです。L2Lには、コマンドラインから実行されるUIテストケースと単体テストケースのスイートがあります。また、基本的なコーディングエラーを確認するために、コードに対して実行されるリンティングプロセスもあります。すべての開発者は、コードをレビューに提出する前に、テストスイートとリンティングプロセスの両方を実行する必要があります。QAチームは、コードをQAテスト環境にデプロイした後、自動テストスイートの結果を独自にレビューします。これにより、コード更新が設計どおりに、かつ品質基準に従って機能する能力を評価するためのクリーンなテスト環境が確保されます。

QAチームは、追加の品質を確保するために、コードの手動テストを調整します。QAチームからのフィードバックは開発チケットに記録されます。多くの場合、QAが承認する前にコードのリファクタリングと更新が必要になります。QAは、プルリクエストを承認することで、コードをマージする準備ができたことを示します。すべてが承認されると、QAはコードをメインコードベースにマージします。これにより、開発者がQAプロセスを回避してコードをメインコードベースにマージできないようにしています。

品質保証テストの段階では、QAチームはサポートチームのメンバーと顧客も活用してユーザー受け入れテストを実施します。これらのテストは、コードの変更が使用可能であり、顧客のニーズに適合し、業界の規制や要件に準拠していることを確認するために不可欠です。

変更管理プロセスと生産環境へのデプロイ

生産環境への変更が標準的なプロセスに従うようにするため、変更管理ポリシーの概要で定義されている変更管理プロセスを導入しています。これにより、生産環境の品質、セキュリティ、可用性を確保するために、組織内で適切なチェックとバランスが取られていることを保証します。このプロセスの詳細については、上記のリンクを参照してください。

変更管理プロセスの一環として、L2Lはコードリポジトリから顧客サーバーにソフトウェアをリリースするために、自動デプロイスクリプトを使用していることに注意してください。従業員が生産環境を手動で更新することは一切ありません。この自動システムは、新しいリリース／デプロイごとに監査証跡を作成し、適切な承認が得られていることを確認します。これが完了すると、リリーススクリプトによる生産サーバーの更新が許可されます。この自動スクリプトは、デプロイに関する社内通知も行います。デプロイが完了すると、この自動システムは「スモークテスト」も実行して、デプロイが正常に成功し、生産環境が適切に稼働していることを検証します。

振り返りミーティング

リリースされたコードによって古い問題が再発したり、システムが警告を発したりした場合、振り返りミーティング、別名ポストモーテムを実施します。このミーティングの目的は、問題のあるコードのリリースに関連する事実を収集し、同様の事象が将来発生するのを防ぐ方法について話し合い、将来の事象の防止に関連するタスクを割り当て、インシデントについてチームを教育することです。これらのミーティングは事象発生から36時間以内に実施し、根本原因分析とトレーニングを目的として、できるだけ多くの開発者および品質保証チームのメンバーが参加する必要があります。 

顧客への通知

顧客への通知は、このプロセス中の複数のタイミングで行われることがあります。顧客は、計画、開発、QAの各フェーズ、およびコードのリリース後に相談を受けることがよくあります。顧客には以下の方法で通知します。

• 個別連絡 / 予定されたミーティング。 特定の開発プロジェクトに関与する顧客は、計画、設計、プロジェクトの状況を確認するため、定期的な進捗ミーティングへの参加を招待される場合があります。
• 顧客への個別メール。すべての発端となったサポートチケットが更新され、変更が生産サーバーにリリースされたことを顧客に知らせたうえで、チケットはクローズされます。サポートチケットが作成されていない場合は、サポート担当者が顧客に直接連絡することがあります。変更の影響を受けた顧客が1社のみの場合、他の通知方法は使用されないことがあります。
• 変更履歴。顧客に影響を与えるすべての変更には、変更履歴が含まれます。これには、バグ修正、マイナーアップデート、機能リクエストが含まれます。変更が1社の顧客にのみ影響し、その影響が軽微で、顧客に直接連絡した場合は、変更履歴が追加されないことがあります。顧客はアプリケーションのサポートメニューから変更履歴にアクセスできます。
• 一斉メール。アプリへの大規模な変更については、すべての管理者にメールが送信されます。一斉メールは主に製品のお知らせや大規模なUI強化に使用されますが、その他のシナリオでも使用されることがあります。
• アプリ内通知は、影響のある変更に使用されることがあります。