洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない

非常に古い話である。1993年の日科技連のソフトウェアの品質管理セミナーに参加したとき3日目の東京理科大の高橋武則教授の講義で「品質とは顧客満足度である」というテーマを「秋葉原に洗濯機を買いに行く」というたとえ話で聞いた。

当時29歳の自分にとって、この話は青天の霹靂だった。大げさだがこの話を聞いて製品開発をする場合に何を目標にすべきかということをイメージとしてつかんだと思う。

この話は『組込みソフトエンジニアを極める』の第3章 －再利用の壁を越える－ の中で「洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない」というコラムで紹介している。古い話だったし、テキストにも書かれていない内容だったので出典情報は書かなかった。高橋先生ごめんなさい。

さて、今回はこのコラムを引用する。

【洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない】

現在東京の秋葉原は電気製品のメッカというイメージから、別な意味での聖地と変わりつつあるようです。ところで、1980年代、郊外に大型家電量販店がなかったころ、地元の電気屋さんではなく秋葉原に家電製品を買いに行く人々がいました。なぜ、秋葉原に洗濯機を買いに行ったのでしょうか。もちろん、秋葉原の電気店では最新の商品が豊富に取り揃えられており価格も安かったということが一番の理由でしたが、秋葉原の店員は各メーカーの洗濯機の特長を熟知していて、予算や使い勝手などの要求に応じて一番ピッタリ合う洗濯機を選んでくれるだけの知識と販売の経験（洗剤はどれくらい使うのか、乾燥機能はついているのか、サービス体制は万全かなど）を持っているという理由も大きかったと思います。

2000年代になって家電製品はインターネットで激安のものを購入できるようになりましたが、いろいろなメーカーの商品をおしなべて比較し、誰かにアドバイスしてもらいたいという買い手側の要求はまだあります。その要求に答えるように、都市近郊では郊外に家電量販店の大規模店舗が出店するようになりました。郊外の家電量販店では、かつて秋葉原の電気店の店員が行っていた販売のノウハウがマニュアル化され秋葉原へ行かなくても、地元で最新の機種を適切なアドバイス付きで購入できるようになりました。賢いユーザーはこのような家電量販店で商品の知識を仕入れてインターネットで最も安く買える店を探すのかもしれません。

さて、販売側がこのように商品だけをただ売るだけでなく、商品＋サービス（商品知識とアドバイス）をセットにして売るようになってきたことを考えると、作り手側はどのようなスタンスで物作りをしていけばよいのでしょうか。

この問題を考えるおもしろい例題として洗濯機メーカーが新しい商品を開発するときに、「どのような洗濯機を作ろうか」と考えてはいけないという話があります。洗濯機メーカーならずともメーカーは新しい商品を企画する際に現行モデルをベースにして新しい機能を追加しようと考えがちです。なぜなら、現在販売している商品は目に見える「物」でありその機能や性能について自分たちは熟知しており、お客様からの評判や要望もある程度把握できているので、それをベースに新しい商品を考えることが最も自然だからです。

しかし、このようなアプローチには大きな落とし穴があります。なぜなら、洗濯機を使っているユーザーの真の目的は衣類を洗濯することではないからです。洗濯機を使っているユーザーは決して洗濯をすることが本当の目的ではありません。ユーザーの本当の目的は「汚れた衣服をきれいにすること」です。へりくつのように聞こえるかもしれませんが「洗濯機で洗濯すること」と「汚れた衣服をきれいにすること」未来永劫、同等だとは言い切れないのです。

なぜなら、例えば、自宅近くに、もしも、ワイシャツ１枚を10円でクリーニングするクリーニング屋が現れ、夜玄関脇のボックスに洗濯物を入れておくと朝にはきれいになって戻してくれるようなサービスを始めたら、それでもユーザーは洗濯機で洗濯するでしょうか。もちろん、21世紀になってもそこまでクリーニング料金が安くなるような時代にはなっていませんが今後絶対にそのような状況が現れないとは言い切れません。人々のライフスタイルが変化したり、新しいデバイスが発明されたりすることにより既存の考え方が一変することはよくあるのです。

したがって、洗濯機メーカーは新しい洗濯機を開発することを考えるのではなく、お客様の要望（この場合は衣服をきれいにするということ）を満足するための商品またはサービスとは何か、また、現在の技術や新しい技術を開発することによってどのような商品またはサービスを提供することができるのかを考える必要があるのです。そうやってユーザー要求を第一に考えた商品やサービスと現行商品に新しい機能を付け加えたものがイコールであるとは限らないのです。洗濯機自体がいらなくなる時代だってくるかもしれません。目の前にある形あるものにとらわれないようにしないと時代に取り残されてしまう危険性があるのです。

【引用終わり】

実際、1993年当時ではまったく予想できなかったのではないかと思うが、今ではドラム型でしかもヒートポンプ式の乾燥機が内蔵されている洗濯機まである。

商品開発のディスカッションで何も考えないで話をしていると、今の製品の一部の機能を新しくしたり、他社製品のいいところを取り入れたりといった誰でも思いつくアイディアしか出てこないことが多い。

ユーザーニーズの本質にまで立ち返って、ユーザーが本当に求めているものを、現在世の中にあるあらゆる技術やデバイスを使って実現できるかどうかを考えなければいけない。

イノベーションを起こすためには現実を一度破壊しなければいけないが、組込みの場合、アーキテクトは新しい技術やデバイスを使ったときの実現可能性についてできるかどうかピンとこないといけない。

そのためには、常日頃、まったく関係ない業種であっても新しいデバイスやサービスが現れてきたら、自分のドメインで使えるかどうか考えるくせを付けることが大事だ。

今回の話題は「マーケティングの重要性」の記事にも書いているのでこちらもお読みいただきたい。

仕様書を書かないエンジニア

『組込みソフトエンジニアを極める』の第4章－品質の壁を越える－の中に組込みソフトウェアプロジェクト簡易評価指標を載せた。

組込みソフトウェアプロジェクト簡易評価指標の10個の質問事項は、ジョエル・テスト(The Joel Test: 12 Steps to Better Code)を参考にしたものだ。2005年の12月に、このジョエル・テストを考えた Joel Spolsky 氏の翻訳本、『Joel on Software』が出版された。

Joel Spolsky 氏はMicrosoft にいたとき、Excelの開発に携わっていたソフトウェアエンジニアで、彼のウェブログ Joel on Software は、独立したプログラマ向けのサイトとしては最も人気のあるものの一つである。

【組込みソフトエンジニアを極めるで紹介した 表4.6 組込みソフトウェアプロジェクト簡易評価指標】

• コーディングルールを定めているか？
• 障害票データベースを持っているか？
  
• ソース管理システムを持っているか？
  
• 開発の節目節目でレビューを実施しているか？
  
• スケジュール表を常に更新しているか？
  
• 仕様書を作ってからプログラムを書き始めているか？
  
• プログラムを変更した後の回帰テストは実施しているか？
  
• 買える範囲で一番良い開発ツールを使っているか？
  
• OJT以外に技術者教育のカリキュラムを持っているか？
  
• テスト担当者はいるか？
  

参考：ジョエル・テスト(The Joel Test: 12 Steps to Better Code)
The Joel Test とはソフトウェア開発チームを評価する簡単なYes・No形式のテスト

『Joel on Software』は、Joel Spolsky 氏のウェブログ Joel on Software をベースにしたもので、そのフランクな語り口がとても軽快でおもしろい。具体例が満載でネタの宝庫だ。

今回は、エンジニアがなぜ仕様書を書かないのかについて Joel Spolsky 氏が書いたことについえ考えてみたい。

【Joel on Software 第5章 やさしい機能仕様 パート1：なぜわざわざ書く必要があるのか？ より引用】

2000年10月2日 月曜

ジョエルテストを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければいけないということだった。前にも行ったことだが、仕様書はデンタルフロスみないなもので、みんな書かなきゃいけないとは思っているけど、誰も書かない。
　
なぜみんな仕様書を書きたがらないのだろう？　人々は、仕様書作成フェーズを飛ばして時間を節約しているんだ、と主張している。彼らは、仕様書作成がNASAのスペースシャトルのエンジニアや巨大な保険会社で働いているような人たちのための贅沢品であるかのように振る舞っている。戯言だ。何よりも仕様書を書かないということは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクなのだ。それは着替えだけリュックに詰めて、その場になれば何とかなるさとモハーベ砂漠を横断に出発するのと同じくらい愚かなことだ。仕様を書かずにコードに飛びつくプログラマやソフトウェアエンジニアは、自分たちがかっこいい早撃ちガンマンであるかのように思う傾向がある。そんなんじゃない。彼らはとても非生産的だ。彼らはまずいコードを書き、お粗末なソフトウェアを作り、まったく必要のない大きなリスクを負うことでプロジェクトを危険にさらしている。

　　　　　：

<ここに仕様書を書いた場合と書かない場合の具体的な例が入る>

　　　　　：

この物語の教訓は、人間の言葉で製品をデザインしているときは、いろいろな可能性について考え、修正し、デザインを改良するのに数分しかかからないということだ。ワープロ文書の段落を1つ削除するのを残念に思う人はいない。しかし、あなたがプログラミング言語で製品をデザインしているなら、反復デザインには何週間もかかる。さらに悪いことに、あるコードを書くのにほんの2週間かけただけで、プログラマは、どんなにまずいコードであっても、そのコードにとても執着するようになる。たとえそれが最高のアーキテクチャを表現していなくても、上司や顧客が何と言おうとも、スピーディにその美しいコンバータのコードを捨てさせることはできない。その結果、最終的な製品は、初期の間違ったデザインと理想的なデザインとの間の妥協の産物になりがちだ。それは、「すでに書いてしまったコードがあり、そのコードは捨てたくなかったので、それを前提とすれば私たちに得られた最良のデザイン」ということになる。これは「私たちに得られた最良のデザイン」ほど良いものではないのだ。

これが仕様書を書く大きな理由の1番目だ。大きな理由の2番目はコミュニケーションにかかる時間を節約できるということだ。あなたが仕様書を書いておけば、プログラムがどう動くと想定されているか一度だけ説明すれば済む。チームのみんなはただ仕様書を読めばいいからだ。品質保証の人たちは、プログラムがどう動くと想定されているかを知るために仕様書を読み、何をテストすればよいのかを理解する。マーケティングの人たちは、Webに載せるための、まだ作られていないベーパーウェア製品のホワイトペーパーを書くときに仕様書を使う。ビジネス開発の人たちは仕様を読み違えて、その製品がいかに禿やイボによく効くかという奇妙なファンタジーを紡ぎ出すかもしれないが、それで投資家を引き寄せられるのだから、それはそれでOKだ。開発者たちはどういうコードを書くべきか知るために仕様書を読む。顧客は開発者の作っているものが自分たちの欲しい製品であることを確認するために仕様書を読む。テクニカルライターは仕様書を読んでマニュアルを作る。マネージャは経営会議で何が起こっているかについて知っているような顔をするために仕様書を読む、などなど。

【引用終わり】

前半の仕様書を書く第1番目の理由「仕様書を書かないと、すでに書いてしまったコードが既成事実になってしまい、デザインの修正に時間がかかる」の説明はよく分かる、実際その通りであり現場をよく観察していると思う。それに対して、第2番目に理由は、日本のそれも組込みソフトの開発現場に照らし合わせたとき「そうだ、そのとおり」と相づちが打てるだろうか。

チームのために仕様書を書くという点は分かるものの、「品質保証の人たちのために書く」「マーケティングの人たちのために書く」「ビジネス開発の人たちのために書く」「顧客のために書く」「テクニカルライターのために書く」「マネージャのために書く」というところが引っかかる。一つ一つそうなっているのか検証してみよう。

「品質保証の人たちのために書く」は、品質保証担当がソフトウェアをテストするのに、仕様書をもとにテストケースを作るから仕様書が必要だということだ。でも、10人以下の組込みソフトプロジェクトでは、プログラムの作成者が自分で自分の作ったプログラムをテストしたりする。そうなると仕様は自分の頭の中にあるということになる。

次に「マーケティングの人たちのために書く」はまだ完成していない製品のホワイトペーパーを書くときに仕様書を使うとあるが、組込み製品の場合はホワイトペーパーは書かない。

「テクニカルライターのために書く」は、取り扱い説明書の原案をソフトウェアエンジニアが書いたりする。

「マネージャのために書く」もそうだが、何しろ日本の小規模な組込み開発では、製品の機能仕様について知りたいプロジェクト外の人間は、直接製品開発をしているエンジニアに仕様について聞く。人の流動が少ないので誰が製品仕様について詳しいか知っているし、知らなくてもプロダクトマネージャに尋ねると「彼に聞いて」などと言われる。「仕様書を読んでくれ」とはなかなか言わない。仕様書を読まなくても聞きたいことを直接聞けるから仕様を知りたい側は楽だ。

プロジェクト外の人間のみならず、プロジェクトの内部でも製品の機能仕様を一人のアーキテクトが作っていたりすると、エンジニアもマネージャも誰も彼もが、その一人のアーキテクトに仕様を聞きに来る。

要するに人間仕様書だ、いや生き字引だ。そのエンジニアがすべての仕様を知っていて、その人に聞けばだいたいのことがわかってしまう。そんなエンジニアがあなたのプロジェクトにもひとりぐらいいるのではないか？

「権限もいらないから責任もとらないってあり？」の記事でも書いたように、日本の組込みソフトウェアプロジェクトは責任と権限が曖昧な場合が多い。責務が曖昧だから、仕事の分担がはっきりせず、人間仕様書状態が発生しやすい。

しかし、人間仕様書状態の発生により日本の組込みソフトウェアプロジェクトは2つの大きなリスクを抱えることになる。1つ目は、生き字引となっているアーキテクトが何かの理由でプロジェクトから離れたり、会社を辞めたりするとものすごく製品開発の生産性や品質が落ちる。また、後を引き継いだアーキテクトはろくな仕様書がないから非常に苦労することになる。

2つ目のリスクは、人間仕様書となっているアーキテクトに情報が集中してしまい大きな負荷をかけることにる可能性があるということだ。知らず知らずのうちにそのアーキテクトへの負担を累積させて潰してしまう危険がある。

人間仕様書となったアーキテクトは潰れないまでも、いろいろな会議に呼ばれ、マネージャが外部の人間から製品の仕様について説明を求めら得ると「それは○○君から答えさせます」などと振られる。どこに何が書いてあるか知らなくても、人間仕様書が必要な情報を適宜加工してアウトプットしてくれるので非常に便利だ。

しかし、機能仕様について尋ねられると、自分のやっている作業が一時的に止まるので集中が途切れる。だから、質問が来なくなる残業時間の間に集中して自分の仕事をやったりする。

ああ、無情。悲しきアーキテクトよ。人間仕様書状態から彼を解放せよ！　と叫んでみても始まらない。人間仕様書となっているアーキテクトが、この状態を解消しようとしてがんばって紙の仕様書を書いても、彼に聞いた方が早いので仕様書の方を読んでくれないのだ。

大規模なビジネス系のプロジェクトでもろくに仕様書が書かれないのなら、小規模な組込みソフトプロジェクトで人間仕様書状態を解消するのはかなり大変だ。

いまは小規模でも、ソフトウェアの規模が増大し、一人のエンジニアが製品の仕様全体を把握できなくなったときに、仕様書がないことでプロジェクトが破綻するのを待つか、それとも人間仕様書状態になっているアーキテクトにしばらく倒れてもらうか・・・

現時点では、いいアイディアが浮かばないが、もしも、ドキュメントがなくて困っているプロジェクトマネージャやアーキテクトがいたら、『Joel on Software』を読んで、この本に書いてあるいろいろなシチュエーションの具体例の中から解決のヒントをつかんでいただきたい。

働くことの本質は貢献であるという考え方

日頃コミュニティ活動を行っていると、コミュニティ活動はサラリーを得るための仕事ではないので、"Best Effort"すなわち最大限の努力が大事、別な言い方をすれば「できることしかできない」→「できる範囲でしかできない」という論理になりがちで、忙しいから後回しにしようという弱気になることが少なくない。

また、コミュニティ活動のみならず会社でも自分の職務の範囲外の仕事は、Contribution（貢献）であり、自分以外の人たちに対して「やってあげていること」と考えがちである。

そう思っていたら、日経ビジネス 2006年8月7日・14日号の日産自動車社長　カルロス・ゴーン氏の記事に、「私は働くことの本質は貢献することだと思う」と書いてあるではないか。

働くことと貢献という言葉は背反するイメージを持っていたので「働くことの本質は貢献することだ」という主張にはちょっと驚いた。

以下、日経ビジネスの記事の一部を引用する。

【日経ビジネス 2006年8月7日・14日号 p148 日産自動車社長 カルロス・ゴーン 「働くことの本質とは」より】

今回は「働く」ということについて、考えてみたい。人はなぜ働くのか。皆さんはどう思うだろうか。偉大な芸術家、優秀なビジネスパーソン、優れた芸術家・・・。どんな人でも構わない。最高の仕事を想像してみてほしい。共通するものは何か。そう、彼らには大抵の場合、非常に激しい情熱がある。

早起きして1日20時間働き、翌日も同じ熱心さで仕事に臨む。普通の人ならこうならない。「もううんざりだ。休暇が欲しい」と音を上げるだろう。これを乗り切るには、より高次元の精神性が求められる。つまり愛情や熱意、貢献と呼べるきわめて強い感情だ。これはまさに「あなたのモチベーションは何か」という問いに直結する。

「貢献」こそが仕事の目的

私は働くことの本質は貢献することだと思う。それは必ずしも一方通行ではない。私は社会や会社、自分の家族に貢献しているが、同時に給料などの見返りも手にしている。また、仕事によって自分自身を鍛える、すなわち自分への貢献という側面もある。働いている時、人は特定の目的のためにエネルギーを費やしているが、この目的が何らかの貢献でなくてはならないのだ。

【引用終わり】

カルロス・ゴーン氏の「働くことの本質は貢献」であり、それは一方通行ではない、給料や自分自身を鍛える貢献になっているという考え方が新鮮だった。

給料の対価として働いているのではなく、何かに貢献するために働いている、貢献する先は会社かもしれないし、社会かもしれないし、自分自身かもしれない。

冒頭に書いたコミュニティ活動における貢献は、大部分は社会への貢献であったり、自分自身を鍛える貢献になる。

「働くことの本質は貢献である」という考え方は、目的意識を明確にするのに効果的だし、働くことへのモチベーションも高まる。ゴーン氏は記事の中で、「私が大切にしていることは、どうすれば会社に、あるいは会社からより多くの価値を生み出せるかということだ。平日は朝から晩まで働いているが、このことがいつも頭を離れない。」とも言っている。

『組込みソフトエンジニアを極める』の中では、商品の顕在的な価値と潜在的な価値の両方を高め、顧客満足を最大にする必要があると書いた。

価値を高めるために努力する、貢献するという考え方は分かりやすいし、ポジティブであり、その努力がはずれとなることが少なく、やる気にもつながる。

ゴーン氏の記事の次のくだりを読んで欲しい。

【引き続き、日経ビジネスの記事から引用】

日産自動車では限度ぎりぎりまでコミットメント（必達目標）を高く設定し、達成に向けて社員が成長できるようにしている。容易な目標を掲げれば、個人として、あるいは組織としての成長を経験できない。逆に目標が高すぎてもあきらめてしまう。一見難しいと思われる目標を達成した時、初めて社員は大きな喜びと自信を得るのだ。

生まれながらのリーダーなどいない。誰にでもリーダーになれる素質がある。問題はその素質が花開くかどうかだ。それを分けるものは何なのか。

１つは明らかに教育だと思う。学校の問題だけではない。教育は親の責任でもある。子供の能力の伸ばし、限界に挑戦する姿勢を身につけさせるうえで、親の果たす役割は大きい。
２つ目は経験だ。日産では新入社員に最初の職場から責任を与える。そして3～4年後、誰が最も成果を上げたかを見極め、より困難な仕事に挑戦させる。リーダーは難しい任務の中で育つからだ。

【引用終わり】

「権限もいらないから責任もとらないってあり？」の記事でも書いたように、日本では会社の中でも Best Effort といいつつ、本当はもっと力を出せるのに最大限の努力をしていない場合がある。新しいものへの挑戦に尻込みをする者もいるし、言われなければ動かない者もいる。ゴーン氏が語るコミットメント（必達目標）を設定し、責任を与え、より困難な仕事に挑戦させるということをしないと、人間は間違いなくだらける。権利だけを主張して責任を果たさなくなる。

日本人はピンチのときに誰の責任とは言わなくても、自己犠牲を払って一致団結し問題解決に当たるという非常によい性質を持っているものの、この手法で対処できるのは人海戦術で解決できる問題だけだ。

スキルが足らない場合はスキルの高い者に作業が集中してしまう。そうならないようにするためには、それぞれの技術者が高い目標を掲げそれをクリアしなければならないのだが、技術者が高い目標を掲げ、その目標をコミットすると大抵の場合はスキルアップのオプションがもれなく付いてくる。

スキルアップするためには、本を読んだり、調べ物をしたり、誰かに教わったりしなければならない。それは黙っていれば与えられるものではなく、自ら選択し獲得するものだろう。

これは普通に考えれば自己投資なのだが、ゴーン流に言えば「自分への貢献であり、働くことの本質」ということになる。日本人は働くことが好きな国民とよく言われるが、働くことが好きということはすなわち、社会や会社、自分自身への貢献度が強い国民ということになる。

みんなそのことは暗黙に認識しているので、社会や会社を裏切るような行為が発覚すると糾弾が厳しいのだろう。

働くことの本質が貢献であるのなら、どんなに長い時間勤務していても貢献度が低ければ働いているのではなく、ただ単に時間が過ぎているだけということになってしまう。

仕事をしている一瞬一瞬が働いていることになっているかどうかを見極めるには、その行為が何らかの貢献になっており、商品やサービスの価値を高めているかどうか考えてみるとよい。

教材がいいと受講者の食いつきが違うね

株式会社アフレルが提供する、エンジニア研修 システム開発体験コース　UML・ROBOLAB編を見学する機会があった。この研修については、組込みプレス Vol.4 の LEGOではじめるエンジニア研修事情でも－開発を疑似体験させることの効果－というテーマで記事を書いているのだが、この記事を書いたときは研修をじっくり眺める機会には恵まれていなかった。

LEGOを使った研修の内容と効果の分析については、組込みプレス Vol.4 を読んでいただくとして、この研修のどこが優れているのかについてレポートしたいと思う。

まず、使っている素材。教材のベースとなる LEGO MINDSTORMS は、LEGOブロックでおなじみのデンマークのLEGO社の関連会社が提供している。LEGO MINDSTORMS(レゴ マインドストーム)は、レゴ・エデュケーショナル・ディビジョン社（デンマーク）とマサチューセッツ工科大学が共同開発したロボットを作るキットで、ロボットの頭脳となるCPU内蔵のコントローラRCXには、日本のルネサステクノロジ社製のH8マイコンが搭載されている。

また、LEGO MINDSTORMS を使って、プログラミング言語を使わずにプログラムを作成するために開発されたソフトウェアがROBOLABで、このソフトはナショナルインスツルメンツ社の Lab Viewの技術がほとんどそのまま使われている。ROBOLABでは、「待ち」「モーター順回転」「停止」「今より暗くなるまで待つ」「押されるまで待つ」などのコマンドアイコンをつなぎ合わせてプログラムを作る。プログラムを分岐されることで、並行処理も実現できるので高度なプログラミングも可能だ。

コマンドアイコンの一つ一つは非常によくできたオブジェクトであり、パソコンを使った計測用ソフトで革命を起こした Lab View の技術が活かされている。

この研修の素材の説明で出てきたキーワードを並べてみると

• LEGO
• マサチューセッツ工科大学
• ルネサステクノロジのH8
• ナショナルインスツルメンツ社のLab View

とこれだけでも高度な技術の集積であることがわかる。Mindstorms の新製品 LEGO Mindstorms NXT ではさらに高度なロボットを作ることができ、コントローラのCPUには ARMが使われているとのこと。

ここまでで、素材がいいことはわかった。次はカリキュラムの内容を見てみよう。まず、この研修では、LEGO Mindstorms を使って写真にあるような、ライントレースができる自動車を２体作る。そして、一つの自動車を収集車とし、もう一つの自動車を配送車として役割分担する。

収集車は楕円の半分の距離をライントレースし、中継地点で配送車へ赤外線通信を使ってメッセージを送り、配送車はメッセージを受け取ったら楕円のもう半分の距離をライントレースして、配達地点に見立てた位置に到達したら中継地点に戻る。

2台のLEGOの自動車を使って、このシステムを作り上げ、顧客に見立てた観客にプレゼンテーションしてこのシステムを買ってもらうことがこの研修のミッションとなる。

研修では、ユーザー要求の分析から始まり、システム設計、外部設計、内部設計、プログラミング、単体テスト、結合テスト、システムテスト、レビュー、障害処理票の起票など、ソフトウェアシステムを作り上げるために必要な全行程を一通り体験できる。

分析、設計のドキュメントは、UML（Unified Mideling Language）の図を描いて作成する。この研修を終えると、ユースケース図、シーケンス図、アクティビティ図、コミュニケーション図などの図を自分で考えた内容で描くことができるようになる。単に問題と答えというやり方ではなく、システム開発に必要な図を、自分自身の設計で描くというところが、単なる講習会にはない Project Based Learning のよいところだ。

この研修は 5日構成で

1. ユーザー要求の分析と自動車の組み立て
2. UMLを使ったシステム設計、外部設計、内部設計
3. デバイスの特性を確認しながらプログラミング
4. 単体テスト、結合テスト
5. システムテスト、総合デバッグ、プレゼンテーション

という日程になっている。2日目が実機をさわることがほとんどなく、UMLでシステムを分析するだけの作業が続くテンションが下がる工程なのだが、実はここが大事なポイントとなる。

比較的規模の小さい組込みシステムの開発では、デバイスを動かすプログラムを作りながらできたらつなげていくという試行錯誤的アプローチを取ることで、ユーザー要求分析や、システムのアーキテクチャ設計などがなおざりになりやすい。最初にLEGOで作った自動車とLOBOLABでのプログラミングの使い方を教えてしまえば、受講者が中学生のように夢中で試行錯誤を繰り返してミッションをクリアしようとし、容易にメインテナンスできない継ぎ足し継ぎ足しのプログラムを作ってしまうだろう。

しかし、この研修ではあえてすぐにプログラムを作らせずに UMLを使ってシステムの分析を一日じっくりやらせる。

実は、この後システムの総合テストでうまく動かないときに、プログラムのどこが悪いのか分からずに悩むことになるのだが、初めて使うROBOLABの平行動作が十分に理解できず、デバッガも用意されていないため簡単には試行錯誤的なアプローチでは問題がなかなか解決できない。

このときに、2日目の分析工程で描いたUMLのダイアグラムで、やや抽象度の高い設計ドキュメントを見直すと問題解決の糸口が見つかったりする。

また、3日目で確認する光センサや、タッチセンサの特性をよく調べておかないと、自分の思い描いたように自動車は動いてくれない。光センサーからの入力値を絶対値で指定してしまうと、同じ部屋でも明るさの違いでうまく動かなかったりする。この研修ではPC上でのアプリケーションソフトウェア開発にはない、デバイスの特性を熟知していないとシステムが完成しない組込み系の制約条件の強い開発を体験できる。

また、4日目の単体テスト、結合テストでは本番で使うコースではなく、小さめのライントレースコースしか与えられないため、基本動作の確度を高めることに注力を注ぐ時間がある。

この時間が取ってあると、システムテストで起きた問題について、どこまで前工程に戻ればいいのかのあたりを付けることができる。同時に、単体テストや結合テストで確認できた内容については、やり直す必要がないことがわかるので問題の切り分けにも役立つ。

しかし、なんだかんだいってシステムテストレベルでうまくいかないと試行錯誤が始まる。2人一組で役割が違うので、中継所地点でメッセージの受け取りがうまく行かないと、収集車が悪いのか配送車が悪いのか分からなかったりする。双方が疑いのまなざしで見たりするのだが、受け取ったことが分かったら確認音を鳴らすなどのくふうをして、問題の切り分けをする。（現場のハード屋さんソフト屋さんも見習うべきだろう）

そして、最終日のプレゼンテーションでは、そのシステムがいかに優れているかを顧客に説明し、基本動作のみならず、ライン上に障害物が置いてあっても障害物を避ける動きができるといった実演を見せる。

もちろん、システムテストで確認しているのでキチンと動く筈なのだが、何しろ光センサが微妙だったり、スタートしてから配送車が中継地点に戻るまでの時間制限が40秒だったりするので、研修参加者は実演するときはドキドキしながら自動車の動きを見守ることになる。

この緊張感がいいのだ。

この教材を開発した株式会社アフレルの小林社長は、小学生、中学生、高校生に LEGO Mindstorms を使った教材を提供しつつ、社会人向けのこの教材を3年かけて練りに練って作った。もともと小林さんはビジネス系のソフトウェアを正統な方法で開発していただけあって、この研修の流れも理想的なプロセスになっている。その上で、組込みならではのデバイスの特徴の確認の重要性や、制限時間40秒という制約条件などの設定が巧みにちりばめられており、ところどころで「さすが、よく考えられている」と感じさせられる。

教材がいいと受講者の食いつきが違う。この研修を見てしまうと、Power Point で資料作って講義するだけの教材じゃ太刀打ちできないなあと思ってしまう。

そこまでやってもらわなくても、先輩から技を盗めよ！と言いたいところだが、先輩がUMLのことを知らなかったりすると技を盗みようがないし、最近のソフトウェア工学は本読んだだけじゃ理解が難しいことが多いので、ソフトウェア技術者にこのような研修を受けさせることも必要なんだと感じた。

『組込みソフトエンジニアを極める』も仮想プロジェクトで読者に成功体験させることをねらっているものの、やっぱり実際に手を動かしながら進める研修には勝てないかもね。