全体最適の抱えるムダ

仕事がちょっと落ち着いてきたと何回か日記にも書きましたけれど、私が落ち着いているからと言って全員がゆったりと仕事をしているわけではありません。と言うか、私も落ち着いて仕事ができるほど、余裕があるわけでもありませんけれど、ちょっと前の自分を見るようなバタバタとした様子の人が周りにいると、手伝わないといけないかも、と言う気分になってきます。とは言え、年レベルで過重勤務が続いていた状態から２，３か月で万全の体調に戻るわけもなく、また、そこまでの余裕もあるわけではないので、あまり手のかかる手伝いはできそうにありません。

今の職場は（以前、書いたかもしれませんけれど）、割と古い体質の（もしくは近代的な働き方を維持するための努力をしていない）職場で、仕事があるとメインの担当を決め、その人のやり方で進めていますから、人の仕事を手伝うには、まず、「で、どういうやり方しているの？」から始めなくてはいけません。個人的には、標準化を進めたいところですが、できるのはせいぜい一番多そうなやり方を踏襲するくらいで、当然のことながら、一貫性はないし、次にやる作業との整合性も取る必要がありますから、あまりうまくいかず、結局はつぎはぎをうまくつなげて流すために別の独自性が必要になってくるという感じです。

ソフトウェア開発、特にオブジェクト指向開発では、こういう問題を解決するために作業を「カプセル化」（作業の中で、別の作業と干渉させない）し、メッセージパスと言う概念で授受する情報を明確にしてインターフェースをきちんと定義することで個々の作業を標準化しつつ、開発すべき内容を最小化することができます。つまり、カプセル化した「部品」を組み合わせてできることは、部品の組み合わせだけを設計すればよく、部品の中身を考える必要がありませんし、新たに作る部品もインターフェースだけきちんと定義されていれば、他の部品との「相性」を考えずに設計できるからです。

作業を最適化するために、ひとつの作業の途中で他の作業とまとめてできることを一緒にやろう、などとすると、その流れでは効率化できても、別の作業と組み合わせたときに非効率になったり、本来別のところでやっていた作業の成果を使うことができず、うまく仕事が回らないと言ったケースも発生します。これを防ぐための「カプセル化」ですが、最適化や「今の効率」を最重要に感じる人には、標準化はムダを詰め込んだ「非効率のススメ」に思えるようで、今の職場環境のような状況では「仕事のできる人」から反発を受けてなかなか受け入れてもらえません。と言うことで、私ができることと言えば、自分の周りでちょっとした標準化を提案してゆくことくらいでしょうか。