本文へ移動
ひとつの安定したアイデンティティ 人によるオーサリングが基本 ポータビリティを前提に設計
Topoloom by Relia1

評価ガイド · 日本語

ひとつのService変更を試す。 次に何をするかを決める。

評価を広げる前に、現在のプロセス、設定の手間、観察した挙動、未解決の制限、エクスポート結果を記録します。

製品の挙動は評価環境で実際に示される必要があります。

01 · 課題

調整の課題をひとつ選ぶ。

チームにとって重要なServiceに関する判断をひとつ選びます。共有モデルが作業を変えるかを試す前に、現在の手順を記録してください。

  • コピーされたサービスの説明

    複数の文書やダイアグラムに登場する概念をひとつ選び、コピー同士が食い違っている箇所や、別々にメンテナンスが必要な箇所を記録します。

  • 重要な変更

    レビュー担当者が理解し承認できるべき、担当者、依存関係、Runbook、SLO、Decision の変更をひとつ選びます。

  • 見えるベースライン

    現在のレビュー時間、コピーの数、欠けている関係、その他評価後に再度測定できるエビデンスを記録します。

02 · 評価の準備

デモの前に境界を明示する。

何を評価に含めるか、誰が閲覧できるか、何をもって有用な結果とするかを合意します。本番のナレッジが適切でない場合は、合成データまたは明示的に承認されたコンテンツを使用してください。

  • データセット

    再利用を試すために、Serviceひとつ、Teamひとつ、短い文書二つ、ダイアグラムひとつを使います。Runbook、SLO、Decisionは関係する場合にのみ追加します。

  • 参加者

    作成者、レビュー担当者、評価オーナー、閲覧のみのオブザーバーを指名します。各ロールに想定されるアクセス権を文書化します。

  • 環境

    製品バージョン、有効な設定、連携、ID プロバイダー、評価中に使用する外部サービスを記録します。

  • エビデンスの取得

    顧客や本番の機密情報を含めずに最終判断を裏付けるスクリーンショット、タイムスタンプ、エクスポート、レビュー担当者のメモを決めます。

  • 終了基準

    判断日を設定し、何を示す必要があるか、何を未検証のままにしてよいか、どのギャップがあれば拡大を止めるかを合意します。

広げる前に、作業を合意する。

Topoloomチームとこのチェックリストを使います。より広い展開を始める前に、各項目の回答と担当者を記録してください。

  1. 担当者と時間

    作成者、レビュアー、評価責任者を指名します。セッション、準備作業、各人が割ける時間を合意します。

  2. コンテンツと移行

    短い合成または承認済みの文書から始めます。現行のインポートはMarkdown、プレーンテキスト、CSV/TSV、HTML、DOCX、ConfluenceからエクスポートしたWordファイルを、それぞれ最大1 MBまで受け付けます。一つ試し、大規模な移行を計画する前に手作業で整える箇所を記録します。

  3. セットアップと接続

    利用可能なデプロイメント、ログイン方法、有効な機能、コネクターを確認します。現行リリースでは、デプロイメント運用者がWorkspaceメンバーを追加します。招待やセルフサービス登録はありません。どのデータが環境外へ出るか、誰がアクセスできるかを記録します。

  4. サポートと費用

    セットアップ、質問、障害を誰が扱うかを合意します。評価費用、継続料金、含まれるサポートは書面で確認し、デモでこれらの条件が決まるとは考えないでください。

  5. 判断と完了

    レビュー日を設定します。結果をベースラインと比較し、停止、継続テスト、拡大のいずれにするかを決めます。エクスポート、保持、削除の手順も合意します。

03 · サンプルワークフロー

ひとつの概念を執筆から出口まで追う。

合意した環境で各ステップを製品チームに実演してもらいます。スライド、ダイアグラム、用語だけから機能を推測しないでください。

  1. 書く

    通常のオーサリング画面で短い技術的な説明を作成またはインポートし、フリーフォームのまま残る部分を記録します。

  2. 特定する

    重要な概念を選択し、識別子、型、オーサリング、現在の状態がどのように表現されるかを確認します。

  3. 再利用する

    その概念を2つ目の文書またはダイアグラムから参照し、製品が参照を作成したのか、別の独立したコピーを作成したのかを確認します。

  4. 変更する

    合意した担当者、依存関係、Runbook、SLO、Decision の変更を提案し、承認前にレビュー担当者が何を見られるかを観察します。

  5. 公開または保存する

    設定された公開とバージョンのワークフローを実演してもらい、何が不変になり、何が編集可能なまま残るかを記録します。

  6. エクスポートして検査する

    利用可能なエクスポートを生成し、製品の外で開いて、その内容を文書化されたエクスポート一覧と比較します。

各ステップについて、成功した経路と、権限、プロバイダー、ネットワーク、バリデーションの条件によって完了できなかった場合の挙動の両方を記録してください。

04 · 権限とデータ

エビデンスで答えられる問いを立てる。

答えは評価対象のデプロイメントとその設定によって異なります。包括的な保証を受け入れるのではなく、実演、設定の参照先、責任者の名前を求めてください。

  • 選択したリソースを誰が閲覧、作成、レビュー、公開、エクスポート、管理できますか?

    評価マトリクスの各ロールについて、許可される操作と拒否される操作を少なくとも1つずつ検証します。

  • コンテンツが検索、参照、エクスポートされたり連携経由で表示されたりするとき、認可はどこで評価されますか?

    どのチェックが実演され、どれが設計上の記述や設定上の前提にとどまるかを記録します。

  • どのデータが、どの目的で評価環境の外に出ますか?

    有効化された各連携またはプロバイダーについて、送信先、フィールド、トリガー、保持、削除の経路を一覧にします。

  • どのログ、分析、バックアップ、サポートプロセスに評価データが含まれる可能性がありますか?

    グローバルなポリシーを前提とせず、当該環境の運用責任者と保持ポリシーを確認します。

  • 外部プロバイダー、ネットワーク経路、連携が利用できなくなると何が起きますか?

    どのオーサリングとレビューの作業が継続し、どれが停止し、不完全または古いコンテキストがどのように表示されるかを観察します。

  • この評価はどのセキュリティ、プライバシー、法務の文書に基づきますか?

    所有者から提供された承認済みの文書のみを使用してください。このガイドはそれらの資料の代わりにはなりません。

05 · エクスポートと出口

拡大を決める前に出口の経路を試す。

エクスポートの名称は完全性のエビデンスではありません。含まれる情報と省略される情報の一覧を求め、Topoloom の外部にあるツールでパッケージを検査してください。

  • 読める内容

    稼働中の Topoloom 環境なしで、どの文書とダイアグラムの表現を開けるかを確認します。

  • 構造化されたコンテキスト

    評価したエクスポートに、出口計画に必要な識別子、バージョン、関係、来歴、レビュー記録、マッピングが含まれているかを検査します。

  • 文書化された省略

    評価したフィールドや挙動のうち、エクスポートされないもの、変換されるもの、別の管理プロセスが必要なものをすべて一覧にします。

  • 再現性

    管理された状態からエクスポートを2回実行し、下流での利用や監査に影響する差異を説明します。

  • 削除と終了処理

    評価用ワークスペース、プロバイダーのデータ、アカウント、バックアップ、エビデンスファイルを評価後にどのように保持または削除するかを合意します。

06 · 判断記録

テストで確立したことを書き残す。

この八つの項目を判断メモに写します。各結果を「示された」「設定により示された」「利用不可」「未検証」として記録し、エビデンスをリンクして、各ギャップの担当者を明記します。

  • 範囲と担当者

    Service、文書、ダイアグラム、試した変更、作成者、レビュアー、環境、判断日を記録します。

  • 現在のベースライン

    Topoloomのテスト前に、既存の手順、繰り返す編集、レビュー時間、見つかった不足を記録します。

  • 観察したワークフロー

    オブジェクトID、参照、二回目の更新、レビュー結果、設定の手間、手作業での修正を、エビデンスへのリンクとともに記録します。

  • アクセスとデータ

    許可された操作と拒否された操作を各一つ、有効なデータフロー、その担当者、未解決の問いを記録します。

  • 障害時の挙動

    試したプロバイダー、権限、バリデーションの失敗を記録し、何が続き、何が古くなったか、または利用できなくなったかを記します。

  • エクスポートと出口

    Topoloomの外で開いたもの、パッケージ形式、省略、再マッピング、完了作業を記録します。

  • 比較と不足

    二回目の更新を含め、同じ変更をベースラインと比較します。すべての不足に担当者と解決日を割り当てます。

  • 判断

    停止、延長、拡大のいずれかを記録し、エビデンス、未検証の前提、次のレビュー日を記します。

次のステップ

ワークフローを試す。 限界を記録する。

セッションの前に用語集で言葉を揃え、チームが選んだ範囲付きのワークフローとエビデンスに沿ったウォークスルーをリクエストしてください。

製品の画面