Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

リーンソフトウェア開発 | デミングの14項目

概要

デミングの14項目:Deming's 14 Points

14項目(和)

No Points
1 競争力を保ち・雇用を生み出すために製品とサービスの改良を恒常化する
2 新しい考え方を取り入れること。我々は新たな経済時代にいる。
挑戦に目覚め、責任を学び、革新へのリーダーシップを取らなければならない。
3 全品検査への依存を止める。
はじめから製品の品質を作りこむことに寄って大規模な検査の必要性を排除する。
4 単に価格の低い業者の選定を行うのを止める。代わりに総費用を最小化する。
最終的には信頼の出来る単一サプライヤーを選ぶ。
5 品質と生産性を向上させ、コストを減らすために商品とサービスを永久に改善し続ける
6 OJTを導入する
7 リーダーシップの制度。管理の狙いは人・機械等がよりよい仕事をするのをサポートすることである。
管理者は労働者がよりよく働けるように徹底的に作業を見直す必要がある。
8 恐怖を持たせないようにすれば、各自は会社のために効果的に働く。
9 部署間の壁を壊す。各部署のメンバーは製品や製品・サービスの利用に関する問題点を見越すために、チームとして働くべきである
10 生産性を上げたり、欠陥をゼロにするためのスローガン、勧告、目標を排除する。
低い品質と生産性の大部分の原因は各労働者ではな労働システム自体によるものであるため、このような勧告は敵対的関係を作り出してしまう
11 労働者に対するノルマや数値目標を排除する。代わりにリーダーシップによるマネジメントを行う
12 時給労働者の権利、誇りを奪う制度を廃止する。管理者の責任は厳しい数値目標よりも品質に変えるべきである。
管理者や技術者の人々の製品への誇りを奪う障壁を排除する。
特に査定や人事考査や目標による管理を排除する
13 積極的な教育、自己啓発のプログラムを制度化する
14 全員が改善を成し遂げるために会社で働くようにする。改善は全員の仕事である。

14項目(英)

No Points
1 Create constancy of purpose toward improvement of product and service,
with the aim to become competitive, stay in business and to provide jobs.
2 Adopt the new philosophy.
We are in a new economic age.
Western management must awaken to the challenge, must learn their responsibilities,
and take on leadership for change.
3 Cease dependence on inspection to achieve quality.
Eliminate the need for massive inspection by building quality into the product in the first place.
4 End the practice of awarding business on the basis of a price tag.
Instead, minimize total cost.
Move towards a single supplier for any one item,
on a long-term relationship of loyalty and trust.
5 Improve constantly and forever the system of production and service,
to improve quality and productivity, and thus constantly decrease costs.
6 Institute training on the job.
7 Institute leadership.
The aim of supervision should be to help people and machines and gadgets do a better job.
Supervision of management is in need of overhaul,
as well as supervision of production workers.
8 Drive out fear, so that everyone may work effectively for the company.
9 Break down barriers between departments.
People in research, design, sales, and production must work as a team,
in order to foresee problems of production
and usage that may be encountered with the product or service.
10 Eliminate slogans, exhortations,
and targets for the work force asking for zero defects and new levels of productivity.
Such exhortations only create adversarial relationships,
as the bulk of the causes of low quality and low productivity belong to the system
and thus lie beyond the power of the work force.
11 a. Eliminate work standards (quotas) on the factory floor. Substitute with leadership.
b. Eliminate management by objective. Eliminate management by numbers and numerical goals. Instead substitute with leadership.
12 a. Remove barriers that rob the hourly worker of his right to pride of workmanship.
The responsibility of supervisors must be changed from sheer numbers to quality.
b. Remove barriers that rob people in management and in engineering of their right to pride of workmanship.
This means, inter alia, abolishment of the annual or merit rating and of management by objectives.
13 Institute a vigorous program of education and self-improvement.
14 Put everybody in the company to work to accomplish the transformation.
The transformation is everybody's job.

個人的な雑感

No Points
1 常時改善。開発においては開発手法、作業フロー、自動化、設計等々
2 枯れた技術や試行に固執しない。常に最新技術へのアンテナを貼り、自信も新たな考えを発見出来るように常に考える。
3 ウォーターフォルで一括製造、ビッグバンテストにビッグバン結合で破綻が悪例か。対局にあるのは自動テスト・テスト駆動・CI。
4 品質を軽視しない。技術力を伴わない下請けやオフショアの乱用を避け、長期的なコストを下げる「プロの技術者」を雇うべき、といったところか?
5 1と類似
6 OJTを行うということはマネージャーも技術を理解している必要がある。典型的なSI'erだと欠けていることが多い視点。
(そもそも下請けを育成したりしないですし、ヘタすると社内に開発者が全く居なかったり。)
安い下請けを大量に雇い、開発を知らない管理者が指示を出し、下請けを育成することもなく開発が終了すると開発者は契約終了となり社内に全くノウハウが残らない。
逆に強い開発会社は開発者の育成を重視し、開発者全体の社員比率を上げ、下請けも分け隔てなく教育し、
協力会社が継続して働いてもらえるような環境を提供するのではないだろうか。
7 監視や、マイクロマネジメント、単純な「作業」の割り振りによる管理が悪例か。
良例はアジャイル等の各自が自律的に行動できるチームを作り、そのサポートをするスクラムマスターのようなイメージか。
8 これは現場で自他共に実体験。
自分がされた時はパフォーマンスを発揮できなかったし、
第三者として恐怖を受け続けている担当者を見たが恐怖によるマネジメントで能力を発揮している開発者を見たことがない。
チーム全体の雰囲気も悪くなるし、問題の隠蔽率も増えるのでいいことなし
9 これは出来ると良いとよく聞くけど現実では結構難しいですね。
結局予算が別腹になっていることもあり、他部署の人を巻き込もうとして後で怒られた経験等のほうが多い。
自分はあまり強く言えない性格なのですが、「会社・お客様の利益と部署の利益どっちが大事なんですか?」とか言えばよかったのだろうか?
ナレッジ管理系のソフトなども導入しているが、結局チーム内程度しか知識を共有できていないことが多い
10 数値や目標による管理は組織の部分最適化や、個別担当者ではどうにもならないシステム全体の不具合に左右されやすいのでよくない、ということか。
11 10と類似
12 この辺りはSI'erと下請けによく見られそうな話。
また技術力不足の管理者には品質を判断しきれない部分もあるため、この辺もSI'erにありがち。
ある管理者がオフショアが優秀、と言っていたので成果物を見たことがあるのだが仕様を満たしているものの、保守困難なひどいソースコードだった。
13 組織内の技術者のレベル、モチベーション次第で効果が分かれそう。
採用時に自律的に学習するタイプを採用できればこのあたりのコストは最小化しそうに思える。
14 ここも意識レベル次第。常にこの意識がある開発者はほっといても改善するし、そういう意識のない開発者は言ってもやらない。
そういう意味ではまた採用時点の話になるのか。
これから育つ新人・若手に関しては育成の価値あり。