短い答えは、「はい、そうすべきです」！優れた業務記述書（SOW）は、あなたのストレス、時間、コストを大幅に削減するかもしれません。試してみる価値はありそうですよね？このブログでは、効果的な作業指示書の書き方の基本を説明します。また、この文書の最も重要な利点についても説明します。その前に、SOWとは何か、プロジェクトマネジメントのプロセスにおける位置づけについて説明しよう。
プロジェクトマネジメントにおける作業記述書とは何か？
プロジェクトマネジメント知識体系ガイド』では、プロジェクトの作業記述書を定義している。 プロジェクトによって提供される製品、サービス、または結果についての説明として (出典：PMBOK®ガイド第5版）。
基本的には プロジェクトのさまざまな側面を概説した文書を含む：
- ゴール
- 仕事の範囲
- スケジュールと期日、
- 成功の基準と定義
- 支払詳細
作業指示書は、すべてのプロジェクト利害関係者が署名する必要があり、多くの場合、プロジェクト契約の一部となる。
作業指示書（Statement of Work）と作業範囲（Scope of Work）の違いについて疑問に思うかもしれない。前者は、通常、プロジェクトの範囲を含む文書の名前です。スコープ・オブ・ワーク（Scope of Work）」とは、通常、プロジェクトを遂行するために必要な作業を指します。スコープを文書化することは、プロジェクトを効果的に進めるために不可欠な要素である。 プロジェクトスコープ管理.そのためには、スコープを視覚化できる、いわゆるWBS（Work Breakdown Structure）を作成すればよい。また、WBSをStatement of Workに追加するのも良いアイデアでしょう。
プロジェクトマネジメント業務記述書を作成する主なメリット
このブログ記事の冒頭で、優れたワーク・ステートメントがあれば、神経とコストを大幅に節約できると述べた。社外のステークホルダーと仕事をしていて、プロジェクトがかなり複雑な場合は特にそうだ。あなたがやるべき仕事とやるべきでない仕事に関する単一の真実の情報源を持つことは、救いの神になる可能性があります。作業指示書のおかげで、以下のことが可能になる：
- 期待値の管理 - SOWは、プロジェクトの範囲内と範囲外を明確に概説する必要があります。これはプロジェクトチームにとっても有益ですが、クライアントの期待を管理することもできます。プロジェクトに プロジェクトの透明性すべての関係者が、いつ何が起こるかを知っている。
- 決意 スケジュールの都合 チームが行う仕事を明確に定義しても、紛争や誤解が生じることがあります。そのような事態を解決するために「作業指示書（Statement of Work）」があります！当然ながら、SOWは正確で詳細なものであるべきであり、あなたやクライアントが何かを明確にする必要があるときに役立つものでなければなりません。
- スコープクリープを避ける スコープクリーププロジェクトのスコープが制御不能に拡大することは、作業が明確に定義されていない場合に起こりやすい。作業指示書があれば、関係者全員が、何をしなければならないかだけでなく、いつまでに何を納品し、何が「最終成果物」なのかを知ることができる。もちろん、プロジェクトに調整が必要になったときのために、変更管理プロセスも整備しておく必要がある。
[/vc_column_text]。
プロジェクトマネジメントにおける「作業指示書」には何を含めるべきか？
プロジェクトは千差万別であるため、提供するプロジェクトの性質によっては、企業によって使用する業務記述書が大きく異なる可能性があることに留意する必要がある。しかし、一般的にSOWに含まれる要素はいくつかあります。ひとつずつ見ていきましょう：
プロジェクト概要
職務記述書の序章では、プロジェクトの概要と関係者の概要を説明します。プロジェクトの要約は通常、プロジェクトの目的とビジョンを説明する場所です。このプロジェクトはどのようなものなのか？それを提供するビジネス上の目的は何か？最終製品はどのような問題を解決するのか？
これらの要素をSOWの冒頭で説明することで、文書全体の方向性を定めることができ、また、特定の成果物をスコープに含めるか否かの根拠にもなります。
プロジェクトの範囲
職務記述書のこの部分で、あなたは2つの質問に答えようとしている：
- 何が届くのか？
- 何が届かないのか？
当然のことながら、誤解を招く恐れがあるため、このセクションはあまり曖昧にしてはならない。一方で、例えばこの時点ですべてのタスクの概要を説明できないかもしれない。その場合は大丈夫です。重要なのは、あなたと他のステークホルダーが合意したスコープを正確に反映することです。
スコープの一般的な概要から、プロジェクトチームが行う必要のある特定のステップやタスクを列挙することができます。成果物についても忘れずに具体的に。以下のような曖昧な表現は避けることが重要です。 あれもこれも。 将来、クライアントとの交渉に役立てたいのであれば、「業務内容説明書」は可能な限り明確であるべきだ。
また、SOWにネガティブ・スコープを含めるのも良いアイデアです。これは、クライアントと話し合った、あるいは競合他社製品に存在するが、最終的にはスコープに入れないことで合意したプロジェクトの要素について話しているのです。
スケジュールとマイルストーン
プロジェクトのさまざまなステップを説明する際に、次のような内容を含めるとよいだろう。 プロジェクトのマイルストーン と期日も指定します。プロジェクトによっては納期が決まっているものもあれば、そうでないものもあるため、必ずしも正確な履行期間を指定できるとは限りません。それでも、少なくともSOWでプロジェクトのさまざまなフェーズと、それらにかかるおおよその時間を伝えることは有益です。
受け入れ基準、成功の定義
業務記述書には正確な言葉を使い、プロジェクトを正確に示す必要があることはすでに強調した。SOWに含めるべき基準や受け入れ基準についても同様です。
あなたのチームがクライアントのためにモバイルアプリケーションを開発しているとします。SOWにアプリの機能を記述するだけでは不十分です。もし、あなたのアプリがほとんどのモバイルデバイスで仕様通りに動作しても、すべてのデバイスで動作しないとしたらどうでしょうか？もしあなたとクライアントが、アプリが目指しているプラットフォームのリストについて合意していなければ、その仕事が成功裏に完了したと主張することは難しいでしょう。だからこそ、業界特有の基準を盛り込むことが重要なのだ。ソフトウェア開発プロジェクトの場合、以下のような詳細が含まれます：
- テスト（製品はどのようにテストされるのか？）
- デバイス、ブラウザ、オペレーティング・システム。
- 製品のダウンタイムとメンテナンス、
- セキュリティ基準など
また、SOW文書の中でクライアントの責任について言及することもできる。例えば、クライアントは資産を提供する必要があるのか？
最後に、プロジェクトの成功の定義を記録する。クライアントは、成功するプロジェクトがどのようなものであることを期待しているのか？プロジェクトが成功したかどうかを判断する責任者は誰か？
価格と支払い条件
予算に関する情報は、SOWの不可欠な部分です。プロジェクトの費用を提示できるのであれば、それを書き出してください。タイム＆マテリアル・ベースで仕事をしている場合、または他の取り決めがある場合は、その条件を明確に説明する。ライセンス料、機材費、出張費など、プロジェクトの追加費用も忘れずに。
支払いスケジュールもSOWに明記されるべきである。支払いはいつになるのか？分割払いはあるのか？プロジェクトを担当する企業としては、SOWのどの部分にも疑問の余地を残さないことが得策であり、当然のことながら、このセクションも例外ではない。
業務記述書（Statement of Work）に必要なすべての詳細を集めましたか？関係者全員がこの文書に精通していることを確認し、署名をもらってください。
プロジェクト管理における優れたSOWで、企業のコストと手間を大幅に削減する。
よく練られた職務記述書の価値は、もうお分かりでしょう。あなたがブティックエージェンシーを経営しているにせよ、大きな組織で働いているにせよ、それはあなたのチームのプロジェクト管理プロセスの有用な要素です。このガイドを社内のプロジェクトマネージャーと共有し、それぞれのプロジェクトでSOW文書を作成するよう促してください。
Teamdeckブログでは、プロジェクト管理ガイドをよくシェアしています。ここではあなたとあなたのチームメイトが役に立つかもしれないものをいくつか紹介します：
- ガイド プロジェクトコスト追跡
- について知っておくべきすべてのこと プロジェクト・ステータス・レポート
- ヒント 効果的な会議運営
- などなど！
