無駄とは何か?

はじめに

ITに限らず昨今のプロジェクトでは「無駄を無くして効率的に作業する」ことが叫ばれている。
では、一体「無駄」とは何なのだろうか?
辞書を引いてみると「役に立たないこと。効果・効用がないこと。」とある。
しかし、個人的に思うのは「無駄とは未来への投資」であるということだ。

何故なら無駄か否かの判断には「時間(工数)」、「発動タイミング」、「効果」、「観点」の4つの要因が複数絡んでいるのだ。
それでは、それぞれの要因を紐解いてみよう。

(1) 時間(工数)

例えば、通常行う作業手順で、6時間(6.0h)掛かる作業があったとしよう。
この作業の一部を自動で行えるようにするために、11時間(11.0h)掛かった。
この場合、単純に計算すると、11-6=5と5.0hの無駄が発生したことになる。

確かに短期プロジェクトまたは一回きりの作業であれば、その通りであろう。
しかし、ことITでは、そのような作業は稀である。
初回作業だけ見れば無駄かもしれないが、長期に渡るプロジェクトでは、自動化の効率がボディブローのように後からジワジワ効いてくるのだ。
但し、残念なことに文字通りにジワジワなので、その効果が見え難い。
従ってこの手の効率化作業だとしても、プロジェクトマネージャー(PM)、プロジェクトリーダー(PL)の技量やプロジェクトの特性にもよるが、無駄と判断されてしまうことが多い。

(2) 発動タイミング

ここでの発動タイミングとは、無駄作業が役に立つ(役に立った)までの期間のことだ。

極端な例として「昨日行った無駄作業が今日役に立った」としよう。
この時点で無駄作業は「有効な作業」に昇華するのである。
では、この発動タイミングがいつまでなら無駄とみなされないだろうか?
この辺りはプロジェクトの期間にもよるが、個人的な感覚として、大概一ヶ月位だろうと思う。
これ以上長くなるのであれば「もっと後で行っても良いだろう」という部類の作業になってしまうためだ。
だが、一方で一ヶ月以内に必要になるかどうかは大抵不透明なのだ。

(3) 効果

ここでの効果とは、「(1) 時間(工数)」以外のことだ。効率と言っても良い。
(1)で挙げた自動化の例の場合、時間の他に「手動操作によるミスが防止できる。」という効果がある。
また、プログラムに拡張性を持たせた実装にしておくことは、後作業で効果を発揮する。
※プログラムにある程度柔軟性を持たせるため、拡張可能な実装とすることは、本来当たり前のことであるが、分かり易い例として記載した。

(4) 観点

本来前に挙げた「(1)時間(工数)~(3)効果」を総合的に鑑みて、無駄か否かを判断する。
しかし、主に管理者(PM/PL)と現場作業者では、その観点が大きく異なる。
また現場作業者のSE属性(SEの種類(職業SEと技術SE)参照。)によっても異なる。

なぜ管理者と現場作業者では、価値観が異なるかの分析については、別の機会にする。
ザックリ言えば、「見えない(数字に表れない)」、「新しい事を導入するリスク」の2つであろう。
特に「新しい事を導入する」という点においては、技術SEの方が積極的な傾向にある。
要するに、各個人の「先を見通す能力」の差がそのまま観点に表れるのだ。

最後に

ここまで書いて何だが、結局のところ何が無駄であるかは、非常に不明瞭である。
そこで主観的になるが「自分が必要であると思ったら他人がどう言おうと、その作業は行うべきである」という結論だ。その理由は簡単である。
貴方が行った作業は、そのまま貴方自身の未来のためになることだからだ。