なぜ、ワタシたちは無意識に経験したことを前提を置いてしまうのだろう

ワタシたちは、と言うより“人は”の方がよりしっくりするかもしれないですけど。以前のプロジェクトでは、複数のシステム環境を作ることになっていたんですね。「多いの少ないの？どっち？」と訊かれたら、「多いよ！」って言うくらい多かったですね。

でね、一番最初のシステム環境の導入、構築、試験をするときは、それはもう準備不足全開で突入しようとしていたので、

「なんですか。」
「週末から構築するシステム環境の準備は終わってる？」
「持っていくものは整理しました。」

「(えらいね。でも確認しておこう。)」
「持っていくものリスト作った？」
「いいえ。」
「(ふぁ！それでどうやって忘れ物がないか確認するのよ？)」

「現地での作業リストは？」
「いいえ、作っていませんよ。」
「(ちょっとまって♡)」
「(だから、それ何で作業が終わった、って確認できるわけ？)」

冗談かと思うかもしれないけれど、現実に合った話です。はい。一から十まで指示することはしないようにしていたのは、それをやっちゃうとメンバが全く何も考えないで受け身で仕事をするから、なんだけれど、それにしても目が点になるというか、呆れるというか。

当時のプロジェクトチームのメンバはそのプロジェクトで初見だったこともあるんですが、少なくともワタシとの作業品質に関する価値観があっていないかったのはずっと驚きっぱなしでした。

作業は求めるアウトプットの品質を確保するためにするものである
ちょっと脱線です。上の遣り取りでは、少なくともワタシとメンバの作業で得たいアウトプットは同じだったんです。それはそうですね。設計したシステムを作る、という点において違いあればそれはそれで大変なことですから。

ところが、その作業によって得ようとしているアウトプットが設計どおりに作られているかを担保するエビデンスに関してワタシとプロジェクトチームのメンバと違ったんですね。いや、違うというか、“担保を確保していないといけない”という発想がなかったんですね。

そんなんでシステムを構築しても、その作ったシステムが設計どおりであると説明できなければ顧客承認は得られないし、最悪、多くの作業がやり直しになってしまうんですよ。時間もお金もパーになってしまう。そういうことを多分ですが考えたこともないんだと思うんです。これまで誰も教えてあげなかったのでしょうか。

一度経験したことは良くも悪くも財産になる
そんなこんなで、直前に準備をさせ直して、作業品質を確保するためにも作業計画を作らせて、エビデンスを取るようにして、現地へ向かわせたんです。で、そこそこの規模のプロジェクトでしたから、多分に、同じように準備不足だったチームがゴロゴロしていたようで、それこそNWやサーバや連携するシステムから炎上して煙が上がっている状態だったようです。

まぁ、自分たちの仕事は作業リストに沿って終わらないとそれはそれで拙いので、終わらすために現場合わせ的に情報を収集して辻褄を合わせるわけです。

ここで後の作業に影響することを織り込んでしまったんですね。

そのときの整然としてない作業での情報を正としてメンバが認識してしまったんです。これ、怖いです。人は刷り込まれちゃうと自然とその刷り込まれたことがデフォルトというか思考の標準値になるので、そのあとに続いてシステムを構築するときの作業リストや準備するものや入手する情報の前提を一番最初に経験して得たものに“無意識”にしてしまうんです。

で、それ、前の混乱しながらもシステム構築したときの話であって、次のときのシステム構築ではそれのままなのかどうかは誰もわからないわけです。大体にして、そうしたものはカウンターとなる人がいるもので、そのカウンターとなる人がその人の都合で決めちゃうんですから。

そう、カウンターとなる人の都合で、一番最初のシステム構築ではこうだった、という前提が“変えられちゃうかもしれない”ということを想定しないんですよ。これは怖い。

自分の裁量で都合でコントロールできないことについては、いつでも“変わっている”と思って臨まないと当日痛い目にあいますよ。

後日……

「現地に行って環境を確認しているんですが。」
「(が、と言っている。よくないことか？)」
「端末からサーバにアクセスできません。」
「(あー、前乗りして通信関係チェックしておけばよかった……。)
「じゃあ、一応、接続の申請書を確認して。」
「次に、ルーティングのログとって。」
　：