典型的なドキュメント環境は、少しずつ積み重なって出来上がったものです。何年も前に誰かがライセンスを購入したデスクトップのPDF編集ソフト、大きな取引のために契約した電子署名サービスのサブスクリプション、そして成果物が行き着く共有ドライブ。ツールそれぞれに問題はありません。ドキュメントが傷つくのは、その受け渡しの場面です。
受け渡しのたびに履歴が失われる
エディタからエクスポートし、署名サービスにアップロードし、署名済みのコピーをダウンロードして、ドライブに保管する — この移動のたびに、ドキュメントは素性の分からないただのファイルとして振り出しに戻ります。編集履歴はエディタの中に置き去りになり、署名のイベントは電子署名ツールの中に残されたまま。ドライブにあるのは、そのどちらの記憶も持たないPDFです。
半年後に何が起きたのかを再構成しようとすれば、3つのツールに散らばった断片的な記録を突き合わせるしかありません — そもそもサブスクリプションがまだ有効であれば、の話ですが。
代わりに、1つの途切れない記録を
GingerDocsでは、編集から署名、そして保管まで、同じ1つのドキュメントオブジェクトがそのまま進んでいきます。原本のPDFは読み取り専用のまま保持され、編集は元に戻す/やり直しとバージョン履歴を備えたオーバーレイ上で行われます。署名は並行または順次のフローを通じて同じオブジェクトに対して行われ、その過程のすべてのイベントは、追記専用でハッシュチェーン化された1つの監査ログに記録されます。
完了すると、フラット化されたPDFがその同じ記録から生成されます。そしてドキュメントを取り巻くワークスペースが、フォルダ、プロジェクト、全体検索、ダッシュボードの件数表示、連絡先、チームのロールといった、本来なら共有ドライブの仕事だったはずの機能を提供します。
ツールが減れば、抜け漏れも減る
| 質問 | 3ツール構成 | GingerDocs |
|---|---|---|
| 誰がいつ編集したか? | 記録されていたとしても、デスクトップの編集ソフトの中 | ドキュメントのバージョン履歴に |
| 誰が閲覧し、署名したか? | 電子署名ベンダーのポータルの中 | ドキュメントの監査ログに |
| このPDFは本物の署名済みコピーか? | ファイルを見比べて祈るだけ | 検証ページで確認できる |
| 最新版はどこにあるか? | 最後に触ったツールの中 | 1つのドキュメント、1つの場所 |
大事なのはセット販売ではなく、記録そのもの
統合のための統合は、単なるベンダーの都合にすぎません。本当の論点は継続性です。紛争の場面でドキュメントの価値を決めるのは途切れのない履歴であり、その途切れのない履歴こそ、受け渡しが壊してしまうものです。一連の流れを1つの場所に収めれば、記録はおのずと保たれます。