Windows Embedded CE で変わる組込み開発

みなさん、こんにちは

(株）富士通ラーニングメディアの鈴木です。

5回目は「Windows Embedded CE 6.0で変わる組込み開発」についてです。

前回の記事はこちら

Windows Embedded CE 6.0 は、マイクロソフト社の組込み機器向けリアルタイム OS です。Windows Embedded CE 6.0を使用することで、組込みシステム開発メーカーは、市場投入期間の短縮化と開発コストを削減しつつ、豊富なメディアや通信コンポーネントを使用した機器を開発することができます。今回は Windows Embedded CE 6.0 の開発についてご紹介いたします。

単一のツールですべての開発工程をサポート

通常の組込み開発の場合は、プログラミング、デバッグ、テストなどで使用するツールがばらばらだったり、もしくは同一ツールでも機能が別売りになっていたりする場合も多いですが、Windows Embedded CE 6.0 の場合はすべての作業を Visual Studio 2005 上で行えます。
Windows Embedded CE 6.0 標準にサポートしているツールには以下のようなものがあります。

❑ファイル ビューア … 開発 PC からターゲットデバイスに対しファイルをやり取りするツールです
　

❑ヒープ ウォーカ … 各プロセスが持つヒープの詳細情報を確認できます

❑ズームイン … ターゲットデバイスの画面をキャプチャします

❑プロセス ビューア … 各プロセスが持つスレッドとモジュールの詳細情報を確認できます

❑レジストリ エディタ … ターゲットデバイス上のレジストリに変更を加えることができます

❑システム情報 … ターゲットデバイス上のシステム情報を確認できます

❑パフォーマンス モニタ … ターゲットデバイス上のパフォーマンスを計測できます

❑スパイ … ターゲットデバイス上のアプリケーションウインドウが受信したメッセージを確認できます

❑カーネル トラッカ … ターゲットデバイス上のスレッドとプロセスの状態をリアルタイムに確認できます

機能のコンポーネント化により、開発工数を短縮

Windows Embedded CE 6.0では各OSの機能がコンポーネント化されています。必要なコンポーネントをカタログ項目ビューから選択することにより必要最小限の組込みOSを作成することができます。
コンポーネントを選択する際、あるコンポーネントが動作するには別のコンポーネントも必要な場合があります。このように、コンポーネント同士が依存関係を持っている場合でも、Windows Embedded CE 6.0は自動的に依存関係のあるコンポーネントを追加してくれます。右図の 【チェックマーク（緑色）】（注１）が追加したコンポーネントで、【四角（緑色）】(注２）が依存関係のために自動的に追加されたコンポーネントです。


 

豊富なCPU・ボードに対応

Windows Embedded CE 6.0は、ARM系、SH系、MIPS系、x86系など、実に200種類以上のボードに対応しているとのことです。もちろんCPUやボードが変更になればBSPを始めハードに近い部分の修正は避けられませんが、共通で利用できる部分も多く、アーキテクチャの変更にも柔軟に対応できます。なによりも開発環境が全く同じであるというのが、心強いですね。

シェアードソースコード

Windows Embedded CE 6.0では、OS内部のソースコードも公開されています。そのため、障害が発生した場合は、OSの内部ソースも含め追跡して障害を突き止めることができ、万が一OS内部のソースコードに障害の原因がある場合でも、迅速に対応することができます。

最後になりますが、Windows Embedded CE 6.0は単に組込みOSを指すだけでなく、非常に多くの機能を持ったツール群も含んでいます。これらすべてを使いこなすのはなかなか難しいかもしれません。

ここで、弊社の研修をご紹介させていただきます。

まずは手始めに弊社の「Windows Embedded CE 6.0基礎」(1日間)をお勧めします。このコースは日本初のマイクロソフト社認定のWindows Embedded CE 6.0トレーニングコースです。

基礎で大まかな流れを把握していただき、「Windows Embedded CE 6.0応用」(3日間)でさらに理解を深めていただくことができます。各コースの詳細な内容に関しては、それぞれのリンク先をご確認ください。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
　お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

プロジェクトマネージャーの育成 不祥事多発！ 仕事ができるプロマネの「プロフェッショナル責任」とは （２）

みなさん、こんにちは
（株）富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア（http://ascii.jp/cate/21/）に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回も、プロフェッショナル責任についてです。

前回の記事はこちら

*******************

マネジメントで全体最適を目指す
　プロフェッショナル責任が大切だということは、誰もが頭では理解できていると思います。現に、世の中で起きている問題の多くは“技術的な問題”というより、“行動”に関する問題です。問題を事前に食い止めようとすれば、食い止められる単純なことなのです。では、これらを守っていくにはどうすればいいのでしょうか。

　対策の1つとしては、物事の判断基準を明確にすることです。「このときはいいけど、あのときはダメ」「今回は時間がなかったので、本当はダメなんだけど、いいことにしよう」など妥協やいい加減な判断があると、徐々にプロフェッショナル責任に対する意識が弱くなってしまいます。しかも、個々の品質の低下やプロジェクトの遅れ、トラブルにもつながっていきます。

　判断基準としては「全体最適」を目指すのがよいでしょう。プロジェクトを進めるとき、それぞれのメンバーは自分の担当箇所にとって最適を目指して仕事をするでしょう。それはプロとして重要なことではありますが、時に自分の担当の最適（部分最適）が、全体としての最適（全体最適）にならないことがあります。

　たとえば、あるパートが進行の遅れを取り戻すため、決められた方法を簡素化して作業を進めた場合。スケジュールどおりには進むでしょうが、そこではルールが無視されています。するとその結果、全体として不良個所が発生し、成果物は最適とは言えなくなります。確かに、個別で部分的な作業をすることの多いメンバーが、常に全体最適をとるのは困難です。そこで、プロジェクトマネージャーが全体の最適を目指してプロジェクトをコントロールし、小さなズレや間違いを早く修正して全体の最適に向かわせなければならないのです。

仕事をするすべての人が、PMBOKを学習する必要がある
　プロジェクトマネージャーやプロジェクトに関わるメンバーに限らず、プロとして仕事をしていくにはプロフェッショナル責任を強く意識することが大切です。それには時に教育をすること、教育を受けることも必要でしょう。そして、トラブルや失敗を起こしてしまったとき、正直に話すという責任が果たせるようにならなくてはなりません。結果的にそのことで一時的に個人や組織が非難されるかも知れませんが、逆に以前に増して信頼を得られることもあります。

　たとえば、不祥事をいち早く公表して、対策をとった家電メーカーが過去にありました。多大なコストをかけて新聞やテレビ、インターネット、ハガキなどで製品の欠陥を大々的に公表し、すべての消費者を対象に使用の停止と製品の回収を呼びかけました。するとその会社は「公正で誠実な会社である」という評価を得ることができたのです。

　最後に、プロジェクトマネジメントで教科書的に使われるPMBOKは、プロジェクトを進めていく際に、非常に有益で実践的な内容で構成されています。PMBOKはプロジェクトマネージャー向けの書籍ですが、プロジェクトマネージャーだけでなく、プロジェクトに関わるメンバーすべてが理解しておくことで、プロジェクトが成功に向かってスムーズに進むことでしょう。なので、プロジェクトに関わるすべての人に学習することをお薦めします。PMBOKで身につけた知識は、プロジェクトマネジメントに限らず、あらゆる仕事をしていくうえでもとても役立つことでしょう。

プロジェクト成功のポイント
・常に勉強を怠らずさらなる専門性を高めなければならない
・どんなときも、正直に、誠実に対応しなければならない
・プロジェクトメンバー、お客さんなどのステークホルダーと信頼関係を築く
・プロマネだけでなく、プロジェクトの関係者は「PMBOK」を勉強する
*******************

このブログでご紹介したスキル診断が対応しているＩＴスキル標準の職種プロジェクトマネジメントも、このＰＭＢＯＫに対応しています。
以下の記事もご参照ください。

→　「スキル診断の結果より～職種・専門分野ごとのスキル状況（１）～」の記事

▼２０回にわたって、「プロジェクトマネージャーの育成」を連載してまいりましたが、本日で最後となります。
ご意見やご感想をお待ちしております！
また「このようなテーマを取り上げてほしい」など、お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

プロジェクトマネージャーの育成 不祥事多発！ 仕事ができるプロマネの「プロフェッショナル責任」とは （１）

みなさん、こんにちは
（株）富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア（http://ascii.jp/cate/21/）に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、プロフェッショナル責任についてです。

前回の記事はこちら

*******************

より“責任が問われる”時代
　最近、企業の不祥事が明るみに出ることが多くなっています。しかも不祥事を隠そうとして、さらに事態を悪化させてしまうケースが目立ちます。このような社会状況では、会社の姿勢としてコンプライアンス（法令遵守）やアカウンタビリティー（説明責任）が厳しく問われるようになりました。

　かつては、意識しなくてもこのようなプロフェッショナル責任がわざわざ問われることはそれほどありませんでした。しかしあえて問われなくてはならないほど“できていない”ことがあるのです。コンプライアンスというのは、法律などが守られないがためにわざわざ宣言しなければならなくなるということでしょう。

　そこで、プロジェクトマネージャーにもプロとして、自らだけでなくステークホルダーに対して公正かつ誠実な仕事をするようにマネジメントすることが一層求められようになっているのです。

プロフェッショナルとしての責任意識
　では、具体的にプロジェクトマネージャーがプロフェッショナル責任を持つというのは、どういうことなのでしょうか。ここでいうプロとは、ただ専門性が高いことを指しているのではありません。高度な専門性を身につけているのはもちろん、高い技術者倫理を持っていることが含まれます。簡単に言えば正直かつ誠実な仕事ができることです。これらは当たり前のことですが、近年ではないがしろにされている傾向にあります。

　たとえば技術者倫理の低さの現われとして、「技術に疎い人にもわかりやすく説明する」という基本的な責任を忘れられている点があるでしょう。この傾向が顕在化したのは、技術の高度化・専門化が進んだことで、それ以外の理解していない人が増えたことが原因です。相手がわからないからといって、説明をしないで勝手に進めるのはよくありません。わかるように説明したり、素人が気づかない部分は気づかせてあげたりする。そして納得を得てから進めることが非常に重要であり、プロとしての責任です。「説明してもわからないので説明しない」というのは、素人をだましていることと同じです。このことを深く心に留めておてい下さい。

　また、加えてここに必要なプロフェッショナルの意識としては、高い専門性を持っていても、それを活用できないと単なる知識に過ぎないということへの認識です。技術や知識を生かしてこそビジネスになり、プロフェッショナルとしての存在意義がが生まれます。高い技術があり、それが適切な形で生かされることで、社会に役に立つ技術として成り立ちます。

*******************

このブログでご紹介したスキル診断が対応しているＩＴスキル標準の職種プロジェクトマネジメントも、このＰＭＢＯＫに対応しています。
以下の記事もご参照ください。

→　「スキル診断の結果より～職種・専門分野ごとのスキル状況（１）～」の記事

次回も引き続き、「プロフェッショナル責任」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
　お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

電気

みなさん、こんにちは

(株）富士通ラーニングメディアの鈴木です。

４回目は、「電気」です。

前回の記事はこちら

「電気」とは

　電気と聞いてみなさんはどう思われますか。古臭い分野で、もはや時代遅れの領域、工学系の学校でも人気にかげりの出てきた学問。そんなイメージをもたれてはいないでしょうか。あるいは、｢ビリビリして怖い｣「下手に触ったら壊しちゃいそう」なんて思っていませんか。でも実際には私たちの生活に密着して、切っても切り離せないんですね。どうしてでしょう。
　電気はエネルギーの一つです。エネルギーといえば他にもいろいろあって、例えば熱もエネルギーですし、高いところからものを落とすことで、重力をエネルギーとして使うこともできます。エネルギーはそれを使っていろいろな仕事をさせることができるのですが、普通は作る場所と使う場所は異なります。ですから、エネルギーは簡単に運搬、移動できると便利なんです。ところが、熱や重力はあまり移動に適しません。そこで、電気の出番です。電気は配線を接続するだけで簡単に場所を移動することができます。あるいは電波を使えば、ワイヤレスで場所を移動することができます。また小さなエネルギーとしてものすごく微少な量を扱うことも得意です。モバイル機器の普及などは、この特長をうまく利用している例ですね。
　このような電気の特長をうまく使って、これまでに真空管や半導体を経てマイコンが生まれました。組込みシステムのハードウェアは、このマイコンや電子部品を使って作られているというわけです。

ソフトウェアとハードウェアの境界

　組込みシステムを作っていくには、ソフトウェアだけを単独で開発していくことはあまりありません。通常は、組込みシステムが動作するハードウェアも並行して開発していくことになります。すでにあるハードウェアを用いてソフトウェアを開発していく、いわゆるエンタープライズ系の開発とは、ここが大きく異なります。エンタープライズ系のソフトウェア開発では、何らかの障害が発生した場合、まずソフトウェアに原因があると考えることができます。これはハードウェアがすでに完成しているため、障害の原因要素から省いて考えることができるためです。一方組込みソフトでは、ハードウェアも並行開発しているため、必ずしもハードウェアに間違いがないとは言い切れません。したがって障害の原因として、ハードに原因があるのかないのかを切り分けられる力はとても大切です。例えば、そもそも配線がつながっていなければ、うまく動作するわけはありませんから、その原因究明にソフトのデバッグを行っていても、多大な時間の浪費にしかならないですよね。

開発の現状

　ところが、実際の開発の現場ではこのような時間の浪費が多くなされています。なぜなら組込みソフトウェア技術者がハードウェアに対する知識や技術が十分でないため、ハードウェアに起因する不具合を見極められないからです。しかしながらこれは当然のことです。もともとソフトウェア技術者は必ずしもハードウェアに関する教育を体系的に学んでいるとは限らないからです。最近では文系出身者が組込みソフトウェア技術者になっていることだって珍しくありません。そういった方々は電気について学んだ経験がほとんどないでしょう。中学校の理科か高校の物理で少しかじった程度でしょうから、はるか昔の記憶の彼方に消え去ってしまってもなんら不思議はありません。

記憶をほじくりかえそう

　そうは言っても、忘れていたままではもったいないですね。はるか昔とはいえ、せっかく学んだことで、かつ大きな武器になるのだったら使わない手はありません。ほんの少しだけ時間を使ってきっかけを作ってあげれば、すぐに思い出すことができるはずです。そうすれば、開発時間の無駄な浪費を省くことができるのと同時に、不必要に遠慮することなくハードウェア技術者とも自信を持ってコミュニケーションできるようになります。基本が分かっていれば、今度はハードウェア技術者は新しいことをどんどん教えてくれることでしょう。それが組込みソフトウェア技術者としての能力を向上させることに結びつくことは明らかです。ぜひとも高校の物理の教科書をひっくり返して、記憶のすみをほじくりかえしてみてください。

次回は組込みOSで着目されているWindows　Embedded　CEについてお話しします。キーワードは「日本初」です。お楽しみに。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
　お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

プロジェクトマネージャーの育成 発注者として必須の意識とは 「調達・マネジメント」 （２）

みなさん、こんにちは
（株）富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア（http://ascii.jp/cate/21/）に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回も、調達・マネジメントについてです。

前回の記事はこちら

*******************

根底には「任せておけばいいや」の意識の甘さがある
　たとえば最初に調達・マネジメントのルールがしっかり決められていたとしても、プロジェクトの進行フェーズでルールがなし崩し的に乱れ、最終的に納入側が自分たちがやりやすい方法で作業を進めてしまうことも現場ではよくあります。これは、できあがった成果物の外見は繕っているけれども中身は混沌としているため、メンテナンスのときにトラブルが起きるという事態につながりかねません。トラブルは開発段階より、運用時やメンテナンス時に起きることが多いのです。それは、システムは開発期間よりもはるかに長い期間で運用されるからです。そのことをしっかりと念頭に置いて、納入側に中身も整えられた成果物を納品してもらえるようにマネジメントしなければならないと考えて下さい。

　さらに、受注した会社がより下請けに発注するときにはルールがもっと曖昧になりやすくなります。それを防ぐ方法は、まずスタート時に調達側がしっかりとルールを説明し、そしてプロジェクト進行の途中にルールどおりに行なわれているかをチェックすることです。これを行なうだけで、トラブルはかなり防げると思います。

　かつては系列の会社が下請けを育てるという意識がありました。知識や経験は調達側の方がはるかに豊富に持っていたのです。しかし、今では納入側の方が力をつけ、調達側にスキルが足りないという状況でしょう。調達側は、このスキルの差を埋める努力が必要なのかもしれません。

　しかし、調達側がマネジメントできないのは、知識や経験の不足によるところだけではないと思われます。「任せておけばいいや」という甘えや、意識の低さが根底にあるのです。つまり、調達者としての意識がプロフェッショナルではないということでしょう。一方、受注者は「先方はどうせわからないだろう」と高を括っている部分もあるのかもしれません。双方ともに、そのような考えを捨て、ルールに則ってプロジェクトは進めていくべきです。

プロジェクト成功のポイント
・調達先から納入された成果物はきちんと検収する
・調達契約を結んだらプロジェクトの特に設計や運用ルールを納入者に説明する
・プロジェクトの進行過程の途中段階でも調達先の状況をチェックする

*******************

このブログでご紹介したスキル診断が対応しているＩＴスキル標準の職種プロジェクトマネジメントも、このＰＭＢＯＫに対応しています。
以下の記事もご参照ください。

→　「スキル診断の結果より～職種・専門分野ごとのスキル状況（１）～」の記事

次回は、「プロフェッショナル責任」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
　お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

プロジェクトマネージャーの育成 発注者として必須の意識とは 「調達・マネジメント」 （1）

みなさん、こんにちは
（株）富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア（http://ascii.jp/cate/21/）に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、調達・マネジメントについてです。

前回の記事はこちら

*******************

一括作成請負で、いわば「丸投げ状態」
　プロジェクトというものは必要な作業のすべてを内部でまかなうことはほとんどなく、外部の手を借りることになります。特に日本のIT業界の場合は、一括作成請負という契約方法で外部に作業を丸ごと任せることがよくあります。それは、発注する案件の専門性が高く、自社に十分な知識や技術を有している人材がいないので、専門家に任せてしまおうという考えによるものです。しかし、そうするといわゆる「丸投げ状態」になってしまい、意図していたものと違う成果物が納品され、「こんなものを頼んだのではない」とトラブルになる場合があります。これでは、調達側は成果物の納品日が遅れてしまうおそれが出てしまうし、納入側には手戻り作業が発生してしまうでしょう。両者ともに不利益が生じるのです。

　また、トラブルの原因となるのが、納品時の検収不十分があります。検収を怠ることで、システム稼働後のメンテナンス時に問題が発生するケースとなるのです。この場合、システムがブラックボックスのままなので、トラブルの原因を解明するのが非常に困難となります。

イニシアティブを持ってルールの決定と説明ができていない
　プロジェクトというものは、多くの会社が関わります。そして、そこには製品を調達する側と納入する側があり、調達する側にはそれを管理する「調達・マネジメント」が必要となります。PMBOKガイドには「外部の組織（購入者）が実行組織（納入者）からプロジェクトを取得する際に発行する契約書の管理、およびプロジェクト・チームに課される契約上の責務の管理を行なう」と書かれています。つまりプロジェクトの本体が外部からサービスや成果物などを調達する場合、発注、契約などスタート時点から納入まですべての過程で、決められたルールどおりにできているかを管理する必要があるということです。

　調達・マネジメントでトラブルが起こるのは、契約管理のときにルール決めがしっかりなされていないからです。何をどのように、いつまでに、そしていくらでということだけでなく、細かい設計ルールや運用の方法なども決める必要があります。そして、これらのことは調達側がイニシアティブを持って行なわなければなりません。しかしながら、冒頭で述べたように、はじめに決めておく必要がある事柄に関して調達側がよくわかっていないケースがあり、その結果「丸投げ」となることが多いようです。

*******************

このブログでご紹介したスキル診断が対応しているＩＴスキル標準の職種プロジェクトマネジメントも、このＰＭＢＯＫに対応しています。
以下の記事もご参照ください。

→　「スキル診断の結果より～職種・専門分野ごとのスキル状況（１）～」の記事

次回も引き続き、「調達・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
　お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

組込みシステムにおけるプロジェクトマネジメント

みなさん、こんにちは

(株）富士通ラーニングメディアの鈴木です。

３回目は、「組込みシステムにおけるプロジェクトマネジメント」についてご紹介いたします。

前回の記事はこちら

組込みシステム開発における「プロジェクトマネジメント」を、エンタープライズ系の開発との違いに焦点を絞って考えてみたいと思います。

ソフトとハードのコンカレント開発

  組込みシステム開発におけるプロジェクトマネージャ（ＰＭ）は、お客様から仕様の提示を受ける、または、お客様とともに仕様を考えるというエンタープライズ系の開発とは異なります。組込みシステムでは、お客様、または、マーケットを想定して自分たちで仕様を考えることになります。その時、仕様を、ハードウェアで実現するのか、あるいは、ソフトウェアで実現するのか、開発費、製造コストの両面で、ハードウェアＰＭとソフトウェアＰＭ（あるいは、プロダクトマネージャ）が一緒になって考える必要があります。
第２に、ソフトウェアＰＭは、ハードウェアからのインプット情報や試験用ターゲット機器の提供時期について、ハードウェアＰＭとしっかり情報共有し、常に神経質に、その開発状況を把握しながら、リスクの管理をする必要があります。
第３に、ハードウェア開発者とソフトウェア開発者が、一緒に試験を進めることも多いのですが、それぞれのＰＭは、自分たちの品質だけではなく、他者の品質にも十分注意して、部下に対する指示を行う必要があります。

問題対応

第4に、試験等で発生した問題対応についても、ハードウェア開発者とソフトウェア開発者が一緒になって調査や解決手段の検討をするのが、格段に効率がよいようです。簡単なインタフェースの変更で済む場合は、ハードウェアの不具合をソフトウェアで吸収したほうがシステムで考えた場合はいい場合もあるでしょう。また、ソフトで複雑な制御を仕様追加するより、ハードウェア的にバッファメモリを増やして、製造コストを多少犠牲にしても開発コストを抑えたほうがいい場合もあるでしょう。こういったことを、システム全体で最適解にまとめていくには、ハード／ソフト双方のＰＭがコミュニケーションを含めうまく機能している必要があります。

コストとスケジュール

第5に、コストを考えるとき、開発コストだけではなく、当然のことながら、部品や製造も考慮した製品コストも検討する必要があります。先ほど触れたように、ソフトとハードの両面で考えることも必要です。
第6に、スケジュールを考えるとき、開発だけに着目するのではなく、部品の供給や製造を含めたスケジュールの管理が必須です。開発と同様に、製造などについてもトレードオフの関係になることが多いコストとスケジュールを、切り離して考えることはできません。もちろん、これらは、マーケットとの兼ね合いも含めて考える必要があります。

ブートやドライバの開発

ソフトウェアＰＭが、注意したほうがいい特殊な開発として、汎用ＯＳなどでＢＳＰやＬＳＰとして扱われている、ブートやデバイスドライバの開発が挙げられると思います。これらは、ハードウェアに非常に密接な部分なので、トラブルが起きた場合には、スケジュールに大きく影響を与えてしまうことも珍しくありません。そういう意味で、しっかりリスク管理すべき項目の一つといえるでしょう。

以上で、今回の「プロジェクトマネジメント」のご紹介は終わりです。みなさん、なんとなく、「プロジェクトマネジメント」、特に、組込みシステムにおける「プロジェクトマネジメント」について、イメージがつかめましたでしょうか？また、経験者の方にとって、共感できる内容はあったでしょうか？

次回のテーマは、「電気」です。ソフトウェア開発者でハードウェアはさっぱり、という方にもわかりやすくお話します。お楽しみに。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
　お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

プロジェクトマネージャーの育成 危機管理はまだまだ甘い？ 「リスク・マネジメント」の第一歩 （２）

みなさん、こんにちは
（株）富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア（http://ascii.jp/cate/21/）に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回も、リスク・マネジメントについてです。

前回の記事はこちら

*******************

プロジェクトの途中にこそ、リスク・マネジメントは必要
　このリスク分析は、プロジェクトのスタート時にはしっかり行なわれているようですが、プロジェクトの途中ではあまり行なわれていないようです。そのため、途中で発生するリスクについては対策が練られておらず、トラブルが起きたときに対応する問題解決型のマネジメントになってしまいます。プロジェクトは進行していくに従って状況が変わっていくもので、それに合わせてリスクも変化します。したがって、プロジェクトの途中にもリスク分析をし、対策を立てる必要があります。定例の会議の中で、進捗について報告するだけでなく、リスクについても話し合う機会を作るとリスクを共通認識できることでしょう。プロジェクトの全体を通して、リスクについて分析予測し、対策を立て、リスクを追跡することで、はじめてリスク・マネジメントができていると言えるのです。

リスクを「ゼロ」にするという間違った発想
　リスク・マネジメントの目的は、リスクをゼロにするのが目的ではありません。その影響を最小限に抑えることにあります。リスクの判断基準は0％か100％ではなく、五分五分でその五分のリスクについて小さくする対策を取るという考え方が必要です。

　プロジェクトのリスク・マネジメントでよく起こる問題としては、人材の確保があります。たとえば、あるプロジェクトの成功にはAというエンジニアの技術が必要だとします。そのエンジニアAは、現在別のプロジェクトに関わっていて、終了後にプロジェクトに参加してくれる段取りになっています。このケースでは、リスクの1つとして「先のプロジェクト作業が延びてエンジニアAがプロジェクトに参加できなくなる」ことが考えられます。この場合は、今関わっているプロジェクトのマネージャーに、エンジニアAが次のプロジェクトに必ず必要であることをしっかり伝えプレッシャーを与えたり、もしものことを考え、エンジニアAの次に適任だと思われるエンジニアBの手当をするのがリスク・マネジメントです。こうしてプロジェクトのリスクを小さくしていくのです。

　リスクはゼロにはならないし、ゼロを目指すというものでないことは先に解説しましが、「新技術適用を検討する」プロジェクトでは、新技術適用のリスクをゼロにするために、はじめから新技術を諦めるなどの安全な方法ばかりを選択していては、よりよい成果物はできないし、新しいことにチャレンジできません。最善のものを目指しつつ、その中でリスクを小さくしていくのがリスク・マネジメントのあるべき姿と言えるでしょう。

　最後に、リスク分析をし、ある事柄がリスクが大きいと判断しても、それを承知の上でプロジェクトを進めていく場合があります。これはプロジェクトマネージャーの判断ではなく、組織としての判断が下された場合です。組織としては上を目指したり、政治的な判断により、リスクを受け入れることが多々あります。このようにリスクについての考え方は、プロジェクトマネージャーの判断を超えるケースがあることを承知しておいてください。

*******************

このブログでご紹介したスキル診断が対応しているＩＴスキル標準の職種プロジェクトマネジメントも、このＰＭＢＯＫに対応しています。
以下の記事もご参照ください。

→　「スキル診断の結果より～職種・専門分野ごとのスキル状況（１）～」の記事

次回は、「調達・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
　お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

プロジェクトマネージャーの育成 危機管理はまだまだ甘い？ 「リスク・マネジメント」の第一歩 （１）

みなさん、こんにちは
（株）富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア（http://ascii.jp/cate/21/）に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、リスク・マネジメントについてです。

前回の記事はこちら

*******************

リスクに対する認識が甘さが及ぼす影響
　新しい事業を立ち上げたり、プロジェクトを進めたりするのにリスクは付き物です。しかし、ある事柄がリスクであるとわかっているにも関わらず、先送りにしてしまう事があります。それは「直接被害が及ばない」「まだ大丈夫だ」と考えてしまうからでしょう。でもそうすると、リスクの拡大、対策の選択肢の減少、手戻り作業の発生、新たなリスクの表面化などさまざまな悪い事態を招くことになります。プロジェクトの成功は、このリスクにどう対応していくかにかかっています。これができないと、プロジェクトを進めるどころか、問題解決だけに終始してしまう可能性が高いでしょう。

ほかのプロマネ、メンバー、ステークホルダーから多角的な視点を得る
　リスク・マネジメントという考えを強調するようになったのは、ここ数年のことです。それまではトラブルが起こるたびに解決していくという問題解決の考え方が一般的でした。つまり、「モグラたたき」のような解決方法だったのです。しかし、これではプロジェクトを進めることよりも問題解決に時間とコスト、労力を取られることになりプロジェクトは疲弊してしまいます。そこで起こりうる問題を予測し、事前に対策しておいた方が賢明であるという考えに基づいたのが「リスク・マネジメント」であったのです。

　このリスク・マネジメントで、まず大切なことはプロジェクトにどんなリスクがあるのかを洗い出す作業をすることです。コストは予算内に収まるのか、スケジュールどおり進むのか、人手は足りているのか、どんなリソースが必要なのか、さまざまな方面からの洗い出しをするのです。その際、他のプロジェクトに関わったプロジェクトマネージャーに「どのようなリスクが考えられるか」過去の経験を聞くことをお勧めします。つまり、ここでもこれまで何度も解説してきた「過去のプロセス資産を生かす」ことが大切となるのです。また、プロジェクトのメンバーだけでなく、ステークホルダーも含めてこのリスクの洗い出しをするとよいでしょう。見る眼が違ってくると問題の視点が変わり、新たなリスクが発見できるはずです。

定性的リスク分析と定量的リスク分析
　さらにリスク・マネジメントにおいて大切なことがもう1つあります。前述のリスクの洗い出しだけでなく、リスクをしっかり認識するための「リスク分析」ができることです。

　具体的なリスク分析の方法には、定性的リスク分析と、定量的リスク分析があります。まず定性的リスク分析については、PMBOKガイドによると「リスクの発生確率と影響度を評価し、組み合わせ、この後の分析や対処のためにリスクの優先順位付けを行なう」と書かれています。つまり、リスクには大小があるので、相対的にランキングをつけて優先すべきリスクとそうでないリスクを分けるのです。また、定量的リスク分析は「識別したリスクがプロジェクト目標の全体に対して与える影響を数値的に分析する」とあり、定性的分析で優先度が識別されたリスクに対して、それぞれがどれくらい重要なのかを今度は認識しやすいように数値で表し分析します。つまり各リスクの対応にどの程度のリソース（金額・時間・人材など）が必要となるのかを判断し、この分析をもとに優先順位をつけて対策を立てていくのです。
*******************

このブログでご紹介したスキル診断が対応しているＩＴスキル標準の職種プロジェクトマネジメントも、このＰＭＢＯＫに対応しています。
以下の記事もご参照ください。

→　「スキル診断の結果より～職種・専門分野ごとのスキル状況（１）～」の記事

次回も引き続き、「リスク・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
　お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

モデルベース開発

みなさん、こんにちは

(株）富士通ラーニングメディアの鈴木です。

2回目は、「モデルベース開発」についてご紹介いたします。

前回の記事はこちら

リモコンカーを動かそう
「モデルベース開発」の説明の前に、まずは、研修の際に開発の対象となるリモコンカーについてご説明します。写真ではボディを取り外しているため、オフロードカーに見えますが、れっきとしたレーシングカーです。スピードを競う訳ではないのですが、性能はバッチリです。キャッツ株式会社が研修用に作成したもので、家庭用のリモコンを使用し、右/左、前進/後進などを操作することができます。車体にある2つのボードは、1つが赤外線制御用、もう1つが駆動用となっていて、ボード間は、なんとCAN（車載ネットワークプロトコル）で接続されています。リモコンカーを走らせることによって、通信制御、センサー制御、モーター制御などのソフトウェアを、楽しく学習することができます。

組込みシステム開発の現状は
リモコンカーを走らせるのは楽しいことですが、「モデルベース開発」研修の目的は別にあります。
組込みシステムでは、通常、ハードウェアとソフトウェアを並行して開発していきます。ハードウェアが完成してからソフトウェアを作るのでは、まず納期に間に合わないため、ハードウェアが完成する前に、ソフトウェアの作成にかかります。しかし、プログラムの動作を確認するには、ある程度のハードウェアが完成している必要があります。
ハードウェアが正常に動作するかどうかは、実際に、もの（ハードウェア）を動かして確認するのが一番ですが、もっと早い段階でプログラムが仕様どおりに動作するか確認できます。一般的には、開発者同士でレビューを行うことで、設計書の漏れなどを見つけ出します。レビューを行い、ソフトウェアとしての品質を高めていくのです。

「モデルベース開発」とは
複数のモデル（図）を使用して、ソフトウェアを開発していくことを「モデルベース開発」といいます。組込みシステムには、システムがある状態を持ち、外部からのイベントによってその状態が変化するといった動作を行う開発をすることが多くあります。たとえば、ビデオプレーヤのボタン操作（ボタンを押すと、再生・停止をする）などをイメージしていただければ、理解しやすいでしょう。このように状態が遷移する場合は、その様子が分かる「状態遷移表」というモデル図を使用します。
ソフトウェア開発では、いろいろなモデルを使用し、ソフトウェアの動作を目で見えるようにしていく作業が必要になってきます。

ツールを使用し、効率的にプログラムを開発しよう
この「状態遷移表」は、システムの動作を分かりやすく整理したモデルです。この動作が仕様どおりなのかをプログラムを動かす前に確認できれば、ソフトウェアの品質を早い段階から向上させ、効率よくプログラムを作成することができます。そこで、「モデルベース開発」の研修では、状態遷移表作成ツールとして、キャッツ株式会社が提供するZIPC（ジップシー）を使用します。ZIPCでは、状態遷移表の設計から、シミュレートによる動作確認までを、プログラムを作成するまえに行うことができるため、効率的、かつ、高品質なソフトウェア開発を行うことができます。さらに、プログラムを自動生成し、実機を使用したエミュレートまで行うことが可能です。

システムがどのような状態を持つべきなのかは、システムを設計する人が考えていきます。すなわち、システム設計者の考え方によって、そのシステムの品質が左右されるわけです。
最後に、「状態遷移表」を作成するうえでのポイントをお話して、「モデルベース開発」のご紹介を終わりにしたいと思います。

「状態遷移表」を作成するうえでのポイント
・ 表内の状態数をあまり増やさない
・ 複数の独立した表に分割する
・ 可読性を考慮し、シンプルに作成する

❑関連コースはこちら
組込みソフトウェア開発におけるモデルベース設計～状態遷移設計を中心にして～

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
　お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

プロジェクトマネージャーの育成 クライアントとの言った、言わない問題…… 情報伝達の「コミュニケーション・マネジメント」 （２）

みなさん、こんにちは
（株）富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア（http://ascii.jp/cate/21/）に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、前回に引き続き、コミュニケーション・マネジメントについてです。

前回の記事はこちら

*******************

悪い情報をクライアントへ開示する重要性
　コミュニケーション・マネジメントの失敗でよくあることは、チーム・マネジメントの回（注１）でも解説した「悪い情報が行き渡らない」ケースの存在です。社内で対策を考えて対処し、それからクライアントに伝えるという段取りを踏むことも状況によっては仕方ないですが、基本的に悪い情報はできるだけ早く伝えるべきです。特に昨今のプロジェクトは専門性の高いものが増えているため、専門的なところは専門家に任せようという社会的な流れがあります。そのため、プロジェクトをほぼ丸投げで任されることもあります。この場合でも、高い信頼関係の下でプロジェクトを推進できるように、悪い情報ほどきちんとクライアントに開示していくことが重要です。

100％正確に伝わる情報はないという認識
　これまでの内容を踏まえコミュニケーション・マネジメントのポイントをまとめると、必要とされる人に的確な情報を適切な方法で送ることが大切だということですが、しかしこれらは「情報が受け手に100％正確に伝わることはない」ことを常に前提とされるべきです。チームメンバー以外のクライアントに情報を伝える場面は、このような意識を一層持つ必要があります。

　たとえば、受け手は届いた情報を自分のフィルターに通して理解しようとします。その際に、情報はそぎ落とされたり、受け手側の都合のよいように解釈されたりするため、伝達側の意図通りに伝わることは、まずないでしょう（図1参照）。そこで伝達した後には、受け手が「どう受け取ったか」「間違いなく意図が伝わっているか」を確認し、合意するフォローが重要になります。これを怠るとよくある“言った、言わない問題”が起こり、プロジェクトの成功どころか、信頼関係の崩壊につながりかねません。念入りに行ないましょう。

 

図1:伝達側のメッセージは、受け手側のフィルターを通って認識される。また、受け手側のフィードバックの際には、伝達側のフィルターを通ることになる。

クライアントとの“言った、言わない問題”を防ぐために
　情報共有のよい方法として、会議では議事録をつけ、それを双方が確認し、合意することは特に大切です。議事録をつけるだけでなく、会議自体を録音するのもいいでしょう。そうすれば、それを元に議事録を作ることもできるし、万一に“言った、言わない”の水掛け論に発展しても、録音した内容で確認できます。会議で誰もが責任ある発言をするような効果もあるでしょう。

　このように、多くの人が関わるプロジェクトだからこそ、メールなのか、会議なのか、どれくらいの頻度で情報交換を行なうかなどのコミュニケーションルールを決めることは大切です。相手の合意と確認はプロジェクトの命運を左右する重要なポイントとります。

プロジェクト成功のポイント

・悪い情報は次の手を打ちやすくするために、早め、早めに報告する
・コミュニケーションは100％相手に伝わらないことを前提に、確認・合意をする
・メールなのか、会議なのか、どれくらいの頻度で情報交換を行なうかなどのコミュニケーションルールを決める

注１：チーム・マネジメントの回は、こちらからご参照ください。
プロジェクトマネージャーの育成　メンバーのモチベーションを高めてチームを活性化させる「チーム・マネジメント」のあり方（１）

プロジェクトマネージャーの育成　メンバーのモチベーションを高めてチームを活性化させる「チーム・マネジメント」のあり方（２）

*******************

このブログでご紹介したスキル診断が対応しているＩＴスキル標準の職種プロジェクトマネジメントも、このＰＭＢＯＫに対応しています。
以下の記事もご参照ください。

→　「スキル診断の結果より～職種・専門分野ごとのスキル状況（１）～」の記事

次回は、「リスク・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
　お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

プロジェクトマネージャーの育成 クライアントとの言った、言わない問題…… 情報伝達の「コミュニケーション・マネジメント」 （１）

みなさん、こんにちは
（株）富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア（http://ascii.jp/cate/21/）に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、コミュニケーション・マネジメントについてです。

前回の記事はこちら

*******************

ステークホルダーを含むコミュニケーション
　前々回、前回の「チーム・マネジメント」（注１）では、情報の重要性と、正しく情報が伝えられる環境づくりの大切さを解説しました。　しかし、このチーム・マネジメントとは主にメンバー同士やメンバーとプロジェクトマネージャーの間のマネジメントなのですが、今回解説するコミュニケーション・マネジメントは、それ以外のステークホルダーも含むマネジメントです。つまり、プロジェクトに関わるすべての人とのコミュニケーションをマネジメントするものです。チーム・マネジメントができている場合でも、コミュニケーション・マネジメントの欠如によってプロジェクトがうまくいかない場合があります。

　PMBOKガイドにも、コミュニケーション・マネジメントについて「プロジェクトを成功させるために必要とされる人と情報を結びつける重要な役割を果たす」と書いてあります。

コミュニケーション・マネジメントのよくある失敗、メールにおける情報伝達の落とし穴
　ステークホルダー含むすべての人間をマネジメントするコミュニケーション・マネジメントでは、関係者と直接会えないため、その情報伝達方法をメールに依存せざるえない場面も多いでしょう。その際「カーボンコピー（CC）」の機能を使って、関係のある人すべてに同じメールを送ることがよく行なわれるはずです。これは関係者全員に情報を行き渡らせるという意味合いにおいては、効果がある方法と言えます。しかし、行き交うメールがあまりに膨大だと、すべてのメールに詳細に目を通せないということが起こります。それでは、ただ情報を送っただけで、情報を伝えていることにはなりません。

　これはコミュニケーション・マネジメントの欠如と言えます。特にプロジェクトの終盤は、確認する事柄が多くなり情報の量も増え、目を通さなければならない資料やデータが次々にメールに添付されてきます。それに加え、1つ1つの情報の重要度が増すため、重大なトラブルが発生しかねないので注意が必要です。

　また、この伝えるべき情報についでですが、「必要な情報」というのは、受け手のポジションやプロジェクトの進行段階によって異なるという意識を強く持つべきです。たとえば、新しいシステムを導入する場合を考えると、情報の受け手がクライアントの進捗管理担当者なら期日どおりに稼働するか進捗状況が気になるし、予算管理担当者ならコストに関する情報が必要になります。このように情報は受け手によって異なり、さらにプロジェクトの初期段階や終盤など時期によっても異なるので、単一に情報を伝達しても意味がないと考えて下さい。

注１：チーム・マネジメントの回は、こちらからご参照ください。
プロジェクトマネージャーの育成　メンバーのモチベーションを高めてチームを活性化させる「チーム・マネジメント」のあり方（１）

プロジェクトマネージャーの育成　メンバーのモチベーションを高めてチームを活性化させる「チーム・マネジメント」のあり方（２）

*******************

このブログでご紹介したスキル診断が対応しているＩＴスキル標準の職種プロジェクトマネジメントも、このＰＭＢＯＫに対応しています。
以下の記事もご参照ください。

→　「スキル診断の結果より～職種・専門分野ごとのスキル状況（１）～」の記事

次回も引き続き、「コミュニケーション・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
　お気軽にコメントにてお寄せください！

※コメント・トラックバックは、当社確認後表示となります。
　コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
　コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
（株）富士通ラーニングメディアへのリンク

ものづくりの楽しさを、LEGOを使って学ぶ

みなさん、はじめまして

(株）富士通ラーニングメディアの鈴木です。

組込みソフトウェア開発の研修の企画、実施などを担当しています。今回は、「LEGOを使って学んだものづくりの楽しさ」についてご紹介いたします。

LEGOマインドストームとの出会い

私が、LEGOマインドストームを本格的にさわり始めたのは、会社でETロボットコンテストに出場したことがきっかけです。ETロボットコンテストとは、通称「ETロボコン」の名前で親しまれており、組込みソフトウェア技術者の技術力の向上と、交流を目的とした大会です。競技内容は、設計図の良さを競う「モデリング部門」と、ライントレースの速さを競う「タイムトライアル部門」があります。

LEGOマインドストームは、LEGOブロック内にコンピュータを内蔵し、プログラムを転送することで、モーターの制御や、センサーの制御をすることが可能な学習用ロボットです。この「LEGOロボット」を使い、黒いラインを光センサーでトレースして、コースを走ることができます。