ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。
一次対応
とにもかくにもPJTに投入されて最初にやったこと。
コミュニケーションルールをみんなで確認して、守ってもらうようにした
誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、
もうぐっちゃぐちゃになっていた。
- ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。
- （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。）
- ただし、ディレクターからメンバーに指示を出しているところは、公開チャットでやる。
めんどくさいように見えるが、
- エンジニアにとっては勝手に仕様追加されて納期減らされるみたいなことがされないように、ディレクターが全部交渉してくれるといういい感じに使えるやつなのだ。
- エンジニアにとって、ディレクターはリソースを確保して要件を減らしてくれる便利なやつなので、積極的に盾として、また剣として使ってほしい。
- お客さん側にとっては、自分の言った仕様がエンジニアに全然伝わってない…というリスクを避けるかっこうのエサなのだ。「ディレクターには言ったんだけど」となすりつけていい。
- また「よくわかんないけど、こういう感じにいい感じにしといて」みたいなのをエンジニアに言うとわけわからんものが出てくる可能性が超高いが、ディレクターに頼めばまさにいい感じになってくる確率が上がるので、積極的に意見を言ってほしい。
そんな感じで伝えつつ、ときに直接やった人がいたら裏で
「直接指示するなー！頼むから私を通してって言ったでしょ？もちろん私が忙しいから、配慮して指示をかわりに出してくれてるとは分かってる。分かってるけど、あなたが知らないけど別件で同じ個所の修正とかがあったりするんだよ、、、頼むからディレクター通してくれっておだてなだめつ怒りつつお願いする。
これまでの要件や仕様についてはドキュメントにまとめ、タスクも全部拾い集めていく作業をした
開発は海の向こうの子会社さんだったこともあって、開発者もいまいち仕様を把握していないっぽい。
ダメなことに発注側で指示を出す人が複数いて、しかも五月雨式に指示をパラパラ出しまくっていたので、どこにどんな仕様がどうまとまっているか全く整理されてなかった。
- 必要なアカウントや資料、仕様書がてんでばらばらの位置にあったので、これはディレクターの独断と偏見でこれまでのログを追って極力資料を収集した。
- 収集したものを、これもディレクターの独断と偏見でドキュメントにまとめた。
- みんなが見る公開チャットには、その収集した場所のアドレスを貼り、概要だけにし詳細は収集場所へまとめた。
- ぱっと見たいものや、ぱっとアクセスしたいものだけを載せることに。不要なものを削除した。
- リリース1週間前だが課題管理表を作って、そこに質問だろうが確認事項だろうがとにかく集めた。要望レベルも可。要望を具体的な開発者への指示に落とし込むところは、SEに丸投げした。
協力体制の構築
ディレクター一人では、何もできない。
ディレクターはみんなの嫌な奴でもあると同時に、みんなが「ディレクターにとりあえずなげときゃいーや」っていう優秀な方向指示器であれるといいと思う。
その、専門分野のプロフェッショナル達がするまでもないような細かなこと、面倒なことはディレクターが面倒を見る。そうやってエンジニアとディレクター、それから発注者がお互いWin-Winな関係を築ければいいと思ってる。
- コミュニケーションルールを決めたが、結局はディレクターからキーマン一人ひとりに声をかけていって「正直私一人はスキルも無いし、何もできません、○○という専門分野についてはあなたしか私は頼れる人がいない。なんとか力になってもらえないか。」とベタにお願いしたのが、結局一番効果的だった
- 「しゃーねーなー、じゃあちょっと助けてやるわ」と少しでも思ってくれたら、今まで受け身だったメンバーでも、積極的にプロジェクトや、仕様についてコミットしてくれるようになる。こうなるとプロダクト全体のレベルが上がるサイクルに入ってくるように感じた
コアメンバーを減らした
船頭多くして、船山に登る。
- 基本系は、エンジニア‐ディレクター‐発注者（仕様決定者）の3人になるように、組織を編成しなおす。つまり、多すぎるメンバーのうちコアメンバーを選び出し、エンジニアは開発についてのトップになってまとめてもらい、発注者はいろいろな仕様をまとめてもらう役割を持ってもらう。
- エンジニアが複数いても、ディレクターは一人のエンジニアにしか話をしない。エンジニアは責任をもって他のエンジニアと開発について調整をし、発注者は責任を持って発注側の要望や要件をまとめ調整してもらう。
- 決めたその一人以外の人からディレクターに意見があった場合は、ディレクターは「トップと話をして、トップから報告を上げて」っということを徹底する。
- ディレクターを飛び超えて、エンジニアと発注者が直接やりとりするのは原則禁止。
二次対応
一次対応はそもそも、PJTが混乱しまくっていたのを、その後きちんと業務が回るようにするためにとる方策。
なので、コミュニケーションルールがきちんと守られるようになって、コアメンバーが3-4人ぐらいに減り、ドキュメントがひとところにまとまり、課題が管理されるようになったら、いよいよ納品物をリリースに向けて軟着陸すべく二次対応。
仕様書（テスト仕様書）の作成
仕様がもはや誰も分からなかったので、ディレクターも手を動かしつつ読み込んだドキュメントを思い起こしつつ、サービスフローを書いたり、やりとりで増えた/変更になった仕様をドキュメントに落としたりしながら、
「これができたら正常な挙動（またはエラー制御）」についてまとめていく。
最終的にはこれが仕様書みたいになった。
ステークホルダー（特に決裁権のある人たち）にコンタクトを取り、必要要件や機能を減らし納期を伸ばすように交渉した
定番の手だがディレクターの打ち手で一番即効性がありかつ、効果的なもの。
「納品後に対応しますから」などで、納品時に必要な要件と機能をギリギリまで減らして（制作物を小さくして）、かつスケジュールを交渉。
スケジュールだけは一次対応に含めていいかもしれない。
本当は一次対応時に出来ればいいのだが、ディレクターが仕様分かっていないとそもそも「この機能は削ってもいいですか」っという交渉が出来ないし、またお客さんも「じゃその機能はいらないわ」って判断もできないので、二次対応にせざるを得ない。
最終決裁者、つまり「ローンチ時の利用者（または、その代理となる人）」を明確にして、最終調整
「最終的に、オペレートするのは誰か（誰が管理者となるのか/運用するのか）」「最終的に、誰が使うのか（エンドユーザ）、またはその気持ちを代弁するのは誰か」を明確にし、その人と細部をツメる。
- 外野が「これはやっぱり要るんじゃないか」「ここはユーザーにとって云々」とかワイワイ言ってくることもあると思うが、ディレクター権限でぶった切る。
- ディレクターが指示も交渉もやりつつ仕様を決定するのは、頭が回りきらなくてキツい上、ダブルチェックがかからないので、できればエンドユーザと運用側の決裁者はディレクター以外の人に置いて、その人とディレクター、ディレクターと開発がそれぞれ調整するようにしたい。
- ここで荒れるとしゃれにならないので、決裁者はほどよきリアリストで、切るものをちゃんと切れる判断力のある人をアサインすることを強くオススメしたい。
可能であれば開発側の稼働日を増やし、ディレクターは手駒を増やす
プロジェクトメンバー全員が疲弊するので休日出勤とかはしたくない主義だが、可能であれば開発側は稼働日を増やした方がいい。
ディレクター側はこのころになると手を動かすシーンが増えてくるので、信頼出来て小回りがきき、細かいテストなどをしてくれる手駒を持っておくとぐっとラクになる。
クリティカルパスの確認
今回怠って痛い目に合ったが、特にアプリの審査まで10日かかるなど、「そもそも絶対に待たないといけない日数」が無いかどうかチェックを。
このタイミングでクリティカルパスが通らないと即死する。
- 「審査系」「承認系」「確認に○○日かかる」系のものは、中途半端でも出しておいて通すだけ通した方が良いかもしれない。
- あと、こういうのの確認のとき、バッファ無しの最少日数で言ってくる人がいたりするので、見極めと自分でも確認をキッチリする。自分の中で内部バッファを1-2日、場合によっては3日ぐらい持つのを忘れずに。
- 見落としがちなのは「デプロイがサクッと終わらない」系。ほんっとーーに、本番稼働までに必要なものを洗い出すのを忘れずに。
デプロイについては、デプロイそのものの練習が複数回行えるなら、それに越したことはない。
- エンジニアさん曰く、機能を小分けにして継続的にアップしていると、デプロイ周りのモタモタは結構防げる、とのこと
- とにかく環境を早く作ってもらう
- 環境が出来たらデプロイの仕組みを作る
- 定期的なレビュー時やテスト時に何度もデプロイして、デプロイの経験を積んでおく
納品条件の調整
納品前にありがちなドタバタは、
- 開発は出来ているけど、デプロイ出来ない・デプロイ先が決まっていないとか、インフラに関わるような部分のモタモタ
- リリースに必要なプレスリリースが手配出来ていない、みたいな開発の外側のゴタゴタ
- 開発は終わっているが、初期にデータをうん千件セットしないといけないなど、運用につながる不手際
クリティカルパスの確認とも重複するが、開発終わったあとの動き（デプロイがサクっと出来るのかどうか、つまりデプロイに日数をカウントしないといけないかどうか）は、忘れず確認すること。
それから、3のように、本番稼働までに必要データが無いと稼働出来ない場合があったりもするので、納品条件、つまりリリース時に必要な機能に加えて、どういう状態となってはじめて「納品」と言うのかをよく確認し、調整しておくこと。
あとはできればスケジュールには余裕を
1-2日前に終わって余裕をふかしてテストするぐらいがよい。肝に銘じよう
【個人的なオススメ】無事リリースできたら、クロージングミーティングを実施
最後に。炎上案件はその名の通り、メンバーごと焼きつくし灰にしてしまうことも少なくない。
キックオフミーティングがあるのと同じように、クロージングミーティングを実施しよう。
キックオフは「今からこういうことをしていきます」というミーティングだが、クロージングミーティングは「今こういうことをしました（またはしたかったけれど出来ませんでした）」というミーティング。
イメージとしてはゲームのResult画面みたいな感じでしょうか。
- 振り返り（KPT等）
- ドキュメントの整頓、それから今後の運用フェーズに向けた運用方針の決定
- 残案件の確認
出来たこと出来なかったことを整理して、次につなげるために後片付けをすることで、灰となったメンバーにも「これで…終わったんだ…ようやく…！」と解放感を味わってもらえるメリットが。
あとは、炎上案件は終わった、とクロージングミーティングで実感することで、気持ちの切り替えがしやすくなるのではないかと、個人的には思っています。
さいごに
ディレクター一人の力って、もちろん凄い方は凄いですが、やっぱりチームの力と比べると大したことないと思っています。
炎上案件をいくつか見てきた中で、もし、単純に状況が混乱しているだけであれば、ディレクターが適切に方向指示――すなわちディレクションすることで、状況は劇的に改善していきます。
ディレクターはチーム全員の司令塔であり、チーム全員の小間使いであり、触媒であるように努めて動くべし。
という個人的な信条にもとづいて頑張っていった結果、今回の炎上案件でもメンバーの士気がみるみる上がっていって、アウトプットがどんどん良くなっていき、オンスケでリリースできたのを見られたのは、とてもディレクターとして嬉しい瞬間でした。
ディレクターの基本中の基本、
- 要件管理
- スケジュール管理
- リソース管理（コスト管理）
の３つのポイントを押さえて動けば、炎上案件ももう怖くないっ！
……いや、やっぱり怖い！ので、これからも炎上しないように予防につとめよう、と改めて思ったプロジェクトでした。