翻訳

学内のあるシステム発注に携わっていたが、結果として、発注しないことが決断された。お金のこともあるがここでは置いておいて、システムを発注することについて考えさせられた。

システムを発注するというのは、仕様書を作るということである。請負業者によってシステムはあくまでも仕様書通りに作られるので、発注する側といえば、仕様書を作ることに他ならない。

今ある業務、またはこれからやりたい業務を、すべて文字情報として翻訳することは、とても難しい。人間が考えていることはもちろん、無意識で共有されていることも含めて、客観的に記述しなければならない。ある意味、仮想演習に似ている。

仕様書のたたき台ができたら、それをが自分たちが望むことに合致しているかをチェックするのも、一苦労だ。これも仮想演習に近い。

さらに厄介なのは、システムに望むことを、メンバーで一致させること。 これは、仕様書を作る以前の問題である。システム発注に慣れていない中で、直列のこの事象を、並列に行っていたのが大きな問題のように思う。その問題あることが問題ではなく、そういうメンバーが携わらなければならないのが問題なのではないか。

携わったメンバーは、全く悪意はなく、非難されるほどの責任はないと思う。でも、集合体となった時に、これがシステム発注に対してベストな布陣なのか、という、マネジメント側の責任はあるのではないか。

何にしろ、レビューは必要なので、自分なりに分析して、私の糧にしたい。少なくとも10個くらいは思い浮かぶ。ただし、このレビューの行為は、私以外には必要とされていないようなのは残念だ。

多くの人が使っているある会計に関するシステムの評判が非常に悪いが、これも問題の根底がこの風土にあるのではないかと思ってしまった。


翻って、日々の学生との研究打ち合わせにおいても、日本語でやり取りしているようで、実はお互いに意思疎通が図れていないことも、少なからず感じることがあった。どうやって、考えを共有するか、改めて日々考える。


（他にも事例があり、まだまとまっていないので、今後推敲する）

メモ：
機械や試験装置の使い方の本質を理解すること→表面的な動かし方の真似、→手順書の書き方
研究室で動かしている取り組みの本質を理解すること→作業になっていやしないか