プログラムには終わりがあります。ところが、終わり方を決めずに始めることが多く、結果としていつまでも終わらない状態になります。

構成プロジェクトはすべて完了しているのに、誰も「終了」と宣言しない。会議だけが続き、予算も少しずつ使われていく。こういう状態を避けるには、終わり方を先に決めておくことです。

■ 終わり方は3通り

図のとおり、完了・縮小・中止の3つです。重要なのは、どれも「終わらせる作業」が必要だということです。

特に③の中止は、「やめたのだから何もしなくていい」と思われがちですが、それは違います。使っている環境を止め、契約を整理し、関係者に伝える作業が残ります。放置すると、費用だけが払い続けられます。

■ 中止を決めやすくする準備

日本の組織では、中止の判断が特に難しいものです。ここまで使った費用と、関わった人の努力が、判断を鈍らせます。

だから、始めるときに止める条件を書いておきます。

この一文があると、中止が「誰かの失敗」ではなく「最初に決めたルールの適用」になります。判断する人の心理的な負担が、かなり違います。

■ 「縮小して終了」という選択

実務で最も現実的なのが、この②です。プログラムの一部は成果を出しているが、残りの構成要素は見込みが薄い。このとき、全部を続けるか全部やめるかの二択にする必要はありません。

• 成果の出ている部分は、運用に引き継いで維持する

• 見込みの薄い部分は、次年度以降の検討に回す（やめるとは言わない）

• プログラムとしては、ここまでの成果をもって終了とする

2つ目の書き方が大事です。「中止」と書くと社内で説明しにくくなりますが、「次期検討」なら、実際にそのとおりでもあります。状況が変われば、また必要になるかもしれません。

■ 終了時に必ずやる5つ

図の表のとおりです。このうち、特に抜けやすい2つを補足します。

運用への引き継ぎ。プログラムが終わると、チームは解散します。そのあと、システムに不具合が出たら誰が見るのか。改修したいときはどこに言うのか。これを決めずに解散すると、数か月後に困ります。

決めることは3つだけです。問い合わせの窓口、改修の依頼経路、監視や定期作業の担当。紙1枚にして配ります。

学びの記録。想定と実績の差と、その理由。これを残すかどうかで、次のプログラムの精度が変わります。

3行目まで書いて初めて、次に活きます。

■ 終わりを宣言する

最後に、終了を明確に伝えます。運営委員会で報告し、関係者にメールを送り、会議体を解散します。

地味ですが、これをやらないと、半年後も旧の窓口に依頼が届き続けます。そして、その依頼を受ける人がいない状態になります。

■ まとめ

プログラムの終わり方は完了・縮小・中止の3通り。中止しやすくするために、始めるときに止める条件を書いておく。そして終了時には、成果の測定・運用への引き継ぎ・資産の整理・学びの記録・周知の5つを行う。

いま関わっているプログラムに、「どうなったら止めるか」が書かれているか確かめてみてください。なければ、次のゲートで決めておく価値があります。