圧力

「結局のところ、コストに縛られるな! と云う結論になってしまった。」

「開発者にプレッシャーをかける」ってヤツは、なかなかやっかいだ。厳しい条件を設定しておいて、高い生産効率を維持しようとする考え方があるらしいのだが、こんなやり方は時代遅れだと考えた方がいい。少なくともシステム開発に適用するのは望ましくない。なぜなら、期日に合わせて内容の水準を落とすことが可能だからだ。

上流工程なら、論理的整合性は確実に犠牲になる。見た目だけを整えた正確さを欠いた成果物ができあがる。それは、レビューでは発見することはできず、後ろの工程に持ち越されることになる。実装の場合なら、保守性を確保するための工夫が犠牲になるだろう。思考を重ねて抽象化し、余計な処理を記述しないようにする工夫はされなくなり、表現が統一されてなかったり、似たような処理が散見されることになる。発見した問題をこまめに報告するといった地道な作業も犠牲になるだろう。

短期間の一時的なプレッシャーなら、生産効率が向上することもあり得るが、長期間に及ぶなら、間違いなく逆効果にしかならないし、まともに計画を立てられない管理者だと思われることになる。部下の評価と上司の評価は違うのだが、本当に生産効率を上げようと思えば、部下の評価は大事にした方がいい。

1. やり方を縛らず、結果を縛る。これは、完了条件を明確にするってこと。
2. 仕事を単純化する。単純で大量生産可能な仕事を組み合わせて複雑な仕事を実現する。
3. 曖昧さを排除する。
4. 短期間の完了を設定する。日毎が望ましい。確実に達成できるものであること。
5. 早帰りを推奨する。率先して早く帰る。
6. 必要に応じて、工夫したやり方をアドバイスする。

完了条件と確実にできる量を明確にすれば、余計なプレッシャーなんかかけなくたって、仕事は順調に進む。少しずつやり方を工夫してゆけば、余力も生まれるようになる。そうなれば、少し仕事量を増やすこともできる。まあ、でも、20% 程度の余力は残して、そこは次の仕事に向けた準備作業に充てた方がいい。

これを実現するのは簡単ではない…らしい。まあ、いい加減な判断で開発者に「xx月xx日までに完成させなきゃいかん!」と効果のないプレッシャーをかけるよりは難しい。仕事を適切に分割して、完了基準を設定して、実現可能なボリュームを見極めなきゃならない。今日から突然できるようなものではないかもしれないけれど、開発者にプレッシャーをかけるってのは、非科学的で慣習的なもので、プロジェクトを破綻へと導くばかりだから、そこからの脱却は目指すべきだと思う。でも、しんどい事ばかりでもなくって、副次的に楽になる仕事もある。根拠薄弱な遅延理由を説明したりする時間はいらなくなるし、基準のはっきりしない効果の薄い進捗報告も作らなくてよくなる。開発チームが迷走することもなくなる。

…理想論なのかなぁ…。

どうも「技術者をフルに働かせないと費用対効果が悪い。」と云う間違った価値観に縛られてるだけのような気がするのだけど…。