2006-10-29

顧客満足を高めるためのエンジニアがするべきこと

日経ビジネス 2006年10月23日号の特集は、日本一○○を売るセールスマン・セールスウーマンの記事だった。この特集記事には10人以上の日本一が登場する。

セールス日本一の秘訣というか、共通の特長はあるか考えてみた。

ひと言で言えばお客さんの立場にたって何が求められているのかを自分なりに考え実践し、目的を達成するための努力を惜しまないということだろう。

ここで考えてみたいのは、セールスマン・セールスウーマンは顧客に直接対応するフロントエンドのパーソンで、ものづくりをしているメーカーから見た場合でも自分たちの商品をユーザーに売ってくれるという意味で彼らはフロントエンドだということだ。

セールスマン・セールスウーマンはメーカーと同系列の社員であるとは限らない。独立した販売店なら複数のメーカーの商品のうち、お客さんが求めていることを聞き出して「ピタッと」きている商品を勧める。

だから、メーカーは日本一のセールスマン・セールスウーマンに成り代わってユーザーが求めていることを調査・分析し、その要求にピタッときた商品を開発しなければいけない。

そうすれば、メーカーの系列ではない独立した販売店の店員も、自分たちの商品を紹介してくれる可能性が高まる。

この話は部品の供給者や、ソフトウェアの受託開発業者にとっては関係ないと切り捨てない方がいい。なぜなら、メーカーは部品やソフトウェアのサプライヤーに「顧客要求を満たすために必要な、安価で品質のよい部品、ソフトウェア」を求めており、それが何なのかを考えるにはエンドユーザーが何を欲しがっているかについて知っておいた方が絶対に有利だからだ。

そう考えると、トップセールスが顧客要求を正確に吸い上げているノウハウをメーカー、サプライヤーサイドのエンジニアが知ることは非常に大事だということが分かる。

<トップセールスが顧客要求を吸い上げるノウハウ>

  1. “お客さんの立場にたって”何が求められているのかを考える
  2. それを“自分なり”に考える
  3. 分析した顧客要求を“実践(実現)”する
  4. 目的を達成するための努力を惜しまない

一見、この4つはマーケティングの技術のようにも見えるが、必ずしも既成のマーケティングテクニックだけで実現できることではないように思える。

たとえば、1の「“お客さんの立場にたって”何が求められているのかを考える」は、顧客へのアンケート調査なので実現できそうな気がするが、トップセールスが実践している顧客要求の分析方法はそのような画一的なやり方ではない。

たとえば薄型テレビのトップセールスウーマンは若干20歳にして、メーカーの新製品展示会があると、休暇を潰してでも見学に行き、開発担当者を質問攻めにする。そして、新機能をリモコンで完全に操作できるようになるまで、展示機の前を離れない。そして、電化製品に詳しくない母親に説明して分かってもらえるかどうか確認する。そして、店頭でこの情報をお客さんに披露し、その反応を見ながら提供した情報がフィットしたかどうかをリサーチしフィードバックする。

2の「それを“自分なり”に考える」という部分は、他社よりもよりフィットしたユーザー要求を吸い上げて商品に反映させるという意味で重要である。ようするに人と同じような調査では他を出し抜くことはできない。ちなみに、このような外部環境を含めた経営戦略分析手法の一つに SWOT分析というのがある。

SWOTとは Strength(強み。内部環境・自社経営資源の強み)、Weakness(弱み。内部環境・自社経営資源の弱み)、Opportunity(機会。外部環境・競合・顧客などからのチャンス)、Threat(脅威。外部環境・競合・顧客からの脅威)の4つの要因の頭文字を会わせたもので、この4つの要因をマトリックスにして、分析する方法である。『通勤大学MBA1 マネジメント』(¥893)を参照されたし。

別の見方をすると日本のトップセールスは、MBAを取らなくても、顧客が何を求めているのかを分析する能力を自らの経験により身につけているということである。

ただし誰もがトップセールスのなれるくらいの分析能力を身につけられる訳ではない。そういう場合は、先人の知恵が体系化されているマーケティングの技術を知って自分の現場のテーラリングすることができれば、人が何十年もかかって蓄積した知恵を効率よく拝借することができるはずだ。

さて、次は3の「分析した顧客要求を“実践(実現)”する」だが、これは関わっている人間の数が少なければ少ないほどやりやすい。トップセールスは自分の中で閉じている環境を持っているので、顧客要求に応えるための戦略を実践しやすいと言えるだろう。

技術者の方はどうだろうか。メカ、エレ、ソフトの技術者がひとりずつといった小さいプロジェクトならば、分析した顧客要求の実践は自分の役割分担の中で実現させることができる。逐一誰かにコンセンサスを得ながら進める必要もない。しかし、プロジェクトの規模が大きくなってくると、プロジェクトマネージメントのテクニックを使わないと顧客要求の実践を効率よく適用させることは難しいだろう。

エンジニアもトップセールスマン・セールスウーマンの気分を味わいたい。トップセールスは顧客の要求にピタッとあった商品を選んだり、顧客が望んでいる使い方をサジェスチョンしたりするのだが、エンジニアは顧客の望んでいるものを作り上げることもできる。

ただ、トップセールスの場合は「分析した顧客要求を“実践(実現)”する」は成功すれば組織全体に利益をもたらし、失敗してもセールルマン・セールスウーマンの販売実績が伸びないという被害にしかならない。

ところが、エンジニアの場合はそうではない。「分析した顧客要求を“実践(実現)”する」が組織的にコンセンサスを得られていない状況で失敗した場合、その影響は個人の責任範囲では済まされない。

機能が足らない、期待した性能が出ていないといった顕在的価値が低いだけならまだしも、エンジニアがよかれと思ってやったことが安全性や信頼性を損ねるような結果になっていると、ユーザーに不利益をもたらし、リコールにより組織に経済的な損失をもたらす。

したがって、「分析した顧客要求を“実践(実現)”する」は技術者の場合は、組織的コンセンサスを得ながら進めていく必要がある。要求分析やユーザビリティの分析結果は、組織としてオーソライズされなければならない。

ただ、そのときにトップセールスが実践しているように、自分自身のオリジナルの分析を盛り込むことは可能だ。ユーザビリティの分析方法としてペルソナ法というのがある。ペルソナ法は、仮想の特定ユーザーを想定して、そのユーザーならこんな使い方をするだろうとか、こんな趣向があるのでこのような機能の提供のしかたが好まれるはずだといった分析をする。

トップセールスが「自分が考えるユーザー像」から、販売戦略を考えるように、ペルソナを想定するときに「自分が考えるユーザー像」を設定するのである。この2つの違いは、トップセールスの場合は自分だけの秘密にしておける可能性があるが、エンジニアの場合は自分だけの秘密にしてしまうと、失敗したときにユーザーに不利益をもたらすような組織的失敗に結びついてしまう危険があるという点である。

最後に、4の「目的を達成するための努力を惜しまない」については、トップセールスもエンジニアも同じだと思う。みんなと同じことをやっていて、競争力の高い商品やサービスを提供できる訳がない。

ただ、トップセールスの場合は個人の中で閉じた話になることが多いが、エンジニアの場合は目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者と、誰かが設計した仕様を忠実にコードの落とす者に分かれる。

どっちのサイドに行くのかはエンジニアの心づもりひとつだが、普通なら「目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者」と「誰かが設計した仕様を忠実にコードの落とす者」の間には評価に差が生じるはずだろう。

アメリカではエントリーしたばかりのプログラマとアーキテクトやアナリストとのサラリーの差は10倍以上もあると聞いたことがある。

日本の場合、ソフトウェアエンジニアの職種が明確でないこともあって「目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者」と「誰かが設計した仕様を忠実にコードの落とす者」の間に明確な評価の差がないことが多い。

そうなると、「誰かが設計した仕様を忠実にコードの落とす者」のサイドにいた方が楽だと考える技術者が増えても不思議ではない。

「目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者」が組織からルールに基づいた評価を得られる確証がないのなら、自分の努力が顧客満足につながるという方向に持って行くしかないだろう。

しかし、エンジニアの自己努力(多くの場合、オリジナリティを主張した努力)の成否の影響は、自分の中だけに閉じないため、大枠で組織のコンセンサスを得ながら進めていく必要があるのだ。

ここがトップセールスがある程度自分の裁量でいろいろなことができるのと違う部分だ。

したがって、組織はエンジニアの貢献度を客観的に評価するためのシステムを確立できていないのであれば、エンジニアが考えた顧客満足を達成するためのアイディアについて大枠でとらえてオーソライズしながら、ディテールについては権限を持たせて自由にやらせるということも必要ではないだろうか。

ただ、忘れてはいけないのは、顧客要求の中には設計品質の代表さえれるような潜在的価値の部分が含まれており、エンジニアが好き勝手にプログラミングしていたのでは決してソフトウェア品質を高めることはできず、潜在的価値を高めるという顧客要求を満たすことはできないということだ。

「エンジニアにある程度権限を持たせて自由にやらせる」を詳細に分解すると、次のようになる。

  1. 顕在的価値(カタログに載るような機能・性能)については自由度を広げる
  2. 顕在的価値(安全性や信頼性)については、顧客要求を満たすために1とは逆に自由度を制限する
2の自由度を制限するというのは「自由にやらせる」と背反しているように見えるが、組織が作ったルールをプロジェクト内である程度の自由度でカスタマイズしてもよいと考えれば完全否定にはならない。

トップセールスもトップエンジニアも顧客満足を高めたいという目標設定は同じでよい。しかし、エンジニア特にソフトウェアエンジニアの方は、以下の4点を進めるにあたり、エンジニア個人のオリジナリティを持って進めていい部分と、組織やプロジェクトのルールを満たしながら進める部分の両面がある分難易度が高い。
  1. “お客さんの立場にたって”何が求められているのかを考える
  2. それを“自分なり”に考える
  3. 分析した顧客要求を“実践(実現)”する
  4. 目的を達成するための努力を惜しまない
何はともあれ、日経ビジネス 2006年10月23日号の特集で各分野のトップセールスの戦略や努力を見ると「自分も顧客満足を高めるために頑張らねば」という気持ちにさせられる。

2006-10-22

シンドラーのエレベータ事故(つづき)

日経ものづくり 2006年10月号に シンドラーのエレベータの検証記事が掲載された。2006年6月,東京都港区のマンションで起きたエレベータでの事故の原因はまだ分かっていないが、日経ものづくりの記事ではエレベータの構造や安全装置のしくみなど、かなり深いところまで掘り下げておりいろいろと勉強になった。

特集 -事故は語る-「シンドラーの波紋」 記事の内訳】

Part 1 総論
相次ぐ事故に共通する課題
再発防止に三つの視点

Part2 安全装置の裏側
トビラが閉じずに動くカゴ
想定外の事態で表れた弱点

Part3 軽視された保守
自覚のなさが高めるリスク
業者間の責任分担を明確に

Part4 生かせぬ教訓
埋もれてしまう不具合情報
分析と公開が予防のカギ

【引用おわり】

自分が興味があるのは、エレベータの構造とハードウェアデバイス、そしてエレベータの詳細な要求仕様である。これらが分かればエレベータの制御ソフトウェアをどのように作ればいいかだいたい分かる。

組込み機器はユーザーとして使う立場に立てば、その機器の表に出ている制御仕様はだいたい分かる。ソフトウェアの価値である顕在的価値と潜在的価値のうち、顕在的価値の部分は、外に見えているところからその中身を予測できる。

しかし、組込み機器の潜在的価値を構成している「使いやすさ」や「安全性」「保守性」などの部分は、外側からではよく分からない。よく分からないのだが、「使いやすさ」「安全性」「保守性」に使われているハードウェアデバイスがシステムとどのように結合しているのかが分かると、ソフトウェアがどんな制御をしているのかもある程度想像できる。

今回、日経ものづくりの記事で再確認したのは、安全装置に関しては「かご側のトビラ確認スイッチ」「乗り場側のトビラ確認スイッチ」「モータ」「電磁ブレーキ」の関係がベースにあるということだ。

戸開走行しないための安全機能は、かご側のトビラと乗り場側のトビラが両方とも閉じているときのみ、電磁ブレーキを解除し、モータを回転させてよいということだ。

2006年6月の事故では、かご側のトビラと乗り場側のトビラが両方開いてるにも関わらず、電磁ブレーキが効かずにモータが回転してしまった。電磁ブレーキの摩耗の疑いがあるようだが、電磁ブレーキが摩耗していたとしても、それとは別に、トビラの開閉のセンシングを誤り、モータを積極的に回転させなければ事故は起こらないことから、どう考えても運転制御プログラムが怪しい。

そう考えていたら、ソフトウェアの不具合を誘発しそうな要因があることが今回の記事でわかった。それは、戸開走行の例外処理だ。

【戸開走行する例外処理も-「シンドラーの波紋」より引用-】

実は、安全制御装置にはトビラが開いた状態でも電源を投入するようにバイパスが設置されているときがある。それが、再床合わせ装置を持つエレベータの場合だ。

再床合わせとは、ロープの伸びなどによってカゴの床面と乗り場側トビラの床面に発生した段差を調整すること。乗り場の床とカゴの床に段差があった場合に、つまづいたりして危険だからだ。主に、ロープが長い高層エレベータや積載容量が大きいエレベータで採用される。

【引用おわり】

要するに、トビラが開いたときでも再床合わせゾーンの範囲内であれば電磁ブレーキを解除し、エレベータをゆっくりと走行させる。この際には、一種の戸開走行となる。ただし、この例外仕様の安全対策として、再床合わせゾーンを越えてドアゾーンを外れると安全装置がモータへの通電を遮断し、エレベータを制止する。

この再床合わせの戸開走行のソフトウェアは危険を伴う例外的な処理であり、他のソフトウェアに比べて、より慎重により正確に作り込まなければならない。

ここで組込みソフトエンジニアとして思うのは、安全面から考えたときのこの例外処理が他の処理より重要度が高いということを示すのは以外に難しいということだ。

安全装置がハードウェアデバイスとして、メインCPUの制御から独立している場合、その機能や役割は外から見えやすい。メインCPUとのインターフェースも明確であり、安全装置単体としてのテストもしやすい。しかし、安全をつかさどる制御ソフトウェアがその他のソフトウェアと一緒になってしまっていると、その重要性の高いソフトウェアをマーキングして「ここが装置の安全性を確保するためのソフトウェアですよ」と強調したくても、外からその重要性を分からせる方法がないのだ。

結局、ソースリストを追いかけることでしか問題があるのかないのか分からないということになりがちだ。

たとえば仮に、モータを制御する関数の中身が以下のようになっていたとしよう。

void driveMotor( 命令 )
{

  /* モータを止める処理 */
  if ( 命令 == STOP) {
    モータを止める;
    電磁ブレーキON;
  }

  /* モータを正転させる処理 */
  else if ( 命令 == UP ) {
    status = getCageStates();
    if ( status != open ) {
      電磁ブレーキを解除;
      モータを正転させる;
    }
  }

  /* モータを逆転させる処理 */
  else if ( 命令 == DOWN ) {
    status = getCageStates();
    if ( status != open ) {
      電磁ブレーキを解除;
      モータを逆転させる;
    }
  }
}

ようするに、モータを正転、逆転させるという処理に入ってから、ドアが開いていないかどうかをチェックしている。安全のための同じ処理が複数点在してしまっている。

一方、安全確認のソフトウェアはモータ処理とは独立させて監視させたり、モータ制御の関数を呼ぶ前にチェックをし、そのチェックがOKにならなければモータを制御させないという作り方もできる。

問題なのは、ソフトウェアの場合、目的を達成するための方法(プログラムの作り方)はいくつもあり、どのようなプログラミングをしているのかは、外からはよく見えないということだ。

上記のプログラミング構造に、戸開走行の例外処理を追加し、 "SLOWUP" や "SLOWDOWN" などの制御を追加し、付け足し付け足しでシステムを完成させたとしたらどうだろう。

関数の複雑性は増し、テストから漏れるパスが生まれる可能性も出てくる。

試行錯誤でソフトウェアシステムを作り上げる怖さはここにある。外見では同じように動くソフトウェアであっても、潜在的価値の低いソフトウェアはある。ソフトウェアエンジニアがそうしたいと思っていなくても、試行錯誤でソフトウェアを作り上げることで、なかなか到達しにくい部分に爆弾を作り込んでしまうことはあるのだ。

この危険は排除するために、メインCPU(制御プログラム)とは独立した、安全機能の装置を設ける方法はある。しかし、このような独立した安全装置は確実にコストアップにつながるので経済性を優先させようとした場合、取り除いてメインプログラムの中に入れればいいという判断になりやすい。

そうすると、安全機能は外から見えなくなり、キチンと機能しているかどうかわかりにくくなる。

日経ものづくりの記事では、制御装置のプログラムミスの可能性を示唆しているものの、どのようなミスの可能性があったかについては言及していない。国土交通省のエレベータワーキングチームでは、安全装置の独立化と安全制御プログラムに関しては第3者の専門家によって認証・確認する体制を構築することを提言しているらしいが、第3者の専門家による認証・確認というのはたぶん機能しないと思う。

なぜなら、第3者の専門家が安全性に関してお墨付きを与えるということはおそらくできないからだ。安全機能のためのソフトウェアの独立性や完全性は、同じCPUで動いている他のソフトウェアの影響を絶対に受けないという保証ができないだけに、どんなときでもキチンと動くということを証明するのは難しい。スレッド(タスク)を動的に生成しているシステムでメモリリークなどの影響を受けないことを保証することは非常に難しい。

不確定要素がある中で、第3者が安全性を保証することはできない。安全性の検証や妥当性確認は装置を組み上げてユーザーに提供するメーカが行うしかない。完成された部品をシステムに組み込む場合は、それがハードウェアであってもソフトウェアであってもその部品が仕様どおりに動くかどうかを検証することはできても、システムに組み込んだ後の安全性を保証することはできない。

実は、日経ものづくりの記事を読んだ後に感じたのは、「これだけ詳細な内容を記者はよく調べたなあ」という感想と「これだけ詳細な記事の中でソフトウェアについてはほとんど突っ込まれていない」という印象だ。

日経ものづくりは生産や機械設計といった話題が得意分野の雑誌だけに、ソフトウェアにメスを入れろということ自体ムリなのかもしれないが、分かったのはやっぱりソフトウェアは見えにくいということなのだ。探偵のようにエレベータを調べまくった記者もソフトウェアの中身までには切り込むことができない。この見えない世界の中で何が行われているのかは、ソフトウェアエンジニアしか知らない。

だから、ソフトウェアエンジニアが口を閉ざしてしまうと、ソースリストから問題の原因を探るしかない。事故が起こりやすいソフトウェアであればあるほど、構造が複雑であり問題を起こすカラクリを解きほぐすことが難しい。

安全をコントロールするソフトウェアの独立性を高め、その機能や性能の検証が容易になるようにしておかなければいけない。

そして、ソフトウェアモジュールを動かすベースである、オペレーティングシステムの検証は十分に行い、リスクがないことを確認しておく必要がある。

組込みソフトウェアの安全性を高めるための技術はある。それはなんだろうと思った方は『組込みソフトエンジニアを極める』の第4章-品質の壁を越える-を読んでいただければと思う。

以前書いた「シンドラーの事故を再発防止するためにエンジニアは何をすべきか」の記事も参照されたし。

2006-10-15

ここが変だよ日本の管理職

テレビ東京で毎週月曜日22:00から放映している「カンブリア宮殿」の2006年10月9日放送でソフトブレーン創業者の宋 文洲氏がゲストだった。

【宋 文洲さんのプロフィール-ソフトブレーンWEBサイトより-】

85年に北海道大学大学院に国費留学。天安門事件で帰国を断念し、札幌の会社に就職するが、すぐに倒産。学生時代に開発した土木解析ソフトの販売を始め、92年28歳の時にソフトブレーンを創業。経営を通して日本企業の非製造部門の非効率性を痛感した。
98年に営業など非製造部門の効率改善のためのソフト開発とコンサルティング事業を始めた。2000年12月に東証マザーズに上場。成人後に来日した外国人では初のケースとなる。 取締役会長 宋文洲
2004年経済界大賞・青年経営者賞を受賞。2005年6月1日には東証1部上場を果たし、業界最大手に成長。
営業改革を訴えた著書「やっぱり変だよ日本の営業」は、トヨタ自動車の張富士夫社長(当時)自身が購入し、営業系の役員を中心に配布。12万部に迫るベストセラー&ロングセラーに。
2006年、企業情報化協会・特別表彰を受賞。

【引用終わり】

宋さんは、自分が感じた日本の組織運営の変なところをズバズバと切る。言われてみればごもっともなことを遠慮せずにピシッと言ってくれるので、組織的問題で悩んでいる人にとっては小気味いい。逆に日本的な組織運営にどっぷり浸かっている人には耳が痛いだろう。

宋さんの本は『 やっぱり変だよ日本の営業―競争力回復への提案』の方が売れているようだが、自分は営業職ではないので、『ここが変だよ日本の管理職』の方を買って読んでみた。

【第2章 ここが変だよ 赤信号をみんなで渡る日本の管理職 より引用】

*-馴れ合い、もたれ合い

 儲からない会社には、いくつかの共通点があります。その一つは、間違っていることをはっきりさせないことです。
 たとえば、儲かっていない会社ですから、社内には儲かっていない部署が必ずある。そうしたら、その部署が儲かっていない原因をきちんと分析して、将来的にも厳しいようなら、その事業については撤退するなり手を打たなければならないはずです。でも、そんなことを言い出す管理職の人は、あまり見かけません。
 あるいは大きなミスをした人間がいる。でも、「この人がミスをしました」とは誰も言い出さない。しばらくしてから、「こんなことが起こりました。みなさん気をつけましょう」となるだけです。
 どうして、儲かっていない部署をどうすべきかと、はっきりさせないのでしょう。○○さんがこんなミスをしましたと、はっきり言わないのでしょう。自分の会社に責任を持たなければならない管理職の人たちが、なぜ口をつぐんでしまうのでしょう。
 少なくとも、他の部署や他の人の揚げ足を取り、個人攻撃をしようとしているわけではないのですがから、はっきり言わないのは変です。
 日本人のメンタリティーとして、表だって自分が何かについて批判するようなことが、精神的に堪えられないということもあるようです。そんなことをして、「あいつは他人のあら探しばかりするイヤなヤツだ」というレッテルを貼られるのが恐いのです。
 もっと言えば、自分たちの“ムラ社会”に波風を立てることによって、今度は自分が疎外されるのを恐れるからなのでしょう。
 私は、日本人の特性と言うよりは、お互いに信頼感が持てないことが、他人に対してズバッとものが言えない習性をつくり出す、大きな要因になっているのではないかと思っています。そのため、はっきりさせないほうが自分も安全なところにいられると考えてしまうのです。

【引用終わり】

ソフトウェア品質シンポジウムで大場充先生も言っていたが、日本人のエンジニアはソフトウェアレビューの際に確実に間違っているところしか指摘しない、「ここはこうした方がいい」というところも言えるようにならないとレビューにならない。それは宋さんが言うように「あいつは他人のあら探しばかりするイヤなヤツだ」というレッテルを貼られるのが恐いという心理だろう。

その根幹には「ISO9000やCMMIに違和感を感じませんか?」の記事でも書いたように、子供の頃から日本では「あたたかい人間関係の中のやさしい一員」という教育を受けているという事実があると思われる。米国の「創造性と個性にあふれた強い個人」の教育とは対照的だ。

【第2章 ここが変だよ 赤信号をみんなで渡る日本の管理職 より引用】

*-みんなが後出しジャンケンをする組織

 モラルの問題だけでなく、個人、自己が弱いと困ることがたくさんあります。たとえば、そういう人たちには“群れたがる”傾向があることもその一つです。
 どういうことかと言うと、お互いに傷つけ合わない者同士でないと安心できないために、同じような感覚の人で集まりたがるのです。
 つまり、「オレはお前の悪口は言わない。その代わりお前もオレの悪口を言うなよ」と暗黙のうちに目で語り合う。そして、「オレたちの悪口を言うヤツは、仲間には入れるな」とも。

【引用終わり】

後出しジャンケンとまで言わなくても、「お前の責任だ」と言われないために、何の意見も言わずに黙っている者が技術者にも管理職のもいる。

【第5章 まだまだ変だよ 不合理がいっぱいの日本の会社の人事評価 より引用】

*-成功した旗の舌には百人が集まる

 「成功した旗の下には百人が集まる。敗れた戦場には一人も残らない」-ちょうっとうろ覚えで恐縮ですが、ある実力派の社長さんから伺った言葉です。
 人間心理からすれば当然の働きかもしれませんが、日本の会社ではとくに目立つパターンだと感じるのは私だけでしょうか。
 集団主義にどっぷり浸かり、組織から排除されないように、後出しジャンケンでしか意思表明しない人が多いと、当然そんな現象が顕著に表れます。
 たとえば、新しいプロジェクトに挑戦しようという時には、どこの会社でも、何回もブレーンストーミングや会議を重ねることになるでしょう。そんな際に、出席者の多くが必ず口にする言葉があります。
 「よいアイディアだとは思うんだ・・・」というのと、「大丈夫かい。リスクはないの・・・」です。この二つの意味を含んだ内容の発言が、折りに触れていろんな人の口から発せられます。
 大丈夫かどうかなんてわかったら、誰も心配しません。進めながら大丈夫なように処理していくのですし、リスクのないような仕事を誰がよろこんでするのでしょう。
 でも、そのひと言が“保険”のようなもので、後々それが効いてくるのです。
 つまり、たまたまプロジェクトが成功したとします。すると、「ほら、オレが言ったとおりだろ。成功するアイデアだと思ったんだ」とみんなが口にします。なかには、「ほら、オレが言ったように、リスクに気をつけたから上手くいったんだ」なんて言う人もいます。
 一方、不幸にしてよい結果につながらない場合には、「ほら、だからオレがリスクがあるから危ないって言っただろ」となるのです。
 これも全部、後出しジャンケンです。
 要は結果がすべてで、どんなふうにプロジェクトが進行したかなんて、誰も関心がないんです。これでは成功のノウハウが蓄積されるなどということは、絶対にありません。

【引用終わり】

宋さんの言うように、失敗を恐れていたり、失敗したプロジェクトを振り返って、プロセスを見直すことから逃げることしか考えない管理職は多いように思う。これは「あたたかい人間関係の中のやさしい一員」の悪い側面に他ならない。「あたたかい人間関係の中のやさしい一員」は、うまくベクトルが一つになって、それぞれが犠牲をいとわず目標を達成する気持ちになったときは強いが、プロジェクトが成功しそうになく、一人一人が保身を考えるようになるととたんに弱くなる。

【第6章 こうしていこうよ 新しい日本の会社 より引用】

*-顧客価値を決めるのは管理職

 このように、日本の会社にとどまらず日本の社会にも好影響を与えることが期待できるプロセスマネジメントですが、その中核となる「顧客価値の決定」というのは、非常に重要な仕事だということがわかっていただけると思います。
 この重要な仕事を担うのが、基本的には経営者と管理職ということになります。
 顧客価値を決めるには、徹底的にお客さんを知る力が必要です。それが身についておらずに、間違ったプロセスを設計してしまうと、その影響は計り知れません。大変なことになります。
 今までも、経営者や管理職の多くは、自分たちがやっていることはみんなお客さんのためだと思い込んでいます。実はこれが独善で、顧客価値など考えていないことが多いのです。
 「徹底的にお客さんのことを知る力を身につける」というのも、口で言うのは簡単ですが、そんなにたやすいことではありません。
 これは、理屈ではないと思います。どういうことかというと、個人の自立なんです。
 この本では、日本の会社やそこで働く人たちの現実を見て、変なことだらけだと言い続けてきました。欧米の人も中国の人も日本の人も、みんな少しずつ見た目は違っているだけで同じ人間なのですが、日本の人を見ていると実はかなり違和感を感じる部分があるのです。その一番の原因はそれぞれが自立できていないということだと思います。
 サラリーマンになって、一生同じ会社しか経験しないのが当たり前。その会社を辞めたらもうやっていけないと思い込んでいるとか、日本の管理職の人たちの価値観はとても単純です。
 それというのも、学校を卒業して大きな会社に入ったら、かなりの額の給料が約束されます。そうなると、その会社から離れることを考えないようになりますし、お酒を飲むのも全部会社の仲間、先輩、後輩。言ってみれば、一つの会社しか経験しないために、その会社で通じる理屈しか知りません。
 そんな人間に、徹底的にお客さんのことを知らなければならないと言っても、ムリな話なんです。これは、極論ですが、狼と一緒に育った子は、いくら頑張ったって人間のことがわからないのです。
 人間としていろいろな価値観があることを知った上で、消費者の視点をちゃんと持った人間との交流を持たなければいけません。
 そのためには、やっぱり経験を積むしかありません。自分自身がきちんと自立した消費者になることです。

【引用終わり】

自立していない者ほど「こんな会社辞めてやる」と言いながら絶対に辞めずに何とかしてすがりつこうとする。

【第7章 プロセスマネジメント 導入・実践のために より引用】

*-意識改革は「気づき」から

 これまでの日本企業は、精神主義と結果主義を根幹に据えたマネジメントを行ってきたと、私は見ています。この二つのがんじがらめになった日本企業のマネジメントをガラリと意識改革するのが、私自身の仕事でもあり、私の会社の主要業務となっています。意識改革をもたらすために、私たちが実際に行っている手法についてお話ししましょう。
 まず、部長と支店長クラスを集めて、私が社内講演会を一回やります。講演のテーマは「どうしたらマネージャはラクになれるか」です。
 日本のみなさんは、ラクになることに罪悪感があって、「どうしたら頑張れるか」しか語ろうとしませんが、私は「どうしたらラクになれるか」という話しかしません。
 ここが重要です。従来の意識改革の手法は、「もっと頑張れ」でした。私は逆です。「頑張らないでください。それでもあたなの方にメリットのある仕組みがあります。それをやりませんか」とお話しするのです。つまり、仕事をラクにするために発想を変えることを提案し、結果主義からプロセスマネジメントへの転換を促すわけです。
 同じ頑張りならば、もっとインセンティブや給料を増やすような方法、給料を増やせないのなら早く家に帰ってラクになる方法を考えたほうがいいに決まっています。
 こうしたことについて具体論で話し合うと、「そういえばそうだね」「やってみようか」となります。
 「気づき」です。自分で気づき、自分で変えようと思わせることが、意識改革のポイントなのです。

【引用終わり】

宋さんがこの本で一貫して主張しているのが効率のよいマネジメントをしましょうということだと思う。これまで日本の技術者は技術のことだけ考えていればよかったのだか、開発するソフトウェアの規模が増大し、プロジェクトメンバーの数も増えてくると、技術のことだけでなくマネジメントのことを考えないとプロジェクトが成功しない世界に入ってきた。

宋さんは日本は工場のプロセスマネジメントは世界一なのに、ホワイトカラーの効率性が非常に低いと指摘している。この非効率なマネジメントの手法が、ソフトウェアプロジェクトのマネジメントにも影響を及ぼしている。

ただ、この状況に気付いたとしても、プロジェクトメンバーの意識改革を行うのはそう簡単ではない。宋さんのようにトップの地位にいたなら、いろいろな指示が可能だが、絶対的な権限を持たない状況でプロジェクトの意識改革を行うには、それ相当のエネルギーがいる。

自分は、そのエネルギー源は「顧客満足を高めるために必要である」という意識だと思う。「顧客満足を高めるため」というコンセプトの対して反対する経営者はいないし、エンジニアにしても「顧客満足を高めること」に後ろ向きなことを言うのはイヤだからである。

今の日本の組織で一番恐いのは外から見ると「ここが変」というところが、組織の中にどっぷり浸かっていると「お前の言っていることの方が変だ」と思ってしまうことだと思う。

2006-10-09

本当にマルチコアがいいんですか?

日経エレクトロニクス2006年10月9日号 に 『マルチコアが変えるソフトウェア開発』というタイトルの特別企画が載るらしい。Tech-On! の日経エレクトロニクスのサイトで、その概要を見た。

Tech-On! の記事をずっとウォッチしていると、マルチコアプロセッサの話題が目に付く。マルチコアプロセッサの記事を見るたびに自分はしっくりこない何かを感じる。

こういう「何かしっくりこない感じ」がわき出るときは必ず理由がある。これまで記憶した数々の経験や知見から構築された脳内のネットワークに刺激が与えられたときにこのような感覚はアウトプットされる。

自分の場合は最初に感覚がきて、あとからその感覚を説明する論理はなんだろうかと理由付けすることがよくある。「何かしっくりこない感じ」の論理がはっきり分からないと、もやもやした感覚だけが残り気持ち悪い。

そこで、マルチコアプロセッサの話題がなぜ自分にとって「しっくりこないのか」よく考えてみることにした。

たぶん、もやもやする最大の原因は、プロセッサをマルチにしようというのはプロセッサメーカーの都合であり、プロセッサのユーザーがプロセッサの内部をマルチにして欲しいと切望しているわけではないからだではないかと思う。単純にプロセッサがマルチになっていると、アーキテクトとしてはどのプロセッサになんのタスクを割り当てたらよいのか悩むことになる。もしかすると、その割り当ての技術がアーキテクトとしての腕の見せ所になるのかもしれないが、考えなくてもいいのなら余計なことは考えたくない。

最近マルチプロセッサが話題になっているのは、これまでシングルプロセッサでCPUの性能を上げてきたCPUメーカーが、これ以上CPUの性能を上げながら低消費電力を実現するのが難しくなってきたからだと聞いている。消費電力を押さえながらCPUの性能を高めるための技術的ブレークスルーがCPUコアのマルチ化だというのだ。ようするに、これまでのCPUアーキテクチャではこれ以上の進歩は望めないので、CPUコアをシングルからマルチにして負荷を分散させようというのだ。

しかし、組込みアーキテクトから言わせてもらえば、それはCPUの作り手側の都合であり、我々の切なる要求というわけではない。ちなみに、自分のプライベートPCのCPUは Intel の Pentium Dプロセッサで、デュアルコアプロセッサだが、たぶん、Windows アプリケーションのプログラマは、デュアルコアプロセッサの特性を活かしたアプリケーションソフトを作ってはいないと思う。

CPUがシングルかマルチなのかを気にしているとしたら、Windwos XP のOSだろう。どこかのWEBサイトで、Pentium Dプロセッサを使うのなら、XP Personal ではなく、XP Peofessonal にした方がパフォーマンスが上がる場合があると書いてあるのを見た記憶がある。

ようするに、デュアルコアプロセッサの特長を活かしているのはOSであって、アプリケーションソフトではない。もしかすると、OSもシングルコアかデュアルコアか気にしなくてもいいように、CPU側がくふうしてくれている可能性もある。

組込みの方もそういう考え方で、アプリケーションエンジニアやアーキテクトがCPUがシングルであったり、マルチであることを気にしなくていいのなら、「何かしっくりこない感じ」はしないはずだ。

ところが、日経エレクトロニクス2006年10月9日号 に『マルチコアが変えるソフトウェア開発』には、次のようなことが書いてあるらしい。

【<事例編>マルチコアに向けたソフト開発の現場から】

並列処理を意識したソフトウェア開発にとってマルチコア型マイクロプロセッサの性能を引き出した例が民生機器で登場しつつある。事例から見えてきたのは、ソフトウェア開発者がスレッドの粒度や同期の在り方にまで気を配ることの大切さである。

【引用終わり】

モデル駆動開発の用語でPIM(Platform Independent Model)と、PSM(Platform Specific Model) という言葉がある。

PIM(Platform Independent Model)はプラットフォームから独立したプラットフォームに依存しないモデルで、PSMはプラットフォームに依存したモデルを意味する。

PIMはプラットフォームから独立しているので、プラットフォームが変化してもモデル自体が変わらない、だから寿命が長い。モデル駆動開発では、ユーザー要求をプラットフォームに依存しないPIMとして記述し、プラットフォームに依存する実際に実装するためのPSMはツールを使ってモデル変換できるようにしようと考えている。

実は、自分はこのモデル駆動開発の支持者ではない。モデル駆動開発がうまくいってしまうと、組込みアーキテクトが職を失ってしまうという危機感もあるが、それ以上に組込みの場合、ユーザー要求を最適化することがツールで簡単にできるとは思えないからだ。

しかし、だからといって、PIM(Platform Independent Model)が重要でないとは言わない。PIMを目指す重要性は十分分かっている。プラットフォームに依存したモデルばかり設計していると、ハードウェアやプラットフォームの変更があるたびにソフトウェアを修正しなければいけない。それは効率的でないし、ソフトウェアエンジニアの首を絞めることにつながる。

だから『組込みソフトエンジニアを極める』では、ユーザー要求を性能的な面で実現させる PSM的ボトムアップの視点と、ユーザー要求を機能的な面で実現させる PIM的トップダウンの視点の両方の視点を持つことだ大事だと書いた。

ここで、PSM的ボトムアップの視点を考慮すると言っているのは、製品の機能や性能を実現するためのキーデバイスの特性を考慮することを想定しているのであって、CPUアーキテクチャを考慮することが重要だと言っているのではない。

CPUが変更されたとしても、できるだけアプリケーションソフトウェアは変更しないでよい作りになっていた方がよいと考えている。

なぜなら、CPUは製品の価値を実現するための直接的なデバイスではないと思うからだ。CPUの機能や性能は製品の価値を高めるために間接的に関与するが、パフォーマンスや消費電力などを満たすことができるならばなんでもいい。

T-Engine ではアプリケーションソフトは 明確にCPUから Independent であることを目指している。

そう考えると、 “マルチコア型マイクロプロセッサの事例から見えてきたのは、ソフトウェア開発者がスレッドの粒度や同期の在り方にまで気を配ることの大切さである。” は、PIM を目指そうと考えるソフトウェアエンジニアから見ると PIMからPSMへ逆戻りしているように見える。

マルチコアでもCPU+DSPのような組み合わせは、それほど「もやもや」しない。なぜなら、DSP(Digital Signal Processor)は画像の圧縮・伸張や、デジタルフィルタなどの信号処理に適しており、CPUの役割とは異なり処理を分離することがユーザーの直接的な利益につながるように思えるからである。

そう考えると、同じCPUコアを複数搭載し、どちらのCPUコアにどのタスクを割り当てるべきかを考えるのは、組込みアーキテクトにとって余計な作業であり、どんなに上手に割り当てを行ってもユーザーに直接的なメリットをもたらすように思えないのだ。

たとえば優先度の高いタスクをデュアルコアの片方のCPUに割り当てるという方法はある。でも、よく考えて欲しい。それは組込みソフトエンジニアから見れば、リアルタイムOSを使ってタスクを分割し、タスクの優先度変えることで、限られたCPUパフォーマンスを最適化してきたのと何ら変わりないように見える。

リアルタイムOSでタスクの優先度を変えるのは簡単だが、デュアルコアでCPUに対してのタスクの割り当てを変えるのは簡単ではないように思う。さらにデバッグのことを考えると頭が痛い。CPUが分かれていると同期を取りながらデバッグするのはとても難しいだろう。シングルチップなら、突き詰めれば処理はシーケンシャルなのでなんとかデバッグもできる。

だから、マルチコアプロセッサを選択しようとしている方達にタイトルのような「本当にマルチコアがいいんですか?」という質問をしたいのだ。

一番危ないのは、アプリケーションやシステムの構造がどんなに無駄な動きをしていてもCPUの性能をどんどん高くしていけば、製品の機能性や性能をカバーできてしまうと考えてしまうことだろう。

ソフトウェアは見えにくいだけに、アーキテクチャの悪さが外からは見えないことも多い。シングルコアとRTOSの使い方のくふうで十分にユーザー要求を満たすべく、機能・性能を最適化できるにもかかわらず、CPUの性能を上げることで強引に解決してしまおうと考えるのは、本質的な問題に蓋をして表面的なくふうでその場をしのごうとしているようにも思える。リアルタイムアーキテクチャーを実現するための道具としてのリアルタイムOSも十分に使いこなせていないのに、安易にマルチコアプロセッサという解決策へ逃げているように見えるのだ。

また、「何かしっくりこない感じ」の原因は、作り手側の都合が先行していて、ユーザーへの価値を最大にするという考えに基づいていないように思えるからかもしれない。

もしも、デュアルコアプロセッサで成功しているプロジェクトがあるのなら、それはデュアルコアであることを製品の価値を高めることに結びつけることに成功しているからに違いない。ようするに、その製品はデュアルコアプロセッサを使う必然性がある筈なのだ。

だから、必然性もないのに最近の流行だからといってデュアルコアプロセッサを選択するのは危険なにおいがする。

2006-10-01

バッテリーは大きなエネルギーを内在している

ソニーエナジー・デバイス製のリチウムイオンバッテリの回収が話題になっている。回収の規模は200億円、バッテリの数は590万個にも上るそうだ。

2006年6月に大阪で開催された Dell laptop explodes at Japanese conference で、会議中に突如 Dell 製のノート・パソコンが発火、炎上したとのこと。

この事故が今回の回収につながった。パソコン関係のリコールというと、「メーカから交換の連絡を待っていればいいかな」という軽い気持ちで受け止めていたが、写真のように発火する可能性があるとなると、対象機種のユーザーなら、さすがに心穏やかにはしていられないだろう。

海外の航空会社では飛行機の中ではノートパソコンはバッテリでの使用を禁じており、バッテリなしのAC電源で使用できない場合はノートパソコンは使えないようにしているところもあるらしい。

なぜ、バッテリが燃えるのかについて、日経エレクトロニクス 2006年9月11日号の「視点焦点」の記事に書いてあった。その内容をもとになぜバッテリが発火するのかについて考えてみたい。

まず、電池がなぜ電気を貯めておけるのかについて考えてみよう。

銅と亜鉛を電解液となる希硫酸や食塩水などに入れると、銅は原子がほとんど溶けず反対に亜鉛は原子が溶け出して電子が出る。そして、銅と亜鉛をつなぐと銅から亜鉛に電気が流れる。これがボルタの電池の基本だ。

要するに正極と負極を二つに分け、この二つの極の間を電荷を付帯したイオンが移動することで電流が流れる。リチウムイオン電池の場合はLi+イオンが正極と負極の間を行き来する。

バッテリが蓄えられる電力が大きければ大きいほど正極に蓄えられるLi+イオンが多いということになる。ノートパソコンが低消費電力になったとはいえ、6時間も8時間も連続で使用できるようになったということは、リチウムイオン電池やニッケル水素電池の蓄電量は非常に大きいということだ。

だから、リチウムイオン電池やニッケル水素電池の正極と負極を電気的な負荷なしに短絡させたりするととんでもないことになる。爆発するかもしれない。

だから、このような大容量のバッテリではショートしたときのための不可逆的なヒューズや発生したガスを逃がすための安全弁が用意されている。

ではこのような安全装置が施されているにもかかわらずバッテリが燃えてしまうのはなぜか。

【バッテリが発火するメカニズム】

1. 電池セルの製造工程で微少な金属粉がセルに混入する。
2. 金属粉が正極部に付着する。
3. 充放電を繰り返す。
4. 正極に付着した金属粉が金属イオンを放出する。
5. 金属イオンが樹枝状に析出し、正極と負極を隔てているセパレータを破り両極を短絡する。
6. 短絡による電流漏洩でセル内部の温度が上昇する。
7. 200℃ほどで正極材料の結晶が崩壊して酸素放出し、さらに熱を発する。(熱暴走)
8. セルの内圧が一気に高まり可燃物である電解液が気化して安全弁から放出され発火に至る。

このような内部短絡にはセル外部に搭載したヒューズや温度管理用のサーミスタは何も意味をなさない。内部が短絡しているから、ヒューズで電流の流れを切っても内部の短絡から電流は流れてしまうのだ。

したがって、製造工程での金属片の混入はもっとも注意を払わなければいけないらしい。金属片の混入の可能性としては、製造ラインを循環する空気の洗浄が不十分であるということも考えられるそうだ。

ただ、金属粉が原因で短絡しても、150℃前後でセパレータが溶解してLiイオンが通過する穴がふさがり、科学反応が止まる仕組みになっているので、金属粉の混入だけが原因ではなく、いくつかの製造工程上のミスが重なったのではないかと予想されている。

リチウムイオン電池やニッケル水素電池は取り扱いに注意しなければいけないということは、ずいぶん前から知っていた。かつてリチウムイオン電池を使った製品のバッテリ充電のソフトウェアの状態遷移について分析したことがあるからだ。

リチウムイオン電池やニッケル水素電池の取扱説明書にはおびただしい数の警告文が書かれている。バッテリを火の中に投入したり、五寸釘で打ち抜いたりしては絶対にいけない。

今回のリチウムイオン電池の事故でよく考えなければいけないのは、大きなエネルギーを持つデバイスはどんなに安全装置を施しても危険が近くにあるということだ。

組込み機器メーカーやデバイスメーカーは危険が表面にでないように幾重にも安全装置を施すので、ユーザー側はそんなリスクをまったく感じることなく機器を日常的に使用している。だからこそ、日常的ではない何かがあったときに危ないのだ。

身の回りにある機器が危ないか危なくないかは人を傷つけるほどのエネルギーを制御するものかどうかで判断できる。

たとえば、車、電車などはもちろんだが、エレベータや自動ドアだって大きなエネルギーを制御する。車や電車がなく、徒歩で目的地まで行ったらどれだけエネルギーを消費するかわかる。エレベータを使わず8階まで階段で上がったら、どれだけの位置エネルギーをエレベータが肩代わりしてくれているのかがわかる。バッテリは一見たいしたエネルギーを持っていそうにもないが、ノートパソコンを連続で8時間動かすエネルギーを一気に放出するような場合は傷害を起こしうる。

逆に言えば、単4電池2本くらいで動いている電子機器は人を傷つけるほどのエネルギーをもともと持っていないので、どんな故障の仕方をしても安全性は高いと言える。

AC電源は大きな電流を取り出すことができるので、AC電源から電流を取り出す電子機器の電源の安全性は非常に高いものが要求されている。

組込みソフトはハードウェアデバイスをコントロールすることができるため、設計の仕方によっては巨大なエネルギーの制御を誤り人を傷つけるような事故を起こしかねない。

組込みソフトエンジニアは、自分が関わっている組込み機器が扱うエネルギーの大きさに注意を払い、取り扱うエネルギーが大きければ大きいほど、慎重にソフトウェアを設計し、ハードウェアデバイスを制御し、検証や妥当性確認を納得がいくまで実施しなければならない。

今回のバッテリ事故は、ソフトウェアが絡んだ事故ではないが、AC電源につながれていない機器でも大きなエネルギー源を抱えていて危険と隣り合わせにあることがわかったと思う。

世の中がネットワークでどんどんつながれていくと、大きなエネルギーを制御するソフトウェアと、たいしたエネルギーも制御しないソフトウェアが通信するようになり、何かの間違いで大きなエネルギーを制御するソフトウェアの中に眠っていたバグを呼び覚まし、大きな事故を起こすような事態が起こるかもしれない。

ユビキタスの時代になると、組込みソフトエンジニアは自分のプロダクトだけでなく、自分のプロダクトが通信によって流す情報にも責任を持つ必要がでてくる。

高密度のバッテリ開発など世の中が便利になればなるほど、そのような利便性とは対照的に組込み機器を取り巻く環境の危険度は増し、逆に安全に対する要求は高くなるのだ。バッテリの事故は対岸の火事ではない。