ISO 26262との向き合い方 (25) B787バッテリ故障FTAモデル

現在、SESSAMEで主催するソフトウェア安全分析・設計セミナ（第1回 6/7, 第2回 7/19)の講義スライドを作っている。

この特集記事を書いているせいか、第1回目のセミナの応募者の半分以上が自動車ドメインの方になっている。

第1回目のセミナは募集開始から10日間で定員に達してしまったため、第2回を 7/19 に行うことになった。

第2回は自動車ドメイン以外の方にも是非多くきて欲しいと思っているので、最近ニュースになっているボーイング787のバッテリ故障について FTAを使ってケーススタディをしてみようと思う。（このケーススタディはソフトウェア安全分析・設計セミナで詳しく解説する）

B787のトラブルのうち 1/8 と 1/16 のぶんがリチウムイオンバッテリの発熱・発煙事故だった。

日付 （日本時間）	会社	トラブル
01月08日	JAL	米・ボストンのローガン国際空港で、駐機中の日航機の機体内部から出火
01月09日	JAL	同空港で、地上走行中の日航機の主翼から燃料漏れ
01月09日	ANA	羽田発山口宇部行きの全日空機でブレーキに不具合
01月11日	ANA	羽田発松山行きの全日空機で操縦席窓にひびが入るトラブル
01月11日	ANA	宮崎空港で離陸前点検中の全日空機の左エンジンからオイル漏れ
01月13日	JAL	成田空港で、米国ボストンの空港で燃料漏れを起こした機体が、整備作業中に燃料漏れ
01月16日	ANA	山口宇部発羽田行きの全日空機で飛行中、操縦室内で異臭がしたため高松空港に緊急着陸。乗客129人と乗員8人が脱出用シューターで避難、乗客5人が軽傷

ニュースソースによるとボーイング社はリチウムイオン電池の故障確率を1000万時間に1度としていたが、実際には5200時間以下で事故が発生した。

FTAでは部品の故障確率を計算して総合的にトップ事象が発生する確率を計算できるが、個々の基本事象の発生確率の根拠が不確かな場合、トップ事象の確率がいい加減になるという典型的な例だ。

歴史的にもFTAによって、事故事象の発生確率が意図的に低いように見せるために、基本事象の発生確率を低く設定した例はある。また、ソフトウェアが起因する不具合の場合、不具合の発現は統計的な確率を持たないため、FTAでもこのことを考慮する必要がある。（詳しくはソフトウェア安全分析・設計セミナで解説する）

リチウムイオンバッテリが熱暴走し発熱・発煙したことは事実だが、結局その原因はまだ分かっていない。そこで、ボーイング社は80の可能性について対策を施すことで、FAAに B787 の飛行許可を申請し受理された。

ニュースでは熱暴走の本当の原因が分からないままで、運行を許可してよいのかというコメントが必ず付く。その通りなのだが、実際、セーフティ・クリティカルな製品を製造し市場に出している中で、再現しない不具合に対処しなければならないことはある。

そのような場合は、今回ボーイング社が行ったように、想定されるすべてのリスクを洗い出してその対策を施す。これが、リスクアセスメント（リスクの特定、リスク分析及びリスク評価）とリスクコントロールであり、ソフトウェア安全分析・設計セミナのメインテーマだ。

ボーイング社が80の対策を行ったということは、逆に言えば、対策を行う前は新たに想定した故障が具現化するとバッテリが熱暴走を起こし発火・発煙を起こすということだ。

これを FTA で表すと左記のようになる。実際はそう単純ではないが、何らかのハードウェアの故障及びソフトウェアの不具合が発生するとそれが OR 接続でトップ事象に結びく。

何か一つクリティカルな故障が起こるとそれが重大事故に繋がることを FTA は表している。

一般の人は、なぜ前もって対策をしなかったのかと思うだろうが、このような トップ事象に至る基本事象は無限に存在するのだ。

だから、ボーイング社が事故が起こった後に行った追加対策は80もあった。ただ、それで全てではない。リスクは無限に存在するので対策も無限に存在する。

そういった場合、仮にトップ事象の発現を押さえる包括的な対策があれば、それをシステムに追加することが安全面では非常に有効だ。（エレベータで安全用のブレーキを追加するなど）

これを FTA 表すと左のようになる。熱暴走故障の発現は包括的な安全装置で押さえられており、安全装置が故障しない限りトップ事象には至らない。

トップ事象は熱暴走の故障と安全装置故障が AND で起こらないと発生しないので、非常に低い確率に抑えることができる。

ただし、これは安全装置をハードウェアで用意した場合であって、ソフトウェアが絡んでいると必ずしも確率を言えないので注意が必要だ。

では、包括的な安全対策がない場合はどうするのか。それは、この図のように、ひとつひとつのハードウェア故障の発生確率を下げる対策を取る（Fault Avoidance)か、ハードウェア故障が発生したことを検出して、故障の発生を認知したら、オペレータに知らせそのための対策をオペレータが取る。

実際今回の80の対策のうち、バッテリの状態をB787の運行中も地上で監視できるようにしたそうだ。

バッテリ状態に異常があることが分かったら、パイロットに緊急着陸の指示を出す。

これを FTA で表すと左記のようになる。ハードウェア故障1の発生確率を下げ、かつ、故障検出装置を付けることで故障検出装置が故障しない限り、ハードウェア故障1のトップ事象への影響を下げることができることが分かる。

そして、最後に問題として残るのがソフトウェアの不具合がトップ事象に与える影響だ。

ハードウェアによる包括的な安全装置が使えない場合、個々のハードウェアの対策をしても、ソフトウェアの不具合がトップ事象に直接作用してしまう場合がある。

ソフトウェアの不具合の発生確率は統計的な性質を持たないため、高いとも低いとも言い切れない。

これが Systematic Failure の特徴だ。このように包括的な Fail Safe 対策が取れない場合、Fault  Avoidance  対策かFault Tolerance 対策で対処するしかない。

そこがソフトウェア対策の難しいところだ。実際、B787のバッテリ制御ソフトウェアに対しても、今回対策を行ったと報じられている。どんな対策か詳細は伝えられていないが、おそらくソフトウェアの信頼性検証を再度行ったか(Fault  Avoidance対策)、冗長設計(Fault Tolerance対策)を施したのだろう。

なお、FMEA（ハザード分析）をするとこんな感じになる。

ソフトウェア安全分析・設計セミナでは上記のことを含めた安全実現の手順について下記を紹介している。

1. Intended Use （意図した使用目的）を定義する
2. リスク分析を実施する。（ユーザビリティを考慮する）
3. リスクを評価する。（FMEA：ハザード分析、FTA)
4. リスクコントロール手段を考える。（ハード or ソフト or 表記）
5. ハードウェアによるリスクコントロールを優先する。
6. ソフトウェアによるセーフティアーキテクチャを可視化する。
7. 安全に貢献するソフトウェアアイテムを特定する。
8. それらのソフトウェアアイテムの信頼性を高める。
9. セーフティアーキテクチャを維持する。
10. フィールドで発生した問題をトリガにして1から繰り返す。

セミナでは、今回説明したB787バッテリ事故モデル以外にも、放射線治療器 Therac-25 の事故モデル、体温計モデル、エレベータモデル、電気メスモデル、緊急操舵回避支援システムモデルについて解説する。

7/19 の回にはまだ空きがあるので、是非セミナを聞きにきて欲しい。

ISO 26262との向き合い方 (24) ソフトウェア安全分析・設計2

SESSAMEで6月7日に開催するソフトウェア安全分析・設計セミナの資料を作っているところだ。

4月17日に募集要項を公開してから2日間で事務局宛に11名の応募があったようだ。（定員は30名なので参加を検討されている方は早めに申し込んで欲しい）

東京近郊以外の遠方から申し込んでいただいた方も半分くらいおられるので、その方達の期待に添う内容にしたいと思っている。

セミナで使うスライドはまだまだこれから作成、ブラッシュアップしていくので、参加を希望されている方達の業務ドメインを眺めながらそれぞれの実務でイメージが湧くような事例を多く紹介しようと思っている。

なお、このブログで ISO 26262 の特集記事を書いていることもあって、現在のところ自動車系のドメインの方の申し込みが多い。（自動車ドメインに特化した内容ではないので、他のドメインの方も来て欲しい）

この記事では、『ソフトウェア安全分析・設計セミナ』が、他の ISO 26262 に代表される機能安全のセミナとどこが違うのかを説明したいと思う。

プロセスアプローチの話をするつもりはない

このセミナでソフトウェア開発のプロセスアプローチの説明をくどくどとするつもりはさらさらない。そこが他のセミナとの違いだ。 ISO 26262 に代表される機能安全のセミナは、必ずソフトウェア開発プロセスの話から入り、ソフトウェア開発プロセスの重要性を説き、ソフトウェア開発プロセスのマネジメントの話をし、場合によっては、プロセス管理に有効とされるツールが紹介され、コンサルテーションを勧められる。

ISO 26262 だけでなく、ISO 9001 以下、ほとんどの品質要求がプロセスアプローチをベースにしているのでしようがないが、自分はこの流れに対して常に違和感を感じてきたエンジニアの一人だ。

プロセスアプローチを否定するつもりはまったくないが、特に日本のプロジェクトの場合、そこから入ると本質を見失うような気がしてならない。

自動車ドメインの方達はもしかすると自分が考えるこの違和感に慣れていないのではないかと思っている。特に自動車ドメインではハードウェアエンジニアの人や、ハード・ソフト込みでコンポーネントに対する責務を負っている人達、品質保証部門の方達が今後の方向性が分からなくなっているような気がする。

自動車業界では、昔からソフトウェアの開発に対してプロセスアプローチが求められてきた訳ではない。今回 ISO 26262 が国際規格になって初めて、ソフトウェア開発にプロセスアプローチが求められた。それまでハード屋さんは、ソフト屋さんにソフトウェア開発に関するすべてを委任してきた。ところが、ISO 26262ができて、ソフトウェア開発にプロセス要求が求められていることに気がついた。

そこで、ソフト屋さんに「これらの要求は当然これまでもやってきていて、できているんだよな」と尋ねる。ところが、その回答の歯切れが悪い。「当然、できています」という答えが返ってこないのだ。

そこで、ハード屋さんやQA担当は、「だから、ソフトウェアで問題が起こるんだ」「国際規格にも適合できないような作り方をしているから問題を起こすんだ」とはや合点する。

自動車ドメインのソフト屋さんを代弁して言う。「そうじゃないからね」。

日本の自動車産業の組込みソフトウェアの品質は海外のソフトウェアの品質より格段に高かったし、今でもその品質を高く保っている。

そして、それが達成できている理由は、下記の図にあるように文化の違いともの作りのアーキテクチャの違いから来ている。

欧米のもの作りでは「ルール/責任」を重視し「システム/ツール」を使いこなすのが得意だが、「品質を心配する意識」が低い。一方、日本のもの作りでは、「ルール/責任」は重要視せず、「システム/ツール」を使いこなすのが下手だが、「品質を心配する意識」がものすごく強い。それも、マネージャクラスの意識だけが強いのではなく、プロジェクトメンバー全員の意識が高い。

そして、システムのアーキテクチャがコンポーネントの組合せではなく、すり合わせたような作り方をする。

サンプルは少ないかもしれないが、日本のソフトウェアに起因する不具合が修正されるスピードは欧米のそれに比べて格段に早い気がする。

ようするに、不具合が見つかってからアップデートのプログラムがリリースされるまでが早い。問題が放置される時間が短いので、長い目で見れば顧客満足度は高い。

海外の開発品で不具合の現象がはっきり出ているのに、なんだかんだ理由を付けて改善のためのアクションを起こさないという例を数多く見てきた。

責任の所在があっちだ、こっちだと言っているうちの時間だけがどんどん経過していくというケースもたくさんある。

それに比べると日本のソフトウェアプロジェクトでは問題が起こったという情報が伝わってきた時点から、猛然と原因を調べ始める。これは「品質を心配する意識」が強く、恥の文化があるからだと思う。

逆の言い方をすると、欧米の文化では、「品質を心配する意識」が弱く、恥の文化がないから、ソフトウェア開発プロセスをがっちり管理しないと、品質が上がらないのだ。

ソフトウェア品質系の国際規格で問題解決プロセス(Software problem resolution process)がやたら強く要求されていて、何でだろうと考えていた。

問題解決プロセスの例 (Software problem resolution process)

1. 問題報告の作成
2. 問題の調査
3. 関係者への通知
4. 変更管理プロセスの使用
5. 記録の保持
6. 問題の傾向分析
7. ソフトウェア問題解決の検証
8. 試験文書の内容への要求

それは、問題解決プロセスを定義して問題が起こったときにそのプロセスを回さないと、人が動かないからそうするのだと気がついた。問題の重大度にもよるが、日本のプロジェクトではいちいち問題解決プロセスを回さなくても、問題がものすごいスピードで解決されてしまうことが多いと感じる。

すべてのケースでそのやり方がよいとは思わないが、通り一遍の問題解決プロセスの適用はかえって顧客満足度を下げる結果になると思う。

だから、プロセスアプローチ至上主義のような説明は本セミナではしない。

自動車ドメインの例で説明するとこうなる

だからといって、自動車ドメインのソフトウェア開発のあり方がいままでのままで何も変えなくてもよいとは考えていない。そう考える理由を一つの例で説明しよう。

自動車のアーキテクチャの基本は「走る」「曲がる」「止まる」の3要素だ。

そして、それらの三つの基本要素はハードウェア的にもソフトウェア的にも独立していた。

それは設計としては美しい。それぞれの機能・性能要素の関連が疎でり、独立性が高い状態で維持できていれば、システム全体としての複雑性を回避できるし、何か問題が起こったときでも、どこに不具合の原因があるのかがすぐに分かる。

さらに、コンポーネントごとにサプライヤを分離できるため、設計上だけでなく問題が発生したときの責任も明確になる。

自動車業界におけるメーカーとサプライヤの関係ともマッチする。

完成度の高いコンポーネントを組み合わせることで製品全体の信頼性が高まる。

このようなアーキテクチャはセーフティの観点から見るとフォールドアボイダンス(Fault　Avoidance) と言う。

しかし、現代の自動車のシステムはこんなに単純な構造ではない。

高凝集、疎結合のコンポーネントの組合せではなくなってきている。前述したすり合わせのソフトウェア構造が有効なのは、基本機能・基本性能のコンポーネントの中の話だ。「走る」の機能・性能を司るコンポーネントの内部である程度のすり合わせがあるのは総合的にプラスに働くことがある。（競争力の高いコア資産の形成に有利）

ところが、最新の衝突回避システムを導入すると、衝突リスク分析判定ECUを介して「止まる」と「曲がる」の基本機能コンポーネントの結合度は強くなる。

ハイブリッド車では「走る」と「止まる」はすでにエネルギーの回収をすることで結合しているので、今後、自動車のシステムアーキテクチャはどんどん複雑になって結合を強めていく可能性がある。

その結果、コンポーネントごとに明確だった責務が「走る」「曲がる」「止まる」にまたがってくる。

このことは不具合が起こったときの対処や、そもそも安全を考慮した設計ができているかどうかの確認の所在が、サプライヤをまたがる可能性が出てきたということだ。

この状況はこれまでの強みだった日本の良さを消しかねない。自動車のシステムアーキテクチャの変化が、日本的なもの作りのやり方のアドバンテージを低下させようとしている。

そうなると、欧米的なプロセスアプローチを取り入れないと安全が確保できないかもしれない。

リスクマネジメントとセーフティアーキテクチャの重要性

ただ、自分は日本のもの作りにおいて、今後も世界の優位に立つための必要なのはリスクマネジメント（リスクアセスメント+リスクコントロール）とセーフティアーキテクチャ設計だと考えている。

そこを押さえた上で、プロセスアプローチを取り入れていけばよい。

こういった話を織り交ぜながら、セーフティの考え方と具体的な実践手法を6月7日のセミナでレクチャーしたいと思っている。

今回の記事では自動車ドメインでの例を取り上げたが、参加者の業務ドメインを見ながらどのドメインにも通じるような話をしたいと思う。

P.S.

自動車業界でも医療機器業界でもUSでは規制をクリアするために必要な知識・スキルをを身につけるセミナはだいたい3日間で$1500～$2000くらいかかる。（1日あたり $500 以上） これに宿泊代や飛行機代がかかるから、結果としてものすごい金額になる。（例えば、こんな感じ。大学のセミナだってそれぐらいかかる。）

ISO 26262との向き合い方 (23) ソフトウェア安全分析・設計セミナ

ISO 26262 が2011年に発行されてから時間が経過し、今になって自動車の設計開発の現場で混乱が起こり始めたような気がする。

ソフトウェアの開発経験のないハードウェアエンジニアにもISO 26262の存在がクローズアップされるようになり、ソフトウェアエンジニア達に規格適合できているの問いただすような視線を送るようになってきた。

ISO 26262 は基本的にプロセスアプローチだから、規格が要求するプロセス通りにもの作りをし、エビデンスとなるドキュメントが作成していないと規格に適合していると認めてはもらえない。

規格適合について監査したり、自分達でアセスメントをしたりすると、いろいろと漏れが出てくる。そうすると、ソフトウェアのことを分からない人達は「なんだ、ダメじゃないか」「どうして、国際規格の要求ができていないんだ」「怠慢だ」とソフト屋さんを責める。

電気的安全性のように試験で白黒がはっきりするような規格なら、不合格のままで出荷されることなどないから、ハード屋さんや品質保証担当は、ソフトウェアの規格が満たされないまま商品が世界に出荷されていることが我慢ならないのだろう。

しかし、そこがソフトウェアの評価の難しいところだ。ソフトウェアはハードウェア部品のように確率論的な故障のしかたをしない。だから、ソフトウェアの信頼性を高めるためにはソフトウェアの開発プロセスを管理するしかないというのが定説になっている。

しかし、ソフトウェアの信頼性を高めたからと言って、システムが安全かと言えばそうではない。このことを上記のような感情を抱くハードウェアエンジニアや品質保証担当は分かっていない。

分かっていないにもかかわらず、ソフトウェアの開発プロセスの管理ばかりに注力を注いでいると、規格の目的とは対照的に商品の安全性が脅かされる危険さえある。

そういう背景もあって、所属しているコミュニティの SESSAMEで 2013年6月7日(金)にソフトウェア安全分析・設計セミナ（1日）を開催することになった。

6月7日のセミナは、ソフトウェアプロセスアプローチとはまったく別の切り口から安全設計を考えるセミナだ。


セミナのプログラム案はこのようになっている。

22nd Open SESSAME Seminar プログラム（案）
10:00～10:30	クリティカルソフトウェアを取り巻く環境
10:30～11:30	安全（セーフティ）の考え方 ・安全（セーフティ）の定義 ・リスクアセスメント,リスク低減 ・リスクマネジメントの反復プロセス ・ソフトウェア起因の障害のリスク評価
12:30～13:30	リスク分析手法1（FMEA) ・FMEAの歴史、ハザード分析 ・ソフトウェア視点のFMEA
13:40～14:40	リスク分析手法2（FTA) ・FTAの歴史 ・ソフトウェア視点のFTA
14:50～16:10	リスクコントロール手法 ・フェールセーフ ・エラープルーフ（フールプルーフ） ・フォールト・アボイダンス ・フォールト・トレランス ・ソフトウェアコンポーネントの分離 ・事例検討
16:10～16:30	リスクコントロールの維持
16:30～17:00	質疑応答

プログラムを見てもらえば分かるように、リスク分析とリスクコントロールの方法に注力を注いだ構成になっている。FMEAやFTAは古くからあるリスク分析手法で、教科書も日科技連から出ていて、セミナも定期的に行われている。ただ、改めて教科書となっている本を眺めていると、事例が古いのと、ソフトウェアのことが考慮されていない。

これらの教科書が書かれた時代から、すでに40年近く経過している。時の流れとともに、商品はソフトウェアへの依存度が高くなり、その構造自体もかなり変わってきた。

例えば、これはFMEA/FTAの教科書に載っているガス暖房システムのブロック図だ。昔のシステムはハードウェアコンポーネントが独立したブロックになっていて、ブロック図の四角と実際のコンポーネントが一致していた。

だから、FMEAを実施する前に作成する信頼性ブロック図の各ブロックはそれぞれ独立性が高かった。別な言い方をするとブロックで書かれたコンポーネントの凝集度は高く、他のコンポーネントとの結合度は低い設計になっていたということだ。

しかし、システムの制御の大半をソフトウェアが担うことになって、信頼性ブロック図で書かれたコンポーネントと現実のハードウェア、ソフトウェアのコンポーネントは一致しなくなった。

また、ソフトウェアコンポーネント同士は密接に結合するようになり、どことどこがくっついているのか、どこがどこに影響を与えるのかどんどん見えにくくなってきている。

システム構造の変化が激しく起こったため、FMEAやFTAなどのリスク分析の手法も時代に合わせて使い方を変える必要がでてきた。6/7のセミナでそれを解説したいと思う。

また、これだけソフトウェアの規模が拡大し、複雑化した今日において、システムを構成するすべてのソフトウェア部品の信頼性を高めようとするアプローチは効果が薄く、苦労する割には得るものが小さい。

安全設計の方法（日経ものづくり 2010年8月号 の特集記事『ソフトが揺さぶる製品安全』参考）

現在のソフトウェアシステムのセーフティを実現するための考え方は全体最適の発想が必要である。それを表したのがこの図である。

フォールト・アボイダンスは個別最適の発想であり、大規模ソフトウェアシステムの安全性はそのやり方では確保できない。

全体最適の手法としてフェール・セーフ、フォールト・トレランス、エラー・プルーフといった考え方をシステムの設計者は常に考慮しなければいけない。

また、ソフトウェアによってシステムは格段にユーザーインタフェースが向上した。UIが向上した一方で、オペレーションが複雑になり、ユーザーが誤った使い方をすることでリスクを生むようになった。このため、ソフトウェア搭載機器の危険を避けるためのユーザビリティエンジニアリングは重要性が増している。

セミナでは、これらのリスクコントロール手段についても解説をしたいと思っている。正式なアナウンスは SESSAME のホームページでの掲載を待っていただきたいが、興味のある方は自動車ドメインの技術者だけでなく、さまざまな産業のソフトウェアエンジニア、ハードウェアエンジニア、品質保証担当に参加して欲しいと思っている。

問題解決リーダーシップ(Problem Solving Leadership)：自ら動きそしてチームを動かす力

確か北九州市立大学の山崎さんの紹介だったと思う。今、『採用基準』という本を電子ブックで読み終えたところだ。

Amazon でのこの本の内容紹介はこうだ。

マッキンゼーの採用マネジャーを12年務めた著者が語る

マッキンゼーと言えば、ずば抜けて優秀な学生の就職先として思い浮かぶだろう。そこでは学歴のみならず、地頭のよさが問われると思われがちで、応募する学生は論理的思考やフェルミ推定など学んで試験に挑もうとする。
しかしマッキンゼーの人事採用マネジャーを10年以上務めた著者は、このような見方に対して勘違いだという。実はマッキンゼーが求める人材は、いまの日本が必要としている人材とまったく同じなのだ。だからこそ、マッキンゼーは「最強」と言われる人材の宝庫の源泉であり、多くのOBが社会で活躍しているのだ。
本書では、延べ数千人の学生と面接してきた著者が、本当に優秀な人材の条件を説くとともに、日本社会にいまこそ必要な人材像を明らかにする。

でも、マッキンゼーの採用基準を紹介した内容というよりは、日本の組織に足らないもの、鍛えられていないものが何かを語った本だと思う。

このブログでもよく読まれている『問題解決能力（Problem Solving Skills)：自ら考え行動する力』で紹介した本もマッキンゼーを卒業された渡辺健介さんの本だった。

『採用基準』もよく売れているらしく、この本の著者の伊賀泰代さんもマッキンゼーの出身だ。あまりよく知らなかったがマッキンゼーは相当すごいコンサルティングファームらしい。

マッキンゼーでは、問題解決スキル(Problem solving skills)という言葉と並んで「問題解決リーダーシップ（Problem solving leadership)」という言葉が使われる。この本では、この問題解決リーダーシップの重要性やそれがいったいどういうことなのかの説明にかなりのページが割かれている。

伊賀さんはリーダーシップを組織やプロジェクトの中で一人が持っていればよいものではないと強調している。

【『採用基準』「リーダーシップは全員に必要」から引用】

「組織においてはごく一部の人がリーダーシップを持っていればいいのに、なぜ外資系企業や欧米の大学では、採用面接や大学入試において、全員にリーダーシップを求めるのか」と不思議がられるのです。同様の趣旨で、「メンバー全員が強いリーダーシップを持っていたら、チーム全体としてはうまく動かないのではないか」といった質問もよく聞かれます。

この質問に対する私の答えは極めてシンプルです。全員がリーダーシップを持つ組織は、一部の人だけがリーダーシップを持つ組織より、圧倒的に高い成果を出しやすいのです。だから、学校も企業も、欧米では（もしくは外資系企業では）全員にリーダーシップ体験を求めるのです。もちろんマッキンゼーがリーダーシップを、重要な採用基準と考えているのもそのためです。

【引用終わり】

全メンバーがリーダーとしての自覚を持って活動するチームは、「一人がリーダー、その他はみんなフォロアー」というチームより、明らかに高い成果を出すことができると伊賀さんは言っている。

そして、日本でリーダーシップの概念が理解されず、教育がなされない背景に成果が最優先されない場合が多いからだと書かれている。

【『採用基準』「成果主義とリーダーシップ」から引用】

リーダーシップという概念がここまで理解されていない背景には、日本では社会において、さらに言えばビジネスの現場においてさえ「成果が最優先されない場合が多い」ことが挙げられます。実はリーダーシップを考える時、常にセットで考える必要があるのが「成果主義」なのです。成果主義とは、「努力でもプロセスでもなく、結果を問う」という考えであり、成果主義を原則とする環境でなければ、リーダーシップは必要とされません。

例えば、町内会のグループでお祭りの出し物を企画することになったとしましょう。どんな出し物をするか、町内のメンバーから意見を募ります。こういった話し合いの際、「できるだけ多額の収益を上げ、それを被災地に寄付する」という成果目標がある場合と、特に成果目標はなく「お祭りだから楽しければよい」という場合では、リームの運営方針は大きく異なります。
　：
成果目標がなければ、何の出し物をやるかは単純に多数決や場の雰囲気で決めればよいのです。何を楽しいと思うかは人により異なります。五人中四人が焼きそば屋をやりたいと言うなら、残りの一人が異なる意見をもっていても、「みんながそういうなら、焼きそば屋でいこう」という話になるでしょう。

この場合、最後の一人が「自分はどうしてもうどん屋がやりたい」と主張して譲らず、最終的に多数決で決める場合もあれば、少数意見をもつ人が空気を読んで自分の意見を出さず、結果として議論も採決もなく、焼きそば屋に決まる場合もあるでしょう。そのいずれの場合でも、リーダーは必要とされません。

しかし、もしも「収益を最大化する」という成果目標があれば、たとえメンバーの大半が焼きそば屋に賛成しても、異なる意見を持つメンバーは「本当に焼きそば屋の収益が高いのか。うどん屋の方が儲かるとうい可能性はないか。売り上げとコストを比較してから決めるべきではないか」と問わねばなりません。ほかの人も同じ成果目標を共有しているわけですから、少数派の意見も比較・検討する必要があると理解します。

【引用終わり】

成果目標を収益だけだと考えてしまうと、「なんと冷たい、血の通っていないリーダーシップなのだ」と思われるかもしれないが、成果目標を「顧客満足度を最大にすること」と考えれば、納得できる。そうすれば、売り上げを上げるために、顧客を裏切る行為例えば偽装表示などは避けつつ、何を成果として達成しなければいけないのかに集中できる。成果主義=悪と捉えるのは短絡的過ぎると思う。

リーダーシップと成果目標はセットで考えるべきという話は納得した。ただし、よいリーダーシップを発揮するためには、よい成果目標も必要だと思う。メンバーが納得できる成果目標であれば、判断にぶれが生じないが、成果目標自体が曖昧だとその場の雰囲気や多数決で物事が決まってしまい、失敗しても誰もが「しようがない」と投げやってしまう。組織的には無駄を容認することにつながる。

他部署の判断に口を出さない人たちは、組織の和や組織の秩序を、ビジネス上の利益最大化という成果目標より優先している。こういった職場では、リーダーは必要とされず、全員が空気を読んで「他部署のことは他部署に任せておこう」という思考停止をし、問題が起こっても見て見ぬふりをし、衝突が起こりそうになれば全員が少しずつ譲り合って衝突を避ける、と伊賀さんはバッサリ切っている。そういう日本の組織っていっぱいある。

この他にも「バリューを出す（何らかの成果を生む）」とか「会議で発言ゼロの人はバリューゼロ」とか「So what? （つまり、あなたの結論は何なの？）」にフォーカスするとか、「必要なのはグローバルリーダーでグローバル人材ではない」といった、そうだよなということがたくさん紹介されている。

『経済産業省が掲げている社会人基礎力』で国が育てるべきと提唱している人材像の中に、リーダーシップという言葉がまったく出てこないのは、今や世界の中で極めて“ユニーク”だと言えるでしょう、とも言われてしまっている。

日本の組織が優秀だと考えているのは「専門性が高い」「協調性があり、組織のルールを遵守する」「迅速に正確な処理ができる」といった人であり、これらは欧米企業が考える優秀な人との間に大きな隔たりがあるとも書かれている。高い専門性も、リーダーシップを併せ持ってこそ評価される資質だというのも同意できる。

最後にリーダーシップとは特別な場所、場面で磨かれるものではなく、日常的に発揮されるごく身近なスキルであるという例えの部分を紹介して終わりにしようと思う。

【『採用基準』「あらゆる場面で求められるリーダーシップ」より引用】

たとえば、マンションの管理組合の会合にお菓子の持ち寄りがあったとしましょう。会合が終わり、帰り際になってもテーブルの上にはお菓子や果物が残っています。貸し会議室なので残していくわけにもいきません。お菓子の数は全員分には足らないので、ひとつずつ分けるのも不可能です。みんながそれらをすごく欲しがっているわけでもありません。 

このとき、「このお菓子、持って帰りたい人はいますか。お子さんがいらっしゃる方、どうぞお持ちくださいな」と声を上げる人が、リーダーシップのある人です。 

そんなつまらないことがリーダーシップだなんてと驚かれるかもしれませんが、これがまさにリーダーシップです。その場にいる人の多くは、机の上にお菓子が残ったままになっていても、「自分が声を上げるべき問題ではない」と考えます。これは「役職」の考え方です。「声を上げるべき立場の人、すなわち会合の主催者である管理組合長が問題を解決すればよい」と考えるのです。 

こういった場面を目にした時の言動によって、人はふたつのタイプに分かれます。最初のタイプは、何らかの問題に気がついた時、「それを解決するのは、誰かの役割（責任）か」と考えます。もう一方の人たちは、それを解くのが誰の役割であれ、「こうやったら解決できるのでは？」と、自分の案を口にしてみます。この後者の人を、リーダーシップがあるというのです。

【引用終わり】

日本の組織にはリーダーシップキャパシティが足らない、成果目標とリーダーシップはセットであるといったことがこの本によって気がつかされた。

また、リーダーシップは学べるスキルであり、自分のキャリアパスの中でどのような特長を活かしてリーダーシップを発揮していくかを考えることが重要であることに改めて気づいた。

P.S.

なお、この本、リーダーシップを絡めたタイトルにすればよいのに「採用基準」というタイトルにしたのは、こんなに売れるとは思っておらず、就職氷河期の話題に乗りたかったからではないかと思う。そこはちょっと残念。

ちなみに、全メンバーがリーダーとしての自覚を持って活動するという精神をマッキンゼーが持っていて、そうなるように人材を育てていることはこの本を読んでよく分かったが、自分が読み飛ばしていなければ、そういう素地を持っていない組織において、どうやって change our mind するのかについては書かれていない。

まあ、それがコンサルティングファームのノウハウであり、もっとも実現が難しいことなのだろう。でも、プロジェクトチームのリーダーシップが産業競争力の高さの全ての要因なら、日本の産業はリーダーシップ教育が充実している他国に負けて、ボロボロになっていても不思議ではない。

しかし、現状は必ずしもそうではないし、まだまだ日本の製品が世界でも優れている分野はたくさんある。だから、リーダーシップの欠如だけを問題視するのはよくない。それ以外の要素で日本のチームが欧米に比べて有利な点が必ずあるはずだ。

だから、我々は自分達のやっていること、自分達のやり方を全否定する必要はない。欧米の優れているところは取り入れて、日本の良いところは捨てずに伸ばす、これを忘れてはいけない。

「採用基準」には後者の「日本の良いところは捨てずに伸ばす」ことは書いていないので、一体それがなんなのかについてはよくよく考えないといけない。（『アメリカ人と日本人』『USとJapanの文化の違いと商品品質との関係』『西洋の真似をするだけというのはそろそろやめよう』『リコールを起こさないソフトウェアのつくり方の感想』を参照されたし）

誰も声に出して提案しない、指示していないのにチームメンバーそれぞれが黙々と自分ができることを実行し、問題を解決するといったやり方は外国人チームではやらないだろうが、日本のチームならよくある光景だ。自分の失敗を恥じて全力で修復し、二度と再発させないと誓うというスタイルも日本のチームだけの特長かもしれない。

自国の良さがどこにあるのかを理解して渡り合う日本人こそグローバルリーダーだということは「採用基準」のどこかに書いてあったと思う。