システム開発プロジェクトで作ると便利なドキュメントとは?
システム開発プロジェクトでは、要件定義書や設計書、テスト仕様書など、必要不可欠なドキュメントが数多く存在します。しかし、実は日常的にはあまり作られていないものの、プロジェクトの進行をより円滑にする「便利なドキュメント」もあります。今回は、普段作成されていないが作成すると役立つドキュメントを紹介し、その利点について解説します。
1. コミュニケーションログ
プロジェクトを進行する中で、クライアントやチームとのコミュニケーションは頻繁に行われますが、これらのやり取りが後で振り返ると記録として残っていない場合があります。特に重要な意思決定や変更点が口頭で行われると、その内容が共有されず、後で問題を引き起こすことがあります。
クライアントとの議事録は取っていても、他のやり取りとの取り纏めは出来ておらず、情報が点在することが良くある状況になります。
コミュニケーションログは、会議や打ち合わせ、メールやチャットでのやりとりの要点を記録したもので、重要な決定事項や質問、回答などを一元化してまとめるものです。このドキュメントを定期的に更新し、全員がアクセスできる場所に保管することで、過去のやり取りを迅速に確認でき、コミュニケーションの齟齬を防ぎます。結果として、メンバー間の認識のズレを減らし、トラブルを未然に防ぐ効果があります。
例えば…
会議の内容要約
合意事項と未決事項
スケジュールの変更履歴
2. リスク管理シート
リスク管理は大規模なプロジェクトではよく行われますが、比較的小規模なプロジェクトでは十分にリスク管理に時間が割かれないことがあります。しかし、システム開発では技術的な問題やスケジュールの遅延、リソース不足など、さまざまなリスクが潜んでおり、これをあらかじめ予測し対策を立てることは非常に重要です。
リスク管理シートを活用することで、プロジェクトに潜むリスクをリスト化し、発生時の影響度や発生確率、そして対策を明確にできます。これにより、リスクが顕在化した際に迅速に対応でき、プロジェクト全体のリスクを効果的にコントロールすることが可能になります。定期的にリスクを見直し、シートを更新しておくことで、プロジェクト進行中の不測の事態にも柔軟に対応できます。
またシステム開発する側としては、リスクを事前に共有・記録しておくことで、プロジェクト遅延時などに証跡としても活用することができます。
例えば…
リスクの内容(技術的問題、リソース不足など)
リスク発生時の影響度(高、中、低)
リスクの発生確率(高、中、低)
対策と担当者
3. Architecture Decision Record (ADR)
システム開発では、アーキテクチャの設計や技術スタックの選定など、数々の技術的な意思決定が行われます。しかし、これらの意思決定に至った理由やそのプロセスがドキュメント化されない場合、後に「なぜこの技術を選んだのか?」という質問に答えるのが難しくなることがあります。
Architecture Decision Record (ADR) は、技術的な決定に関する情報を記録し、その背景や選択の理由、他のオプションとの比較、長期的な影響などを文書化するためのドキュメントです。ADRを作成しておくと、新しいメンバーがプロジェクトに加わった際にも、過去の技術的な選択の理由を理解しやすくなり、変更や調整が必要な場合でもスムーズに対応できます。また、プロジェクト全体の技術戦略を振り返ったり、他のプロジェクトに役立つ情報を共有する際にも非常に有効です。他にも途中で参画してエンジニアにとっても、どういう理由を選定したかが分かると、スムーズにプロジェクトの理解を進めることができます。
例
決定事項(アーキテクチャ設計、使用技術の選定)
決定に至る理由(性能、保守性、コスト、スケーラビリティなど)
他の選択肢との比較
長期的な影響やリスク
4. ユーザーストーリーマップ
昨今の開発では、ユーザーストーリーに基づいて機能を開発するのが一般的です。しかし、これを視覚的に整理して全体像を把握しやすくするためのユーザーストーリーマップは、あまり活用されていないことが多いです。ユーザーストーリーマップを作成することで、ユーザーの行動やシナリオをもとに、どの機能がどのように結びついているかを視覚的に整理できます。
このマップを使うことで、開発メンバー全員が全体像を理解し、優先順位を把握しやすくなります。
また、要件変更や新しい機能追加が発生した際にも、ユーザーストーリーマップを使えば迅速に対応でき、開発の柔軟性が向上します。
この内容は要件定義フェーズで作成しておくと、後続のフェーズでのも同様の理解で進めることができます。
例えば…
ユーザーのシナリオごとのフロー
機能の優先順位
要件の整理
5. ナレッジベース
システム開発中に遭遇する技術的な課題や解決策は、その場限りで対応してしまうことが多いですが、これらを体系的に記録しておくと、後々のプロジェクトで役立つことがあります。
ナレッジベースは、プロジェクトで得た技術的な知見やトラブルシューティングの記録を一元化し、誰でも参照できるようにしたドキュメントです。これにより、同じ問題が再発した際に過去の解決策を迅速に参照でき、効率的に対応できるようになります。また、ナレッジベースは新たに参加するメンバーの教育やスムーズなオンボーディングにも役立ちます。
システム開発で得たノウハウはそのまま企業の財産になりますので、蓄積して開発チームとしてのレベルアップに役立てていきましょう。
例えば…
技術的な課題とその解決方法
使用したライブラリやフレームワークに関する知見
ベストプラクティスや注意点
6.まとめ
これらのドキュメントは、普段は作られないことが多いかもしれませんが、プロジェクトの効率化や問題解決に大きな効果をもたらします。特に、チーム間の認識のズレを防ぎ、プロジェクトの進行をよりスムーズにするために、積極的にこれらのドキュメントの作成を検討することをお勧めします。
また、このようなドキュメントはどれも証跡的な意味合いも大きく、企業にとっては、リスク回避にも繋がり、かつ、後々振り返ったときにプロジェクトの進め方で大きなケーススタディにもなります。
少し手間はかかりますが、企業発展のためには重要なものなので、少しずつ取り入れることをお勧めします。
この情報は役に立ちましたか?
カテゴリー: