Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
このページについて
Markdownファイルにおける電子署名/承認の実装方法と運用について、Git、外部サービス、DMSなど複数のアプローチを解説します。
Markdownファイルにおける電子署名/承認
Markdownで設計書を作成する際、承認欄における「電子署名/承認」は、Markdownのテキストベースの性質上、PDFなどの専用ツールのような厳密な電子署名（暗号技術を用いた改ざん防止機能など）を直接埋め込むことはできません。
しかし、「電子的な承認の記録と運用」という観点であれば、いくつかの方法で実現・運用が可能です。これは、Markdownファイル自体に署名を埋め込むのではなく、Markdownファイルを管理するシステムやプロセスと連携して承認を記録するというアプローチになります。
結論から言えば、プロジェクトやドキュメントの性質に応じて、複数の手法を併用すべきと言えます。
以下に、主な実装・運用方法と、それぞれのメリット・デメリットを解説します。
Markdownファイルにおける電子署名/承認の考え方
Markdownファイル自体はプレーンテキストであるため、その内容が改ざんされていないことを保証する暗号学的署名を直接埋め込むことは困難です。したがって、Markdownにおける「電子署名/承認」とは、以下のいずれかの方法で「誰が、いつ、どのバージョンの文書内容に合意したか」という事実を電子的に記録することを指します。
- Markdownファイルに承認情報をテキストで記載し、その正当性を外部のシステム（バージョン管理システム、メールなど）で担保する。
- Markdownファイルを別の形式（PDFなど）に変換し、その変換されたファイルに対して厳密な電子署名を行う。
実装・運用方法
1. バージョン管理システム (Gitなど) のコミットログを利用する
これは開発チーム内で最も一般的かつ手軽な方法です。
- 実装 (Markdown):
承認欄には、承認者の氏名と承認日をテキストで記載します（以下の例では、解説に不要な項目を省略しています）。## 9. レビュー・承認履歴 ### 9.2. 承認欄 本基本設計書の内容について、以下の通り承認します。 | 役割 | 氏名 | 承認日 | 承認方法 | | :------------- | :----------- | :----------- | :----------------------- | | **顧客代表** | [顧客代表者名] | 2025/12/06 | Gitコミット([コミットID]) | | **PM** | [PM氏名] | 2025/12/06 | Gitコミット([コミットID]) | | **技術責任者** | [技術責任者名] | 2025/12/06 | Gitコミット([コミットID]) |コミットIDは承認後に追記するか、承認の事実を記録したコミットのIDを記載します。
- 運用:
- 設計書がレビューを経て最終版になったら、承認が必要な関係者にMarkdownファイルを共有（GitリポジトリのURLなど）します。
- 関係者は設計書の内容を確認し、承認の意思を表明します（口頭、チャット、メールなど）。
- 承認の意思表明を受け、承認者自身、または承認者の代理で責任者が、Markdownファイルの承認欄に氏名と日付を追記し、その変更をGitにコミットします。
- このコミット自体が「電子的な承認の記録」となります。Gitのコミットログには、誰が、いつ、どのような変更（承認欄の更新）を行ったかの記録が残ります。コミットIDをMarkdownファイルに記載することで、その承認がどのコミットで行われたかを追跡できます。
- 必要であれば、コミットにGPG署名を行うことで、コミット自体の改ざん防止とコミット者の本人性を強化できます。
- メリット:
- 手軽さ: 開発チームが日常的に利用するツールで完結します。
- バージョン管理との連携: 設計書の変更履歴と承認履歴が一体で管理されます。
- 追跡可能性: Gitのコミットログにより、誰がいつ承認したか、その時点の設計書の内容がどうだったかを容易に追跡できます。
- 完全性(改ざん検知・防止): Gitのハッシュ値により、コミット後のファイルの改ざんを検知できます（厳密な電子署名とは異なりますが、一定の保証はあります）。GPG署名をすれば、さらに完全性を強化できます。
- デメリット:
- 非技術者には不向き: Gitの操作に慣れていない顧客や非技術者には、この方法での「承認」は理解しづらい場合があります。
- 法的効力の限界: Gitコミット単体では厳密な法的効力を持つ電子署名とは見なされないことも多くあります。
- 代理コミットのリスク: 承認者自身がコミットしない場合、代理コミット者の信頼性に依存します。
2. 外部の電子署名サービス (DocuSign, Adobe Signなど) と連携する
法的効力や非技術者への対応が必要な場合に有効です。
- 実装 (Markdown):
承認欄には、外部サービスで承認されたことを示す文言と、署名済み文書へのリンクを記載します（以下の例では、解説に不要な項目を省略しています）。## 9. レビュー・承認履歴 ### 9.2. 承認欄 本基本設計書の内容について、以下の通り承認します。 | 役割 | 氏名 | 承認日 | 承認方法 | | :------------- | :----------- | :----------- | :----------------------- | | **顧客代表** | [顧客代表者名] | 2025/12/06 | 外部電子署名サービス([リンク]) | | **PM** | [PM氏名] | 2025/12/06 | 外部電子署名サービス([リンク]) | | **技術責任者** | [技術責任者名] | 2025/12/06 | 外部電子署名サービス([リンク]) | *本設計書の正式な承認は、[外部電子署名サービス名]にて署名されたPDF文書([署名済みPDFへのリンク])によって行われています。* - 運用:
- MarkdownファイルをPDFなどの署名可能な形式に変換します。
- 変換したファイルをDocuSignやAdobe Signなどの電子署名サービスにアップロードします。
- サービス上で承認依頼を関係者に送信し、各関係者がサービスを通じて電子署名を行います。
- 署名済みのPDFファイルをダウンロードし、安全な場所に保管します。
- Markdownファイルの承認欄を更新し、署名済みPDFファイルへのリンク（またはその保管場所への参照）を記載します。
- Markdownファイル自体もGitなどでバージョン管理しておきます。
- メリット:
- 法的効力: 多くの電子署名サービスは、法的効力を持つ電子署名を提供します。
- 非技術者にも対応: サービスは直感的なUIを提供するため、非技術者でも容易に承認できます。
- 改ざん防止: 署名されたPDFは改ざん検知機能を持つため、高い信頼性があります。
- デメリット:
- 手間とコスト: MarkdownからPDFへの変換、サービスへのアップロード、署名依頼などの手間がかかり、サービスの利用料も発生します。
- 情報の分散: 承認の「事実」はPDFにあり、Markdownファイルはその参照元となります。Markdownファイル自体が承認済みというわけではありません。
- バージョン管理との連携: Markdownの変更履歴と、署名済みPDFのバージョン管理を別途行う必要があります。
3. ドキュメント管理システム (DMS) のワークフローを利用する
Confluence, SharePoint, RedmineのWiki機能など、承認ワークフローを持つDMSにMarkdownファイルを格納する場合。
- 実装 (Markdown):
承認欄は、Gitコミットの場合と同様にテキストで記載します。DMSの承認機能と連携していることを明記します（以下の例では、解説に不要な項目を省略しています）。## 9. レビュー・承認履歴 ### 9.2. 承認欄 本基本設計書の内容について、以下の通り承認します。 | 役割 | 氏名 | 承認日 | 承認方法 | | :------------- | :----------- | :----------- | :----------------------- | | **顧客代表** | [顧客代表者名] | 2025/12/06 | DMSワークフロー([リンク]) | | **PM** | [PM氏名] | 2025/12/06 | DMSワークフロー([リンク]) | | **技術責任者** | [技術責任者名] | 2025/12/06 | DMSワークフロー([リンク]) | *本設計書の正式な承認は、[DMS名]の承認ワークフロー([承認履歴へのリンク])によって記録されています。* - 運用:
- MarkdownファイルをDMSにアップロードまたは直接編集します。
- DMSの承認ワークフロー機能を利用して、関係者に承認依頼を送信します。
- 関係者はDMS上で設計書を確認し、「承認」ボタンなどをクリックします。
- DMSは承認者、承認日時、承認した文書のバージョンなどの情報を記録します。
- Markdownファイルの承認欄を更新し、DMSの承認記録へのリンクを記載します。
- メリット:
- 統合されたワークフロー: ドキュメントの作成から承認までを一元的に管理できます。
- 監査証跡: DMSが承認履歴を自動的に記録し、改ざん防止機能を持つことが多いです。
- アクセス管理: 文書の閲覧・編集権限をDMSで管理できます。
- デメリット:
- DMSの導入・運用コスト: 適切なDMSが必要であり、その導入や運用にコストがかかります。
- Markdownの表現力: DMSのMarkdownエディタによっては、表現力に制約がある場合があります。
- 法的効力: DMSの承認機能が厳密な法的効力を持つ電子署名と見なされるかは、システムや地域によって異なります。
4. メールやチャットでの承認記録を利用する
最も簡易的な方法で、内部的な合意形成に利用されます。
- 実装 (Markdown):
承認欄には、承認者の氏名と承認日をテキストで記載し、承認の証拠となるメールやチャットのID/リンクを記載します。## 9. レビュー・承認履歴 ### 9.2. 承認欄 本基本設計書の内容について、以下の通り承認します。 | 役割 | 氏名 | 承認日 | 承認方法 | | :------------- | :----------- | :----------- | :----------------------- | | **顧客代表** | [顧客代表者名] | 2025/12/06 | 承認メール([メールID/リンク]) | | **PM** | [PM氏名] | 2025/12/06 | 承認チャット([チャットID/リンク]) | | **技術責任者** | [技術責任者名] | 2025/12/06 | 承認メール([メールID/リンク]) | - 運用:
- 設計書の最終版を、承認が必要な関係者にメールで送付するか、チャットで共有します。
- 関係者は内容を確認し、「承認します」といった明確な意思表示をメールやチャットで返信します。
- この承認メールやチャットの記録を保存し、Markdownファイルの承認欄にそのメールのIDやチャットのリンクを記載します。
- Markdownファイル自体もGitなどでバージョン管理しておきます。
- メリット:
- 非常に手軽: 特別なツールを導入する必要がありません。
- コミュニケーションツールとの連携: 日常的なコミュニケーション手段で承認プロセスを完結できます。
- デメリット:
- 法的効力の限界: 厳密な法的効力を持つ電子署名とは見なされません。
- 追跡の困難さ: メールやチャットの記録が分散しやすく、後から特定の承認を追跡するのが難しい場合があります。
- 改ざんリスク: メールやチャットの内容が改ざんされていないことを保証する仕組みは弱いです。
どの方法を選択すべきか？
選択するべき方法は、プロジェクトの要件、関係者、法的要件、利用可能なツール、およびプロジェクトの規模によって異なります。
- 開発チーム内での合意形成: Gitコミットを利用する方法が最も効率的です。
- 顧客や外部パートナーとの正式な合意、法的効力が必要な場合: 外部の電子署名サービスを利用する方法が最も確実です。
- 社内での一元的なドキュメント管理と承認ワークフロー: ドキュメント管理システムの利用を検討します。
- 小規模なプロジェクトや迅速な内部合意: メールやチャットでの承認記録も選択肢になりえますが、リスクを理解しておく必要があります。
どの方法を採用するにしても、「誰が、いつ、どのバージョンの文書に合意したか」という事実を明確に記録し、後からその記録を追跡できるようにすることが最も重要です。