「社員が不安を感じていると生産性は下がる」
山梨県でジュエリー業を展開する光彩工芸の深沢社長の言葉です。
まったくそのとおりですね。
私が自分の経験をかえりみて補足するとこんな感じです。
不安を感じる対象から自分の身を守るため、身辺の事柄に注意深く気を払う。
自分の発言や行動のどこにスキが生じるか定かでないため、他者に対して安易に自分の手の内は明かさない。
そんな状況の中、上層部からはこんなことを実施するように圧力をかけられる。
自分の立場に拘泥せず積極的に能力を解放し、長期的視野で創造性のある大胆な発想を心がける。
各自が培った経験値を持ち寄り「衆知で事を成す」という、組織ならではの強みを存分に発揮する。
青字と赤字の内容は矛盾していて、頭の使い方で言えば左脳と右脳を同時に使うようなもので、さすがに無理があります。
生産性の向上には付加価値を生み出すことが重要。
だからこそ、それに必要な「創造的発想」を阻害する環境は作らないほうが良いということが言えそうです。
造り手の魂が宿った基幹システムの影響
開発する際の「保身脳」が組み込まれた基幹システムは、表面的な機能と同時に「裏側の機能（ホンネ）」を持っている。
ちなみに「保身脳」が先行してしまう理由のいくつかを書いてきましたので、それらを読みたい方はどうぞ。
こうやって生まれたシステムは、使えば使うほど気づかぬうちに「ホンネのメッセージ」がサブリミナルで浸透してしまう。
すると実務上、本当に必要な意見が言いづらくなる謎の抑圧が常態化する。
『それが普通』となるので、外部からやって来た新人などの ”異を唱える者” は「教育」によって矯正されてしまう。
これは現場で遂行される業務の傾向に影響するのはもちろん、使っているユーザーの意識に刷り込まれることで組織の風土をも作ってしまいかねません。
効率化を目指した「使いづらいシステム」の矛盾
とはいっても基幹システムなので、企業会計と同じく『保守主義の原則』に基づくのは良いことだと思います。
手堅く、間違いをできるだけ回避する仕組みとして機能し、ミス発生で現場がリカバリー対応に追われて足踏み状態が続いたりしないようにするのが、基幹システムの存在意義のひとつですから。
しかし、その割には見落としや誤解が生じやすいデザインや、作業手順と逆順に組まれた動作に困惑させられるシステムは随所に見られます。
また、入力ミス防止の目的を阻害したいのか？とツッコミたくなるような、配慮の足りない注意書きが無造作に放置されていて、あたかも注意力訓練を受けているかのようなインターフェースに仕上がっている現場が多い。
そしてミスをすると多数のギャラリーが閲覧するメール等で指摘を受けるだけでなく、その後の関連事項のやり取りでは「RE：」「FW：」が付いたまま擦られ続けることになる。
そんな洗礼を受けると、その後はミスを避けんがために基幹システムとは別に、独自の管理用スプレッドシートを用意するハメに陥る。
主要情報を転記し、実務者ならではの極めて現実的／即物的なチェック機能を持たせ、重要なメモ書きは自作の表のほうに記述するなど「ナレッジ情報の塊」みたいなものを作って自己防衛しなければならない。
こうやって「タコツボ化」が進んでいる現場は、一体どれくらい有るのでしょう？
システム導入で難攻不落になる属人化
こうなってしまうと、会社が創造的発想で付加価値を生み出すためには、数多のタコツボを訪問してタコたちを説得し、彼らが誰にも渡すまいと必死で抱え込む暗黙知を引っ張り出すという、誰もやりたがらない仕事が最初に必要になる。
しかもタコたちには基幹（保身）システムのサブリミナル効果で骨の髄まで保身思想が染み付いてしまっているので、説得は容易ではない。
でもこれをやろうというのが要件定義（厳密には要求定義）です。
きっと、マトモにやろうとすればすさまじいバトルが展開することでしょう。
社内では「ノウハウを共有」といったスローガンが叫ばれるものの、事実上はそこを避けて表層的な話に寄せ、”システムの体裁” を作る流れになるのは仕方がない事かもしれない。
「平和な要件定義打ち合わせ」の真相
ということで、社員が不安を感じ、自分たちの身を守ることが最重要課題になっている状況でのシステム開発では、必然的に冒険的な試みが議論されなくなる。
それゆえに表面的には「安全な要件」しか出なくなり、会議のテーブルに臨んだエンジニアの視点では、かなり平和的な話し合いが行われているように見えるのではないでしょうか。
前に何度か書きましたが、知り合いのエンジニアが「要件定義の会議は、結構スムーズに進みますよ」と言ったことに驚きと同時に疑いを持ってしまった背景は、こんなところにあります。
＜雑談は続く＞
