2008-12-20

ソフトウェアエンジニアが自分の成果を表現する必要性について

2008年も終わりに近づいている。2008年の年初にこのような金融危機からくる景気の急速な減速が起こるとは予想もしていなかった。

この事態に一時的に職を失った人もいると思うので軽々なことは言えないが、毎日流れる不況のニュースを聞いていて技術者にとって仕事とはなんだろうかといろいろ考えを巡らせたのでその内容を書きたいと思う。

ソフトウェア技術者として仕事をしているのであれば、個人の価値と組織の価値をできるだけオーバーラップさせ、かつ、大変だけれども楽しいと思える仕事をしたいと思っているし、このブログでそう書いてきたつもりだ。実際にエンジニアとして仕事をしてきた自分自身の22年間を振り返ると多くの時間がそうであったと思うし、それなりの満足感もある。

過去を振り返ったときに満足感を得るためには、その時その時に流されてしまってはいけない。ここぞというときにはこだわりを持って踏ん張らなければならない。逆風に立ち向かうシーンが必ずあるはずだ。しかし、皆いろいろな人間関係や社会状況の中で仕事をしているわけで、いつでも逆風に立ち向かうことができるとは限らない。自分自身が弱っているときや、自分の周りの環境が安定していないときは一時的に壁の陰に退避しなけれいけないときもある。

今のような異常な経済状況はまさに退避をしなければいけない時かもしれない。だから、こんな状況のときに言うのではなく、安定した社会環境のときに言えばよいのだけれど、普段からソフトウェア技術者はこうしているべきであるということをあえて書いておきたいと思う。自分の体力がみなぎっているとき、周りの環境が安定したときにこれから書くことを思い出していただきたい。

ソフトウェアエンジニアが他のエンジニアよりも不利な点は、成果が見えにくいことだ。組込みソフトの場合は最終的には製品ができあがるので、製品の外側に現れる機能や性能でソフトウェアエンジニアの成果を推し量ることもできるが、ソフトウェアはユーザーインタフェースに関わるところ以外の役目もたくさんある。それらの裏方のソフトウェア開発に携わったエンジニアの成果は見えづらいし、メーカーがソフトウェアを外部に発注している場合、協力会社が自分たちの成果が最終製品に搭載されていることを公に言えない場合もある。

ソフトウェア技術者のスキルレベルをITSSやETSSといったスキルスタンダードで表すこともできるようになったが、ETSSの場合は技術要素の部分は自分たちのドメインに必要な技術を自分たちで定義して測ることになっており、それができていない組織は数多くあるので、実際にはそのエンジニアの実力を表現しきれていないこともある。

成果が見えないということは、その技術者を評価する指標がないということだ。「彼は優秀だ」とか、「○○についての技術がある」などといった評価は、一緒に仕事をしている仲間や上司なら分かるが、いったんその環境を離れてしまうと、技術力や成果といったソフトウェア技術者にとっての鎧はすべてはがされ丸裸になってしまう。

そういったときのために一般的には資格というものがあるのだが、こと組込みソフトの場合は資格はある程度の指標にはなっても、「この人材を採るか採らないか」の決定的な判断には使えないと思う。

そういう意味で、ソフトウェア技術者がしておかなければいけないことは、自分がこの一年でどんな仕事をしたのかを記録して蓄積しておくことだと思う。10年選手ならば、これまでの10年分の成果が何かをいつでも説明できるようにしておくのだ。

成果が見えにくいからこそ成果を一目で見えるようにしておくことがソフトウェアエンジニアとしての鎧になる。この一年でどんな仕事をしたのか、どんな技術を習得したのかを実績のリストに記録する。毎年開催されるソフトウェア系のシンポジウムに投稿して採用された論文を成果として追記しておくのもよいだろう。

ソフトウェアエンジニアの成果が見えにくいというのはみな同じ条件だ。だから、同じ成果を持っているエンジニアが複数いた場合、これまでの成果をどれくらい分かりやすく表現できるかどうかで鎧のグレードが変わってくる。

組織に所属していても常に自分は個人商店なんだと思っている。だから、ウチの商店で扱う商品や他の店にはない特長や、他の店よりも優れているところは聞かれればいつでも説明できるようにしているつもりだ。そういう意味では、まったく転職する気がない技術者であっても、毎年年末に業務履歴を中心とした履歴書を書いてみるのは、自分の技術の棚卸しにもつながるのでよいことだと思う。

反省しないエンジニアは成長しないし、どんな業界でもプロフェッショナルは自分がした仕事が顧客を満足させているかどうか常に自問自答している。

ただし、冒頭にも書いたようにこのようなことを考えていいのは、自分自身の体調が万全であり、周りの環境が安定しているときだ。もしも、自分の周りで嵐が吹き荒れている人は、嵐が去るのをじっとまって晴れ間が現れたときに、自分自身の成果をどのように表現できるか考えて欲しい。
 

2008-12-07

進学塾のソリューションを考える

みなさんは、日本の小学生向けの進学塾のアプローチの仕方をご存じだろうか。簡単に言えば、小学5年生のうちに6年生のカリキュラムをすべて履修してしまい、6年生になったら志望校に合わせた受験対策のための勉強をするという方法だ。

それは小学生本人にとってはとても過酷な勉強方法であるが、やりきることができれば効果は絶大だ。なにしろ一年分も前倒ししてカリキュラムをこなし、一年間も受験の対策をするのだから、そんな勉強の仕方をしていない子供はなかなか立ちゆかない。

自分がこの状況に問題点を感じるのは、偏差値の高い学校に入学することをゴールにしていることもさることながら、目的を達成するためのソリューションを考えているのは進学塾サイドであり、生徒や親は提供されたソリューションに乗っかっているだけだという点だ。

問題を解決するための方法を自分で考えてないということ=問題解決力が低いということにならないだろうか。あらかじめ答えの決まっているテストに回答して得点を競うというということは、知識と回答のパターンの記憶の勝負とも言える。

東大合格生のノートはかならず美しい』という本が売れているが、この本で紹介されているノートの書き方をまねしてしまったのではたぶんダメなんじゃないかと思う。ノートの書き方のくふうを考える→やってみる→調子を見る→改善してみる、といったP(Plan)→D(Do)→C(Check)→A(Action)を回して確立した結果がこの本で紹介されてる美しいノートなのではないだろうか。

だから、すでに確立されてしまっているソリューションをまねしただけでは効果は半分ぐらいしかないのではないかと思う。技は自分で苦労して編み出したときに最大の効力を発揮する。プロフェッショナルが考えたソリューションをただ単にまねするのではなく、少なくとも自分向けにテーラリングするくらいのくふうがないと力がつかない。

『問題解決能力』はこのブログサイトにたどり着くキーワードの常に上位にランクされている。過去に書いた『問題解決能力(Problem Solving Skill):自ら考え行動する力』の記事の影響だと思う。この記事にも書いたけれど、問題が何かを見据えて、その問題を解決する能力が高いと、その問題を解決するための知識やスキルは何かが分かる。要するに誰かから指示されなくても、自分で問題を解決し、問題解決のために必要な知識、スキルを身につけることができる。問題解決に必要のない知識、スキルを身につけなくてもいいから効率がいい。

問題解決能力が高いということは、自立した万能選手であることと同等だと思う。後は、その万能選手に燃料を与えてあげるだけだ。その燃料となるのがエンジニアに対するモチベーションであり、モチベーションは顧客満足と考えると組織の価値ともオーバーラップするからよいよとこのブログで言い続けている。

進学塾は自分たちのビジネスのために最大の努力をしており、そのソリューションは確かにすごいと感じる。ただ、問題はそのソリューションを使った教育は答えのない問題を解決する能力を高める訓練にはなっていないという点だ。

この問題を解決するにはどうすればいいのか。それには教育に対する顧客と顧客満足は何なのかを考える必要がある。教育サービスの顧客が子供の親であり、親が有名な学校に子供を入れることが顧客満足なら進学塾のアプローチは間違っていない。

教育の目的を、子供が成長したときに自立して生きていくことと考えるのなら、教育サービスが「子供が成長したときに自立して生きていくこと」につながっていかどうかを常に確認しておく必要があると思う。
 

2008-11-29

ツールの導入とは自分自身が変化するということ

Embedded Technology 2008 が終わった。5月のESECと11月のETは組込み系の首都圏で開催される2大イベントで、これらの展示会に行くことでツール類の情報や、開発方法論の情報などをチェックする。

日頃、ソフトウェア開発に関するツールについて、「ツール至上主義はいけない」とか「ツールベンダーの口車に乗ってはいけない」などと言っているが、ツールについて最新情報をチェックしていない訳ではない。何が本当に役に立つのか、立たないのかの判断基準を自分の中にしっかり持ってツールを見定めているし、ツールベンダーの話も聞くようにしている。

そういう目で展示会の会場を回っていると、ツールを通してエンジニアを助けてあげたいと思っているツールメーカー、ツールベンダーと、時流にのって売り上げを伸ばすことだけを考えているツールメーカー、ツールベンダーが見分けられるようになる。

ツールメーカーは純粋にソリューションを提供したいと考え、ツールベンダーは売り上げしか考えていないとか、ツールベンダーの営業員によっても目先の売り上げだけを考えている者と、ユーザーと長く付き合うために何とか要望を聞いてあげたいと考える者がいるので、一概にあの会社はいいとか悪いとか言えないが、好ましくないベンダーは好ましくないユーザーがいるからこそ生き残ってしまうのではないかと思うことがある。

ET2008の展示会場で 富士設備工業(株)電子機器事業部 の浅野さんと話しをしていたときのことだ。(富士設備工業なんて、およそソフトウェアと関係ありそうもないが、実は海外の開発ツールを積極的に導入しサポートまで提供している)

富士設備工業(株)電子機器事業部 では、ソフトウェアプロダクトラインの支援ツール pure::variants を取り扱っている。今でこそ、ソフトウェアプロダクトラインはメジャーなキーワードになりつつあるが、たぶん日本で初めて話題になったのは2003年くらいからだと思う。当時、自分はEEBOFでソフトウェアプロダクトラインのことを知り、CQ出版の Interface誌 2003年12月号で『具体例で学ぶ組み込みソフトの再利用技術』というタイトルで自分がモデレータとなってソフトウェアプロダクトラインにも関係する記事を書いた。浅野さんはこの記事をことを覚えていてくれて、当時ソフトウェアプロダクトラインの情報源のひとつとして役に立ったと言ってくれた。

浅野さんとソフトウェアプロダクトラインを日本で成功させるのは簡単ではないという話をしていたら、お客さんの中にはツールを導入しても結果的にうまくいかず、ツールやそのソリューション自体に対して役に立たないという烙印を押してしまい、その経験がトラウマになってしまう人たちもいるということを聞いた。

自分はツールを導入するきっかけは、技術者個人がある状態から別の状態に変化すること、あるいは変化したいと思うことにあると考えている。

現在の状態では問題がある、効率が悪い、品質が上がらないので、それらの問題を解決し、開発効率がよい状態、ソフトウェア品質が高い状態に移行したいと考え、ツールが状態変化に必要だから導入するという考え方だ。

みなさんによく考えて欲しいのはソフトウェア開発は基本的にはソフトウェアエンジニアの日々の活動の成果の積み重ねであり、ソフトウェアエンジニアの頭の中で考えたことが最終成果物になるということだ。
ソフトウェア開発で何か状態を変化させるということは、すなわちソフトウェアエンジニア自身(正確に言えばエンジニアの頭の中)がある状態から別の状態に変わるということなのだ。だから、自分自身が変わる気はさらさらなく、ツールがソリューションを提供し成果物を変化させてくれるはずだと考えているとたいてい失敗する。

一番成功する確率が高いのは、技術者が自分自身で状態の変化を手作業で実現し、その手作業の工程を自動でやってもらうといケースだ。手作業で業務なりプロセスなり、活動なりを改善し、その一部をツールに任さるためにツールを導入するケースだ。すでにやったことがあって効率化を図るという方法ならほとんどの場合成功する。

それとは逆に自分自身が変わる気がなく、ツールを魔法の箱にように見たてて期待していても何も起こらない。高い金払ったのだから何か出せと言っても何もでてこない。

ただ、ツールを購入したことをきっかけにして、ツールを使いこなせるようになることで自分自身の変化のきっかけにする人はいると思う。でも、自分自身の変化の必要性の認識とそのたいへんさが十分に理解できていないと結局は途中でくじけてツールはお蔵入りとなる。

世の中には操作者が何も考えなくてもインプットを与えて期待するアウトプットを出力するタイプのツールもたくさんある。でもソフトウェア開発に使うツールはソフトウェア開発自体がひとつの方法論には集約できないのでそんな単機能のツールなど存在しないし、そのような単機能なツールはあったとしても一般化されているのでESECやETで物色することもないのだ。

ソフトウェア開発ツールには結局は何かしらのソリューションが隠蔽されているのだけれど、利用者側はそのソリューションがどんな問題を解決する方法論からきているのかを理解する必要があるし、場合によっては自組織や開発製品に合わせてツールの使い方をくふうしたり、ツール自体をカスタマイズしてもらわないと問題解決に有効でないこともよくある。

ツールを使うユーザーが自分自身の変化について心の準備ができており、変化しなければならない目的が明確になっており、その目的のためには多少の犠牲も必要というそれなりの根性があればツールは活きてくる。そのようなユーザーに手厚く援助してくれるツールメーカーやツールベンダーを見つけないといけない。

その自信がないユーザーはまずは、ツールを買うのでなくソリューション自体を学習したり、手持ちの道具を使って問題を解決してみることを考えるとよい。解決できる見通しが立ってからツールを導入すれば失敗はしない。

実は、Excel や Word やフリーのツールなどをくふうすることで解決できてしまう問題はたくさんある。そういう努力を日々やっていると、「なんで、わざわざこんなツールを作るの?」とクビをかしげたくなるようなツールも見えるようになってくる。
 

2008-11-22

人生は実験

広い心で聞く』の続きで、米国シリコンバレーを中心に経営コンサルタントとして活躍するKimberly Wiefing 氏のインタビュー記事の最終回である。
Life is an Experiment

Wiefling: Some people tell me, “Kimberly, this kind of listening, this kind takes a long time. I’m very busy person.” Here’s the problem, though. Do you ever have a conversation with somebody, and you have the same conversation over and over and over again? This takes a lot of time. When somebody says something, if they think you didn’t hear them, you know what they do? They say it again. And if they don’t like the conversation, they come back and have another conversation with you. So what we find is spending this time on these kind of critical conversations actually is a lot faster than trying to rush through the conversation with non-generous listening skills.
Listening seems very passive, and sometimes it’s hard for people to understand how powerful it can be. When we’re listening, we’re sitting quietly. This is very difficult for some people to understand. How can listening be great leadership? It’s something you just have to try.
When you start really listening to people, they feel valued. When they feel valued, they start contributing more. When they start contributing more, more ideas come, they have good feedback about their performance, and everything improves in that working relationship and in the team. I and listen to somebody that you haven’t listened before.

ウィーフリング:「キンバリー、こういった聞き方は時間がかかる。私はすごく忙しいんだ」と言う人たちもいます。でも、そこに問題があるのです。あなたは、誰かと話をして、同じ会話を何度も繰り返したことがありませんか? これは大変時間がかかる行為です。何か言って、相手が聞いていないと思ったら、その人がどうするか、おわかりですか? また同じことを言うんです。また同じことを言うんです。会話に満足しなかったら、戻ってきて、もう一度話しをします。ここでわかるのは、実際、こうした決定的な会話にはそれなりの時間を割いた方が、ジェネラス・リスニングのスキルを用いないで会話を急いで切り上げようとするより、ずっと早く済む、ということです。

 聞くという行為は、大変受け身なことに思われますし、それがどれほどの威力を持ち得るのか、理解しにくいこともあります。人の話を聞いているとき、私たちは黙って座っています。そのことがなかなか理解できない人々もいるのです。話を聞くことが、優れたリーダーシップであるものか、とね。それは、あなたがとにかく試してみるべきことなんです。
 あなたが人の話を心から耳を傾け始めたら、相手は自分が重んじられていると感じます。重んじられていると感じると、人は今まで以上に貢献し始めます。貢献度が増せば、より多くのアイデアが浮かび、自分の業績についていいフィードバックがもらえる。そうすれば、そうした職場の人間関係やチームにおいては、あらゆることが向上していきます。私は皆さんに「やってみてください」とアドバイスするんです。人生は実験です。時間をかけて、試してください。これまで耳を傾けたことのなかった人の話に耳を傾けてください。
キンバリー・ウィーフリング氏の話を聞いてみて感じるのは自分の主張がはっきりしており、説得力があることだ。もちろん、主張の裏付けもある。

振り返って、日々の仕事の中で感じるのはエンジニアやマネージャの自信のなさだ。うまく回っていないプロジェクトほどサンドバッグのように右から叩かれると左に振れ、左から叩かれると右に触れてしまう。もちろん、広い心も持てないのでプロジェクトリーダーはジェネラス・リスニングもできない。

問題を解決しようと思っても誰も決断できない、誰かが話を切り出すのを待っている、誰かがダメだししてくれるのを待っている。日々の発言や行動に明確な根拠を持っていないからそうなる。

そういう状況でもキンバリー・ウィーフリング氏のような優秀なコンサルタントはネガティブな言い方はしない。必ずポジティブに自信を持って攻める。

結局、ダメだしして受動的に動いているようではダメだしする人がいなくなった瞬間にプロジェクトは立ちすくんでしまう。自立できるようにしなければ意味がないのだ。

エンジニアが自立するためには自分の発言や自分の行動に自信を持てるようにならなければいけない。ジェネラス・リスニングは技術者に自信を付けるのに役立つと感じる。時間をかけてジェネラス・リスニングを行うのは、相手に自信を付けてもらい、自立させて自分でどんどん問題を解決でききるようになってもらうためでもあると思う。

問題解決能力(Problem Solving Skill):自ら考え行動する力』も参照されたし。
 

2008-11-15

広い心で聞く

もっとも重要なリーダーシップ・スキル』の続きで、米国シリコンバレーを中心に経営コンサルタントとして活躍するKimberly Wiefing 氏のインタビュー記事の4/5回である。
Listening Generously

Interviewer: So, can you tell us about the actual skills involved in generous listening? How do we do it?

Wiefling: Yes. Generous is very challenging. Most of the time, we are not trained in how to listen. So, in generous listening, you have to give people some motivation. “Why should I listen? It’s hard work to listen generously. Why bother?” So, when we do the workshops, first we must convince people that it’s a good use of their time. It takes time. It takes energy.
So, the first thing we do is we shoe people an exercise where we ask them to do a simple task, and we ask each person, “What is your answer? What is your answer?” And everyone answers a different way for the same task. And then they realize, “Oh my gosh! I cannot do this simple task. This other person was successful. Why couldn’t I be successful?
We do another little game, another little trick, each time showing them each person makes mistakes, but somebody in the group has the answer. So, now, they’re starting to get very curious. “What do other people see, that I am blind to? What are other people hearing that I can’t hear? What do other people know, that I am missing?”
Now we have them. Now they’re ready to listen, because they’re curious. It’s very interesting when you work with people who are so smart, and you give them a simple task, and show them individually you cannot do this task, but as a group you can succeed. Suddenly they become much more interested in listening to each other.
Then I show them generous listening. Generous listening is for problems that you can’t solve by yourself. It’s for creating new opportunities that you can’t create by yourself.
If someone is listening to me, and says, “Interesting! Kimberly, tell me more,” – four magic words: interesting, tell me more – then I can hear myself think more clearly.
If I am speaking, and no one’s listening, I quickly close down my ideas. That’s why generous listening is so powerful. It allows me to overcome my own self-limiting behavior.

インタビュアー:ジェネラス・リスニングに必要な具体的なスキルについて、お話いただけますか?どうしたら、ジェネラス・リスニングができるでしょうか?

ウィーフリング:ええ、ジェネラス・リスニングは非常に難しいスキルです。ほとんどの場合、私たちは聞き方の訓練を受けていません。ですから、ジェネラス・リスニングを行う場合、(聞き手の)皆さんに何らかの動機付けをしてあげる必要があります。「なぜ私が話しを聞かなきゃいけないんだ? 広い心で話を聞くなんて大変なことじゃないか。なんで、わざわざ?」(と人は言うでしょうからね)。ですから、ワークショップを行う際は、最初に、ジェネラス・リスニングが時間の有効な使い方なのだということを、受講生に納得させなくてはなりません。ジェネラス・リスニングには時間もかかりますし、エネルギーだって費やしますから。
 そこで、私たちが最初にやるには、受講生の皆さんに課題を示し、単純な作業をさせて、一人一人に「あなたの答えは何? あなたの答えは何?」と尋ねることです。同じ作業に対して、みんな違う答え方をします。そこで、受講生は、「ええっ! この単純な作業が私にはできない。あの人はうまくできたのに。なんで私はうまくいかなかったんだろう?」と思います。
 もう一つ、ちょっとしたゲーム、というか、お遊びをします。今回、一人一人は間違いを犯すけれども、グループの誰かは答えをわかっているということを教えるのです。すると、皆さん、すごく興味津々になります。「ほかの人たちに見えていて、自分には見えていないものって何だろう? ほかの人たちには聞こえていて、自分には聞こえないことは何だろう? ほかの人たちにはわかっていて、自分が見落としていることは何だろう?」とね。
 こうして、受講生の皆さんの心をとらえます。こうなると、皆さん興味津々ですから、話を聞く心構えができています。頭の切れる人たちと一緒に取り組むのは、本当に楽しいものですよ。単純な仕事を与えて、一人一人ではできないけれども、グループとしては成功する、ということを示してあげるんです。すると、皆さん、お互いの話を聞くことに急に熱心になります。

 そこで、ジェネラス・リスニングについてお教えするんです。ジェネラス・リスニングは、一人では解決できない問題を解くためのスキルです。自分一人では生み出せないチャンスを生み出すためのスキルなのです。
 誰かが私の話を聞いていて、「面白い! キンバリー、もっと詳しく話してよ」と言ったら-面白い、私に、もっと詳しく、話して、というのは魔法の4ワードなんです-私は、さらにその物事に注意を傾けることができるようになります。
 自分が話していても、誰も聞いていなければ、私は考えるのをさっさと打ち切ってしまうでしょう。そういうわけで、ジェネラス・リスニングというのは非常に効果的なのです。相手にジェネラス・リスニングをしてもらうことで、こちらは、自分を狭めてしまうような振る舞いを克服できるのです。
確かに我々は聞き方の訓練を受けていないかもしれない。そして、聞き方がうまい、話を引き出すことがうまい人の周りには優秀な人が集まっているような気がする。優秀な人が集まっているのではなく、それぞれの人が持っている能力を最大限に引き出すことができるからそう見えるのかもしれない。

自分は何でもいいから自分が持っていないものを相手が持っているときは、ジェネラス・リスニングができていると思う。自分自身がその知識や技術を吸収したいから、素直に「おもしろい、もっと詳しく話して」と言える。

では、実際には自分がすでに知っていること修得していることについて相手がしゃべり出したときはどうかと振り返ってみると、おそらく口には出していなくてもつまらなそうな顔をしていると思う。

ウィーフリング氏が言っている聞き方の訓練が必要というのがこういう事なのだと思う。自分のためではなく、相手の能力を引き出したり、チームの成功のために聞くための技術を使うということがリーダーには求められるのだ。

最近、NHKのクローズアップ現代という番組で、神奈川トヨタが心の悩みを抱える従業員をフォローアップするための部門を作り取り組んでいる様子を流していた。ある販売店の所長が終業後の事務所で若い営業員の話を延々と聞いているシーンがあった。営業員は自分が考える販売店の在り方などを所長に話しており、話が終わったのは23時を過ぎていた。この営業所では所長が部下の話をじっくり聞く取り組みを始めてから販売成績が上がったという。

これはまさに、ジェネラス・リスニングを実践しているということに違いない。
 

2008-11-08

最も重要なリーダーシップ・スキル

さまざまなリーダーのタイプ』の続きで、米国シリコンバレーを中心に経営コンサルタントとして活躍するKimberly Wiefing 氏のインタビュー記事の3/5回である。
The Last Leadership Skill

Interviewer: You say there are two reasons that teams fail to achieve their goals. What are they?

Wiefling: The top two reasons, on average, typical teams fail to achieve their goals – the number one reason is: they don’t have goals, or goals are unclear, or people don’t understand the goals the same way. It’s a very preventable cause of failure, and every leader is responsible for making sure this is never a cause of failure for their teams.
The number two most common reason for teams to fail, especially in this world, this global economy, is communication. Communication is the only way we have to lead other people, to influence other people. And yet, we are given very little guidance on the most important part of communication, and that is listening. Listening is the lost leadership skill. Everybody’s good at talking.

Interviewer: And so that’s why you teach what you call “generous listening”?

Wiefling: Generous listening. Most listening is listening for what’s wrong with what the other person is saying. This kind of listening filters out many ideas. When we’re working in a organization where we need every idea, generous listening helps expand possibilities. In generous listening, it’s not the responsibility of the speaker to be interesting or to have something valuable to say. The generous listening puts the responsibility on the listener to find, “What’s valuable here? What am I listening to that is important? And I am responsible for increasing the quality of the conversation by the quality of my listening.” It’s a unusual approach to conversation, I find.

最も重要なリーダーシップ・スキル

インタビュアー:組織が目標を達成できないのには、2つ理由があると、おっしゃっていますね。その理由とは何ですか?

ウィーフリング:典型的な組織が目標を達成できない理由の、平均して上位2つに入るものは-第1位は、目標を持っていないか、目標があいまいであるか、みんなが目標を同じように理解していない、ということです。これは、失敗の原因としては防ぐのが容易なもので、どのリーダーも、これが原因で組織が失敗することがないようにする責任があります。
2番目によく見られる、組織の失敗の理由は、特にこの世界、グローバル経済の世界にあっては、コミュニケーションです。コミュニケーションは、ほかの人々を導き、ほかの人々に働き掛けるための唯一の手段です。ところが、コミュニケーションの最も重要な部分に関して、私たちはまったくといっていいほど指導を受けていません。それは、聞くということです。聞くことは、人々に忘れられてしまった、リーダーシップ・スキルなのです。誰でも話すことは達者です。

インタビュアー:だから、あなたはいわゆる「ジェネラス・リスニング(広い心で話を聞くこと)」を教えていらっしゃるわけですね?
ウィーフリング:ジェネラス・リスニングですね。(人が話を)聞くときはたいてい、相手の話の間違いを耳にそば立てるような感じです。こうした聞き方は多くの優れたアイデアを排除してしまいます。あらゆるアイデアを必要とする組織で働いている場合、ジェネラス・リスニングが可能性を広げることに一役買います。ジェネラス・リスニングの場合、話し手が興味深い人物だったり、有益な意見を持っていたりする責任はありません。ジェネラス・リスニングは、聞き手の側に、「ここで有益なことは何か? 自分が聞いている中で重要な部分はどこか? 私には、自分の聞き方の質によって、この会話の質を高める責任があるのだ」ということを理解する義務を課します。これは会話に対するアプローチとしては珍しいものだと思いますね。
ウィーフリング氏が挙げている組織が目標を達成できない理由のひとつ、「目標を持っていないか、目標があいまいであるか、みんなが目標を同じように理解していない」というのはよく分かる。ただし、リーダーがこれが原因で組織が失敗することのないようにする責任があるというのは、改めて確かにそうだよなと思った。

上の人たちの会議で、それは売り上げのためなのか、ステークホルダにいい顔したいからなのか、誰かにした約束のためなのか、目標が不明確な泥沼のやりとりを聞くことがある。顧客満足を達成するという目標が忘れられると、プレッシャーに負けて中途半端な品質のまま商品をリリースしてしまうことがあるように思う。これは必ずしも確信犯ということではない。ウィーフリング氏がいう「ジェネラス・リスニング(広い心で話を聞くこと)」をしないために、下の者達が本当のことを積極的にさらけだすことをしなくなり、結果的にリスクが見えていないという状況を自ら作ってしまっているのだ。

ようするに「見なかったことにする」が寄せ集まってリスクとなり、そのリスクがフィールドで発現してユーザーに迷惑がかかるという構図だ。リーダーがそれに怒って「ジェネラス・リスニング(広い心で話を聞くこと)」と反対のことをし出すと、ますます、下は正直なことを言わなくなりリスクは拡大する。

確かに、「ジェネラス・リスニング(広い心で話を聞くこと)」は最も大事なリーダーシップ・スキルかもしれない。
 

2008-11-01

さまざまなリーダーのタイプ

『リーダーになるための扉を開く』の続きで、今回が2/5回である。

ちなみに、このインタビューに答えているキンバリー・ウィーフリング氏は、女性でアメリカ、ペンシルバニア州生まれ、ゼロックス・バーク社の子会社であるアウトサイド社の元プログラムマネジメント副社長で、現在は、リーダーシップ、コミュニケーションの分野を中心に、企業の人材育成のトレーナーとして活躍中とのこと。ヒューレット・パッカード社での10年間にわたる技術管理および製品開発の経験を生かし、さまざまなハイテク企業の立ち上げにも貢献しているとのこと。
Leaders to Look for

Interviewer: Can you, maybe, describe some different types of leadership for us?

インタビュアー:さまざまなリーダーシップのタイプについて、少しご説明いただけますか?

Wiefling: Some leaders are loud and bold and crazy like me – make a lot of noise and tell people, “Come on, everybody! Let’s go and do this!” That’s a very charismatic leader. Sometimes, this is called the “rock-star leader.” Everybody knows them; they have a huge personality. Steve Jobs, head of Apple; he’s a rock-star leader; I say it like this; these kinds of leaders take up all the oxygen in the room.
Then there’s something called a “level-five leader.” Level-five leader is somebody who comes in day after day, weak after weak, year after year, constantly working for the good of the team, the organization. When something good happens, all the credit goes to their team. When something bad happens, they look in the mirror and say, “How did I contribute to this bad happening? And they are constantly focused, give, ten, fifteen, twenty years, leading companies to greatness.
This is the king of leader that Jim Collins writes about in a book called Good to Great. It’s very easy to be a good company, but in order to be a great company, you need a level-five leader.
Then there is a very quiet kind of leader called the “servant leader.” This person is behind the scenes, serving their people, leading from behind, removing obstacles, providing resources, encouraging and supporting them, not getting the credit, and not even appearing to lead sometimes. This is the kind of leader that Loa-tzu says, “That kind of leader, when the people accomplish their goals, they say, “We did it ourselves!”

ウィーフリング:私みたいに、うるさくと、大胆で、無茶なリーダーがいますね-いろいろ騒ぎ立てて、人に「さあ、みんな! これをやってみようよ!」と言うようなタイプです。これは実にカリスマ的なリーダーですね。「ロックスター型リーダー」と呼ばれることもあります。誰もが知っている、強烈な個性を持っている人物です。アップル社の最高経営責任者であるスティーブ・ジョブス、彼がロックスター型リーダーです。私はこんなふうに言うんです。こういうタイプのリーダーは部屋中の酸素をみんな吸い取ってしまう、と。
 それから、「レベル5型リーダー」と呼ばれるタイプがあります。レベル5型のリーダーは、来る日も、来る週も、来る年も、たゆまずチームや組織のために働き続ける人です。何かいいことが起これば、手柄はすべてチームのものとなります。悪いことが起きると、この手のリーダーは、鏡をのぞき込んで「今のこのまずい事態に、私はどう加担してしまったのだろう?」と問い掛けます。そして、5年、10年、15年、20年と、優れた企業にしていくことに、たゆまず力を注ぎます。
 これは、ジム・コリンズが『ビジョナリーカンパニー2-飛躍の法則』という本の中で書いたリーダーの種類です。良い企業をつくることは実にたやすいことですが、偉大な企業を作るためには「レベル5型のリーダー」が必要です。
それから、「奉仕型リーダー」と呼ばれる、非常に物静かなタイプのリーダーもいます。このタイプの人物は舞台裏にいて、部下に奉仕し、背後から導き、障害を取り除き、あらゆる資源を供給し、部下を励まし、支え、手柄を自分のものにせず、ときには指揮していないように見えることさえあります。こうしたリーダーは、老子が言うところの「目的が達成されると、部下の者たちが『私たちが自らの手で成し遂げたんだ!』と言うようなタイプのリーダー」です。
ちなみに、自分は偉大な企業を作ったり、組織を優れた企業にすることを目的としているわけではない。組込みソフトエンジニア、特に優秀な組込みアーキテクトが高い能力を持っているのに評価されない、クリエイティブな仕事ができない、能力が高ければ高いほどこき使われ仕事が増えるという状況を改善し、優秀な組込みアーキテクトを育てたいだけである。

しかし、組織の上位層やプロジェクトリーダー、技術リーダークラスを動かさなければどうにもこうにも、その目的を達成することはできないということが分かってきた。

組織内のリーダーと呼ばれる人たちがキンバリー・ウィーフリング氏が言うような素養を身につけていかなければ、我々エンジニアの明日はないのではないかと思う。または、自分自身がそのような素養を身につけてリーダーにならないと、自分やその下の者達が浮かばれないように感じている。だから、このようなリーダー論はソフトウェアエンジニアにとっても無縁なことではないと思っている。
 

2008-10-28

リーダーになるための扉を開く

ある雑誌に、米国シリコンバレーを中心に経営コンサルタントとして活躍するグローバル・マネジメント・プログラム(Global Management Programs=GMP) の講師である、Kimberly Wiefing 氏のインタビュー記事が載っていた。Kimberly Wiefing 氏のリーダーシップに対する考え方の一部を見ていただきたい。
Opening the Door

Interviewer: A lot of people will say that you’re either born to be a leader, or you’re not – that if you don’t already have the aptitude for it, you’ll never gain great leadership skills. What do you think about that?

インタビュアー:人がリーダーになるかならないかは、生まれつき決まっている、と言う人は多いと思います-もともと、リーダーとしての適性を持っていなければ、その後もリーダーとしての優れた能力を身につけることはないだろう、と。そうした意見についてどう思いますか?

Kimberly Wiefling: I totally disagree. I think anyone can be a leader if they care about something more than their comfort, if they care about something more than the approval of other people. You may see somebody who’s very quiet, who does not seem to be a great leader. But if you find something they’re passionate about, something that are willing to do something about to make a difference, they will suddenly become a much better leader.
Leadership is not about confidence. Many leaders are afraid. Many leaders are nervous or anxious or worried because they may fail. Leadership is about continuing in the face of fear of fear and being committed to your goals, even if you’re afraid, even if you are worried that you may not succeed or other people won’t like it, because you care more than about the goals than the approval of other people and your own comfort.
I have seen leadership in many faces – every different size, shape, culture, age, many different kinds of people in the right circumstances demonstrate leadership. My job is to open a door and say, “Would you like to step through the door of becoming a great leader?” Each person must make that choice. Everybody is capable of making choice in the right circumstances.

キンバリー・ウィーフリング:まったく賛成できませんね。自らの快適さや、他人からの賛同以上に大事だと思えることがあれば、誰でもリーダーになれると私は思います。とてもおとなしくて、優れたリーダーになりそうには見えないような人もいるでしょう。けれども、そうした人が情熱を注げること、変化をもたらすためにしてみようと思えることを何か見つけてあげれば、突如として格段に優れたリーダーになるはずです。

リーダーシップというのは、自信があるかないかではありません。多くのリーダーは恐れを抱いています。失敗を恐れて緊張したり、不安になったり、心配したりするリーダーは恐れを抱いています。失敗を怖れて緊張したり、不安になったり、心配したりするリーダーは大勢います。リーダーシップとは、たとえ恐くても、うまくいかないかもしれない、ほかの人が気に入らないかもしれないと心配でも、恐怖心に負けずに進み続け、目標達成のために力を尽くすことなのです。それは、他人の賛同や自らの快適さ以上に、目標を気に掛けているからです。

私は、さまざまな人の顔にリーダーの資質をみてきました-体格も体型も文化も年齢も異なる、実にさまざまな人々が、しかるべき状況でリーダーシップを発揮しているのです。私の仕事は、扉を開けて、「優れたリーダーになる扉の向こうに足を踏み入れてみませんか?」と言うことなのです。一人一人がその選択をしなくてはなりません。誰でも、しかるべき状況でその選択をすることができるのです。
キンバリー・ウィーフリング氏の発言で考えさせられるのは、リーダーシップとは自信があるかないかではなく、「たとえ恐くても、うまくいかないかもしれない、ほかの人が気に入らないかもしれないと心配でも、恐怖心に負けずに進み続け、目標達成のために力を尽くすことなのです。」と言っている点だ。「他人の賛同や自らの快適さ以上に、目標を気に掛けているからです。」というところにハッと気づかせてくれるものがある。

人間、どうしたって他人の賛同や自らの快適さに流されてしまいがちだ。目標に対して障壁があると、無意識に回避したいと考えてしまう。しかし、「優れたリーダーは失敗を怖れて緊張したり、不安になったり、心配したりしながらも、目標達成のために力を尽くす」とキンバリー・ウィーフリング氏は言っている。

「たとえ恐くても、うまくいかないかもしれない、ほかの人が気に入らないかもしれないと心配でも、恐怖心に負けずに進み続けることがリーダーシップだ」と言っている。

これを日本人できっぱりと言えるひとは少ないと思うし、まして、リーダーを育成するためのトレーニングをすることができる人もほとんどいないと思う。

創造性と個性にあふれた強い個人」を育む環境を持ったアメリカ人だからこそ言えることかもしれない。

でも、たとえ恐くても、「うまくいかないかもしれない」、「ほかの人が気に入らないかもしれない」と心配でも、恐怖心に負けずに進み続けなければいけないシチュエーションは、社会生活をしている上では少なからず発生する。そこを目標を見据えて乗り切ることがく必要なんだと思う。

その前提条件として、仮に壁を乗り越えられなかったとしても、進むべき道の先にある目標だけは常に認識していなければいけないのだと思う。目標を見定めることもできずに、自らの快適さや、他人からの賛同に流されているようではいけない。
 

2008-10-18

USとJapanの文化の違いと商品品質との関係

先日、日科技連主催の第15回 品質機能展開シンポジウムに参加してきた。

品質機能展開(Quality Function Deployment)は日本初の顧客の声を製品やサービスの開発につなげるための手法で、 新製品開発の現場など、多くの「ものづくり」の現場で国内・海外問わずに活用されている。シンポジウムでは QFD の生みの親である赤尾洋二先生も出席されていた。

シンポジウムの特別講演で GD3 コンサルティング代表/JMAC GD3 センター長 の吉村達彦氏の話を聞くことができた。(吉村氏の本:トヨタ式未然防止手法GD3―いかに問題を未然に防ぐか


吉村氏はトヨタ自動車に約30年務め、その後九州大学教授を経て、GM(General Motors)の Exective Director Reliability & Durability Strategy の仕事をし、GD3コンサルティング代表に至る。

そして、GMに3年間いてそのときに感じた日本とアメリカの文化の違いを表したのが冒頭の図である。

この図はこれまで自分が抱いていた日本人とアメリカ人の違いを端的に表していたのでここに掲載させてもらった。

この図が意味するところは、アメリカ人(吉村さんの経験ではGMのこと)はルールと責任はしっかりしており、システムやツールを構築することには長けているが、品質を心配する意識が小さい。一方、日本人(吉村さんの経験ではトヨタのこと)は、品質を心配する意識はとても大きいが、ルールや責任を重要視する姿勢は小さく、システムやツールの構築もアメリカほどは進んでいない。

どちらもバランスがいいとは言えないという話だった。

特に、アメリカのカルチャーの問題点として次のことを指摘されていた。

【アメリカのカルチャーの問題点】
  1. 明確に責任や役割を定義すると・・・品質は他の人の仕事だと思ってしまう。
  2. すばらしい支援システムを作ると・・・現地に行って現物を見て考えたり、心配したりする必要はないと思ってしまう。
したがって、品質を心配する意識をもっと大きくしなければいけない。製造業はエンジニアとテクニシャンの創造的技術・技能を製品に付加して利益を得ている業種であり、創造的技術とは問題を発見してそれを製品の価値に変換する能力である。発見するということはシステムやツールでできるものではなく、人間の行為であり、製品に価値を付ける上で意識がもっても大切であると説明されていた。

システムやツールで問題点を発見しやすくすることはできるけれども、そこには気づきが必要であり、気づくためには品質を心配する意識が必要であるということだ。

また、吉村氏は50%の品質を90%に上げること、すなわちだめな品質を良くすることと、90%の品質を99%にすること、すなわち良い品質をもっと良くすることは違うと言っている。

50%の品質とは問題は見えているが、積極的に解決をしていないし、再発防止もしていない状態で、これを解決する過程は知識も知恵もつくし、おもしろい。

また、責任体制やシステムを強化すれば、問題を積極的に解決するようになり、再発防止の体制もでき90%のレベルにはなるが、90%の品質を99%に引き上げるには品質を心配する意識が必要だというのだ。

実際、GMが作る自動車の品質レベルはクレームの件数で言えば日本車と変わらないレベルまで来ているという。しかしながら、顧客の信頼や安心の意識はまだ日本車のレベルに達しておらず、顧客はわずかか品質の差やデータ以外の事実や評判(イメージ)に反応するのだそうだ。

ようするに品質でお客様の信頼を獲得するためには、そこそこの品質(90%の品質)ではダメであり、99%の品質を目指さなければいけない。

吉村氏の話を組込みソフトウェアの世界に展開して現状を分析すると、次のようになる。
  • 日本の組込みソフトエンジニアは品質を心配する意識を武器にして製品のソフトウェアの信頼性を高めていた。
  • このときルールや責任は曖昧なまま。(「あたたかい人間関係の中のやさしい一員」という日本人の特長を活かしている)
  • システムやツールもアメリカほど発達していない。
  • 「品質を心配する意識」を糧にして、繰り返し修正を行いソフトウェアの品質を高めてきた。
  • ところが、ソフトウェアの規模が拡大してくると、このやり方では品質を保てなくなってきた。
  • 何が悪いのか見当がつかないので、欧米のやり方を見習おうということになる。
  • アメリカと日本を比較すると「ルールや責任」「システムやツール」が弱いことに気づく。
  • そこでアメリカ式のルールやプロセス、システムやツールを導入する。
  • そのうち、アメリカで起こっている問題「明確に責任や役割と定義すると、品質は他の人の仕事だと思ってしまう」や「すばらしい支援システムを作ると現地に行って現物を見て考えたり、心配したりする必要はないと思ってしまう」という悪いところまで導入されてしまう。
  • 結果的に、品質を心配する意識が縮小し、日本や日本人の特長が薄れ99%の品質を確保できなくなる。
こんな状態に陥っている組織はないだろうか。問題を可視化することは絶対に必要であり、それをしなければ話が始まらない。しかし、問題を可視化した後で、何かしらの気づきがなければ次のアクションを起こすことができない。多くの気づきが発生するためには、品質を心配する意識がプロジェクトメンバになければいけない。

『組込みソフトウェアの安全設計』の記事で次の図を紹介した。一番下の Safety Culture = 品質を心配する意識 がベースにないと、その上の要素は形骸化してしまうという話は今回の話に通じていると思う。

-ソフトウェア安全確保のための重要な要素-

□    Design & Verification
□□□   Methodologies & Techniques
□□□□□  Rules/Regulations
□□□□□□□ Safety Culture

※Rules/Regulations:Rules/Regulations for Safety Critical System development

2008-10-13

アメリカンなショッピングセンターCOSTCO

半年くらい前だろうか。車で30分くらいのところにCOSTCOという名のショッピングセンターができた。COSTCOのことは、数年間アメリカに住んでいた人にその噂は聞いていた。

COSTCOの特長は次のようなものだ。
  1. 会員制で顔写真入りの会員カードがないと入れない
  2. 会員になるには4000円払う。
  3. 買い物でカードを使う場合は特定のカード(基本はAmex)が必要
  4. 商品は使ってしまった状態でも返品可能。
  5. COSTCOに満足できなかった会員は会費を返してもらえる。
  6. いろいろな商品の割引クーポン券がもらえる
  7. 売っているものが安い(大量仕入れのため)
  8. 業務用と思われるような大容量の商品が多い。(例えば洗剤など)
ショッピングカートも巨大(最近は日本のホームセンターのカートも大きくなったが、それよりもさらにでかい)で、巨大な倉庫の棚に商品が山積みになっているというかんじ。

すべてがビッグな感じでアメリカンな感じがプンプン臭っている。一番日本と違うなあと思ったのは、ファストフードのコーナーだ。例えば、ホットドッグを頼むと大きな空の紙コップに紙に巻かれたホットドッグが渡される。

ホットドッグが包まれた紙を開けると細長いパンの間にソーセージだけが挟まっている。ホットドッグを買った客はこれを持ってトッピングのコーナーにいく。そこで、刻みピックルスとケチャップとマスタードを好きなだけかける。飲みのもは好きなドリンクが飲み放題だ。

雰囲気はまさにアメリカなので、その雰囲気を楽しみたい人には楽しいひとときになるだろう。

アメリカで暮らしていた人に聞くと、アメリカではこのCOSTCOの手厚い保証のしくみを悪用して、使用してしまった水着をいろいと文句を付けて返品してしまうような人もいるそうだ。年会費4000円の中には、このような返品補償費も含まれているということだろう。

ちなみに、自分がCOSTCOで買ったのは、ホットドッグだけで商品はひとつも買っていない。理由は売っているものの量が多い、大きいので多くの場合買いだめするような感じになるのだが、比較的安い小売りスーパーが家の近くにあるので、買いだめするよりも、少しずつ買う方がライフスタイルに合っているからだ。

例えば、COSTCOに売っている冷凍ピザは何しろ巨大だ。近所の人たちを呼んでパーティでも開くときにはぴったりだが、家族だけで一回だけ食べたいときには多すぎる。

COSTCOを見てふと思ったのは、アメリカのライフスタイルと日本のライフスタイルはやっぱり違うのだなあということだ。COSTCOのようなアメリカのスタイルをそのまま持ってきて日本のスタイルに合わせないという方法は確かに日本の市場へのインパクトが強く話題を呼ぶし、昔アメリカに住んでいたような人には郷愁を呼び、他にはないということからファンもできると思う。

でも、やっぱりその地で多くのユーザーに受け入れられるためには、その土地のマーケットニーズを取り入れる必要があるのではないかと思う。COSTCOが高付加価値の商品を専門に扱っているのならいいが、基本的には安売りで勝負しようとしているので、それなら安い商品を(大量に)買いたい日本の消費者のニーズに合わせる必要があるのだと思う。

ということで、4000円出して作った会員カードを返却しようかどうか今考えている。
 

2008-09-20

組込みソフトってなに?(高校生の質問から)その3

また、匿名の高校生さんからお題をもらったので答えていきます。

匿名 さんのコメント...

面白くて、わかりやすかったです。あと、いいホームページももらいました。ありがとうございます。確かに、自分が作った組込みソフトが組込 み機器に搭載され、お客さんに満足してもらえるならうれしいですね。将来の夢のために、もっと頑張らないと......学校の勉強でそれに最も関連のある 教科とか、最も使える知識とかはありますか。知りたいです!このやりとりで、ますます組込みソフトに興味を持つようになりました(笑)。普通の会話みたい に何の違和感もなく、すごく楽しいです。これからもお願いします。


さて、質問に答える前に組込みソフトの楽しさを全国の高校生に伝えようとしている二上貴夫さんから、君に向けて情報やアドバイスをもらったので伝えておきます。

まず、高校生向けの組込みソフト教育に関する状況について。マジカルスプーンは当初工業高校向けにカリキュラムを開発しており、その後、普通科の高校生向けの情報科学の教材としてのカリキュラムを開発していく予定とのこと。

都内の普通科の高校でデモンストレーションを行った結果、情報処理に強い興味を持った生徒がいて、彼らに対して特別カリキュラムを秋から実施するそうです。工業高校向けに少し専門的な組込みシステム開発の教育を飛行船を題材に実施することも企画中とのことです。(これ必ずしも自分の会社の仕事とは直接関係ない計画だからその情熱たるやすごいよね。こういう人たちが利益度外視でがんばっていることに感謝して、与えられた機会を有効に使って欲しいと思う。)

二上さんは、高校生の頃に社会人から情報を仕入れるのは良いことだと思うと言っています。また、君のように自分がやりたいことを外に向かって発信できる人は、よい組込み技術教育の教材を紹介すれば、かなりのところまで自分で学習できてしまうだろうと見ています。組込みの世界でアーキテクト(建築で言うところの設計士)として活躍しているエンジニアの生い立ちを紐解くとみなそのようなタイプだそうです。

また、前回紹介したETロボコンの他に Hamana というロケット打ち上げの実験プロジェクトや、MDDロボットチャレンジという取り組みも是非見て欲しいとのこと。

マジカルボックスのプログラミング教室というのをSESSAMEのメンバーでもある舘 伸幸さんが計画しているそうです。

ちなみに、自分が住んでいることろからイベント開催場所が離れている場合は、SESSAMEが費用を補助することも考えようと思っているので、資金のことで今一歩踏み出せないでいる高校生諸君は一度 SESSAMEの相談窓口 query@sessame.jp に「組込みソフトイベント参加の相談」という件名で相談メールを出してみて欲しい。

以下は二上さんの直接のメッセージ
私からのアドバイスとしては、7月、8月に出たCQ出版のボード付雑誌を買って(酒井注釈:CQ出版のInterface誌でたぶん7月号、8月号ではない。定価が高い号がボード付きの号。こちらから探すべし。)、自分で組み立ててこらん。わからなくなったら、著者に質問状を書こう。私から著者に取り次いであげるから。ただし、君が高校3年生で大学受験するつもりなら、ボードの組み立ては来春に私の実験室で一緒にやろう。(酒井注釈:東海大学 組込み技術研究科 組込み技術専攻 を受験して大学で一緒に勉強しようということだと思う)
【「(組込みソフトの仕事に就くには)学校の勉強でそれに最も関連のある教科とか、最も使える知識とかはありますか。知りたいです!」の質問へのアドバイス】

まず、アドバイスの前に伝えておきたいことがある。それは、「人から言われたことをそのまま鵜呑みにしちゃいけないよ」ということだ。これは「人を信じるな」「必ず疑ってかかれ」ということではない。人にはいろいろな考え方があって、僕が正しいと思ったことはもしかすると他の人はそうではないと考えているかもしれない。世の中にはいろいろな考え方があって答えがひとつではないことがたくさんあるということを認識して欲しい。

現に、組込みソフトってなに?の回答に対して、stpete97 さんはもっと違う組込みソフトの世界もあると書いている。(こちらの記事) 21世紀の組込みソフトの世界という意味ではセンサーやアクチュエータを使わないような世界もある。組込みソフトといっても何しろ幅が広いので「コレが組込みソフト」と一刀両断では答えられない。だから、ひとつのアドバイスを鵜呑みにしてはいけないし、最後はいろいろな意見や考え方を聞いた上で、自分が持っている価値観に照らし合わせて咀嚼することが必要だ。ただ、高校生という年代は自分の価値観を構築する時期でもあるので、いろいろなことに首を突っ込んで世の中の多くのことにアンテナを張り巡らせ感度を高めておくことがよいと思う。

次に、考えて欲しいのは自分の人生という長い年月のことだ。例えば、君が80歳まで生きるとしよう。そうするともし君が今17歳なら人生はまだ、全体の21%しか進んでいないことになる。この後大学に進んだとして、就職して仕事について定年を迎えるとすると、社会人として働く期間はだいたい38年間で一生の48%となる。だからこそ、人生の約半分を費やす社会人として期間どんな仕事をするのかを選択するのは非常に重要な選択だ。

ただ、よくよく考えてみて欲しいのは、それでもその38年間は人生の約半分に過ぎないということだ。社会人を卒業してからの人生も20年近くある。また、30歳くらいで結婚したとしたら人生の62.5%は新しい家族との生活があるということになる。

何が言いたいかというと、人生を80年と考えれば、17歳くらいの君が学んでいること、過ごしている時間で何に役立つかはそう簡単には言えないということだ。

そのことを前提にして、今人生の約半分くらいまで来ている自分が過去を振り返って、君が学んでいることが何に役に立つかについて自分の考えを書いてみたいと思う。(鵜呑みにしちゃいけないよ)

【英語】

実は中学、高校、大学と一番きらいな教科が英語だった。なぜかというと、自分は英単語を覚えるのが苦手だったからだ。必ずしも記憶力が悪いということではなく、今後の人生において役に立ちそうにないと思うとやる気がなくなって学習する意欲が低下し、結果として勉強が進まなかった。あまり我慢強い性格じゃなかったんだ。

その当時、自分は日本を出て海外で働くような夢はなかったし、そうしたいと思ったこともなかったし、英語が分からないことで得られない情報などないと思っていたから、英語は大人になっても使うことはないというちょっとした自信があった。

でも、社会人になってから以外に必要だということが分かってきたね。その当時、社会人の人たちに英語は使うから勉強しておいた方がいいよと言ってもらいたかった。だから君には英語は勉強しておいた方がいいよと言っておくよ。

何に使うのかというと、まず、海外で作られたハードウェア部品やソフトウェア部品のカタログや取扱説明書は英語で書かれていることが多く、日本語に翻訳されていない場合もあるから英文を読む必要がある。また、日本で作った商品を海外で売るためには、国際規格を理解しないといけないことがあるけれど、この国際規格はフランス語と英語で書いてある。

さらに、インターネット上の情報で特定の分野においては日本語のサイトよりも英語圏のサイトの方が圧倒的に多くの情報が存在するケースがある。例えば、ソフトウェアの構築方法について書かれたソフトウェアアーキテクチャ(Software Architecture)については、英語サイトの方が情報量が多い。だから、英語が分かっていると最新の情報をゲットできる可能性が高い。

もう一つ、場合によっては君は外国人と仕事をすることがあるかもしれない。グローバルな世界で部品や商品を売り買いしていると、自ずと海外の人たちとメールを交わしたり、打ち合わせしたり、出張したりする機会も出てくる。そのときに英語が話せるととても楽だ。

ということで学生時代、なかなか身につかなかった英語は、社会人になってからお金も使いつつ、ちょっとずつ勉強している。いまではどんなことに役立つのかイメージがわいているので、辛いながらも意欲は持ちながら勉強できているのでまあいいかと思うけど、学生時代に英語が自分の人生の中で役に立たないと決めつけてしまっていたことは間違いだったと素直に認めるね。

全然関係ないけど、英語の授業で今でも覚えているのは中学生のときの先生がテープレコーダを毎回持ってきて英語の歌を生徒に聞かせてみんなで歌えるようにしてくれたことだ。

もちろん、そんなことは学習指導要領には書いてないから先生のオリジナルの授業だった。そのとき歌った歌は次のようなもの。

「花はどこへ行った」(原題 Where have all the flowers gone?)

ザ・ブラザース・フォア が歌ったものを先生は聞かせてくれた。そのときは何のことを言っているのかまったく分かっていなかったし、先生もわざわざ解説しなかったけど、大人になってから知ったのはこの曲は世界で一番有名な反戦歌でフォークの不朽の名曲だったんだ。

「We shall overcome」 アメリカ公民権運動のテーマ・ソングのように歌われた歌で、アフリカからヨーロッパを回って奴隷としてアメリカへ連れてこられた人たちの、船上での労働歌のようなものだったという歌。その当時はそんな背景はまったく知らなかった。

「Country Road」 ジョン・デンバーの作詞作曲で、このときはオリビア・ニュートン・ジョンが歌っていた。最近では宮崎駿監督の耳を澄ませばで挿入歌として使われていたね。

中学生レベルでネイティブな英語の歌詞を歌えるようになるのは至難の業だったけれど、今でも覚えているんだからもっともインパクトのある授業だったと思う。

【国語】

ソフトウェアとはまったく関係がないように見えて実は大いに関係があるのは国語だと思う。プログラムもアセンブラというコンピュータが解釈するための言語で書いていたときはそうでもなかったけれど、C言語などの高級言語と呼ばれる、より自然言語(もちろん英語)に近い言語でプログラムが書かれるようになって、プログラミング=やりたいことを文章で書き表すに近くなってきた。

だから、極端に言えば分かりやすい文章を書く人は分かりやすいプログラムを書く傾向があるように思う。自分自身にしか分からないようなトリッキーなプログラムを書く天才プログラマーと呼ばれるエンジニアも中にはいるけれど、そういう人が書いたプログラムは多くの場合その人しかメインテナンスできないので、チームで仕事をしたり、同じ人がずっとその製品の担当になれない場合が増えてきた現在では、分かりやすいプログラムを書くことがもとめられている。

また、ソフトウェアは市場やユーザーの要求を図や文章で書き表し、それをもとにしてプログラムを書くことになるので、文章の読解力や作文の能力は高い方がよい。

先人の成功や失敗が体系化されたソフトウェア工学を勉強する際には書籍を読むことでそれらの知識を吸収することも多いから、長文読解能力は特に求められる。「こいつは何を言いたいんだ」ということができるだけ早く分かるようになることが重要なんだ。また、ソフトウェアでは他の人が書いたドキュメントをチェックするレビューという行為を頻繁に行うのだけれども、このときもいかに大量のドキュメントを斜め読みして、重要なポイントがどこかあたりを付ける能力が求められる。

【数学】

数学は言わずもがなソフトウェアの世界ではよく使う。ソフトウェアの世界では解を求めるときに総当たりで見つけ出すのが得意で、大きな数字同士の最大公約数を求めるような問題は自分でやるとうんざりするけれど、コンピュータは繰り返し演算させてもイヤだとはいわない。

そういう意味では個人が使っているようなパソコンの計算の仕方で美しくないなあと思うことはある。例えば、分数を使った演算は分数のままで表しておけば割り算をしないので誤差はゼロだが、一般的なコンピュータでは途中の計算でどんどん割り算を繰り返してしまうので誤差が生じてしまう。誤差を最小限に抑えるために浮動小数点演算を行うこともできるけど、誤差がゼロになるわけではない。そういう観点から分数演算は美しいと思うし、ソフトウェアの世界は最新の数学の世界に追いついていないところもまだまだあるように思う。

【物理】

組込み機器でセンサーやアクチュエータを使う可能性があるのなら物理学は必ず使う。自然界で起こる現象を物理法則で表して、その法則をもとにセンサーやアクチュエータを動かすことになるからだ。

【生物】

生物はどんな組込みソフトの分野に進むのかによってはとても重要な学問となる。あんまり詳しくはいえないけど、自分の仕事では生物学はとても重要だし、生物学が一番好きだったから今の仕事を選んだとも言える。なぜ、生物が好きだったかというと、それは自分自身の体の中で起こっていることが説明されていたからだ。そこには内なる宇宙が広がっていて、信じられないような精巧なメカニズムで生命を維持する活動が行われている。植物は地球上で光合成により最も効率よく光のエネルギーを化学エネルギーに変換し、二酸化炭素から酸素を作りだし、夜は夜で呼吸によりエネルギーを作れる。

その頃は勉強しなければいけないからではなくて、おもしろいから教科書や参考書を何度も読み直したし、25年以上たっても DNAの情報からミトコンドリアがタンパク質を作り出すしくみなんかは覚えている。

【地理・歴史】

地理や歴史もソフトウェア開発には役に立たないと思うだろう。確かに、ソフトウェアエンジニアには必須の教科ではないかもしれない。でも、最初に書いた人生80年のことを思い出して欲しい。

人生80年の中で、必ずしも仕事の関係だけではなく日本国内のいろいろな地域の人、または海外の人と交流することはある。そのときに大事なのは、その人の地域のことについてある程度知っていることと、さらに大事なのは自分の地域や日本のことについて説明できるということだ。

海外の若者は自分の国のことを説明することがうまいのに、日本人は日本のことをうまく説明できないと聞く。そういう場面に慣れていないのかもしれないが、日本人として誇りのようなものを持つことがピンとこない、そんなことをしなくても普通に暮らしていけるからだろう。でも、今後商品作りは間違いなく世界が市場になる。大田区の町工場でロケットの先端部分が作られていることからも分かるように、世界のどこの人々から部品を入手し、どの国の人々へ商品を届けることになるのかはわからない。

ソフトウェアエンジニアはそんなことを知らなくてもいいかと言えば、知っていていろいろな国のいろいろな業種の人々とコミュニケート出来るようになっていた方が当然のことながら自分の器が大きくなる。

海外のエンジニアと親交を深めることで飛躍的にスキルがアップすることもあるだろう。

【問題解決能力】

学校の授業で教えるようなものではなく、社会人になると必要になる能力、それが問題解決能力だ。簡単に言うと、学園祭でバンドをやりたい、メンバーを募ってライブを盛り上げたいと思い、幾多の障害を乗り越えながら成功させるといった経験を積むことでこの能力は高まっていく。

何か作りたいものがあって、いろいろな情報源や道具を使いながら自分の力だけで完成させるというのも問題解決能力を高めることにつながる。

与えられた問題をひたすら解いていい点数を取ることでは、決して身につかない。くわしくはこちらの記事を読んでもらいたい。

【放課後】

さて、組込みソフトエンジニアとしての道を進みたいと考えた場合、大きな分岐点があると思う。それはプログラミングすること=ソフトウェアを作ることが好きなのか、それとも何か特定の分野のことが好きで、その分野の中でソフトウェアエンジニアになりたいのかという選択肢だ。

前者の仕事をする一つの例としてサプライヤーと呼ばれるソフトウェアの受託開発会社がある。ソフトウェアの開発を請け負って、ソフトウェアをクライアントとなる商品開発メーカーなどに納めるような場合。また、技術者の派遣会社に入って、ソフトウェア技術者としていろいろな会社に派遣される仕事に就くこともある。

非常に規模の大きい会社でどんな分野の商品を作ることになるか分からないけれど、例えばソフトウェアエンジニアとしてのスペシャリティを活かして商品作りに関わる人もいる。

一方で、車好きな人、鉄道が好きな人、宇宙ロケットが好きな人、音楽が好きな人がそれらの分野の会社に入って、その分野の商品を作り上げる過程において組込みソフトエンジニアとして働くということもある。

自分はSESSAMEのメンバーでTEACの國方さんという人を知っているが、TEACは自分の中では音響機器(特に録音機器)の会社で、國方さんは音楽が好きな組込みソフトエンジニアだ。SESSAMEではバンドを組んだり、技術者の教育教材を作るためのセミナーで講演者の音声を自分が開発した機材を使って録音したり、後で聞きやすいように編集したりしている。

ようするにある分野に強い興味があって、その分野において組込みソフトエンジニアとして働きたいのなら、当然のことながらその分野のことは徹底的に詳しくないとよい製品を作ることはできない。

音楽機材を作る仕事がしたいのなら音楽のことを知らないといけないし、自動車作るのなら自動車のしくみ、鉄道の仕事するのなら鉄道の知識といった具合だ。

これは、どっちかというと勉強しなければいけないことではなくて、今君が何に興味を持っていて人から言われなくても調べてみたい、知りたいと思うことは何かということだ。

ちなみに、現時点で興味があるのはソフトウェアや組込みソフトウェアであり、後から関心の強い分野が出てくる、もしくは、その仕事に就いた後からその分野が好きになるということもあるので、今すぐに何が好きか決めろということではない。

だから、教科別の最後のアドバイスはあまり範囲を狭めるのは得策ではなく、若いうちは興味があると思ったら飽きるまで徹底的に突っ込んで満足いくところまでやってみるという経験を重ねておくことが大事だということを言いたい。

そうなると、学校の授業も大事だし、それ以上に放課後に何をするのかということも大事になる。SESSAMEのメンバーが仕事を持ちながら、プライベートな時間に活動しているのと似たような話で、一見関係ないような活動でも、実はそれぞれが相乗効果になっていることも少なくない。

全部精一杯頑張れというような内容になってしまったけれど、まあ、いろいろチャレンジしてみることだね。組込みはやってみないことには楽しさはわからない、これは間違いないと思うよ。今の時期は「クリエイティブで楽しい」「クリエイティブでおもしろい」という経験をたくさん積み重ねることがもっとも大事だと思う。小さい楽しい、おもしろいを経験すると、より大きな楽しい、おもしろいを経験したくなる。そうなると技術的な壁が現れるけれど、最初に楽しい、おもしろいという体験を持っていると、一時期辛くてもその壁を意欲をもって乗り越えることができるんだ。

そのことを学生のうちに経験しておけば、その経験は間違いなく社会人になったときに役に立つことは保証します。

組込みソフトってなに?(高校生の質問から)つづき

匿名の高校生さんから追加情報をもらった。

3 コメント:

匿名 さんのコメント...

すみません、初めてのコメントです。実は私、高校生なんですが、組込みソフトに興味を持っています。今、私たちの生活の中で(身近なところ)よく使われている組込みソフトってなんですか。答えてくれるならすごくうれしいです。お願いします。

sakai さんのコメント...

組込みソフトウェア工房の管理人です。

たぶん一度では答えられないので何度かやりとりしましょう。

「組込みソフトとは何か?」これに答えるにあたって一番の大事なのは高校生の君がなぜそれを知りたいと思ったのか・・・これが問題です。

1. 学校の授業で「組込みソフト」の話がでてきたから
2. 何かおもしろそうな感じがするのでどんなものか知りたいから
3. 進路について組込みソフトの仕事につくことも考えているから
4. 親が組込みソフトの仕事をしているのだけれど教えてくれないから
5. その他の理由

この中のどれ? 例えば、1とか2なら組込みソフトでワクワクするイベントや教材を紹介するし、3や4ならどんなところが楽しいのか、どんなところが大変なのかを中心に答えを考えます。

こんな日記風の説明もありますが、もう少し情報をください。

匿名 さんのコメント...
組込みソフトってなに?(高校生の質問から)を読んで

ありがとうございます。わかりやすかったところもありますし、少しわかりにくいところもありました。私は元々ソフトウェアに興味を持っていて、将来 ソフトウェアに関する仕事につきたいと考えています。その中でも、特に組込みソフトに強い関心を持っています。ってことは、2. 3.ですね(笑)。ぜひ、組込みソフトについていろんな話を聞かせてください。


もしも、君が組込みソフトに興味を持っていて、将来組込みソフトの仕事につきたいと思っているのなら、おすすめのアプローチは『習うより慣れろ!』作戦だ。

まずは昔話から

実は組込みソフトは社会人になってからでしか始められないかというと、今はそうではない。30年前は高校生が組込みソフトをやってみたいと思っても難しかったね。

実 際、自分が大学生のとき日本で初めて個人でも使えるパーソナルコンピュータPC-8001がNECから発売された。もともと外国製では Appleのコンピュータがあったけど何十万円もしてとても手が出なかった。PC-8001も高かったので結局は買えず、その弟ぶんのパソコン PC-6001が出たとき7万円くらいで買った。これは家庭にあるテレビにつないで画面を見るタイプのパソコンでプログラムはなんとこれも自分が持ってい るテープレコーダに音声情報として録音していたんだ。

このときはパソコン雑誌に載っているプログラムのリストをキーボードから打ち込んで は実際に動かして遊んでいた。でも、打ち込むプログラムがだんだん多くなってくるとプログラムリストを紙に打ち出したくなる。でもプリンタが高い。モノク ロでしかも一行ずつ文字しか打てないインクリボン式のプリンタがパソコンと同じく7万円もしたんだよ。でも、どうしても欲しかったからアルバイトしてお金貯めて買ったなあ。

パソコンの価格だけは時がたつにつれて安くなるので驚きだね。いまや7万円で高性能なディスプレイ付きのパソコンが買えるし、カラーのインクジェットプリンタは1万円台で買える。(消耗品のインクで儲けているからプリンタはほとんどタダ同然でもいいんだ)

だから、君はすでにパソコンを持っているという前提で話しをするよ。

君 がパソコンを持っていてインターネットに接続する環境があるのなら、プログラムを作ってみる方法はたくさんある。今はインターネットで世界中がつながったことで、無償でソフトウェア開発の環境を提供してくれる個人や企業もたくさんあるし、わからないことがあったら親切に教えてくれるしくみもそろっている。

だけど、君が組込みソフトに興味を持っているのなら、おすすめのコースは別にある。

前回の記事に書いたように組込みソフトはセンサーとアクチュエータがあると格段におもしろい。センサーとアクチュエータを積んだ組込み機器に自分が作ったプログラムを載せて、いろいろ試してみると自分が作ったプログラムの通りに組込み機器が動くから楽しい。

実は、こんな教材を高校生向けに考えてプロデュースしている二上 貴夫というおじさんがいるんだ。この人はとてもおもしろい人で、サラリーマンとして仕事を持っていながら組込みソフトの楽しさを多くの人に伝えることができるのなら寝食を忘れてがんばっちゃう人なんだ。

科学の楽しさをわかりやすく子供達に伝える活動をしている米村でんじろうさんは知っていると思うけど、二上 さんは組込みソフトの世界では有名な組込みソフトの楽しさを伝える伝道師なんだよ。

その二上さんが最近開発した飛行船をプログラムで制御するキット「マジカルスプーン」というのがある。

現在はマジカルスプーンシミュレータが約7千円で通販で買える。二上さんは今マジカルスプーンリアルを開発していてもうしばらくすると買えるようになるよ。

マジカルスプーンはスプーンをたたいて出る超音波で命令コードを作り(=プログラム)をセンサーでこの超音波を拾って飛行船を制御するんだ。なんだか、わくわくするでしょ。

簡単な説明は、自分も所属している組込みソフトの教育を考えるコミュニティSESSAMEのこのページを見て欲しい。

また、二上さんに負けず劣らず、組込みソフトの楽しさを伝えるのにがんばっちゃっているおじさん、おばさん(おねえさんと言わないと怒られるかも)達は何人もいて、この中の舘 伸幸さんたちがマジカルスプーンのことをWEB上で連載記事として書いているのでこれも読んでみて欲しい。

最後にもう一つのおすすめは、もし君が関東近県に住んでいるのなら、レゴで作った車にプログラムを載せて動かすETロボコンのチャンピオンシップ大会がパシフィコ横浜で11月19日~21日のどこかであるのでこれを見てみたらどうかと思う。チャンピオンシップ大会は平日になるので学校の先生に正直に話しをして休みをもらって見学しに行こう。組込みソフトに夢中になっている学生や社会人達の情熱が伝わってくると思うよ。

以上、これが組込みソフトを知る『習うより慣れろ作戦』の全貌です。また、何かもっと聞きたいことがあったらコメントをください。このやり取りのことは仲間のおじさん達にも伝えておくので後でアドバイスをもらっておきます。

そ れと、『習うより慣れろ作戦』で組込みソフトの楽しさを満喫したら、次は職業として組込みソフトエンジニアになることについて真剣に考えてみて欲しい。 仕事で組込みソフトを作るのは自分が楽しければいいってもんじゃないから、時には辛いことも乗り越えなければいけない技術的な壁もある。でも、自分が作っ た組込みソフトが組込み機器に搭載されお客さんに満足してもらえることが分かると、喜びや辛さを繰り返しながら、それらの壁を乗り越えることができる。だから、まずは何が楽しいのか、おもしろいのかを実感した上で、職業としての組込みソフトと組込みソフトエンジニアについて考えて欲しいと思う。
 

2008-09-16

組込みソフトってなに?(高校生の質問から)

組込みソフト開発におけるプロセス改善』の記事に匿名さんから次のようなコメントをもらった。
すみません、初めてのコメントです。実は私、高校生なんですが、
組込みソフトに興味を持っています。今、私たちの生活の中で(身近なところ)よく使われている組込みソフトってなんですか。答えてくれるならすごくうれしいです。お願いします。
そもそも、このブログを始めた最初の目的は読者との双方向コミュニケーションなので、いただいたお題に対して答えてきたいと思う。(=○○)の記述は大人向けの解説。

自分は組込みソフトを説明するときにこの絵を使うことが多い。

まずは、一番左を見てもらいたい。

そもそも、人間が生活していく上であると便利なものはたくさんある。便利なものがあってもオーダーメードで作っていたのでは多くの人に使ってもらうことができない。

だから、加工しやすい部材を使って同じ働きをするものをいくつも作ることを人間は考えた。加工しやすい部材とは古くは木材であっただろう。今でも木はさまざまなものに加工され商品となっている。

その後、電気で動く部品(トランジスタなど)が発明され、定電圧で動くさまざまな電子部品、機械部品が作られて流通するようになった。これらの電子部品、機械部品の中にはセンサーと呼ばれる外界の状態をセンシングする電子部品や、モーターのように物理的に物体を動かすことのできるアクチュエータと呼ばれる機械部品もある。

これらセンサーやアクチュエータは、総称してハードウェアと呼ばれる。ハードウェアは決められた入力に対して決められた動作をする。それぞれのハードウェアにはデータシートもしくはスペックシートという取扱説明書がついている。ハードウェア部品を利用するエンジニアはこの取扱説明書を見てある目的を達成するための機器を作ろうとする。

センサーを使うと外界の状況を機器に取り込むことができる。また、アクチュエータにある入力を与えると何らかの動作をさせることができる。

センサーとアクチュエータを組み合わせると、外界の状況に合わせて組込み機器に何らかの動作をさせることができそうだ。ところが、センサーからの出力をアクチュエータに直接つないで期待通りの動きをさせることができるかというとなかなかそうはいかない。

センサーからの出力を期待通りの動きになるように変換してからアクチュエータに入力してしなければいけない。

このハードウェアとハードウェアの間に入って信号を変換する役割を担うのが元祖組込みソフトウェアだ。(上図の左)

組込みソフトウェアはCPU(中央演算装置:Central Processing Unit)という特殊なハードウェアにプログラムで命令を与えることで、信号をいろいろな信号に変換することができる。プログラムは書き換えることが可能なので、いろいろな信号の変換を試してみて「これでいける」と思ったら完成したプログラムをROM(Read Only Memory)と呼ばれる電子部品に書きこんで組込み機器に搭載する。(=設計情報の転写)

ハードウェア部品群とハードウェアとハードウェアをつなぐソフトウェアが協力しあって組込み機器が完成する。ハードウェア部品もソフトウェアも同じものを大量に生産できるので工場で部品を組み上げて消費者に届けることができる。(=設計から生産へ)

上図の左で、ハードウェアとハードウェアの隙間を埋めるような感じでソフトウェアを描いているのはソフトウェアにこんな特長があるからだ。

もうひとつ別な見方をすると、ユーザーや市場が欲しいと思うものに対して、メーカーは何らかのキーデバイスを選択して「こんな素晴らしいハードウェアを使った商品なんですよ」と宣伝する。

例えば薄型テレビのキーデバイスはもちろん液晶パネルやプラズマのパネルだ。このキーデバイスが表の顔であり、この表の顔にユーザーは惹かれる。(=コアコンピタンスとしてのハードウェア)

しかし、大抵の場合キーデバイスだけでは組込み機器に目的の動作をさせることはできない。ユーザーやマーケットが欲している機能や性能を実現するためには、キーデバイスの能力を引き出すソフトウェアが必要になる。これが組込みソフトウェアだ。(=コアコンピタンスとしてのソフトウェア)

ユーザーやマーケットの要求が複雑でかつ多様になるにつれ、組込み機器における組込みソフトの割合は大きくなってきた。

最初の絵の左から右への変遷がその様子を表している。今ではソフトウェアの分量は20年前の100倍から1000倍以上になっており、ハードウェアとハードウェアの隙間を埋めるためだけの役割だけではなくなってきている。

ソフトウェア自体を再利用可能な部品にしてそれらを組み合わせることもしないと、ソフトウェア作りが間に合わなくなってきた。(=ソフトウェアプロダクトラインの必要性)

昔はハードウェアとハードウェアの間を埋めるだけの役割をソフトウェアが担っていたので、試作品に対して何らかの入力を与え出力をチェックしながらプログラムを直していって「これで完成」という時点でソフトウェアをフィックスすればよかったが、今ではそんなやり方をしていたらソフトウェアが固まるまで何年もかかってしまう。(=Verification & Validationの計画と実行)

商品を作って他社との競争に勝つためには開発のスピード、商品が提供する機能や性能及び品質が大事になる。(=マーケティングと要求品質定義、トレーサビリティ)

ハードウェアは故障することで製品の品質を悪化させるが、ハードウェア部品の故障を最小限にするための技術は長い年月をかけて確立してきたと言える。(=故障解析、歩留まり)

一方でソフトウェアはバグと言われる意図しない動作をするプログラムが入ったまま製品を出荷することで製品の品質を悪化させる。これが市場で見つかるとメーカーは製品を回収してプログラムを正しいものに入れ替えたりする。(=リコール)

ではバグをなくしてから製品を出荷すればよいのに・・・と思うだろう。それはそう簡単ではない。例えば、400字詰めの原稿用紙で100枚ぶんの作文を書いたとしよう。この4万字の作文の中で誤字脱字を一個もない状態にするにはどれくらいの時間がかかるだろうか。

100枚の原稿を何回も何回も見直したりしていると、ふとこ「この文章を直しておきたいなあ」と思うこともある。手書きの原稿ならいざ知らず、今はパソコンで簡単に直せるので余り気にせずに直してしまう。これを何回も何回も繰り返していると、いつの間にか直す前の文章と直した後の文章がどれがどれだか分からなくなりごちゃごちゃになってしまったりする。(=構成管理、変更管理の必要性)

組込みソフトでもこれと同じことが起こる。100万行にも膨れあがったプログラムを一点のミスもない状態にするのは至難の業であり、時間もかかるし、みんなの知恵を借りていろいろなくふうをしないといけない。(=ソフトウェア工学の利用)

最後に、ひとつ現代の組込みソフトエンジニアのやりがいというプラスの面を書いておこう。ハードウェアは決まった動きをする要素部品であり、ハードウェアエンジニアは目的を果たすためにどのハードウェアをどのように組み合わせればよいかを考え、その考えを製品で実現し大量生産できるようにする。(=組み合わせとすり合わせの組み合わせ技術)

ソフトウェアエンジニアはハードウェアの構成が決まれば、勝負の世界は自分が書くプログラムにゆだねられる。毎日のプログラミングの積み重ねが商品の善し悪しを決定する。(=組み合わせとすり合わせ技術のすり合わせ技術)

ある意味、自分の技術や努力の結果が商品の品質にストレートに影響するとも言える。ようするに腕のよいソフトウェアエンジニアが書いたプログラムが高い商品価値を生み出すということだ。技術的な成長を反映させやすい、また成果を実感しやすい仕事であるとも言えるだろう。

また、ハードウェアとソフトウェアが協力して合って組込み機器ができあがるため、特にアクチュエータが使われていると物理的な動きが見えてきて機器が完成して自分の思い通りに機器が動いたとき喜びが大きい。そして、自分が作ったソフトウェアが組込み機器に載って多くのお客さんに使ってもらえるという喜びもある。これらが組込みソフトの醍醐味である。(=組込みソフトエンジニアのモチベーションの源泉)

以上、「組込みソフトってなに?」の疑問の解消にこの記事が少しでも役に立てれば幸いである。
 

2008-09-01

ソフトウェア工場 vs アジャイル どっちが組込みに向いている?

先日、「Rational Team Concert にみるソフトウェア開発におけるチームコラボレーション支援について」というタイトルの講演(講師 日本アイ・ビー・エム株式会社ソフトウェア事業 Rational テクニカルセールス&サービス 藤井 智弘氏)を聴いた。

簡単に言うと、IBMによって開発された統合開発環境のEclipseを開発したチームが使用したチームコラボレーション支援ツールを一般向けに使えるように整備するというプロジェクトの話しだ。

オブジェクト指向におけるデザインパターンの有名な本の著者 GoF (Gang of Four) の一人、Erich Gamma もこのプロジェクトにスイスから参加している。

ものすごく表面的でやじうま的な見方をすると、Microsoft が提唱した Software Factories の開発手法とまったく正反対のアプローチを IBM Rational が打ち出した・・・ように感じた。

【Microsoft の Software Factories】

Software Factories の考え方は、開発から運用までのソフトウェア・ライフサイクルの効率化を開発者の側に立って推進する「Dynamic Systems Initiative(DSI)」がベースにあって、Microsoft の戦略に乗っかるのならば、Visual Studio Team System を使っていくことになる。

どちらかと言えばトップダウンのアプローチであり、ソフトウェアプロダクトライン、ドメインエンジニアリングの考え方も踏襲されていて、非常にシステマティックだと感じるし、これまでのソフトウェアエンジニアリングの延長線上にあるように見える。

ただひとつだけ引っかかるのは、優れたアーキテクトがプロジェクト内にいない状態でSoftware Factories のアプローチを進めていくには無理があって、どうしてもやりたい場合はVisual Studio Team System を使うことで Microsoft が用意したアーキテクチャやソフトウェア資産を使うように誘導されてしまうような気がする点である。

また、Visual Studio Team System を使いこなすだけでもソフトウェアエンジニアに相当量の学習が必要がある。ある程度システムの全体構成を構築できてしまえば、その後の開発が飛躍的に効率化できるようになるものの、そこに達するまでのハードルが高いという印象がある。

【IBM Rational の Team Concert】

一方、IBM Rational Team Concert を利用した Jazz プロジェクトは、「分散」「アジャイル」「コラボレーション」といったキーワードからわかるように、どちらかと言えばボトムアップのアプローチで巨大ソフトウェアシステムの開発を成功に導こうとしている。

これまで Agaile は大規模システムへの適用は困難と見られていたが、IBM Rational Team Concert はAgaile のアプローチの人力で提唱されていた部分をすべてシステムに取り込んで、数百人の規模の開発でも、Agail の効果を最大限に引き出すことを目的にしているようだ。

実際、Eclipse の開発で成功した実績があるのだから説得力がある。

Rational Team Concert では、日々の作業はワークアイテムを中心に回っていく。ワークアイテムは「反復する計画と関連するワークアイテムの管理」「ソース管理」「ビルド」「レポート」を含む。

ある拠点に置かれた大量なトランザクションを処理できる強力なサーバー(おそらくはIBMのサーバー)を中心にして、世界中のプログラマーが WEB上のポータルサイトを共有するような感じで、プロジェクトの状況をリアルタイムに見ることができる。各人の写真も掲載され、チャットもできるし、プロジェクトリーダーやコンポーネントの責任者からの指示も共有できる。

共通環境で管理されるのはユーザー間の情報のやりとりとソースファイルであって、分散された環境でそれぞれが持っている個々の開発環境はあまり制限せずに、それらの環境への URL によるリンクのみがツール上で飛び回ることになる。

一方で、プロジェクトの状況は自動的にグラフ化され、それらのグラフを眺めることで開発の進捗を確認したり、品質を推し量ったりできる。

ソース管理に関する機能は重要視されていて、リーダーは各チームが勝手にソースをチェックイン、チェックアウトできなくすることも可能。(チームのコンテキストにより運営ルールをダイナミックに変更できるというところが Rational Team Concert が単なるコミュニケーションツールではなく、コラボレーションツールであるという理由)

【組込みで使えそうか?】

「Rational Team Concert にみるソフトウェア開発におけるチームコラボレーション支援について」の講演を聴いていておもしろかったのは、ソフトウェアシステム開発におけるアーキテクチャの話しはほどんど出てこない点だ。アーキテクチャはコンポーネントアーキテクチャだとのこと。要するにソフトウェアのモジュールをコンポーネントに分けるところまでが重要なポイントで、後は繰り返しリリースを重ねる過程で最適化していくというような考え方に聞こえた。

大人数での Agile 開発での注意点は「コミッターボード」「ガバナンス」「チェックインの制限」ということで、ソフトウェア技術者に勝手気ままにやらせない上手なコントロールをツール上で提供することだということだった。

Rational Team Concert は表面的には出てこないが、プロジェクト内に必ず優秀なアーキテクト兼プロジェクトリーダー(複数人かもしれない)が必要になる。彼または彼らが上手にプログラマー達をコントロールしてソフトウェアシステム開発を成功に導く。表面的は完璧なボトムアップアプローチだ。(表には出てこないが、プロジェクトリーダーのリアルタイムの舵取りがプロジェクトの成功の鍵を握っているため、その意味ではトップダウンとも言えるかもしれない)

Iteration(反復)を数多く繰り返すことに重きが置かれているため、もともとポテンシャルの高い技術者が参加しているのなら、プログラマとしての成長も早いだろう。

ソフトウェアエンジニアリングの歴史から考えると正反対のアプローチのように見えるが、人間工学・組織行動学的には理にかなっているように見える。

IBM Rational Team Concert 的なアプローチがいいのか、Microsoft Software Factories 的なアプローチがいいのか・・・

組込みソフトの世界なら次のようなシナリオで適用したらうまくいくような気がするのだけれどどうだろうか?

(そのドメインの制約条件を含む知識を十分に持ち合わせた優秀なアーキテクトがプロジェクト内にいると仮定して)まず、IBM Rational Team Concert で徹底的に Iteration(反復)を繰り返し、完成度の高いプロトタイプモデルを作る。次に、できあがったプロトタイプモデルのアーキテクチャとドメインの要求がどのようにすり合わされたのかを分析し、今後同様の製品群を作成するためのプロセスモデル、ドメインモデル、アーキテクチャを Visual Studio Team System を使って設計し、可視化されたモデルをレビューし洗練させる。システムの品質が担保できるようにテスト計画を立て、すでに実施されているテスト結果を利用しながらシステム全体の Verification(検証)と Validation(妥当性確認)を確立する。

個人的な感想を言うと、IBM Rational Team Concert では、開発チームのパフォーマンスは最大になるように思うが、開発チームはシステムの品質をも担保できているようには見えない。(システム品質の説明責任を果たすことが難しい) 開発のパフォーマンスを最大限に上げることでシステム品質までも凌駕してしまおうというアプローチであり、根拠ははっきりしないが実効性はあるようにも感じる。(優秀なアーキテクト兼プロジェクトリーダーの存在が必須)

一方、 Visual Studio Team System では、プロセスモデル、ドメインモデル、アーキテクチャを構築するハードルが高く、それを実現できるプロジェクトは非常に少ない。道筋がつけられるまでを外部の優秀なアーキテクトにコンサルテーションしてもらうことは可能だが、効果が現れるまで時間がかかるし、効果が現れるまでに必要な時間や費用を組織内で確保するのが難しい。

でも、どちらのアプローチにも必要なのはドメインの知識に精通したアーキテクトの存在だ。ドメインの知識に精通したアーキテクトを育てるためには、Iteration(反復)をできるだけ回した方がいいから、IBM Rational Team Concert の方を先に取り入れた方がよいかもしれない。

【参考資料】
Rational Team Concert に関して Jazzプロジェクト
Eclips (Wikipedia)
Erich Gamma(Wikipedia)

Visual Sstudio Team System に関して(Microsoft)
Software Factories に関して(@it)
 

2008-08-24

安全ソフトウェアの設計(その4)

組込みZine に 安全ソフトウェアの設計~第4回 安全ソフトウェアの実現と維持に向けた取り組み~ を書きましたのでご参照ください。

-ソフトウェア安全確保のための重要な要素-

   □    Design & Verification
  □□□   Methodologies & Techniques
 □□□□□  Rules/Regulations
□□□□□□□ Safety Culture

※Rules/Regulations:Rules/Regulations for Safety Critical System development

この記事のポイントは組織の中にSafety Culture(安全文化)を定着させ、そのSafety Culture(安全文化)に立脚してRules/Regulations(規定/規則)を作り、Rules/Regulations(規定/規則)のもとでMethodologies & Techniques(方法論と技術)が検討され、Methodologies & Techniques(方法論と技術)に基づいてDesign & Verification(設計と検証)が実施されるべきであるということである。

でも、安全文化・品質文化を組織に定着させるのは簡単ではない。かつて、組込みソフトエンジニアは、自分が作っているソフトウェアがどのような製品に搭載され、どのようなユーザーがどんな風に使うのかををよく知っていたものだが、今では必ずしもすべてのソフトウェアエンジニアが、エンドユーザーがどのように製品を使うのかを知っているとは限らない。

汎用に使える市販のソフトウェア部品も増えてきている。汎用なソフトウェア部品を作っているエンジニアはどこまで自分たちが作っているソフトウェアの安全性や信頼性を高めれば要求に耐えうるのかよく分からないこともあるだろう。市販で買ってきたソフトウェアや、自組織内で過去に作られた開発のプロセスがよく分かっていないソフトウェアをそのまま製品に使って問題は絶対起きないと言い切れるだろうか。

こんな時代だからこそ、安全ソフトウェアの設計とは何か、何をしなければいけないのかを考えなければいけない。
 

2008-08-17

国際標準との向き合い方

ソフトウェアの世界でも国際標準への対応が求められる機会が今後増えてくると考えられる。ISO 9001などが最もポピュラーだが、各業務ドメインにおいてもソフトウェアを意識した個別の規格がでてきた。日本のエンジニア特にソフトウェアエンジニアは国際基準・国際規格との付き合い方が下手だ。

それは、おそらくソフトウェアエンジニアが自分たちの日々の取り組みを外部にさらす機会がほとんどなかったからだと推測される。今回はソフトウェアエンジニアが国際標準とどのように向き合っていけばよいのかを考えてみる。

【国際標準との向き合い方】

国際標準の策定に対して、日本のエンジニアは自分たちとは縁遠いもの、天から振ってくるものだと考えがちだが、実際にはそうではない。国際標準は各国の代表が意見を出し合って議論し、投票によって内容を決定する。もちろん日本も代表として標準の策定に参画しているので、意見を主張することができる。ただし、日本人は議論の際に押しが弱く、欧州のように多数派を構成する能力に長けていないため、国際標準を自分たちの考え方に引き寄せることが難しいようだ。その結果、国際標準の多くは欧米が中心となって作られることが多く、責任を権限が明確な組織において構成メンバの役割をベースに「誰が何を」すべきかに焦点が当てられることになる。

ところが、責任や権限が明確でなくても、いざというとき、エンジニア同士が権限の範囲を超えて協力しあうことで問題を解決していく日本の環境では、このような考え方で体系化された方法論がうまく機能しない場合もある。しかし、鉄道、航空機、自動車、医療機器、航空宇宙など、組込み製品にソフトウェアを搭載して世界に商品を展開している日本の組織では、世界の標準や規格が日本人に合わないと愚痴をこぼしているだけでは、グローバルマーケットで生きていくことはできない。

多数派を占める欧米中心に決まった標準であったとしても、世界に商品を供給していくのなら世界のルールににしたがって自分たちの商品の安全性や信頼性を示すことも必要なのだ。海外の企業と渡り合っていくのなら日本人もルールの策定に積極的に関わり、自分たちの主張を標準に反映させるように働きかけていくことが大事である。

国際標準を「自分たちには縁遠いもの」「天から振ってきたもの」「実質的には役に立たないもの」と考え、国際基準の縛りから逃れる抜け道を探すのではなく、基準が作られた背景や策定に関わった人々の考え方をポジティブに捉えて、どうしたら自分たちの中に取り入れることができるかどうかを考えることが重要である。

【安全性や信頼性を説明する責任】

グローバルなマーケットで商品をリリースし社会的な責任を負っていく組織は、ユーザーに対して商品を実質的に安全で信頼して使ってもらえるようにするのと同時に、商品が安全で信頼できることについて根拠を持って説明できるようにすることがが求められる。開発プロジェクトは、組織内の品質保証担当や外部監査機関、組込みソフトウェアを発注したクライアントなどにソフトウェアの安全性や信頼性を説明する。クリティカルデバイスのソフトウェアの世界では、定期的な内部監査、外部監査が行われ、監査の際に十分な説明ができないと是正を求められたり、最悪の場合商品の出荷を停止させられたりすることもある。

近年、組込みソフトの規模が増大し、複雑化が進んだことによって、組込み商品そのものの安全性や信頼性を示すだけでは事故を防止することが難しくなり、商品に搭載するソフトウェアの安全性や信頼性についても説明責任を果たす義務が生じるようになってきた。この傾向は、航空宇宙、鉄道、プラント、医療機器のようなクリティカルなソフトウェアでかつ、資格を持ったオペレータが商品を扱う業種で検討が進んできたが、今後は自動車など資格を持ったオペレータではない、一般ユーザーが使用するような機器に搭載するソフトウェアに対しても、安全性や信頼性の証明が求められるようになってくることが予想される。

【説明責任が果たせない製品は世界に受け入れられないし実際に危ない】

日本の特に昔気質のエンジニアは、「商品が実質的に安全で信頼性が高ければその根拠をわざわざ示す必要はない」、「自分たちには安全で信頼できる商品を作り上げる自信がある」、「その開発工程や工程内の活動はわざわざ他人に披露するようなものではない」と考える人が少なからずいるように見受けらる。実際に安全で信頼性の高い商品をアウトプットし続けることができていれば、その主張も分からないではないが、大規模、複雑化したソフトウェアシステムにおいて安全や信頼を確保し続けることが難しくなった今日では、仮に日本製品のリコールの数が他国の製品に比べて圧倒的に少なかったとしても「最終製品の品質が高ければ、開発の工程や安全や信頼の根拠を見せる必要がない」という主張は国際的には「逃げ」や「隠蔽」ととらえられてしまう。

日本人が作っているから安全であるという主張は組込みソフトウェアの規模が小さかった時代には通じたかもしれないが、ソースコードの行数が数十万行から数百万行になってくる、また、オフショア開発で海外にソフトウェアの制作を依頼するようになった現在では説得力がない。商品に組み込んだソフトウェアが安全で信頼できるかどうかは、国際的な標準で説明できりようにしておくことが必要となる。仮に日本のエンジニアが独自の方法で製品に搭載するソフトウェアの品質を確保しており、国際標準が示す方法と相違点があったとしても、その根拠を説明することが必要なのだ。

【国際標準をポジティブにとらえる】

このとき、ソフトウェアの安全性や信頼性を国際標準に沿って説明するための労力を、育った環境の違う人たちへの余計な作業だとネガティブに考えてはいけない。ソフトウェアに起因するリコールが増えてきたことによって、日本のユーザーだけではなく世界のユーザーが製品に搭載されているソフトウェアが安全で信頼できることの説明責任を求めるようになってきたのだと認識しなければならない。国際標準に対するネガティブな気持ちをポジティブに切り替えるには、まず、世界のユーザーが何を考え、何を要求していることを知って、国際標準が目指していることと、国際標準がに記された内容のうち自分対に役立つところを見いだそうと前向きに考えることが必要となる。

その考え方ができれば、現状の自分たちのソフトウェア開発において、国際標準のどの部分を取り入れると有効なのか、どうすれば世界に対する説明責任を果たすことができるのかが見えてくるはずである。また、国際標準の有効性は何かを追っていくとクリティカルデバイスのソフトウェアエンジニアでなくても、ソフトウェアの安全や信頼で先行する業界の世界標準を知り、それらの良いところを自分のドメイン、自分の製品に取り入れることができるようになる。それができれば、自分たちの製品においてリコールを起こさないソフトウェアを作るためにプラスに働くだろう。
 

2008-08-01

サムライエンジニア

三冊屋というのが話題だそうだ。一冊ではなく関連のある三冊を束ねて本屋は売って、我々はそれを買って読む。

いろいろなジャンルがある中で、一番人気が次の三冊だという。この三冊の共通する特徴は、「日本を紹介するために書かれた初版が外国語の本」である。三冊合わせて Amazon で買うとちょうど 1533円となり送料が無料になる。
  1. 武士道(新渡戸稲造著)
  2. 茶の本(岡倉覚三著)
  3. 代表的日本人(内村鑑三著)
今は武士道の本を読んでいるが、なんせ新渡戸稲造が生きていたときの時代の本なので言葉が難しい。

まあ、それはそれとして「武士道」を読んでいるうちに、サムライエンジニアという言葉が頭に浮かんできた。サムライエンジニアとは武士道の精神を持ち合わせたエンジニアという意味だ。

自分が考えるサムライエンジニアとは次のような技術者のことだ。(字下げされている部分は『武士道』からの引用)

【義】 サムライエンジニアは義理堅く恩義は忘れない
 義理の本来の意味は義務に他ならない。しかして義理という語のできた理由は次の事実からであると、私は思う。すなわち我々の行為、たとえば親に対する行為において、唯一の動機は愛であるべきであるが、そに欠けたる場合、孝を命ずるためには何か他の権威がなければならぬ。そこで人々はこの権威を義理において構成したのである。彼らが義理の権威を形成したことは極めて正当である。何ともなればもし愛が徳行を刺激するほどに強烈に働かない場合には、人は知性に助けを求めねばならない。すなわち人の理性を動かして、正しく行為する必要を知らしめなければならない。
サムライエンジニアは金や権威では動かない。受けた恩義を返すために動く。

【勇】 サムライエンジニアは正しいことを行うときこそ勇気を使う 
 勇気は、義のために行われるのでなければ、徳の中に数えられるにほとんど値しない。孔子は『論語』において、その常用の論法に従い消極的に勇の定義を下して、「義を見てならざるは勇なきなり」と説いた。この格言を積極的に言い直せば、「勇とは義(ただ)しき事をなすことなり」である。
サムライエンジニアは組織や上司の命令あっても、コンプライアンスや顧客に不利益となることは行わない。顧客に不利益となることを指示された場合は勇気をもって義のために反論する。

【仁】 サムライエンジニアは仁愛を持って他者に接する 
 仁は柔和なる徳であって、母のごとくである。真直なる道義と厳格なる正義とが特に男性的であるとすれば、慈愛は女性的なる柔和さと説得性を持つ。我々は無差別的な愛に溺れることなく、正義と道義をもってこれに塩つくべきことを戒められた。伊達政宗が「義に過ぐれば固くなる、仁に過ぐれば弱くなる」と道破せる格言は、人のしばしば引用するところである。
 幸いにも慈愛は美であり、しかも希有ではない。「最も剛毅なる者は柔和なる者は最も柔和なる者であり、愛ある者は勇敢なるものである」とは普遍的に真理である。「武士の情け」という言は、直ちに我が国民の高貴なる情感に訴えた。武士の仁愛が他の人間の仁愛と種別的に異なるわけではない。しかし武士の場合にありては愛は盲目的な衝動ではなく、正義に対して適当なる顧慮を払える愛であり、また単に或る心の状態としてのみではなく、殺生与奪の権力を背後に有する愛だからである。
サムライエンジニアは誠実な隣人に対して仁愛を持って接する。クライアントとサプライヤの関係や上司と部下の関係を利用することはせず、誠実な技術者には立場を越えて協業する。

【礼】 サムライエンジニアは正当なる物事に対して尊敬の念を抱き礼を尽くす
 作法の慇懃鄭重(いんぎんていちょう)は日本人の著しき特性として、外人観光者を惹くところである。もし単に良き趣味を損なうことを怖れてなされるに過ぎざる時は、礼儀は貧弱なる徳である。真の礼はこれに反し、他人の感情に対する同情的思いやりの外に現れたるものである。それはまた正当なる事物に対する正当なる尊敬、したがって社会的地位に対する正当なる尊敬を意味する。何となれば社会的地位に対する尊敬を意味する。
サムライエンジニアは高き技術に素直に感動し、その技術を吸収したいと考えるとともに、その技術、その技術を持つ者を尊敬し礼を尽くす。

【誠】 サムライエンジニアは誠実に徹し、嘘をつかない 
 真実と誠実なくしては、礼儀は茶番であり芝居である。伊達政宗曰く、「礼に過ぐれば諂い(へつらい)となる」と。「心だに誠の道にかないなば、祈らずとても神や守らん」と戒めし昔の歌人は、ポロニウスを凌駕する。孔子は『中庸』において誠を尊び、これに超自然力を賦与してほとんど神と同視した。曰く、「誠は物の終始なり、誠ならざれば物なし」と。
サムライエンジニアは失敗やリスク、日程の遅れの可能性について嘘をつかない。真実を報告し、問題解決を誠実に遂行する。

-----------

子供の頃、ウルトラマンや仮面ライダーが好きだった。あの頃の子供向けテレビ番組はみんな勧善懲悪だった。子供の頃のテレビ番組に強く影響を受けるなんて我ながら幼稚だなあと思っていた。でも、よくよく考えてみれば、ウルトラマンや仮面ライダーのベースにあったのは武士道の精神ではないか。21世紀になって、マッハGoGoGoの実写版「スピードレーサー」を見て胸が熱くなってもいいんじゃないかと思う。

サムライエンジニアは強きをくじいて弱きを助ける。ここでいう「強き」とは、例えば権威を笠に着て実力もないのに暴利をむさぼるような巨大組織のようなものだ。子供のテレビ番組では必ずこういう悪者は正義の味方にやっつけられるのだが、現実にはそう簡単にはいかない。

だからこそ、現代のサムライエンジニアは刀を研ぎ、剣術を修得しておかなければいけない。また、持っている刀や剣術の腕をひけらかすこともしてはいけない。そして、ここぞというときに刀を抜き悪を切るのだ。

そんなサムライエンジニアに自分はなりたい。
 

2008-07-26

なぜ、この仕事を続けている? の投票結果

1. 好きで選んだ仕事だから 10 45%
2. この道で一流になりたいから 6 27%
3. お客さんに喜んでもらえるとうれしいから 5 22%
4. 生計を立てるため 4 18%
5. いまさら変えるのは面倒 3 13%
6. サラリーがそこそこいいから 3 13%
7. キャリアアップしたいから 3 13%
8. なんとなく 2 9%
9. この会社(組織)が好きだから 1 4%



投票総数 22名(複数回答可)


ちなみに、1と2と3と7と9はポジティブな回答、5と6と8はどちらかと言えばネガティブな回答となる。ポジティブな回答が上位にいったので、まずは安心。

なお、「好きで選んだ仕事だから」は組込みの場合、どちらかと言えば業務ドメイン(例えば車なら車関係、カメラ好きならカメラ関係)やものづくりに関係している組込み業界に愛着があるという人が多いのではないだろうか。

「この道で一流になりたいから」は業務ドメインだけではなく、ソフトウェアエンジニアとして一流になりたいという意味も含まれる。「キャリアアップしたいから」はスキル向上、出世に対する意欲を示している。

「お客さんに喜んでもらえるとうれしいから」は顧客満足が仕事へのモチベーションにつながっているので、多少辛いことがあっても前向きに仕事に取り組んでいける可能性が高い。

一方で、「生計を立てるため 」「いまさら変えるのは面倒」「なんとなく」はやや投げやりであり、一時的な感情であればいいが、長期的にそのような感覚を持ち続けているであれば、「好きで選んだ仕事だから」「この道で一流になりたいから」「お客さんに喜んでもらえるとうれしいから」といったポジティブな気持ちになるには何がどう変わればいいのかを考えることが必要だと思う。

長い人生の中で仕事を続けていくのだから「好きで選んだ仕事だから」「この道で一流になりたいから」「お客さんに喜んでもらえるとうれしいから」と思えるようになりたいものだ。
 

2008-07-21

ブログを訪れたきっかけとなった「キーワード」

学校も夏休みに入ったので本ブログも夏休みモード(楽して役に立つ情報の提供)に入ります。

今回は、本「組込みソフトウェア工房」に検索エンジンを使って訪れた人が使ったキーワードのランキング(過去一ヶ月間)をアップします。

傾向としては車系のキーワードが多いように感じます。固有名詞が出てくると「なぜ、この人が?」という興味が沸きますね。

キーワードの ISO 26262 とは 自動車分野の機能安全 のこと。機能安全ということばは何回説明を聞いても意味がよくわからないので個人的には嫌い。勝手に想像するに、ISO 26262 とは、車の安全を確保するために製造業者は何をすべきかを示した国際標準だと思う。

近年の自動車はECUを多数搭載し、ソフトウェアの量も尋常ではないため、ソフトウェアを安全にする、ソフトウェアで確実に安全をコントロールすることが求められています。国際的な基準を作って守っていかないと安全に動くのが当たり前と思っている自動車が凶器になる危険性があるから、このような基準が作られることになるのでしょう。

ただ、勘違いしないようにした方がいいのは、ISOはそれだけでは法的拘束力はありません。各国(ヨーロッパの場合はEU)が国内法に取り込む、または、規制の対象にしなければ法的な拘束力はないのです。ただ、ライバル会社が みな、その国際標準の適合を宣言したのならば、競合上他社に劣る、もしくは安全とはいえないと見なされ、売り上げが落ちるかもしれないので、みんな情報を収集しようとするのですね。

グローバルマーケティングにおいてトップグループを走っている日本のメーカーとしては、安全に関する国際標準をクリアできていないとは言えないでしょう。



キーワード セッション
1 iso 26262 37
2 組込みソフトウェア 16
3 協力会社 組み込み 13
4 シンドラー エレベーター 事故 12
5 組み込みソフト 設計 ドキュメント 12
6 embedded manufactory 11
7 問題解決能力 9
8 見せる化 9
9 matlab マイコン コード 8
10 國方 7
11 理系白書から考えるソフトウェア工学 7
12 組込みソフトウェア工房 7
13 はじめての課長の教科書 6
14 トヨタ 重松 6
15 jaxa 片平 5
16 シンドラー 事故 5
17 ソフトウェア 開発工程 5
18 トヨタ 戦略 5
19 トヨタの戦略 5
20 モデルベース開発 自動車 5
21 モデル駆動開発 5
22 misra-sa 4
23 nokia 戦略 4
24 ソフト プロセス改善 4
25 ソフト 技術伝承 とは 4
26 ソフトウェア 安全性 4
27 ソフトウェア分割 テクニック 4
28 ソフトウェア開発 工程 4
29 ソフト開発 工程 4
30 回路図 ソフトウェアエンジニア 4
31 月で遭難 4
32 理想 現実 仕様 管理 4
33 組込み 品質 改善 4
34 詳細設計 組み込み フローチャート 4
35 iec61508 ソフトウェア 3
36 matlab 開発効率 3
37 misra sa 3
38 uml 組込み 3
39 あしたをつかめ 平成若者図鑑 3
40 アメリカ人と日本人 3
41 シンドラー エレベータ 事故 3
42 ジョエルテスト 3
43 ソフトウェア開発工程 3
44 ハイバネーション技術 3
45 ベストエフォート ギャランティ 3
46 モデル駆動 3
47 仕様変更 組み込みソフト 3
48 品質とは 3
49 大西 建児 プロダクト ライン 3
50 安全設計 3
51 組み合わせ型製品 3
52 組み込みソフト 開発 図書 3
53 組み込みソフト開発 3
54 組込み emc 必要 3
55 組込みシステムではないもの 3
56 組込みソフトエンジニアを極める 3
57 進藤智則 3
58 酒井 embedded 3
59 alc工 2
60 critical system 組込み 2
61 eebof メーリングリスト 2
62 embedded ブログ 2
63 etss 2
64 labview matlab 比較 2
65 matlab スペクトル 表示 2
66 mbd 開発 2
67 qaスペシャリスト 2
68 rtosを使うメリット 2
69 uml 組み込み 2
70 xp マルチコア 最適化 2
71 あしたをつかめ平成若者図鑑 2
72 ここが変だよ日本の管理職 2
73 すり合わせ型 2
74 すり合わせ型 組み合わせ型 2
75 すり合わせ型とは 2
76 すり合わせ型開発 2
77 エレベーター事故処理 2
78 ギャランティ型ビジネスモデル 2
79 グローバル変数 割り込み 組込み 2
80 シンドラー 安全側 設計 2
81 ソフト バグ 再発防止 2
82 ソフトウェア 品質 過剰 2
83 ソフトウェア 品質とは 2
84 ソフトウェア 安全設計 2
85 ソフトウェア 組込み 再利用 2
86 ソフトウェア 開発計画書 2
87 ソフトウェア工学 品質特性 2
88 ソフトウェア開発 失敗 2
89 ソフトウェア開発手順 2
90 トヨタのマーケティング戦略 2
91 マイコン ソフトウェア 分割 2
92 モジュール 疎結合 2
93 ライオンと魔女 挿絵 2
94 人事 部下を選ぶ 2
95 共有結合 ソフトウェア 2
96 分析 設計 実装 評価 工程 ソフトウェア 2
97 品質とは ソフトウェア 2
98 商品コンセプト 2
99 問題解決キッズ 2
100 安全設計 組み込み 2