タスクシュートの理解不足でプロジェクトが停滞していた時の話（その２）
はじめに
今回は、前回の記事の続編となります。チームを引っ張る立場になったのに、部下が１人、外部社員が２人だけで、雪だるまのように数十プロジェクトが始まるという地獄のような状態だった頃のお話となります。
※ 私は企業の情報システム部でITインフラのチームに所属しています。このため内容がかなり偏ってしまうことをご了承ください。
１．プロジェクトが進まない！
そのころ、いくつもの案件（プロジェクト）に期限が定められていませんでした。
理由としては、案件（プロジェクト）は、複数の部署が絡むのに、「その案件を進める必要がある」と認識しているのが、自分のチームだけだったからです。
どの案件も、サーバー機器やサーバーOSなどの老朽化で、システムを利用する部門には直接関係のない、ITインフラに起因する原因で、発生する案件（プロジェクト）だったからです。
老朽化対応が必要なサーバーやデータセンターは、10年以上前にくみ上げたものなので、当時の資料が残っておらず、担当者も辞めている状態がほとんどでした。
「サーバーやデータセンターの老朽化で、今まで使っていた機器が使えなくなる期限は、半年後や３か月後など決まっています。
しかしながら、サーバー機器の上に載っているアプリケーションは、新しいサーバーが機器ができあがってから開発アプリの実装・テストが始められるようになるため、調整が難しいのです。
そのため、自分は「その案件を進める必要がある」と認識していても、「いつまでにプロジェクトを完了する必要があるのか」というプロジェクトのゴールは、どうしてもサーバーベンダーなど、利害関係者にヒアリングしないとイメージすらできないのです。
では、どうすればいいのでしょうか。。。
２．期限のないプロジェクトはどうなるのか
「期限」がないと、プロジェクトにかかる費用が確定できません。
なぜなら、外部ベンダーが見積書を作成できないからです。
システム関連の案件には外部のシステムエンジニアによる開発がかかせません。開発にかかる費用は人件費で計算されます。
人件費は、時間で計算されますので、プロジェクトの期限が確定していない場合、開発にかかる費用が算出できなくなるのです。
３．費用が確定できないプロジェクトはどうなるのか
「費用」が確定できないと、その案件は正式に上層部に報告できません。
「いったいいくらかかるプロジェクトなんだ？」ということがかなり重要だからです。
もちろん、「概算でどれくらい」とわかるのがよいのですが、それも関連する利害関係者であるベンダーすべてを把握する必要があります。
４．利害関係者が確定できないプロジェクトはどうなるのか
「利害関係者」が確定できないとそのプロジェクトは予想外の作業や費用がプロジェクト開始後に発覚してしまいます。
上層部にも、「プロジェクト開始報告時から、費用と利害関係者が変わりました」と報告しなければなりません。
５．結局どうすればいいのか
停滞している案件（プロジェクト）については、利害関係者を洗い出し、ベンダーに対して、案件を説明し見積依頼して、概算でもいいので費用を確定させることが先決です。
そのためには、どうしたらいいのか。それを彼は教えてくれました。
６．彼のプロジェクト遅延対策
概算費用を出して、予算やプロジェクト開始について社内承認を得るには、「費用が発生する作業をベンダーに依頼する内容は、どのような目的で何をしなければならないのか」を簡単に説明できる資料を作って、説明をする必要があります。
① ベンダーや利害関係者に内容を説明するための資料かメール文章を作る
ベンダーには、案件を提案いただくために本来であればRFP（RequestForProposal）が必要ですが、簡易的に案件概要と期限を伝えれば、概算費用見積くらいは算出いただけます。メールでも大丈夫です。
このため、スモールスタートで実行すべきは、案件概要と期限が書かれた文章なのです。
②プロジェクト完了の時期を決めてしまう
案件（プロジェクト）に期限が定められていない場合、自ら定める必要があります。
まず、案件について連絡する際、関係者に「いつまでという期限があるか」ヒアリングします。
「今のところ特にない」という返事が来たら、自分の感覚でいいので案件完了段階をイメージして、そこから逆算して段取りを箇条書きにして、各工程にどれくらいかかるか、これも感覚でいいので、自分でわかる範囲の条件を想定して、決めてしまいます。
そうして決めた各工程の期限を積み上げて、外部ベンダーに見積依頼します。
ここでは、正確に各工程が計算できているかよりも、スピードが重要なのでイメージさえできていれば、スケジュール感が間違っていてもこの段階ではよいのです。
そのかわり、具体的に正式な期限がみえてきたら、概算見積→正式見積にしなければいけません。
このため、社内で報告する費用は、概算見積＞正式見積 でなければなりません。
７．彼から学んだこと
何度も書いてしまいますが、私が彼から学んだことは、間違ってもいいから、スピード優先で、案件のイメージを、メールや資料などで、形にして、利害関係者に共有することでした。
これからも、
「正確な情報を待っていても、わからないものは誰かに聞かないとわからない。誰かに聞くには、こちらから何が起きているのか説明しないといけない。それをしないといつまでも、プロジェクトは停滞して遅延してしまう」
「先に、間違ってもいいからわかる範囲で早めに情報を整理して、関係者に共有する」
を徹底して仕事を進めたいと考えています。
※ 当然のことながら、「間違ってもいい」は、あとで正しい金額、スケジュール期限に訂正することが前提で書いています。
８．おわりに
当時私は、タスクシュートのおかげで、毎日遅くまで残業して、例え帰宅した後の生活がボロボロでも、ストレスはあまりありませんでした。
（全くなかったといえばうそになります（苦笑））
しかしながら、いくら毎日仕事に目いっぱい時間をかけても、プロジェクト管理のコツを彼から教わるまでは、いくつものプロジェクトが停滞したままでした。
彼のおかげで、プロジェクトを前に進めるためのコツを学べたおかげで少しずつ、各プロジェクトについて、各工程の期限を自ら抑えていけるようになっていきました。
というわけで、TCを使っていて注意することは、TCの「プラン」とプロジェクト管理ツールの「計画管理」は別でしっかりおこなうというところも重要かなと考えています。
※ この内容は以前掲載したブログ記事「タスクシュートとプロジェクト管理ツールとの関係」にも関連する内容となりますので、こちらの記事もおススメです。
要はタスクシュートの目的は個人の幸せのため、プロジェクト管理ツールで管理する目的は各案件のプロジェクトのゴールとなる目的のためなんです。
いいなと思ったら応援しよう！
