第1章 1.3 ← 1.0 プロジェクト管理とは
プロジェクトと定常業務は、能力ではなく性質が違います
定常業務で高い評価を受けてきた人が、プロジェクトを任されたとたんに苦戦することがあります。本人の能力が落ちたわけではありません。うまくいくための条件が、正反対に近いからです。この記事では、その違いを5つの観点で並べます。
この記事の要点
- 定常業務は「決めたとおりに回すこと」で成功し、プロジェクトは「途中で決め直せること」で成功します。
- 定常業務の失敗はその日のうちに分かり、プロジェクトの失敗は数か月後にまとめて表に出ます。
- だからプロジェクトは、放っておくと必ず後回しになります。今日さぼっても、今日は誰も困らないからです。
- 兼任でプロジェクトを持つ人にとって、これがいちばんの落とし穴です。
- 対策は根性ではなく、時間の置き方です。週の中に固定した枠をつくるほうが確実に効きます。
5つの観点で並べてみます
どちらが優れているという話ではありません。会社の売上のほとんどは定常業務が生んでいますし、プロジェクトはその定常業務を変えるために存在します。ただ、うまく回すための条件が違います。
「決めたとおりに回す」と「途中で決め直す」
定常業務では、手順を守ることが価値です。請求処理も、月次の締めも、問い合わせ対応も、決まったやり方があり、そのとおりにやれば品質が安定します。人によってやり方が変わることのほうが問題になります。
プロジェクトでは、これが逆になります。最初に立てた計画は、いちばん情報が少ない時点で立てたものです。進むにつれて、想定していなかったことが分かります。連携先の仕様が違った。相手の担当者が代わった。使ってみたら業務に合わなかった。このとき、当初の計画どおりに進めることは美徳ではありません。分かったことに合わせて計画を直せることのほうが価値です。
ここが、定常業務で評価されてきた人ほど戸惑うところです。計画を変えることが、失敗を認めることのように感じられます。実際には、変えないほうが失敗です。計画は約束ではなく、その時点での最善の見通しにすぎません。
失敗の見え方が、まったく違います
定常業務の失敗はすぐ分かります。請求書が出なければ、その日のうちに誰かが電話をかけてきます。フィードバックが速いので、勝手に上達します。
プロジェクトはそうなりません。要件定義でひとつ確認を飛ばしても、その日は何も起きません。翌週も、翌月も起きません。それが表に出るのはテスト工程で、しかもそのときには他の原因も5つ並んでいます。ベンダーが遅れた、担当者が抜けた、スコープが増えた、テストで想定外が出た——どの説明も本当なので、本当の起点にはたどり着きません。
この「フィードバックが遅くて、しかも他の原因と混ざる」という性質が、プロジェクトを経験だけでは上達しにくい仕事にしています。この点への対処は10.1で扱います。
兼任の人にとっての、本当の問題
ここからが、この記事でいちばん実務的な部分です。表のいちばん下の行——今日やらなくても、今日は誰も困らない——は、性質の違いではなく力学です。
朝、机に着いたとします。定常業務のほうには、返さないと止まる問い合わせがあり、今日締切の処理があり、隣の人が待っている確認があります。プロジェクトのほうには、来月の移行に向けて連携先に確認しておきたいことがあります。今日やらなくても、今日は誰も困りません。
この選択を20営業日くり返すと、1か月ぶんの遅れになります。しかもそれは、どこにも記録されません。あなたはずっと忙しく働いていて、定常業務は完璧に回っていて、それでもプロジェクトだけが動いていない、という状態になります。そして数か月後、まとめて表に出ます。
これは意志の弱さの問題ではありません。締切が近い順に手をつけるのは、人として合理的です。だから対策も、気合いではなく置き方で考えます。
兼任で回すときの、現実的な3つ
- 週に1枠、固定する。「毎週水曜の朝いちばんの30分」のように、曜日と時刻を決めて予定表に入れてください。空いた時間にやろうとすると、空いた時間は永遠に来ません。
- 次の一手だけ決めておく。その枠が来たときに「何をやろうか」から始めると、それだけで15分が消えます。前回の終わりに、次にやる1件を書いておいてください。
- 止まっている理由を、外に出す。他部署の回答待ちで止まっているなら、それは自分の遅れではなく組織の遅れです。課題として登録して見えるようにしておかないと、最後にはあなたの遅れとして記録されます。
実際には、混ざっていることのほうが多い
ここまで2つを対比してきましたが、現場ではきれいに分かれていません。運用しながら改善する、保守の中に小さな改修が混ざる、というのが普通です。
迷ったときの判断は単純です。終わりが決まっているかどうかを見てください。「システムを安定して動かし続ける」は定常業務です。「来年3月までに新しいシステムへ移行する」はプロジェクトです。同じチームが両方を持っていても、扱い方は分けたほうが管理しやすくなります。
混ぜたまま扱うと、たいてい定常業務のやり方に引きずられます。手順を守ることが優先され、計画を直すという発想が出てこなくなり、期日だけが動いていきます。第2章で扱う「フェーズ」という考え方は、この混ざりを解くための道具でもあります。
ABではこう見えます
定常業務とプロジェクトを同じ場所で扱うと、片方がもう片方に埋もれます。AB Projectsでは、終わりのある仕事をプロジェクトとして分けて持てるので、「今週プロジェクトが何も進んでいない」ことが、それ自体として見えるようになります。忙しさに紛れて見えなくなるのが、いちばん危ない状態です。
兼任で回している方には、週次の固定枠をタスクとして置いてしまうことをおすすめします。期日つきで自分に割り当てておけば、他の仕事と同じ土俵に乗ります。予定表の中にない仕事は、実際には存在していないのと同じです。
このページで使った言葉
- 定常業務
- 毎日・毎月くり返される、終わりのない仕事です。ルーチンワーク、運用とも呼びます。手順が決まっていること自体が価値になります。くわしく →
- 兼任
- 本来の担当業務を持ったまま、別の役割も同時に担うことです。日本の中堅企業では、システム関連の仕事の多くが兼任で回されています。くわしく →
- フェーズ
- プロジェクトを性質の違う区間に分けたものです。区切りごとに「進めてよいか」を判断できるようにするための仕組みでもあります。くわしく →
- 課題
- すでに起きていて、対処しないと進まない事柄です。まだ起きていない「リスク」とは区別して扱います。くわしく →
- ひとり情シス
- 社内の情報システム業務を、実質ひとりで担っている状態です。中堅・中小企業で増えており、プロジェクトが兼任で回される典型的な背景になっています。くわしく →
- 運用
- つくったものを、日々動かし続ける仕事です。プロジェクトが終わったあとに始まり、終わりがありません。くわしく →
あわせて読みたい
2.0 プロジェクトの進み方
立ち上げから終結まで、フェーズという考え方で全体を見ます。
5.5 タスク管理ツール
定常業務とプロジェクトを、道具の上でどう分けて持つか。
9.1 はじめての人のQ&A
はじめてプロジェクトを任された人が、実際に困ることへの答えです。