数人月の小さな保守案件に、大規模案件と同じ多段階レビューをそのまま回したら、手続きだけで工数がふくらみ、品質のための仕組みがスケジュールを苦しめ始めた——完全な本末転倒を、私は実際にやりました。この記事では、その顛末から始めて、PMBOK第7版の原則⑦「テーラリング」が言う「標準を調整して使う」の意味を整理します。
この記事でわかること
- 標準の遵守が目的化すると起きること
- テーラリングの原則が言う「標準を調整して使う」の意味
- 案件の規模・リスクに応じてプロセスを選ぶ判断軸
筆者はSIerのPMです。標準プロセスと小さな案件の板挟みを何度も経験してきた立場から、PMPの学び直しで再会したこの原則について書きます。
テーラリング(tailoring)とは、標準プロセスやテンプレートを、その案件の規模・リスク・組織文化に合わせて調整し、「使えるもの」にすることです。語源は洋服の仕立て直し。既製の型紙(標準)は便利ですが、体に合わなければ着心地は悪い。目的に合わせて丈を詰めたり袖を足したりする、その調整こそがテーラリングです。
重厚なレビューが、小さな案件を圧迫した
リーダーに成り立ての頃の話です。全社標準として、しっかりしたレビュープロセスが定められている職場でした。多段階のレビューと承認、詳細なチェックリスト。大規模案件では、この重厚さが品質を支えていて、頼もしい仕組みです。
問題は、それを小規模な保守案件にもそのまま適用したときに起きました。数人月の小さな案件に、大規模案件と同じレビュー階層を回したのです。すると、レビューと承認の手続きだけで工数がふくらみ、気づけばレビュー工数がプロジェクト本体の工数を圧迫していました。品質のための仕組みが、逆にスケジュールを苦しめる。完全な本末転倒でした。
このあと、私は「案件の規模とリスクに応じて、レビュー階層を簡略化してよい」というルールを整備しました。たとえば影響範囲の小さい保守なら、多段階レビューを一段に減らす。大事なのは、「何のためのレビューか」に立ち返ること。目的(品質確保・リスク低減)が達成できるなら、手続きは軽くしていい。以降は案件の性質に応じてプロセスを選べるようになり、無駄な疲弊が消えました。
標準を守ることこそ正義だと思っていた
かつての私は、「標準を守ること」そのものが正しさだと感じていました。標準から外れるのは手抜き、くらいの感覚すらありました。
でも、標準の遵守が目的化すると、本来のねらい(品質を保つ、リスクを下げる)が置き去りになります。分厚い手続きを回すことに満足して、肝心の品質は上がっていない、ということも起こる。標準は「目的」ではなく「手段」。「守れているか」ではなく「役に立っているか」で見るべきでした。試験でも、「標準を杓子定規に適用する」選択肢はまず選ばれません。それだけ覚えておくと選択肢が絞れます。
なぜ標準は「そのまま」だと合わないのか
標準プロセスは、多くの失敗から生まれた知恵の結晶なので、基本は尊重すべきものです。ただ、標準は「平均的な案件」を想定して作られているため、規模やリスクが違う案件にそのまま当てると、過剰にも過小にもなります。「守ること」と「役立てること」は違う。そのギャップを埋めるのがテーラリングです。
私が続けている工夫
- 標準を適用する前に、その案件の規模とリスクを一度評価する
- 「何のためのプロセスか」に立ち返って、過不足を調整する
- テーラリングの判断を個人の勘に頼らず、組織のルールとして明文化する
よくある質問(FAQ)
Q. テーラリングは、標準を無視していい理由になりませんか?
なりません。テーラリングは「目的に照らして調整する」ことで、「都合よく省く」ことではありません。なぜ調整したのかを説明できることがセットです。
Q. どこまで調整していいか、基準がわかりません。
「その手続きを外すと、どんなリスクが上がるか」を考えるのが基準です。リスクが小さければ簡略化、大きければ維持。目的から逆算すると判断しやすくなります。
振り返って
テーラリングとは、標準を守り抜くことではなく、目的に合わせて調整し、使える形に仕立て直すことでした。あなたが今回している手続きは、その案件にとって「ちょうどいい」サイズでしょうか? 一度「何のためか」に立ち返ると、削れるものが見えてきます。
関連記事
- PMBOKとは?なぜ今あらためて学ぶのか ― この連載の入口から
- 「品質」の原則:バグゼロでも満足されない理由 ― 次に読むならこちら
- 「システム思考」の原則:部分最適が全体を壊すとき ― 全体を見て調整する視点
コメント