「テスト工程を削れませんか」と言われた日 ― スチュワードシップはきれいごとではなかった

顧客からの「コスト削減のために、テスト工程を圧縮できないか」という相談。受け入れれば予算はきれいに収まり、機嫌も損ねません。でも、そのテストは過去に本番障害を何度も食い止めてきた工程でした——この記事では、私がこの場面でどう動いたかから始めて、PMBOK第7版の最初の原則「スチュワードシップ」が現場で何を意味するのかを考えます。きれいごとに見えるこの言葉、実は一番実務的な原則でした。

この記事でわかること

「短期の要求」と「長期の責任」がぶつかったとき、何を判断材料にするか
スチュワードシップの意味を、試験の定義と現場の感覚の両方から
学び始めの人が誤解しやすいところと、今日からの向き合い方

筆者はSIerで複数の案件を預かるPMです。PMPの学び直しの途中で「スチュワードシップ」という聞き慣れない言葉に立ち止まったところから、この記事を書いています。

先に言葉だけ一段落で。スチュワードシップ(stewardship)とは、預かったものを、責任を持って良い状態で次に渡す管理者の姿勢のことです。PMBOK第7版では、勤勉さ・誠実さ・コンプライアンスをもって、組織の内外(顧客やチーム、社会や環境まで)に責任ある行動をとることと説明され、12の原則の筆頭に置かれています。プロジェクトが本質的に「他人の大切なもの(予算・人・信頼)を一時的に預かる」営みだからです。

現場で直面した「コスト削減 vs 責任」
「言われた通りにやること」だと思っていた
PMBOKがこの原則を最初に置いた理由
私が続けている習慣
よくある質問(FAQ)
振り返って
関連記事

現場で直面した「コスト削減 vs 責任」

私自身が判断に迷った話を、ひとつ紹介させてください。

リーダーになりたての頃、ある基幹システムの開発案件で、顧客から「コスト削減のためにテスト工程を圧縮できないか」という相談を受けました。正直に言えば、受け入れるのが一番ラクです。短期的には予算内にきれいに収まりますし、顧客の機嫌も損ねません。当時の私も一瞬、「削っても大きな問題は出ないかもしれない」と考えかけました。

でも、圧縮対象のテストは、過去に本番障害を何度か食い止めてきた工程でした。ここを削れば、半年後に本番で問題が出るリスクが明らかに上がる。それが見えていながら「言われたから」で受け入れるのは、預かった責任を果たしていることになるのか。そこが引っかかったのです。

そこで私は、その場で「はい」とも「いいえ」とも言わず、リスクを数字で示す資料を用意しました。「この工程を削ると、想定される障害発生確率と、発生した場合の復旧コスト・信用毀損はこれくらいです」と、目先の削減額と並べて提示したのです。すると顧客の意思決定者は、「それなら今のテスト工程は維持しよう」と判断を変えました。

結果として、半年後に大きな障害は起きませんでした。そして何より、「この会社は目先の売上より、こちらの長期の利益を考えてくれる」と、顧客からの信頼はむしろ強まったのです。この一件で、スチュワードシップは体裁のいい理想論ではなく、信頼という一番割に合う資産を積み上げる実務スキルなのだと、身をもって知りました。

「言われた通りにやること」だと思っていた

正直に言うと、私はしばらく、スチュワードシップを「言われた通りに、きちんとやること」だと思い込んでいました。でも学ぶうちに、実際は逆だと分かってきます。

責任ある管理者だからこそ、顧客や上司の短期的な要求に対して、根拠を持って「それは避けたほうがいいと思います」と言える。この「責任ある異議」まで含めてスチュワードシップなんだ、と。

定義の文章では「誠実さ・勤勉さ」と抽象的に書かれていて、正直ピンときませんでした。自分の言葉に置き換えてやっと納得できたのは、「嫌われるのを恐れず、正しいと思うことを提案できるか」ということです。試験勉強をしている方は、「短期的な要求をそのまま受け入れる」選択肢は基本的に正解になりにくい、と頭の片隅に置いておくと迷いにくいと思います。

PMBOKがこの原則を最初に置いた理由

12の原則の筆頭がスチュワードシップなのは、飾りではありません。ここが崩れると、残りの11原則がどれだけ正しくても土台から傾くからです。「予算とスケジュールを守る」ことだけがゴールではなく、その判断が半年後・一年後に、誰へどんな影響を与えるかまで視野に入れる。学び始めのうちは、「目先だけでなく、長期の責任まで考える姿勢のことね」くらいの理解で十分です。