第3章 3.3 ← 3.0 計画の基本
体制図の人数より、「この人しかできない」の数を見てください
要員計画というと、何人必要かという話になりがちです。ところが実際に日程を壊すのは人数ではなく、特定の作業ができる人がひとりしかいないという状態です。属人化は、止まるまで誰も気づきません。そして止まったときには、代わりを立てる時間が残っていません。
この記事の要点
- 体制を「誰がいるか」ではなく「誰が何をできるか」で書くと、弱点が一目で分かります。
- 「この人しかできない」行が3つあれば、それがこのプロジェクトの本当のリスクです。
- 属人化を完全に解消する必要はありません。○をひとつ増やすだけでも効きます。
- 稼働率を確認せずに人数だけ数えると、いるはずの人がいない計画になります。
- 商流が深いと、決める人と作業する人が離れます。誰に聞けば決まるのかを最初に確認してください。
できることの表を、一度だけ作ってください
作業領域を縦に、参加者を横に並べて、できる／手伝えば進む／できない、を埋めるだけです。30分で終わります。そして、たいてい見たくないものが見えます。
「この人だけ」の行が、本当のリスクです
3.4でリスクの話をしますが、ほとんどのプロジェクトでは、この表のオレンジの行が最大のリスクです。技術的な難所より、こちらのほうが確実に効いてきます。
理由は、起きる確率が高いからです。半年のプロジェクトのあいだに、誰かが1週間休む確率は高い。別案件に呼ばれる確率も高い。異動や退職もあります。そして日本の職場では、これらは本人が言い出すまで分からないことが多くあります。
2025年に国内のIT関連職325名を対象に行われた調査でも、要件定義の最大の課題として属人化を挙げた人が50.8%と最多でした。これは特別に管理の悪い現場の話ではなく、多くの現場の標準状態です。
全部埋める必要はありません
この表を見て「全部の欄を◎にしよう」と考えると、何も進みません。教える時間も、覚える時間もないからです。
現実的な目標は、オレンジの行のうち、いちばん危ないものに○をひとつ増やすことです。◎にする必要はありません。「手伝えば進む」人がひとりいるだけで、その人が休んだときに完全には止まらなくなります。
そして、○を増やすいちばん安い方法は手順を書き残すことです。教えるより速く、教わる側の時間も取りません。「この作業の手順」を1ページ書いてもらうだけで、それを読める人は全員が○に近づきます。
ひとり情シスの現場では
社内のシステム業務を実質ひとりで担っている場合、この表は1列しかありません。属人化を解消する相手がいないので、手順を書き残すことの価値が他のどんな現場よりも高くなります。目的は誰かに引き継ぐことではなく、あなたが休んだ日に会社が止まらないこと、そして半年後のあなた自身が思い出せることです。前者だけでも、書く理由としては十分です。
人数ではなく、使える時間で数える
3.2で触れた稼働率の話は、要員計画の側から見るともっと露骨になります。
「3人体制です」と言われても、それが3人分の時間を意味することはまずありません。ひとりは定常業務が本業で週1日、ひとりは別案件と掛け持ちで週2日、ひとりは専任で週5日。合計すると週8日、つまり実質1.6人分です。
だから体制表には、名前の横に「この案件に使える日数／週」を書いてください。書いた瞬間に、3人が1.6人になります。この数字を持っていないと、日程の議論が「人を増やせば何とかなる」で終わってしまいます。実際には、増やした人の稼働率が週1日なら、ほとんど何も変わりません。
商流が深いと、決める人が遠くなります
日本のシステム開発では、発注元から実際に作業する会社まで、契約が何段も重なっていることが珍しくありません。元請け、一次請け、協力会社、常駐。この並びを商流と呼びます。
商流が深いと、体制図に載っている人が「決められる人」ではないことが増えます。会議で質問しても「持ち帰ります」となり、答えが返るのが1週間後。これは相手の能力の問題ではなく、契約の構造上そうなっているだけです。
対処は、責めることではなくルートを把握することです。「この判断は、誰まで上がれば決まりますか」を早い段階で聞いておく。そして日程には、そのルートを通る日数を入れておく。これをしておくと、待ち時間が「予定どおり」になります。
ABではこう見えます
AB Projectsでは、タスクの担当者がひとりに定まるので、誰に何が寄っているかが自然に見えます。特定の人にタスクが集中していれば、それは属人化の兆候です。人数ではなく、割り当ての偏りを見てください。
手順を書き残す場所としては、プロジェクトWikiが向いています。「この作業の手順」をタスクから参照できる形にしておけば、次に誰がやるときも、書いた本人がいなくても進みます。7.3で扱う知識の引き継ぎは、プロジェクトが終わってから始めるのでは遅く、この段階から少しずつ溜めるものです。
このページで使った言葉
- 属人化
- 特定の人しか分からない・できない状態です。進捗が良く見えていても、その人が抜けた瞬間に止まります。くわしく →
- 体制
- 誰が何の役割で参加しているかの構成です。図にしたものが体制図で、確認すべきは名前より「決めていい人か」です。くわしく →
- 稼働率
- その人が実際にこのプロジェクトに使える時間の割合です。人数ではなく、これを合計して数えます。くわしく →
- 商流
- 発注元から実際に作業する会社までの契約のつながりです。深いほど、決める人と作業する人が離れます。くわしく →
- ひとり情シス
- 社内の情報システム業務を実質ひとりで担っている状態です。属人化が構造的に避けられません。くわしく →
- 持ち帰り
- その場で決めず、自分の組織に相談することです。商流が深いほど頻度が上がります。くわしく →
あわせて読みたい
3.4 リスクの扱い方
属人化を含め、まだ起きていないことへの備え方。
4.1 チームのつくり方
集まった人を、機能するチームにするまで。
7.3 知識の引き継ぎ
頭の中にあるものを、外に出しておく方法。