中身の分からないEUCの山で生き延びるには　その2

前回はこちら

ブラックボックスなシステムの中身を解き明かすのは評価に結びつきづらい仕事である。今ある仕事を改善するわけでもなく、ただ「こう動いてる理由が分かるようになった」というだけだから。

しかし、この仕事はその後に続く業務改善や教育への足掛かりとなる。理由が分かると、他人とコミュニケーションをとる上での説得力が全く違ってくる。

システムは目に見えないものだが、作り替えるには他人とコミュニケーションをとることが避けられない。そのときに必要になるのが話し合いの土台となる文書やイメージ図である。

そして、構造がちゃんと分かっている人じゃないと分かりやすいイメージ図は書けない。(逆に相手の理解度を確かめようと思ったら、イメージ図を書いてもらうとよい)

ということで、ブラックボックスになったEUCを解明する上で、私のやっている取り組みを紹介しよう。

①一つのEUCをディスカッションしながら読み解く

効率だけ考えると、「5人の人間が並行して5つの別々のEUCを直す」のが良さそうに感じる。

しかし、この方法が効果を発揮するのは、全員が独力でやり抜くだけのスキルを保有している時だ。

そこまで至っていない時は、有識者も初心者も交えて一つのEUCを議論しながら読み解く方法をとることにしている。

これにより、有識者がEUCのどこに目をつけて原因を突き止めているのかという思考回路を体感することができる。この教育的効果は非常に高い。

各自が並行して別々のツールを直している時でも、この方法を織り交ぜることで自身のツール修正のヒントを得ることができ、一気に仕事が進む場合がある。

②EUCの一部を構造図に書き表す
EUCメンバーに若手がいる場合、ツールの肝となる機能を文書化する課題を与えてみてはどうだろうか。

はじめはクエリやモジュールの一つ一つを箇条書きで書かせ、最終的には要素の一つ一つを線で紐づけ、構造図に仕上げてもらう。

多くの人が悩む「ドキュメントがないことによるブラックボックス化」と、メンバーの教育という一挙両得を狙う方法だ。

③仕事で関連するメンバーをどんどん引き込む
運営が軌道に乗ってきて、「EUCの問題はとにかくここで議題に上げよう」という習慣ができると、EUCの情報を集中的に浴びる場が形成される。

すると「ここに参加すればEUCに詳しくなれる」という期待が形成され、EUCに関心のある人を惹きつける原動力になる。

そのような噂を聞きつけたら、上司と掛け合ってすかさずメンバーに引き入れてゆく。するとまた新しい視点が提供されて、議論の活性化に繋がる。

私も会議の進行役をやるだけでどんどんEUCに詳しくなることができ、内心ホクホクである。

続きはこちら