リーン開発_第6章_人

マネージメントシステム

「人を尊重する」という原則以外のすべてのリーン原則を実践しても、 リーンがもたらしうる利益のうち、ほんのわずかしか得られない。
逆に「人を尊重する」という１原則だけを実践すれば、人が残りのリーン原則を発見し、実践してくれる。

■ボーイング７７７の話

スケジュールの遅延の根本的原因を分析した結果、ひとつの結論に至った。 遅れが出たのは、人々が一緒に作業をしていなかったため、そして、問題を早期に発見しようとせず、問題が発生しても気に留めなかったため。 また、コミュニケーションが迅速かつ効果的に行われてなかった。

早期にテストをして、速く失敗する。

W・エドワーズ・テミング

テミングは４つの要点からなる「深遠な知識のシステム」を信奉していた。

1.システムの正しい理解

• どのようなシステムであれ、部分間の相乗効果がシステム全体の成功の鍵となると教えた。
• 製造をシステムと捉えていた為、その部分間の関係、つまり、企業内の部署間の関係や、サプライヤ、製造者、顧客の間の関係を管理する事が重要
• システム全体を見ることが基本であり、システムのどの部分であれ、部分最適化は全体の最高の利益にはつながらない。

2.変動についての知識

• 作業者がシステムに内在する問題のせいで、責められるのは言語道断。
• 一般的原因による変動、つまりシステムに内在する変動。
• この変動をシステムから排除しようとするのはムダで、状況を悪化させかねない。
• 低品質や低生産性の原因の大半は、そのシステムに内在するものであり、個々の作業者にはどうしようもないこと。
• 締切やスローガンは、システム上の問題の解決にまったく役に立たない。システムの動きを変える際のリーダシップが必要。

3.知識の理論

• 仮説を立て、実験し、学習し、学習を組み入れるという科学的手法のステップによって、計画・実施・監視、改善(PDCA)という有名なテミング・サイクルを生み出した。

4.心理学

• スキルや誇り、専門知識、自信、そして協力による影響が大きい。

品質に関する多次元的な観点をマネージメントの14項目としてまとめた。

<テミングの14項目>

• １．長期にわたって、必要とされる企業となる。
  端的な採算性に目を奪われてはならない。
  目標はビジネスで生き残り、雇用を生み出すことである。

• ２．世界は変わった、マネージャーも新しい考え方を取り入れなくてはならない。
  遅れやミス、欠陥品、質の悪いサービスは、もはや受け入れられない。

• ３．欠陥を発見するための検査に頼るのをやめ、製品を作る過程で、品質を作り込むようにする。
  統計的プロセス制御を採用する。

• ４．サプライヤは、入札額だけで選んではならない。
  誠実さと信頼に基づいた、長期的な関係をサプライヤとの間に確立し、それによって総費用を最少に抑えるべきである。

• ５．生産やサービスの提供のシステム改善するため、絶えず努力を続ける。
  改善は、一度で終わらせる作業ではない。
  システムの各活動は、ムダの削減と品質向上のため、絶えず改善されなくてはならない。

• ６．訓練を制度化する。
  マネージャーは、自分が監督している作業のやり方を知っていなくてはならず、また、作業者の訓練も出来なくてはならない。
  マネージャーもまた、生産のシステムを理解するため、訓練を受ける必要がある。

• ７．リーダシップを育てる。
  マネージャーの仕事は、人々がよりうまく仕事を出来るように手助けし、システム内において、彼らが誇りを持って仕事をするうえでじゃまになるものを取り除くことである。
  アメリカの最大のムダは、人の能力を活用できない点である。

• ８．恐怖感をもたせない。
  うまく仕事をするためには、身の安全を感じていなくてはならない。
  会社にとって最善のことと、今の作業に期待されていることが矛盾してはならない。

• ９．部署間の垣根を壊す。
  全員がお互いの考え方を理解できるように、部署の枠を超えたチームを作る。
  個人の成績を評価して、チームの協力関係の土台を崩してはならない。

• １０．スローガンや説教、到達目標の使用をやめる。
  欠陥や生産性を生み出すのは、人ではなくシステムなのだ。
  説教をしてもシステムが変わるわけではない。
  システムを変えるのはマネージメント側の責任である。

• １１．作業者への数量的ノルマや、管理者層の数量的目標をなくす（開発チームへの身勝手な締切をなくす）これは、恐怖によるマネージメントである。
  代わりにリーダシップによるマネージメントを試してみると良い。

• １２．技術者の誇りを奪う制度をなくす。
  時間給の作業者をモノのように扱うのをやめる。
  固定給の作業者には、毎年の査定をやめる。

• １３．全員に対して教育と自己改善を奨励する。
  教育を受けた労働力と管理層が、将来への鍵になるのである。

• １４．変化を遂げるための行動をとる。
  経営トップ層が、サポートするだけではなく、実際の行動によって変化を導いていかなくてはならない。

良いはずの活動がなぜ失敗するのか

• マネージメント改革を勝手な解釈に基づいて模倣しようとする企業はほぼ例外なく、革新の基本原則を見落としてしまう。
• マネジメントの常識は、経営者層の考え方にあまり深く浸透しているため、ほとんど無意識に信じられており、論破できない。
• マネージメント革新の根本にある原則が型破りであればその分、競合他社側の反応も時間もかかる。何十年もの間、手が打てないまま頭を悩ませ続ける場合さえある。

別の言い方をすれば、マネージメント革新の要点は、
その革新を真似しようとするほとんどのマネージメントチームには見えないもの。

• 例：
  トヨタの真の革新は、「普通の」従業員の知力を引き出す能力である。
  リーン導入を成功させるためには、何よりもまず、社員全員（特に、製品を作ったり、コードを作り出したりする「普通の」従業員）に対する深い敬意を基礎としなくてはならない。

チーム

人を集めてグループにし「チーム」と呼んだとしても、それでチームが出来上がるわけではない。
メンバーが、各自持つさまざまなスキルを出し合って、共通の目的のために共同作業をする、
というお互いの約束があってはじめて、グループはチームに変わる。

つりがね曲線

優れたソフトウェア製品を生むには、
第一に、アーキテクチャー、オブジェクト指向技術、コーディング戦略、データ構造、テスト自動化など、あらゆる分野での優秀な技術専門知識が必要となる。
優れた製品の背後にはからなず、その開発手法とは関係なく、優秀な技術者いるものである。

• 開発チームには
  目標達成に必要とされる専門知識を備えた人材がいなくてはならない。
• チームメンバーは
  特定のチーム目標を達成することを約束し合わなくてはならない。

協力し合い、必要とあればお互いに助け合って、確実にその目標を達成できなくてはならない。 チームに複数のスキルを兼ね備えた人材がいれば、お互いに助けやすくなる。

チームの全員が、第一に、チームの一員であり、次に、特定の分野におけるスペシャリストなのだ。
チームに完成させると約束した作業がすべてが終わるまでは、チームの誰一人として「仕事がおわった」ことにはならない。
そのため、全員が自分にできることなら何でもする。

チームリーダー

• １人か２人、顧客を深く理解し、技術を深く理解する人物がいるべきなのだ。
• それが２人の場合、お互いの意見を一致させ、２人で製品の成功に対する責任を負わせなくてはならない。
• 組織が新しいプロセスを実施するときには、プロセスリーダを立ててもいい。
• しかし、チャンピオンと緊密に協力し合うか、プロセスリーダー役をチャンピオンの役割として加えるかして、
  プロセスリーダーの役割をチャンピオンの役割をうまく同調させなくてはならない。

責任ベースの計画と制御

• ボートのチームにはコーチがいる。
• コーチは通常、メガホンを手にモーターボートに乗り、練習メニューを組み立てたり、改善点を指摘したりする。
• しかし、レースが始まれば、後はすべてチームに任される。コーチに出来るのは見ていることだけ。
• 責任ベースの計画と制御も、それと同じ原則で動いている。
• 十分に訓練された専門家に指図するのをやめて、彼ら自身に何をすべきかを見つけ出すように求める時期は来る。

スケジュールを約束するときに、心に留めておかなくてはならない重要な点がある。
それは、完成を約束した仕事をするための時間がかならずなくてはならないということ。
その仕事の細部は常に変化するということである。チームに厳しい締切を守って欲しいなら。
作業を許容量以内に制限しなくてはならない。

それにはいくつかの方法がある。

トヨタは、どのような開発サイクルであっても、必要な作業量を見積もるのがうまく、各職務がある程度平均して必要とされるよう、モデルの開発サイクルをずらしている。
さらに、トヨタは細かなスケジュールを決めようとはせず、各部門や各サプライヤに、チームメンバーが手助けを必要としているときはいつでも支援するよう、求めている。

スケジュール

1．タスクのスケジュールを立てないほうが良いですか？

　タスク完了日のように、本質的に変動しやすいものに対して、決定論なスケジュールを用いれば、 　本当のタスク完了日はスケジュールとかならず食い違う。
　タスクの完了日を変動させまいとするのは、テミングの教えのとおり、間違った手法にほかならない。 　変動は、システムに内在するものだから。

システム自体を変える必要があり、その選択肢は３つである。

• a．モンテカルロ・シュミレーションを行って、スケジュールの確実性をあげるという方法がある。
  しかし、この手法が最も効果的なのは、機能レベルでのスケジューリングの場合。

• b．後述するように、クリティカルチェーン・スケジューリングによってスケジュールにプロジェクトバッファを使うという方法がある。

• c．単に、タスクのスケジューリングを一切しない、という方法もある。その代わり、責任をベースとした計画と制御を行う。

2.WBS(WorkBreakdownStructure 作業分割構造)は必要ないのでしょうか？

• システム設計には欠かせない作業、主要なサブシステムの設計やインターフェース設計は必要である。

• これは機能のブレークダウン構造(FBS)であり、作業のブレークダウン構造(WBS)ではない。

• 【ＦＢＳ】Function Breakdown Structure： 　ものごとを行うためにはそれを実行する機能が必要である。 　裏返せばプロジェクト遂行は“まずそれに必要な機能(Function)を確保し、これを（メンバーの誰かが）実行すること”とも言える。
  

　タスクのスケジューリングをする代わりに、どのような機能を、いつ実際にデモとして動かすべきかを決定する。 　そのような機能を、実装できるだけのスキルと許容力があることを確認した上でチームにアサインして、チームに自分たちで作業管理させよう。

3.依存関係はどうしたらいいですか？

• まず、すべての依存関係が本当に必要だとは考えないほうが良い。

　個人やチームは、依存関係にあるタスクを、その目標が達成できるように実装しなくてはならない。 　聡明なシステム設計やオプションベースの開発手法（第７章の「集合ベース設計」を参照）を用いた上で、 　シンプルで効率的なコミュニケーションを取り合えば、依存関係に対処する最高のツールになる。

自律的な作業

• 多くのことを本当にすばやくやるには「人に作業を与える」という戦略から「人が作業を自律的に行う」という戦略に切り替えなくてはならない。

• 作業を与える場合 他の人の作業ステップをいちいち計画しなくてはならない。 作業を自律的にするためには 指示を受けなくても各自がどのように作業を行えばよいのかわかる環境を作り上げなくてはならない。

• 多くのことを素早くやらねばならない場合 作業を自律的に行うのが、唯一うまくいく手法。
  

作業が自律的であれば、朝職場に現れた全員が、指図されなくても、正確にやるべき仕事を把握できる。そして、もっとも重要な仕事を選んで取り掛かるだろう。
仕事を終わらせたら、次にすべきことが見えてくる。
一日のうちいつでも、質問が出たときに見回して、すぐにその答えがわかるような職場にする。

自律的な職場を作るには３つの重要な情報ツールに着目しなくてはならない。

かんばん、あんどん、ダッシュボード

かんばん

• かんは、日本語で「見る」、ばんは日本語で「板」のこと。

かんばんに関して、肝となるのは、次の作業の選び方ではない。 それは簡単だから。
本当に難しいのは、カードが選ばれたときに次に取り掛かるのにふさわしい分量の作業内容がカードに十分書き込まれているよう、カードの内容や場所を確実かつ正しく保つという点

カードは作業仕様ではない、それは、次の仕事に向けて、カードに書かれたストーリーを詳細設計したり検証したり実装したりするのにふさわしい人材を集めるための合図。

作業を自律的にするために、どのような仕組みを使うにしても、多少の思索や実験が必要になる。
それぞれの仕事が、簡潔に説明されていなくてはならないし、作業のセットは完全かつ正しい順に並べられていなくてはならない。
作業の提出や選択のルールにより、その作業を上手にできる専門知識を備えた人が作業するよう、保証しなくてはならない。

あんどん

• トヨタでは「あんどん」という言葉を「ライン・ストップ」させるために引っ張る紐を指して使っている。

あんどんの紐を引くと、通常ライトがついて、問題がおきている場所に注意を喚起させるから。 あんどんの背景には「すぐに解決できるように問題を開始化する」という考え。

駅に設置された出発ホームを表示する掲示板は、あんどん板と呼ばれることがある。
あんどん板は、注意すべき異常に気を向かせ、変わりゆく状況に応じて表示を変え、頻繁に手が加えられている箇所（例えば、どのサーバが今のテストサーバなのか）を示す。

ダッシュボード

• チームが自分たちの作業進捗を、状況に即して、そして、より広範囲な会社の目標に即して目にするのは重要なこと。
  

そのために、いろいろな種類のダッシュボードを用いる。
バーンダウンチャート、作成・実行された受け入れテストのグラフなどは非常に役立つ。
複数チームにまたがる作業の全体的な進捗状況は、中心となる「戦術ルーム」に全員が見れるように貼っておくのがよい。

その場合、電子ダッシュボードが最適ツール 電子ダッシュボードは、手で作るよりも電子的に生成したほうが簡単な、主要メトリクスを算出するのにも便利。

インセンティブ

• 企業が死ぬのは、マネージャーたちが製品やサービスを生み出す経済活動ばかり意識を向けて、組織が本来、人のコミュニティであると言うことをわすれてしまうためである。
• 人々が仕事に対して関心を持ち、信頼し、熱中する度合いは、収益に直接的な影響を与えるだけでなく、企業の予測寿命に何よりも直接的な影響をあたえるのである。

業績評価

• テミングのアドバイスの中で、最も無視されているのがこれ

「従業員に対する毎年の査定をやめる。個人の成績を評価して、チーム内の協力関係の土台を崩してはならない」
毎年の能力評価で、思いがけないフィードバックをして、社員を驚かしてはならない。
能力評価のフィードバックグループは１年（あるいは、四半期）も一度の査定サイクルよりももっと短くあるべきだ。
毎年の能力査定のときだけ、従業員にとって自分の働きぶりを知る機会なのであれば、その評価システム自体に真の欠陥があるということだ。

能力査定の基準では（もし現状がそうであれば）、個人の業績よりも、チームの成功への貢献を重視し、チームワークに重点を置くべきである。

結果として、得られるのは、評価する対象なのだ。つまり、協力関係を評価する効果的な方法を見つけられれば、協力関係からもっと多くのものが得られることになる。

効率に関する問題は、マネージャー側の問題である
マネージャーは組織の業績に対する責任を負い、システムの効率を改善するために、部下と協力しなくてはならない。

ランクづけ

• リーンな世界では、わざわざ誰かを非難するようなことはしない。

誰でも同じ失敗でをしていたかもしれない。非難する代わりに、 その問題が二度と起こらないように、システムのポカヨケを備える方法を見つけ出そうとする。