仕事が行われる場所から始めます。

御社のスタッフのそばで時間を過ごすことから始めます。日常の作業、例外、引き継ぎ、そして業務を回し続けている工夫を観察します。

人がどの情報を信頼しているか、どこで判断を迫られるか、何かがうまくいかないとき何が起きるかを理解したいのです。

それが、何を変えるかを決める現実的な土台になります。

学んだことを、具体的な改善の優先順位付きリストにします。各項目には、誰を助けるか、どんな結果を生むべきか、どんな条件に依存するかを明記します。

開発の前に、役立つ結果とは何かに合意します。限界も明らかにします。システムが警告すべきケース、人に委ねるべき判断、単独で扱ってはいけない情報です。

私たちは圧縮した開発サイクルをハイパースプリントと呼んでいます。人のリードが、プロダクト計画、業務分析、開発、品質保証、ドキュメントの役割を持つエージェントを指揮します。

リードは何を作るかを決め、トレードオフを解決し、結果が合意した課題を解決しているかを判断します。

短いサイクルは、仕事を点検し、方向を変える機会を増やします。各リリースの範囲と準備状況が、それがスタッフに届く時期を決めます。

すべてのビルドは、それを書いたモデルとは別のモデルがレビューします。そのうえで、スタッフに届く前に人が結果をレビューします。

モデルによるレビューは確認の一層にすぎません。人の判断や、システムが担うべき仕事に対するテストの代わりにはなりません。

システムが動くか、どこで失敗するか、使う人がその限界を認識できるかを確認します。

実際に仕事をしている人がシステムを試し、次の変更を形づくります。そのフィードバックは構築チームに戻ります。

Tanが御社のスタッフとの作業を主導し、ベトナム語と英語でのセッションや文書を含みます。その他の関係者の言語ニーズは開始時に合意します。

システムが使われ始めたら、合意した範囲で運用と保守を続けます。

データ、基盤技術、御社のプロセスの変化を確認します。さらなる改善は、システムが実際にどう使われているかに基づき、御社と一緒に優先順位を決めます。