コンサルタントの眼
第２回 「今、必要なチェンジとは？」 by 石川 恵美
"It's NOT my job."
昔、外資系エンジニアと話した時によく聞いたセリフである。
経済が右肩上がりの時代には、営業、管理職、設計者、プログラマー、マニュアル・ライター、…とそれぞれの業種毎に専門家を呼び寄せ、縦割りで、専門性の高い仕事の振り分け方で、膨大な量の業務を乗り越えてきた。
１つのシステムを構築するには、要求仕様作成、設計、製作、テスト仕様書作成、デバッグ、マニュアル執筆、推敲、リリースまでの間には、種々雑多な仕事が降り注ぐ。
１人のスーパースターが、それぞれの工程に関わっていたのでは、到底、業務を遂行できないという状況下で、上流工程、コーディング担当、テスト担当、マニュアルライターとSEは専門性を高めてきたのである。
しかしながら、小さい組織で同等のレベルの業務をこなそうとすると、大企業のような縦割り担当の工程進捗では、当然の如くリソースが不足する。 必然的に、一人何役かをこなさざるを負えない。 しかしながら、それは、システムもしくは、生産ライン、装置に対しての深く理解を促進する体制でもある。
アトリエ イシカワでは、沢山のリソースが贅沢に準備されているわけではないので、大抵、設計者もテストを行い、マニュアルのコンテンツに対して責任を持たされる。
たったひとつの数値であっても、それが絶対値なのか？相対値なのか？どこを基準にした値なのか？単位は？どこで有効無効を切り替えられるの？ジョブレポートのどこにロギングされているの？本当にシステムを理解していないと、マニュアルは書けないものである。
ほんの少しでも、ライターに迷いがあると、伝えたいことは読み手に伝わらない。
読み手に伝わらない機能は、どんなに優れた設計であっても、長くは使ってもらえないものなのだ。
ソフトウェアとは、卓越したハードウェアの特性を使いやすいサービスとして提供する手段である。サービスの受け方を知らないユーザには、その装置の素晴らしさはわかってもらえない。
設計者がマニュアルに責任を持つ体制にすると、これまた必然的にどんなソースコードを書いているのか、非常に気になる。
この処理の最中にエラーが起こったら、どうなるの？ どのようにオペレータに通知されるの？シーケンスはどこから再開できるの？
画面の表示はどのようになるの？設計時点で構築したビジョンに沿っていないコーディングがされていないか、入念にチェックをする。
これも、設計時の理念をプログラマーに全く伝達損失ゼロで伝えることは難しい。
しかしながら、この部分を怠ると、スムーズなものづくり、システム構築を行うことは不可能である。
ゆえに、システムに関する質問は、何遍聞いても怒らないこれがアトリエ イシカワの方針の一つである。
同じことを何度か聞く場合、それには、２通りのケースがある。
１つは、視野視点が変わってくると、以前に疑問に思わなかったことが不自然に思える場合だ。「あれ？あっちは、こうで、こっちは何故こうなの？」と。
これは知識が増えれば増える程、意外性も増加することに類似する。
進化の過程においては当然のことであるゆえ、むしろ尊重すべきことなのである。※１
もう１つは、「聞いていない」タイプである。
これも、聞いていなかった理由は、いろいろあるかもしれない、ケアレスミスとはいうものの、バッドラックが不運にも重なった場合、一番反省しているのは本人かもしれない、これを尊重したいためである。※２
それゆえに、ミスは１度２度では怒らない。 では、全然怒らないかというと、そんなことはない。
３度４度めは、ダースベイダーに匹敵する。何故なら、３度４度は、プロとしての意識が欠けているからである。 これは地鳴りがする程、恐ろしい。怒られていない人まで、その空気に包まれるのであるから、本当に回避したいものである。
実際のところ、蔑んだ表情で「なんで今頃そんなことを聞くんですか？」この言葉は禁句である。一番恐ろしいことは、担当者が怒られることを恐れて、質問せずに自分の思い込みで進めてしまうことである。
これは、上下の信頼を失うだけでなく、品質低下の最たる原因となっている。
アトリエ イシカワでは、この言葉は許されない。これを言ったほうが、ペナルティを食らうルールになっているのだ。
さて、※１※２の状態で、通常の状態と同じマネジメントで遂行できるか？というと、そうではない。
この時点では、必ず"要ウォッチ状態"とする。
担当者同士の情報伝達、理解のレベルの確認を更に強化する必要がある。これを「のりしろ」と呼ぶ。
具体的に何を意味するかというと、「そこに疑問があるということは、ここは大丈夫か？」というように、問題のあった部分の関連について、相互の理解を確認しあう＝のりしろを確認して張り合わせるのだ。仕事は、拙い伝言ゲームであってはならない。
システム構築の際には、自然と水面下で何度もそのようなことが発生しては、解決していく。
担当者に自覚があれば、それぞれのシステムへの理解が促進され、目的地に向かうベクトルは、それぞれ結束していく。
最終的に納品検収が完了するということは、こうしたことの積み重ねになっているものである。
本当に面倒ではあるが、階段をもう一度降りて、赤子の手を引っ張って、一緒に登る訓練をするくらいの忍耐も必要だ。
プロジェクト・マネージャ、プロジェクト・リーダとは、このことを自然にこなせる人を云う。
組織で人が育たない、という話は、本来はこの「のりしろ」を最適に張り合わせることができないことを意味する。 最適「のりしろ」を判断するためには「見通し力」と「想像力」が必要なのだ。専門性重視の縦割り構造であっても、自分の担当部分が他にどのような影響を与えているか？を想像することができれば、育つことは可能である。
冒頭の"It's NOT my job."と言っていては、のりしろが不足する。
理解不足のプログラマーを責めるより、十分理解できるほどに努力したか？を自身に問うことが先決だ。 自分のほうが仕事ができることを誇示するタイプは、プロジェクト・マネージャ、プロジェクト・リーダには適さない。
プロジェクトがうまくいかない理由は、この部分にある。
どんな装置を作りたいのか？ どのように発展するシステムをビジョンにもっているのか？
それが明確になり、実感すると、不思議と仕様書の行間をくみ取れるようになり、おのずとプログラマーも不明点が明確になり、質問内容も高度になっていく。
そして、マニュアルを書く時点では、こうした不安点が削ぎ落とされるようになり、不思議なことに、マニュアル・エディタが一度も本物の装置を触ったことのないのに、熟練工のように語れるようになるのである。
何度かこのような経験を繰り返し、人間の持つポテンシャルは、本当に予想できないものだと私は実感している。
日本の製造業はこのようにして、試行錯誤を繰り返し、不可能にチャレンジして進化してきた。 だが、コンサルタントの眼：第１回「批判する時、される時」で果田が指摘するように、縦割り社会の中で、日本の製造業の品質と競争力に陰りが出てきてしまった。
「昔は上司の背中を見て、仕事を覚え成長したものですが、今はそのようなことは通用しないようです」と残念そうに大手営業がこぼしている昨今、もう一度復活するためには、ものづくりの現場において、「のりしろ」役を意識して配役してみると、縦割り構造の組織の中で、潤滑油になると推進している。
今、製造業に必要なチェンジとは？ それは、のりしろ役！
アトリエ イシカワが関わるプロジェクトには、この「のりしろ」という数値化されない機能ではあるが、業務遂行の最もボトムをささえる力を働かせている。
またビジネスを長期的に成功存続するための戦略も数値化されない。ただ、ほんの少しのジャッジ力の差が、実は数年後に大きく岐路となるケースを次回以降にご紹介する。これも形にも数値にも残らない。
だか、本当に大切なことは目に見えないものなのだ。
2010/03/15
石川 恵美
-
国内精密制御装置メーカ勤務後、1994年アトリエ イシカワを設立。
専門は、半導体製造装置、検査装置、製造管理システム。
アトリエ イシカワ代表取締役 装置プロデューサー／生産ラインコンサルタント