結論から言えば、非常に似ている…というのは10年以上前から思っているのだけど、アニメ制作会社の「進行」が具体的にどんな仕事をこなしているのかわからなかったのだが、TVアニメ「SHIROBAKO」公式サイト を見るとよくわかる。というか、ソフトウェア開発のマネジメント（主にアジャイル開発のほう）で、どのようなプランニングと調節/折衝を行えばよいのかが、よく描かれている。
プランニング
何を作るのかが決まると、概略のスケジュールを立てる。スケジュールを立てるには、あらかじめ必要なタスクが必要になる。
ソフトウェア開発は複雑怪奇なのでプランニングがうまくいかないという話を昔からよく聞くが、実は、大まかな単位（要件定義、設計、実装、試験などの古来のウォーターフォール開発の工程）と関わる人はあまり変わらない。
だから、超概算見積もり的には、ざっくりと開発者の人数と人月を出してしまって、超概算のスケジュールを立てる。最初のプランにあうかどうかは分からないし、実際には合わない。しかし、プロジェクトが進めば「確実性が増す」ので、その都度プランを変えていく。
どちらのせよ、最初にタスクの総量の概算を出す必要がある。
変更に対応する
それぞれのメンバの思惑があって、ステークホルダー（利害関係者）があるので、横槍なり変更がはいる。
過度な変更を排除するのもマネジメント手法のひとつ（スクラムマスターの役割とか）だけど、やむ得ない変更の場合は、現在の進行を変える必要がでてくる。
現場の進行全体を止める必要はなく、進められる部分は勧めてしまう。いわゆるタスクを並行に動かして依存関係をチェックする。
大抵のマネージャはガントチャートにそれを求めてしまうが、変更しにくいガントチャートのソフトを使うことによって、現場の進行を変更できないというドツボにはまってしまう。なので、ガントチャートは過信せず、単なるチケットの羅列でもよい場合が多い。
残件を確認する
全てのタスクをこなしたら終了になるとすれば、すべてのタスクがどれほどあるのか？を知っておかないといけない。
トラブルが発生したら、タスクが増える。何かを整理したらタスクが減る。プロジェクト開始時に未知だった部分も、プロジェクトが進むと既知になってくる。タスクを抽出して、消化したタスクを消していけば、残りのタスクが分かる。
そうすると、あとどれだけのタスクをこなせばプロジェクトが終わるのかが判明する。
なので、マネージャはあとどれだけ仕事をこなしたら、プロジェクトが終わるのか？をバーンダウンチャートなどを使いながら常に頭に入れておく必要がある。
合意形成
ソフトウェア開発において、顧客との合意形成（場合によってはメンバに対しても）することは、営業の範疇なのかマネジメントの範疇なのかが問われるけど、単純な契約書だけでは済まないものが、合意形成である。
理不尽な要求ははねのけるのだけど、どうしても受け入れざるを得ない要求変更というものがある。そこは、プロジェクト予算とか保険とかマージンとかで賄うものなのだけど（あるいは、工数単位で請求するとか）、納期が変わらないというパターンが一番面倒である。
これも、日本のソフトウェア開発の事情と、欧米の開発事情、中国や東南アジアでの開発事情もあるので、それぞれの文化における「合意形成」のラインを引いておく必要がある。こちらの常識はあちらでは通じないし、同時にあちらの常識をこちらに押し通してくる場合もある。
合意形成の失敗によって、被害をこうむりそうな場合、いくつかの対処のパターンがある。そう、対処が数パターンあることを覚えておくとよい。
- 違約金を払ってでも撤退する
- 自腹で、予算を変えても、変更を飲み込む
- 予算を変更せずに、できればスケジュール（納期）を変更する。
- 納期は変えずに、追加費用を請求する
- 未作成の部分と追加要求を交換する
- 変更要求を、納期後に飲み込む
- 変更要求を、受け付けない。
どのパターンを取ってもよいのだが、いちばんやってはいけないのは「変更要求をのみ込んで、予算も納期も変えない。機能も変えない」というパターンだ。これだと、いくらでも変更を突っ込まれてしまう。何かを詰め込めば、何がはみ出るというパターンに必ずしておく。
ひとまず、ざっと箇条書き的に。全話見たら、また追記しましょうか。
