筆者はディレクターではないが、エンジニアリーダーのような立場で、チーム内エンジニアの作業進捗を管理した事は何度かある。
「スケジュール管理」という物はなんなのか、まずはその定義をしなければならないのだが、筆者が考える物は話すと長くなるので、それはまた別の機会にする。
ここでは、その時の管理経験と、イチ作業員としてプロジェクトに従事した際の経験から、いくつか見落としがちな作業工数の指摘をしていこうと思う。
〇甘く見られている会議の工数
さて、皆さんは週にどの程度会議をするだろうか。色々な会議があると思う。
・朝イチで行う、10分程度のミーティング
・週に一度、チーム全体で行う週定例
・週に一度、セクション毎（プログラマーだけとか、デザイナーだけとか）で行う週定例
・取引先が居れば、リーダークラスの人間は参加せざるをえない事が多い、先方との定例会議
などなど、例を挙げればきりがない。
さて、ここで質問。これらの日数はあなたのプロジェクトのスケジュールに工数として計上されているだろうか？
計上されていなかったとしたら、残念だが、その時点でそのプロジェクトのスケジュールは何の意味もなさない物になっている。
というよりは、そのスケジュールは「各人が通常の1日8時間勤務という基準より、多く働くことが前提」としたスケジュールになっていると表現できる。スケジュールを立てた本人にその気が無くてもだ。
理由は簡単だ。例えば、朝のMTG（＝ミーティング）が10分、週に1度チーム全体で1時間のMTG、週に1度セクション内で1時間MTGがあったとすると、
・朝MTG＝10分*5＝ほぼ1時間
・チーム全体MTG＝1時間
・セクションMTG＝1時間
と、週に3時間も消費している。
これを月換算すると、12時間、1年プロジェクトだとしたら、144時間だ。
スケジュール換算でいうところの人日（1日を8時間として計算した際の指標）に換算すれば、年間で18人日にもなる。
これをチーム全体の人数、ここでは適当に10名とするが、それで計算すると、180人日もの時間をMTGに費やしている事になる。
また、これがリーダークラスの人間になると更に深刻で、MTGの為の資料準備や周知対応等を行っていたら、週1，2時間では済まされないはずだ（経験済み）
これだけ時間がかかる物をスケジュールに組み込んでいなかったとしたら、そのスケジュールは正常だと言えるだろうか。
では、このツケはどこに回るかというと、残業と休日出勤で返す事になる。幸い、ゲーム業界では「裁量労働制（仮）」なる労働契約を結ぶことが多いので、残業や休日出勤した分がそのまま全てお金になって返ってはこない、会社側にハートフルなシステムになっている事が多い（まぁ、さすがに月300時間以上働けば話は変わってくるだろうが。）
体裁としては、その代わりに基本給料にすでに残業分が上乗せしてあるんだよ、という建前の上で年俸が定められているだろうが、働いている社員の方は、その上乗せ分と思われる数値と実際の残業代を比べたことがあるだろうか。恐らく、比べると裁量労働制などやりたくなくなると思う。
これが、
＞そのスケジュールは「各人が通常の1日8時間勤務という基準より、多く働くことが前提」としたスケジュールになっていると表現できる。
と表現できる根拠だ。
もし、あなたがエンジニアで見積もりを出したりスケジュールを管理する立場なのであれば、恐れずこの工数を確保する事をお勧めする。そうでなければ、上記の理屈を突き付けて、どのように思っているか問いただすのもいいだろう。そのスケジュール管理者、プロジェクトマネージャが何を考えているかがわかるはずだ。
〇タダだと思われている見積もり工数
さて、例えば何か追加機能を実装する事になったとして、その要望を叶えるために見積もりを依頼されたとする。
これは、要求されている見積もりの精度にもよるのだが、ある程度ちゃんとした確度の高い見積もりを出さなければならない場合、見積もりを出す為の作業が発生するはずだ。
・仕様書をきちんと読み直し、質疑応答をする必要がある
・場合によっては、プログラムで簡単な検証を行う必要がある
・既存実装されている物を調査する必要がある
等だ。
仮に、この調査作業に0.5人日かかったとして、新規実装を行う作業の見積もりが5人日だとしたら、提出する見積もりは5.5人日にするべきだ。実作業が発生しているからである。
そして、スケジュール管理者に、「今日行った作業は0.5人日、新規作業の見積もりタスクです」と申告すべきだ。
もしそれでいい顔をされないのだとするなら、いくつか段階を踏むことをお勧めする
・そもそも、見積もりに時間がかかる事を了承させる
・それもダメなら、見積もりに時間が取れないので、確度が著しく落ちる見積もりになる事を了承させる
・これらの言質を取っておく
という自衛をしておくことだ。この自衛でどこまで自分の身を守れるかわからないが、何もしないよりはいいと思う。
〇まとめ
見積もりに関する落とし穴を2例紹介させてもらった。いずれも、この落とし穴にハマっているプロジェクトは実際に存在し、筆者も従事してきた。
少し考えれば当たり前のような事だが、人から言われるなどのきっかけがないと見落としてしまいがちな部分だと思う。
〇余談
こうしてみると、会議に費やしている時間に度肝を抜かれると同時に、バカみたいに感じる。
参考になるかわからないが、筆者が取ってきた対策を一例として紹介しておく。
前職場のスマフォ案件時は、筆者にもある程度裁量が与えられていたので、チーム内定例にはエンジニアは参加させなかったし、朝の10分MTGも行わなかった。筆者が個別で確認に回って聞けばいいし、チャットで数行情報を伝達してもらうだけで十分だ。問題があれば、筆者が他のリーダークラスに伝達すれば済む。先方との定例でも、技術的に必要な話になった時だけ呼び出してくれと会議を拒否する。エンジニアMTGも、口頭で話す必要性を感じない限りは、チャットで連絡事項共有だけで済ます。
とはいえ、口頭で話すタイミングでついでに相談等しやすくなるというメリットも感じていなくはないので、個別で時間を取らせないように口頭で会話をしに行くという事は行う。その中で、他者とのコミュニケーションが必要と感じれば、それはその時にセッティングを考えればいいだけだ。
それがうまくいったかどうかの反省をしなかったのが、良くなかった事だが、極力作業者に時間を取らせない、というのは、管理者が行う責務であると仕事に取り組んだ。
他の人はどう思ったかを振り返りで聞かなかったのが最大のミスなのだが、少なくとも筆者の作業時間は取れたし、つまらない情報伝達ミスなどもなかったので、失敗ではなかったはずだ。成功だったかどうかは、わからない。
今後も裁量が与えられたとするならば、無駄な会議は指摘して削り、極力作業者には作業に集中してもらうような環境づくりを心掛けると思う。
