Tenex のシチズン・デベロッパー SDLC のご紹介。これは、AI を使って非技術系従業員が構築したものを、個人のプロトタイプから、全社が依存できる本番環境へと導く、6 つのステージからなるライフサイクルです。
執筆者: Alex Lieberman (@businessbarista)、Arman Hezarkhani (@ArmanHezarkhani)、Suchi Patel、Ashwin Kadaru (*@AshwinKadaru
Tenex.co のフレームワークです。
概要
シチズン SDLC は、AI を使って非技術系従業員が構築したソフトウェアを、個人のプロトタイプから管理された本番環境へと導く、6 つのステージ（アイデア、フロントドア、トリアージ、プロビジョニング、ビルド、運用と変更）からなるライフサイクルです。すべてのステージには、一つの原則が貫かれています。AI が労働を担い、決定論的なコードがガードレールを設定し、人間が例外を処理する。この枠組みが存在する理由は、AI がコードを書くコストをほぼゼロにまで下げ、ボトルネックを下流、つまり、構築されたものが健全であることを確認し、稼働後は増え続けるアプリ群を管理することに移したからです。
私たちのクライアントの一社は、投資会社です。ポートフォリオ・オペレーションズ・チームのメンバー、つまりコードを一行も書いたことのない人物が、現在彼女のチーム全体が毎日使っているダッシュボードを構築しました。これは、数十社のポートフォリオ企業にわたる価値創造の取り組みを追跡するものです。彼女は Claude にプロンプトを送り、約 2 ヶ月かけて反復作業を行いながら構築しました。すべての行は AI によって書かれました。
そして、これは優れたものです。表示は適切で、ワークフローはチームの実際の運用方法に適合しており、導入は瞬時に行われました。彼女は、エンジニアが関与する前に、正しいプロダクトをスケッチしたのです。
それは偶然ではありません。何十年もの間、ビジネス上の問題を理解している人が、それを解決するソフトウェアを構築できる人であることはほとんどありませんでした。そのギャップを埋めることは、非常に困難な作業でした。彼女の問題を仕様に変換するプロダクトマネージャー、仕様をコードに変換するエンジニア、そしてロードマップ上の他のすべてのタスクの後ろに並ぶ順番待ち。アイデアからツールができるまでには数ヶ月がかかり、最終的にリリースされたものは、彼女が意図したことの誰か他の人の解釈でした。
そのギャップは今、崩壊しました。構築する力は、プロセスを実際に理解し、データの意味を知り、日々そのワークフローの中で生きている人々に移りました。彼女は、自分こそが情報源だったため、最初の試行で正しいものを構築しました。誰も彼女の意図を翻訳したり、少し間違って伝えたりするために間に立つことはありませんでした。これこそがシチズン・デベロップメントの約束であり、彼女はそれを実現しました。
それから私たちは、その内部を覗いてみました。
アプリケーション全体は 1 つの HTML ファイルでした。540 KB。約 5,300 行。マスターデータセットは、1 行に 80 KB のデータブロブとして内部に存在していました。ファイルを更新する必要があるとき、AI は、アプリが読み込まれるたびに値を書き換えるパッチ関数を追加で組み込んでいました。作業を保存するということは、アプリが自身の HTML を書き換え、自分のラップトップにダウンロードし、新しいバージョンとして共有ドライブに再アップロードすることを意味しました。2 人が同時に編集した場合、最後に保存した人が勝ち、もう一方の人の編集内容は消えました。
ある日、保存関数がファイル内のマーカーを探しに行き、見つからず、それでも持っていたものを書き戻しました。540 KB のアプリケーション全体が 7 バイトに切り詰められました。たった一度の静かな書き込みで、彼女のチームが毎日依存していたダッシュボードは存在しなくなり、その構築方法には、それを検出したり、阻止したり、復元したりするための仕組みは何もありませんでした。
ほとんどのリーダーはこの話を聞いて、シチズン・デベロップメントはシャットダウンすべき責任だと結論付けます。私たちは、それは間違った教訓であり、それに基づいて行動する企業は敗北するだろうと考えています。正しい教訓はこうです。彼女は自分の仕事を見事に遂行した。誰もソフトウェアが出荷されるための道を整備していなかっただけなのです。
ボトルネックが移動した
何十年もの間、ソフトウェアを構築することは高価な部分でした。それは遅く、希少で、コストがかかり、ソフトウェア開発ライフサイクル全体はそれを保護するために発展してきました。仕様、チケット、スプリント、コードレビュー：従来の SDLC におけるすべての儀式は、コードを書くことがボトルネックだったために存在しています。
AI はそのステージをほぼゼロにまで崩壊させ、ボトルネックは移動しました。誰でも半日で動作するアプリを構築できるようになった今、高価な作業はもはや構築することではありません。それは、その後に来ることです。構築されたものが健全で安全であることを確認し、それらのアプリが稼働した後は、増え続けるアプリ群を管理し続けることです。
GIF
そして、構築のペースは衰えておらず、解決すべき 2 つの問題を生み出しています。
第一に、内部の品質です。非エンジニアが白紙の状態からエージェントにプロンプトを送ると、今日は動くが、永遠に保守不可能な場当たり的なソフトウェアに収束します。540 KB のファイルは例外ではありません。それは、レールなしで構築した場合のデフォルトのアウトプットです。
第二に、乱立です。すべてのチームが独自のアプリを欲しがり、中央の IT 部門がそれらを手作業で構築し、運用することは不可能です。ガードレールがなければ、それぞれのアプリは、ビルダーやモデルが手にしたスタック（異なるデータベース、異なる認証方式、あちこちに隠されたシークレット）の上に構築されます。代わりにリクエストをブロックしても、彼らは止まらず、オフブックに移動するだけです。どちらの場合でも、あなたはアプリ群だけでなく、その下にあるインフラストラクチャの複雑な混乱を引き継ぐことになり、そのどれも IT が合理的にセキュリティ保護、サポート、説明できるものではありません。
そこで、すべての企業が直面しようとしている本当の疑問はこれです。非技術系スタッフに本当の社内ソフトウェアをリリースさせつつ、そのアプリ群を引き継がないようにするには、どうすればよいのか？
3 つのデフォルトの答えはすべて失敗します。
1) ロックダウンする。 リクエストはキュー待ちになり、忍耐は尽き、シャドウアプリはいずれにせよ構築されます。そうなると、あなたはそのどれも見ることができません。見えないものは管理できません。
2) そのままやらせる。 非エンジニアを構造のない AI ツールに向かわせ、デモを称賛する。これが 540 KB のファイルを得る方法です。そして、事後的にレビューでそこから抜け出すことはできません。モノリスがコードレビューに現れる頃には、それはすでにモノリスです。それは出発点で防止されなければなりません。
3) すべてをレビューする。 すべての変更に人間の承認を置く。あなたの IT チームはスリムで、ビルドの量は爆発的に増加しており、今やすべてのデプロイはレビュー担当者のカレンダーを待つことになります。レビューは採用を殺すか、形だけのものになるかのどちらかです。どちらの結果も目的を無効にします。
したがって、答えは別のポリシー文書ではなく、ライフサイクルです。つまり、自分を開発者とは決して呼ばない人々のために設計され、ガードレールがメモに書かれるのではなくプラットフォームに組み込まれた、真の SDLC です。ビルドを、最初の平易な言葉によるアイデアから、ビルダーにエンジニアになることを求めることなく、管理された本番環境に至るまで運ぶ道です。人が意図を提供し、プラットフォームが規律を提供します。
そのすべてのステージには、一つの原則が貫かれています。AI が労働を担い、決定論的なコードがガードレールを設定し、人間が例外を処理する。 AI がドラフトを作成し、分類し、記述します。コードが何を許可するかを決定します。人が使われるのは、実際に判断が必要な場合のみです。その分割を維持してください。それが全体をスケーラブルにするものです。
私たちはこれをシチズン SDLC と呼びます。6 つのステージで、それぞれが管理されています。
ステージ 1
アイデア
ある人が、AI の助けを借りて、アプリを平易な言葉で説明します。何をするのか、誰が使うのか、どのデータに触れるのか、誰が所有するのか。数分で完了し、覚書のように読めます。これは、下流のすべてが基づくブリーフとしても機能します。これがオペレーティングモデルの最初の動きです。AI が、とりとめのない話を構造化された成果物に変える労働を担います。
実際にどのように見えるかを示します。ファンドファイナンスの誰かが次のようにタイプします。「出資喚起通知書のトラッカーが欲しい。現在は手動で更新するスプレッドシートで、毎週金曜日にメールで送っている。」AI は、インテークアナリストが尋ねるような質問をします。他に誰が見る必要があるのか？ファンドファイナンスと IR の 12 人。データは現在どこにあるのか？Box のスプレッドシートで、読み取り専用で十分。あなたがいないときの所有者は？彼女のマネージャー。とりとめのない話はブリーフになりました。目的、ユーザー、データソース、アクセスレベル、所有者、さらにはアプリの形状の最初の推測まで。PRD という言葉を聞いたことのない人によって書かれた、事実上の PRD です。
GIF
まだ何も存在しません。コードも、アクセスも、インフラもありません。これは意図的です。企業は、アプリが存在する前にそのアプリについて意見を形成し、アプリが重要な役割を担うようになってから 6 ヶ月後ではありません。
ステージ 2
フロントドア
すべてのリクエストは、1 つの構造化されたフロントドアを通過し、それをファイルするのと同じ動作で、直接トリアージに送られます。ブリーフは、リクエスト、IT が見るチケット、永続的な記録、そして誰もが検索できるカタログのエントリを、すべて同時に兼ねます。廊下での依頼も、コネも、シャドウパイプラインもありません。見えないものは管理できず、見つけられないものは共有できません。フロントドアは、初日から両方を真実にします。
これは、シャドウパイプラインを殺すステージです。フロントドアをスキップしたビルドは、ラップトップ上のプロトタイプとして存在することはできますが、そこに留まります。プロトタイプをチームが依存できるソフトウェアに変えるものはすべて、このステージの下流にあります。真のストレージ、企業サインイン、デプロイパイプライン、実際に実行する場所。それらのどれも、フロントドアを通過したことのないビルドには届きません。フロントドアを迂回することはできます。ただし、プロトタイプを超えることはできません。
ステージ 3
トリアージ
AI は、2 つの軸に沿ってリクエストを分類します。形状: それはどのような種類のアプリか？従業員が実際に構築するものの逆監査は、ほとんどの場合、短いリストに収束します。アーティファクト生成ツール、ワークフロー自動化、CRUD アプリ、インタラクティブダッシュボード。形状を特定することで、必要なアーキテクチャがわかり、次のステージにスタンプを押すための舗装された道を渡します。爆発半径: このビルドがうまくいかなかった場合、どれだけの損害が発生する可能性があるか？私たちはこれを 4 つの次元でスコアリングします。
- 到達範囲と機能: 何に触れることができ、書き込み可能か、読み取りのみか？
- 可逆性と自律性: 人間がループ内にいるか、そのアクションは元に戻せるか？
- 露出: 誰が出力を見るのか、会社の外にどれだけ広がるのか？
- データの機密性: 相互作用するデータの機密性はどの程度か？
しかし、これを信頼できるものにするルールはこれです。AI が助言する。コードが決定する。 モデルはブリーフを読み、分類します。その後、IT が書いたポリシーコードが、各分類をルールに対してチェックします。出資喚起トラッカーでどのように機能するか見てみましょう。形状: インタラクティブダッシュボード。爆発半径: 内部ファンドデータ、12 人の内部ユーザー、読み取り専用、人間がループ内にいる、既存のアプリとの重複なし。すべての次元が承認されたしきい値内に収まるため、承認され、誰もそれについて議論しませんでした。
ここで、1 つの事実を変更します。トラッカーが LP のコミットメントデータも必要だとします。ブリーフがどんなに説得力があっても、その 1 つの変更により、データ感度の次元が IT が設定したしきい値を超え、リクエストは人のもとへ行きます。その間に判断は行われませんでした。ルールが一致するか、しないかのどちらかです。
3 つの出口があります。
- 承認済み。 爆発半径がすべてのしきい値内、完全なブリーフ、高い信頼性。私たちのクライアントでは、約 10 件中 9 件のリクエストがこのように自動的に解決されます。
- 再利用。 既存のアプリと重複するため、リクエスト者は重複を構築する代わりに、そのアプリの所有者に誘導されます。重複は統合され、増殖しません。
- エスカレーション。 ある次元がそのしきい値を超えたか、信頼性が低い。IT とセキュリティの人間が、完全なリクエストをコンテキストとして受け取ります。
GIF
10 番目のリクエスト、つまり例外的なものは、完全なブリーフが添付された状態で、依然として人間の机の上に届きます。他の 9 件は、人間を必要としませんでした。
ステージ 4
プロビジョニング
ここが、IT が大量に「はい」と言えるようにする動きです。プロビジョニングは、IT が出荷するものの制御を失うことではなく、IT の制御が上流に移動することです。IT は、すべてのアプリを事後的にレビューする代わりに、舗装された道を一度作成し、すべてのアプリがその上で生まれます。一人が承認すると、プラットフォームは、その形状に応じてアプリに道からスタンプを押します。リポジトリ、企業サインイン、デプロイ ID、プライベート環境、独自のデータベース。これらはすべて、IT が所有しバージョン管理するインフラストラクチャ・アズ・コードとして定義されます。数分でプロビジョニングされます。
この瞬間だけ、昇格された権限が実行され、その前に人間がいます。すべてのアプリは、隔離され、管理され、監査されて生まれます。独自の壁で囲まれた環境、パブリックアドレスなし、保存されたクラウドシークレットなし、初日からの追加専用の監査証跡。セキュリティ作業は、道の中で一度行われました。どのアプリもそれを繰り返す必要はありません。
道は形状ごとに作成されるため、人間による承認はデフォルトの姿勢であり、永続的な税金ではありません。新しい形状と高い爆発半径のビルドは、人間のゲートを永久に維持します。しかし、一度形状の道が十分な数のビルドで実績を証明すれば、その道での低い爆発半径のリクエストは自動的にプロビジョニングできます。これは、同じ「末尾のために人間の判断を温存する」というロジックを、1 ステージ早く適用したものです。初期にはより多くのリクエストを人に回し、パターンが維持されるにつれて、ラインは自動化に向かってシフトします。
そして、道は、インフラストラクチャと同じくらい重要なもう一つのものを運びます。それは、AI ルールブックです。継承されたリポジトリは、コーディングエージェントに、セッションごとに実行する一連の指示を渡し、実際の失敗から学んだアンチパターンをエンコードします。1 KB を超えるデータブロブをインライン化しない。アプリの読み込み時にデータを書き換える関数を追加しない。これが、ビルダーにベストプラクティスを一つも知ることを求めずに、内部の品質を解決する方法です。道がエージェントにそれらに従わせるのです。それらのルールのそれぞれは、背後に物語のある傷跡です（あなたはそのうちの一つを読んだことがあります）。
ステージ 5
ビルド
ビルダーは、自分のラップトップではなく、管理されたクラウドワークスペース内で、コーディングエージェント（Claude Code、Codex など）にプロンプトを送ります。ラップトップ上のターミナルエージェントは、そこにあるすべてのもの（メール、同期ドライブ、ブラウザクッキー、キャッシュされた認証情報）を継承します。ワークスペースでは、エージェントはプロジェクトを見ます。それ以外は何も見ません。
エンジニアが通常携帯するものはすべて、代わりにレールによって運ばれます。私たちのクライアントでは、ビルダーがオフにできない 4 つのレイヤーに 35 のガードレールがあります。
マージレイヤーには、AI 生成コード専用に設計されたドリフトチェックが含まれています。ファイルサイズの予算、過大なインラインデータなし、監査ログへの準拠。合格するか、マージされません。チェックが失敗した場合、ビルダーはエージェントに修正を依頼し、再度プッシュします。
人間はルーチン変更をレビューしません。チェックがレビューです。ルーチン変更は、レビュー担当者のカレンダーの速度ではなく、CI の速度で移動します。人間に届くのは、結果的な末尾であり、機械的に検出されます。破壊的なスキーマ変更、新しい依存関係、エージェント自身の制約の変更、インフラストラクチャに触れるもの。これらは人を待ちます。それ以外は何も待ちません。そして、何か新しいものがそれでもすり抜けた場合、修正は新しい自動チェックであり、より多くの人間のレビューではありません。システムは、会議を追加するのではなく、教訓をエンコードすることによって、より厳格になります。冒頭のダッシュボードを思い出してください。そのドリフトチェックのうち 2 つは、最初の週に発動していたでしょう。80 KB の 1 行ブロブは、最初のコミットで CI に失敗していたはずであり、障害モードが定着する何ヶ月も前に。
ステージ 6
運用と変更
6 ヶ月後、出資喚起トラッカーはまだ稼働しており、ここでライフサイクルがその価値を発揮します。IR の誰かが 3 月の通知書の送金期限について疑問を持ちます。監査証跡が 30 秒で答えを出します。誰がいつフィールドを変更したか、変更前の値は何だったかが、編集自体と同じトランザクションで記録されています。誰もメールのやり取りから真実を再構築しません。ビルダーがチームを異動するとき、所有権は肩をすくめて消え去るのではなく、指名された後任者に移譲されます。そして、彼女が会社を完全に去る場合、彼女のサインインは無効になり、それが開いていたすべてのドアは同時に閉じます。トラッカーも含めて。来四半期の機能リクエストは、最初のコミットと同じレールをたどります。
ガバナンスは、年次監査ではなく、シグナルに基づいて実行されます。トラッカーの使用状況メトリクスは、さらに 2 つのチームがそれに依存していることを示しており、昇格され、投資されます。4 月以降誰も開いていない通貨ダッシュボードは、メニュー内で腐るままにされるのではなく、アーカイブされます。誰もそれを惜しみません。所有権は初日に割り当てられるため、ビルダーがいなくなった後も、所有者のないまま存続することはありません。文書はアプリの進化に合わせて再生成されるため、古くなることはありません。使われていないアプリは、トロフィーではなく、失敗です。目標はアプリの数ではありませんでした。それは、忘れ去られたソフトウェアの墓場ではなく、あなたの従業員が実際に信頼する生きたカタログです。
カタログが 10 のアプリから 200 に成長するにつれて、中央のチームはもはやそのすべてに目を光らせることができなくなり、監視はアプリを所有するチームへと外側に押し出される必要があります。それをいつ、どの程度まで連邦化するかは判断であり、ポートフォリオが成長するにつれて変化します。ここでのガバナンスは、一度設定したら終わりのコントロールではなく、調整し続ける姿勢です。
全体を支えるルール
私たちがすべてのクライアントに教えるトリガーが 1 つあります。それは、「これには完全なプロセスが必要か？」という質問の 90% に答えるからです。第 2 コンシューマルール。 これが機能するのは、その瞬間にリスクプロファイルが変わるからです。
自分自身のために、自分のラップトップで、制限されたデータアクセスで分析を構築している人がいる？爆発半径は低く、ガバナンスは軽微です。自分自身のために実行するチャート、メモ、スクリプトは、デプロイパイプラインを必要としません。しかし、2 人目の人物が、作成者に更新を依頼する代わりに、出力を直接使用したいと思った瞬間？爆発半径は跳ね上がります。より多くの到達範囲、データがより遠くへ移動する、誰かがそれが正しいと信頼する。それは今やソフトウェアであり、完全なライフサイクルに、意図的に、明確なイベントとして卒業します。同じデータソース、同じ ID、新しい道。
この 1 つのルールにより、プロセスが人々を溺れさせることがありません。ほとんどのビルドはその線を越えることはありません。越えるものはまさに、その儀式に値するものだけです。
私たちが正直に認めていること
どのプラットフォームも、初めてのビルダーに完璧なコードを書かせることはできません。私たちもそれを主張しません。レイヤーは、ミスが全社的なインシデントではなく、1 つの小さな境界内での不便さで済むように存在します。各レイヤーは、その上のレイヤーがカバーできないものを正確にカバーします。
そして、監査は何も防ぎませんが、すべてのインシデントを短く、説明可能で、責任の所在を明確にします。それが、悪い午後と悪い四半期の違いです。
シチズン・デベロップメントは、プロフェッショナルエンジニアリングを置き換えることを意図していません。規制されたプロセスにおける記録システム、顧客向けまたは投資家向けのもの、外部ユーザー向けに構築されたアプリ、ダウンタイムが金銭的ペナルティを伴うものは、依然としてエンジニアリングに属し、フロントドアは初日にそれらをそこにルーティングします。それが置き換えるのはボトルネックです。それは、正式なエンジニアリングプロジェクトに値することのなかった内部ツールのロングテールを民主化し、ロードマップキューが決して提供できなかった速度でそれらを出荷します。境界のないフレームワークはスローガンです。これは、自分が何のためでないかを知っています。
実際に変わること
投資会社では、プラットフォームを通る最初のアプリは、それを動機付けたもの、つまり冒頭のストーリーのダッシュボードを、レール上で再構築したものです。同じ画面。同じビルダー。今や、真のストレージ、企業サインイン、すべての編集の履歴があります。それは二度と 7 バイトに切り詰められることはありません。なぜなら、それを引き起こしたクラスのコードがマージできないからです。
約 10 件中 9 件のリクエストがすでに自動的に解決され、その割合は増える一方です。非技術系ビルダーが作るもののほとんどは、本質的に爆発半径が低いものです。内部向け、読み取り中心、小規模なオーディエンスのツール。各形状の道が実績を証明するにつれて、それらのビルドのより多くが、人間をループに全く入れずにプロビジョニングおよびデプロイしても安全になります。人間の注意は、結果的な末尾に集中し続け、他の場所では薄くなっていきます。
今日、「はい」は数分で完了し、瞬時に向かっています。なぜなら、「いいえ」が組み込まれているからです。
すべての企業は、間もなく何百ものビルダーを抱えることになります。ほとんどの企業は、それを怖がるべきか、それとも興奮すべきかをまだ決めかねています。勝つ企業は、最も多くのビルダーを抱える企業ではありません。最も優れた道を持つ企業です。
