I don't think so !

じゃあ、お前はどう考えるのだ!

海王丸と富山湾の曇り空

サラリーマンとしての基礎的能力は訓練によって身につけることができる/思考能力編③

<プラス・マイナス型思考法>

長所・短所型思考法と言っても良いが、物事にはだいたいにおいてプラスもあればマイナスもある、その両方に着目して考えなければならない、ということだ。ところが実際にはこれができない社員が多いし、これができないと大きな失敗に結びつくこともあるため、サラリーマンには必須の思考法なのである。

絶対的な正解がないという問題や課題は会社の中では意外と多い。というか大多数かもしれない。人事異動や組織変更を考えると分かりやすい。社員の異動や部署の分割あるいは統合を検討する場合、その決定は常によりましな方向になるだろうという期待のもとに行われる。4÷2=2のような正解がないのだ。だから実際にやってみて事態がより悪化するような人事異動や組織の再編は頻繁に起こる。

これができない社員が多いのは、目の前の問題に目が奪われ、その解決策としてマイナス面にのみ着目して、解決策を考えるためである。他人の書いた提案書、いま使用しているシステム、会社の組織など、すでにでき上がっているもの、いま目の前にあるものの欠点や問題点を指摘するのは、実は誰にでもできる簡単なことだ。その簡単なことを声を大にして言いまわるのが社内評論家だ。アホでもできる社内評論家。

実際にあった例だが、5系統の生産ラインの稼働データを5台のサーバで処理しているシステムがあった。ところがサーバのリプレース時に、処理するデータ量が少なく、CPU負荷も低かったために1台のサーバで処理するように変更してしまった。ところがこれが思わぬ事態を招いた。そのサーバに不具合が発生したとき、5系統の生産ライン全てが停止してしまったのである。

初期の生産ライン構築時に、生産現場は設計業者に対して「生産ライン停止の回避」を第一優先として要請していたため、5台のサーバによる冗長化構成となっていたのだ。しかもサーバ同士が相互に稼働監視し、不具合を検出すればリカバリーする仕組みも組み込まれていた。つまりどのサーバが故障しても5系統の生産ラインが停止しないよう2重、3重の安全策が組み込まれていたのだ。

そうした初期システムの設計思想を理解していなかったため、単にサーバの購入コストや台数が減ることによる管理コストが下がるという判断で1台のサーバに処理を集約してしまったのである。このとき、

生産現場の意見を聞く

②設計者に設計思想を聞く

③なぜ5台のサーバによる冗長化構成となっているのか理由を考える

④初期システムの仕様書を最後まで読む(仕様書の前半にデータ処理仕様、後半に冗長化構成やサーバ同士に相互監視システムの仕様が記載されており、前半だけを見てシステムの内容を理解したつもりになって、その部分のコピーを新しい開発業者に渡していた)

⑤2台のサーバによる冗長化構成にする

のいずれかをやっていれば防ぐことができたミスである。少なくとも⑤ぐらいは考えて欲しかったが、ミスやトラブルが発生するときは、このようにごく基本的なこと、ごく当たり前のことができていなかったケースが多い。新しい仕事に着手するとき、考えるべき要素が多くあるため、ポロポロと基本的なことや当たり前のことが脱落するのだ。

最近はコンピュータの処理性能が向上し、リアルタイム化が叫ばれる中、同様の実例を良く耳にする。たとえば1日に1回の処理を1分に1回の処理に変更したりするときなどは要注意である。1日に1回の処理の中で確立していたルールが、1分に1回の処理に変更したとき必ずしも保障されなくなるからである。1日1回と1分1回の処理とでは世界が異なる。世界が異なるとルールが異なる、ということだ。

さらには1日に1回の稼働確認で終わっていたことが、1時間に1回確認しなければならなくなり運用コストが上昇したりする。

物事には常にプラスがあればマイナスがある、マイナスがあればプラスがある。目の前のマイナスは、実はもっと大きな他のマイナスをカバーするために敢えて採用されている方法かもしれない。スクラップ・アンド・ビルドやリニューアルが成功するかどうかは、このプラス・マイナス思考法ができるかどうかにかかっているのかもしれない。

この思考方法の訓練は極めて簡単だ。誰でもできるマイナス面を、まず、書き出す。次にマイナス面以上の数のプラス面を書き出す。マイナス面以上の数のプラス面を書き出すことが重要だ。その上で、自らの判断を書き加え、回覧して意見をもらう、それだけだ。社内提案書などでも、なぜそのような選択をしたのかの判断根拠として、マイナス面、プラス面を記載することは、社内評論家を撃退するためにも有効である。