AI はあなたの働き方を学ぶべき

Snappy PM を最初に設計したとき、とても自然なアイデアがありました：

AI があるのだから、AI に企業の過去のプロジェクトを読ませて、その企業専用の Workflow を自動生成させたらどうだろう？

理にかなっています。

そしてとても AI-native です。

でも作り続けるうちに、私たちは考えを変えました。

AI は単純なことを、とても賢く見せてしまいがちだからです。

企業の過去のプロジェクトを見て、多くの Stage、Rule、Role、Exception をまとめ上げることができます。

でも問題は：

過去に起きたことが、未来もそうあるべきとは限らない。

企業自身の歴史的なプロセスには、もともと偶然の、非効率な、あるいは間違ったやり方がたくさん含まれているかもしれません。

AI がこの歴史をとても真面目に学んだら、最終的な結果は単に：

Automating yesterday.（昨日を自動化する）

かもしれません。

だから新しい Snappy PM は、非常に重要な単純化を行いました。

AI に企業ごとの State Machine を発明させるのはやめました。

プロジェクトの基本骨格は 5 つの Phase です：

Requirement Capturing

Scoping & Design

Implementation or Manufacturing

Deployment or Installation

Closing

この部分は安定させます。

AI が本当に学ぶべきなのは、企業間の意味のある違いです。

たとえば：

どの Phase があなたに適用されるか？

普段どんな Quotation を使うか？

あなたの Payment Terms は？

どの Document が自社の標準テンプレートか？

Inventory はあるか？

顧客が相手にするのはこの会社か、それともグループ内の別の Sales Company か？

これらこそが：

How you work.

だから Snappy は過去のプロジェクトを読み、企業の働く習慣とドキュメントを理解し、提案を出すことができます。

でも私たちはもうひとつの原則を与えました：

Evidence or default.

AI が企業に何らかの働き方があると考えるなら、こう教えられるべきです：

どの実際のドキュメントからそれを見たのか。

証拠がなければ、シンプルで安定したプラットフォームのデフォルトを使う——AI に推測させるのではなく。

これは AI プロダクト設計における非常に重要な境界だと、私はますます感じています。

AI の最も価値あるところは、必ずしも：

すべてを AI に決めさせること

ではありません。

それは：

何を安定させるべきか、何を学習すべきかを知ること。

Accounting rules は安定させるべきです。

中核の Project Flow は安定させるべきです。

権限の境界は安定させるべきです。

一方、企業のドキュメント、習慣、テンプレート、具体的な働き方は学習できます。

だから今、私たちは Snappy PM をこう説明する方を好みます：

AI learns how you work.

It doesn't invent how you should work.

AI は企業がソフトウェアに適応するコストを減らすべきです。

新しい複雑さを作り出して、企業に AI へ適応を要求するのではなく。

SnapLedger, your life easier.