A00.md
0. この文書の役割
この文書は、PortXという会社が何者で、何を信じ、どこで勝ち、何を実現したいのかを最も短く鋭く定義する文書である。 A00は、会社の思想、存在意義、勝ち筋、世界の見方を固定するための中核文書であり、事業、採用、営業、プロダクト、デリバリー、組織運営のすべては、この文書と整合していなければならない。
A00はスローガンではない。 A00は、PortXの意思決定OSにおける最上位の原則である。 この文書に書くのは「何が正しいか」「何を勝ち筋とみなすか」「何をやらないか」であり、個別案件や一時的な施策は書かない。
A00は、会社の規模が大きくなっても全員がズレずに動ける状態を作るための共通言語である。 A00がないまま各自が善意で頑張ると、会社は必ず分散し、目先の案件、採用しやすさ、作りやすさ、売りやすさに引っ張られてズレる。 PortXは、それを避けるためにA00を持つ。
1. A00とは何か
A00とは、PortXが何の会社で、どこで勝ち、何を実現したいのかを最も短く鋭く表す共通言語である。
A00が担う役割は次の通りである。
- 会社の存在意義を固定する
- 何を勝ち筋とみなすかを固定する
- 何をやらないかを明示する
- 全員の判断基準を揃える
- CEOの頭の中にある判断基準を会社の共通資産にする
- 日々の運用や案件判断を、会社全体の方向に接続する
A00は「理念」だけでも「戦略」だけでもない。 A00は、理念と戦略と判断基準を一つに束ねた、会社の中核規範である。
2. PortXの原体験
PortXの原体験は、単なる起業アイデアではない。 エンタープライズITの構造への怒りが出発点である。
原体験は、次のように整理できる。
ユーザーは、誰が本当に価値を出しているかを分かっていた。 しかし、発注権はユーザーになく、デジタル統括部門と看板だけの大手が意思決定を支配していた。 プロジェクト成功より保身と売上が優先され、本当に必要な側が切られ、品質は落ち、最後に困るのはユーザーだった。
本来、中核業務のシステム化は、痛みと必要性を最も理解しているユーザーが主導すべきである。 にもかかわらず、従来はその手段がなく、ユーザーは構造的にシステム部門に頼らざるを得なかった。
この構造を壊し、ユーザーに主導権を取り戻すためにPortXは生まれた。
PortXの出発点は「AIで何か面白いものを作ること」ではない。 「価値を作る側が負け、発注権と看板を持つ側が勝つ」というエンタープライズITの構造を壊すことである。
3. 世界の見方
PortXは、世界を次のように見ている。
3.1 エンタープライズITには構造的なねじれがある
大企業の中核業務において、本当に困っているのはユーザー部門である。 しかし、多くの企業では、予算や発注権はシステム部門、デジタル部門、調達部門が握っている。 このねじれにより、価値を必要としている人と、意思決定する人が分離している。
3.2 間接化が価値を劣化させる
ユーザーの本当の痛み、必要な変化、判断の現実、業務の例外は、システム部門やSIを経由する過程で二次情報化される。 その結果、要件は薄まり、優先順位はズレ、現場が本当に欲しいものから遠ざかる。
3.3 従来のエンタープライズSIは本格対応できるが、重く、遅く、間接的である
従来の大規模SIは、本番運用に耐える設計書、レビュー、テスト、運用保守への接続を重視する。 それ自体は必要である。 問題は、それを成立させるためのコスト構造、間接部門、多重下請け、管理工数が大きすぎることである。
3.4 市民開発やSaaSは便利だが、中核業務には届かない
kintone、Excelマクロ、VBAなどの市民開発は、小さい改善には向いている。 SaaSやERPパッケージは、一定の標準業務には強い。 しかし、中核業務は企業固有性が高く、部門横断で、例外が多く、意思決定そのものが競争優位であるため、これらだけでは十分に解けない。
3.5 だからこそ、空白市場がある
従来は、 小さく速くやるなら市民開発 本格的にやるならシステム部門とSI という分断があり、ユーザー部門が自ら中核業務のシステム化を主導する選択肢はほぼ存在しなかった。 PortXが狙うのは、この空白である。
4. Why Now
PortXが今この市場に挑戦できる理由は、LLMによってこれまで高コストだった知的作業が大幅に低コスト化したからである。
従来、ユーザー部門がシステム部門に頼らざるを得なかったのは、単に権限の問題ではなかった。 要求を言語化する、曖昧な会話を構造化する、設計書に落とす、レビュー可能な形にする、差分や変更影響を追う、運用保守に必要な情報を残す、といった知的作業のコストが高すぎたからである。
LLMは、この知的作業を大幅に代替・補完できるようにした。 しかし、LLM単体ではエンタープライズSIにはならない。 この能力を、要求整理、設計、実装、変更管理、運用接続まで一貫した実務に変換する基盤が必要だった。
その基盤がFormulaである。
Why Now を一文で言うならこうなる。
LLMがシステムプロジェクトを成立させる知的作業を大幅に低コスト化し、Formulaがそれを実務として束ねたことで、初めてユーザー主導のエンタープライズSIが可能になった。
5. 会社のA00
PortXの会社A00は、次の一文で固定する。
大企業のユーザー部門に、中核業務変革の主導権を取り戻し、競争優位そのものを実装すること。
このA00に含まれる意味は以下の通りである。
5.1 「大企業のユーザー部門に」
PortXの主語は、システム部門でも、調達でも、ベンダーでもない。 本当に業務を使い、本当に痛みを持ち、本当に変革の価値を受け取るユーザー部門である。
5.2 「中核業務変革の主導権を取り戻し」
PortXが変えたいのは、単なるシステムの中身ではなく、誰が変革を主導するかという構造である。 ユーザー部門が、自らの中核業務について「何を変えるか」「なぜ変えるか」「どう進めるか」を主導できるようにする。
5.3 「競争優位そのものを実装する」
PortXが作るのは便利機能ではない。 顧客の売上、利益、サービス品質、在庫、納期、柔軟性、判断品質といった、競争優位に直結する業務能力そのものを、ソフトウェアとして実装する。
6. PortXは何の会社か
PortXは、コンサル会社でも、従来型SI会社でも、汎用SaaS会社でもない。
PortXは、 ユーザーと直接向き合い、 顧客の中核業務の課題を構造化し、 A00を定義し、 動くToBeを提示し、 要求整理から実装、運用接続まで一気通貫で担い、 案件知見を複利で蓄積していく AIネイティブなエンタープライズSI基盤会社である。
簡単に見えるようでいて、ここにPortXの全部が入っている。 PortXは、単なる「開発を請ける会社」ではなく、「ユーザー主導の中核業務変革を成立させる会社」である。
7. どの市場で戦うか
PortXが真正面から挑む市場は、エンタープライズSI市場である。
ただし、会社全体のビジョンは広くても、市場への入り方は narrow wedge にする。 つまり、いきなり「全ての中核業務を変えます」とは言わない。 現場責任者が「これはうちの問題だ」と自分事化できる、狭く深い業務痛から入る。
たとえば、 - 在庫数は見えているのに、使える在庫か、滞留在庫か、欠品予備軍かが分からない - 受注、配車、生産確認が電話と再入力で止まる - 納期回答や生産可否判断がベテラン依存になっている - 需給調整が属人的で、変動に弱い といったテーマである。
表側の市場への入り方は narrow wedge にする。 裏側では Formula とデリバリー基盤を共通化する。 これが PortX の勝ち筋である。
8. どこで勝つか
PortXの勝ち筋は次の5つに要約できる。
8.1 ユーザー直結
ユーザーと直接向き合い、顧客がまだ整理できていない課題やA00を一緒に定義する。
8.2 A00起点
案件を機能要求から始めるのではなく、顧客の最終的な業務状態、意思決定、成果の変化から逆算する。
8.3 Formulaによる早期具体化
動くToBeを営業段階から提示し、要求整理と価値提示を同時に進める。
8.4 一気通貫デリバリー
要求整理、設計、実装、変更管理、運用接続までを分断しない。
8.5 複利化
案件のたびに、要求整理の型、AsIs整理の型、ToBe設計の型、見積、WBS、変更管理、レビュー、業務パターンを会社資産に戻し、次案件を速く・深く・高利益率にする。
PortXは、一件ごとに消費される会社ではなく、案件のたびに会社そのものが強くなる会社でなければならない。
9. Formulaの位置づけ
Formulaは、PortXのプロダクトであると同時に、PortXの勝ち方そのものを内包した基盤である。
Formulaは、 LLMが可能にした知的作業の低コスト化を、 ユーザー主導のエンタープライズSIとして成立させるための基盤 である。
より具体的には、 ユーザーの曖昧な要求 業務シナリオ 設計書 モック データ API 変更管理 レビュー 運用接続 を一貫して扱うデリバリーOSである。
Formulaは、PortXが「なぜそんなに速く、深く、安く、品質高くできるのか」を支える根本であり、PortXの競争優位そのものの一部である。
10. FormulaのA00
FormulaのA00は、次の一文で固定する。
ユーザー部門が、これまでシステム部門を介さないと進められなかった中核業務のシステム化を、自ら主導して実現できる状態をつくること。
このA00に「速さ」を中心語として入れない理由は、早さは価値の一部ではあるが、本質ではないからである。 Formulaの本質は、主導権の移動であり、プロジェクト成立能力の移動である。
11. Formulaとは何か
Formulaとは何かを、一文で言うならこうである。
Formulaは、SaaSでは解けない中核業務の課題を、フルスクラッチ並みの自由度で、SaaSのような体験で実現するための、AIネイティブなエンタープライズSI基盤である。
ただし、これだけでは少し雑なので、より本質的には次のように定義する。
Formulaは、ユーザー部門の曖昧な問題意識や要求を、要求整理、設計、実装、変更管理、運用保守まで一貫して成立するエンタープライズSIの成果物に変換するための基盤である。
Formulaは、単なるノーコードツールではない。 単なるモック生成ツールでもない。 単なるVibe Codingの延長でもない。
Formulaは、業務理解、要求整理、AsIs整理、ToBe設計、見積、WBS化、実装、変更管理、レビュー、テスト、運用接続までを一貫して扱うデリバリーOSである。
12. spec.mdの意味
Formulaを理解するうえで重要なのが spec.md である。
spec.md は、Formulaにおける設計書の元データ、もしくは唯一の正本である。 すごく簡単に言えば、 - この画面では何を表示するか - どんな入力があるか - 押したら何が起きるか - どんなデータを使うか を、一つの構造化されたテキストファイルで持つ考え方である。
Formulaでは、この spec.md を唯一の源泉として扱い、HTML、データ、APIなどをそこから自動派生させる。 その結果、 - 設計書と実装がズレる - どれが最新かわからない - 引き継ぎが伝言ゲームになる という問題を減らすことができる。
spec.md を中心にしている意味は、単に開発しやすいからではない。 人もAIも読める中間表現を持つことで、設計、実装、レビュー、改修、運用、引き継ぎ、問い合わせ対応まで全部強くできるからである。
13. Formulaの強み
Formulaの強みは、次の8点に整理できる。
13.1 ユーザーの曖昧な要求を起点にできる
会話、メモ、ヒアリング、ラフな業務説明から入り、そこから構造化していける。 これはユーザー主導に不可欠である。
13.2 動くものを見ながら要求整理できる
営業段階や初期設計段階から「動くToBe」を見せられるため、ユーザーは抽象的な仕様書だけでなく、動くシナリオを見ながらフィードバックできる。
13.3 エンタープライズSIとして必要な成果物を出せる
ウォーターフォール市場で必要な設計書、レビュー可能性、運用保守への接続を満たしながら進められる。
13.4 spec.mdをSSOTとして設計と実装を一致させられる
設計書と実装が乖離しにくく、保守や変更にも強い。
13.5 変更追従と影響把握に強い
変更が入ったときに、どこまで影響するかを構造的に追いやすい。
13.6 運用・保守に強い
仕様、設計、コード、履歴が揃うことで、障害調査、改修影響調査、引き継ぎ、ベンダースイッチまで強い。
13.7 運用AI Agentの基盤になりうる
問い合わせ対応、仕様確認、運用マニュアル生成、保守支援などのAI Agentに発展しやすい。
13.8 SIの構造そのものの中で勝てる
SIとして必要な要件を満たしたまま、SIのコスト構造と進め方そのものを変えられる。
一文で言えば、Formulaの強さは、SIの要件を満たしたまま、SIの勝ち方そのものを作り変えられることにある。
14. なぜ速さはA00の中心に入れていないのか
Formulaは速い。しかし、A00の中心に「速さ」は置いていない。
理由は単純である。 早さは価値の一部だが、本質ではないからだ。
早さは結果であって、Formulaが実現したい構造変化そのものではない。 A00に速さを置くと、「早いだけのツール」「安いだけの開発基盤」と誤解されやすい。
Formulaが本当にやっているのは、ユーザー部門が中核業務のシステム化を主導できるようにすることであり、速さはそのための手段であり結果である。
15. なぜFormulaはVibe Codingと違うのか
投資家や外部の人は、Formulaを「Vibe Codingと何が違うのか」と誤解しやすい。 違いは明確である。
Vibe Codingは、主にコード生成の話である。 Formulaは、エンタープライズSIを成立させる話である。
Vibe Codingでは、 - 要求整理 - 設計書 - 変更履歴 - 成果物の一貫性 - レビュー可能性 - 運用保守への接続 までを一貫して面倒を見ることは難しい。
Formulaは、ユーザーの曖昧な要求を、設計、モック、データ、API、レビュー、運用資産まで一気通貫で成立させる。 Formulaの本質は「AIがコードを書くこと」ではなく、「AIがエンタープライズSIに必要な知的作業と成果物を一貫して成立させること」にある。
16. 何をやらないか
PortXは次のことをやらない。
- 単なるAI受託会社にならない
- 単なる高速プロトタイピング会社にならない
- 単なる安売りSIにならない
- 看板や間接者に最適化した仕事をしない
- ユーザーの中核業務に効かないテーマを本業にしない
- 会社の規模のために、勝ち筋から外れた仕事を取り続けない
- 速さや安さだけを売り物にしない
- 思想なき拡大をしない
17. 組織原則
PortXは、会社が大きくなっても、全員がA00からズレずに動ける状態を作る。
そのために、次を原則とする。
- 全員がA00を共通言語として持つ
- CEOの頭の中だけにある判断基準を会社資産にする
- 案件、採用、営業、Formula開発のすべてをA00に接続する
- 一件ごとの判断や知見を消費せず、会社に蓄積する
- 会社運営も、Formulaと同じく複利で強くなる構造にする
18. この文書の更新原則
A00.md は、会社の存在意義、勝ち筋、世界の見方を固定する文書である。 したがって、日々の運用上の迷いで頻繁に変えてはならない。
A00.md を変えてよいのは、次のような場合だけである。
- 会社が何者かの定義を変える必要が出たとき
- 主戦場が本質的に変わったとき
- 競争優位の源泉が変わったとき
- 世界の見方そのものが変わったとき
- Formulaの役割定義が本質的に変わったとき
それ以外の判断や運用は、P00.md に蓄積する。 A00 は「何が正しいか」を固定し、P00 は「日々どう正しく動くか」を扱う。
19. 最後に一文でまとめると
会社のA00
大企業のユーザー部門に、中核業務変革の主導権を取り戻し、競争優位そのものを実装すること。
FormulaのA00
ユーザー部門が、これまでシステム部門を介さないと進められなかった中核業務のシステム化を、自ら主導して実現できる状態をつくること。
Formulaの本質
Formulaは、LLMが可能にした知的作業の低コスト化を、ユーザー主導のエンタープライズSIとして成立させるための基盤である。
Formulaの原体験
価値を作る側ではなく、発注権と看板を持つ側が勝つ。そのエンタープライズITの構造への怒りが、Formulaの原体験である。