あなたの会社も要注意！「善意の行動」が仕組みを破壊するメカニズム

Tweet

Pocket

システム開発の落とし穴は標準化

　私が開発したモデルは、Excelをつかった簡単なRPA （ロボティクス）による余剰在庫撲滅のためのロジックを組み込んだ6MBもあるシステムである。

　彼が、私をスルーし、クライアントと勝手にどんどん進めるものだから、止めようにも止まらない。彼はクライアントを抱え込み、自分のやりたいように夜遅くまで働いたかと思ったら、朝は遅刻をしだした。彼の説明は何がいいたいのかわからないデジタル用語のオンパレードで、クライアント側は「横文字も知らないのか」と思われるのを嫌ってか、質問はゼロだった。

　このままでは組織もプロジェクトもめちゃくちゃになると危機感を感じた私は、とうとう彼をチームから外したのであった。

　このように、魔物はクライアント側にも、そして、コンサル側にも住んでいる。すべて、自分の力の過信と無責任（自分にはカットオーバーの責任はないので、思いつきレベルの助言のつもりでいる）が原因だ。

　これは特に「標準化」に対して、重要性を理解していないことが原因である。 

　私は16年アメリカ企業に勤めていたので、「標準化」についての重要性を熟知している。日本人が考えているより遙かに厳しいコード（やりかた・様式）があるのが外資である。特にものつくりの「標準化」は、現在と過去、現在と未来、一個と複数、一個と別の一個など、ありとあらゆるパーツがそのまま一定の法則で作られているため、人が急にいなくなっても代わりの人が代替できる。

　　「そんなこと、当たり前じゃないか」という声が聞こえそうだが、きれいに標準化ができていて、チームプレイが当たり前の組織というものを見たことがない。みな、唯我独尊。自分達のやり方が数千、いや、時に数万分の一の特別な手法でやっているため、バリューチェーンがメチャクチャになるのだ。

 　 「システム」というものは、すべてのプロセスが繋がっており、あるプロセスが実行される場合、その前のプロセスがトリガーとなる。このように、ドミノ倒しのように、最初の一打がドミノをどんどん倒し、大がかりなシステムを動かすのだ。これに対し、現実の業務というのは、「調達部」「企画部」「販売部」などで、自社の業務範囲がきまっており、主に部門をまたいだ業務のやり取りは印鑑のついた書類でなされる。

　その感覚で、「ああ、ここはおれの業務範囲だから」とやりたいようにやってしまえば、そのプロセスがトリガーとなって実行される大規模なシステム全体の動きに不具合が生じてくるわけだ。Excelでつくった業務支援システムや、AccessでつくったイントラネットベースのRDB（リレーショナルデータベース）もすべて止まってしまうのである。これは、「無自覚の無責任」といって、自分の狭い見識の中でシステムを自由に動かせると考え、自分には責任がないから、そのために起きるシステムの不具合には一切責任をとらないということがおきてくるのだ。

　くどいようだが、システムのプロセスはすべて繋がっており、たとえば調達部のプロセスは余剰在庫の簿価評価に連動するため、何か1つの項目を変えるとまったく別のところで不具合がでてくる。その結果、何が原因となってこのようなことになっているのかが分からなくなってしまうのだ。 

　この問題がややこしいのは、「無責任のアドバイス、あるいは、命令」をした人間とて、もともとはシステムをめちゃくちゃにしようと思ってやっているわけでなく、「よりよくやりたい」という思いからやっているということだ。したがって、みなが「良い人」だし「うまくシステム化が進むことを願っている人」であるということなのだ。

 　この問題、このように文字にすれば極めて簡単であるが、やり取りの中で一度ボタンを掛け違えてしまった。そこから喧嘩になり、どうでも良いようなところで開発がスタックしてしまうなど、人が多く集まればそれだけ複雑性が増し、人が多く集まれば、それだけ考え方もいろいろでてくる。このように、善意の行動がシステムの仕組みを壊してしまうメカニズムはよく理解しておきたい。

参考になった