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

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

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

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

キーワードの 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

ルールを決める権利を放棄する日本人

子供の頃、民主主義とは多数決で物事を決めることだと思っていた。ホームルームの時間に何か決めごとがあると、まず、議長がみんなから意見を聞き意見がが出尽くしたところで多数決を取る。

昔を振り返ると、学校のホームルームでは議論が発熱することはあまりなく、意見を言う生徒も大抵は決まっていた。いつも自分の意見を言わない者もいた。たまに自分が議長になったときなど、なかなか意見がでない状況で誰かを指名して無理矢理意見を言わせるのがイヤでしようがなかった。

「なぜ、最初から多数決を取らないのだろう」と思ったものだ。

ところが最近になって、そうは思わなくなった。何で物事を決める際に議論をしつくさなければいけないのか何となく分かってきたような気がする。

例えば、組込みソフト開発において、プロジェクト内でコーディングルール・コーティングスタイルを決めるというシチュエーションを例に取って考えてみよう。

自分の経験ではプロジェクトに「コーディングルールを決めてください」とお願いすると、サッとできてくるチームとコーディングルール・コーディングスタイルを提示してあげなければいつまでたっても出来てこないチームの二通りがある。

ちなみにサッとできているチームも、必ずしもプロジェクト内で十分にディスカッションしているとは限らない。率先してコーディングルール・コーディングスタイルはこうあるべきと主張する一人のエンジニアの考えを丸呑みしてしまっていることも多い。

これは、ホームルームの時間に議長が意見を求めても、一部の人しか発言しない状況とよく似ている。発言してその案が採用されたときに言い出しっぺとして「自分自身に責任が降りかかってくるのではないか」という恐怖心があるのではないだろうか。

民主主義で物事を決めるということは、参加者が自分の意見を発言するという権利を行使してディスカッションの場に提示し、自分の意見の正当性を主張し、意見が一つにまとまらなかったら多数決で決定するということだと思う。

なぜ、少数意見も含めて議論をし尽くしてから多数決を取らなければいけないかと言えば、議長は会議の参加者が自分の意見を発言するという権利を出来る限り平等に行使できるように気を配らなければいけないからだ。

ようするに少数意見であっても発言させないのはアンフェア－だから、議論をし尽くさないで多数決を取ってはいけないのだ。

でも日本人は「さあ、発言してください」と会議で口火を切ると大抵の場合黙っている。黙っているということは発言できる権利を放棄しているということになる。

発言の権利を放棄してしまったということは、無条件に決めごとに従うと宣言したようなものだ。日本人はこの権利を放棄しているという感覚が分かっていない。

例えば、自分たちでコーディングルールやコーディングスタイルを決められないチームに、ベースとなるコーディングルールやコーディングスタイルを提示すると、いったんはそれに従おうとするが、しばらくしてルールに逸脱する者が現れても、それを注意したり、自分たちで是正しようとしない。ルールからの逸脱を外部の誰かから指摘されない限り、是正しようとしない。

これは日本人の気質だと言ってしまえばひと言で終わってしまうが、民主主義を自分たちで勝ち取った権利であると考える人たちからみればルールを自分たちで決める権利を放棄したのに、指定されたルールに従わない実にアンフェア－な人々に見えるに違いない。

自分たちでルールを決めることに消極的な組織はルールに振り回される傾向がある。ルールを決める際に議論に参加していないため、「そのルールがなぜ決まったのか」、「どうしてそうしなければいけないのか」についての思慮が足りない。だから、ルールを守る方も守らせる方も重箱の隅をつつき合ってはちょっとした逸脱について過敏に反応したりする。

ISO9001の外部監査、内部監査などで是正を食らわないことだけを争点に水掛け論をしている光景を目にすると、品質マネジメントシステムがキチンと機能しているかどうかを確認していることを忘れているのではないかと感じる。

原理原則を理解せずにルールに振り回されている日本の技術者は大勢いいる。このような技術者は他人にバグを見つけてもらっても「ありがとう」とは言わないし思わない。

『アメリカ人と日本人』の記事で書いたように、日本人は「あたたかい人間関係の中のやさしい一員」としてものづくりに有利な面を持っていると思う。しかし、「創造性と個性にあふれた強い個人」の人たちとも一緒に仕事をしなければいけないし、「創造性と個性にあふれた強い個人」が作ったルールに従わなければいけない場面も多々ある。

【よくある日本のプロジェクト】
・ルールを自分で決められない（ルールを決める権利を放棄してしまう）
・ルールからの逸脱を是正することができない（自制できない）

なぜ、これがいけないのかといえば、ルールを自分で決められず、ルールからの逸脱を是正することができないプロジェクトや組織は品質の高いソフトウェアをアウトプットできない可能性が高いからだ。30万行を超えるような規模のソフトウェア開発では特にそう思う。

ルールがあっても形骸化する組織やプロジェクトはルールの作成時の議論に積極的参加していない（権利を行使していない）か、ルールの本質を理解していないからだ。

そう考えるとすでに存在するルールをプロジェクトに適用する際には、最初にその本質も含めてプロジェクトに対して最初にキチンと説明してから適用しないとフェアーではないということになる。開発の途中からルールへの遵守を求められたら、それはフェアーではないと主張しなければいけない。

組織はプロジェクトに対してルールを理解させるトレーニングを提供する義務がある。そして、いったんルールの意味を理解したのならば、対象者に資格を与えルールからの逸脱を監視して、場合によっては資格を剥奪しなければならない。

こういうまどろっこしいことを一切省略して、プログラマーの能力を最大限に引き出し、ソフトウェアシステムの完成度を高めるという開発手法もある。優秀なエンジニアの集団にルールを押しつけるよりも、このような方法でプロジェクトのパフォーマンスを上げる方を優先させた方が結果的に品質が上がる場合もある。

しかし、このような技術者個人に依存するやり方では組織は常に一定の水準のソフトウェア品質を担保できるとはいえないし、その組織が品質の高いソフトウェアをアウトプットできることを内外に示すことができない。ルールやプロセスやプロセス内で実施する活動を規定せずにソフトウェア品質を高めるしくみがないとダメだ。でも、人間がキーボードをたたきながらソフトウェアを作っている限り、そんな都合のいい方法はないだろう。

日本人もルールに正面から向き合うくせをつけて、ルールを自分たちで決める権利についてよく考え、頭の中で権利と義務と責任について常日頃整理しておかないと、グローバルマーケットでものづくりはできないと思う。
　

エレキの分かる組込みソフトエンジニアの育て方

今回は、まっさらな新人が入ってきて組込みソフトエンジニアとして育てたいとき、どんな学習方法を取り入れるとよいかという提案をしてみたい。

ちなみに、ここで紹介する方法はたぶんデジタル系の電気系技術者の教育にも使えると思う。

【前提条件】

・複数人の新人を教育する場合に有効。（できれば4人以上がよい。チームを2つ以上作れるので）
・3ヶ月以上は現場から隔離できることが望ましい。（集中して課題に取り組んでもらいたいから）
・プログラミングの経験は必要なし。・電気回路設計の経験も必要なし。
・Word や Excel や PowerPoint 、インターネットブラウザでの検索等は使えること。

【教材】

1. CPUの創りかた











2. 電子回路シミュレータ TINA7(日本語・Book版)で見てわかる デジタル回路の「しくみ」と「基本」










3. 電子回路シミュレータ TINA7（日本語・Book版2）で見てわかる 電子回路の「しくみ」と「基本」

※純粋にソフトウェアしかやらないのなら3は省いてもよい。








【ねらい】

「CPUの創りかた」は秋葉原で買えるロジックデバイスを組み合わせて CPU を自分で作ってしまおうという本だ。イラストはちょっと怪しいが中身はいたってまじめであり非常にていねいに解説してあるので、本に書いてあるように進めていけばシンプルなCPUを自作することができる。

何をするにもはじめに原点を追求しておくのはよいことだ。CPUをディスクリートで自作し、実際にプログラムコードの読み出しやアキュームレータの動きをテスターやオシロスコープを使いながら確かめることは、組込みソフトウェアエンジニアにとっても、デジタル回路設計技術者にとっても貴重な経験となるはずだ。

次に、電子回路シミュレータ TINA7 は実機がなくても、回路を書いてその動きをシミュレーションすることができる。回路に電源を供給して回路上の不特定の端子ポイントをバーチャルオシロスコープで観察することもできる。東京電機大学高等学校教諭の小峯龍男先生は、このTINA7を使った学習本の中で、「ひとつだけ残念に思うことは、TINAでは回路の組み立てに失敗しても、コンデンサをパンクさせたり、抵抗器の被覆焼け焦げたり、ICのパッケージが火傷するほど熱くなるという経験をできないことです。」と書いているが、『CPUの創りかた』で実際にCPUを作ってしまうことで、その欠点を補おうというのが今回の作戦となる。

電子回路シミュレータ TINA7(日本語・Book版)には、機能限定で TINA7のCDがついているので安価に学習ができる。

3つの本を使って、各チームにそれぞれCPUボードを作るという目標を達成させる。（Project Based Learning）

教育とマネージメントする側はPCの用意などインフラの整備、最低限のルールの規定、ポイントポイントで進捗をチェックする以外は基本的にチームに運営を任せる。

スケジューリング、材料リストの作成、道具の購入、予算管理、材料収集、回路シミュレーション、一次試作、製品制作をすべてチームに任せることで、製品開発工程のミニチュア版を体験させる。（本番と比べると商品企画と自分たちで考える回路設計だけが欠けている）

【学習方法】

まず、新人を複数のチームに分けて、各チームのリーダを決めておく。いい加減に決めるのではなく、できるだけ人物をよく観察して適性がありそうな者を指名しておく。

次に、PCやインターネットなどのインフラを使えるようにして、プロジェクトの主旨を説明し、まずは『デジタル回路の「しくみ」と「基本」』を頭から読んで、回路シミュレーションをやらせてみる。

しばらくしたら、CPUを作るための簡単な工程の説明をして、スケジューリングをさせる。（スケジューリングするためのツールとしては、GanttProject などのフリーツールを指定してもよい）

毎週一回週末に各チームの代表1人に10分間で、その週に学んだこと次週の予定などをプレゼンさせる。（週報プレゼン）　また、月末には30分のプレゼンをさせる。（月報プレゼン）

【CPU制作プロジェクト】

CPU制作は、『CPUの創りかた』に書いてあるとおりにやれば出来るはずだが以下の点を考慮するとよい。

【材料収集と予算管理】

• 必要な材料と道具のリストを作らせ、大まかな価格をインターネットで調べさせる。
• 部品の購入方法について検討させる。（首都圏なら秋葉原で購入する）
• 部品は一台ぶんではなく、一次試作ぶんと製品ぶんの2セット以上を購入させる。
• 予想価格と実際に購入した価格の差を明確にさせる。

この後の工程の注意については、また今度本ブログで紹介したいと思う。
　
【この学習方法の良いところ】

• 管理者サイドの工数がほとんどかからない。
• チームが複数あるとそれぞれの様子を見て、良い点を取り入れようとする。
• 週報プレゼン、月報プレゼンをさせることで学習の進度や進捗が分かる。
• 製品の開発工程を体験させることができるので、現場に出たとき何かと役に立つ。
• CPUの動きの原点を学習できる。
• 早い段階で回路デバッグを経験させることができる。
• 一発では完成度の高い製品レベルの制作は難しいことが分かる。
• 教材費が安い（本3冊で1万円以内。CPU制作費はたぶん数万円）
• 新人は最初とてもまじめなので黙々と学習に取り組み学習効率がよい。
• まだ現場の仕事をしていないため割り込みの仕事がほとんどなく集中できる。
  

とてもよい教材本を作成してくれた『CPUの創りかた』の著者 渡波 郁氏と『電子回路シミュレータ TINA7(日本語・Book版)で見てわかる デジタル回路の「しくみ」と「基本」』『電子回路シミュレータ TINA7（日本語・Book版2）で見てわかる 電子回路の「しくみ」と「基本」』の著者 小峯 龍男先生に感謝したい。

ぜひ、お試しあれ。