何事にも最初に仕様が確定する事はありません。変更があって当然なのですが、モノには限度があります。変更には手間もお金も掛かるものですが、問題は変更を要請する側がそれを何処まで理解しているかです。

SOWという考え方

変更が有るのは当然ですが、何もかもが変動する前提では、仕事を始めることが出来ません。したがって、最初に何らかの枠組みを決めるわけです。それを、SOW、Scope Of Workと呼ぶことが有ります。システム開発もイベントの組立も、基本的にプロジェクトの企画と推進だと考えると、たぶん同じだと思います。

チェンジ・オーダーという考え方

最初に必要な要素を定義し、必要な資源を検討し、納期と手順を考えて仕様を決定する。

「イベントでそんなのできる訳無いだろ！」

変更が生じたときには、その変更内容を確認し、影響範囲を検討し、そもそも誰のオーダーで変更を行うのかを確定させてようやく、元の仕様に対するチェンジ・オーダーが成立します。

「だから、忙しくて、そんなのできる訳無いだろ！」

いえ、本来はやらなくちゃいけないんです。そうしないと、責任の所在が判らなくなるんです。誰かが最後に理不尽な泥をかぶる羽目になるんです。

システム開発と同じです。

「出し物がかわります」

よくある話です。特に新製品が絡む場合には、発表のタイミング、納期、そもそもいくつ確保できるのか。いろんな要素がからんで、最後まで決まらないのはよくある話です。

ただ、すべての段取りが出来ているのに、そこに何ら問題があるとは思えないのに、有る意志によって企画が変更になることがあります。

そ の瞬間、どれだけ反応出来るか、どういう反応が出来るかが腕の見せ所の一つでは有るのですが、それは正直本筋ではありません。ヤバそうな状況が伝わってく ると、それとなくそのために、ダブルスタンバイ、トリプルスタンバイしているわけです。費用が懸かるかとかは別の話ですが、そこで余計な手間がかかるのは 事実。結果としていかにスマートに、いかに何気なく、どこまで事態に対応できるか。本筋ではありませんが、プロフェッショナルの腕の見せ所では有ります。

プロも丸腰では勝負出来ない

どんなすばらしいマジックにも仕込みがあります。どんなすばらしい講演にもネタの仕込みがあります。どんなに面白い漫才にも段取りがあります。

そう、すべてには必要な期間 と必要な内容の仕込みが必要です。丸腰ではプロフェッショナルも仕事は出来ません。状況にもよりますが、本来は必要な資源だけを用意しておけばよい筈で す。その方が、無駄がありません。でも、あらゆる状況を想定した準備が必要になるかも知れません。それを踏まえて、何を何処まで用意できるか。最大限用意 出来るか。無駄を、リスクを最小限に出来るか。

９割を無駄にして、1割で結果を出す事があるかも知れません。或いは全部吐き出しても足りない事も有るかも知れません。そこの匙加減。

正解は無いのですが、非常事態に手持ちのネタで反応できたとき、しかもそれを目立たず、静かに、あたかも何も問題がなかったのように収拾出来たとき。コレがプロデューサーあるいはプロジェクト・マネージャーの真骨頂のような気がしています。

「あいつら、なんのために居るんだ？」
「コレって、何に使うの？要らないじゃん。」
「今回、結局なんにも問題起きなかったよね」

あなたの知らないところで、しかも知らせる必要もないところで、静かに、確実に、ヤバいところは潰してるんですよ。

誰がやってると思ってます？プロがやってるんです。

貧乏性

たまたまこのお題で殆ど書き終わった時点で、川上さんの仕様変更は必ず起きる！？というエントリーが殆ど同じことをシステム開発プロジェクトの側面から取り上げているのに気が付きました。いや、結局立場は違っても同じようなモノだというところでしょうか。

そこまで突っ張った現場ばかりだと疲れてしまいますし、もっと楽したいのは山々ですが、突っ張ってる割には段取りが悪かったり、社内の調整がへたくそだったり、あるいは貧乏性なんで、妙にいろんなモノを背負い込んだり。

自分で苦労を買って喜ぶ歳じゃ無いのをそろそろ自覚した方が良いんですよね。判ってるんですけど・・・ね。