タイム・コンサルタントの日誌から

講演のお知らせ：「生産スケジューリングの基礎とリードタイム短縮のポイント」（6月27日）

お知らせです。6月に、生産スケジューリングとリードタイム短縮をテーマとした研修講演を行います（有料）。

わたしは長年、エンジニアリング会社で国内外の工場・プラント作りに関わってきました。また、それなりに数多くの工場も見てきましたが、疑問を感じるケースが少なくありませんでした。「なぜ、こんな所に在庫を持つのだろう？」「どうしていらないモノはたくさんあるのに、必要なモノは欠品しがちなのか？」「ここを工夫すれば、もっと効率よく、かつ楽に仕事ができるはずなのに」

そうした非効率が生じるのは、生産活動の仕組み＝『生産システム』の基本デザインに問題があるからです。つまり、生産活動のシステム・エンジニアリングが欠けているのです。むろん、ここで言うシステムとは、コンピュータのことではありません。情報系も一要素ですが、むしろ働く人々と、機械設備と、物流と、それを包む建築空間のことをいっています。こうした基本的なことを抜きにして、ただ最近の流行である「スマート技術」を追いかけても、部分的な改善効果しか生まないのがつねです。

また生産システムは、自社を取り巻くサプライチェーンの特性に応じて、適切な機能構成を選ばなくてはなりません。単に、業績の良い他社の物真似をしても、生産形態が違えば、役に立たないのです。

拙著「革新的生産スケジューリング入門」や「BOM/部品表入門」をお読みになった方はご承知の通り、わたしは具体的なテクニック論のみならず、原理・原則に関する体系的な理解を重視しています。そのため、生産システムをより良く運用するにはどうしたらいいか、より上手に設計するためには何に留意したらいいを考える『システムズ・アプローチ』をとります。したがって業種分野については、わりと間口を広くとってお話しできる点が特徴です。年1回行っているこの講演も6回目になりますが、今年はさらにバージョンアップしてお届けするつもりです。

普通の現場改善コンサルタントや、ITベンダー系コンサルタント達の提言に、飽き足りない気持ちでおられる技術者の皆さんの、ヒントになればと思っています。

===================================

「生産スケジューリングの基礎とリードタイム短縮のポイント　〜演習付〜」（3月24日）

日時：　6月27日（水）　10:30～17:30

主催：　株式会社日本テクノセンター

http://www.j-techno.co.jp

会場：　株式会社日本テクノセンター研修室

　　　　　東京都新宿区西新宿2-7-1 小田急第一生命ビル22F

　　　　　（都営地下鉄大江戸線「都庁前」駅または丸ノ内線「西新宿」駅）

生産計画とスケジューリング、リードタイム短縮について、事例と演習を含めてお話しします。

セミナー詳細：　下記のURLをご参照ください（受講申込もここからできます）

https://www.j-techno.co.jp/seminar/seminar-18730/

===================================

関心のある大勢の方のご来聴をお待ちしております。

佐藤知一

プロジェクト・マネジメントの能力は何で決まるか

先週からまた、大学で行う週一回のプロジェクト・マネジメントの講義が始まった。準備にはそれなりに手間がかかるが、それでも、授業自体は楽しい仕事だと思う。わたしはなるべく、大学の講義をインタラクティブにやろう、と心がけている。単なる一方的な講義形式では面白くないし、自分が学生だった頃のことを思い出してみても、そうした授業で頭に残った事は少ない。

教育とか研修は、それを受けた後で、自分自身の行動が変わらなければ、ほとんど価値がない。学びとは、自分の能力を高めるために行うものだ。単に知識が増えただけで、自分の行動に変化がなければ、何かを学んだことにはならない。だから、せめて授業の間は、なるべく学生に考えてもらい、また、手を動かしてもらうようにしている。インプットだけでなく、何かアウトプットしてもらうことで、相手の理解も測れるからだ。

そしてもちろん、一番良いのは、質問をしてもらうことである。ただ、授業中に「何か質問ありますか?」と問いかけても、学生が手をあげてくる事は、ほとんどない。他の皆の前で、何か質問を口に出すことには、心理的な抵抗があるらしい。私たちの社会におけるコミニケーションには、「受信者責任の原則」とも言うべき暗黙のルールがあるらしく、理解できないのは、受け手の側の理解力が低い（＝頭が悪い）せいだ、と判断されかねないからだろう。

仕方がないので、わたしは講義の際、毎回必ず「出席シート」の紙を配り、そこに授業で感じた質問や、コメントを書いてもらうことにしている。こうすると、無口な学生たちもそれなりに、色々と質問を書いてくれる。こうして出た質問は、次の週、授業で極力回答するようにしている。

中でも、いい質問だなぁ、と感じる問いに対しては、「今週のGood Question賞」を与えることにしている。良い質問は、教える教師にとって、何よりもうれしい報酬である。質問が出るという事は、教え方に足りない点があったことを示しているし、特に良い質問は、教師のものの見方に、新しい光を投げかけてくれるからだ。良い質問は大抵、答えるのがやや難しい質問だし、それを考えることで、むしろ教師を育ててくれるのだ。

さて、先週のプロジェクトマネジメント講義の第一回目のテーマは、「プロジェクトとは何か?　マネジメントとは何か?」だった。まぁ要するに、全体へのイントロダクションである。プロジェクトの定義を説明し、それを自己流に敷衍する。さらに「マネジメント」なる言葉の意味の中核には、「人を動かす」ということがあると説明した。

さて、帰り道に出席シートを読んでいると、次のような質問に出くわした。なかなか面白い質問だと思う。読者諸賢だったら、この問いにどう答えられるだろうか?

「マネジメントの能力は、どう見極めるのが良いのでしょうか。単にプロジェクトの成功・失敗だけで評価するなら、プロジェクトの難易度に差があるので、不公平だと思いました。それとも『結果がすべて』なのでしょうか？」

とても良い視点からの質問だ。プロジェクトを扱ういろいろな企業の経営者に、そのまま問いただしてみたい気持ちにもなる。プロジェクトは一つ一つが固有の、その場限りの、時限的な取り組みだから、難易度に差があるのも当然である。この学生はちゃんと、その本質を理解している。その上で、この問いを投げかけている。

「プロマネは結果が全て」という決めつけ方に、わたしはずっと反対してきた。それは、個々のプロジェクトを取り巻く環境の違い、難易度の差をまるで無視した、ものの言い方だからだ。以前も書いたが、プロジェクト・マネジメントの能力は、いわば確率的な能力である。プロ野球の選手だって、一度限りの打席の結果だけで能力を判定したりはしない。何試合分か、ないしはシーズン全体の打率（ヒットの確率）で、能力を測るのである。

「優秀なプロマネなんかいない。運の良いプロマネがいるだけだ。」という言葉を、最近、ある大先輩から聞いた。一種の逆説であろう。優秀なプロマネさえ連れてくれば、どんなに難しい大規模プロジェクトでも、うまく収まるはずだ、といった思い込みに警告を発する言葉だ。

そもそも、プロジェクト・マネジメントの能力とは、プロマネ個人の能力だけで決まるものなのだろうか？　このような思い込みは、世間でかなり根強い。

こうした信憑は、さらに３種類に区分することができるように思う。第一は、プロマネの能力は、その人の人柄や根性、あるいは頭の回転の速さで決まるという考え方である。「あの仕事がまとまったのは、プロマネの彼が根っから優秀だからだよ」と言うわけだ。つまりプロジェクト・マネジメントの能力は、プロマネの資質で決まるとの信憑である。

もしこのような考え方が正しいのだとしたら、会社がプロジェクトマネジメントの能力を向上するには、どういう対策が必要だろうか？　資質はある意味、生まれつきのものである。である以上、生まれつき優秀な人間を、プロマネの座につけるかどうかで、ビジネスの成否が決まってしまう。逆に言えば、だめなプロマネ達は、もう一度生まれ変わるしかない、ということになる。まことに身もふたもない結論だ。だが、これで能力向上の処方箋と言えるだろうか?

第二の考え方は、「プロジェクト・マネジメントの能力はプロマネの知識で決まる」というものである。こちらの方が、能力は生まれつきだと言うよりは、多少救いがある。知識ならば、本や研修から得ることができるからだ。十分な知識があるかどうかは、ペーパーテストなどの試験で検証可能だ。そして実際、PMP (Project Management Professional)の資格試験などは、こうした論理でてきあがっているように思う。そうでなければ、パソコンの端末に向かって何時間も、ひたすら４択問題を答えさせる、などという資格審査の方法を思いつくだろうか。

しかし本当に、プロジェクト・マネジメントの能力を、知識だけで判断して良いのだろうか?　知識量と記憶力では、人間はコンピュータにかなわない。だとすると、いずれプロマネの仕事は、AIが人間を駆逐することになる。そして人々は、ただコンピュータの指示に従って、仕様書を書いたり、構築結果をテストしたりするだけの身分になる。・・これで本当に、全てのプロジェクトは、成功するようになるだろうか?　この考え方は、いささか疑問に思える。

となると、プロジェクトマネジメント能力は、プロマネ個人のスキルである、ということになる。資質でもなく、知識だけでもない、と。これが三番目の考え方である。スキルとは身体化された技能で、かつ、ある程度まで属人的なものだ（「あの人のスキルはすごい」というが、「あの会社は高いスキルを持っている」とは、普通言わない）。

スキルは身に付けることができる。なおかつ、スキルを身に付けるには、練習が必要である。ここが単なる知識取得と違う点だ。そのためには、実地練習の場を作る必要がある、ということになる。練習の場とは、言い換えれば、失敗しても、傷つかずにすむ場所である。そうした場を作り、提供できるかどうかが、エンジニアのPM能力の向上のカギになると言うことだ。

ところで、ここまでは、PM能力はプロマネ個人の能力だけで決まる、と言う立場の議論だった。これに対し、いや、プロジェクトのパフォーマンスは、プロマネとチーム員の能力で決まるはずだ、という見方もありうる。つまり、組織としての能力ということである。わたしは、どちらかということこの意見に組する。

ただ、この考えも、２種類に区分できよう。よくありがちな見解は、「組織の能力は、構成員の能力の足し算である」、との考えだ。これは、能力ある人間を揃えれば、自動的に組織のパフォーマンスもよくなる、という、単純な足し算の論理である。オリンピックなどで、トップチームのスタープレイヤーばかりを集めた「ドリームチーム」を作れば最高だ、という話がでるが、この延長上の発想だと思う。

では、この考え方からは、どのような能力の向上策が導かれるだろうか。各人の能力はまちまちである。となると、良いプロジェクト運営をしたければ、ベストなメンバーを選ぶしかない、ということになる。つまり社内での人の取り合いを、推奨するわけだ。でも、これでは企業全体のパフォーマンス向上にはつながるまい。

そしてドリームチームが必ずしも最高でないのと同じように、組織もまた、単なる能力の足し算では決まらない。そもそも能力といっても、いろいろ種類がある。プロマネに求められる能力と、チーフ・デザイナーに必要な能力と、品質管理責任者の能力は異なる。こうした別々の能力が、適材適所に生かされるよう構成配置し、かつ問題を速やかに検知して対処するのが、そもそもプロマネの仕事ではないか。つまりマネジメント能力とは、「能力に関する能力」、ないし「能力を活かす仕組みづくりの能力」なのである。

そうした仕組み（システム）を、組織の全員が理解・共有し、皆がその中で安心して働ける状態になっていること。だから、毎回書いていることだが、プロジェクト・マネジメントにはシステムズ・アプローチが大切なのである。そして、システムズ・アプローチから生み出されたWBSやCPM・EVMSといった技術が重要になる。

つまり、プロジェクト・マネジメント能力は、組織が共有する技術で決まる、というのがわたしの考えだ。技術は本来、蓄積・移転可能なものだ。その技術をもとに、仕組み（システム）を作る。無論、プロマネ個人のスキルも、もちろん必要である。ただ、それだけで十分条件にはならない。組織の構成員一人ひとりが、その思考と行動習慣（＝組織のOS）を共有すること。これが能力向上の処方箋である。

ここに書いたようなことは、別にわたしの独創ではない。落ち着いて順序立てて考えれば、誰でも思いつくことだ。もちろん、見解の差はあるだろう。「やっぱり人間の能力は、生まれつきの差だろ」と信じるのは自由だ。だが、そこから、どういう帰結が生じるかも、考えてみてほしい。

もしも仕事のパフォーマンスを左右する能力が、リーダーやプロマネ個人に付随する能力だけで決まるのだとしたら、企業の成長力は、優秀な人間の頭数で制約されることになる。優秀な人間は限られていて、急には育たない。したがって、このような思想に立つ限り、ビジネスをスケールアウトすることはとても難しいーーこれが道理である。

わたし達の社会は、こんな個人依存の考え方を、もう20年この方、続けてきた。その間、海の外の競合相手は、仕事のシステムを作ることで、成長とスケーラビリティを実現してきたのだ。今やその差は、歴然としつつある。

わたし達に必要なのは、仕事に関する基本的な概念について、思い込みや常識をいったん置いて、ロジックを見直してみることではないだろうか。それは、上に述べたように、大学生にだって発問できるのである。知識を勉強することだけで十分ではない。良い質問を考える事こそ、はるかに価値があるのだ。

＜関連エントリ＞

　→「マネジメントとリーダーシップはどう違うか」 https://brevis.exblog.jp/24082343/ （2016-01-25）

　→「天の時・地の利・人の和と、プロジェクト」 https://brevis.exblog.jp/26170090/ （2017-11-12）

「インテグレーター不在」という深い谷間

先日、ある技術系コンサルタントの方が来訪したので、最近の話題を聞いた。AI技術がこのところ注目を集めており、工場の製造現場でも、様々な取り組みを始めている。ただ、汎用的なAIのエンジンを、自分たちの仕事の用途に合わせて、テーラーメイドで開発するには、それなりの力量が要る。

そこで最近は、FA用途に向けた「アプリケーション特化型」のAIソフトが出てきた、という。特定の目的、例えば機械の振動のデータを蓄積分析して、異常の予兆を診断するといった、目的特化型のAIソフトが出てきているらしい。これが次のトレンドかな。なるほど、なかなか面白い。

ただ、ひとつ心配な点がありますね、とわたしは指摘した。そうしたアプリケーション特化型のAIソフトを売るベンダーと、工場でそれを使用したユーザとの間に、1つ問題となるギャップがある。それは、AIのソフトウェアパッケージと、工場側の具体的な制御システムないしMESとの、インテグレーションの仕事である。

その仕事を、自分たちだけでできるユーザが、果たして日本の工場でどれだけいるだろうか?　かといって、2つのシステムを統合する難しい仕事を引き受けてくれる業者、すなわち製造現場に強いシステム・インテグレーターがいるかというと、世の中には決して多くない、という事情がある。

つまり、AIベンダーと製造現場のユーザーとの間に、「インテグレーター不在」という深い谷間があるのだ。

いや、話はAIのソフトウェアに限らない。MESのソフトを導入するにせよ、あるいはデジタル屋台のシステムを買ってきて、社内の3D-CADとつなげるにせよ、同様の困難がある。いや、それどころではない。例えば産業用ロボットを買ってきたり、あるいは気の利いた搬送システムや立体自動倉庫を買ってきて、自動化・省力化を図る場合だって、自社の製造ラインとのインテグレーションが必要になるのだ。こうした仕事はしばしば、生産技術を受け持つ機械エンジニアだけの手には余る。

もちろん、高価な機械を何台も買ってやるから、ついでにインテグレーション業務もしてくれ、と機械メーカーに要求することは可能だ。実際、有力な機械設備メーカーの中には、自社製品を買ってくれることを条件に、請け負ってくれる企業もある。ただ、そうした「つなぎ」の仕事は、しばしば、子会社や下請けにやらせたりするらしい。

逆に、いや、それはお客さんの仕事です、と突き放すメーカーもある。請ける・請けない、いずれの場合も、機械メーカーやパッケージソフト・ベンダーが、製造現場におけるインテグレーションの仕事自体を好んでいない点では、同じだ。

なぜか。儲からないからである。

『インテグレーション』とは何か。それは、それぞれ単独で完結した機能を持つ要素群を、上手に連結して、一体として働くようにすることである。

例えばパソコンのソフトに例えるならば、ワープロと表計算とのあいだで、クリップボードを経由したコピー＆ペーストを可能にすることも、インテグレーションの一例だ。今日では、まるっきり当たり前のように思えるこの機能も、'90年代前半までMS-DOSやCPMといった旧世代のPC用OSを使っていたユーザにとっては、とても新鮮なものだった。当時の感覚では、Lotus 1-2-3で表を作成して、WordPerfectの文章の中に貼るなど、想像しにくい使い方だったのだ。

だからMacOSやウィンドウズが登場して、OSレベルでカット&ペーストをサポートし、複数のアプリケーション間でデータのやり取りを統合的に行えるようにした事は、ほとんど革命的な進歩だった。これがインテグレーションの価値なのだ。

あるいは、鉄道の世界でたとえるなら、インテグレーションとは「相互乗り入れ」がそれに該当する。私の勤務先は横浜の「みなとみらい」地区だが、実家は今は埼玉県所沢市にある。以前は、職場から実家まで帰るためには、渋谷と池袋で2回、乗り換えなければならなかった。そのたびごとに階段を上り下りし、行列に並んで席に座らなければいけない。

だから、西武池袋線と副都心線と東横線・みなとみらい線が相互乗り入れを開始し、みなとみらい駅のホームに小手指行き列車が到着した瞬間は、頭がクラクラするほどの衝撃があった。実際、乗り換えの不便が減ったし、所要時間も圧倒的に短くなった。これも、インテグレーションがユーザにもたらす価値だ。

周知の通り、システムにおける要素間のインタフェースには、密結合と疎結合の2種類がある。製造現場の例で言えば、一貫生産ラインは密結合であり、工程間に在庫のスペースがあるのは、疎結合である。コンピュータなら、「ファイル渡し」は疎結合であり、APIの呼び出しなどは密結合だ。

高度なインテグレーションとは、サブシステム間を密結合・強連結にすることである。すなわち、一つの指示（インプット）で、複数の要素が連携協調して動作するようにすること。あるいは、モノやデータの受け渡しのある要素間では、処理量とタイミングを同期化することだ。

また、部分に異常が生じたら、全体が安全にスローダウンする、ないし、共通したアラームを発信するといった対応もいる。さらには、必要に応じて、個別要素を部分的に立ち上げたり、全体を止めずに切り離したりできる機能も必要だ。

したがって、構成要素数が多く、かつ高度にインテグレーションされたシステムには、主要な全要素をモニタリングする「情報のハブ」が、必然的に生まれてくる。そこが、全体のタイミングをとり、要素に適切な指示を出す。まあ、オーケストラの指揮者のようなものである。

こうした「インテグラルなシステム」を作る仕事のプロが、インテグレーターである。

つまり、インテグレーターの仕事とは、システム構築＝仕組みづくりである。だが、「システム」という、目に見えないものが理解できない人たちには、そもそもその価値が分からない。この人達には、目に見えやすいもの、たとえばロボットだとか、立体自動倉庫だとかAIソフトパッケージだとかいったものが、価値の中核に見える。インテグレーション作業はオマケだ、という訳である。

高価な機械を買ってくれる代償として、周辺のインテグレーション作業を請け負うメーカーは、ある意味、そうした理解ないし誤解を助長しているとも言える。もちろん、エンドユーザーを助けるという積極的な面もあるわけだが。

インテグレーションの仕事は、ユーザの個別性の高い要求（制約条件）に合致するよう、複数の要素を選んで組み合わせる能力を必要とする。つまり、「すり合わせ」型の業務である。工場のように、既存の機械や仕組みと組み合わせる場合、相手の状況に応じて作業量が変わるし、つながらないリスクもある。だから、本来は固定金額の見積にはなじまない仕事だ。

それなのに、たいていの顧客は、インテグレーション・サービスに要した人工（工数）分の費用しか、インテグレーターに払ってくれない。曖昧でリスクが大きいのに、である。だから、インテグレーションは儲からない商売だ、という事情が生まれる。

だったら、単体売りに徹する方が、商売として「堅い」「手切れが良い」ということになる。かくて、ウチは単体設備メーカーです、というスタンスを持った企業が栄えることになる。いいかえると、優秀な部品メーカーは多いが、全体システムの売り手はあまりいない、ということで、どこかの業界によく似た構図ができている。

工場系の生産システム・インテグレーターは、機械メーカーの下請けに位置せざるを得ない。だから、中小零細企業が多い、という話を良く聞く。そうなると、人材の確保や育成も課題だ。

それでも、信頼できるインテグレーターを、身近に抱えている企業なら、まだ良い。多くの場合は、ユーザが自分でインテグレーションするしかない。そこで、機械設備やIT系における、モノの受け渡しやデータ通信インタフェースの標準化、せめて共通化が望まれる。

いや、本当は、機械設備メーカーやITベンダーなどは、インテグレーションされることを前提に、自社製品を考える態度が必要なのだろう。だが、かつてIBMのOS/360開発のプロマネで、後に名著『人月の神話』を書いたBrooks Jr.によると、要素をインテグレーション可能な形にするには、単に作るだけに比べて、3倍の費用がかかる、という。

これはソフトウェアの場合の話で、機械設備の場合は、もう少し小さな数字になるだろうが、余計なコストがかかるのは事実だ。コストがかかれば、製品の価格に跳ね返る。価格競争にさらされるメーカーにとっては、ありがたくない話だろう。

では、どうしたら良いのか。要素技術のプロバイダーと、ユーザの間には、「インテグレーター不在」という深い谷間がある。ここうまくつながないと、ユーザが困るだけでなく、優れた技術を持つAIベンダー・機械メーカー等のベンチャー企業も、日本では育たないことになる。

もちろん、エンドユーザーである日本の製造業の、経営管理職の人たちが、インテグレーションの価値を認めて、それにきちんとお金を払うようになることが、理想型である。しかしそれは、百年河清を待つ、の類だろう。

わたしは、こうしたFA系のインテグレーターたちが、下請けや系列の地位から脱するためにも、せめて一個の独立した業界として認められ、その価値を世間に対してアピールしていくような方策が必要だろうと思う。そのためには、業界団体の結成も、ひとつの手段だろう。聞くところによれば、近々、経産省の旗振りで、「ロボット・インテグレーション協会」が設立されることになる見通しだと言う。これは良いニュースだ。

しかし「深い谷間」の問題は、ロボットという（先進的な見かけの）部分だけでは留まらないはずである。より広く、産業システムのエンジニアリング、ないし生産システム・インテグレーションの担い手が、求められているのだ。以前、政府の「ものづくり白書」には、『ラインビルダー』という言葉も紹介されていた。こうした業界の確立を助けるために、国の支援策も必要だろうし、標準的な契約や仕様のあり方も、議論される必要がある。

ドイツのIndustry 4.0の向こうをはって、日本は「ソサエティー 5.0」を目指すのだそうだ。"Connected Industries"というスローガンも、よく見かける。それが具体的に何を意味しているのか、わたしにはまだよくわからない。だが、少なくとも、インテグレーター不在と言う深い谷間を、埋めるための努力が必要だという事だけは、明らかだろう。

POPとは何か、MESとはどこが違うのか

工場見学が趣味である。いや、趣味というのは言い過ぎかも知れないが、とても好きなことは確かだ。昨年から思うところあって、いわゆる組立加工系の工場について、機会があれば業種を問わず見学して歩いている。国内外あわせてすでに１ダースを越えたから、平均すると一月に1ヶ所は訪問している勘定だ。むろん、工場の改善指導をしているプロのコンサルタント諸氏には及びもつかないが、まあそれなりに見ている方ではないか。

工場見学に行ったら、何を見るべきかについては、すでに記事も書いた（「超入門：上手な工場見学の見方・歩き方」 https://brevis.exblog.jp/21898734/ 2014-04-16）。とくに製造現場を歩いているときは、できるかぎり、現品票を見ることにしている。

現品票とは何か。それは、工場の中を行き来している部品・材料などの現品に添付されて回っている紙の帳票のことである。なお、機械加工系では、加工対象の物品のことを「ワーク」Workとも呼ぶ。英語のworkは仕事・作業の意味が強いが、仕掛品のことをWork in Process（略称WIP）と呼んだりもする。そこで以後、この記事の中では、現品とか物品という代わりに、ワークということにする。現品票とは、工場内でワークに添付されている紙の帳票のことである。

ワークはそれぞれが個別だから、現品票もそれに1対1でついている必要がある。ただしワークが小さな部品である場合や、ロット単位でずっと流れていく場合は、複数個のワークに1現品票のこともある。ただ、その際は、複数個のワークが、通い箱や台車などに入っていて、物理的にワンセットで動かなければならない。そうしないと、ワークと現品票の対応関係が崩れてしまうからだ。

現品票とは、ワークについて「これは何か」を示す名札のようなものだ。小学校の新入生につける名札と思えばいい。高井戸小学校・1年4組・佐藤知一、という風に（たしか1年のときは4組だったと思う・・違っているかも知れないが）。現品票には、少なくともそのワークの品目コード・品名が表示される。

そして、通常は、そのワークが使用される『製造オーダー』の番号と付帯情報も示される。もっとも、日本では生産関係の用語に統一がないため、企業によっては製造オーダーではなく「製番」「製造指図番号」と呼んだりする。付帯情報とは、製造作業の納期、必要数量、製作図面の番号、どの最終製品に使われるか、どの工程（作業区）で使用されるか、等々だ。ちなみに、トヨタ生産方式で使われる「かんばん」も現品票の一種である。

工場内には多種多様なワークが流れている。それに対して、一対一で現品票を発行し添付するのは、手間とコストがかかる。ただ、それをやらないと、目の前のモノが何なのか、本来どこに置くべきか、いつまでに使用されるのか、等々が、「良く知っている担当者」以外の人には分からなくなってしまう。だから、すべてのワークに現品票がついているかを見ると、その工場のマネジメント・レベルがすぐ判断できる。

そして、現品票にバーコードがついているかどうかも、大事なポイントだ。

現品票には、人間に必要な情報は印字してある。では、バーコードは何に使うのか？　答えは、POPに使うのだ。

POPとはPoint of Production、すなわち「生産時点情報管理」の略称だ。ふつうは、それを支えるITシステムのことを指す。流通業界、たとえばコンビニでは、お客が買い物をすると、レジで商品のバーコードをスキャンして、品目・数量を確認し、金額を計算する。この時点で、購入情報はレジを通して吸い上げられる。この仕組みをPOS（Point of Sales）＝「販売時点情報管理」という。そしてバーコードリーダと通信機能のついているレジを、「POSレジ」と呼ぶ。

POSシステムが表れる前は、商店は、一日が終わって棚の残量をチェックするまで、販売数量を知る方法がなかった。その時点で翌日の仕入れ数量を決めるのでは、遅すぎる。だからPOSという概念が現れた。

同じように、従来多くの工場では、一日が終わって作業者が「製造日報」を記入するまでは、何がどれだけできたのか、把握する方法がなかった。これでは、短納期化した注文に追いつくことが難しい。そこで、流通業界を真似る形で、POPシステムを導入する工場が現れるようになったのだ。

POPシステムでは、現場の作業者が新しいワークに対する作業に着手するとき、現品票のバーコードをスキャンする。また、作業が完了したときも同様に、スキャンする。これによって、作業区単位（ないし機械単位）に、どのワークを、いつ着手/完了したかを、システムがリアルタイムに把握する。

POPの目的は、大きく三つある。一つめは、個別オーダーの進捗把握である。受注生産では通常、個別の注文（オーダー）ごとに、納期と数量が決まっている。生産管理担当者は、製品単位の「生産オーダー」を、部品展開（工程展開）して、各部品ごとの「製造オーダー」に展開する。この時点で、各工程ごとの数量と期限が決まる。そして、これを製造現場に指図として送る（これを「差し立て」ないし「ディスパッチング」とよぶ）。と同時に、それぞれの部品に対して「現品票」を発行し、現品に添付させるのである。

したがってPOPシステムを利用して、予定した製造作業の期限に対し、きちんと完了の信号があがってきているかをチェックすれば、進捗状況が把握でき、遅れがある場合は検知できる。現品がどの作業区にあるかについて、ラフな所在管理もできる。

二番目の目的は、作業時間の計測である。着手・完了時刻を取得している訳だから、作業時間を計算するのはたやすいし、従来の日報に比べて、正確だ。作業時間が分かると、賃率をかけることで、個別オーダーのコストの集計・管理ができるようになる。すると、オーダー単位の利益が計算できるし、また次の見積にも基礎データとして役に立つ。

三番目の目的は、生産性の把握だ。こちらも作業時間の計測が基礎になるが、さらに機械単位ないし作業者単位に、どれだけの生産数量ができたかを集計し、生産性を比べることができる。もしも標準工数が決まっているのならば、作業区別の負荷と余力も推算することができる、という訳だ。

POPシステムの概念は決して新しいものではない。図は、わたしが1992年に、中小企業診断士の受験参考書のために描いた、手書きの図（笑）である。日刊工業新聞社「工程管理ハンドブック」を参考に作図した。今から26年も前の話なので、「ホスト・コンピュータ」などと書いてある。今ならPCサーバとかエッジサーバと書くところだろう。

ちなみに、POPに隣接する概念として、SOPおよびデジタル屋台の支援システムがある。SOP（Standard Operating Procedure＝標準作業指示書）とは、適正な作業を行い品質を保つ目的で定める、作業の詳細な手順指示である。これは医薬品製造や食品製造などの分野で広く用いられる。これを電子化し、現場の作業者に端末経由で示し、それにしたがって確認記録を入力することで、製造作業をガイダンスする仕組みを、この分野ではよく用いている。とくに医薬品はGMP（Good Manufacturing Practice）の法的要請があり、適正な作業記録が義務づけられるからだ。

デジタル屋台とは、組立工程における一種のセル生産の仕組みである。ちょうど屋台のように、作業台を一人1台ずつ与え、台の周囲に部品供給用の引き出しやラックを置く。そして、作業台にはモニターを設置して、作業者に対して組立作業をワンステップずつ、3D的に図解して示すのである。とくに組立の部品点数が非常に多いケースや、個別受注で組立手順が毎回少しずつ違うケースに有効である。

さらに、作業者が部品棚から正しい部品を正しい個数取り出したか、とか、適正なトルクでネジを締めたか、といった点までセンサーでモニタリングすることも行われる。現在、静岡大学客員教授の関伸一氏が、2000年代にローランドディージー社で見事なデジタル屋台システムを作り上げ、広く知られるようになった。この事例では、作業者一人ひとりの生産性を測定し、自分の能力アップを実感できる仕組みにして、作業者のモチベーション向上に大いに貢献したという。

SOPもデジタル屋台も、必ずしも現品票とバーコードを活用するとは限らないが、作業時間を計測しているので、いろいろと付加的な機能を持てる点で共通している。

このようにメリットの大きいシステムであるにもかかわらず、日本の全ての工場に常識的に普及しているかというと、決してそうでもない（だから毎回、工場見学のたびに現品票とバーコードをチェックしているのである）。技術的には、25年前から存在し、ある意味、もう枯れた技術である。なのに、なぜ普及しないのかについては、ここではあまり深入りしないが、大きく３つの要因がある。一つめが、こうした製造現場のIT化投資に関する経営側の無理解、二つめが現場作業者のもの言わぬ抵抗、三つめは生産管理（とくに生産計画）担当部門の力量不足である。（さらに4番目をつけ加えるなら、現場に強いITエンジニア不足もあるが）

ところで、この１〜２年ほど、少し潮目が変わったかな、という感じを受けている。IoT技術の進展と、スマート化・AIブームなどの影響で、再び製造現場のIT化の遅れが問題視されるようになった。今回は特に、深刻な人手不足問題が追い打ちをかけている。自動化を進めないと、受注をさばききれない、という状況があちこちに生じたのだ。その結果、たとえばわたし自身も、MES（Manufacturing Execution System＝製造実行システム）に関する問合せを受けるようになってきた。MESの話題なんて、この15年間、特定業界以外の人はほとんど誰も口にしなかったのに。

MESが何かについては、別に解説記事も書いた（「IoT時代のMESをもう一度考え直す 〜 (1) MES普及を妨げたもの」 https://brevis.exblog.jp/25991822/ 2017-08-19）ので、ここでは繰り返さない。ただ、POPとMESの関係だけは整理しておこう。簡単に言うと、POPとはMESの第一歩である。

そもそも、組立加工系の工場におけるMESの機能要素は、7種類くらいに分けることができる（世間的にはMESA Internationalの「11機能」を列挙するのが通例だが、あれはプロセス系も混ざり込んで分かりにくいので、自分流に整理し直した）

(1) 詳細な工程（作業）展開と指示発行（SOP含む）

(2) 機械設備の高度な連携制御（DNC含む）

(3) 製造プロセスのモニタリング

　→これは、機械・人の状態監視と、ワークの所在・数量・移動の把握に、さらに区分できる

(4) 製造オーダーのトラッキング

　→これも、進捗と完了予測、そしてトレーサビリティ機能に区分できる

(5) 品質と製造パフォーマンスの計測

　→すなわち、品質・リードタイム・生産性の計測と分析である

(6) 製造資源の維持・保守

(7) 製造技術情報（製作図面・BOMを含む）の共有・検索

逆に、MESでは通常、対象外となる機能もある。すなわち、

(8) 通常の制御系機能

(9) 調達・コスト管理機能

POPは、上の機能リストで言うと、(1)と(3)を部分的にカバーしている。つまり、MESのサブセットという訳だ。もちろん、別に上の機能全てをカバーしなければ、MESと呼んではいけない、というつもりはないし、工場によって必要な機能のセットは異なるだろう。そこはもちろん、IT化の手間と効果、そしてコストの見合いで決めるべき事柄だ。一般に、対象業務の規模が大きくなり、コントロールすべき物事の数が増えたら、IT化の効果が出やすい。

さらにいうなら、市販の生産管理システム・パッケージや、ERPパッケージにも、ある程度POP的な機能が実装されている場合が多い。現代では、選択肢はいろいろあるのだ。ただ、生産管理やERPが、どちらかというとコスト管理目的に傾斜しがちであるのに対し、単体のPOPやMESは、製造プロセスの円滑なマネジメントが主目的であるという違いはある。それに応じて、現場に要求される作業も微妙に変わってくるだろう。

わたしの個人的な意見としては、最初から製造現場に細かなコスト管理の仕組みを持ち込むよりも、まずは製造が遅滞や不良なく円滑に進むことを、優先すべきではないかと思っている。ここは異論のあるところかもしれないが、もしも納期遅延や生産性に悩んでいるのなら、単体のPOP構築からはじめてみるのが、賢い選択ではないだろうか。

＜関連エントリ＞

　→「超入門：上手な工場見学の見方・歩き方」 https://brevis.exblog.jp/21898734/ （2014-04-16）

　→「IoT時代のMESをもう一度考え直す 〜 (1) MES普及を妨げたもの」 https://brevis.exblog.jp/25991822/ （2017-08-19）

書評：「小水力発電が地域を救う」中島大・著

「小水力発電が地域を救う」 （Amazon）

最近読んだ中で、最も面白かった本だ。わたしはあまり新刊書を批評しない（というか、読んだけれど書評を書けずに溜まっている本が沢山ありすぎる^^;）。だが、この本はできる限り多くの人に読んでもらいたいので、あえて順番を飛び抜かして取り上げよう。

タイトルを見ると、本書はたんに再生可能エネルギーの一分野である「小水力発電」を紹介し、宣伝するだけの目的に思えるだろう。だが著者は、この一見地味な技術について、もっと広いパースペクティブ（ほとんど文明論的な視野）に立って、日本社会に与えうるポテンシャルを論じる。いやあ、頭の良い人が書いた本は面白いなあ、と読みながら久々に感じた。お勉強のできる人や知識の豊富な人は、たくさんいる。だが、広い視野からものごとを多面的にとらえて考えられる人は、滅多にいないのだ。

著者は、全国小水力利用推進協議会の事務局長。経歴を見ると、’85年に東大の物理学科を卒業するが、その後は官庁や大企業にいかず、ベンチャー企業をへて、2005年に非営利の協議会組織を立ち上げ、リードしてきた人だ。

思い出してみると、2005年頃と今では、再生可能エネルギーをめぐる状況は、まったく変わってしまっている。その供給量も価格競争力も、世界的にここまで進むとは、誰も思わなかったろう。日本では2011年にFIT（固定価格買取制度）が制定され、以来とくに太陽光発電がブームになった。

だが、わたし達が最も古くから利用してきた再生可能エネルギーは、水力なのだ。日本は気候と地形に恵まれ、水力利用の適地だという事情もある。だが、著者が指摘するように、ヨーロッパの産業革命も、じつは水力からはじまった。アークライトの水力紡績機は、ジェームズ・ワットの蒸気機関よりも先に現れ、機械工業化の火付け役となったのだ（p. 150）。

水力発電のメリットとは何か。それは、発電量が安定していることだ。太陽光が、日周変動を不可避的に持つことはいうまでもない。では、風力発電はどうか。じつは、風力の発電量は、風速の3乗に比例するという物理法則がある（流体の動圧＝運動エネルギーは流速の2乗に比例し、かつ発電の能力はタービンを通過する風量に比例するから）。大気乱流のスペクトル分布を考えれば、風力発電がいかにブレやすいか容易に想像がつく。

水力発電も風力発電も、基礎原理的には同一だ。なのに、発電量の安定度が違うのは、水力は発電機のタービンの前に、堰・ダム・水路などのバッファーをたっぷり持っているからだ。さらに、天からふる降雨量を、山それ自体が平準化して流出してくれる。本書が対象とするのは、1000 kW未満の小水力だが、それでも全国の開発可能量（経済性を考慮した数量）は数千箇所、合計100万kW程度と見込まれている（p.21）。ほぼ原発1基分である。これだけあれば、足下の山間地の需要はおおむね満たすことができる、という。

ただし、第8章「歴史の中の小水力発電」に詳しく書かれているように、日本には小水力発電が育ちにくい不幸な事情があった。現在、小水力発電を計画しようとすると、肝心の水車を、欧州やアジアから買ってこなければならない。発電用水車を安価に製造できるメーカーが、日本にほとんど無いからだ。なぜ、この技術大国で、水車程度を作れる企業が存在しないのか。それは、そもそも市場がなかったからだ。

戦前の日本では、水力発電事業を行う鉄道会社や自治体も、それなりに沢山あった。しかし、「戦争に伴う挙国一致体制を築くため、小水力も含めて、発電所・電気事業は日本発送電という国策会社に統合されてしまいます。そして敗戦後も、元に戻すのではなく、（沖縄を除く）9社の電力会社に分割再編することになり、地域の小水力発電所もその電力会社に帰属することになりました」（p.158）

地域独占となり、経済成長で巨大となった電力会社にとって、「戦前から引き継いだ小水力発電所はコストパフォーマンスがわるいため、だんだんと廃止され」ていった（p.159）。たとえば東電管内の山梨県では、300kW以下の発電所は廃止の指示が出た。こうなると、機器を製造するメーカーも生きていけなくなってしまう。

ところがヨーロッパでは事情が違った。もともと歴史的には、日本も欧州も、大都市向けの大規模水力の開発と、村落向けの小水力の増加が並行して進んでいた。だが敗戦国ドイツでさえ、小水力発電所の統合は行われなかった。今でも村営の発電所が多数残って、馬鹿にならない量の電力を安定供給している。かくして、今でもドイツやイタリアに、安価で優秀な水力機器メーカーが生き残っているのである（p.159-161）。

ただ、歴史の面白いところは、このような状況にもかかわらず、民間が自由に水力発電事業を営める形態が、ほんの一筋の水脈のように、残ったことだ。それも、なぜか中国地方に残っていた。織田史郎という人物のおかげだった。彼は中国電力の前身にあたある中国配電会社の役員だった。彼は、戦後まだ残っていた「無点灯地区」（電気の来ない村）では、自力で発電事業をやればいいと考えた。そして将来、配電線が村に届いたら「電力会社に電気を売って、地域振興の財源にすればいい」とまで見通した（p.164）。

こうして彼らの働きかけにより、「農山漁村電気導入促進法」が1952年に制定される。織田の努力が実り、中国地方には最盛期には200ヶ所もの小水力発電所があった。事業主体は農協や漁協、土地改良区などだ。水力発電設備は寿命が長いから、今も50ヶ所が事業を続けているという。ただ、全国的には衰退していく。「その原因を一言で言えば『挙国一致体制で国策会社に統合した』ことにつきます」、と著者は書く（p.167）

しかし、まだ「促進法」自体は生き残っている。これを活用する形で、この10年ほど、全国にぽつりぽつりと、地域振興をかねて小水力発電が復活しはじめた。その代表例は、第1章に詳しく書かれている岐阜県郡上市石徹白（いとしろ）地区の事例だ。岐阜市出身で一時は外資系コンサル会社に勤めていた平野彰秀氏が、一種のUターン（正確にはIターン）をし、地域づくり協議会として、マイクロ水力、ミニ水車をつくっていく。ついには発電目的の農協を組織し、125kW出力の発電所を建設するのである。

「FIT制度が始まった今は、小水力発電に良い時代です」と著者の中島さんは書く。「農産加工品などの市場開拓は簡単ではありません。ところが、小水力発電の電気は、FITのおかげで必ず売れるという利点があります」（p.47）。

石徹白の取り組みの原動力になったのは、じつは小学校が廃校になってしまうかも知れない、という危機感だった。「小学校の存続は、地域が存続するかどうかの先行指標と言っても過言ではありません。子育て環境の悪化で若い夫婦がいなくなるだけでなく、子どもたちの帰属意識が薄れ、高校・大学を卒業した後戻ってくる動機が弱くなるからです」（p.38）-- このように、過疎に悩む限界集落にとって、発電事業による収入の確保は、地域の生き残りのカギになりうる。

そればかりではない。日本の里山では、農業用水路の維持保守が、死活的に重要だ。しかし近年の農業人口の減少により、一人あたりの維持費用負担が高くなり、ますます離農が増えるというダウンスパイラルが、あちこちに起きている。そこで、農業用水路を活用した小水力発電と、それに伴う現金収入は、農業それ自体を維持する上で重要なのだ。

ここで、農業用水路の『空き断面』を活用した水力発電、という新ビジネスモデルが、にわかに登場する。空き断面とは、水路の余裕となる流量だ。農業用水は田植えなどの時期を除くと、じつはかなり流量を絞っている。10の容量があっても、１の水量しか流れていない状態は珍しくない。そこで、ここに10の水量を流して、９の分は発電に使うのだ（p.57）。発電に使った後の水は、農地ではなく川に戻す。こうした話は、本書を読むまでまったく思いもかけなかったアイデアで、とても面白い。

もう一つ、なるほどと思ったのは、「山村の土建会社は小水力発電で生き残れ」（第3章）だ。近年、地方の小規模な土木業者たちはつぎつぎと廃業している。しかし、山村ではいったん大雨や災害が起きると、土建業者が対応してくれない限り、ライフラインが復旧しない。だから地方の土建会社は必要なのだ。ところで小水力発電所の建設と運営は、土木技術の固まりである。だから公共事業の減った今日、土建会社にとって良い副業になる。

おまけに土建会社の経営者は、当たり前だが経営感覚に優れている。発電所の設置と運営は、やはり経営感覚のある人がいるかどうかが、成功の鍵なのだ。第3章には、富山県の土木経営者だった、故・古栃一夫の獅子奮迅の働き（当時は監督官庁の、言いがかりに近い無理解があり、それと闘った）が、いきいきと描かれている。

というわけで、本書は具体事例をふんだんに盛り込みつつ、地方活性化のために小水力発電事業がいかに有用かを、多面的かつ客観的に書いている。副題に「日本を明るくする広大なフロンティア」とあるが、地方の山村を明るく事こそ、著者（ご本人は都会生まれだと書いているが）の強い願いなのだ。

その信念は、序章と終章によく表れている。序章で著者は書く。「日本の山の木材の価値を死なせてしまったのが、1964年の木材輸入自由化でした。海外から木材を安く輸入できるようになったため輸入材が急増し、日本の林業は壊滅状態になってしまったのです。このことは山村から主要な価値が失われたことを意味していました。（中略） 木材が燃料であり建築材であった20世紀の半ばまでは、ものの価値と言う意味で見れば、山は価値の流れの上流にあったのです。ところが山は、価値の流れの下流、しかも最も末端になってしまったのです。こうして、山村から人がどんどんと里へと移動し、過疎化が進んだわけです。」(p.14)

このような流れを止め、できれば逆転させる力となりたい、というのが著者の望みなのだろう。今日風のグローバリズムの観点に立てば、そんな経済効率の低い辺境地域などうち捨てて、人口は都市に集中させ、そこに資源を集中させる方が効率的だ、という結論しか出てこない。だが、著者の意見は違う。

「町育ちの人ばかりになると、社会が脆くなります」（p.177）

効率性は脆弱性と裏表の関係にある。効率性の高いシステムは、冗長性が乏しく、外部条件の変化に対して脆弱になる、と著者は指摘する（同頁）。このテーゼは、わたしが最近ずっと考えている、システムに固有なトレードオフの問題と同じで、その点でもとても共鳴してしまった。

小水力発電事業は、たぶんわたしの勤務先のビジネス領域には重ならない。多くの読者にとっても、同じだろう。だが、それでも、日本の地域の文化が生き生きと存続することを願うならば、一人でも多くの人にこうした活性化のビジネスがあり得ることを知ってほしいと思う。

スコープ・組織・スケジュール・コストの間の依存関係 〜プロジェクト・インテグレーション・マネジメントのもう一つの顔

うーむ、長いタイトルだな（笑）。そもそも、「プロジェクト・インテグレーション・マネジメント」という用語自体が長い。カタカナで23文字もある。PMBOK Guideの邦訳版のように「プロジェクト統合マネジメント」としても、14文字だ。しかしこれ、”PIM"とかって3文字略語にしても通じないだろうし、致し方ないだろうな。

前回の記事にも書いたが（「プロジェクト・インテグレーション・マネジメントと『鉄の三角形』」https://brevis.exblog.jp/27102305/）、現在のPMBOK Guideには、PMに必要な10のマネジメント知識エリアが列挙されている（初期の頃は9個だった）。そしてその中核となるのが、「プロジェクト・インテグレーション・マネジメント」（ああ長い^^;）である。それは、他の9個の領域のマネジメントを統合する。そして、他の9個の領域には、とくに順序はなく、対等だということになっている・・PMPの試験対策的には。

しかし、もちろんそんな事は嘘である。９つの領域：スコープ・スケジュール・コスト・品質・人的資源・コミュニケーション・リスク・調達・ステークホルダーエンゲージメント、の間には、実務上、明確な軽重があり、そして順序に関する依存関係がある。なぜそういうことをPMBOK Guideがはっきり書かないのか、わたしにはよく分からない。だが、9個のマネジメント領域の間をどう調整していくかこそ、「インテグレーション・マネジメント」の一番大事な機能である。こうしたことを知らないと、プロマネの実務上、明らかに不便だ。だから、ここにそれを記しておこうと思う。

まず、プロジェクトを取り巻く様々な制約条件の内、もっとも広く存在し、そして強くしばられるものは、「スコープ」（役務範囲）と、「予算」と、「納期」の三つである。そこで、これを『鉄の三角形』と呼ぶことは、前回も書いた。言いかえるなら、プロジェクト遂行において、プロマネがつねに意識の上位においておかなければならないのは、スコープ・スケジュール・コストの3つである。そして、だからこそ、PMBOK Guideはごく初期の版の頃から、この3領域が最初の方におかれてきたのだ。

もちろん、プロジェクトにはいろいろな種類があるし、個性や取り巻く状況も様々だ。だから、納期制約のないプロジェクトもあるし、予算を気にしなくてもいいプロジェクトだって（うらやましい限りだが）希には存在する。逆に人的資源（つまり配員）の制約が一番きついとかいうケースだって、あるだろう。ただ、もっとも多くの場合、上記の3つが主要な制約条件なのである。

ちなみに、受注型プロジェクトと違い、自発型プロジェクトの場合は、スコープ制約よりも品質（ないしプロダクトの性能）制約の方が優先される場合も多い。とくに新製品開発などではそうだろう。また、納期制約や予算枠も、受注型より弱い場合がある。でも、通常は「スコープ・コスト・スケジュール」または「品質・コスト・スケジュール」が、プロマネにとって主要な関心事項なのである。

（なお、品質とスコープの間には相補的関係があるのだが、この話をしていると長くなるので、別に書くことにする）

そもそも、上に掲げた９つの要素のうち、プロジェクトの目標や制約になり得るのは、スコープ、コスト、スケジュール、品質の４つである。これらは、仕事のパフォーマンス指標と言っていい。人的資源は制約にはなり得るが、それ自体が目標になることはない。逆に、リスクとは基本的に、目標の反対概念であって、あまり歓迎されざる環境的要素である。そして、それ以外の、コミュニケーション、調達、ステークホルダーエンゲージメントなどは、目的と言うよりは手段に関することである。

ということで、上に掲げた9つの領域は、

(1) 主要な領域：　スコープ、コスト、スケジュール

(2) それに準じる注意領域：　人的資源、品質、リスク

(3) 上記を支える補助的領域：　コミュニケーション、調達、ステークホルダーエンゲージメント

という風に層別することができる。

これらは、互いにいろいろな形で関係し合っている。それを認識し、うまく調整・統合するのがインテグレーション・マネジメントだ、という訳である。主要とか補助的とか分類したが、補助的だからといってコミュニケーションとかステークホルダー・エンゲージメントをおろそかにすると、結局は品質やリスクを経由して、大事なお金と納期にはね返ってくる。

とくに、これらの要素間の関係性を意識しなければならないのは、計画作成段階である。プロジェクト・マネジメント計画書の策定において、間違った順序で進めると、とんでもない計画が生まれてしまう。

プロジェクトの計画立案において、まず真っ先に着手しなければならないのは、スコープ定義である。「スコープ」の制約とは、「役務範囲」のことだと、上で書いた。役務範囲とは契約用語だが、とにかく「やらなければいけない責任範囲」を意味する。言いかえると、プロジェクトを構成する必須の作業（Activity）の集合を指す。

といっても、契約書にリストがあって、「これこれのActivityを全部実行せよ」などという形で、制約が与えられることはない。普通、もっと大まかな形で、受発注者の間の責任範囲が指定されるだけだ。では、どうやって「こんな注文を出されたらスコープ外なので追加です」などと主張できるのか？

じつはスコープは2段構造になっている。まず、成果物のスコープ（プロダクト・スコープ）がある。これは、プロジェクトの成果物がどのような特性を持ったもので、およそどのような構成になっているかを示したものだ。契約書に規定されるのは、主にこちらである。たとえばPCのセットが成果物ならば、CPUとボードと筐体とモニタとキーボード、といったモノのスコープが列挙される。

この成果物スコープを、すべて算出するための作業（Activity）を拾い出す。その結果うまれるのがプロジェクト・スコープだ。つまり、プロジェクト・スコープとは、Activityの集合である。通常それは、階層的に構成され管理番号を付番されたWBS（Work Breakdown Structure）の形で表現される。WBSはスコープの表現形で、ベースラインとも呼ばれる。

そしてこのWBSが、その後の計画作業の主要なベースとなる。

まずは、WBSを構成するそれぞれのActivityを、誰が責任を持って遂行するかを考えなければならない。これは、かつて「WBSはプロジェクト組織を規定する」（https://brevis.exblog.jp/19096066/ 2012-10-24）に書いたとおりである。「誰が」といっても、別に個人の名前まで全て決める必要はない。計画段階では、職種と大まかな人数を考えればいい。それがプロジェクト・チームの組織図と役割となる。

そして、Activityに割り当てた人数と、その仕事に必要な作業量、そして一人あたりの生産性から、各activityの所要期間が推算できる。また、各Activityのアウトプットとインプットを明らかにすると、Activity間の依存関係（Aが終わらなければBが開始できない、など）が分かる。それをもとに、プロジェクト全体の中での、Activityのつながり（ロジック・ネットワーク）を作る。そうすると、クリティカル・パスが計算でき、プロジェクトの全体工期も見えてくる。これがスケジュール計画である。

かくして、動員する人数、各Activityの期間、それに付随する工数と、外部費用などをWBSの構造に従って積み上げることによって、プロジェクトの実行予算計画ができる。全体をまとめると、次のようなステップで、プロジェクト計画は立案されるのである。

まあ、より細かく言うと、コスト計画の後でリスク・アセスメントをやって対策を考え、それによってスケジュールやコスト計画の内容に戻って修正するとか、あるいは品質計画や調達計画も必要な場合が多いとか、いろいろある。だが、大筋で言うと、スコープ・組織・スケジュール・コストの4つの柱をおさえなければ、プロジェクトの計画を作ったとは言えない。

逆に言うと、スケジュール計画が見えないまま、コスト推算や予算計画を立てても、意味が無い。また、プロジェクトの組織や人数が決まらぬ段階で、スケジュールは計画できない。そして、組織はWBSがなかったら決まらない。WBSはスコープ定義がなければ作れない。こういう順序でしか、計画立案はできないのだ。

ところが、現在のPMBOK Guideでは、なぜかこうしたプロジェクト計画立案の流れが、明確に書いていない。かわりに、プロジェクト・インテグレーション・マネジメントの章の説明によると、「プロジェクト・マネジメント計画書は、スコープ・スケジュール・コスト・品質・・等の「補助的マネジメント計画」とベースラインを、インプットにせよ、と書いてある。まるで、各領域の計画を独立に別々に作っておいて、最後にバインダーでまとめれば計画書ができあがる、といわんばかりだ。

もちろん、そんなおかしな事はない。こういう書き方になっているのは、「段階的詳細化」にしたがって、プロジェクト・マネジメント計画書を何度か作り直しブラッシュアップするはずだ、という考え方が背景にあるのだ。そして、コスト見積が、WBSのベースラインをインプットとする、といった依存関係も、確証を細かく見ていくと書いてある。だが、全体としては、9つの領域が平等に、並列に、そしてあまりお互いに関係なく成立するような印象を受ける書き方だ。これは、とてもミス・リーディングな説明ではないかと思う。

ちなみに念のため、2000年に発行された、古い「PMBOK Guide 第2版」を見直してみたら、なんのことはない。Project Integration Managementの章に、ちゃんと計画立案の流れ図が描いてあるではないか。

作業の分割の仕方は、わたしの5ステップと多少違って、より詳細だが、大筋としての流れは似ている。というか、実務的にはこういう順序でやるしかないのだ。そして、こういう図がある方が、全体の関係がずっと分かりやすいと思うのだが。

PMBOK Guideがなぜ、こうした図をやめてしまったのか、正確な理由は知らない。ただ、9つの領域を独立に並列に扱ったのでは、プロジェクト・インテグレーション・マネジメントにならない、ということはもっと強調されるべきだと思う。

そして、このことは、むしろプロジェクトを発注する側の責任者に、ちゃんと理解してほしいと思うのだ。発注者が、あとから思いついたようにいろんな注文を出し、スコープを変更しておいて、しかしコストも品質も納期も「元のままでやってくれ」、と言ってくるケースを、しばしば目にしてきた。だが、そんなことはプロジェクト統合の原理から言って、不可能なのだ。プロジェクトの要素は互いに絡み合い、関係し合っているのであって、一つだけを勝手にかえることはできない。そういう基本的なことを、わたしは多くの発注者に理解しておいてほしいと思う。

わたしは機会があって、ときどきPMの教育研修を手伝うこともあるし、また自分が主査を務める研究部会などで他の業界のPMの方々と話すこともある。そうした中でしばしば痛感するのは、多くの受注側のプロマネの苦労が、発注者側のプロジェクトへの無理解に起因しているという事実である。とくにIT分野で、この傾向は強いのではないか。

発注者はもっと、プロジェクトの性質を理解してほしい。何か変更を要求するにしても、せめてリーズナブルな要望の形でだしてもらいたい・・こう感じているプロマネが、いかに多いことか。これは、とても残念なことである。そして、はっきりいってIT業界の損失でもあると思う。

プロジェクトは、9つもの要素が複雑に関係し合った、一種のシステムである。だから、システムズ・アプローチをもって扱わなければならない。こういう理解を、もっと多くのユーザ企業の情シス部門が知ってほしいと願うのである。

プロジェクト・インテグレーション・マネジメントと「鉄の三角形」

プロジェクト・マネジメントの世界で最も広く普及している標準書PMBOK GuideⓇには、ご存じの通り以下のような、10の知識エリアが規定されている。

・プロジェクト・インテグレーション （Project integration）

・スコープ （Scope）

・スケジュール （Schedule）

・コスト （Cost）

・品質 （Quality）

・人的資源 （Human resource）

・コミュニケーション （Communication）

・リスク （Risk）

・調達 （Procurement）

・ステークホルダー・エンゲージメント （Stakeholder engagement）

各知識エリアは、それぞれが”xx Management"と題されている。つまりQuality ManagementとかCost Managementといったたぐいだ。もっとも上記10個には多少の変遷があり、最初は9個だった。途中からステークホルダー・マネジメントが追加され、さらに最新版ではステークホルダー・エンゲージメント・マネジメントにかわった（ステークホルダーは外部の利害関係者なので、プロマネが直接はマネージできないためだろう）。またスケジュール・マネジメントの用語も、第5版まではタイム・マネジメントだった。

PMBOK Guideには、PMをプロフェッショナルな職域として確立しようとした、先達の叡智がつまっている。中でも一番偉かったのは、最初に「プロジェクト・インテグレーション・マネジメント」なる領域をおいたことだと思う（日本語版では「プロジェクト統合マネジメント」と訳されている）。プロジェクトという複雑な活動の集合を、一種のシステムとしてとらえ、そのIntegrityを保つ必要があるという問題意識から、この概念が生まれたのだろう。ちなみにIntegrityという英語には、全体性、統合性、整合性などのほかに、誠実さ・品位といった意味もあり、非常に高い価値が込められている。

ところで、プロジェクトのインテグレーション・マネジメントというのが何を指しているのか、ここが意外と分かりにくい。

PMOBK Guideはプロセス中心の記述になっていて、Project integrationの中には５つのプロセスが定義されている。(1)Project charterの作成、(2)プロジェクト・マネジメント計画書の作成、(3)プロジェクト作業の指揮・マネジメント、(4)プロジェクト作業の監視・コントロール、(5)統合変更管理、(6)プロジェクトやフェーズの終結、の６つである。

このうち、(1)と(2)は立ち上げフェーズと計画フェーズでの、いわば全体計画立案作業なので、明確だろう。遂行フェーズに入ると、プロジェクトのマネジメントとコントロールを行う。どちらもプロジェクトの全体が対象だ。

ただ、マネジメントとコントロールの二つが、別々のプロセスになっているのは、英語ではmanagementとcontrolがレベルの違う概念として、区別されるからだ（「わたしはなぜ、「プロジェクト管理」という言葉を使わないのか」 https://brevis.exblog.jp/26270824/ 参照のこと）。実際、大規模プロジェクトでは、両者はプロジェクト・マネージャー（PM）とプロジェクト・コントロール・マネージャー（PCM）という風に、職種が分かれて分担する。もちろん、PMはPCMの上位職である。

さて、問題は『統合変更管理』（Integrated change control）である。日本語訳では「管理」となってるが、原語はContorlであることに注意してほしい。これはいったい何をするのか。

PMBOK Guideはプロセス中心、つまり手続き主義の記述になっている。そして「変更要求」だとか「承認済み変更要求」だとかが、インプット/アウトプットに出てくる。

米国流のプロジェクト遂行では、発注者と受注者の間で、変更要求Change Requestと変更指示Change Orderが、やりとりされる。通常は受注者から変更のリクエストが提出され、発注者がそれを審査・承認して正式なオーダーを切る。オーダーには変更作業の詳細と共に、追加費用や納期延長が記載されている。もちろん現実には、提出から承認までの間に、「これは高すぎるだろ」と値切られたり、「これは追加じゃないはずだ」と言われて押し問答したり、といった交渉がはさまるのだが、そういう商慣習のプロトコルを知らないと、ここら辺の記述は分かりにくい。

また、自社内で完結する自発型プロジェクトの場合も、予算権限を持っているプロマネと、社内のステークホルダとの間で、似たようなやりとりが行われる。だからPMBOK Guideでは「承認済み変更要求」という用語になっているのだろう。

ところで、どうしてこれに、あえて『統合』という修飾語がついているのか？　何かの事情で仕様の追加や変更等が必要になり、それで予算が増えるなら予算追加要求、納期が延びるなら納期変更要求、それだけの話ではないか。

ところが、そうではないのである。

プロジェクトを取り巻く制約条件には様々なものがありうるが、通常、その中でも

• Scope（役務範囲）

• Cost（予算）

• Schedule（納期）

はProject の三大制約条件である。まあ、だからこそPMBOK Guideでは最初の方の章に、この3つのエリアがあげられている。

ところで、この三大要素を図にすると、三角形で表される。三角形は、知っての通り、他の2辺に影響を及ぼさずに1辺だけをかえることができない。どれか、ある要素を変更するには、他の要素の変更も必要になるのだ。

たとえば、何か仕様上の追加が必要になったとしよう。その場合、作業（Activity）が増える訳だから、スコープの1辺が長くなる。この場合、

・期限（スケジュール）を延ばして作業を完了

・人員（コスト）を増やして作業を完了

のいずれかが必要になる、という具合だ。

図を見てほしい。三角形の底辺であるスコープを長くすると、どちらかの斜辺を同時に長くせざるを得ない。いや、しばしばあることだが、スケジュールとコストの両方が増大したりする。

似たようなケースとして、遅れつつあるプロジェクトで、納期を間に合わせる工夫が必要だとしよう。その場合、

・人員を追加して（＝コスト追加）、仕事を完了する

・スコープを減らして、期限までの作業量を減らす

のいずれかの方策が必要になる。

あるいは、予算内（コスト）で終わらせる場合ならば、こうなる：

・残業などはせず、プロジェクトの納期を延長する

・スコープを減らして、コストを削減する

プロジェクトには、変更がつきものである。だが、その影響範囲や必要性を考える際には、コストならコストだけ、スケジュールならスケジュールだけでは、判断できない。プロマネは、上述のように、つねにスコープ・コスト・スケジュールの3辺を制約条件として意識しながら、変更をコントロールしなくてはならないのだ。だから、「統合」変更管理 Integrated change control と呼ばれるのである。

英国の初期のPM研究者マーティンは、1970年頃、Scope/Cost/Scheduleからなるこの三辺を、「鉄の三角形」と名付けた。鉄の三角形は、プロマネをとじこめる束縛、あるいは牢獄のようなものだ。プロマネは、とくにプロジェクトの中盤以降、つねにこの三角形の制約条件と戦い続ける。なにか予期せぬ事が起きても、なんとかしてこの三角形の内部で解決すべく努力する。どれか一辺でも破ると、三角形全体の形が変わってしまう。

プロジェクトの成功には、いろいろな定義が可能だが、一番短期的に測りやすいのは、「スコープ・コスト・納期が、当初の予定通り完遂できた」である。外部コンサルタントなども、よくこの指標を用いる。それはつまり、鉄の三角形の内部で完結できたか、を問うている訳だ。

そして、逆に言うと、プロジェクト・マネージャーが首尾良く仕事を完遂するためには、スコープ・コスト・スケジュールのいずれについても、判断し実行する権限を持たなければならない。プロマネは結果に責任を持て、とか、プロマネは結果が全てだ、といった標語をよく耳にする。だが、もしも組織がプロマネにそうした仕事ぶりを期待するなら、それなりの権限を与える必要がある。

「ウチの会社ではプロマネは進捗管理係でしかない」とか、「○○業界のプロマネは、コスト管理の権限がない。発注権は、その上の部課長級が握っている」といった話を、ときどき耳にすることがある。それなりの理由があって、そうした慣習ができあがっているのかも知れない。だが、3辺に対する権限もなしに、3辺の結果責任だけを問われるのは、フェアなマネジメントのやり方ではないと、わたしには思えるのである。

＜関連エントリ＞

「わたしはなぜ、『プロジェクト管理』という言葉を使わないのか」 https://brevis.exblog.jp/26270824/ （2017-12-18）

「プロジェクト＆プログラム・アナリシス研究部会」（3月23日）開催のお知らせ

各位：

「プロジェクト＆プログラム・アナリシス研究部会」の2018年第2回会合を開催いたします。

今回は、グローバルプロジェクトデザイン・ジャパン代表取締役の池大様に、プロジェクトデザインについてご講演いただきます。

企業が新しい製品をつくるにあたって、何の設計図も青写真も持たずに、いきなり実現に向けて走り出すことは稀でしょう。必ず最初にデザインという行為があるはずです。それでは、プロジェクトを開始する場合はどうでしょうか。たしかに今日、多くの組織では、WBS・スケジュール・予算等を含む「プロジェクト計画書」くらいは作ると思います。しかし、「適切なデザイン」という視点で、プロジェクトづくりに向かうケースは、まだ少ないのではないでしょうか。

デザインには、つねにサイエンスとアートの両方の要素があります。プロジェクト・マネジメントの分野でも「デザイン思考」が 注目を集めつつある今日、プロジェクトのデザインはいかなる行為であるべきか。この問題について、東大とMITのコラボレーションによる共同研究と研修プログラムのキーマンとなっている池様から、最新の潮流についてお話を伺います。ぜひご来聴ください。

＜記＞

■日時：2018年3月23日（金）　18：30～20：30

■場所：慶応大学三田キャンパス　北館会議室2（1階）（定員：28）

https://www.keio.ac.jp/ja/maps/mita.html

キャンパスマップ　【1】

■講演タイトル：

「多様化、不確定の時代に対応するプロジェクトデザイン」

■概要：

　現在の社会は、複雑化、多様化、不確定に向かっています。その中でプロジェクトは関係者の多様性を受け入れ、変化に柔軟に対応する必要があります。今回は、東京大学とMITのコンソーシアムであるグローバル・チームワーク・ラボも採用しているプロジェクトデザインと言う考え方についてご紹介します。

■講師：グローバルプロジェクトデザイン・ジャパン　代表取締役　　池大（いけ・だい）

■講師略歴：

　前職はアクセンチュアでシステム運用保守方法論およびツールの日本国内の責任者を務める。25年以上IT業界に従事し、多くのプロジェクトにSEおよびコンサルタント、PMとして参加。

　リスクマネジメント協会会員 Certified Risk Manager

　参考Url：

　http://www.teamport.com/1250312525124721245512463124881253912487124701245212531123921239965311.html

■参加費用：無料。

　ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金（¥1,000）は免除されます。

　参加を希望される方は、確認のため、できましたら当日までに三好副幹事までご連絡ください。

　以上、よろしくお願いいたします。

佐藤知一＠日揮（株）

書評：「ななめの音楽」（Ⅰ・Ⅱ） 川原由美子・著

「ななめの音楽１ (ソノラマコミックス)」 「ななめの音楽Ⅱ (ソノラマコミックス)」（Amazon）

現代マンガの一つの到達点を示す傑作。それが川原由美子の「ななめの音楽」である。

2017年の個人的ベスト3は、「怒りの葡萄」（スタインベック・著）、「ケセン語訳 新約聖書 【マタイによる福音書】」（山浦玄嗣・著）、そして本書「ななめの音楽」だった。本書の実際の発刊は2011年だが、わたしが読み終えたのはたまたま昨年なので、ここであえてとりあげたい。

現代日本のマンガはきわめて豊穣だ。そのバラエティの幅広さ、表現の深さ、作者・読者層の多様さ、どれをとっても第一級の文化的ジャンルと言える。その中で、あえて本作品を「一つの到達点」と呼ぶのはなぜか。それは、この作品が、手塚治虫以降に発明されてきた現代マンガの主要な技法を、あえて捨てたところで表現を作っているからだ。

こうした話は、実物を見ないとうまく伝えられない。そこで、本書のII巻にある1ページをここに掲載することにする。（こういうことをすると著作権者から抗議されるのかも知れないが、その場合は画像を削除し取り下げることにする）

見ていただくと分かるとおり、1ページが正確に4つの同じ大きさの長方形のコマに分割されている。本書は全頁がこのようになっている。つまり、どのページも黒地に4コマで、大小のコマ割りもなく、斜めのコマ分割や枠線の消失もない。手塚治虫が「新宝島」で導入した、映画的でダイナミックなコマ割りを一切、使っていないのだ。

それだけではない。空中を飛んでいる飛行機に、その動きを表すような線が一切、描かれていない。そして爆音も描かれていない。つまり、いわゆる「漫符」がないのである。動きの線、心理状態を表す模様、「シーン」といった沈黙音の表現、その他マンガ特有の一切の補助表現が、ここにはない。まるで江戸浮世絵か西洋絵画を見ているようだ。ただ、本当に目に見えるものしか描かれていない。

そして、会話を表す吹き出しに、吹き出し線がないことにも注目してほしい。このため、このマンガでは誰がしゃべっているセリフなのか、言葉の内容のみから推測するしかない。一コマ目、

　「こゆるさん　ひとつお話ししておきたいことがあります」

　「はい」

この対話から、最初の話者が、「こゆる」（主人公の名前）以外の人物であること、これに対して、こゆるが相づちを打っていること、などがわかる仕組みになっている。吹き出し線抜きで、空の上でのこうした対話を描写することが、実際にはいかに難しいか、想像にかたくない。

このような制約を自らに課すことで、作家・川原由美子が表そうとした世界は、いったい何か。

「美しい機体と少女たちが 蒼い空を翔る　近未来ドラマティック スカイ・ストーリー」

と、帯のアオリ文句にある。戦闘機と、空中戦と、そして戦う美少女たち、というのは、実に現代日本のマンガが大好きな題材だ。しかしここに展開されるのは、きわめてシリアスな心理ドラマだった。

主人公の高校生・伊咲こゆるは、大好きな先輩・光子を追って、北ヨーロッパの空で展開される航空機レースに一緒に参加する。そして光子の祖父（ドイツ系の貴族）に仕える女性ラウラ・シュミート、日本からTV局の中継のために訪れているアイドル歌手の久永まな希らと出会いつつ、奇妙で複雑なバトルレースに巻き込まれていく。その中で、こゆるは、なぜ光子がいつも笑わずにいるのかを次第に知るようになり・・

タイトルの「ななめの音楽」Shrage Musikとは、どういう意味か。「ジャズのことですよ。」と、I巻でラウラは、こゆるに説明する。アメリカからジャズが輸入されたとき、ドイツの音楽家たちは、歪んでズレた音感（と彼らには聞こえたのだろう）を、そうよんで揶揄した、という。ただし、「ななめの音楽」にはもう一つの意味があった。それはII巻をよんでいただくとして、無邪気で美しく見えた世界が、すこしずらすと深刻で悲劇的な意味を持ち始める、というテーマは、本書に繰り返し現れてくる。

本書の扉には、”Based on non existent novel written by Michiaki Sato”というクレジットが書かれている。イラストレーターでメカデザイナーの佐藤道明氏による、刊行されていない小説を原作としているという意味だ。ネットの情報によると、佐藤道明は一時、川原由美子のアシスタントだか助手だかをしていたことがあり、実際、同じタイトルによる作品を’90年代に共作で発表しているらしい。ただ、その時は光子が主人公であったようだ。本書は視点を、こゆるという後輩の少女に移している。つまり佐藤道明のストーリーをベースにしつつ、20年後に川原由美子が一人でリライトしたのが、本作品なのである。

ちなみに川原由美子氏は高校を中退して漫画家になったらしい。1960年生まれだから、ずいぶん長いキャリアである。わたしは本書がはじめて読む作品だったが、初期の本の書影を見ると、じつにまあ、ごく普通の正統的少女マンガである。絵も単純に見える。近年は寡作のようだが、本書のような造形はそうスピード生産できるものでもない。そして絵も信じられないくらい、巧い。本書の次に刊行された「TUKIKAGE カフェ」も読んだが、こちらも美的に見事である。たとえ中卒であっても、職人芸をつきつめて、ここまでの表現レベルに達する作家がいるのだ。それが、現代マンガの豊穣の証左かも知れない。

戦闘機の飛び交う世界でありながら（第II巻の巻末には、ご丁寧に「ラウラさんの翼くらべ」と題する航空機解説ページがおまけについている）、しかし本作品は、伊咲こゆるという主人公の成長の物語であり、まことに正統派の少女マンガになっている。

正統派の少女マンガの主題とは何か？　それは、「自分が女性であることを選択する」物語である。

男女の性別は、生まれついたときから備わっているが、子どもの時はだれもが無性な存在だ。しかし、この世界は基本的に男性中心にできあがっている。その中で、自分自身が女性になることを、女の子たちはある段階で、自分から選び取らなければならない。これが少女マンガの中心にあるテーマなのだというのが、わたしの仮説だ。

だから、こゆると光子との二人の魂の、変転と成長を描くこの物語は、まことにこの作者にふさわしい正統な少女マンガなのである。この伊咲こゆるというキャラの視点がよほど気に入ったのだろうか、作者は後に、こゆるとの共作名義の本も出しているくらいだ。（ちなみに男性中心に出来上がりすぎた社会は、結局、男の子をも不幸にする。だから最後の方で作者は、「つぎの世紀は男性につらい時代になるはず」と、光子のセリフを借りて予言している）

美しく静謐な画面と、劇的な序破急のストーリー。それに加え、魅力的なキャラクター、意外な結末、そして鮮やかな幕切れ・・本書は、じつに多彩なマンガの魅力を持っている。まことに傑作である。

人間主義のプラスとマイナス

「よくこんな非効率で危険な現場運営を、A社は許しているな。」

思わずわたしは、つぶやいた。もう10年近く前、ある中東の大国で、科学技術施設の建設現場を訪れたときのことだ。顧客との打合せが目的で、現場視察のために行ったのではない。だが、どうしても仕事柄、現場のことが目に入ってしまう。建設工事を請け負っているのは、中東エリアで名の知れた大手建設会社2社。巨大な建設現場で、大勢の労働者が投入されていた。

その施設の建設は国の威信をかけたプロジェクトだったのに、例によって納期に遅れつつあった。そこで、国営石油会社であるA社が政府の依頼で、発注側に立ってテコ入れをしているときいていた。A社は国際的に準オイルメジャー級の企業であり、その国で本当に巨大なプロジェクトのマネジメント能力を持つのは、A社くらいしかない。畑違いだが、やむを得ない対策と思われた。

ところで、国際メジャー級の企業は、建設現場におけるHSEの要求も厳しい。HSEとはHealth, Safety & Environmentの略で、つまり労働安全衛生と環境保護の要請だ。以前も書いたことがあるが、メジャーの建設現場では、安全教育を受けずに現場入りしてはいけないし、ヘルメット・防護グラス・安全帯などの装備を身につけることが必須である。ちょっとでも高所作業をする際には、ハーネスをかけて落下予防をする、といった基本動作が事細かく求められる。

ところがその現場は違った。2階以上の高さでも安全帯をかけずに作業をやっているし、地面を掘った穴には十分な安全柵が立てられていない。とにかく及第点以下なのだ。それどころか現場に、図面も持たず材料・工具も持たぬ労働者が大勢うろうろしている。

当たり前だが、直接作業に従事する者は工具や材料がなければ仕事ができないし、監督者（スーパーバイザー）は施工図面を持たなければ仕事にならない。だとするとあの大勢の手ぶらの連中は何のためにいるのか。何の生産性にも貢献していないことになる。いくら突貫工事で大勢を追加動員したといっても、これでは効率が上がらぬ。そればかりか、万が一大きな労働災害事故が発生したら、現場周辺は作業を一切とめて対応せざるをえない。ますます仕事が遅れるのだ。大手顧客がHSEをやかましく言うのも、無事故が作業の生産性に直接つながるからでもある。

ところで同じ時期に、わたしの勤務先は、中東エリアの別の場所で、建設現場における全く新しい取組をおこなっていた。"Incident and Injury Free"の頭文字をとって『IIF活動』とよばれるこの取組は、建設現場の安全性とパフォーマンス向上に画期的な成果を生み出しつつあった。もっとも、これはわたし自身が直接関わった活動ではないし、その詳細について開示する自由を持たないので、具体的には以下のUrlなどを参照いただきたい。

日揮のIIF活動

http://www.jgc.com/jp/06_csr_hsse/pdf/2013/section/03_02iif.pdf

http://www.jgc.com/jp/06_csr_hsse/pdf/2014/section/03_02hse_ks14.pdf

JGCのIIF活動（英語だがより詳しく書いてある）

http://hsse.jgc.com/web/corporate/index.html

その活動のエッセンスだけを紹介すると、以下のようになる（もちろん、これはわたしの勤務先のことなので、宣伝半分じゃないかと疑う読者諸賢もおられよう。その場合は、バイアスを割り引いて読んでほしい）：

IIF活動とは、現場のHSE向上を目的として、安全文化の構築と啓蒙を中心とする活動である。プラントの建設現場というのは、基本的に、誰もが出稼ぎのために故郷を離れて働きにやってくる。そこで、「建設工事に携わる誰もが、無事故で元気で家に帰る」ことが、皆に共通する一番の願いとなる。そのために、「お互いをケアする」（Respect & Care）ような安全文化を、組織(集団) 全体に構築していく。

具体的には、現場で働く作業員の気持ちを掴み、個々のモチベー ションを高めるための活動をする。たとえば現場責任者が、率先して毎朝欠かさず建設現場内を歩き、現場作業員たちに「おはよう。元気ですか」などと声をかけ、握手するなどスキンシップをとり、人間関係の壁を取り除く訳である。

また、互いの出自の紹介をして、名前を持つ人間同士として関係をつくることに取り組む。つまり、お互いに名前を覚えるのだ。大きな建設現場となると、数十の工事業者が関わり、労働者は5千人とか1万人以上になる。そこを、分け隔て無く実践するのである。

あるいは、分かりやすい図面パネルを制作して現場に持って行き、作業員達に、彼らが今、作っている装置の役割の説明をする。プラントは複雑で、見ただけでは何をする装置か分からないし、そもそも建設労働者達にそんな説明をする習慣はなかった。だが、そうした意義の説明を通じて、誇りとやりがいが生まれるし、全員が同じ目標に向かって作業している「仲間」である意識ができてくる。

こうなると、お互いが安全に向けて声をかけ合い、注意し合うカルチャーが醸成されてくる。現場作業には思わぬ危険が潜んでいるし、人間には必ず不注意やミスもある。それを、近くにいる他人（他の会社の人間かも知れない）が、声をかけて防げるようになってくる。

一般に労働安全活動は、「警察取締り型」と、「相互扶助型」のタイプがある。ふつうは、前者だ。危険を見つけたら注意し、繰り返しても改善されなければ、現場退去を命じる。しかし、警察型の活動は、いろいろな事故防止のテクニカルな対策を併用しても、事故発生率の低下に、ある壁があった。IIF活動は相互扶助型によって、その壁をブレークスルーすることを目指している。

結果として、たとえばUAEで遂行したIGD Habshan 5プロジェクトでは1億時間以上にわたり、LTI（Lost Time Incident＝休業災害）ゼロを実現したし、カタールでのBarzanプロジェクト建設現場では、なんと1億 3,000 万時間超の休業無災害を記録した。1億時間といってもピンとこないだろうが、中東の建設現場は1日10時間・週休1日で月260時間勤務が通常なので、つまり約40万人月以上の無災害である。たとえば2万人の労働者が、丸20ヶ月、一人のケガによる休業も出さなかった、という規模がこの数字である。

しかし、生み出した成果はそれだけではない。相互扶助型のIIF活動は、結果として、工事における品質向上と生産性アップの効果を生み出した。それは、皆が自分の仕事の意義を理解し、また周囲と協力しやすくなったことから生まれた結果だろう。

IIF活動は、人を人として遇することの大切さを、わたし達に教えた。目の前の労働者を、無名の、いつでも取り替えのきく存在として見るのではなく、名前もあり家族もある一人の人格＝対等な仲間として遇すること。中東の現場を終えて数年ぶりに帰国した幹部が、「あの活動に取り組んで良かった。この歳になっても、まだ学ぶことがあるんだと分かった」といっていたのが印象的だった。

こうした、異国の途上国の労働者を「対等な人として遇する」点は、日本企業の方が、欧米系よりも自然にできるかも知れない。日本人に差別意識が薄いなどと言うつもりはないが、 社長も平社員も同じ食堂で食べる日本企業の文化（少なくともわたしの勤務先は、社員食堂がある時代はそうだった）に、現れているのではないか。1950年代のアメリカ映画「アパートの鍵、貸します」には、「役員専用のトイレ」の鍵というものが、象徴的に出てくる。役員専用のトイレなどない企業の方が、現場労働者を人として扱う『人間主義』に近いのではないか。

だが、物事にはつねに、両面がある。日本企業の人間主義には、マイナスの面もある。

最近、聞いた話だが、現場改善や経営指導に長い伝統のある某団体が、企業向けに各種研修セミナーを行っている。ところで、その頂点に当たる経営者用コースの内容というのが、たとえば「禅の心」とか「先達の型の伝承」といったテーマであり、人心掌握が中心であるという。そういう話が、企業経営者には人気があるらしい。つまり、経営とは人だ、という認識が広くあると言うことだ。

経営は人なり。なるほど、確かにそうなのだろう。だが、それをもう少し延長すると、どのような認識を生み出すか？

いうまでもない。仕事で良い結果が出たのは、人が優秀だったおかげ、結果が出なかったのは、人がダメだったため、という説明が生まれてくる。仕事のパフォーマンスを決める要因には本来、外部環境もあるし、技術も仕組み（システム）もツールもあるはずだ。組織のルールもまた、制約条件の一種であろう。だが、そうした他の要因は捨象され、すべては、個人の人格だか人徳だかで説明されてしまう。これもまた、ある種の「人間主義」である。

経営は人なり、という認識からは、当然ながら「経営者の使命は、すぐれた人物を見いだして育てること」という方針が出てくる。そこには、組織を安定して進めていく仕事の『仕組み』（システム）をつくること、という課題意識が抜けている。

また、その経営セミナーの話は、かつて書評した、日経文庫の「はじめてのプロジェクトマネジメント」（近藤哲生・著）をも想起させる。本を読んで驚いたのだが、そこにはWBSもなければクリティカル・パスの説明もなく、EVMSも見積手法論もない。いわゆる近代的PMの技術論は一切無くて、いきなりプロマネの心構え論になってしまう。そしてひたすら説明されるのは、部下のモチベーションと掌握と問題解決への心構え、といった話だった。でも何より驚いたのは、その著者が日立の情報通信部門のベテランだったという事実だ。うーむ。そういう人間主義の会社だったんだ、と感心(?)した記憶がある。

上記の経営セミナーの話をわたしにしてくれた人によると、英国と日本では、歴史教育に大きな差があるらしい。英国の歴史教育では、たとえば「産業革命」という事象を取り上げて、何がそれを可能とする条件なのか、なぜイギリスは世界に先駆けて産業革命を経験することになったのか、それによって及ぼした社会への影響は何か、といった構造的な説明がなされる。そして、その説明にはあまり固有名詞が出てこないのだそうだ。

ところが、日本の歴史のテスト問題というのは、年号と人名の暗記問題である。ジェームズ・ワットが蒸気機関を発明、ついでスティーブンソンが蒸気機関車を開発、といった事は覚える。だが、産業革命一般とはどのような事象であるのか、どの国・どの社会で早く発生し、遅れたのはどのような地域だったか、といった、大きな歴史構造はよく分からぬままの場合が多い。大きな社会変化が起きるにはそれなりの条件が必要だ。だが、まるでワットとスティーブンソンという有能な個人たちの出現が、それを可能にしたかのような歴史像しか頭に残らない。それは明治維新などをめぐっても似たような認識になる。西郷隆盛やら勝海舟やらの大人物が織りなす、点と線としての物語。

人と人とのドラマが、世界を動かしている。経営とは人である。仕事の成果を左右するのは、個人の能力である・・このような人間主義の世界観で、何がまずいか。それは、仕事の能力の「移転ができない」ことである。

知識・技術というものは、基本的に移転可能だ。文字にして伝えることができるし、ツールを作って渡すこともできる。だが、個人に内面化された技能を他者が継承するには、長い時間をかけるしかない。そのために、徒弟制度風のOJTを重視する組織は多い。それでも、昭和世代と平成世代の間のギャップ問題は、どこでも悩みの種となっている。

また、移転に時間がかかるということは、異なる製品やプロジェクトの間での、教訓（L&L）の学びが効きにくいことを意味する。もちろん、海外工場をつくっても、すぐに仕事を移転できない。つまり、組織としてスケーラビリティがないということだ。

そして、現代の世界市場規模での競争において、スケーラビリティがないことは、企業にとってほとんど致命的である。少なくともわたしの見る限り、欧米系ではどうやって仕事をシステム化し、展開可能とするかに、かなり注力している。だが、こうした危機意識が、わたし達の社会には非常に希薄だ。個人の能力（技能）を、科学の力を借りて客観化し、それを技術として移転する、という基本的な発想が、エンジニア達にも欠けているとしか思えない。そうした例は、ゲーム開発の分野からスポーツまで、あちこちに転がっているというのに。

労働者一人ひとりを、人間として遇すること。そのことが、仕事へのオーナー意識を生み、「やらされ感」で働かされるよりは、ずっと高いパフォーマンスを示す。これが人間主義のポジティブな面だ。だが、それをずっと延長していくと、「経営は人だ」「すべては人間の技能と気持ち次第だ」という認識が出てくる。かくして、技術やシステムの軽視、スケーラビリティの喪失が起きる。これが人間主義のネガティブな面だ。しまいには、竹槍でB29戦闘機と戦おうとする、奇妙な精神主義にまで至るかもしれない。

わたしは二つの違うものを、無理やり一つに並べているのだろうか？　もし、どこかに断絶点があるなら、教えてほしい。だが、もしそうでないなら、わたし達の社会の人間主義には、両面があることを、意識すべきなのだ。