12-factor-fasd

12 Factor FASD(Fully Autonomous Software Development)

日本語 | English | GitHub

はじめに

文脈

FASD(Fully Autonomous Software Development) とは、要件定義より後の設計・開発・テストを AI に自走させるソフトウェア開発手法を指します。AI または人によってつくった要件定義を与え、最終成果物の生成まで自律的に動かします。人間による介入、たとえば承認は一切ありません。FASD の結果を受けて、フィードバックを反映してもう一度走らせることは可能ですが、FASD の最中に人間が割り込むことはありません。その名のとおり、AI が完全に自律的に動きます。

FASD の目的は、ソフトウェアの開発コストを減らすことです。AI を用いた開発パラダイムは Lv1:人手、Lv2:人間 with AI、Lv3:AI with 人間、Lv4:AI となっており、FASD は Lv4 にリーチするものです。Lv3 以前よりも、はるかにコストを抑えることができます。

用語を定義します。FASD を実現する何らかの製品を プロダクト と呼ぶことにします。また FASD によってつくられた最終成果物を ファスドウェア（Fasdware） と呼ぶことにします。

本ドキュメントと対象読者について

本ドキュメントは、現時点で先進の域に留まっている FASD を成功に導くためのエッセンスを 12 の TIPS として整理します。12 Factor Agents に触発されていますが、これの内容は含みません。しかし本質的には似通っています。12 Factor FASD は、FASD のための、より具体的な本質に踏み込みます。もし 12 Factor Agents が未履修なら、先に理解しておいた方が良いでしょう。

本ドキュメントの対象読者は、FASD を探索している個人または企業です。探索のヒントに役立てる――具体的には実際に取り入れてみたり、議論のネタにしたりといったことを想定しています。

注意点として、すでに述べたとおり、FASD はまだ先進的なものであり、確立されたプラクティスはありません。本ドキュメントは、そんな難題に挑む皆さんにインスピレーションを与えるために書きました。

12 Factor FASD

1: 要件定義に必要な事前情報はプレーンテキストで太らせろ

なぜなら、書かれていないことはやりようがないから。

Actions:

• プレーンテキストにせよ。また可能なら図や表ではなくデータ記述フォーマット、疑似コード、DSLにせよ
• リッチテキストがある場合は、先にプレーンテキストに変換せよ
• 図や表がある場合は、先にプレーンテキストかつ同等の表現に変換せよ。あるいはそれらを使わずに済むシナリオやストーリーをつくれ

Background:

• 人間向けの表現がまだまだ染み付いている。PDF も、Excel やパワポも、図も、表もすべて人間向けだ
• 人間向けの表現に整えるコストを警戒しがちだが、整える必要がないなら警戒も無用だ

Considerations:

• 生のインタビューや議事録であっても、ないよりははるかにマシである

2: 要件を検証可能にせよ

なぜなら、要件を検証できないと品質や完了の判定ができないから。

Actions:

• 要件定義は Machine Readable または同等のフォーマットと文法でつくれ
• フォーマットと文法は LLM が学習済のものを使え
  • たとえば Gherkin や EARS が挙げられるが、ソフトウェア開発でない分野から拝借しても良い。使う文法をAIに任せても良いだろう
  • 独自のフォーマットや文法は非推奨である。なぜならチューニングされていない上にコンテキストも食うためだ。おそらく独自のそれらに高精度に従わせること自体が難しい
• 要件の検証は要件定義のテストによって行わせろ。つまりは BDD 的に行え

Background:

• None

Considerations:

• もし、BDD 的に検証できない場合、要件の言語化に問題があると考えよ。ソフトウェア開発では設計と開発の二層にフォーカスするが、FASD ではさらに設計の前に要件定義も加わる。「検証可能な形に翻訳された要件定義」自体も修正対象であり、成果物なのだ

• …

3: 品質はプラガブル（交換可能）にせよ

なぜなら、品質とは合意事項であり単一の絶対解は存在しないから。

Actions:

• 品質体系（Quality Set）はハードコードするのではなく、プラガブルにせよ
• 複数の体系に対して、納得のいく評価が出ることを目指せ

Background:

• 品質に絶対解は無い
  • 内部向けで各個人が使う CLI であれば品質の定義はシンプルで済む。一方、大企業において社内全域に正式に展開するシステムの場合は、社内で規程された品質項目が多数あるだろう。どちらの品質体系も絶対解ではなく、その文脈において適切な「解の一種」でしかない
  • したがって、重要なのは品質体系そのものをプラガブルにすることである。そして、生成したファスドウェアを、搭載した品質体系に基づいて評価し、納得できるかどうかである

Considerations:

• FASD では、ファスドウェアに品質体系が同梱される形となる。ソフトウェアにはドキュメントも同梱されるが、ファスドウェアには品質体系も同梱されるのだ

4: コンポーネントもプラガブルにせよ

なぜなら、ソフトウェア全体または大部分を一度につくりきるのは非現実的だから。

Actions:

• コンポーネントはプラガブルにせよ
  • フロントエンドとバックエンドから成る Web サービスをつくるとして、密結合的につくるのではなく、プラガブルなコンポーネントとしてつくるべきだ。UI として CLI、簡易的なデスクトップアプリ、フロントエンドをつくって交換できるようにしたり、バックエンドは API の形でつくってフロントエンド側コンポーネントとの組み合わせに応じれるようにする
• コンポーネントはできるだけ独立かつ部品的にせよ
  • 小さなファスドウェアをつくれるようにせよ。たとえば画面の一部とAPIの一部のみを搭載した「小さなファスドウェア」をつくれるようにする

Background:

• 現在の AI では、大きなソフトウェアを品質を維持したまま一度につくるのは難しい

Considerations:

• n 行以上のコードを問題無き品質で生成するのは難しい、と単純化しても良い
  • これは「生成単位は n 行以内」という制約を抱えているに等しく、これを言い換えたのがプラガブルなコンポーネントである
  • n としては 3 桁、つまり 1000 行未満を想定している

5: ワークフローは厳密に設計と修正を行えるようにせよ

なぜなら、エージェントに秩序を与えるのはワークフローだから。

Actions:

• すべてのステップ（inputを受け取って、processを実行して、outputを出す単位）を掌握せよ
• すべてのステップ間の関係を掌握せよ
• すべてのデータとその流れを掌握せよ
  • 少なくとも常用コンテキスト（常に含める）、共用コンテキスト（必要に応じて含める）、インプット、アーティファクト（中間成果物）、デリバラブル（最終成果物） があるはずだ

Background:

• None

Considerations:

• None

6: エージェントは Composite にせよ

なぜなら、再現性と柔軟性のバランスを取れる塩梅だから。

Actions:

• エージェントは単一のインタフェースを実装する形にせよ
  • これによりワークフローの目線では、単一のビルディング・ブロック（エージェント・インタフェース）の組み合わせを考えるだけで済むようになるし、ワークフロー全体の動作と限界も読みやすくなる
  • たとえばインタフェースとしてリトライとタイムアウトを定義したとすると、リトライとタイムアウトの二つの概念が共通言語として機能するようになる。ワークフローの改善を、リトライやタイムアウトといった言葉で統一的に扱えるようになる
• エージェントからエージェントを呼び出せるようにせよ
  • つまりオーケストレーターとエージェントが分かれるといった役割分担をするのではなく、エージェントの種類は一種類（エージェント・インタフェース）のみであり、これがオーケストレーションの機能も持つ
• エージェント・インタフェースのバランスを調整せよ
  • エージェント・インタフェース自体が多機能的になると容易に破綻する。設計と同様、いかにシンプルなインタフェースで済ませられるかを探り当てねばならない

Background:

• ファスドウェアの品質を安定させるには、LLM Friendly でなくてはならない
  • ワークフローの表現力も例外ではない

Considerations:

• 究極的にはワークフローはグラフ構造であり、ノードとエッジから成るものであるが、このノードとエッジの種類が多いと、それだけ LLM に混乱の余地を与えてしまう。混乱を抑えるアプローチは多数あるが、12 Factor FASD ではノードの種類を単一にする。またワークフローを表現しきれるだけの表現力も搭載する。その塩梅が Composite である

7: デリバラブルは LX(LLM Transformation) 的に解釈せよ

なぜなら、LLM の、道具としての価値は「人間が想定したとおりの UI/UX を実現すること」ではなく「問題無く使えること」であり、前者は後者の必要条件ではないから。むしろ前者を満たしてなくても後者を満たせる塩梅があるはずだから。

Actions:

• None

Background:

• LX とは LLM Transformation を指す
  • DX(Digital Transformation) がそうであるように、XXX Transoformation とは XXX の制約や世界観に人間が適応することを指す
  • 特に私達はビジュアル面にうるさく、プレーンテキストの箇条書きでいいものをビジュアルなスライドをつくってプレゼンしたりする程度にはアナログである。さらに日本はオーダーメイド文化があり、Fit to Standard ではなく顧客の言う通りにつくろうとする文化が強い

Considerations:

• 人間向けのあり方から抜け出さない限り、FASD は実現不可能だ
  • そもそも技術とは、技術が想定するあり方に人間が合わせる営みなのである。FASD も例外ではない。

8: ビジュアルを排除せよ

なぜなら、ビジュアルは LLM Friendly ではないから。

Actions:

• 図を排除せよ
  • Marmaid や UML など記法的なものも含む
• 表を排除せよ
  • Markdown table も含む
• YAML や json など汎用的なデータフォーマットを採用せよ
• 擬似コードで書け
• 適用可能な領域には DSL を適用せよ

Background:

• Factor 1 参照、ビジュアル至上は人間向けであって LLM 向けではない
• Factor 7 参照、LLM の事情に人間が合わせる（Transformation）ことが重要である

Considerations:

• 図表が欲しいなら、FASD におけるインプットではなく、人間向けのアウトプットとして生成させよ
  • つまり図表はビューの扱いにせよ

9: コンテキストウィンドウを超過する前にアボートせよ

なぜなら、物忘れ（コンテキストウィンドウの超過）は低品質を招くから。

Actions:

• コンテキストウィンドウの超過をチェックするアサーションを差し込め
  • つまり超過した時点でアボートするようにせよ

Background:

• コンテキストウィンドウの超過を前提とした FASD はカオスになる
  • ただでさえ再現性と追跡性を担保しづらい FASD において、もはや説明責任は絶望的になる

Considerations:

• せめてコンテキストウィンドウの範囲内に入っていることは保障しなければならない

10: 待ち時間はコーヒータイム未満にせよ

なぜなら、フィードバックループの効率が最重要だから。

Actions:

• タイムアウト値を憲法として定めよ
• リッチな処理を行いがちなエンプラ向けのサードパーティ製品（特に SCA その他品質評価系）には頼らず、かわりに軽量でカスタマイズ可能なオープンソースで代替せよ

Background:

• FASD は野心的な試みであり、実験の量と多様性がものをいう
  • 一方、何も考えず実装すると、デリバラブル生成まで数時間、場合によってはそれ以上を要してしまう。これでは実験どころではない
• 高速な試行錯誤を回すために、小さな実験単位を指向するべきである
  • 従来開発のリリースサイクルは年、月、週、日と短くなってきた
  • SDD の潮流でも、一機能ずつつくっていくのが無難であるとの合意が形成されつつある

Considerations:

• とはいえ、数分以内に完了できるほど技術的に成熟してはいない
  • 12 Factor FASD では「コーヒータイム」という抽象的な基準を設けた。

11: オンボーディングの自走を可能にせよ

なぜなら、チームワークにかかるコストを減らして、その分を多様な実験に回すべきだから。

Actions:

• チームワークではなくソロワークを取り入れよ
  • 1つのプロダクトをn人でつくるのではなく、1 人 1 プロダクトを抱えて切磋琢磨せよ
  • 前者を想定するアジャイル開発、特にスクラム開発は役に立たない
• 既存メンバーには定期的にゼロからcloneさせよ
  • たとえば毎週誰か一人にアサインしてやらせよ。この手間を許容できる程度にはセットアップの冪等性と簡潔性を洗練させよ
• 新人でも独学かつ会議無しで機能追加作業ができる程度には、オンボーディングコンテンツを整えよ
• オンボーディングコンテンツは必ず人手で、妥協せずつくりこみ、メンテナンスも継続せよ
  • この Factor 11 を満たせるなら AI に任せても良いが、おそらく AI 単体ではその品質にならないため、人手は必須と考えるべきだ
• 自走できない人材は FASD においては役に立たないが、サポートメンバーとしては役に立つ可能性がある:
  • 例: マネージャー、スクラムマスター、グルーワーカー、カタリスト

Background:

• Factor 10 参照、FASD は実験がものをいう世界である
• AI エージェントのおかげで、新人であっても短期間で 1 人開発を回せるようになれる
  • かつ、FASD は探索段階のプロジェクトである
  • それゆえソロワークが現実的な選択肢に入る
• チームワークのデメリットは、単一または少数のコアメンバーやマネージャーがボトルネックになることである
  • ボトルネックとは制約であり、統制をもって発展させる段階では必須であるが、FASD はその限りではない

Considerations:

• None

12: 非機能要件はクラフトマンシップに則ってベストエフォートせよ

なぜなら、非機能要件とは人間と人間の契約であり、環境の制約と思惑も絡むため、FASD として行うのは筋違いだから。

Actions:

• 性能テストや負荷テストを行うな。行っているならば廃止せよ
• クラフトマンシップに基づいたベストエフォートで済ませよ
  • エンジニアやプログラマとしてのプロ意識をもって、できる限り優れたファスドウェアを生み出す努力をせよ。設計のクリーンさ、パフォーマンス、コスト最適化など様々な軸があるが、FASD の開発者であるあなた自身のプロ意識をもって、できる限り良いものになるように努めればそれでよい
• 政治的に非機能要件を切り離せないのであれば、デリバラブルに対する追加検証を（FASD の外で）行い、その結果を FASD にフィードバックすることで連携せよ

Background:

• ファスドウェアは道具であるが、非機能要件は道具の運用品質に関する要件である
  • つまりファスドウェアが担保するものではなく、ファスドウェアの利用者が決めるものである
• しかし道具自体の品質は非機能要件にも直結するため、品質を軽視していい理由にはならない

Considerations:

• None

This site is open source. Improve this page.