<   2017年 03月 ( 5 )   > この月の画像一覧

工程表と部品表 - 個別受注生産における主従の逆転


若い頃、『システム・モデラー』という職種を目指したい、と言ったら、上司から「そんな職種はない」と言われたという話は、以前書いた。(「システムとはいったい何を指すのか」 http://brevis.exblog.jp/20878001/ 2013-08-01)。それで、その後わたしは「プロジェクト・アナリスト」を名乗るようになり、今では名刺に、勤務先の「チーフ戦略アナリスト」である、と書いている。

だが、今でもわたしはモデリングの仕事が好きだ。データ・モデリングとは、世界の概念的スケッチである。言葉と簡単な図を使って、世界のあり方を切り取って分析する仕事は、何より楽しい、と思う。モデリングという仕事は、技術とアートの中間地点にある、とも言われる。科学的論理性だけでは、良いモデルを作るには足りない。モデルとは近似であり、見切りだからだ。モデルは必ずしも事物の厳密・正確な再現ではない。英語で、"Models are all wrong. But, they are useful.”という言葉をきいたことがあるが、金言だと思う。モデルはすべて、正しくない。だが、有用なのだ。

さて、前回(http://brevis.exblog.jp/25634844/)は『部品表』と『工程表』という概念について、簡単なイントロ的解説を書いた。ところで、前回の記述は、じつは繰返し性の高い生産形態での話だった。つまり、見込生産(MTS)とか繰返し受注生産(MTO)の場合なのだ。

(なお、若干話がずれるが、生産形態の分類を表す用語については、日本語の慣用句よりも英語の用語の方が本質を突いているので好きである。見込生産は英語でMake to Stock = MTSとなる。「在庫してストックするために作る」形態なのである。繰返し受注生産はMake to Order = MTOで、これは「注文に応じて作る」やり方だ。このように、何に対して製造するか・製造の結果が何になるか、が英語での表現では、より明快だ)

さて今回は、ETOの場合について書いてみたい。ETOとは、Engineer to Orderの略だ。Engineerという単語は、ここでは「技術者」という名詞ではなく、「設計すること」という動詞で使っている(ちょうど”Engineering”という動名詞の言葉があるように)。ETOは日本語では、「個別受注生産」あるいは「一品受注生産」「受注設計生産」などとも呼ぶ。

ETOという生産形態の本質は、製造の前に設計作業が必須となることだ。このような生産形態は、意外と多い。たとえば造船。航空機。大型の産業機械(たとえば圧縮機や工作機械など)。あるいは金型。いろいろある。わたし達プラント・エンジニアリング会社が購入する資機材の大部分も、ETOの形態で生産される。そしてIT業界でSIerが行う受託型のシステム開発も、受注後に設計が必要になる点では、ETOの一種だと見ることもできる。

わたしの見るところ、日本の製造業には、このETO形態をとっている企業がかなり多い。好むと好まざるとに関わらず、いや、それが企業自身で自覚して選んだ結果なのかどうかも分からないが、とにかく、広く見受けられる。統計的根拠までは示せないが、英米や中国などより、ずっと比率が高いのではないかと思う。

その理由は、日本における顧客(買い手)側のあり方に起因している、というのがわたしの推測だ。日本の顧客(B2Bで、顧客が企業の場合)は、なぜかメーカー標準品を買うことを潔しとせず、必ず自分好みの個別仕様を付け加えたがる傾向がある。たとえば生産財を買う場合、それが自社の生産ラインにぴったり最適化され、面倒が少ないようにしたい。そのため、いろいろ個別で特殊な注文がつく訳だ。そういう風に細かな注文をつけること自体が、エンジニアとしてのプライド、ないし存在意義とさえ思っているらしい(実際にはその分、標準品よりコストが上がっている可能性が高いのだが、会計部門への説明能力の高いこともエンジニアの能力の一部である^^;)。顧客から個別注文を受け取った企業の技術者は、自分のサプライヤーに振り向いて、同じように個別仕様を要求する。かくして、日本ではETOに対応しない企業は生き残れなくなっていく。

ところで、いろいろな生産形態のうちで、生産管理の一番難しいものが、このETOなのである。だから日本の製造業は、全体として、わざわざ一番難しい生産形態を、みんなして選んで、お互いに生産性の低さに苦しんでいるとも言える。

ETOは、なぜ難しいのか? ETOの特徴は、受注時点で部品表(BOM)が固まっていないことにある。まあ受注時点でも、たいていの場合、大きな骨格くらいは見えている。そうでなければ、そもそも金額さえ見積れないからだ。

しかし、細部は設計してみないと決まらない。当然、設計後に、部材を注文することになる。注文してはじめて、部材は工場に入ってくる。部材がなければ、製造はできない。当たり前だろうって? その通りだ。だが、製造のスケジュールという観点から見ると、ETOとそれ以外では、大きな違いがあるのだ。

前回の図を思い出してほしい。複数の子部品が組み合わさって、一つの製品ないし親部品ができあがる。それを作るために、工順がある。いいかえると、部品の親子関係に対応して、一つの工順がある(厳密には『代替工順』というものも存在しうるが、今その話には深入りしない)。工順は複数の作業からなっていて、それぞれの作業に、製造資源(人や機械)が結びつく。こういう構造だ。

ここで、ちょっと図を見てほしい。ここに掲げたのは、渡辺幸三氏が「CONCEPTWARE/生産管理」の名前で公開している、生産管理システムのデータモデル図の一部だ(http://dbc.in.coocan.jp)。渡辺氏は、今日のIT業界のレベルアップと生産性向上をめざして、あえてこうした本格的で実線的な業務系システムのデータモデルを公開しておられる。
e0058447_22074045.jpg
E-R図を見慣れた方ならば、これを見るだけでわたしの言いたいことはお分かりいただけると思うが、念のために説明しておこう。なお渡辺氏の用語はわたしのとは少し違っているため、対応関係を示しておく。左が渡辺氏のモデル上の用語で、右がわたしの用語である。

(1) 工程→工順、 (2) 作業場→作業区(ワークセンター)、 (3) 製造品工程明細→作業、 (4) 製造品材料明細→部品表、 (5) 品目→マテリアル(品目)

この図を見ると、(5)「品目」レコードに対して、複数の(4)「製造品材料明細」レコードがぶら下がっている(渡辺氏の図法では、「∈」は1:Nの関係を示す)。これは、一つの親部品が、複数の子部品から組立・加工されて作られる「親子関係」を示している。そして、(5)「品目」レコードに対し、(3)製造工程明細が、やはり複数ぶらさがっている。つまりここでは、品目が主であり、工順・作業が従であることが表されているのだ。(細部に興味がある方はダウンロードして、全体をご覧になることをおすすめする。非常に勉強になると思う)

そして製造リードタイム(渡辺氏の図ではLead Timeの頭文字をとってLTと略されている)は、個別の作業に結びついており、作業を積み上げて、工順の、そして全体の生産スケジュールができあがるのだ。

言いかえるなら、設計が完了して、すべてのマテリアルと部品表が決まらない限り、製造コストやスケジュールが確定しない、ということになる。コスト(原価)については、もはや受注時点ですでに販売価格が決まっているのだから、今さら泣いても笑ってもどうにもならない。だがスケジュールは問題だ。工場では複数の品目や注文が流れており、スケジュールの相互調整によっては、他の品目の納期に影響してしまう。

MTS(見込生産)やETO(繰返し受注生産)ならば、事前にBOMが確定しているから、「標準納期」とか「標準リードタイム」といったものを設定することができる。だがETOは、受注時点で全体のスケジュールが見えないのだ。ということは、受注時点で、本当に納期を確約できるかどうかも、分からない訳だ。おまけに、現場の人や機械の事前手配も、難しいと言うことになってしまう。

それがどうした。ものづくり現場は、部品と図面がなければ動けないのだ。だったら設計が全部終わった時点で、製造のスケジュール計画を立てればいいではないか、と思う人もいるかもしれない。だが、そうはいかないのだ。競争環境下では、そんなにのんびりした納期を顧客は与えてくれない。だから、部品表が確定した部分から、順次作り始めなければ、ふつう間に合わなくなるのだ。かくして、設計作業と、部品調達と、製造作業が、並行して進むことになる。本来は順番に進むはずの仕事が、入れ子になったり逆転したりして進むのだ。設計部品表(E-BOM)と製造部品表(M-BOM)が別々に管理されている企業の場合、話はさらに混乱してくる。

米国生まれの生産管理手法であるMRPが、日本でなかなか受け入れられ普及しなかった理由の一つが、ここにある。MRPは、大量繰返し生産マインドの強い米国で、'60年代に生まれた手法である。MRPでは、計画時点に、製品のBOMデータが存在していることを前提している。だが個別仕様が好きで短納期を要求したがる顧客だらけのわが国では、なかなか使い物にならない。

では、どうしたらいいのか?

ここで実は、発想の転換が必要となる。それは、「品目」→「作業」という主従関係の逆転である。

「作業」と、その集合である「工順」を、視点の中心におく。そして工順のインプットとアウトプットとして、子部品・親部品をとらえる。前回の図を、もう一度見直してみてほしい。

今、ここで問題としたいのは、製造スケジュールである。つまり個別作業にかかる正味時間、工順に与えるべきリードタイムだ。そして、それは、同じような親部品を製造する作業では、子部品の細部が多少異なっても、ほぼ同じだと見ることができる。え? 六角の部品の加工と、円形の部品の加工では作業が違うだろうって? たしかに厳密には違う。だが、生産スケジュールはモデルであり、一種の近似であることを思いだしてほしい。何秒単位の厳密な数字を議論しても仕方ないし、そんな精度は必要ないのだ。現場が必要とするのは、現場が混乱しないですむようなざっくりした精度の、しかしある程度は信頼しうる予測なのだ。

個別作業の所要時間見積のために、ここで登場するのが「パラメトリック見積法」である。これは、作業対象が持つ、なんらかの代表的なパラメーターを用いて、作業時間(つまりコストを)推計する方法だ。そして、この仕事のために、BOQ = Bill of Quantityという概念が、BOMのかわりに登場する。Quantityはパラメーターの数字である。グラムとか、mmとか、リットルとか、何の単位でもよい。それが作業の量(Quantity)を適切に示してくれたら、それで良いのだ。あとは割り当てる製造資源と、その生産性指標とから、作業時間を推算することができる。製造コストも、推算できる。

詳細な設計作業が十分に完了していなくても、基本設計段階(ないし受注前の見積設計段階)で、製品を構成するサブ・モジュールや共通部品等のBOQを洗い出し、リスト化しておく。そうすれば、これを元に、製造スケジュールをあらかじめ立てられる。これが、プロジェクト的なETO=受注設計生産のやり方なのである。詳細のBOMは、設計のあとでできてくれば良い。

もともとBOQという用語・概念は、100年ほど前に英国の建設業界で生まれた概念だ。そして、エンジニアリング業界に流れ込んできた。わたし達の業界では、このBOQ(しばしばBQとも略す)が、プロジェクト・スケジューリングの中心的なデータになるのである。わたし達にとって、作業(プロジェクト用語ではActivity)が主であって、そのインプット・アウトプットとなる品目(マテリアル)は従である。作業が先にあり、品目は段階的詳細化の結果として、後から決まってくる。このような世界観で、エンジ会社はプロジェクト・マネジメントを行っている。

そしてエンジニアリング・プロジェクトは、まさに巨大な「受注設計生産」そのものなのである。基本設計の外部仕様を元に、詳細設計を起こし、資機材を世界中のサプライヤーから調達し、プラントの現場に運んで、据付組立作業(「建設」)を行う。我々もまた、組立加工産業なのだ。

そしてもう一度最初の話に戻ると、システム・モデリングの面白い点は、こうしたデータモデル上の主従の逆転、アクロバティックな視点の転換が、ときに必要となることにある。必要なだけではなく、とても有効でもある。もちろん、そのためには、ある種のスキルがいる。ものごとを俯瞰して見る、一種マネジメント的なスキルが。そういう訓練の場をエンジニアのために作ろうと、わたしはこのところずっと研究部会の仲間達と活動しているのである。どうか期待していてほしい。


<関連エントリ>
 →「システムとはいったい何を指すのか」 http://brevis.exblog.jp/20878001/(2013-08-01)
 →「部品表と工程表」 http://brevis.exblog.jp/25634844/ (2017-03-22)

by Tomoichi_Sato | 2017-03-31 22:10 | サプライチェーン | Comments(0)

部品表と工程表

今年の初め頃だったが、ある集まりを手伝うことになった。中高校生くらいの若い子達が20人くらい集まるので、彼らに昼食を出す。わたしと連れ合いはその食事作りのお手伝い、という受け持ちになった。わたし以外は全員、年配の女性達だ。集会場所の横にはそれなりのキッチン設備があり、食器もそろっているので、そこに集合となった。前日までのメールでは、シチューを作ると聞いていたのだが、当日集まっていたら、なぜかメニューはカレーと野菜スープに変更になっていた。ともあれ、食材もそろって、さあ調理と言うことになった。

ところで、この調理の進め方がなかなか見物だった。わたしは男なので、食器洗いその他の力仕事に回り、実際の調理は女性達が受け持つ。皆、何十年と料理をしてこられた方ばかりだ。ただ、わたしも一応、料理の心得はあるので、どんなプロセスで進むかは理解している。まず材料を洗い、切り、大鍋に適時投入して、煮て味付けをする。そのかたわらご飯を炊いて、織機を用意する。それだけのことなのだが、現場は大騒ぎだった。

まず、この集団には、采配をふるうリーダーがいない。2、3人、それなりにリーダー格というか、まあ仕切り屋のタイプの人はいる。だが回りの人たちも黙っていない。みな、料理については一家言ある女性ばかりだ。だからどの材料をどれくらい使うか、どう切っていつ鍋に投入するか、味付けには何をどれくらい入れるか、まあ実に喧々がくがく、議論が続く。議論だけでなく、彼女たちはしゃべりながら実際に手が動き、勝手にやってしまう。もうどうなることやら、ホントに昼食時間までに間に合うのか、などハラハラして見ていたが、幸いというかカレーも野菜スープもなんとかそれなりに出来上がって、腹を空かせたティーンエイジャー達の胃袋にあっという間に飲み込まれた。

この集まりはまあ、ボランティア集団のようなものである。こういう集団では、会社のような上司・部下関係が無いし、指示=命令原理も働かない。誰か図抜けたリーダーがいればその人の判断と采配で、皆が一応動くだろう。だが、そういう人もいなかった。それでも何とかなったのは、女性達の調理のスキルもあるが、一つにはカレーとスープという料理が、材料にも味つけにもある程度幅があっても、まとまりやすい料理だったからだろう。

それにしても、同じこの仕事を、わたしの勤務先の同僚達がやったらどうなるだろう、と想像してみた。ボランティアの組織だ。賛同者が集まり、業務命令系統はとくにない。でも、きっと、自然にこうなるだろう:
(1) まず、料理は何を何人前作るか相談の上、決める。
(2) 必要な食材のリストを作る。食材の種類と、数量と。必要ならば、スペックつき(たとえば豚肉ならば「バラ肉」とか)で。
(3) 調理の手順のリストを作る。それに必要な調理器具もリスト化する。
(4) 食材調達の担当者を決めて、買い物を任せる。
(5) その間に、調理器具と食器の準備をする。必要な食器を集めて洗い、並べる。
(6) 食材が来たら、これも分担して洗い、カット、下ごしらえをする。
(7) 調理をする。この作業にはやはり、多少はスキルのある経験者をあてる。
(8) たぶん何人かで味見をして、OKとなれば盛りつけ、配膳作業をする。

たぶんこうしたことが、なかば自然に進むだろう。なぜなら、これはエンジ会社が普段やっている、エンジニアリングの仕事そのものだからだ。誰かがリーダー役を引き受けるだろう。あるいは長老が、誰か若手を指名してリーダー役にするかもしれない。皆、そのリーダーの采配と交通整理に従う。難しい問題が起きたら、皆で相談して解決する。それでも迷ったら、リーダーの責任で打ち手を決断する。これがたぶん、わたし達のスタイルだ。もちろん、調理の腕前は熟練の女性達にはかなうまい。でも、何とか必要なものを必要なタイミングに必要な量だけ、届けられると思う。

とくに大事なことは、最初に大まかな計画を立て、必要な材料や道具や手順のリストを作ること。これがないと、全体の仕事量も、作業の分担も、そして納期も見通せないからだ。

わたしの勤務先が特別だというつもりはない。たぶん大方の会社は、少なくとも製造業なら、こういう風に仕事を進めると思う。ものづくり企業に共通なDNAというのがあるとしたら、その一つは、最初にいろいろなリストを作ることにあるだろう。リストなんか作らなくても、あの女性達のように、ものは作れる。だが、仕事の見通しは、格段に落ちるだろう。

必要なリストは何だろうか? あるいは、もっと抽象化して問題を捉えるなら、生産という仕事に必須な基準情報は何なのか。

それは大きく、「もの」(=マテリアル)に関する情報と、「製造作業」に関する情報とに分かれる。「もの」に関する情報は、まず、どういう品目(材料・製品を含む)があって、それはどういった使用・属性を持つか、というリストになる。これは通常のIT用語で言うと『マテリアル・マスタ』(品目マスタ)と呼ばれる。ついで、ある製品は、どのような部品・材料から成っていて、どれだけの数量を要するのか、という製品構成に関する情報が必要だ。これが『部品表』(BOM = Bill of Material)データである。ただしBOMがマスタとしてITシステムの中に整備されているかどうかは、その企業・生産形態に依存する。

では、製造作業に関する情報はどうか。これはまず、製造に使う機械・設備の情報と、具体的な作業の情報に分かれる。前者は、機械リストとか、会社によっては作業区(ワークセンター)マスタと呼ばれる。もう少し進んだ形では設備構成マスタというデータ形式になる。設備構成マスタとなると、その中に階層構造が表現されて、たとえば作業区1の圧縮機Aには、補機として潤滑油ポンプA1がある、といった事情がわかるようになっている。つまり一種の、機械設備に関する部品表みたいなものである。かなり保守業務のレベルの高い企業では、こうしたマスタが必要とされる。

後者の、具体的な作業の情報については、特定の製品・品番ごとに、(通常は複数の)製造作業が生じる。つまり、各作業に必要な機械・設備は何で、その順序はどうで、各作業条件は何で、(もしあれば)マニュアルや作業標準はどれで、といった属性が並ぶ作業マスタがいる訳だ。これは基準情報である。ただし、個別の作業指示が出される場合は、それぞれの作業にIDをふり、これに着手・完了のタイミングを指定し、さらに必要な機械・設備などをアサインしたリストを作ることになる。これは、しばしば『工程表』と呼ばれる。英語でBOP(Bill of Process)と呼ぶこともある。

以上をまとめると、生産という仕事に関する基準情報は大きく4種類に分けられる:

マテリアルに関する情報
・マテリアルの属性情報 → マテリアル・マスタ(品目マスタ)
・マテリアルの構成情報 → 部品表(BOM)
製造方法に関する情報
・機械・設備の構成情報 → 作業区マスタ、ないし設備構成マスタ
・製造作業の属性情報  → 作業マスタ、あるいはその具体型としての工程表(BOP)

なお、ここで注意しておきたいことがある。それは「情報」と「データ」の区別だ。これについては以前、『ITって、何?』というシリーズで長々と述べたことがあるから詳しくは繰り返さないが、
・「情報」とは人間に意味をもたらすもので、基本的には不定形
・「データ」は定型化された記号の並びで、機械的処理に適する
という区別がある。今日はA社の業績ニュースが流れて株価が上がりました、が情報。各社の株価が定型化されて並んでいる株式欄が、データ。情報を定型化して機械で処理したり、データを読み取って人間に意味を提示するのが、IT(情報技術)である。上に述べた基準情報の例でいえば、人間は情報だけあればいい。ただ、量が増えたときには、紙に記録してリスト化したり、さらにコンピュータの中に収めてマスタ・データ化する方がベターだ。

もう一点。上の説明では、『工程』という言葉をあえて使わぬように説明した(「工程表」は別として)。これは、工程という用語が業種・会社によってかなりいろいろな意味に使われているためだ。大きく分けても、工程をプロセス=作業群の意味で使うケースと、ワークセンター=作業区の意味で使うケースがある。それらをごっちゃにしているケースだって、少なくない。工程表という用語だって、それなりにブレがある。

本当はこうした用語類は、わが国の生産管理の発展のためには、共通化した方が良い。しかし、抽象化・標準化への希求がかなり弱いわたし達の社会では、それぞれの業界や特定の大企業が勝手に作った方言を、グループや系列会社に押しつける例が、よく見受けられる。業界を横断して工場づくりの仕事をしている我々エンジニアリング会社にとっては、まことに不便な状況である。本来だったらアカデミアの学者が先導して、こうした状況を改善すべきなのだろうが、あいにくその動きも薄い。

そこでわたしは、せめてこのサイト内では整合性のある用語を使うように心がけており、とくに多義語である「工程」は極力使わないようにしている次第だ。かわりに、わたしは製造業務のプロセスを呼ぶときは『工順』(英語でRouting)と呼ぶようにしている。わたしの考える製造という仕事のプロセスの構造を、図に示すと次のようになる。
e0058447_12531915.jpg
図 製造という仕事のプロセスの構造

もっとも「工順」という言葉だって、作業の集合を指す場合と、単に一連作業の中の連番(数字)だけを指す場合があるから、曖昧性は残るのだが、「工程」よりは誤解が少ないだろうと考えて、こうしている。

なお、図の中には「リソース」(Resource=製造資源)という言葉が出てくる。これは、作業の間は占有するが、作業した後でも別の作業に再利用できるようなものを指す用語だ。具体的には、作業する人・機械設備・治工具・金型などが含まれる。つまり、機械とか作業者とかよりも、1レベル抽象度を上げた用語である。このリソースのリストのことを、「資源表」(BOR = Bill of Resource)と呼ぶこともある。

かくして、製造業には、大きく言っても4〜5種類の基準情報が必要であり、それをきちんと整備・保守していく仕事が生じることになる。こうした仕事は全て、「間接業務」=直接お金を生まない仕事である。だから、しばしば日陰の仕事、縁の下の力持ち的な業務とみなされ、不況の時は優先度が下げられたりもする。そして、そういう態度自体が、生産性の低下をもたらし、さらに不況を加速するというダウン・スパイラルが生じる。これは、企業の持つ思考と行動の習慣=OSがバグっている状態だ。

なぜ企業には基準情報が必要なのか? それは、情報・データを再利用可能な状態に保つためだ。さらにいえば、仕事を予見・計画可能な状態に保つために必要なのである。冒頭に紹介したように、たまに集まるおばさま達の集団なら、基準情報など無くても、なんとか料理はできる。いや、それこそ、「ちょっとカレーの味が薄いみたいだから、ここにある和風だしを入れちゃいましょ。」などという、臨機応変な小技(大技?)を繰り出すことだって、できたりする。だが、これを仕事にして食堂を開くなら、もう一歩上を目指す必要がある。きちんと計画できて、繰り返し可能な仕事の状態にするべきなのだ。部品表と工程表は、そのための武器なのである。


(本記事を書くきっかけとなったのは、OpenLearning(https://open.netlearning.co.jp)が提供する「応用情報学」講義シリーズの中の、京都情報大学院・上田治文教授による「企業経営の情報学」Wee 2・Lesson 3「工場のIT化の核 部品表のコンセプト」を見たことである。わたしの用語・見解とはいろいろ異なっているが、4種類のマスタの整理など、いろいろと学ぶべき良いヒントをいただいたことを記しておきたい)






by Tomoichi_Sato | 2017-03-22 12:56 | サプライチェーン | Comments(0)

「理屈を言うな」という理屈

15歳の時の4月。高校の入学式を終えたわたし達・新入生は、各クラスでの挨拶と簡単な自己紹介のあと、体育館に集められた。「オリエンテーション」という行事があると言うことだった。どういう行事かの説明はなかった。

新入生ばかり400人あまりが集められた後、体育館の扉が閉められたが、中には先生達の姿はなかった。壇上には学ランを着た屈強な上級生達が十何人か立って、両手を後ろに組み、胸を反らして立って、わたし達新入生をにらみつけた。どうやら『応援団』という存在らしかった。その中の団長格とおぼしき人が壇上の中央に立って、上半身を腰から前にかがめ、わたし達に向かって、かすれた声で

「ウース」

という声を発した。いや、正確には文字化が難しいのだが、とにかく強引に文字にすると、そういう音声だ。何事か、と驚いてきょとんとしているわたし達に向かって、壇上の、そして左右通路の応援団員達が、わたし達に口々に「返事はどうした!」「声が出てない!!」と大声で怒鳴りつけはじめた。どうやら壇上の人は「押忍(オス)!」とわたし達に呼びかけているのであり、わたし達はそれに対し、同じく「オス!」と大声で答えなければいけないのだ、という理屈が飲み込めるまで、たぶん10分くらい混乱の時間があった。

わたし達がようやく「オス」と声を揃えて返事することができるようになると、今度は校歌斉唱を命じられた。何人か固まって座っているブロックが指名され、校歌の一節ずつを歌え、というのだ。伴奏は応援団の大太鼓だけ。校歌と言っても、わたし達には簡単な歌詞のプリントが、入学手続きのときに、手続き書類の束と一緒に、渡されていただけだった。当然誰も歌えないし、覚えてもいない。無体な要求である。

だが立たされたものの口もきけずに黙っている新入生達に対し、応援団員は怒鳴った。「オリエンテーションまでに覚えろと書いてあったはずだ!」 たしかに配られたその紙をもう一度よく見ると、「オリエンテーションで校歌斉唱の練習をするので、その時までに覚えてくるよう、諸君と約束しておく」と書いてある。だが志望校合格に浮かれている新入生で、そんなものをまともに受け取った者はほとんどいなかった。

応援団員は恩着せがましく、では、一節ずつ我々が歌って示すから、お前たちはそれを復唱して繰り返せ、と指示した。かくて順繰りに新入生達は立たせられ、数節ずつ歌わされた。声が小さかったり、歌詞を間違えたりすると大声で叱られ、良しとされるまで、何度も何度も繰り返させられた。その間、回りの生徒がよそ見をしたり上の空だったりすると、すぐに通路の団員がとんでくる。体育館の扉は閉められ、出口にも守りを固めるように団員が立っている。実際に暴力がふるわれた訳ではないが、ほとんど脅迫的な雰囲気である。このような拷問に近い時間を、あとどれくらい過ごさなければいけないのだろうと、わたし達は思った。

ところで、あるブロックにさしかかって、うまく歌えないといって叱られた中の一人が、勇敢にも壇上の応援団員に向かって、必死の声を上げた。「たしかにプリントには『諸君と約束しておく』と書いてありますけれど、僕たちはとくに約束した訳ではありません。」 こうした火に油を注ぐような口答えに、応援団はどう反応するだろうかと固唾をのんだ。はたして、壇上にいる団長格の人は怒って、

理屈を言うな!

と一喝した。全員がしんとなる。そのとき、横に立っていた、もっと小柄で温和そうな人が彼を手で制して、言った(後で知ったが、実はこの人が団長なのだった)。

「たしかに理屈だ。だが、入学したら校歌を覚えるのは当然ではないか。君たちには春休みの長い期間があったはずだ。そんなに大変なことを、君たちに要求した覚えはないし、君たちから『約束できません』と言われた覚えもない。」

こう言われると、誰も反論できない。結局、オリエンテーションは2時間ほど続き、わたし達は校歌の1番はなんとか全員で歌えるようになった。だが校歌は全部で3番まである。明日もまた放課後にオリエンテーションの続きがあるのだ。わたし達はくたくたの心と体を抱えて、家路についた。

それにしても、理屈を言うな、という世界があるのか・・。帰り道、わたしは思った。本サイトの読者はお分かりと思うが、わたしは理屈っぽい人間である。だがわたしの高校は男子校だった。進学校ではあるが、古い高校で、バンカラの気質も残っていた。男社会で、しかも上級生下級生のタテ型序列の強い世界では、理屈を言うな、というセリフが通ってしまうんだ。理が通っても、力でねじ曲げられてしまう場所があるのだ。15歳のわたしは、このとき大きな教訓を得たと思う。

前回、「設計の『なぜ』を考える」で、わたし達は「なぜ」を問いかけたり答えたりするのがヘタだ、と書いた。だが、そもそもわたし達は、議論という行為自体が下手だ。そして、それは文化に多少根ざしたものだと、わたしは思う。理屈を言うな、は普通のノーマルな日本語である。賛成するにせよしないにせよ、意味するとことは誰にも通じる。だが、このセリフを外国語で言えるだろうか? とても難しいと思う。英語なら、”Don’t tell me your reasoning."といった感じだろうか。だが、あまりしっくりこない。イタリア語やロシア語で、これに類する言い方は可能なのか。アラビア語で、あるいはヒンディー語ならどうか。もしかしたら中国語や韓国語なら、似た言い方はあるのかもしれないが。

もちろん、どこの国に行っても、無体な要求、非道な連中は存在する。ただ西洋や中洋のように文化の根底が理屈っぽい社会では、そういう連中でも、自分たちが道理を蹂躙している、という自意識はあるのではないか。意識してやるのと、無意識にやるのでは、大きな違いがある。

理屈を言うな、というセリフは、どんなときに発せられるのか。それは、自分たちが共有している意思や熱情や気分に、水を差すな、という時ではないかと、わたしは考える。場を壊すな、といいかえてもいい。というのは、理屈というのは、自分と対象とを引き離すはたらきがあるからだ。『客観化』と呼んでもいい。自分と対象、自分と相手がほとんど一体化しているときには、理屈は無用で、入り込むスキマはない。たとえば恋愛に理屈はない。あるいはスポーツや勝負事で皆が一丸となっているとき、その行為の中に理屈を持ち出すのはヤボだ。そしてもちろん、上下関係の中にも。

理屈、つまり道理というのは、誰に対しても通用する。つまり公平である。万人に公平に与えられているのが、論理だ。こういうものは、上下関係の中の対話には、いささか邪魔なのだ。たとえば男子校の運動部のような場所では。あるいは一般に、タテ社会の中では。わたし達の社会における運動部(体育会)というのは、ある種、軍隊の中の人間関係を再現、ないし予習するための場所である。そこでは論理より熱情が優先される。

そして身分や立場の上下がある間柄には、議論はふつう成立しない。議論は一応、「対等」な間で行うものだからだ。

では、そもそも「議論」とはどのようなものだろうか。わたし達エンジニアが仕事の上で議論するとき、それはどのようなプロセスをとっているか、考えたことがあるだろうか? わたしの理解では、(少なくとも西洋社会では)議論は以下のようなプロセスを経る:

(1) まず参加者の共通の前提や目的を確認する。
(2) 議論の対象となる事実について、客観的・多面的に検討する。
(3) 問題となっていることや対策に関し、相互の意見を出し合う。
(4) 互いの視点や意見を組み合わせて発展させる。
 (ここで揉めたら、(1)や(2)に立ち戻って考え直す)
(5) 合意点を見つける。

つまり議論というのは一種の共同作業であり、一緒になにか建物を建てるような仕事なのである。まず(1)で共通の地盤を固める(ここが無いとそもそも議論にならない)。ついで(2)で、議論という建物の土台をつくる。事実というのはたいてい多面的で、見る人の視点によって見え方が異なる。だからここの部分は念入りに進める必要がある。そして、どちら側も「この上に建てて大丈夫」という風な認識を得るべく、客観的にものごとを記述することをつとめる。そして、このステップには自分の熱情や思い込みを持ち込めない。この『客観化』こそが、対象と自分を切りはなすような、“水くさい”部分なのだ。

その先も一応、順番に意見を応酬し合う、一種の共同作業である。互いにブロックを積み上げ合うような行為だ。そして互いに合意できる結論にたどり着く。それは建物の最上階に見晴台を築くのに似ている。これが議論のプロセス、あり方である。

だから、こうした議論では、基本的に「勝ち負け」がない。対等な立場同士の、共同作業だからだ。また通常の個人間の議論のみならず、学問上の論証も、ビジネスの交渉も、いや刑事裁判でさえ、こうした枠組みの中の『議論』の一種である、というのが西洋風のとらえ方だ。

まあ、議論に勝った負けたはないと言っても、もちろん人間だから、それぞれ途中や結果に対して不満もあり得よう。優位に立った方が、勝ち誇るような態度をとることもある。だが、原則として、議論は勝負ではない(和解に至らぬ民事訴訟やディベートという一種のスポーツは別として)。そしてもちろん、議論とは、どちらが頭がいいかの優劣を決める場でもなければ、言葉による喧嘩や暴力(口げんか)でもない。

こういう認識が文化(OS)の中で共有されていないと、意味のある議論ができなくなる。とくに、議論は口げんかではない、ということは早くから子ども達に教える必要がある。また、自分の意見に意固地にこだわらず、議論を通じて、オープンに変えていけるような態度を身につけさせなければいけない。

そして、議論とは広い意味で「学び」の一部である。なぜなら、「学び」とは考え方や知識や意見の変更をもたらすものであり、議論とはまさにそうした結果を生むためにするものだからだ。議論がきちんとできない組織では、認識も深まらないし、学びも行われない。そうした組織では、きっと同じような思い込みが受け継がれ、同じようなミスが繰り返されるだろう。

人間集団はいろいろな形で、不可避的に「上下関係」「優劣の順位」を作りたがる。それは一種、本能の一部なのだろうし、組織に一定の規律や効率をもたらすといってもいい。ただ、上の意見が下に対して絶対で、「理屈を言うな」という言葉で上下間での対等な議論を抑制してしまうと、組織は硬直化していく。理屈を含む議論はその解毒剤なのだ。少なくともわたしは、そう信じている。

私の高校が今でもあんなオリエンテーションという行事をやっているのかは知らない。たぶん、あんな野蛮なやり方は、今の時勢に合わないだろう。だが、15歳の記憶力はたしかに絶大だった。同窓会で集まると、いい歳したおっさん達が声を揃えて、今でも「こーしゃの、いーしずえ、動きなき〜」と校歌を歌うことができる。それと同時に、わたしはあの「理屈を言うな」という一言を忘れていない。あの一言はわたしに、偉大な教訓を与えてくれた。それは逆説的な仕方でわたしに、道理というものが弱い立場の者をまもる武器にもなりうるのだと、教えてくれたのだ。


<関連エントリ>
 →「設計の『なぜ』を考える」http://brevis.exblog.jp/25540003/ (2017-03-07)


by Tomoichi_Sato | 2017-03-13 22:16 | 考えるヒント | Comments(3)

設計の「なぜ」を考える

まだ駆け出しだった頃、工場改善コンサルタントの話を聞いたことがある。それなりに面白い話がいろいろあったが、1番よく覚えているのはヘアドライヤーの話だった。このコンサルタントは、製造業、とくに電気系メーカーの設計部門を訪れた際は、必ずヘアドライヤーの冷風スイッチについて、尋ねることにしていると言っていた。

「ヘアドライヤーには、温風のスイッチのほかに、必ず冷風のスイッチがありますよね。御社の製品にも、ついていると思います。ではこの冷風のスイッチは、何のためにあるんですか?」

皆を集めてこう質問すると、たいてい誰も答えない。日本の会社は、皆そうだ。でも繰り返して尋ねると、中には元気のいい若手社員が手を上げて、こう答えたりする。

「はい。それは、あの、夏なんかの暑いときは、冷風で頭を乾かしたほうが気持ちいいからです。」

するとコンサルタント氏は続けて聞き返すのだそうだ。「それは本当ですか? じゃぁ、夏に冷風で頭を乾かしている人、手を上げてください。」実際には、手をあげる人はほとんどいない。そこで彼はとどめの一言を放つ。

「アメリカのメーカーに行ったら、こういう答えが返ってくるんです。『髪の毛は熱風を当てると柔らかくなるが、冷やすと硬くなる性質があるので、スタイリングをするときには最初は温風を当て形を作り、最後に冷風スイッチを使って固めるのです。』・・ところが皆さんはそれを作っているのに、なぜそれがあるかを知らない。」

アメリカの技術や製品を日本に持ってきたときに、何も考えずに形だけ真似するから、こういうことになる。何のためにあるんだか理解しないまま、機能をつけてしまう。そのためムダに設計も検査もコストが上がる。・・コンサルタント氏は私たちに、そう教訓を述べた。

もう一つ彼は例をあげた。「どこの工場に行ってもスパナって言う工具がある。知ってるでしょう? ところでこのスパナって、なんだか妙に握りが太くて持ちにくいじゃないですか。だから職場によっては工夫して、わざわざ細い棒を持ち手側に縛り付けて、持ちやすくしている」(彼は黒板に図を描いた)。「でも、なんでこんなことしなくちゃいけないんです?」——無論、わたし達は答えられない。

「それはね、最初にスパナをアメリカから持ち込んできた人間が、そのままのサイズで複製したんですよ。だからアメリカ人のデカい手に合わせた握りになってる。考えないでただ真似したんじゃ、工夫にならない。」

このコンサルタントの言うことがどこまで正確なのか、私はよく知らない。でもその時の私の頭には、『直輸入技術』の弱さ、脆さが刻み込まれた。それは「技術導入は麻薬のようなものだ」といっていた大先輩の言葉を思い起こさせた。外国からの技術導入は、最初は楽だが、次第に自分で考え、開発する力をなくしてしまう。

わたしはエンジニアである。最近はもう自分で設計する事はほとんどなくなってしまったが、それでもエンジニアだと思っている。なにか設計したら、結果は図面や仕様書に落とし込む。その結果が下流側部門のインプットとなって、関連する設計や調達や製造に使われる。それがエンジニアの仕事だ。

だが、エンジニアとして先輩の仕事に学び、自分の成長の糧とするときには、それだけでは足りない。設計の結果だけではなく、考えと仮説を学ぶ必要がある。先のコンサルタント氏による、冷風スイッチのエピソードは、そのことを示している。「技術を伝える」とは、結果としての形だけを教えるのでは不十分なのだ。「なぜ」そうなのかが大切だ。ノウハウ(Know How)より、ノウホワイ(Know Why)が大事だと、わたしの勤務先のトップマネジメントも、よく口にしている。

だから設計をするときには、設計の理由を記した設計ノートやメモやコメントを、なるべく作って残すようにしましょう。

・・というだけでは、実は話はまだ終わらないのだ。

なぜなら、わたし達は「なぜ」を問うたり、「なぜ」と問われたりするのに、文化的に不慣れだからだ。そうでなければ、どうして、誰かが大勢に理由の問いかけをしたとき、皆、遠慮したかのように答えないのか。間違っていても、推理を述べればいいではないか。間違いだったら、そこで学べばいい。別に命を取られる訳でもない。それなのに、「間違った答えをいうと恥ずかしい」という気持ちが先に働くから、誰も人前では答えなくなる。あとで廊下で講師をつかまえて、小声で確かめたりする。それで知識を共有できるだろうか。知らないことの方がもっと恥ずかしいはずなのに、皆が知らなければ、怖くないのだ。

「なぜ」の問答に不慣れなわたし達が陥りやすい「なぜの罠」は、何種類か考えられる。

説明1 「そういう慣習だから、昔からそうだから」
 よくある答え方である。上の冷風スイッチと同じだ。これでは理由を説明していることにはならない。

説明2 「目的はこうだから、機能はこうだから」
 なぜ冷風スイッチがあるのですか? それは、冷風を送れるようにするためです・・これは、質問のたんなる言いかえに過ぎない。その機能の目的が、使用者にとってどんな時どのような意義や利便を提供するか、の答えになっていない。答えのはるか手前で止まっているのに、なんだか答えたような気になっているだけである。

説明3 「それはこういう仕組みなんです」「こういう経緯でそうしました」
 ここのボタンを押すと裏で自動的にこのモーターが作動して・・とか、その機能はもともと別の形で実装する予定だったんですが経緯があって・・とか、詳しい説明が続く。だが、それは単に詳細化して説明するだけで、WhyではなくWhat, Howを述べているだけだったりする。こういう答えもありがちである。

説明4 「顧客が(誰かが)決めたから」
 いやあ、お客さんが(あるいは先輩が、他部署が)そうしろと言ったんですよ・・こういう答え方は、WhyではなくWhoを述べている訳だ。言われたことは忠実にやる。しかし言われないと自分では意見やスタンスがない。これは、受注型ビジネスにたずさわるエンジニアに広く見られる傾向ではないか。すなわち、設計へのオーナーシップの喪失である。本当は、これがけっこう深刻な問題だという気がする。

説明5 「自分のセンスで決めました」
 この自信に満ちた答え方は、言い方を変えると「なんとなく決めました」と同じである。設計者のセンスはもちろん、大事だ。設計という仕事は一種のアート(技芸)としての側面があり、設計者の感性を磨くことは訓練の一部と言っていい。センスがあまりにもない人は、ちょっとその仕事に向いていないな、と判断される場合もある。
 だが、感性に頼りすぎる仕事ぶりは、他者にうまく説明できないし、理解もしてもらえない。エンジニアは感性と理性のバランスが大切なのだ。そして、スティーブ・ジョブズ級の感性の持ち主ならともかく、普通クラスの会社員に「俺の感性を信じろ」と言われても、当惑するだけだろう。
結局、こうした罠に陥りやすいのは、設計という仕事において、「なぜ」をあまり問わず、考えない習慣にあると言えないだろうか。

いや! そんなことはない。我々は「設計レビュー」を要所要所で実施していて、そこできちんとチェックしているのだ、とおっしゃる論者もあろう。なるほど。それは素晴らしい。きっとそうした組織では、設計レビューの基準が(それもレビューの方法・手順や体制ではなく、基準が)明確なのだろう。

だが、設計レビューという行為は、しばしば設計書の記述ルールや整合性チェックにとどまる場合が多くないだろうか? つまり、IT分野の例を出せば、設計の「なぜ」を問う代わりに、以下のような項目の確認に時間を費やすのである。
・ネーミングルール
・エンティティ(要素)の洗い出し
・要素間のリレーション
・記述法とフォーマット
・図面間の整合性
・入出力の検証可能性
これはこれで、結構だ。だがこうしたレビューをいくら重ねたって、「いらない機能」「非効率な構造」をあぶり出すのに役に立つだろうか?

かくして、『機能しないレビュー会議』という問題が生じるわけだ(その証拠に、ネットで検索するといろんな関連記事が出てくる)。設計レビューを本当に機能させたければ、きちんと「なぜ」を問いかけ、まともに「なぜ」を答える習慣づけの必要がある。

そもそも、設計のアウトプットが、単なる工学計算の結果ならば、わざわざ誰も「なぜ」を問うことはしない。「この熱交換器の伝熱面積はどう計算したの?」「HTRIの推算式を使いました」「あっそう。」それだけの話だ。そこにはHowはあるがWhyはない。Whyが登場するのは、「この流体は一部が熱で気化して混相になるはずなのに、なぜ液相の伝熱計算式を使ったの?」というような、『判断』が登場する場合だ。

そして、設計業務の一番の肝は、判断(design decision)にある。設計のdecisionとは、本質的にトレードオフ間の決断である。われわれがなにかの設計時に直面するのは、
・安定性と俊敏性
・冗長性と効率性(燃費)
・頑健性と軽量性
・複雑性と保守性
・オマケ機能と製作工数
・品質とコスト・・
といった、「あちらを立てるとこちらが立たず」風の状況下において、どのようなバランスをとるかという決断なのである。そして、決めるためには、なんらかの仮説や推測が要る。「なぜ」の問いは、まさに、設計者の仮説を言語化するためにあるのだ。

設計という行為の中核がこのようなトレードオフの判断である以上、わたしは人工知能(AI)が将来、自動設計をしてくれてエンジニアの職をどんどん駆逐する、などという想像には組みし得ない。AIどんなに発達しても、機械だけでは決して設計問題を自動的には決められないだろう。

なぜなら、それは仮説設定と価値判断だからである。

設計の結論だけでなく、思考のプロセスと判断基準を示すこと。それがエンジニアの仕事であり誇りであってほしいと、わたしは思う。このことは、以前紹介したように、人に説明するとき「なぜ」からはじめるべき(Start with Why)という金言とも一致している。だから、「なぜ」にもっと真剣に向き合おう。

<関連エントリ>
 →「『なぜ』からはじめよう - 仕事の目的を設定する」 http://brevis.exblog.jp/24334345/ (2016-04-18)

by Tomoichi_Sato | 2017-03-07 22:01 | Comments(0)

プロジェクト&プログラム・アナリシス研究部会」(3月28日)開催のお知らせ: 満員になりました

(大変恐縮ですが、下記の研究部会は大勢の方から参加申込みがあり、満員となりました。なお、予約なしに当日の参加はできませんので、ご了承ください)


「プロジェクト&プログラム・アナリシス研究部会」2017年の第2回会合を、下記の要領にて開催いたします。

今回は、JAXA・宇宙航空研究開発機構のチーフエンジニア室長である岩田隆敬氏をお招きして、JAXAのプロジェクトマネジメントについてご講演いただきます。

ご承知の通りJAXAは日本の宇宙開発の中心団体です。「はやぶさ」の例を見れば分かるとおり、宇宙開発は技術的難易度の点でも、また天体条件その他の環境制約の厳しさの点でも、チャレンジングな仕事の極致といえるでしょう。その難しさを克服するため、米国のNASAは1960年代以降、アポロ計画という「プログラム」、その下の個別ロケット・ミッションの「プロジェクト」という概念の元、さまざまな管理技術を開発しました。宇宙開発分野は、いわばモダンPMの育ての親なのです。

日本版のNASAともいえるJAXAもまた、我が国のプロジェクト・マネジメントの頂点の姿を示すと言っても過言ではありません。トップクラスのプロジェクト遂行はどのようなものか、興味深い話が聞けると思います。年度末のお忙しい時期とは思いますが、ぜひご期待ください。


<記>
■日時:2017年3月28日(火) 18:30~20:30
■場所:研究室棟B会議室(研究室棟1階)※定員:36名
 ※キャンパスマップの【10】
  (いつもの建物とは別ですのでご注意ください)

■講演タイトル:「宇宙航空研究開発機構(JAXA)のプロジェクトマネジメント

■概要:
人工衛星やロケットのような宇宙システムは、大規模かつ複雑、高価で、新規開発要素が多い上に、極限環境を飛行することを特徴とする。世界の宇宙機関の事業の大部分は、こうした宇宙システムの開発を中心に据えたプロジェクトで構成されており、宇宙機関は、プロジェクトを確実に遂行するために、開発の段階的実施、フェーズ移行審査、文書によるベースラインの明確化等といった共通のマネジメントを取り入れている。本講演では、宇宙航空研究開発機構の例を取り上げて、プロジェクトマネジメント推進の背景や、体制・仕組み、開発プロセス、審査、進捗確認、計画変更、スコープ設定、人材要件・育成、知識蓄積・継承などについて、紹介する。

■講師: 宇宙航空研究開発機構(JAXA) チーフエンジニア室長 岩田隆敬様
■講師略歴:
岩田隆敬(いわたたかのり)
・東京大学航空学科宇宙工学コース卒業、同大学院航空学専攻工学修士
・米国Stanford大学大学院航空宇宙学科M.S.(Master of Science)、
  Ph.D.(Doctor of Philosophy、主専攻:航空宇宙工学、副専攻:電気工学)
・宇宙開発事業団(現、宇宙航空研究開発機構(JAXA))入社
 ・陸域観測技術衛星(ALOS、「だいち」)プロジェクト
   高精度な姿勢軌道制御系、恒星センサ、GPS受信機や、大型の太陽電池パドル
   系、及び、地上の高精度指向決定システムの開発から運用までを主担当
 ・研究開発本部誘導・制御グループ長
   誘導・制御技術の研究開発とプロジェクト連携を指揮
   恒星センサ、GPS受信機や、GCOM-W1、ALOS-2、SPICAの姿勢軌道制御系
   開発を担当
 ・統合追跡ネットワーク技術部参与・計画マネージャ
   衛星の追跡管制の統括、予算要求、将来計画を担当
 ・現在、チーフエンジニア室室長
   プロジェクトの独立評価、PM/SEの体制・ルール/標準の維持・推進、研究開発
   マネジメントの推進を担当
・専門: 航空宇宙工学(特に、航法・誘導・制御・ダイナミクス)
・PMP

■参加費用:無料。 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金\2,000が免除されます。

会場の人数に上限があるため、参加を希望される方は、できましたら前日までに三好副幹事までご連絡ください。


以上、よろしくお願いいたします。
佐藤知一@日揮(株)

by Tomoichi_Sato | 2017-03-03 23:56 | プロジェクト・マネジメント | Comments(0)