ご提供するサービス

本番準備アセスメント

1〜2週間の有料アセスメントで、成果はお客様が所有する一つの文書にまとめます。システムを支える重要な箇所、そのまま残せるもの、残りに取り組む順序をお伝えします。実装するエンジニアが使え、発注する方にも理解できる文書です。

1〜2週間 ・ 成果物はお客様に帰属 ・ 特定の開発会社に依存しない

01 進め方

3つの段階、2週間、1つの文書。

全体で1〜2週間かかりますが、お客様に1〜2週間の作業をお願いするわけではありません。最初に半日、最後に90分だけご参加ください。その間の作業はすべて私たちが行います。

01 背景とアクセス

始める前に必要なもの

何を、誰のために作っているか、公開について顧客に何を約束しているか、そして、リポジトリとインフラ管理画面への閲覧権限の3点を共有いただきます。アセスメント中に書き込み権限は必要ありません。

1〜2日目 ・ お客様の所要時間は約半日

02 独立した評価

10の項目をすべて評価

定例会議も日次報告もありません。コードを読み、実際に動かし、データモデルとインフラの挙動を確認して、所見をまとめます。どうしても判断できない点だけ文章で一度確認し、その後も作業を続けます。質問ではなく、所見をお返しします。

2〜8日目 ・ お客様の作業はありません

03 意思決定ワークショップ

90分。率直に議論する場です

お客様と実行担当者の方々と一緒に所見を確認し、対応の順序について率直に議論します。十分に異議や疑問を出していただき、最終的な判断を文書へ反映します。

8〜10日目 ・ 90分、オンラインまたは対面

アセスメントでは、指摘の数ではなく優先順位を重視します。何を残すか、何を変えるか、何から着手するかという判断を変える所見だけを文書に記載します。

02 10の評価項目

すべてのアセスメントで、10項目すべてを評価します。

お客様ごとに項目を変えると、都合のよい結論に合わせて確認項目を選ぶことになりかねません。変わるのは、どの項目がそのプロダクトを支える重要な要素になるかです。通常は2〜3項目で、報告書に該当項目と理由を記載します。

01アーキテクチャ
この構造が、次の機能だけでなく、今後12か月の変更にも耐えられるかを見ます。
現在の設計では、どの時点から追加したい機能を支えられなくなりますか?
02保守性
全体を読み込まなくても、次のエンジニアが安全に変更できるかを見ます。
新しい担当者が、何も壊さずに変更をリリースできるまで、どれくらいかかりますか?
03セキュリティ
認証、認可、秘密情報、すでに保持している顧客データを確認します。
サーバー側で強制されていることと、画面上でしか制限されていないことは何ですか?
04データ
スキーマ、整合性、マイグレーション、本番環境の誤ったレコードを1件だけ修正する方法を確認します。
顧客から「この数字が間違っている」と言われたとき、実際にどう対応しますか?
05インフラ
デプロイ、アクセスが10倍になった場合の費用、深夜2時に再デプロイできる人を確認します。
デプロイできる唯一の担当者が移動中なら、どうしますか?
06信頼性
最初に壊れるもの、その影響範囲、実際の復旧時間を確認します。
このシステムに起こりうる最悪の1時間は何ですか? すでに経験していますか?
07可観測性
顧客から連絡を受ける前に、異常へ気づけるかを見ます。
最初に現れる兆候は何ですか? 誰がそれに気づきますか?
08性能
性能の上限、それを引き上げる方法、いま対応する価値があるかを見ます。
利用者が何人になると、使い続けられないほど遅くなりますか?
09プロダクトの範囲
公開に不可欠なものと、必要に見えて実はそうでないものを見極めます。
何なら削っても、同じプロダクトとして公開できますか?
10ローンチ計画
実施順序、切り戻し、サポート体制、公開後2週間の動きを確認します。
初日に問題が起きた場合、すでに書面にした対応計画はありますか?

各項目の下にある藍色の線は、その項目で答えるべき問いを示しています。この10の問いのどれにも答えない所見は、報告書に入れません。

03 お渡しするもの

5つ。すべてお客様に帰属します。

成果物の権利はすべてお客様に帰属します。ライセンス、優先交渉権、他社へ持ち込みにくくする条項はありません。口頭だけでなく文書にするのは、そのためです。

  1. 01

    優先順位をつけたリスク一覧

    すべての所見に、何もしない場合の費用、修正費用の概算、どの段階で直すと最も費用を抑えられるかを添えます。何もしない費用のほうが小さい場合は、明確に「対応不要」と記します。

  2. 02

    残すもの・変えるものの一覧

    そのまま残すものと変更が必要なものを分けます。多くの場合、コードの大部分は残ります。変更するものには理由を添えるため、権威ではなく根拠をもとに判断できます。

  3. 03

    推奨アーキテクチャ

    公開時に必要な構成と、現在の約10倍のアクセスに対応する構成をそれぞれ示し、違いを明記します。後者をいま構築する必要はありません。将来の実現を妨げないことが目的です。

  4. 04

    実行可能なロードマップ

    それぞれ単独でリリースできる単位に分け、実施順に並べます。私たちと話したことのないエンジニアが実行できなければ、完成とは言えません。

  5. 05

    ワークショップでの判断記録

    意見が分かれた点、最終的な判断、その理由を文章に残します。6か月後には、このページが成果物の中で最も役に立つことも少なくありません。

スライドではなく文書でお渡しします。エンジニアが対象のコードと一緒にリポジトリへ保存できるMarkdownと、読みやすいPDFの両方をご用意します。

04 お願いすること

4つ。リポジトリへのアクセスだけは、ご相談後にお願いします。

半日

プロダクトが現在の形になった理由を知る方にご参加いただきます。通常は創業者か開発者で、委員会のような大人数は必要ありません。

閲覧権限

リポジトリとインフラ管理画面への閲覧権限をお願いします。アセスメント中に書き込み権限をお願いすることはありません。

すでに伝えている約束

顧客、投資家、自社チームに伝えている公開時期や内容を、口頭のものも含めて共有してください。コード以上に、作業の順序を左右する情報です。

90分

結果を実行する立場の方全員に、ワークショップへご参加いただきます。この打ち合わせだけは、代理の方にお任せいただくことはできません。

リポジトリへのアクセスをお願いするのは、双方でお役に立てると確認した後です。お問い合わせフォームや相談前にお願いすることはありません。相談の結論が「まだ早い」であれば、アクセスは不要です。

05 対象としないこと

ご提供しないもの、6つ。

対応範囲は、2週目になってから気づくより、最初に明確にするほうが双方の負担を減らせます。

侵入テストや正式なセキュリティ監査ではありません

セキュリティは10項目のうちの一つです。専門家による検証が必要な場合は、その旨と依頼すべき内容を明確にお伝えします。

コンプライアンス認証ではありません

SOC 2やISO 27001などの認証を発行するものでも、代替するものでもありません。対応すべきフレームワークがある場合は、ロードマップに反映します。

コードスタイルのレビューではありません

命名など、書き方の好みを指摘するためのものではありません。負荷がかかったときのシステムの動作を変えない指摘は、報告書に入れません。

全面的な作り直しの提案ではありません

動いているコードは残すのが基本です。置き換えを提案する場合は、何もしない場合の費用もあわせて示します。

動くプロトタイプがないアイデア段階の案件は対象外です

動くものがなければ、評価できるものもありません。別のご相談としてお話を伺うことはできますが、このアセスメントの対象ではありません。

規制対象や安全性が重要な案件を、無条件にはお受けしません

医療、金融、安全性が重要なプロダクトは、私たちが適任かを慎重に確認し、適切に対応できる場合に限ってお受けします。適任でない会社を選ぶ負担を、お客様に負わせるわけにはいかないためです。

06 よくある質問

よくいただく6つの質問に、あらかじめお答えします。

01すべて作り直すよう勧められますか?

いいえ。多くの場合、私たちは全面的な作り直しに反対します。理解しているシステムを未知のシステムに置き換え、顧客に見える成果がないままロードマップを何か月も止めることになるためです。動いているコードは残すのが基本です。置き換えを提案する場合は、何もしない場合の費用も示すため、根拠をもとに判断できます。

02秘密保持にはどのように対応しますか?

御社のNDAに署名します。書式のご用意がなければ、私たちのものも利用できます。アクセスは閲覧のみに限定し、双方でお役に立てると確認した後にお願いします。お客様名や成果を公開するのは、明確な許可をいただいた場合だけです。それ以外の案件は非公開とします。

03AIが生成したプロトタイプでも問題ありませんか?

問題ありません。AIやノーコードは検証手段として有効であり、すでに需要を確かめたプロダクトを評価したいと考えています。AI生成コードには、例外を握りつぶす処理、画面側だけの認可、最初のプロンプトに左右されたスキーマなど、よくある問題があります。見つけやすく、多くは低い費用で修正できます。

04既存の開発チームで成果物を使えますか?

はい。そのために作成します。ロードマップには、実施単位、順序、判断理由を、私たちと話したことのないエンジニアでも引き継ぎなしで実行できる詳しさで記載します。私たちの同席がなければ使えないなら、成果物として不十分です。

05アセスメント後の実装も、uncoolに依頼する必要がありますか?

いいえ。依頼の義務も優先交渉権もありません。成果物はお客様に帰属し、自社チーム、uncool、他の開発会社のいずれでも実装できます。文書は意図的に特定の開発会社に依存しない内容にしています。

06すでに公開済みでも、手遅れではありませんか?

手遅れではありません。よくあるご相談です。公開済みの場合は、アセスメント内容ではなく対応の順序を変えます。停止せずに変更できるもの、移行が必要なもの、作業可能な時間帯まで待つものを整理します。アセスメント中に開発を止める必要はありません。

01すべて作り直すよう勧められますか?

いいえ。多くの場合、私たちは全面的な作り直しに反対します。理解しているシステムを未知のシステムに置き換え、顧客に見える成果がないままロードマップを何か月も止めることになるためです。動いているコードは残すのが基本です。置き換えを提案する場合は、何もしない場合の費用も示すため、根拠をもとに判断できます。

02秘密保持にはどのように対応しますか?

御社のNDAに署名します。書式のご用意がなければ、私たちのものも利用できます。アクセスは閲覧のみに限定し、双方でお役に立てると確認した後にお願いします。お客様名や成果を公開するのは、明確な許可をいただいた場合だけです。それ以外の案件は非公開とします。

03AIが生成したプロトタイプでも問題ありませんか?

問題ありません。AIやノーコードは検証手段として有効であり、すでに需要を確かめたプロダクトを評価したいと考えています。AI生成コードには、例外を握りつぶす処理、画面側だけの認可、最初のプロンプトに左右されたスキーマなど、よくある問題があります。見つけやすく、多くは低い費用で修正できます。

04既存の開発チームで成果物を使えますか?

はい。そのために作成します。ロードマップには、実施単位、順序、判断理由を、私たちと話したことのないエンジニアでも引き継ぎなしで実行できる詳しさで記載します。私たちの同席がなければ使えないなら、成果物として不十分です。

05アセスメント後の実装も、uncoolに依頼する必要がありますか?

いいえ。依頼の義務も優先交渉権もありません。成果物はお客様に帰属し、自社チーム、uncool、他の開発会社のいずれでも実装できます。文書は意図的に特定の開発会社に依存しない内容にしています。

06すでに公開済みでも、手遅れではありませんか?

手遅れではありません。よくあるご相談です。公開済みの場合は、アセスメント内容ではなく対応の順序を変えます。停止せずに変更できるもの、移行が必要なもの、作業可能な時間帯まで待つものを整理します。アセスメント中に開発を止める必要はありません。

07 相談を申し込む

10項目のうち2つ、3つが気になっているなら、ここから始めましょう。

7つの質問に約3分でお答えいただいた後、日程調整用のリンクをお送りします。相談では、いまアセスメントが適切かを一緒に判断します。適切でない場合は、率直にお伝えします。それも無料で得られる、有益な回答の一つです。

1〜2週間 ・ 有料 ・ 成果物はお客様に帰属 ・ 特定の開発会社に依存しない