オーダーメイド開発の費用は何で決まるか
予算の出発点は画面数ではなく、利用者が完了させる仕事と例外処理です。 権限、既存データの取り込み、外部連携、失敗時の復旧まで含めて考えます。
記事
よりよい判断のためのノート。
プロダクト、ソフトウェア開発、その間にある判断についての実践的な記事。
記事
既製ソフトか独自開発かを判断する比較表
業務のどこに独自の価値があるかから考えます。 一般的な仕事は既製品を調べ、運用を変えると顧客への価値が失われる部分は独自開発を検討します。
開発前の調査で答えを出すべき質問
調査の価値は意思決定を変えられることにあります。 誰が仕事をし、何が問題で、成功を何で確認するかを明確にします。
ソースコードだけで終わらせない引き継ぎ確認表
リポジトリは所有と引き継ぎの一部です。 別の担当チームが個人アカウントに依存せず、ビルド、公開、監視、復旧できる状態を目指します。
目的を失わずに開発範囲の変更を扱う
新しい要望は情報であり、そのまま開発指示になるわけではありません。 合意した要件への不具合、新しく判明した要件、好みを分けます。
最初のMVPに含める機能の決め方
MVPには、役に立つ結果まで完了できる一つの道筋と、その価値を確かめる方法が必要です。 選んだ仕事の完了、安全な試行、結果の観測に欠かせない機能を残します。
MVPの日程を左右する依存関係
納期は開発工数だけでなく、決定やアクセス権にも左右されます。 何が先に分かる必要があるかで仕事を並べます。
プロトタイプ、技術検証、MVPの使い分け
プロトタイプは操作の理解を、技術検証は定めた条件で実現できるかを調べます。 MVPは実際の利用者に、限定された使える結果を提供します。
技術に詳しくない創業者のための要件の書き方
技術を選ぶ前に、目で確かめられる動作を書きます。 誰が、どの状態から、何をして、どの結果を確認するかを示し、その結果を変える権限と例外を加えます。
最初の製品にノーコード、ローコード、独自開発のどれを選ぶか
最も難しい必須業務と、その後の保守担当者を基準に選びます。 画面上で作れる道具にもデータ、権限、運用費があります。
複数企業が使うSaaSでデータを分離する
テナント分離は最後に識別子を足す作業ではなく、設計して検証する境界です。 各企業の所有物、境界を越えられる人、個別復旧の必要性を定めます。
SaaSの購読を状態の変化として設計する
まず、顧客が何を利用でき、その権利がいつ変わるかを決めます。 Stripeの説明でも、支払い、請求書、購読は関連しながら別の状態を持ちます。
役立つものを、一緒に。
最初のプロダクト、複雑な業務、見直したいソフトウェア。現在の状況をお聞かせください。