テーラリングのあれこれ

テーラリングとは

• プロジェクトは、組織の標準プロセス群を基に、プロジェクトの定義されたプロセスを生成します。このプロセスを調整することをテーラリングといいます。本来は「プロセスの調整」のことですが、納期・コストの制約により「プロセスの省略」することが多く、「テーラリング＝プロセスの省略」と勘違いされがちです。
• テーラリングは、定義されたプロセスの実装だけでなく、調整も支援します。

テーラリングにおける考慮事項

• システム再構築の際、現行システムがあるために上流工程を省略するといったテーラリングは、リスクを高める恐れがあります。
• ソフトウェア開発では、プロジェクトごとに事情が異なるため、計画書の項目やテンプレートをプロジェクトの特性に合わせたカスタマイズが重要です。

合理的なテーラリングのコツ

• 標準プロセスを理解する：標準プロセス群にはそれぞれ目的があり、安易に省略することは危険です。まず、組織の標準プロセス群を理解し、プロジェクトの目標や制約に合わせて、どの部分を調整する必要があるかを検討します。

• リスクを考慮する：上流工程の省略など、安易なテーラリングは手戻りや品質低下を招く恐れがあるため、リスクを十分に考慮する必要があります。

• プロジェクトの特性を考慮する：プロジェクトの規模、開発期間、技術的な複雑さ、チームの経験などを考慮して、適切なレベルのプロセスを適用します。

• 関係者と合意する：テーラリングの方針や内容について、プロジェクトメンバーや関係者と十分に合意し、共通認識を持つことが重要です. 特に、顧客との合意が曖昧なまま進めると、後で問題が発生する恐れがあります。 「どういう目的・理由で、どういうプロセスを調整するのか、その場合のリスクおよびそのリスク対策はどうするのか」といった内容をステークスホルダーと合意し、ドキュメントに残す ことが望ましいです。

• 段階的な見積もり：プロジェクトの進行段階に応じて、見積もりを多段階化することで、予算超過や契約上のトラブルを回避できます。

• 仕様変更ルールを明確化：仕様変更に対する処置を契約上明確化しておくことで、後々のトラブルを避けることができます。

• 品質保証を考慮する：再構築プロジェクトでは、新規開発に比べて品質保証が容易と思われがちですが、実際には各工程で品質保証の施策を行い、品質を積み上げる必要があります。現行システムを踏襲する部分については、設計ドキュメントに明記し、レビュー・承認を責任をもって行うことが重要です。

• 段階的に導入する: 一度に全てを変更するのではなく、最も効果的な変更から実施すると良いでしょう。

• 柔軟な対応: システム開発には変更への柔軟な適応が求められます。

テーラリングの注意点

• 計画書を軽視しない：計画書を作成しても意味がない、すぐに変更になるから面倒だといった理由で計画書を作成しないと、プロジェクトは悪い方向へ進む可能性があります。計画書は、状況に応じて見直しをかけることで、プロジェクトを成功に導くための有効なツールになります。
• マニュアル人間にならない：プロセスは重要ですが、マニュアルに頼りすぎず、自分の頭で考えて行動することが大切です。

これらの情報を参考に、プロジェクトの状況や目的に合わせて、合理的なテーラリングを行うことが重要です。