外からプロジェクト状況を把握して手を打つ

数十人以上が携わるゲーム開発でひとたび問題が起きると、コストやスケジュール、そしてメンバーへのダメージはかなり大きなものになります。数千万から数億の追加コストがかかった、半年から一年計画が遅延した、といった話は残念ながら業界的によく聞きますし、ニュースやSNSでもたびたび話題に上ります。従って大きなプロジェクトになればなるほど、いかに問題が起きないように事前に手を打つか、起きた場合早期に発見して解決を図るか、が組織の大きな関心事となります。

当然プロジェクト内では進捗管理をしたり1on1に力を入れたりと様々な手を打って予防や早期発見に努めるでしょう。その上で、特にプロジェクトが複数並行して動くような組織ではプロジェクトの外側からも横断的に状況を把握することで、内部では気付きづらい問題を発見したり、プロジェクト単独では難しい大きな手を打つ事が可能になります。

この記事ではその「外側からの状況把握」と打ち手の幾つかについて、自分の組織で取り組んでいる例を説明します。

リーダーは誰か？

プロジェクトの各セクション（企画、デザイン、クライアント開発、など）のリーダーが誰なのか、これまでの実績や周囲の評判からして仕事上の強みや弱みはどのあたりなのか、といった点を押さえます。

「それを知ってどうするの？」と思われるかもしれませんが（自分も最初そう思いました）、実際はそれなりに有用です。状況把握は長期間継続的に行うものなので、序盤に弱みが分かっていれば「このタイプのリーダーは後半こういった点でつまづきがちなので、特に気をつけておこう」という予想を立ててその後の注視点を絞る事ができますし、次に説明するようにプロジェクト外のメンバーとつなぐ事で弱い部分をサポートする事もできるからです。

組織内で強みを持つ部署やメンバーとつなぐ

特に専門性が高かったりプロジェクト内にそこに強いリーダーやメンバーがいない分野について、組織内の専門部署や詳しいメンバーをつないで適宜アドバイスやサポートを依頼します。

放っておいても個人的な横のつながりを駆使してアドバイスをもらったりライブラリを入手して仕事を進める人もいますが、そこを個人に依存せず組織としてつなぐ事で双方が動きやすくなり、頼られた側の貢献を適切に評価する事もできるようになります。プロジェクト初期の決定や設計はその後に与える影響が大きいので、序盤にこれができるかどうかはかなり重要だと思います。

月毎のアウトプットは何か？

各セクションのアウトプットや決め事について、「この月はクライアントセクションで○○画面と✗✗画面が動くようになる、企画セクションで△△の仕様がfixする」といった内容を明確にします。

よくある話なので説明不要な気がしますが、強いて言えば月毎で区切るのはポイントと言えるかもしれません。プロジェクトとしてまとまった意味のある単位でマイルストーンを設定する事はよくありますが（〇〇機能完成、✗✗フェーズ完了など）、この単位だと期間や粒度がまちまちになりがちです。それを一律で月単位のアウトプットとする事で、外から把握する際に状況を見えやすくしています。

ただしプロジェクト内でのマイルストーンや進捗管理とは全く別に管理しようとすると、「外から分かりやすくするためだけの作業に時間が取られて困る」という本末転倒な状況も起き得るので、こだわり過ぎない方が良いとは感じています。

他のプロジェクトで起きた問題やありがちな罠を改めて指摘する

プロジェクト外の立場から「このフェーズではこういった問題が起きがちだけど大丈夫？」「他のプロジェクトだとこんな課題があったのでこの点を可視化して欲しい」といった確認や情報共有をします。そこで少しでもきな臭さを感じたら、遠慮なく深堀りします。

プロジェクトが上手くいかなくなる原因は、誰でも聞いた事があるようなものが多いです。そのため問題が起きた後に振り返ると、当事者も含めてたいていは「最初から兆候はあった」「冷静に考えれば分かったはず」「何故こうなる前に手を打てなかったのか」、といった感想になります。聞いてビックリ、これは予想できないから仕方なかったというケースは稀ではないでしょうか。

では「よくある問題リスト」を作って各プロジェクトに共有すればそれで防げるかというと、ご存知の通りそんな事は全くありません。理由は色々あり、大勢が関わる仕事の本質的な複雑さだったりゲーム制作が持つ見通しの難しさだったりもありそうですが、1つ分かりやすい理由としてプロジェクト内での正常性バイアスがあります（wikipedia）。自分も何度も経験しているのでよく分かりますが、実際にプロジェクトを進めているメンバーやリーダー陣はスケジュールが逼迫したり忙しくなるにつれて、問題の兆候を無意識に(?)スルーしたり起きている問題を過小評価しがちになります。結果、リストに書いてあったよくあるパターンにまたハマるという訳です。

そこで正常性バイアスを持たないプロジェクト外の立場から確認や指摘を行う事で、問題の早期発見や冷静な解決手段検討の可能性を高める事ができます。

問題解決に向けて動いているか？

認識した問題や発生確率が高いリスクをリスト化し、各項目について対応内容を明確にし、その対応の進捗状況を毎回確認します。

プロジェクト全体に関わるような大きめの問題はストレートな解決策が無かったり解決までの道のりが長かったりで、腰が重くなりがちです。またいったん動き出したとしても、緊急度が低いと途中でうやむやになったりもします。この取り組みの意図は「認識していたのに手をこまねいていて問題を大きくしてしまった」とならないよう、外部の視点で継続的に解決の進捗を追って、確実に解決に向かって動くようにする点にあります。また、記事の冒頭に書いたようにプロジェクト単体では難しい大きな手を打つ場合にも、前提としてこのように組織横断で課題を把握している必要があります。

後者の例を挙げると「組織内や採用市場の状況からみて今後必要なタイミングでアサインができないかもしれない」というリスクがあった場合、組織全体でプロジェクトの優先度を決めておいて、どうしてもアサインできない場合は優先度が高いプロジェクトに人を集める旨を周知しておこうという手が考えられるでしょう。

最後に

自分達の組織で行っている取り組みの一例を説明してみました。どれもいたって普通の話ではありますが、普通の事をちゃんとやるのもなかなか大変だと日々感じたりもしています。この記事がどこかの会社や組織の参考なれば幸いです。