2009-01-24

ソフトウェア資産の価値を可視化すべし

ソフトウェア開発の効率化、高品質化がなかなか進まない。なかなか進まないと言っているのは、普通はどんな組織でも何か問題が起これば特に何らかの手法を使わなくても緩やかではあるが改善の方向に進むのだが、ことソフトウェアの開発では放っておいてもいっこうによくならない、よくならないどころか放っておくと悪い方向に向かってしまうということだ。そこには、メカやエレキの世界にはないソフトウェアだけの問題というのがありそうなような気がする。

メカ(機械設計)、エレキ(アナログ、デジタルを含む電気設計)、ソフト(ソフトウェア設計)の3つを比べたとき、開発の効率化、高品質化がやりやすいのは、メカ>エレキ>ソフトの順番ではないかと思う。

たぶん、その理由は各設計ドメインにおける開発の成果が見えやすいか否かの違いだろう。メカはできあがったものを見て動かしてみればできの善し悪しを判断できる。評価はできあがったものをみんなで触ってみればいいし、うまくできたら上司に「動かしてみますので見てください」と言えばいい。ソフトウェアの場合、上司に「いい関数ができたので見てください」と言っても明確かつ一般的な評価指標がないから面倒くさいと言われるだけだ。(共通の価値を見いだすのが難しい)

エレキはそもそも完成された部品を組み合わて回路を構成するため部品単位の検証を行う必要はない。また、ブロック図や回路図といった抽象化されたモデルが必ず存在し、さらに、部品が実装されたプリント基板をまじまじと眺めることができる。

それに比べてソフトウェアはどうだろうか。「いやー、この間の開発で作った○○モジュール、あれはいい仕事だったね」とか「△△のソフトウェアはライバル会社の××のよりも数段性能が高かった」などという会話を聞いたことがあるだろうか。そんなのエレキでも同じだと言うかもしれないが、エレキの場合物理的な実装プリント基板がある。電気屋さんは発注したプリント基板が上がってきたとき、そのプリント基板に部品を実装して正常に動作したとき、喜びを感じることができるし、同僚とも喜びを分かち合えるし、上司に「できました」と物を持って報告にいける。

ソフトウェアの場合は同じことができるのは、ソフトウェアが製品に実装されたときだけだ。そこに大きな問題がある。ソフトウェア部品、ソフトウェアサブシステムが完成したとき、喜びをかみしめることができるのはごく少数の技術者であり、完成したと思ったサブシステムもさみだれ式に変更を繰り返していたのでは完成したという区切りが見えないので「終わった」という感覚がない。だから、組込みソフトウェアエンジニアはソフトウェアが製品に実装されたときにしか周りの人たちに評価されないという問題がある。ソフトウェアの部品単位で評価されることはないから、ソフトウェア部品の作りかたやソフトウェア部品の品質がいいとか悪いなどと評価される機会は残念ながらほとんどない。

ビジネス系のパッケージソフトウェアならばソフトウェア部品であったとしても、ソフトウェア部品としての売り上げで、そのソフトウェアの価値を推し量ることができる。ところが組込みソフトの場合はメカ、エレキ、ソフトが一体となって出荷されるために、もし商品がヒットしても、売り上げに貢献したのがメカなのか、エレキなのか、ソフトなのか分かりにくい。

メカやエレキは性能を計測するこができるから評価する指標を作りやすい。ソフトウェアの場合はどうか。「この製品は1000行あたりのバグが少ないんです」などとハードウェア出身の上司に言おうものなら「バグはゼロにして出荷しろ」と言われるだけだ。「いや、そうじゃなくて」としゃべり始めたときには上司はもう向こうに歩き始めているだろう。

要するに組込みソフトウェアの場合、プラスの価値を表現するのが難しいのだ。パッケージソフトウェアの場合と同様に、ソフトウェア部品を売る会社は、そのソフトウェア部品の売り上げで価値を評価することができるが、実はここにも問題がある。

エレキの場合、部品の検証は相当厳しく実施され、検証が十分に終わらないと出荷はしない。なぜなら、電気部品に不具合があって、その部品を使って商品を作成し、電気部品の不具合が原因でユーザーが被害を被った場合、部品メーカーはそれ相当の責任を負うことになる。エレキの場合、どの部品が不具合の原因かは正確に分かるし、不具合の状況を部品メーカーに突き付けることもできる。問題が起こったら部品メーカーは逃れようがないのだ。だからこそ、エレキの部品メーカーはリリースする部品が完全であることを確認して出荷する。電気部品の場合、検証に必要なテストケースは有限な場合が多い。その有限のテストケースをパスすれば、後は生産の問題に引き継げる。

ただ、エレキの世界でもワンチップマイコンのように、いろいろなデバイスをパッケージした製品を作ると、検証に必要なテストケースは爆発するようになり、すべてのケースをテストするのは不可能になる。だから、まれにワンチップマイコンにはバグが報告される。実際にはバグとは言わず、機能制限ということばで説明され、「これこれ、こういう使い方はしないでください」という注意書がデータブックなどの説明書に書かれる。これを見落とした場合の責任はデバイスを使う側にある。

さて、それでは市販されているソフトウェア部品を使う場合、そのソフトウェア部品はエレキの部品と同じように完全に検証され、不具合はないと言えるだろうか。その答えが NO であることは、組込みソフトウェア開発をやったことがある技術者ならすぐわかるだろう。実際、市販ソフトウェアに瑕疵(不具合)があったら賠償を請求できるだろうか。それは多くの場合できないし、そもそもバグがゼロだなんでだれも思っていないから賠償請求もしない。市販ソフトウェアは部品単体で完成度を表すことは難しいし、そこに問題がないことを証明するのは市販ソフトウェアを製品に組み込む側の責任であるという認識であることが多い。

そう考えると市販ソフトウェアのように明確に部品化されたソフトウェアであっても、そのソフトウェア部品が正しく動くということは部品メーカーサイドは保証することはできないので、そのソフトウェア部品が仕様どおりに動くという当たり前品質における価値は確定することがほとんどできない。ソフトウェア部品の場合、完成を確定することができないので、市販されるソフトウェア部品であってもその価値を確定することが難しいのだ。

ソフトウェアは簡単に変更できてしまうので、ソフトウェア部品のメーカーは出荷したソフトウェアに問題が発覚するとその情報を保守契約している使用者に流し、バージョンアップしたソフトウェア部品を配布する。でも、その市販ソフトウェアを使った製品を出荷してしまったメーカーはいったいどうすればいいのか。それは、その問題がユーザーにリスクを与え、そのリスクが許容できないと判断された場合は、製品のソフトウェアをバージョンアップし、場合によってはリコールするしかない。

ソフトウェア部品の価値の議論にもどると、このようにソフトウェアは当たり前にできているべきことが出来ていないときに負の評価が表面化する。負の評価の評価指標はソフトウェアの作り直しの費用や、ユーザーに対する弁済の費用だ。リコールにかかった費用がもっとも分かりやすい。ソフトウェアが原因でリコールしたら、そのリコールの費用がソフトウェアの負の価値として組織内外を駆け巡ることになる。

そこで、今回の記事のタイトル「ソフトウェア資産の価値を可視化すべし」となる。もちろん、可視化するのはソフトウェア資産のプラスの部分だ。

エレキの場合、性能を評価することがしやすいと書いたが、コストダウンも評価しやすい。同じ性能を安く実現できた場合、コストダウンぶんは直接利益になるからだ。

ソフトウェアの場合もエレキと同じような作戦でソフトウェア資産の価値を可視化する作戦を考えた。ソフトウェアの開発はほとんどが人件費だ。市販ソフトウェアだってもとは技術者が作るわけだからもとは人件費となる。したがって、ソフトウェアは再利用すればするほど、再利用するソフトウェアが問題を起こさなければ起こさないほど価値が高まる。ソフトウェアは複製しても劣化しないから部品を削減するのではなく、開発にかかる費用をセーブし、かつ、品質を高めることができればコストダウンにつながる。

【ソフトウェア資産の価値を可視化する作戦】

ソフトウェアシステムは大抵の場合サブシステムに分割される。ソフトウェアは見えないとよく言われるが、10万行を超えるようなソフトウェアシステムのソースファイルを一つのフォルダで管理しているプロジェクトはないだろう。多くの場合、ソフトウェアシステムのアーキテクチャに考慮して、フォルダを分けるはずだ。非常におおざっぱだが、そのサブフォルダの名前がサブシステムの責務を表しており、そのサブフォルダに入っているソースプログラムを作るのにかかった費用を計算する。これはそのサブシステムの価値の一つの評価指標になる。

サブシステムを協力会社に発注したのであれば、協力会社にいくら払ったかでサブシステムの価値を金額で表すことができる。もしも、設計と検証でかけた費用を分けることができれば、設計にかけた費用が顕在的な価値、検証にかけた費用を潜在的な価値と見なすことも可能だ。

もし、サブシステムを組織内で作成したのであれば工数を集計して、その工数に何かしらの金額(時給)をかければいいだろう。

それらの評価指標が使えない場合は、しょうがないからプログラムソースコードの実行コード行数にある一定の金額をかければよい。ソフトウェア開発がそもそも人件費で成り立っているのならそれもある程度の根拠となる。

これをすべてのサブシステムに実施すると、どのサブシステムがどれだけの価値を持っているか(いくらかけて作ったのか)が見えてくる。そして、次の開発でそれらのサブシステムのうちどれかをそのまま使うことができたら、使ったサブシステムの価値(開発にかかった費用)ぶん、新しい製品の開発費をセーブできたことになる。一つのサブシステムの開発費が数百万、数千万円になることはよくあるから、サブシステムをまるまる再利用すると数百万円、数千万円ぶん開発費をセーブできたことになる。

これができれば、リコールが発生したときにマイナス側でしか評価されていなかった組込みソフトエンジニアは初めてプラス側の評価を得ることができるようになる。これが定着していけば2010年代には日本でも「開発費をよりセーブできるアーキテクチャを設計したエンジニアが評価される」というソフトウェアエンジニアに対する評価のパラダイムシフトが起きるかもしれない。

日本のソフトウェア開発がぐだぐだになるのは、日本人の「あたたかい人間関係の中のやさしい一員」という特性のせいだとこのブログで書いているが、もうひとつの側面はソフトウェアの価値がハードウェア出身のマネージャのみならず、ソフトウェアエンジニア自身のも見分けがつかないからなのだと思う。

ソフトウェアの価値を高めるにはどうすればいいのかの議論は誰でもする。でも、価値が高まったかどうかの評価指標がないので、声の大きいものの発言に引っ張られ、やってみて成功しても失敗しても結果的にソフトウェアの価値が上がったのか下がったのかがわからない。開発期間の短縮という評価指標は、要求の変更などに振り回されるから正確な判断材料にならない。

だから、ソフトウェアサブシステムに開発費がいくらかかって、次の開発でいくら開発費をセーブできたのかでソフトウェア開発プロジェクトやエンジニア、アーキテクトを評価すると道は拓けるはずだ。再利用が進めば進むほど開発費は数百万、数千万円単位でセーブされていく。それが可視化されると、ソフトウェア資産の再利用が進み、ソフトウェアエンジニアは次の開発でできるだけ手を入れないで資産を再利用するにはどのようなアーキテクチャにすればよいのかを真剣に考えるようになる。アーキテクチャを工夫して再利用が成功すれば、数百万、数千万円単位で費用をセーブすることができ、セーブした費用ぶんがそのアーキテクトのソフトウェア開発効率化の実績になる。

ソフトウェアサブシステムは再利用しているといっても、実はかなり手を入れてしまって実際には派生してしまっていることも多い。しかし、これは構成管理ツールなどと連動してフォルダ内のプログラムソースがどれくらい変更されたのかをウォッチすれば変更量がわかるし、また、どれくらいソフトウェアサブシステムが他のアプリケーションから参照されているかもわかるだろう。ソフトウェアの資産価値のみならず、サブシステムが変更されたことによる注意信号(赤、黄、青)を灯すことも可能だ。

このような情報をソフトウェアサブシステムの価値に換算することで、ソフトウェアの開発を行うたびにソフトウェア資産の価値がダイナミックに変化することが見えるようになる。そのソフトウェアサブシステムを作るためにいくらかけたのか、そのサブシステムは何回再利用されたのかという指標がもっともベーシックな価値になるが、ソフトウェア検証やデバッグにどれくらい費用をかけたのかという指標もソフトウェアの信頼性の価値を判断する指標になるだろう。

「このソフトウェアの性能は最高です」とか「バグを減らしました」とか「バグが出にくいソフトウェアを作りました」なんて主張しても、ソフトウェア開発の経験のない組織の上位にいる人たちは表面的には「良くやったね」と言ってくれるかもしれないが、実際には何のことかさっぱり分からず、それらの情報でソフトウェアエンジニアを評価することはできないだろう。所詮、人間なんて自分の中にない価値基準で説明されても評価なんかしないものだ。

環境が違う場所で育った人たちが互いに理解しあうためには共通の価値基準で語りあう必要がある。メカ、エレキの出身の人たちとソフト屋さんの間で共通理解を得るためには共有できる価値基準を用いて話しをするしかない。

げすな話しと思うかもしれないが、ソフトウェアを作ったことがない、もしくは何十年も前に現役を離れてしまっている人達との共通の価値というのはここではお金のこと指す。ただ、よく考えて欲しいのはお金というのは人類が発明した全世界共通の価値基準であり、金に換算することでほとんどの人がその対象に対して共通の価値を認識できる。

だから、ソフトウェアエンジニアはソフトウェアが見えにくいということを嘆いているのではなく、また、リコールによる負の価値でマイナスに評価されることに甘んじるのではなく、ソフトウェア資産の再利用でいくら開発費用をセーブできたかを可視化すればよいのだ。

そして、開発費用をたくさんセーブできるアーキテクチャが評価され、そのようなアーキテクチャを設計できるアーキテクトが評価される。これこそが、日本版 Value-Driven Architecture である。

ソフトウェア資産の価値を簡単に評価して表現できるようなソフトウェア構成管理ツール、例えば、プログラムソースファイルをチェックイン、チェックアウトするたびにサブシステムのフォルダにソフトウェア資産の価値を表す金額が表示される、フォルダ内のファイルの変更が増えるとフォルダの色が青から黄、赤に変わる、変更が減ると青になるような構成管理ツールが現れたら是非教えて欲しい。すぐ導入するから・・・

2009-01-18

日本の技術者が目指すべきはスマートな職人気質

ここ数年、ソフトウェアの開発効率はどうすれば高まるのか、ソフトウェア品質はどうすれば維持できるかかを考え続けてきた。

しかし、教科書や文献に載っている方法論をそのままやってみてうまくいくような気がしない。雑感として次のようなことを感じる。
  • 方法論は昔に提唱されたものの方が効果が高く、新しければ新しいほどハードルが高いような気がする。(問題の根は共通で人間はそれほど成長していない)
  • 日本の組込みソフトウェアシステムの品質は高度な技術で維持されているように思えない。
  • 方法論をツールに隠蔽して解決しようとして失敗するプロジェクトが山ほどある。
とはいうもののいろいろな文献や講演を聴いたときに「これは使える」と思うこともある。後で冷静に「使える」「使えない」を考えたとき、「商品化までたどり着いて、かつ、実際に効果があった」のか「実施したが商品の価値に貢献するところまで確認していない」の違いではないかと思った。

今回の話しは、第7回 クリティカルソフトウェアワークショップ(WOCS2009)の講演を聴いて、「これは使えそうだ」と感じたことと、なぜ、日本では教科書に書かれたことがすんなりと導入できないのかの理由について考えたことだ。

まずは、冒頭の図を見て欲しい。ソフトウェア職人気質とソフトウェア工学を対比させた図で、「ルール/責任」「システム/ツール」「顧客や品質に対する意識」という「USとJapanの文化の違いと商品品質との関係」の記事で引用したGD3 コンサルティング代表/JMAC GD3 センター長 の吉村達彦氏の視点を組み合わせている。

自分の中では日本の多くの組込みソフトウェアプロジェクトの現状はこの図で言い表せるのではないかと考えている。この図で言いたいのは次のようなことである。
  • ソフトウェア工学の教科書にはソフトウェア技術者の職人気質が品質に与える影響が書かれているものが少ない。(逆に書かれているのは『ソフトウェア職人気質』や『ピープルウェア』など)
  • 日本で古くから提唱されている品質向上施策は職人気質的だ。(TQMなど)
  • 「ルール/責任」「システム/ツール」「顧客や品質に対する意識」は日米でかなり異なる
  • 日本的ソフトウェアプロジェクトには何か特殊性がある
  • 日本のプロジェクトに欧米のアプローチをそのまま取り入れようとするとうまくいかないことが多い
  • 日本のプロジェクトは表面的には欧米のアプローチを取り入れるポーズはとるが実際には役に立たないと考えていることが多い
  • 日本では「ソフトウェア職人気質」と「ソフトウェア工学」どちらかに偏ったままでは未来はない
  • それぞれのよいところを見極めながらバランスよく取り入れることが大事
「ルール/責任」「システム/ツール」「顧客や品質に対する意識」の比較の詳細は、「USとJapanの文化の違いと商品品質との関係」の記事を参照してもらうとして、ここではJAXA(宇宙航空研究開発機構)とIPA(情報処理推進機構)が共催した 第7回 クリティカルソフトウェアワークショップ(WOCS2009)の講演でこれならうまくいくのではと感じたことを書こうと思う。

まずは、MITのナンシー・レブソン教授が言った「安全性と信頼性は区別して考える必要がある」と言ったことについて。

WOCS2009では、ソフトウェアのシステム安全のオーソリティであるMITのナンシー・レブソン教授が来日(二度目)し、2時間40分のチュートリアルを講演した。ナンシー・レブソン教授はいつものように安全性と信頼性は異なる、区別する必要があると話し、信頼性を高めたソフトウェア部品を組み合わせてもシステムとして安全にはならないことを説明した。なぜかという理由は複数ある。

【信頼性の高いソフトウェア部品を組み合わせたシステムは安全とは言えない】
  • ソフトウェア部品の信頼性を100%にするだけのテストができない。
  • 仮に信頼性を100%にしても、ソフトウェア部品は簡単に変更できてしまう。
  • 部品が完全でも部品の組み合わせかた使い方で事故は起こる。(デッドロックなどが典型的な例)
だから、「ソフトウェア部品の信頼性を高める」とシステム安全は必ずしもイコールではないのだ。ナンシー・レブソン教授はこれまで数々のソフトウェアが起因する事故を調査することにより、このことを確信した。だから、安全性と信頼性は区別して考える必要があると言っている。実際に起こった事故から再発防止策を考えることは次回役に立つ可能性が高い。

自分は、クリティカルソフトウェアの開発に長く関わっていたし、そのドメインにおける事故や事故を起こした原因について常にアンテナの感度を高くしていたので、安全性と信頼性を同一視すると危ないということは直感的に分かっていた。

ところが、世の中ではソフトウェアの信頼性を高めることが、ソフトウェアシステムの品質を高めるために有効であるという考え方が流行っているように感じる。例えば、ソフトウェア部品が機能安全(IEC61508)の認証を得るとシステムが安全になるという考え方や、形式手法(フォーマルメソッド)のような数学的に漏れのないことを証明したソフトウェアを目指すことで品質が高まるというアプローチだ。

自分は形式手法がこれだけ話題になっているのは、情報処理系のアカデミアが論文にするのに格好のテーマだからではないかと予想している。ソフトウェア工学は自然科学ではないから、主張が正しいことを証明することがとても難しい。ソフトウェアは技術者の日々の積み重ねであるため、そもそもソフトウェアを作っている技術者の特性によって、ソフトウェアの品質も左右されてしまうのだ。そして、人間の脳は必ずしもコンピュータのようにロジカルではないため、いつも一定の動きをするとは限らない。

そうなると、ある方法論を提唱したとしてもそれが常に同じような効果を現すわけではない。だから、情報処理系の論文で、何%バグが減ったとか、開発効率が向上したとかいった記述を見つけたとしても、自分の組織で同じ数値をたたき出せるかどうかはわからない。

ところが、形式手法(フォーマルメソッド)は正しいことが数学的に証明できるから、論文のテーマとしてはうってつけだ。形式手法(フォーマルメソッド)は安全性と信頼性が同じではないということを分かっている技術者、組織が適用すれば効果的に働くが、信頼性を高めることでシステムの安全性を確保できると考えてしまったらかなり危ない。形式手法(フォーマルメソッド)はFelicaの開発に有用だったという実績が有名だが、どんな開発のどのようなシーンに適用するとよいのかを考える=実績から有効な範囲を予測し、自分の開発に投影してみることができないと失敗すると思う。

さて、WOCS2009の2日目の講演で、三菱電機の白坂成功氏と、JAXAの片平真史氏と、ナンシー・レブソン教授の話は、非常に欧米的でかつシステマティックでスマートな感じがした。ナンシー・レブソン教授はアメリカ人で白坂氏と片平氏のミッションはロケットや宇宙開発がテーマでその技術や施策はNASAの影響を強く受けているから当たり前ではある。一方、プログラムの最後に企画されたパネルディスカッションで発言された自動車系のソフトウェア技術者の方々のお話は非常に職人気質な感じがした。

この感覚は、冒頭の「ソフトウェア職人気質」と「ソフトウェア工学」の比較に合致している。三菱電機の白坂成功氏と、JAXAの片平真史氏の話しは、基本的にはソフトウェア工学的なアプローチでソフトウェアの安全設計を実現しようとしていて、欧米で培われたアプローチの弱点と思われる「顧客や品質の対する意識」が低い点をカバーするアクティビティとして第三者による独立検証と妥当性確認が行われたいたように思う。三菱電機の白坂成功氏は日本で開発したソフトウェアシステムの設計情報、アーキテクチャを第三者のレビュー(IV&V)によって徹底的に見直すアプローチを説明していた。JAXAの片平真史氏はソフトウェアシステムの安全設計のベースには安全文化が必要と語っていた。また、ナンシー・レブソン教授は安全性と信頼性の区別の他には、「ソフトウェアの定量的な計測だけでなく、システムを全体から定性的に分析することが安全設計には必要」と言っていた。この3方の話しに共感する感じがしたのはそれぞれ実経験、実績に基づく話しだったからかもしれない。

一方、パネルディスカッションで日本の自動車の開発ですでに確固たる品質の実績を上げてきた人たちは何を語ったかといれば、ハイブリッド車という新たなテーマに対しても「顧客満足、品質向上を高めたいと思う意識と、その意識から生まれる方法を醸成させる」というアプローチで品質を維持している内容だったと思う。これは宇宙開発での方法論の後に聞いてしまうとあまりスマートな話しには聞こえない。でも、今後はどうかわからないが少なくともこれまでは、この日本の職人気質から生まれた安全ソフトウェア設計に関するアーキテクチャとエンジニアの粘り、がんばりが日本のソフトウェアシステムの品質を維持してきたのだと思う。

だからこそ、今一度冒頭に掲げた「ソフトウェア職人気質」と「ソフトウェア工学」の比較をよく見て、自分の組織、自分のプロジェクトがどちらかに偏りすぎていないかどうかをチェックして欲しいのだ。

ソフトウェア技術者はソフトウェアをアウトプットする機械じゃない、生身の人間で必ずしもロジカルな思考をするとは限らない。それに気がついていた一部の人たちは、ソフトウェア工学をベースにしながらも、予想できない人間の思考や行動からくるズレを補正するために、プロセスを繰り返すことで軌道修正したり、改善のプロセスを導入することを思いついた。アジャイルやXPなども、人間の不確定な部分からくる品質の低下を防ぐアプローチではないかと思う。

だから、日本で安全ソフトウェアを実現させるためには、人間の特性や日本人の特性・集団心理等をよく理解した上でソフトウェア工学を導入する必要がある。

日本のソフトウェアエンジニアが目指すのはやはり『スマートな職人気質』なのだと思う。(スマートといっているのは職人のいい仕事の裏付けがソフトウェア工学で説明できるということ。単なる職人気質はスマートではない。)

今後、この比較文化論的考察は今後も続け、何かしらのタイミングで公開していきたい。
 

2009-01-10

リーダーの発言と行動

このブログで政治の話をするつもりはさらさらないのだが、定額給付金の問題での閣僚の発言の迷走ぶりが日本の企業内のリーダー達の発言や行動と似ているところがあると感じたのでここで分析してみたい。

定額給付金を国民に配布するという話しは、当初は低所得者への支援という性格から、配布のタイミングを逸したことで、今では消費刺激という性格に変わっている。

これに対して、各閣僚が定額給付金を受け取るのか受け取らないのかを答えているが、甘利行政改革大臣の答えを聞いて、「この人はクリティカルシンキングができている」と思った。

 「家計支援という趣旨で言えば、私は申請しない。消費刺激の責務があるから、家族には私のポケットマネーから定額給付し、地元の商店街で使うよう要請したい」(甘利 明 行革相)
低所得者への支援という目的に対しては、(自分は高額取得者であるから)定額給付金を受け取らないと答えたのは論理が通っている。

また、消費刺激の目的に対しては、(自分は高額取得者であるから)定額給付金は受け取らずにポケットマネーを使って消費する答えたのも論理が通っている。

この問題は以下の三つに対して矛盾なく、発言と行動ができるかどうかがポイントであり、自分は閣僚11人のうち甘利行政改革大臣だけが矛盾なく答えることができたように感じた。

定額給付金の目的と発言者の立場
  1. 定額給付金は低所得者への支援である
  2. 定額給付金は消費刺激のためである
  3. 自分は1800万円以上の収入がある高額取得者である
そう考えて、何人かの閣僚の発言を眺めてみる。


「個人の判断であって、まだ予算も通ってない段階から、もらったらどうだとかこうだとかいう“たられば”の話というのでは、お答えのしようがない」(麻生首相)

「“ニコニコ給付金”で皆が喜んで受け取ってもらいたい。私はニコニコして受け取る」(鳩山邦夫 総務相)

「省エネ製品を買ったり、エコポイント制度を利用して電球型の蛍光灯を買ったり、私のお金をプラスして地元で消費したい」(斉藤鉄夫 環境相)

「飛騨牛を食べるとか、じっくりそれは考えたい」(野田聖子 消費者行政相)

「個人の内面性に土足で踏み込んで、もらうのかもらわないのか迫るのは、個人の内面性の自由とぶつかるのではないか」(与謝野馨 経財相)

「(給付金の受け取りを)辞退するなんて、格好つけるような事を言う人があるが、そうじゃない。ここで少しでも景気の傾向に歯止めをかけ、頑張っていこうではないか」(自民党 細田博之 幹事長)
麻生首相と与謝野経財相以外は、2の定額給付金は消費刺激のためである という一点だけに着目して発言している。麻生首相と与謝野経財相に至っては、定額給付金の目的を推し量れるようなコメントがどこにも入っていない。

マスコミが「定額給付金を受け取るのか受け取らないのか」などという一見どうでもいいようなことを聞いているのは、これを聞けば定額給付金を低所得者への支援なのか消費刺激のためなのか、閣僚達がどちらだと考えているのか、もしくは別の考えを持っているのかが分かる、おそらく一致していないだろうと考えたからだと想像する。

そして、その問いに対して矛盾なく回答できたのは、甘利行政改革大臣だけのように感じる。

そもそも、このようなクリティカルな思考(自分の考えを批評しながら、より深く論理的に物事を考えること)をするためには、発言や行動の前に「目的」が明確でなければいけない。

「目的」を考えるについては直近の要求ではなく、遠くにあるゴールを見据えながら、今行うべき発言や行動について考える。

日本人はこれに慣れていないし、そのための教育や訓練を受けてきていない。(アメリカ人と日本人の記事を参照のこと)

だから、直近に起こったこと、ステークホルダからの要請、自分の過去の体験に基づく判断で発言や行動をしてしまう。リーダーがこれをしてはいけない理由は、一度した発言や行動が後で撤回されることが続くと、大きな無駄が発生し、部下の信頼がなくなり、プロジェクトのモチベーションが下がるからだ。

だからリーダーが発言や行動をする前には、トヨタ式ならその発言や行動に対して3回から5回、「なぜ、それを指示するのか」を繰り返してみるとよい。なぜを繰り返すことで、発言や行動の本質、目的が明確になり、遠くにあるゴールが何かはっきりしてくる。

それ以外にも、マーケティングの世界では「ファイブフォース分析」とか「SWOT分析」とか「バランスコアカード」とかの分析手法があるが、日本の組織内のリーダー達の多くはそういった理論(先人の知恵を体系化したもの)を使ったり、それらを知っている部下に分析を指示したりせずに、直近に起こったこと、ステークホルダからの要請、自分の過去の体験に基づく判断で発言や行動をしてしまう。

クリティカルシンキングを使わなかったとしても、日本のお家芸的にはカイゼンのアプローチで事態をを打開することができる。

P(Plan)→D(Do)→C(Check)→A(Actoin)のサイクルを回すというのが、カイゼンのプロセスの代表例だが、実際にはそれが身についている人は非常に少ない。

計画を立てて実行したとき、その行動が成功したのか失敗したのかを判断するためには何かしらの評価指標が必要だ。ところが、行動をする前にあらかじめ評価指標を考えている人は以外にも少ない。P(Plan)→D(Do)→C(Check)→A(Actoin)が大事だと教壇に立って教えている人でさえ、講義が受講生に対して効果を及ぼしたのかどうかをチェックしていないこともある。

定額給付金について、「定額給付金は低所得者への支援である」と「定額給付金は消費刺激のためである」の2点について、評価指標を考えてみよう。

「低所得者への支援」が成功したかどうかの評価指標の例としては、今となっては失業率を目標にするのがリーズナブルなように思う。失業率の悪化をゼロにすることはできないから、例えば他国の状況を見て目標失業率を設定し、それをクリアできたかどうかを一定期間後に計測する。

12,000円の定額給付金が失業してしまった人が定職に就くためにどの程度有効かと考えると焼け石に水のような感じがするので、見直した方がよいという判断に傾く。

次に、「消費刺激」に関しては、GDPを0.2%引き上げる効果があるという試算があるようだから、これが計れるのなら半年後など期間を決めて計測すればよい。簡単に計れないのなら企業の倒産件数などを指標にしてもよいと思う。

評価指標を考えると成功したときの自分と失敗したときの自分が見えてきて、本当にこれをやっていいのだろうかと考えるようになる。施策を実行する前に評価指標を考えることで、そもそもその施策自体が目的に合っているのかどうかの見直しができる。これはソフトウェア開発における早期テスト設計、テストファーストと同じだ。

プログラムを作る前に単体テストのテストケースを作っておくと、プログラムの仕様自体が浮き彫りになり、このテストケースを通すためにこの関数を作らなければいけないという視点が生まれる。

日本の企業内で評価指標の設定ができていない(=クリティカルシンキングができていない)例は例えば次のようなことだ。

ある製品の売り上げが落ちた。その原因を問われたリーダーが販売サイドから「他社にはある○○の機能がこの製品にはついていないからだ」という意見が上がっていたことを思い出し、プロジェクトに対して「○○の機能を早速付け足すべし」という指示を出すといったケース。

ここで考えるべき評価指標は、○○の機能を付けたことでどれだけの売り上げアップに貢献するのかという点と、エンドユーザーの満足度はどれくらい向上するのかという視点である。そして、それらを判断するための数値的な指標を考える必要がある。でも、多くの組織ではそんな観点なく、場当たり的な指示が飛ぶことが多く、リーダーの信頼が失われてしまう。

リーダーは行動を起こす前にプロジェクトメンバーに評価指標を提示すれば、評価指標を計測したときに行動が成功だったのか失敗だったのかが判断できる。失敗が明らかになってしまうことに対する恐れを抱くリーダーもいるかと思うが、これまで述べてきたように評価指標を考える段階でクリティカルシンキングが働くため失敗する確率は低くなる。

また、評価指標をあらかじめ掲げて失敗したとしても、カイゼンのプロセスを回す意志はプロジェクトメンバーに伝わるため、次回連続して失敗する確率が減ることが想像され、リーダーへの信頼は逆に高まる可能性もある。発言や行動の評価指標を設定しておけば成功しても失敗しても得るものがある。それができないリーダーは失敗したときに周りからの非難されるが怖いからか、クリティカルシンキングを一度もやったことがないからだ。

ただ、発言や行動をする前に評価指標を考えておくというのは、言うのは簡単だけれども実際にやってみるには、小さいPDCAを回す経験を積み重ねていないとなかなかうまくできない。

例えばお昼ご飯を何にしようかといった非常に小さいことでも、今日の気分と予算を設定して、昼食後に満足度と予算がクリアできたかどうかをチェックして翌日の昼食選びに活かすといったPDCAを回す経験を繰り返しておかないと、もっと大事な行動をしなければいけないときにサッとクリティカルシンキングはできない。

クリティカルシンキングをしながら発言や行動をしないと「いい仕事をしたね」と言われるような実績につながらない。いい仕事を積み重ねることができるとリーダーとしての信頼を得ることができる。いい仕事を積み重ねるためには、今やっていること、やろうとしていることの本質的な目的を常に考えていなければならない。

クリティカルシンキングについては『通勤大学MBA〈3〉クリティカルシンキング (通勤大学文庫)』で819円で学べるので参考にしていただきたい。
 

2009-01-04

日米エンジニアの満足度の違い

2009年最初の記事は、「日米エンジニアの満足度の違い」についてである。このデータはフリー情報誌の EE Times の昨年の記事から引用した。

EE Times は多くの記事が米国発の情報で、今回のデータは米国と日本の読者からのアンケートの集計結果である。

EE Times の読者はどちらかというとデジタル系のハードウェアエンジニアが多いと思うが、ソフトウェアエンジニアも読んでいると想像する。ということでアンケートの対象はハードウェアとソフトウェアの両方のエンジニアを包含したものだと考えればよいと思う。

【日本のエンジニアの特徴(回答者 1420人)】

平均年齢:43.6歳
平均年収:758万円
平均勤務時間:51.3時間/週
平均職務年数:18.3年
平均転職回数:0.8回(転職経験あり:44%)

【米国のエンジニアの特徴(回答者 1158人)】

平均年齢:46.0歳
平均年収:11.4万ドル(約1140万円)
平均勤務時間:46.5時間/週
平均職務年数:20.9年
平均転職回数:3.1回(転職経験あり:80%)

これらのデータを眺めてみると、円高になっても日本のエンジニアは平均年収が300万円以上少なく、平均勤務時間が長い。転職は米国に比べて圧倒的に日本が少ない。エンジニアが浮かばれない日本、これが現実なのかとがっかりする。・・・がでもよく考えてみよう。

組込み機器に限って言えば、市場に流通している製品のできは給料が安く、より多くの時間働いている日本の商品の方が品質がいいんじゃないだろうか。より組込み機器で顧客満足を満たすことができているのは、日本のエンジニアではないだろうか?

もしも、自分たちが市場に送り出している商品の方が、より顧客を満足させている自信があるのならエンジニアとして胸を張っていいはずだ。

ここで日本のエンジニアのみんさんによく考えて欲しいのは、こんな結果が出ているからといって日本のエンジニアの待遇が高くなればいいという単純なことではないということだ。

日本とアメリカでは環境も違うし、日本のエンジニアとアメリカのエンジニアの気質はかなり違う。アメリカ人と同じように平均転職回数が3回になったら、当然技術力をアピールできなければ生き残れないだろうし、日本人としての「あたたかい人間関係の中のやさしい一員」という特長を活かしたものづくりはできないかもしれない。

次に日米のエンジニアの満足度に関するデータを見て欲しい。

2008.12 EE Times Japan p77 図6 エンジニアの満足度など より引用

分野 評価項目 日本米国
満足 エンジニアという職業に満足している 86% 89%
自分のキャリアに満足している 61% 86%
自分のスキルは他のエンジニアと同等以上 60% 90%
自分の子供もエンジニアになってもらいたい 50% 76%
上記4項目平均 64% 85%
尊重度 私の会社はエンジニアを尊重している 56% 80%
私の会社は以前よりもエンジニアを尊重している 42% 48%
現在の会社は以前よりもエンジニアを尊重している 33% 43%
自分の置かれている状況は他の職種と比べて同等以上 44% 76%
上記4項目平均 44% 62%
先進性 私の会社の技術は最先端のものである 44% 67%
私の同僚のエンジニアの技術力は最新のものである 40% 74%
仕事で使っている機器は最新のものである 44% 74%
私の会社は革新性や創造性に力を入れている 46% 72%
私の会社はエンジニアの革新的な成果に報いている 32% 61%
上記5項目平均 41% 70%
快適性他 私の会社はよい職場である 60% 81%
同じ会社に長く勤めたい 70% 68%
上司に対して自由に反対意見を言える 68% 82%
私の会社は少数の経営者だけで意志決定を行う 64% 75%
私の会社はマーケット志向である 53% 85%
上記5項目平均 63% 78%

日本のエンジニアは「尊重されておらず」「満足もなく」「技術力も低い」が会社を辞めたいとは思わないと言っているように見える。

厳しいことを言えば、日本のエンジニアは技術力で勝負していない、技術力に自信もない、会社にも認められていない、でも同じ会社に長く勤めたいと言っているのではないか。

まあ、会社組織の方もエンジニアを技術力で評価できているとは思えないし、エンジニアを尊重しているようにも思えないから、エンジニアも組織も両方とも変わらなければいけないのだと思う。

上記のエンジニアの満足度のデータはあまりにもひどいし、自分達を卑下しすぎている。この状況はなんとか変えていかなければいけないだろう。自分達が作っている商品は胸を張れるのに、自分の子供にエンジニアになってもらいたいとは思わないという状況はどう考えてもおかしい。

この状況を改善するためには、まずエンジニア個人はまず、「こんな会社飛び出してやる」と言えるだけの技術を身につけ、組織はエンジニアの成果がどのように商品価値に活かされたのかを評価し、その評価に見合った尊重をエンジニアに与える必要がある。

「尊重」というのは必ずしもお金だけだとは限らない。例えば、勉強の時間を与えるとか、学会やシンポジウムに参加させるというお金以外の待遇方法だってある。

お金や人はあなたを裏切ることをあるかもしれないが、教育や身につけた技術は決して裏切らない。エンジニアは組織が自分を守ってくれると思っているかもしれないが、実態のない組織はエンジニアを裏切ることだってある。

何はともあれ、エンジニアは技術力を身につけてその技術で勝負し、顧客満足を高めなければ道は開けないということだ。その努力をして、かつ組織を変えようとしても変わらないようなら、身につけた技術を引っさげて新たなフィールドに飛び出せばよい。

ただ、そのとき日本とアメリカの違いをきちんと認識し、日本人の特性、強みを忘れないようにしないといけない。