業務を作れるエンジニアになろう

作ったことある？
唐突だが、エンジニアなのに業務を作ったことの経験はあるだろうか。「何で、エンジニアが業務を作ることがあるの？」と思った人は想像力をもっと働かそう。
ある業務があって、それを人手で出来るけれど手間が掛かるとか、ミスを犯しやすいとか、単純作業とか、費用が掛かりすぎるとかの要件があって、それを機械化する方法の一つがシステム化だ。言い換えると、組織の中の全体の業務の内のある業務の更に内を機械化することになる。システム化のサービスデリバリーを外部委託する場合、業務設計は委託側の顧客の役割であり、受託側のデリバリーサイドは、システム化する範疇において役割を担うことになる。そう考えると、業務を作る機会はデリバリーサイドのエンジニアにはなさそうだ。

経験がないとわからないこと
何事も経験がないと脊髄反射のようにひらめきも神からのお告げも降りてこない。独りよがりな思いつきは、受け入れられるようなものにはならない。業務からシステムを切り出すときもそうだし、そもそもの業務が分からなければ切り出しようがない。システム化のプロジェクトであれば、顧客とデリバリーは一体化したチームであるから、役割分担として顧客からデリバリーサイドに業務知識を移すことになるので何ら問題はなさそうだが、やはり仔細なと頃の勘所まで気付かないこともあるだろうから、フラストレーションを起こしても仕方がない。デリバリーとしては、新たに望むような業務のシステム化であるとき、顧客と強調的な関係を築くことが最初のハードルであって、如何に業務知識を水が流れるように取り込むことが必須のタスクになる。

一体、業務はどこにある
業務は顧客にしかないのだろうか。そんなことはないのである。プロジェクトのデリバリーサイドの開発プロセスやソレを取り巻く組織のプロジェクト管理にも業務は付きまとっている。プロジェクトの中の進捗管理、品質管理、課題管理それぞれ小さいが業務プロセスなのである。“それを行わないと仕事にならない”のであれば、ソレは立派な業務である。
業務を“これだけだ”と決め付けない。身の回りをよく観察することが必要だ。あちらこちらに見つけられるだろう。

業務設計の醍醐味
業務設計の醍醐味は、その業務設計を担当する人が業務の制約の中で自由に制度設計できるということだ。それはその担当者の采配により大変重厚な制度も作れるし、軽量な制度も作れることになる。そのは、その担当者一人の工夫で多くの人の手間を減らすことも出来るし、大変コストの掛かる作業にすることも出来る。
業務設計の醍醐味はココにある。一人が知恵を出し、キーパーソン達と揉むことで洗練された業務を作ることが出来るのだ。自分が作った業務で周りの人が動く。動いて成果を出す。どうだろう、なにか楽しそうではないだろうか。これこそ、醍醐味なのだと思っている。

副産物
この経験は、システム化の機能仕様を削るときに生きる。業務をシンプルに、分かりやすく作れるようになると、システム化の機能仕様で無駄なものや不整合なデータの引渡しなど、業務設計で洗練化した経験が生きるし、顧客と業務をシステムに落とし込むテーマを話すときに、普遍的なスキルとして生きる、という副産物的な効果がある。