プロトタイプ → 本番
AIやノーコードで、価値を検証できるプロダクトができました。そのプロダクトを本番運用へ移すには、別の課題があります。 本番までの道筋を示し、リスクを明らかにして、そのまま実行できる計画をお渡しします。
プロトタイプ開発ツールは、以前なら時間のかかった「人に見せられるものを作る」工程を大幅に速めました。私たちは、この進歩を率直に歓迎しています。 一方で、他の人がそのシステムに頼り始めてから重要になる問いには、ツールだけでは答えられません。
一方で、他の人が頼り始めてから重要になる問いには、ツールだけでは答えられません。誰が安全に変更できますか？ 障害が起きたらどうなりますか？ アクセスが増えたとき、費用はどこにかかりますか？これらの問いは以前からありました。プロトタイプの段階では、答える必要がなかっただけです。
ご相談いただくプロトタイプのほとんどに、4つのことが当てはまります。どれもデモには現れません。デモでは、一人が良好な通信環境で、そのプロダクトが想定する操作だけを行うためです。
同時実行、レート制限、競合状態は、一人で操作するデモには現れません。利用者が増えたその日に表面化します。同時実行、レート制限、競合状態は、一人で操作するデモには現れません。利用者が増えたその日に表面化します。
1,000行なら40ミリ秒で返るクエリも、100万行ではまったく別物です。そして、最も困るタイミングで動かなくなります。1,000行なら40ミリ秒で返るクエリも、100万行ではまったく別物です。
問題を明確に知らせるテストも監視もないため、最初の障害はアラートではなく、顧客からのメールで届きます。問題を明確に知らせるテストも監視もないため、最初の障害は顧客からのメールで届きます。
プロトタイプのコストが生じるのは、作ったときではありません。2回目の変更を加える人が、そのコストを負担します。プロトタイプのコストが生じるのは、作ったときではありません。2回目の変更を加える人が、そのコストを負担します。
だからといって、すべてを作り直す必要はありません。どれが該当するか、放置するとどれだけの費用がかかるか、どの順番で対応すべきかを把握することが大切です。だからといって、すべてを作り直す必要はありません。どれが該当し、どの順番で対応すべきかを把握することが大切です。
期間は1〜2週間です。背景とアクセスを共有いただき、独立した評価を経て、意思決定ワークショップで終了します。優先順位をつけたリスク、そのまま残せるもの、変更すべきもの、推奨アーキテクチャ、実行順に整理したロードマップをお渡しします。期間は1〜2週間です。背景とアクセスの共有、独立した評価、意思決定ワークショップを経て、優先順位をつけたリスクと、実行順に整理したロードマップをお渡しします。
01 背景とアクセス
何を誰のために作っているか、顧客に何を約束しているか、コードとインフラの閲覧権限を共有いただき、プロダクトが現在の形になった理由を知る方に半日ご参加いただきます。の3点です。この段階より前にアクセスをお願いすることはありません。
02 独立した評価
定例会議も日次報告もありません。質問ではなく、所見をお返しします。どうしても判断できない点だけ、文章で一度確認して作業を続けます。
03 意思決定ワークショップ
所見を、実行する立場の方も含めて確認し、対応の順序を率直に議論します。十分に異議や疑問を出していただき、全員が納得した順序を文書に残します。
すべてのアセスメントで10項目すべてを評価します。どれがそのプロダクトを支える重要な要素か、何をそのまま残せるか、残りにどの順番で対応すべきかを報告書に記載します。すべてのアセスメントで10項目すべてを評価します。本当にリスクが高いのは、通常2〜3項目です。
この構造が、次の機能だけでなく、今後12か月の変更にも耐えられるかを確認します。
全体を読み込まなくても、次のエンジニアが安全に変更できるかを確認します。
認証、認可、秘密情報、すでに保持している顧客データを確認します。
スキーマ、整合性、マイグレーション、誤ったレコードを1件だけ修正する方法を確認します。
デプロイ、アクセスが10倍になった場合の費用、深夜2時に再デプロイできる人を確認します。
最初に壊れるもの、異常を検知する方法、復旧にかかる時間を確認します。
顧客から連絡を受ける前に、異常へ気づけるかを確認します。
上限がどこにあり、何をすれば上がるか、いま引き上げる価値があるかを確認します。
公開に不可欠なものと、必要に見えて実はそうでないものを見極めます。
実施順序、切り戻し、サポート体制、公開後2週間の動きを確認します。
多くのコードレビューは「自分ならこうしない」という指摘の一覧になります。しかし、数か月後に問題を起こすものと、放置しても支障のないものを区別していないため、経営判断にはほとんど役立ちません。
実際の利用者がいるプロトタイプは、最も重要な形ですでに検証されています。そのまま残すのが基本であり、置き換える場合にこそ、私たちが理由を説明します。実際の利用者がいるプロトタイプは検証済みです。そのまま残すのが基本です。
すべての所見に、何もしない場合と修正する場合の費用を記します。何もしない費用のほうが小さければ「対応不要」と書き、それも判断として残します。何もしない費用のほうが小さければ「対応不要」と記します。
私たち以外の方が読む前提で書きます。私たちの同席がなければ理解できない文書は未完成であり、他の開発会社へ提示することもできません。私たちが同席しないと意味が通らないなら、それは未完成です。
このサイトで道筋が本当に分かれるのは、ここだけです。成果物はお客様に帰属し、3つの選択肢はいずれも同じゴール、他の人が安心して頼れるシステムへ向かいます。道筋が本当に分かれるのはここだけです。3つとも、他の人が安心して頼れるシステムへ向かいます。
ロードマップは、私たちと話したことのない技術者が読む前提で書いてあります。実行は御社のチームが担当します。リスクの高い2〜3か所だけレビューするか、まったく関わらないか、どちらでも構いません。ロードマップは、私たちと話したことのない技術者が読む前提で書いてあります。
Production Engineering Partnershipとして、多くの場合、ロードマップの最初の実施単位に取り組む、期限を定めた実装スプリントから始めます。継続するのは、それが最も有益な場合だけです。期間を決めた実装スプリントから始めます。続けるのは有益な場合だけです。
成果物はお客様に帰属し、特定の開発会社に依存しないよう作成しています。そのまま仕様書として他社に提示し、回答を比較できます。それが意図した設計です。特定の開発会社に依存しないため、そのまま仕様書として他社に提示し、回答を比較できます。
アセスメント後の実装を私たちに依頼する義務も、優先交渉権もありません。別の方が実行できる形で文書にすること自体が、成果物の目的です。