テスト工程を効率化しようと自動テストを導入し、実行時間は目に見えて短くなった。「成功だ」と思っていたら、リリースのサイクル全体はかえって遅くなっていた——私の苦い実体験です。この記事では、この「もぐら叩き」がなぜ起きたのかから始めて、PMBOK第7版の原則⑤「システム思考」へつなげます。
この記事でわかること
- 良かれと思った部分最適が、全体を悪化させる仕組み
- システム思考が言う「全体を俯瞰する」の意味
- ボトルネックの見誤りを防ぐ視点
筆者はSIerのPMです。PMPを学び直すなかで、この原則ほど過去の失敗を思い出させられたものはありません。その実感込みで書いています。
システム思考とは、プロジェクトを、バラバラの部品の集まりではなく、互いに影響し合う一つのシステムとして捉える見方のことです。ある工程を変えれば、影響は必ず別の工程に波及する。その「つながり」を俯瞰し、「部分を良くしたつもりが全体をどう動かすか」まで見ようとする姿勢です。木を見て森も見る、という感覚に近いかもしれません。
自動テストを増やしたら、全体が遅くなった
リーダーになって間もない頃、テスト工程を効率化しようと、システム全体に自動テストを導入したときの話です。ねらいは明確で、「手動テストの時間を減らせば、リリースは速くなるはず」。実際、テストの実行時間そのものは目に見えて短くなりました。当時の私は「成功だ」と思っていました。
ところが、しばらくすると別の問題が顔を出します。自動テストのケースが増えすぎて、仕様変更のたびにテストコードを直す手間が急増したのです。気づけば、そのメンテナンスにチームの時間が吸い取られ、リリースのサイクル全体としては、かえって遅くなっていました。
工程「単体」の指標(テスト実行時間)だけを見て改善したつもりが、システム「全体」のスループットを悪化させていた。典型的な部分最適の罠でした。この一件以来、私は改善策を打つ前に「これは他の工程に、どんな仕事を増やすか?」を必ず一度考えるようになりました。
「速くすれば全体も速くなる」の落とし穴
「この工程を速くすれば、全体も速くなる」——直感的にはもっともらしいのですが、これはよく外れます。全体の流れを決めているのは、たいてい一番遅い場所(ボトルネック)だからです。
ボトルネックでない工程をいくら速くしても、全体の速度は変わりません。それどころか、私のケースのように新たな負担を生むこともあります。「どこを速くするか」の前に「どこが全体を律速しているか」を見極める。ここを飛ばすと、努力の方向がまるごとズレてしまいます。
なぜ「つながり」で見る必要があるのか
プロジェクトは、工程・チーム・会社・スケジュールが複雑に絡み合っています。どれか一つを取り出して最適化すると、その負担がしわ寄せとして別の場所に移るだけ、ということがよくあります。全体のスループット(通しての流れ)で見ないと、「がんばったのに遅くなった」が起きてしまうのです。
以来、気をつけていること
- 改善策を打つ前に、「この変更は他工程に何を波及させるか」を一度想像する
- 「どこが全体のボトルネックか」を、感覚ではなく実績データで特定する
- 工程単体のKPIだけで良し悪しを判断しない
よくある質問(FAQ)
Q. システム思考と「複雑さ」の原則は何が違う?
システム思考は「つながりを俯瞰する見方」、複雑さの原則は「予測しづらい状況にどう対応するか」です。近い親戚ですが、システム思考は「視点」、複雑さは「対処」に軸足があります。
Q. 全体を見ようとすると、細部が疎かになりませんか?
細部を捨てるのではなく、「細部が全体にどうつながるか」を意識するのがシステム思考です。両方を行き来する感覚を持てると、判断がぶれにくくなります。
ここまでの整理
システム思考とは、部分の最適化に飛びつく前に、全体のつながりとボトルネックを俯瞰することでした。あなたが今打とうとしている改善策は、他の工程にどんな影響を与えるでしょうか? 一度、全体の流れを描いてから動くと、「もぐら叩き」を減らせます。
関連記事
- PMBOKとは?なぜ今あらためて学ぶのか ― この連載の入口から
- 「リーダーシップ」の原則:役職ではなく行動で発揮する ― 次に読むならこちら
- 「複雑さ」の原則:要素は単純なのに制御不能になる理由 ― システム思考と合わせて読みたい
コメント