SDLCワークフロー

意図からリリースまでを管理するライフサイクルと、計画開始前に追加できる任意の承認チェックポイント。

Coroidはビルド工程だけでなく、完全なソフトウェアライフサイクルをモデル化します。その大部分は自動的に実行されますが、重要度が高い作業の場合にのみ有効にできる任意のチェックポイントも存在します。

任意のSDLCワークフロー

「新規作業フォームの詳細設定項目にはチェックボックスが用意されています：

SDLCワークフローを利用（任意）— 計画前に意図と仕様書をレビューします。この機能をオフにすると、要約から直接計画を開始できます。

デフォルトではオフに設定されています。オフの場合、要約は直接計画段階に進みます。オンにすると、まず2つの成果物が作成・承認されます：

これらが承認されて初めて計画が開始されます。

誤ったものを構築するコストが高い場合、依頼者が計画自体をレビューしない場合、または要約に記載された前提条件を文書化して合意を得たい場合に、この機能を有効にしてください。

要約が明確な場合はこの機能をオフにしてください。定型作業に余分な承認ゲートを設けると、メリットのない手間が発生するだけです。また、計画承認ステップはどちらの場合でも適用されます。

完全なライフサイクルは5つの段階で構成され、各段階で次の段階で利用される証拠が生成されます。

ステーション	実行内容	ステータス
定義	曖昧な要求が、承認済みの意図、決定事項、前提条件、成功指標に変換されます。	ベータ版
可視化	任意のUIコンセプトが洗練され、設計ガイダンスとして承認されます。	ベータ版
実装	計画が分解され、エージェントがそれを実行します。	利用可能
検証	要件がタスク、チェック項目、レビュー結果、プルリクエストの変更に紐付けられます。	利用可能
改善	モニタリング、修正、評価により、リグレッションが次のサイクルの作業に変換されます。	利用可能

定義と可視化は現在積極的に開発中の2つのステーションです。実装、検証、改善は、チェックポイントをオンにするかどうかにかかわらず、すべてのタスクで現在実行されています。

承認は成果物の正確なバージョンに紐付けられます。承認済みの成果物を編集すると、既存の合意内容が黙って変更されるのではなく、新しいドラフトが作成されます。

これこそが承認に意味を持たせる仕組みです。「仕様書」という曖昧な対象に承認を紐付けるのではなく、特定のバージョンに紐付けることで、後で文書の内容が変わっても合意内容が維持されます。そうでなければそれは真の承認とは言えません。

プロダクト、デザイン、技術、セキュリティ、リリースに関する責任を個別に割り当てられるため、セキュリティへの影響を承認する人が必ずしも作業範囲を承認する人とは限りません。

各ステーションで証拠を生成する目的は、完成したpull requestを遡って追跡できるようにするためです。つまり、この変更がこのタスクを実現し、そのタスクがこの要件に基づき、その要件が承認済みの意図に基づいていることを確認できます。

この一連の流れがあるからこそ、自律的なデリバリーの履歴を監査できるのです。これがなければ動作するコードはあっても、なぜそれが求められたコードなのかの根拠が残りません。

SDLCワークフローと計画は異なるチェックポイントです：

どちらか一方、両方、またはどちらも使用しないことも可能です。両方を利用する方が、意見が合わない完成したpull requestをレビューするよりもコストが抑えられます。