【レポート】コストダウンの方向性に対する検討事例

自己評価：具体的でありレポートにふさわしいテーマな筈

（１） 組織には必ずボトルネックが存在する

ボトルネックが生じるのは、設計や生産の現場に限らない。

企業全体の経営改革などでもボトルネックが障害となる事態は起こり得る。

なぜなら、組織の活動には何らかの「つながり」があり、そこには「ばらつき」が生じるからである。

（ａ） あなたの仕事は、ほかの人や組織と、つながって行われていますか？

（ｂ） それぞれの人や組織の能力は、同じですか？、ばらついていますか？

この２つの質問について答えようとすれば、組織の中のほとんどの活動に「つながり」があり、「ばらつき」があることが分かる。

そして、ばらつきがあるということは、全体のつながりの中にどこかにボトルネックが存在するということを意味する。

ボトルネックが見つかれば、改革のアプローチは全く変わってくる。

ボトルネックの解消に集中すればいいからである。

一箇所に取り組む方が、結果は早く出るはずだし、設計者にとっても楽だろうと考えられる。

また、費用もたいしてかからない。

よく、あらゆる現場で業務改革活動に取り組むことが、全体のパフォーマンスを上げると思われがちである。

しかし、こうした考えは、実は思い込みにすぎず、実際には、つながりとばらつきのある現実の組織では、ボトルネックに集中して取り組むことが全体のパフォーマンスを上げることになる。

この様な発想の転換ができれば、会社全体の生産能力の向上を実現できると考えられる。

関係部署を挙げて業務改革活動に取り組めば、会社全体のパフォーマンスが上がると思い込み、真に効率的な設計作業を実現できていないのは、日本の大半の会社に共通することである。

ここで、組織全体をシステムと見なすと、広辞苑によればシステムとは、複数の要素が有機的に関係しあい、全体としてまとまった機能を発揮している要素の集合体・組織・系統・仕組みである。

つまり、システムとしての会社組織は一枚岩ではなく、複数要素の集合体というわけである。

当たり前のようだが重要な点である。

だからこそ、業務システム等の開発を行う上では、つながりを意識しつつ、ボトルネックに集中することで全体最適を目指す必要がある。

ボトルネックという言葉には、ネガティブなイメージがあるが、全体から見れば、本来は徹底活用すべき貴重なモノと認識する必要があり、このため、より広く誤解のない「Constraint（制約）」という言葉で表現することができる。

（２） 制約以外の部分の業務改善は無駄

制約だけに集中して取り組むことが全体としての成果を生む。

裏を返せば制約以外の改善活動は、すべて時間と労力、経費の無駄と言える。

「つながり」と「ばらつき」を意識せず、設計者それぞれがばらばらに業務改善を行っていくと、結果として部分最適に陥ることになってしまい、努力の多くは無駄になってしまう。

例えば、全体の制約を「見える化」するだけで、人は自然に助け合うようになる。

そこに集中しさえすれば、全体が良くなることが分かるからだ。

いがみ合う険悪な状態になっていた縦割りの組織でも、あつれきはウソのように消え、全体最適の和が広がると考えられる。

組織の機能を個別にバラバラに分けて考えるのではなく、組織内の「つながり」と「ばらつき」を重視して全体として考える。

このように発想の前提を変えて、全体に影響を及ぼしている制約にみんなの力を集中することで、全体最適を実現可能なシステムを構築することがポイントとなる。

よって、前提が間違っていると多くの努力が無駄になることから、いくら努力しても結果が出ない時に、前提に思い込みがないかどうかをチェックしてみる必要がある。

すると、そこから活路が開ける。

例えば、スケジュールは、不確実で予測できないことを前提とし、常に変動するスケジュールに合わせて作業量を変化させることがキーポイントとなる。

（３） 作業の流れの改善がオペレーションの主要な目的

作業の流れを考えると、待っている時間が格段に長いのが実態である。

その待っている時間の短縮に努めることが流れをスムーズにして、完成するまでの時間を短くするということになる。

ロジカルな作業で早めにスペックや本体条件を達成し、残った時間で品質改善や低コスト化を進められれば、現場にとって長年の課題だった「平準化」の実現と、リードタイムの短縮を同時に満足させることが可能となる。

流れるモノ（条件）が増えてくると、それらに優先順位をつけて管理することは難しくなる。

加えて、関連部署間の必要情報は、常に変動するので、リードタイムが長ければ長いほど、その間に優先順位も変わりやすくなる。

優先順位が変わると、作業手順の組み替えも多くなることから、待っている時間もどんどん増えていき、必然的にリードタイムが長くなっていくというわけである。

ここでの気づきは、こと設計に関して言えば、長くなっているのは、待っている時間だけで、設計時間は変わっていないということである。

そして、待っている時間は、アウトプットが遅すぎる上流設計側によってもたらされているということなる。

裏を返せば、いつ設計を始めるかということよりも、設計を始めてはならないタイミングを示すガイドラインがないと、関連部署間の設計の流れが悪くなり、リードタイムは長くなってしまうということになる。

極論すれば、情報がある時には設計し、情報がない時には設計しないという管理が重要なことなのだと言える。

そのため、部分最適を排除して全体最適を実現する必要があり、設計をシステムにより一括管理させる設計手法を構築するために、システムにつながりとばらつきがあることを前提とし、ばらつきがあることで生じるボトルネック、すなわち制約に集中して取り組むこと。

言い換えると、制約を徹底活用することによって、システム全体の流れをスムーズにすることが重要である。

つまり、システムの流れ（設計）に制約があるならば、制約の前には、設計情報の滞留があり、また、制約の後では、設計情報の流れが遅くなっているはずである。

制約の前後は、流れのバランスが悪い状態となっていて、流れは常に改善していかなければならないことから、この点に着目して、設計業務の整流化を図っていく必要がある。

（４） 不確実性が進捗管理を難しくする

製造業に限らず、どの業種にも何らかの形のプロジェクトが存在する。

業種によっては、仕事そのものがプロジェクトというものもある。

例えば、情報システムや建設業、プラントエンジニアリングなどである。

プロジェクトは、１つひとつが異なっていて、全く同じということがない。

長年携わってきたベテランの技術者にとっても、1 つひとつの設計で初めて経験することがたくさんある。

このように予想していないことに次々と遭遇する不確実性がプロジェクトにはついて回る。

そのためにもともと遅れが生じやすいのだとも考えられる。

さらにプロジェクトには、さまざまな人がかかわる。

新設計であれば、開発の担当部署だけでなく、社内の複数の部門などが関係してくる。

これらの関係者の間での調整に手間取ることも、作業の遅れにつながる。

こう見てくると、プロジェクトを期限に遅れることなく終了させることの困難さが分かる。

こうした場合、まずはプロジェクトの個々の作業に問題がないかどうか、中身を詳細に点検するのが普通だが、個々の作業にある余裕を１つにまとめてみる方法も考えられる。

どういうことかと言えば、個々の作業には、予期せぬ事態に直面して遅れが生じることを見込んで余裕が織り込まれている筈であり、期限の厳守が強く求められているプロジェクトほど、その余裕は大きくなりがちになるからである。

例え話で説明すると、家から空港に車で人を迎えにいくとする。

相手が友人であれば、飛行機が到着する直前かその少し前に空港に着くように家を出るだろう。

では相手が取引先の社長だったらどうか。

渋滞などを心配して、かなりの「余裕」をもって早めに家を出るはずだ。

このように遅れてはいけないという責任感が強ければ強いほど、しっかりと余裕を見込んでおくのが人間の特性なのである。

結果として重要なプロジェクトほど、個々の作業に必要な日数の見積もりは長めになり、全体として見れば余裕が過剰になっている場合が少なくない。

つまり、当初のスケジュールには、必ず過剰な余裕があることになる。

実際、不測の事態に直面することなく個々の作業に専念できたら、どれだけの日数で終えることができるか。

いわば、純粋にその作業に必要な日数を改めて算出してもらうと、必ず当初の日数よりも短くなるものである。

短縮された分の日数が余裕に相当する。

こうして個々の作業で浮かび上がった余裕を集約して、プロジェクトのスケジュールを組み直し、個々の作業には純粋に必要な日数を割り当て、集約した余裕を最後に置く形の作業スケジュールに見直すことで、設計者にゆとりが生まれることになる。

この集約した余裕を個々の作業に織り込まれていた余裕と区別して、ゆとりと呼んでもよい。

ゆとりはもともと過剰になっているから、それを短縮して全体のスケジュールを短くできるはずである。

個々の作業が純粋な必要な日数で終えるか、それとも、終えることができずにゆとりを減らすことになるか、その確率は単純に考えれば、５０％ずつだから、ゆとりを当初の半分まで短縮することも可能となるのである。

ただし、実際にゆとりをどこまで短縮するかは、関係者の合意を得たうえで決めた方が良い。

そうすることで、全体のゆとりを関係者の全員が共通して認識するようにもなるからである。

ここで不思議に感じられる事柄が存在する。

スケジュールに当初から過剰なほど多くの余裕が織り込まれているなら、それでなぜ遅れが生じて期限を守れなくなるのかと。

まず先述のように、プロジェクトには不確実性がついて回る。

不測の事態に次々と直面し、余裕はどんどん失われてしまう。

実際、プロジェクトの現場では煩雑な仕事を抱え、1 つの仕事に専念できることはそう多くはない。

急に別の仕事を頼まれて、その対応に忙殺されたりする。

もとから複数の仕事を同時に進めるマルチタスク状態になっていて、そのために個々の仕事の効率が下がり、手直しも増えて順調に進まないことも少なくない。

さらに、責任感から余裕を大きく持とうとするのとは異なる、別の人間の行動特性が作用することもある。

大きな余裕に安心して、作業に真剣に取り組むのが遅れがちになり、所定の日数のぎりぎりまで作業の終了を引きつけてしまうことも多い。

これを海外では、学生症候群と呼んでおり、日本では一夜漬けと言われるものであるが、仕事においても同様の現象が見受けられ、必要な時に、必要な情報が届かないといった負の連鎖の先頭における現象のひとつだと考えられる。

つまり、個々の作業に余裕があると、作業の担当者たちは自分の作業の期限を守ればいいという部分最適に陥りがちになる。

すると個々の作業の余裕を担当者が使い切ってしまい、不確実性に対応するための全体の「ゆとり」がなくなる。

それが、プロジェクトの遅延につながるというわけである。

個々の作業から余裕を取り出して、ゆとりとして集約することには、このような安心感から生じる遅延を防ぐ狙いがある。

（５） 全体のゆとりの増減で進捗を管理する

個々の作業が純粋に必要な日数で終わらなければ、ゆとりは減っていくことになる。

逆に個々の作業が早く終われば、ゆとりは増える。

システムの開発においては、個々の作業の進捗ではなく、この全体のゆとりの増減をチェックすることで、プロジェクトをマネジメントしていく手法であるバッファー・マネジメント（Buffer Management）も効果的である、

（６） 作業の進め方ではなくマネジメントのあり方を変える

前述の全体のゆとりの増減で進捗を管理する場合においても、個々の作業の進め方は大きく変わらない。

変わるのは主にマネジメントである。

「ゆとり」をバッファー・マネジメントでチェックして、十分なゆとりを持つために関係者の全員が常に協力して対策を早めに打っていくことが重要となる。

このように個々の作業の進捗管理が中心だったマネジメントから、プロジェクト全体の進捗を常に考える全体最適のマネジメントへと切り替えることで、プロジェクトのマネジメントを改革する手法の採用がポイントとなる。

従来からこのようなプロジェクトマネジメントを、ベテランの設計者は、自分の頭の中では行っていたとのではないかと推察される。

個々の作業の日数を必要最小限にまで短縮して、プロジェクトの最後にゆとりを持つ。

そして、常に先手で対策を打っていく。

この考え方は決して新しいものはなく、ベテランのプロジェクトマネジャーならば、多少なりともそうした考えは持っていると思われる。

プロジェクトメンバーにも、その考え方を事あるごとに伝えていたとも思われる。

ここで、従来から知っていて、メンバーにも教え続けてきたのに、なぜ十分に実践されていなかったのかという疑問が生じる。

その理由は、次の２つの質問に答えることで明らかになる。

（ａ） 「知ること」と「やれること」、どちらが難しいですか？

（ｂ） 「やれること」と「やれるように教えること」、どちらが難しいですか？

何かを知ることができても、それをやれるようになるのは難しい。

さらに、自分がやれることでも、ほかの人もやれるように教えることも難しい。

従って、優秀なプロジェクトマネジャーが頭の中だけで行って暗黙知のままになっているプロジェクトマネジメント。

これを誰でも実践できるように形式知化することで多くの人が活用できるようになる。

（７） 二者択一のジレンマ

製造業に限らず、日本の幅広い産業に共通する課題として、利害の対立を直面してそれを解消できず、物事が前進しないという二者択一のジレンマがある。

異なる立場の利害が一致しないことから生じる対立は、どの産業に勤める人も日常の業務の中で直面している問題であると考えられる。

まずは、問題にどのような対立があるのかを明らかにする。

システムの開発に当たって開発者は、担当者から、現場の要求を取り入れたシステムを作ることを求められる一方で、管理者からは、標準化したシステムを作るというミッションを与えられており、それらを両立できずにシステム開発を進められないという状況に陥っていた。

それは、設計者の要求を取り入れたシステムを作る、標準化したシステムを作る、という２つのシステムの作り方、すなわち、２つの手段が対立する関係にあるからである。

この手段の段階にいくら注目しても、対立は解消できず、問題は解決しない。

そこで、２つの手段をそれぞれ開発者に求めている担当者と管理者に目を転じてみる。

管理者も担当者も、同じ組織に属している。

だから、必ず何らかの目的を共有しているはずである。

両者に共通する目的は何かを考える。

すると、システムについては、業務効率を上げるシステムを作るという点では、管理者も担当者も、思いは同じであることに気づく。

次に、そうした共通の目的があるのに、なぜ手段のレベルでは対立してしまうのかを考察する。

お互いに対立する手段は、共通の目的を達成することを目指しながらも内容の異なる２つの要望を満たすためにそれぞれ主張されている。

だから、手段のレベルでは完全に対立してしまっている。

こう考えて、それぞれの手段が充足しようとしている要望を明らかにしていく。

開発部門は、もともと標準化したシステムを作るという手段によって、業務の進め方を標準化するという管理者の要望を満たそうとしていた。

その一方で、現場の要求を取り入れたシステムを作るという手段は、現場で運用しやすいシステムを作るという担当者の現場の要望に応えようとしていたことが明らかになる。

ここで、仕事の進め方を標準化するという要望も、現場で運用しやすいシステムを作るという要望も、業務効率を上げるシステムを作るという共通目的の実現につながるものであることも分かる。

ここで改めて、問題の構造を俯瞰すると、現場の要求を取り入れたシステムを作ると標準化したシステムを作るという手段のレベルでは対立しているが、仕事の進め方を標準化すると現場で運用しやすいシステムを作るという要望のレベルでは必ずしも対立しているわけではない。

それどころか、共通目的の実現につながるのだから、むしろ両立できるものであることに気づく。

２つの異なる要望を両立できれば、手段にはこだわらなくてもいいと考える。

こう考えると、対立する２つの手段とは別の手段で２つの要望を充足する方策を考案することが可能になる。

その方策を考え抜いた末に浮かび上がったのが、ひとつの組織で効率の良い業務の進め方を作り上げ、それに則ったシステムを同時に構築していくという案である。

これが実現すれば、現場で運用しやすいシステムを作る、業務の進め方を標準化するという異なる２つの要望を両立できることは、もう言うまでもないだろう。

さらに、内容が異なる２つの要望を両立する方策を考えるようになって、部分最適から初めて脱却し、全体最適を追求できるようになる。

ここでいま一度、システムの開発で躓いた原因について考えてみると、原因は現場の声に耳を傾けすぎたことにある。

システムを開発する際に、現場にヒアリングするのは基本である。

現場の業務の進め方について知らなければ、それをうまくサポートするシステムは作れないからである。

現場の声を広く集めた開発者は自らの業務に対して誠実に取り組んだと言える。

しかし、そこに落とし穴があることになる。

現場のことは現場が一番良く知っているから、現場にくまなくヒアリングすることで、システム開発の仕様がうまくまとまることもあるだろう。

しかし、実際には、現場から寄せられる要求は玉石混交であることが多い。

しかも現場は一般的に自分の業務の効率を改善することだけを考えている。

そのため、現場の要求は部分最適になりがちだ。

そうした要求に沿ってシステムを開発すると、かえって部分最適のオペレーションを社内のあちこちに定着させてしまうことになりやすい。

こうした状況も考慮して、現場の声を広く集めることをやめ、特定の現場と一緒に全体最適につながるベストプラクティスを作り上げるという手法を採用した方が全体最適化につながる。

こう考えると、例えば、ボトルネック（制約）の1 つは、「良いシステムを開発するには、現場の声を広く聞かなければならない」という思い込みにあるのが分かる。

「Bottle neck is always top of the bottle（ボトルネックはボトルの上にある）」。

ここでボトルの形を想像してみると、ボトルネックは必ず上の方にある。

これを人の姿になぞらえると、ボトルネックは、人の頭の中、すなわち、考え方にあることになる。

実際、この制約は、「現場の声を広く聞く」から「現場の声を広く聞かず、業務の進め方の改善に一緒に取り組む工場を絞り込み、ベストプラクティスを作り上げて、それを水平展開する」という形に考え方を転換することで解決する。

現場の要求を取り入れたシステムを作る、標準化したシステムを作るという対立する手段に着目してどうするかを考えることをやめる。

そして、共通の目的を考えて、内容は異なるが両立可能な２つの要望を導き出し、それらを両立させる方策を探り出すという考え方に転換する。

ここに二者択一のジレンマを解決するカギがある。

つまり、改めて強く感じるのは、対立があるという状況は、ブレークスルーを生むチャンスであるということである。