【テンプレート公開】システム開発のドキュメントの種類| ベトナムとのオフショア開発で良く使うドキュメントは？
アプリやWebの開発チームでは、スケジュールの可視化とコミュニケーションの整理にドキュメントの運用は欠かせません。しかし、ドキュメント管理についてこんな悩みをお持ちの方も多いのではないでしょうか。
・最低限どんなドキュメントがあると良いのか？テンプレートは？
・言語が違うチームの場合、どのようにドキュメント運用すれば良い？
・ドキュメント運用におすすめのツールは？
上記のような疑問や不安にお応えしていきます。
今回の記事を読めばこれがわかる！
☑️ プロジェクトの管理に必要な基本のドキュメント・テンプレート ☑️ 言語が違うチームの場合のドキュメント管理・運用 ☑️ おすすめのドキュメント運用ツール
この記事を書いている私は、、
ベトナムオフショア拠点で5年間、日本のクライアントとベトナムの開発チームとの間に立つ役割を担当してきました。関わったプロジェクトは大小7案件以上、言語が違うリモートのチームで悩みながらも、トライアンドエラーを重ねてきた経験があります。
目次
システム開発チームとの連携でよく使うドキュメント3選・テンプレート
チームのサイズや工程などによって必要なドキュメントも異なりますが、
・10〜20名程度のチーム
・ベトナムの開発チームと日本のクライアントとの間に立つ立場
で私自身がよく使うドキュメントをご紹介します。
WBS
WBSとは
WBSとは「Work Breakdown Structure(作業分解構造図)」の略で、プロジェクト全体を小さな作業に分解した構成図のことです。
目的
WBSを作成する目的は、プロジェクト完了までのタスクを抜け漏れなく洗い出し、タスクの進捗状況やスケジュールを管理することです。
アプリやWebの開発において、下流工程ではエンジニアの実装タスクやテストなど、機能ごとに細かくタスク分解をして担当者を決め、計画を立てていきます。
一方、上流工程ではプロダクト開発全体の把握をする必要があるため、実装フェーズ・テスト・デザイン・仕様策定・セールスなど少し粗い粒度ですべての工程を盛り込んだWBSを作成しています。
テンプレート
私が実際に上流工程で使用しているテンプレートはこちらです。
様々なフォーマットを試しましたが、左側にタスク一覧・担当者・期限日、右側にタイムラインが表示されるこのガントチャートのフォーマットが一番使いやすいと感じます。
QAシート
QAシートとは
QAシートとは、プロダクトの仕様に関する質問と回答のやりとりを記録しておくドキュメントのことです。
目的
質問と回答を記録し、後で振り返ることができるようにするためです。特にリモートのチームでは、チャットやメールなどで質問や確認が日々大量に行われると思います。そうすると、仕様がどのようにして決まったかを後から振り返りたい時、ログをたどるのも一苦労でしょう。
ドキュメントに質問と回答を記録しておくことで、認識齟齬を防ぐことができます。
テンプレート
オフショア開発チームでは必要に応じて翻訳欄を入れたり、英語で運用することもあります。それについては後述します。
画面設計書
画面設計書とは
アプリやWebの開発で、
・どの画面のどの要素にどんな機能をもたせるのか
・どこからどう遷移させるのか
といった仕様を詳細に記載したもののことです。
目的
手戻りを防ぎ、品質の高いプロダクトを作り上げるためのドキュメントです。
開発者は画面設計書を見て具体的なイメージを持ってコードを書き、また品質管理のQCは画面設計書に書いてあることを正だと思ってプロダクトをテストします。
きちんとドキュメントに起こした仕様を共通認識として持つことによって、イメージに近いプロダクトを作ることができます。
※画面設計書が必要な理由について、
【徹底解説】アジャイル開発に設計書は不要か？｜開発管理者が語る設計書の役割と運用・管理方法で徹底解説しております。ご参照ください！
テンプレート
画面設計書のテンプレートや、書き方・活用方法については
【わかりやすい】ソフトウェア開発における画面設計書！グローバル環境でも使える画面設計書の書き方、サンプル、活用方法を公開で解説していますので、ぜひご覧ください！
言語が違うチームの場合のドキュメント管理・運用
ドキュメントは英語が基本
言語が違うチームとの開発プロジェクトでは、基本的にはお互いの共通言語(英語)でドキュメント運用するのが良いでしょう。
日本語で書いたものを現地の言葉に翻訳してもらうことも可能ですが、その分時間や管理の手間がかかってしまいます。
また、お互いに理解できる簡潔な英語で記載することで、翻訳過程での認識齟齬も減らせると思っています。
以上の理由から、ベトナムのチームと共有するドキュメントは英語で作成することがほとんどです。
英語での運用が難しい場合は運用ルールを明確に
とはいえ、英語で複雑な仕様を伝えるのは難しい…という場面もあると思います。そのような場合は、翻訳版を作って運用していっても良いと思います。
ただ、英語一つのドキュメントよりも関わる人・ドキュメントの数が増えますので、
「誰がどのタイミングで更新し、それを翻訳後どう開発チームに伝えるのか」
のフローは明確に定める必要があると思います。
ドキュメント作成・管理におすすめのツール
オフショア開発の現場で、実際によく使うツールをご紹介します。最終的には、メンバーが慣れていて使いやすいものを選ぶのが一番です。
Googleスプレッドシート
様々なツールを試しましたが、やはり使い勝手が良く、最終的に戻ってくるのがスプレッドシートです。
メリット
Googleアカウントを作成すれば誰でも無料で利用可能。また、様々なアドオンがあり、自分の好きなようにカスタマイズしやすいのも魅力です。
デメリット
シートを作りすぎて、リンクのありかが分からなくなると管理が大変です。同じドライブフォルダに格納したり、リンク集を作ったりして一箇所にまとめておくようにすると良いでしょう。
draw.io
draw.ioは文章で説明しきれないような画面の遷移や、ワークフローなどを表現する図を作成するのに便利なツールです。
メリット
こちらも無料、ブラウザで利用可能。エクセルやパワーポイントよりも手軽に作図ができ、Googleドライブと連携させて保存もできます。
デメリット
図を作成したり、閲覧する際に少しレスポンスが遅く感じることがあります。
Backlog
Backlogはプロジェクト管理ツールで、特に開発チームのタスク管理を行うのによく使います。
メリット
タスクを起票し期限日を設定すると自動的にガントチャートを生成してくれるので、スケジュールの可視化が容易です。タスクの更新時やコメント時にはメール通知を飛ばすことができます。
また、Wikiに画像やアカウント情報などを整理して置いておくこともできます。
デメリット
無料プランでは、ユーザ数が10名まで、ガントチャートが使えないなどの制限があり、すべての機能を使うには有料プランに入る必要があります。
また、「課題」としてチケットを一つひとつ作成する必要があるので、スプレッドシートのように一気に入力・更新できない点が少し手間だと感じます。
実際のプロジェクトでは、
・最初のタスク洗い出し・WBS作成は編集しやすいスプレッドシートで
・その後のタスク管理は通知機能があるBacklogで
という風にスプレッドシートとBacklogを併用することが多いです。
まとめ
オフショア開発現場での経験から、よく使うドキュメントの種類やテンプレート、運用方法やツールをまとめました。
アプリやWeb開発プロジェクトでのドキュメント管理や、オフショア先との連携方法に悩んでいる方の参考になれば幸いです。
Enlytについて
株式会社Enlytはベトナムに開発拠点SupremeTechを持ち、これまで50以上の開発プロジェクトを行ってきました。ベトナムと日本のグローバルなチームで、数多くのプロジェクトを成功に導いてきました。
Enlytのオフショア開発は、アジャイル・スクラム開発を採用しています。コミュニケーションの透明化を意識してそれぞれの役割で責任の範囲を明確化しています。クライアントも含めたワンチームとして、フラットな関係で開発を進めることができます。
お客様の納得のいくまで、共に開発させていただき、アイデアを最高のかたちにサービス化いたします。
オフショア開発についてのお悩みやご相談がございましたら、下記ボタンより気軽にお問合せください！
