岸良 裕司氏「大規模ソフトウェア開発における『人中心』の品質革新~組織に自律神経ネットワークをインストールする『QM7つの規律』~」を受けた

講演
項目評価
内容がためになるか4.0
説明の分かりやすさ4.5

ベリサーブ アカデミック イニシアティブ 2022 オンデマンド配信にて。
2022/12/6 – 2022/12/16

講師

株式会社 Goldratt Japan
CEO
岸良 裕司(キシラ ユウジ)氏

全体最適のマネジメント理論TOC(Theory Of Constraints:制約理論)をあらゆる産業界、行政改革で実践。「三方良しの公共事業」をはじめ成果の数々は国際的に高い評価を得て、2008年ゴールドラット博士に請われディレクターに就任。ゴールドラット博士の側近中の側近として知識体系を進化させ、博士の思索に最も影響を与えた一人と言われている。

概要

さまざまな取り組みにもかかわらず、ソフトウェアの品質が上がらないとするならば、この活動は的外れである可能性があります。この講演では、ますます大規模化し、さまざまなステークホルダーが絡む、1万人月を超える車載向けソフトウェア開発において、真の制約を特定し、劇的とも言える品質改善を出したプロセスと成果を紹介します。

最初に

  • オムロンにて右肩成長をさせる。ボーイングにて開発を効率化してコンセプトを固めてから初フライトまで36ヶ月で達成させる。マツダにて4年連続赤字続きだったところから黒字へ転換させる。それら経営のコンサルとして活動していた。
  • 物理学者であるゴールドラット博士が確立したTOC(=Theory Of Constraint: 制約理論)を使用している。
  • ゴールドラット博士曰く、人間の行動は予測できる。予測できないと社会も家族関係も成り立たない。もちろん100%ではないが天気予報も同じだ。TOCは、自然科学と同じレベルの科学的な理論を人間関係や組織に適用している。手法ではない。

全体最適のマネジメント理論 TOCとは

  • 製造業の例。
    • 市場 => 営業 => 設計 => 生産 => 工場 => 現場という流れ
    • 営業 -> 設計生産 -> 設計工場 -> 設計現場 -> 設計と、設計への問い合わせや変更依頼が集中する。その結果、設計がボトルネックになっている。
    • 設計にとって。。。
      • 設計に負荷がかかりすぎ。
      • 良い仕事ができない。
      • 顧客サービスの低下。
      • 結果、せっかくの市場機会の取りこぼしになる。
    • 工場にとって。。。
      • 変更やミスによる手戻り。
      • 手戻りを見越した安全余裕の確保。
      • それらによりリードタイムが冗長になる。
  • 左から右に流れていくもので、20=>15=>10=>12=>16のような仕事量の場合、全体でこなせる仕事量はいくつか?それぞれの部署が一生懸命働いたらどうなるか?真ん中の10の前に仕掛品がどんどん増えていく。
  • 部分最適から全体最適、調和へ
  • 「つながり」と「ばらつき」を前提にすると、どこかに必ず制約がある。全体の制約に集中することが全体最適となる。
  • TOC (Theory Of Constraints) 非制約に力を注ぐことはムダになる。
  • Focus = Not to do = 「今やらないこと」が集中を実現する。

実験

  • 3つの仕事が同時に来た。顧客は別々、すべて緊急案件で、特急納期が要求されている。どの依頼者からも自分のものが最優先と催促。
  • ジレンマ
    • 3つのプロジェクトの納期回答をどうするか?
    • どのプロジェクトを優先するか?
    • 各担当からのプレッシャーはきつい。全てに取り掛かるか?
  • Aというタスク:1~20までを書く。Bというタスク:A~Tまで書く。Cというタスク:○△◇等がランダムに並んだものを書き写す。
  • ダメマネージャーで、全部が最優先だから全てに取り掛かれと言われ、A, B, Cという順で少しずつ取り組んだ場合、すべてが終わるのはかなりの時間が経った後となる。
  • やらないことを決めるマネージャーの場合、まずA、その次B、次Cをやると決める。マルチタスク無しで1つずつ片付けるようにしっかりと言い聞かせる。集中してやるように現場の作業の邪魔はしない。すると、半分以下の時間ですべて終わった。
  • 集中、つまりFocus: Not to doが大事。

経営破綻したハイテク会社

  • 様々な要因があるが、目の前の仕事に追われる -> 人の育成、新技術を学ぶゆとりが無い -> リソースが不足する -> 社外開発が増える -> 湯水のようにお金が出ていく -> 売上と利益を出すことが困難 -> 開発テーマが次々と増える -> 目の前の仕事に追われるというループ。
  • 結果的に、開発レベルの低下、マネジメントが難しくなる、優秀な人がどんどん辞める、ユーザーの真の要望が見えない、価格競争に追い込まれる等に繋がる。

開発の仕事の流れ

チケット管理しているとする。

  • 重要(面倒)なチケットは後回しになる。
  • チケットは沢山完了しているがプロジェクトは終わらない。
  • やっかいな問題が後で露呈する。
  • 準備が不十分で予定より時間がかかる。
  • 割り込みが入ると予定の仕事が終わらない。
  • 助け合いが起こらない。
  • 担当が問題と責任を抱え込む。
  • …等

結果的に、手戻り多発、テストが終わらない、納期遅れ、予算超過等。肝心の作業手順が無く、現場任せ。
しかし、これはソフトウェア技術の問題ではなく、マネジメントの問題である。ソフトウェア技術者でなくても解決できる問題。

解決策(つながりフローボード(WIPボード))

  • 経営幹部と現場の優先順位判断が常に一致
  • チームメンバーの負荷を平準化し、自然に助け合う
  • 手戻り・手直しのムダを撲滅し、生産性を大幅向上
  • 人の仕事の質を上げ、現場に達成感
  • 手遅れになる前にマネジメントが先手管理で現場を支援
  • 会議まで待つことなく、問題解決1個流し
  • 手間がかからず日常業務でシンプルに運用可能
  • ミドルマネジャーが育ち、みんなにゆとりができる
  • 数十か国に広がる数万人の組織にも迅速に導入可能

つながりフローボード(WIPボード)は1枚の紙で下記7つを表現する(ボードの図自体はGoogle検索のこと。Trelloなどのカンバン方式風だが少し異なる)。

  1. 明確な優先順位の判断基準
  2. 負荷の平準化
  3. 万全の準備
  4. 一つ一つ集中完了
  5. 滞留タスクの見える化
  6. 問題解決一個流し
  7. 日常業務で実行

お助けボードというものも作る。上司にサポート依頼。
複数の部署を跨ったエスカレーションボードも作成。
どんな問題が組織全体で起きていて、誰が対応しているのか一目でわかる。
問題解決の滞留を許さない。進捗会議も無し。

問題を報告させるのではなく、問題を早期に拾い上げ、解決するミドルマネージャーを育て、マネジメントにゆとりをもたせる。

マツダやパナソニック等で実践し、慢性的な残業を一気に減らすことにも成功したとのこと。パナソニックは、この取り組みによって日科技連 品質革新賞を受賞したとのこと。

感想

 全体的にわかりやすく、聞き取りやすい発表だった。マルチタスクは効率をかなり落とすというのは、正にその通りと思う。無能上司はなんでも優先と言ってくるというのも経験がある。心理的安全性の保たれた職場で、お助けボードなどによってどういう問題があるかなどを見える化できていれば、マネージャー側も問題を把握して対処しやすく良いと思った。TOC自体は初耳だったが、今回の発表は当たり前のことを言っているとは思う。しかし、その当たり前のことを実践することが難しいのも事実。
 TOC理論について記載された本である「ザ・ゴール」は、Amazon創業者ジェフ・ベゾス氏が2013年にAmazon経営幹部の3冊の必読書のうちの1つに選んでいるらしい(参考: These are the 3 books Jeff Bezos tells his top execs to read)。ザ・ゴールは読む価値がありそうだと感じた。こういった本であればAudibleで聞く方が効率的かもしれない。軽く読みたい人は漫画版が良さそう。

著:エリヤフ ゴールドラット, 翻訳:三本木 亮, 寄稿:稲垣 公夫
著:エリヤフ・ゴールドラット, 著:ジェフ・コックス, イラスト:蒼田 山, 編集:青木 健生, 読み手:岸良 裕司

コメント

タイトルとURLをコピーしました