こんにちは、はむらいとです。
僕はIT業界で長年お仕事をしていて、
その中でもプロジェクト自体が大幅遅延したり、はた目にはほぼ失敗
というのがありました。
今回はそんなケースにならない様に、これからチーム編成を考えておられるプロデューサー、または役職以上の方向けに失敗した例を書いてみたいと思います。
まだ、自分がそこまで責任が大きくないという方は、
こういう傾向が見えたら早めに手を打ったほうが良いと何かの指標にしてくれると嬉しいです。
それでは、見ていきましょう。
失敗の最大要因はやはりディレクターという立場の人間。
IT業界の基本のチーム編成を先にご紹介します。
こちらは案件に対してよくある編成ですが。
ディレクター
デザイナー
フロントエンドエンジニア
バックエンドエンジニア
デバッガー
基本はこの5種からチームを編成します。
デザイナーがフロントを兼任していたり、バックエンドの要らない案件だったり。
もちろん案件規模によって違いますが、基本はこの当てはまる人材をどう投入していくかです。
責任はどうしても一カ所に集中してしまう。それがディレクター。
次にそれぞれやっている事を見ていきましょう。
ディレクター
主に制作進行。
クライアントの交渉、要望のまとめ、提案、スケジュールの策定・管理。
企画面の管理。ゲーム運用で言うとプランナーがレベルアップしてなる。
ウェブサイトでいうとサイトマップの設計や、SEOの対策施策を決めたり雑務的なものが多岐に渡る。
全体のリーダー的立場。
デザイナー
文字通りデザイン面担当。
奇麗で、伝わりやすく、またエンジニアチームの組み込みまで考慮して
画面全体や一枚絵、エフェクトなど様々なものを提案する。
よく、エンジニアへの配慮が足りなくてすごく怒られる(私です)。
エンジニア
ひとまとめに紹介してしまいますが、わかりやすく言うとコードを書いている人です。
もちろんそれぞれ専門分野があり、言語も案件の種類によって異なります。
フロントと呼ばれる人たちはよくコーダーと呼ばれていますね。
インターフェース的な処を作る人たちです。
バックと呼ばれる人たちはサーバーサイドと呼ばれたりします。
APIの連携やデータの持ち方などを管理する人たちですが…。
突っ込まれると甘くなるので割愛。
デバッガー
バグを見つける人です。
納品前、納品後に、機能実装語などにユーザーと同じ環境で検証をして
バグをどんどん報告します。
案件が小さいと全員でやることもありますが、専任の方が居ると心強いです。
ざっくりですがこんな感じです。突っ込まないでください。
このうち、クライアントからみた責任というのは表に出てくるディレクターに一極集中します。
当然ですね、突っ込める対象がそこしかないからです。
逆に言うとクライアントはディレクターに突っ込むことで、疑問が解消できると思っています。
ここが問題です。
ディレクターに実力よりはるかに大きい案件を担当させてはいけない。
この場合の実力というのは【経験】の意味です。
ケースを如何に蓄積しているかの事です。
案件が失敗する要因がディレクターに多いと断言するのは、クライアントもチームメンバーもディレクターを主の責任者としてみてしまうからです(当たり前ですが)。
しかし、ディレクターの経験値が足りない場合、ただの置物になってしまい、クライアントとのコンセンサスが取れなくなります。
例としては
WEBサイトを受注したがディレクターだけ初心者だった場合。
1.一流のデザイナーと一流のエンジニアを配置した。
2.スケジュールもクライアント、デザイナー、エンジニアから吸い上げ、了承を取ったから余裕があるし大丈夫だろう。
3.スケジュール通り提出したがクライアントの返答がどうもハッキリしない
4.はっきりしないまま進めているうちに完成が近づいてしまい、都度クライアントに確認しているつもりだったが、突然こうじゃないとちゃぶ台を返される。(ちゃぶ台返しという表現は語弊がありますがあえて使っています)。
この例の中で問題なのは
全員がやっているつもりになってしまった事です。
スケジュール後半で起こっていることは大体こんな感じです。
クライアント側
なんか制作側からのアウトプットが思っているのと微妙だけど大丈夫だろうか
ディレクターが何も言ってこないから恐らく順調なんだろう。
ディレクター
まだ初心者だからよくわかってないけど、この進行で問題ないのだろうか
どこからも文句は上がってこないし一応大丈夫？
デザイナー
言われたものや意見は全部取り入れたし、提出したから大丈夫。
とりあえず次の案件をやらなきゃいけないから
基本的には進行状態を見ているだけになりそう。ディレクターが何も言ってこないし。
エンジニア
設定とか抜けがあるけど、指定されてないから大丈夫だろうか。
設計も、ちょっと突っ込み入ると治せないほどがちがち憎んでるけど、いままでクライアントから要望もないし大丈夫か。とりあえず進めよう。
ディレクターが何も言ってこないし。
解らない物を共有できない苦しみは解消しなければいけない。
要するに、ディレクターを起点にモノが正しいかどうかをみんなが判断してしまっているのですが、ディレクター自身が初心者だと提案っぽい物、スケジュールっぽい物しか出せないのです。
入り口の進行のみは順調に見えても、ディレクター側でその後どう動いていいかわからず、間違いや提案、確認が漏れていることを自覚できませんし、周りも指摘しません。
この意思の齟齬、見えない崩壊が全体の不協和音を生むのです。
ディレクターは全体のトップに立ってしまう立場上、そのケツを拭ける人間が存在しません。
つまり、ここの人選を誤ると、どんなに他セクションで優秀な人間を付けてもプロジェクトが瓦解してしまいます。
これは他セクションでも言えることですが、初心者を入れる時はマイナス分をカバーできる様により強力な同セクションの人材を置くべきです。
何回も書きますが
初心者は何処が足りないか、どこが誤っているかを自覚できないまま進めてしまうので。
司令塔たるディレクターがそうなってしまった場合は最悪です。
一例としては
優秀なゲームディレクターが優秀なWEBディレクターかどうかは話が全く別という事です。
ツイッターでもこうつぶやきましたが
スケジュールが走り始めてからでは遅いのです。
必ず、リカバリーができる立場の人間を選任でおいてあげてください。
もし、ディレクターが右往左往している様だったら、根気よく助けてあげてください。
その人は恐らくそのプロジェクト中に機能することはありません。
そのプロジェクトで絶賛失敗中なので。
失敗だと気づくのも、時間をおいて冷静に見つめなおしたときになるはずです。
手を抜いた初期編成は関係者全員で損をします。
コメント