カスタムSaaS
チームの実際の仕事に合うソフトウェア。
社内ツール、顧客ポータル、SaaS製品を開発します。メールで届く依頼、スプレッドシート間で繰り返し転記する情報、顧客から何度も寄せられる進捗確認が、プロジェクトのきっかけになることがあります。まず業務の流れを理解し、どの部分をソフトウェアで変える価値があるかを判断します。
何をつくるか決める前に
役立つ要件説明には、作業の内容、作業する人、うまくいかないときに何が起きるかが記されています。画面の一覧だけでは十分ではありません。
実際の業務フローを起点に
誰が作業を始め、どの情報を持ち、次に誰が対応するのでしょうか。例外も含め、実際の依頼や作業を確認します。
役立つ最小限の範囲
利用者が使って評価できる、業務の一部分を選びます。既存のツールに残すものと、初回リリースで置き換えるものを決めます。
届けたものを運営する
アクセス権、データ、サポート、今後の変更の責任者について合意します。運用できる状態で公開するには、エラーを検知し、不具合から復旧する方法も必要です。
構築するもの
社内ツールから顧客向け製品まで。
01
社内業務ツール
事業運営に携わる人のための、依頼受付、作業待ち一覧、レポート、システム連携。手作業による引き継ぎを減らして、チームが作業を完了できるかが有用な評価基準です。
02
顧客ポータル
顧客やパートナーが情報を提出し、進捗を確認し、作業を承認し、書類を探せる場所です。アクセス規則は、各アカウントに利用が認められた情報と一致させる必要があります。
03
SaaS製品
アカウント、利用開始の案内、繰り返し使う業務機能を備えた顧客向け製品です。請求、サポート、製品の変更についても、初期機能と併せて計画する必要があります。
独自開発を検討する価値がある場合
既存のツールでは十分に対応できないことを特定するところから始めます。独自のソフトウェアには柔軟性とともに保守の責任も伴います。
業務フローのボトルネック
手作業、表計算での繰り返し処理、チームを遅らせる引き継ぎは、多くの場合、すばやく着手できる領域です。
分断されたシステム
顧客情報、支払い、サポート依頼が、それぞれ別のシステムに保存されていることがあります。システムを連携すれば、チームが使うすべてのツールを置き換えずに、必要な情報をまとめられます。
サービスからソフトウェアへの移行
チームが同じサービスの手順を繰り返している場合、まず再現可能な部分の製品化を支援します。
顧客体験の不足
ポータル、業務フローの可視化、セルフサービス機能によって、複雑なサービス提供のプロセスを製品のような体験に変えられます。
プロジェクトの範囲を考える3つの例
以下はソフトウェアの開発範囲の例であり、完了した顧客案件の実績を示すものではありません。
業務の状況をチームで共有する
フォームやメールで依頼を受け、スプレッドシートで管理し、チャットで進捗を尋ねているチームを考えます。社内ツールで各依頼を記録し、担当者を割り当て、状況を表示し、その過程での判断を残すことができます。
- 仕事、リスク、処理量を週単位で把握したい運営者に適しています
- 多くの場合、受付、担当、進捗、報告を1つの画面に統合します
顧客・パートナー向けポータル
顧客が情報を提出し、書類を確認し、工程を承認し、進捗を確認する必要がある場合です。ポータルでこれらの操作をまとめ、権限によって各人が閲覧・変更できる範囲を定められます。
- 承認、文書交換、スケジュールの可視化、セルフサービス操作に適しています
- 通常、顧客の安心感を高めるとともに、社内のサポート負荷を軽減します
繰り返し提供するサービスをソフトウェアにする
サービスを提供するチームが、各顧客に対して同じ手順を繰り返す場合です。ソフトウェアで反復する工程を処理し、例外を記録し、判断が必要な部分は責任を持つ人に任せることができます。
- 同じ手順を手作業で繰り返し、ばらつきが大きい場合に適しています
- サービス提供からソフトウェア製品へ移行する、最初の具体的な一歩になることがよくあります
協働の進め方
課題を確認し、実行可能な範囲のリリースに合意してから、サポートの方法を決めます。
調査スプリント
現在のプロセスを、それを利用している人と一緒にたどります。利用者、データ元、権限、連携先、制約、そしてプロジェクトによって改善したい判断を特定します。
構築と提供
対象に含めるものと後回しにするものについて合意します。動く状態の変更内容をチームと確認し、重要な作業と失敗する場合をテストして、リリースと元に戻す手順を準備します。
運営
システムの運用方法と責任者を文書にします。次の変更を決める前に、エラー、利用状況、サポートへの質問を確認します。
得られるもの
製品を使いやすく、保守しやすく、運営しやすく保つ成果物。
製品と開発
- 調査メモと範囲の提案
- 小さな単位で提供する、動作するMVP
- 文書と明確な引き継ぎ
運営と改善
- 分析計画と主要イベント
- 監視、エラー報告、性能予算
- 次の改善とサポートに向けたバックログ
社内ツールから長く使える製品へ
実際の利用から始まり、時間をかけてより明確な製品へと成熟するソフトウェアの道筋を大切にしています。
業務フローを実証する
現場の実際の困りごと、限定した利用者層、明確な改善前後の成果から始めます。
再現可能な部分を製品化する
業務フローが安定したら、UIを簡素化し、権限を精緻化し、1つのチームを超えて使えるシステムにします。
継続利用を目指して運営する
製品段階では、信頼性、導入支援、利用状況の可視化、サポート負担の軽減へと重点が移ります。
ポートフォリオとの関係
開発から製品へと進むこの考え方は、PickleRickleやPlanAndPlayなどを含む、NaviVisionの幅広いソフトウェアポートフォリオにも反映されています。
品質、性能、アクセシビリティ
初日から、運営しやすい標準設計を。
性能
高速なページ、適切なキャッシュ、成長してもバンドルを小さく保つ計画。
基本的なセキュリティ
最小権限のアクセス、安全な認証パターン、ユーザーデータの安全な取り扱い。
アクセシビリティとSEO
複数のロケールに対応するセマンティックHTML、フォーカス状態、メタデータ、コンテンツ構造。
プロジェクトを始めるために必要なこと
業務の流れを知る人、範囲を決められる人、対象システムへのアクセス。
手作業を置き換える事業運営者
メール、表計算、繰り返しの調整に追われるチームは、焦点を絞った社内システムから早期に価値を得られることがよくあります。
専門性を製品化するサービスチーム
サービスに繰り返し可能な手順がある場合、ソフトウェアはその専門性を損なわずに業務フローを標準化できます。
範囲を定めた仕事を依頼したいチーム
明確な課題と、責任を持って判断する人がいれば、範囲に合意し、進捗を確認できます。開発チームがすでにある場合は、当社に任せたい部分と、そのチームの仕事とのつながりを明確にしてください。
よくある質問
カスタム開発と製品づくりについてのよくある質問。
MVPと完成した製品のどちらを開発しますか？
両方です。通常は業務フローと価値を実証するMVPから始め、長く使える製品に向けて改善を重ねます。
社内チームと協働できますか？
はい。チームを補強し、特定の業務領域を担い、整理された文書と引き継ぎを提供できます。
範囲とスケジュールをどう考えていますか？
範囲は、業務の流れ、システム連携、アクセス要件、移行する必要があるものによって変わります。納期を含む計画を立てる前に、これらを話し合います。要件の変更は、同じ期限に黙って追加するのではなく、明示的に検討する必要があります。
始めるにはどうすればよいですか？
目標、制約、時期を[email protected]までお送りください。
開発のアイデアがありますか？
作業の説明、現在のプロセスを使っている人、関連するツールをお知らせください。実際の予定や行事によって期限が決まっている場合は、その期限も含めてください。初回のお問い合わせに、パスワード、アクセストークン、顧客記録を含めないでください。
ソフトウェアの要件説明に含めること
実際の作業を一つ、最初から最後まで説明してください。誰が始めるか、どの情報が必要か、どのツールを使うか、どこで作業が遅れたり繰り返されたりするかを含めてください。次に、アクセスが必要な人、既存システムからのデータ移行の有無、必要な連携、変更を承認できる人といった制約を挙げてください。事前にソフトウェアを設計していただかなくても、それだけで範囲の話し合いを始められます。