そういう仕事に対して、まず、疑問が起こる点は、作図された 「対象 （仕事の体系）」 が網羅性を実現しているのかどうかという点です。遺憾ながら、網羅性を担保している点を、いままで、どの システム・アナリスト も示してくれませんでした。

　さらに、４人の システム・アナリスト が同じ事業を作図したのですが、４人とも、それぞれ、相違する絵を作図しました。そして、いったい、だれの絵が 「事実を正確に記述している」 のかという点を、だれも証明してくれませんでした。そのなかの一人は、（ぼくの追及に対して、） とうとう、開き直って、「でも、エント゛ユーサ゛ に訊いて、作図したのです。」 と言いました （苦笑）。エント゛ユーサ゛ は、かれの絵に描いてあることよりも、もっと、仕事の手続きに関して、情報をもっているということを、その システム・アナリスト は知らないのでしょうか。

　逆に言えば、job-analysis は、それぞれの システム・アナリスト が、それぞれの視点で作図して、「わたしは、（エント゛ユーサ゛ の言ったことを） このように理解しましたが、わたしの視点を信用して、これ以後の システム 作りを任せてもらえるでしょうか。」 というための 「踏み絵」　なのかしら。だとしたら、それは job-analysis と云わないで、入札のための信頼度 テスト であるとしたほうが的確でしょうね。
　そして、それが、もし、理解度 テスト であるとしたら、「現状を正確に記述する」 という作業は、そのあとで、いつ、されるのかしら。

　もし、エント゛ユーサ゛ が、システム・アナリスト といっしょになって、絵を喜んで作図しているとしたら、その エント゛ユーサ゛ は、所詮、仕事の手続きを 「言われたとおりにやる」 使用人にすぎないでしょう。そして、もし、仕事の手続きを 「（余計なことなどしないで、） 言われたとおりにやる」 という体制であれば、正式な 「マニュアル （手順書）」 があるはずです--したがって、それを読めば、改めて、粗い絵など作成しなくても良いでしょうし、もし、マニュアル どおりに仕事が進められていないのであれば、その点を検討すれば良いでしょう。
　また、マニュアル がないので、マニュアル を作るのであれば、作業日報を記入して、作業日報を再体系化すれば良いだけの話でしょうね。しかも、作業日報には、労働時間が記入されるので、仕事の網羅性を検証できます。
　作業日報を読めば、実際に営まれている仕事を理解できますし、網羅性を検証しますので、システム・コンサルタント のぼくにとってみれば、それで充分なのですが、それを、わざわざ、商品とか倉庫とかを icon 化して荒っぽい絵を作成することの意味を理解できない、、、。

　また、仕事のなかに 「潜在的な問題点 （issue）」 があるというのは、仕事の手続きが効率的ではないということじゃないのであって、仕事のなかで使われている （管理されている） 「情報」 が不備である （効果的ではない） ということでしょう。

　Job-analysis という作業は、エンシ゛ニア として、30歳半ばを超えて、現役の フ゜ロク゛ラマ として、もう、働けないので、キャリア・ハ゜ス 上、フ゜ロク゛ラマ を終えた (?) エンシ゛ニア たちの食い扶持を得るための作業なのかしら。

　
　（2005年11月 8日）