OSを持つ、ということ

海外の外注先とトラブルが発生した。発注書で決めていた納期が守れそうもないというのだ。我々から彼らにインプットすべき仕様情報が不正確だったし、予定より遅くなったせいだ、と彼らは、いう。こちらから見ると、彼らが出してきた設計承認図や仕様書の品質が低く、かなりコメントをつけてやり直しさせる必要があった。おまけに、両者共通の悩みとして、われらがエンドユーザーである顧客がぐずぐずとなかなか決めず、リサイクル的コメントをつけてくる問題があった。だが、まだ設計の中盤なのに、じりじりとスケジュールが遅れていった。このままだと、下流工程の仕事にも影響が出かねない。

担当者は、プロマネに相談にいくつもりだった。だが、彼のチームのベテランは、それを制した。そのベテランは別プロジェクトに従事していたが、担当者のことはよく面倒を見ていた。
「いったい何を相談に行くんだ？」
－－このままだと2ヶ月近く遅れそうです。下流部門の仕事に影響がでそうなので、まずは報告に行きます。それで、どうすればいいか相談しようと思います。
「報告ってお前、対策案はあるのか。」
－－いえ。だから相談しようかと。
「そんな相談があるか。相手は忙しいプロマネだぞ。お前が、対策案をいくつか考えて、中ではこれが一番良いと思うので、これで行きたいと思います。ご承認お願いします、って持って行くのが筋だ。」
－－・・はい。
「そもそも、スケジュール遅れの原因は何なんだ？」

担当者は、上に書いた事情を説明した。こちらのインプットの遅れ、向こうの低品質、エンドユーザの不決断。それで、外注先の設計作業の生産性が落ちたんじゃないかと。

「ずいぶん曖昧だな。これまで何度も使ったことのある外注先だろう？　向こうの品質だって分かっているし、ウチのやり方だって慣れているんじゃないのか。この顧客とだって、はじめてじゃない。何かもっと別の原因があるはずだ。」
－－何でしょう？
「それをつかむのがお前の仕事だろ！　根本原因が分からなかったら、この先でまた同じ遅延問題が何度もぶり返すぞ。外注先に行って自分で見てこい！」

出張から帰ってきた担当者は、ベテランに報告した。

－－あの外注先は、コストダウンのために、今回から一部の設計業務をインドに再外注していることが、行ってみて分かりました。それがうまくコントロールできていないんです。
「やっぱりか。今回急に崩れたのは、何か原因があると思った。それで、どういう対策がある？」
－－向こうのマネジメントと話し合ってみたんですが、二通りしか策はないようです。つまり、向こうに時間を与えてちゃんとやらせるか、それとも依頼した仕事の一部をこちらが引き取るか・・

これはまあ、10年以上も昔に経験したことである。上の会話は分かりやすいようにレンダリングしたが、実際にはこんなにテンポよく進んだ訳ではなく、数週間以上かかり、いったりきたりした結果である。でも、全体の雰囲気はつかめたと思う。このベテランが担当者に諭したのは、二つのことだ。

・自分の中に対策をもたずに、上に相談に行ってはいけない。たとえ自分の案が不完全でも（その可能性は高いが）、自分はこうしたい、という意思を持って行くこと。

・問題が起きたら、応急的な対処だけでなく、その問題の根本原因をきちんと調べなくてはいけない。さもないと同じようなトラブルがまた発生する。

最初の点については、以前も「あなたは、どう考えるの？」（2014-09-28）　に書いたことだから、ここではこれ以上、繰り返さない。二番目の点は、問題解決における基本的な態度についてだ。

そもそも問題解決とは、次のような４つのステップを踏む必要がある。
(1) 問題の直接原因と影響範囲をつかむ
(2) 問題の波及を止める（応急措置）
(3) 問題の根本原因をしらべる
(4) 再発を防止する

このうち(3)(4)は、忙しいさなかには同時にできないかもしれない。だが、再発の可能性があるうちは、やはり根本的な解決が必要だから、放置はできない。上のベテランは、このことを指摘した訳だ。一度トラブルを乗り切ったと思っても、似たようなことが再三起きる。それは最初の原因解明が不十分だったからだ。

そして、何よりも大事なことは、上の4つのステップが自分の中で言語化されて、いつでも反射的に取り出せるようになっていることである。トラブルに遭遇し、問題事象に巻き込まれたら、この４つのステップが頭に思い浮かぶこと。それが『OS』化された姿なのだ。

問題解決には、とたえばRoot Cause AnalysisとかLogic Treeとか、いろいろな技法がある。有名なKJ法やブレーンストーミングだって、問題解決技法として登場した。だが、これらはいずれもツールであり、計算機にたとえればアプリケーション・ソフトに相当する。こうした技法を活かすかどうかは、じつはその下のレイヤーにきちんとOSが動いているかどうにかかっている。

OSとは、組織化され体系化された思考態度・行動習慣の集合である。それは個人レベルでも持ちうるし、組織内で共有するものでもある。組織内で、先輩から後輩に必ず受け継がれ、ブラッシュアップされていく仕組みができていれば、それは組織のOSと呼べるだろう。ただし、きちんと伝達され、受け継がれていくためには、（当たり前だが）それが言語化されていなければならない。そうしないと意識の層に上がってこないからだ。単なる職場の慣習で、後輩は先輩の背中を見て覚えるのみ。学ぶも学ばぬも、その当人次第、という状態ではOS化されているとはいえない。

OSがどういうものかは、OSがない状態を考えてみれば分かる。たとえばトラブルが起きる。それに対処する。そしてまた、次のトラブルが起きる。また対処する。つまり、外部からのインパクトやイベントに振り回され、必死に適応するだけの状態になる。つねに受け身で、後手後手の行き方、イベントドリブンな仕事のしかたになる。自分で先を見通せなくなる。

別の例を挙げようか。よく工場の製造現場では「5S」とよばれる標語が壁に貼ってある。5Sとは「整理・整頓・清掃・清潔・習慣化」の略だ（「習慣化」のかわりに「しつけ」という語が使われている場合もある）。5Sというのは、組織化され体系化された態度・習慣の集合で、典型的なOSである。何か材料を加工するとか部品を組み立てるといった作業や、そのための工具装置の操作は、アプリケーションである。このアプリがきちんとスムーズに動くためには、5SというOSが確立していることが望ましい。5Sが働いていないと、しょっちゅう材料のモノを探し回らなければいけないし、作業動線がぎくしゃくして怪我をしやすいし、機械は清掃不足で故障しやすくなる。だから、工場では口やかましく、5Sの徹底ということがいわれるのだ。

同じ事は、本当はオフィスワークでもなされていなければならない。あなたは書類がどこにあるか探し回ったことはないだろうか？　そもそも設計書や提案書に、すべてファイリングNo.は発番されているだろうか？　サーバの中を電子ファイルを探し回ったことは？　あるいは床に変なモノが置いてあるおかげで、つまずいたことはないだろうか。飲み物をこぼしてPCや書類をダメにしたことはないだろうか？　なぜ知的なるオフィスでは、そういう習慣は不要だと信じられているのか。

もう一つだけ、例を挙げる。わたしの勤務先では、顧客や発注先や誰とであれ、打合せを行ったら必ず議事録（MOM = Munites of Meeting）を書く。議事録には、打合せ内容、出席者、決定事項、アクション事項と期限、などが簡潔に記載されている。それをプリントアウトして、出席した客先や業者に、「たしかにこの通りの内容で間違いない」と確認のサインをもらう。後になって、言った・言わないのくだらない水掛け論を防止するためだ。

とくに客先との打合せMOMは表現に神経を使うので、1時間の打合せの議事録作成に1時間以上かかるのはザラだ。非常に面倒くさい。しかし、少なくともわたしの勤務先では、面倒だからといって省略する者はまずいない。むしろ、議事録がないと落ち着かない気分になるだろう。それが言葉を大切にする『記録重視』のOSとして、習慣化されているからだ。会社に入って、最初にしつけられる作業の一つでもある。

（以前書いたかも知れないが、何年か前、わたしは専務によばれて30分ほど製品開発プロジェクトについて相談した。わたしが席に戻るか戻らないかのうちに、当のその専務からメールが入ってきた。開けてみると、「さっきの打合せの結論はこれこれだったよな。」という、3行ほどの念押しの内容だった。腕利きのプロマネ上がりの専務は、忘れっぽい佐藤に頼らず、自分でMOMを書いてよこしたのだ^^;）

OSとは何か。それは、自分が行う行動を、毎回個別の、単独の行為として終わらせずに、繰り返し可能なシステマティックな行動習慣とする仕組みだ。トラブルが起きたら、「問題解決」の思考ルーチンを立ち上げること。打合せを持ったら、「記録」の行動ルーチンを回すこと。モノを生み出したら、「整理」のルーチンに入れること。

それは思考や行動の抽象化とも言えるだろう。標準化といってもいい（ただし「標準化」というと、全然別の杓子定規なものを連想する人もいるから、わたしはあまりOSの説明にはつかわない）。ともあれ、いったん身につけたら、いつでも、ほぼ同じレベルで繰り返せるようにすること、それによってムラなく効率よく実行できるようにすること。これがOSの力だ。

そういう意味では、「5S」の最後の用語は「しつけ」とするよりも、「習慣化」の方が適当だ。「しつけ」ではなんだか、働いている大人をまるで子ども扱いしているかのように感じる人もいるだろうし。

ただし。世の中の物事には、つねに両面がある。すぐれたOSを持つことは良いことだし、組織がOSを確立する事は、とても大切だ。だが、いったんOSが確立してしまい、パターンやルーチンができあがると、人はしばしば、なぜそのシステムが生まれたのかを深く考えなくなる。とにかく習慣だから、そうするんだ、と考える（深いレベルでは思考停止する）可能性が高くなる。おまけに、組織のOSをバージョンアップしようとなると、途方もなく大変な労力がかかる。みんな、習慣化しているからだ。

それでも、OSレベルの仕組みは非常に大事である。このサイトのテーマは「計画とマネジメントの技術ノート」で、ずっとEVMSだのAPSだのといったアプリケーション・レベルの話題をくわしく紹介してきた。しかし、最近わたしは、おおくの職場で抱えている問題はもっと深層の、OSレベルの問題ではないかと感じることが多くなってきた。それはとくに、いったん自分たちの得意な土俵の外に出たとき、顕著になる。

わたしは現在、海外プロジェクトのマネジメントをテーマとした新著を準備中だ。その本の中でも、知識や技法レベルだけではなく、OSレベルの思考・行動習慣について、あらためて光を当ててみたいと思っている。

＜関連エントリ＞
　→「あなたは、どう考えるの？」（2014-09-28）