仕事の基本ルール
何かの稟議をとうすためには、上司やそのまた上司、さらにそのまた上司・・・に決済してもらうことが必要です。ところが総じてこうした役職が上に行くほど決済のための時間を取ってもらえなくなります。忙しいんです。本当に忙しくて決済印を押す時間もないかどうかは、そんなに偉くないので知りませんが…(^^;;
私の専門である IT 関連でも、何かのシステムを導入するとなると何千万円なんて簡単に行ってしまいます。そうすると、重役や社長の決済が必要で、その方々に説明するだけの資料が必要になりますが、役員会などで説明すると、あちこちからツッコミが入って、的確に答えられないと「やり直し」。
こうした問題を避けるためには、いくつかコツがあることが最近わかってきました。
■決済はイベントではない
決済をしてもらえないことによる悪影響というのは、当然ながら「必要な資材が購入できない」「会社の方針としてプロジェクトが承認されない」というところにあるのですが、よく失敗するのは、この「決済をもらう期間」がプロジェクトのスケジュールに組み込まれていないという問題です。
たとえば、何かのシステムを購入するとして
要件定義→決済→発注→開発→納品→検収
というステップを踏んだとすると、要件定義のまえに計画を作りますよね。
そのスケジュールに「決済」というのは、時間的長さを持たない「イベント」になっているか、ある時間範囲を持っている「タスク」になっているかというと、大抵の場合はイベントになっていることが多いようです。
つまり、最大でも1日（日次の計画なら）しか長さを持ってないわけです。
ところが実際には、見積書を作り（もらい）、稟議書を作って役員のところに持っていく、役員に説明して承認をもらうという作業が必要なわけで、稟議書が書き上がったら即日役員のところに持っていくことができるかというと、そんなことはありません。
会社によっては、2週間に一度、こうした稟議をまとめて審議する審議会が設けられているところもありますし、役員のスケジュールを押さえてから、その日、その時間に持っていくこともあるでしょう。
自分自身が相応の役職になければ、役員や社長においそれと会いに行くことはできないんです。
で、稟議書を書き上げて、役員のスケジュールをみたら、つぎに審議会があるのは2週間後だった、とかいう事態になれば、もうそれだけで計画は2週間遅れです。
その上、冒頭のように突っ込まれて出し直しになれば、次は1ヶ月後とか。もうプロジェクトは回復不能。
■無限地獄の決済ループ
決済のプロセスを詳しくみるともっと大変です。
部長決済→担当役員決済→役員会決済→社長決済
なんて日本の会社らしい責任分担システムがあれば、それぞれのところで突っ返される危険があります。なんとか役員会まで行ったところで、ツッコミを受けて資料を修正すれば、もう一度部長決済からやりなおし。
部長から
「何でこんなところ変更したんだ。前と違うじゃないか」
とまたそこでも突っ返されて、直したら今度はまた役員会で「前にここを直せと言っただろうが！」って、ペーペーはほんとつらい…
※せめて決済者どうしくらい意見を合わせておいてほしいもんだ。意見の相違をヒラに押し付けないでほしいなあ。
そんなこんなで、決済がくるくる回り始めると、もう無限地獄。これを私は「決済ループにハマる」と呼んでまして、何度か経験があります。3回もまわるともうプロジェクト当初のモチベーションはゼロになって、「もうやめていいです？」状態に。
■プロジェクトを遅らせない決済のタスク
まず、プロジェクトの計画をたてるときに、それが
活動期間を持たない「イベント」なのか
ある一定の時間が必要な「タスク」なのか
をちゃんと判断する必要があります。決裁を受けること自身はイベントでいいですが、決済を受けられる環境を整えることはイベントではありません。時間が必要なんです。
もうひとつ。「決済」というイベントは、役員の都合で変わってしまうことがあるという前提が必要です。
あるところまで完了したら、即座に決済が受けられるという考え方は変えないといけません。
これは自分の都合。決済する相手の都合を優先しないといけないんです。
◆決済を受けられる環境を整えるタスク
さて、決済を受けられる環境を整えることタスクはどのようなものがあるかというと、
・根回し
・資料作成
・決済イベント調整
・捺印回覧
です。とくに重要なのが「根回し」。
◆根回しで認知度を上げる
たとえば、決済で
部長決済→担当役員決済→役員会決済→社長決済
のそれぞれが必要なら、下の方から順番に事前にこっそり話をしておくことです。
まず、部長に「こういうプロジェクトでこのくらいの費用が必要」ということを説明しておき、だいたいの合意を引き出しておきます。
担当役員には、自分が説明することが難しければ、部長に「○○役員に一言、本件について報告をお願いします」とお願いしておく。
そうすると大抵の場合は、「もうちょっと詳しく」とか「××はどうなんだ？」と質問があるので、それについて説明に行くというレベルで（決済を求めるのではなく、プロジェクトについて説明するだけ）話に行くようにします。もちろん、部長が代行してくれるのが一番なのでしょうけど、部長が突っ込まれて突き返される可能性があるのであれば、プロジェクトを推進している人がちゃんと説明に言ったほうがいいです。突き返されると印象が悪くなるので。
こうして、だんだん上に「状況説明に行く」レベルで、プロジェクトの認知度やそれに関する質疑を事前に集めておけば、いざ決済という場面で、ひっくり返されることは少なくできます。
◆資料はQ&Aを作る
こうして、説明に行くといろいろな質問が出ます。そのときに聞かれたことを資料には必ず盛り込むようにします。定形の資料やページ数に制限があるときには、補足資料として用意します。
たいていの責任者、役員の質問は、要約するとつぎの４つしかありません。
・そのプロジェクトは投資対効果は「十分」なのか？
・そのプロジェクトより優先順位の高い課題はあるのか？
・費用・投下工数、活動期間の絶対値は必要十分だと考えられるか？
・自社の保有技能や世の中の技術からみて達成可能か？
です。これを言葉を変えて聞いているだけです。
これにちゃんと答えられている資料なら、大外れではありません。
ただし、聞く人が嫌いな言葉とか言い回しがあると、突っ込まれますので、根回しで事前に確認しておくわけです。
■決済はタスクをスケジュールする
プロジェクトの計画を作るときには、決済はタスクとして計画しましょう。
やるべきことの主なものは、上記に書きましたが、これ以外にもそれぞれの会社で必要なルールはあるかと思います。
それをちゃんとこなせるだけの時間を組み込まないと、決済がおりたときにはスケジュール遅延状態になりかねません。
さらに、決済が下りなかったときのやり直し期間もリスクとして考慮しておかないと、「社内手続きをしていたらスケジュールがぼろぼろになった」という自分ではどうしようもない問題を抱えかねません。そのせいでプロジェクトの活動期間が苦しくなって、後々禍根を残すことになっても悲しいですので。
