新規業務を設計できるエンジニアと再現するスキル

1人のエンジニアの仕事を、後からヘルプするような形で入ることになった。その仕事は1年前からやっていたようだがなかなか進まなく、トラブルも起こしていたらしく、テコ入れすることになり、呼ばれた、といういつものパターンと言ってはパターンである。

やることと言えば、あるルールの雛形を使い、これまでやっていなかった開発部門に新規業務として導入するだけである。だけ、であるというのは自分としてはこんな感じでやればいいのだろうと見切れているか、たかを括っているだけのことでしかない。

これまでに経験してきた新規業務の導入や組織づくりの中で構築してきた業務から言えば、見切れているの方がニュアンスとしては正しいだろう。

ヘルプするエンジニアの1年間の結果をみていると、1年前はさぞかし大変だったのだろうと思う。1年前からの活動の結果はアセットとして残っているのだが、とても褒められるようなできではない。全体の構成に違和感を持つコンテンツが混ざっていたり、構成が乱れていたり、プロシージャを洗練する時間も取れなかったのだろう。

とてもひどい状態としか言いようがない。

酷さを端的に言えば、アセットを見て業務を再現できないのである。業務なのだから、インプットを整理させながら、受けれられる条件を満たしているトランザクションだけを決めた手続きで処理し、結果は期待する結果の範疇に収まらせなければならない。

自分の感覚では、プログラムを書けるのなら、新規業務は作れるはずた。その理屈は次のとおりある。

  • インプット
    制約条件、前提条件を満たす入力情報であるかを検査する。
  • 処理
    インプットを手続きをルールベースで加工し、アウトプットの仕様に適合しているかを検証した上で、処理を終了する。インプットの加工、中間、最終的な情報の検証は、他者(他部門の権限所有者)のケースがある。
  • アウトプット
    仕様に適合する状態。

どう見てもIPOでしかない。そう書いているから、と言われるとそう書いているのでご指摘のとおりなのだが、システムはもともと業務の機械化であるから当たり前なのである。

逆に言えば、新規業務を建てつけ、導入できない人にシステムのデザインをやらせてはいけない、ということを示唆しているのかもしれない。残念ではあるが、正しそうな気がする。そういう嫌いのあるエンジニアには、単一的な機能モジュールしか任せられないということになる。

システムの内部であれば、何かしらのチャートのフォーマットとして描ければ、エンジニア間ではパタンを伝えられるのでコミュニケーションが成立しそうではあるが、これが業務となると非エンジニアも業務関係者に入ってくるのでパタンを使えない。そうするとコミュニケーションできるプロトコル、つまり業務フローなどで会話しないとどうしようもないが、パタンはかけても業務は描けない(か、描きなればいから伝わらない)。

単に経験する機械の問題なようにも思えるが、新規業務を作る機会自体少ないので中々解消はし辛い問題なのかもしれない。

 

 

RPAのはじめかた ~ツールを見ながら巡る! RPAの楽しい世界

RPAのはじめかた ~ツールを見ながら巡る! RPAの楽しい世界