組込みソフトエンジニアが読むといいデジタル回路の本

久々に「この本は買いだ！」という本に出会った。

それは、『デジタル回路の「しくみ」と「基本」』という本だ。

組込みソフトエンジニアで電気設計担当の技術者と仕事で話をする機会がある技術者はこの本を買って最後まで読むと、彼らの言っていることが「ああ、なるほどそういうことだったのか」と分かるようになる。

また、組込みソフトプロジェクトのマネージャやリーダーで「こいつはハード寄りのことがわかってないなあ」と思う部下がいたら、この本を買って渡してやるといい。2500円なら間違いなくお買い得だと言える。

この本には、電子回路シミュレータ TINA7　日本語版の評価版が付属で付いてくる。この電子回路シミュレータが優れもので、いろんな回路を作れる上に、回路上のポイントにプローブを当ててオシロスコープで波形を眺めたり、3次元で部品類を眺めることができる。

著者は東京電機大学高等学校教諭の小峯龍男さんで、非常に丁寧に電気回路の初心者がゼロから学べるような構成で基本となることを一つずつ丁寧に解説してくれている。

例題の回路もすべて同梱されおり、最終例題として小さな CPU、電卓を作ってみるというゴールが設定されている。 『CPUの創りかた』 も良い本だと思ったが、『デジタル回路の「しくみ」と「基本」』はPC上のシミュレーションで電子回路を基礎から学ぶことができるところが良いところ。

例によって例のごとくはじめにの文章を紹介しようと思う。

【デジタル回路の「しくみ」と「基本」はじめにより引用】

　私がはじめて使った電子回路シミュレータソフトは、DOS（ドス）ベースのモノクロGUI（グラフィック・ユーザ・インタフェース）でした。それでも、シミュレーションした回路をワンチップマイコンへ転送して、実物のLED（発行ダイオード）や小型モータを制御できたときに感激は、オシロスコープ（波形観測器）で初めて期待する波形を出したときの感動と同様に今でも鮮明です。

　ここに「TINＡ」という素晴らしいシミュレータソフトがあります。我流でICをいじり始めた私からすると、何と便利なソフトかと思います。ひとつだけ残念に思うことは、TINAでは回路の組み立てに失敗しても、コンデンサをパンクさせたり、抵抗器の被覆焼け焦げたり、ICのパッケージが火傷するほど熱くなるという経験をできないことです。

　バーチャル体験を否定するわけではありませんが、工作少年だった私としては、指先のキーボード操作を学習するだけではなく、いつかは実際に本物の回路を作ってみて、実際の質感とはんだの溶ける臭いを経験することが大切だと今でも信じています。

　本書は、私自身のICとの付き合い方を思い出しながら執筆しました。それは、初めに動かしたいものがある。こうすれば動く、それは何故なのか。という教科書とは逆順の手法です。
　題材もゲーム感覚の回路を揃えました。何よりも目の前のパソコンが実験室に変わってしまうのですから、よくある教科書と違って最後まで絶対に飽きません。

　これからデジタルICの勉強を始めようとする方は、本書でイメージをつかんだら、いつかは基板の上に実際の回路を作ってみてください。また、すでに回路の実験を経験していて、本書でシミュレータソフトの挑戦する方は、パソコンの中で動く回路と測定器に新鮮な驚きを感じてください。

【引用終わり】

「はじめに」を見ただけで、この本の良さがいろいろ分かる。たとえば、DOSを（ドス）とふりがなをふり、GUIを（グラフィック・ユーザ・インタフェース）、LEDを（発行ダイオード）、オシロスコープを（波形観測器）と説明している。これだけ見ても小峯先生は小学生や中学生がこの本を読むことを想定していることがうかがえる。

中学生でも分かるように丁寧に書いているのだから、電子回路をまったくさわったことない組込みソフトエンジニアでも、電子回路の基礎が学ぶことができ、最後は簡易電卓が電子回路でどのように動いているのか理解できる。

また、小峯先生が書いている「回路の組み立てに失敗しても、コンデンサをパンクさせたり、抵抗器の被覆焼け焦げたり、ICのパッケージが火傷するほど熱くなるという経験をできないことが残念」というコメントも同感だ。「初めに動かしたいものがある。こうすれば動く、それは何故なのか。という教科書とは逆順の手法」というのも、自分の「具体から抽象へ」のポリシーとぴったり一致する。

電源のプラスマイナスを逆に接続し回路を壊してしまったり、コンデンサを「パン！」と鳴らしてしまったりする経験をすることが、ものづくりの実感につながる。

小峯先生のような方の下で勉強できる高校生は幸せだと思う。でも、この本を最初から最後まで通していろいろな回路を実験してみることで、小峯先生の授業を受けたことと同じ体験をすることができるだろう。

付属しているTINAも非常にすぐれたシミュレータで、印刷できないなどの制限はあるものの、この本にある例題を一通り体験できることから、電子回路の基礎を学ぶための道具としては、この上ないツールである。

この本をマスターした部下が「自分はデジタル回路のおもしろさに目覚めました。ハード屋さんに転向させてください。」なんて言い出しても僕を恨まないでね。
　

組込みソフトの品質を高めるには設計の規範が必要

『組込み現場の「C」プログラミング―基礎からわかる徹底入門』という本が技術評論社から出版された。著者は SESSAME（組込みソフトウェア管理者・技術者育成研究会）となっており、過去に開催されたSESSAMEのセミナーコンテンツをベースにして、三浦元さんと、坂本直史さんがまとめ上げた。実質的には三浦さんと坂本さんの努力の結晶と言えるだろう。

この本は、組込み現場で使う Cプログラミングの設計の規範が山のように詰まっている。中身が盛りだくさんなのでまずは、「はじめに」の中身を読んで欲しい。

【『組込み現場の「C」プログラミング』はじめにより引用】

はじめに

　本書では、すでにC言語の文法を学習した方を対象に、C言語による組込みプログラミングで品質を上げるために知るべきこと、意識すべきこと、実行していただきたいことを解説しています。

　ソフトウェアを作文にたとえると、プログラミング言語は「あいうえお」や「てにをはの使い方」に相当するでしょう。仕事でプログラムを書くということは売り物の文章を書く、いわば作家になるということです。プログラミング言語を覚えないと文章（プログラム）は書けませんが、覚えたからといってすぐに世の中に通用する文章が書けるとはかぎりません。

　作文では、なにについて書くか、テーマを明確にし、次にテーマを有効に伝えるための文章構造を設計することになります。まず、対象をよく知ることはもちろんですが、そうであっても、思い付くまま書きなぐった文章と、構造のしっかりしている文章との差は歴然です。もちろん、構造だけではなく、文章そのものの洗練も重要でしょう。また、文章では、推敲がとても重要です。書きっぱなしではなく見直すということですね。さて、これが学校の作文だったらまだしも、人様に読んでいただく小説を数人で分担して執筆するのだったらどうでしょう？読ませるだけのプロットであることはもちろんですが、読み進めるについて文体が変わったり、登場人物の名前がいつのまにか変わったりしていたら興ざめどころではありませんよね。

　プログラムを書く、という作業も同じです。特に最近は、1人だけでプログラムを書くことはほとんどないと思います。組込み製品によっては1000人規模の技術者がソフトウェアを作り上げる作業にかかわります。

　文章を書くたとえで説明しましたが、ソフトウェアについての設計技術、プログラムをわかりやすく表現する技術、見直し確認の重要性をおわかりいただけるかと思います。

　本書では、冒頭に述べたように、C言語の基本を知っている方を対象としていますので、「あいうえお」、「てにおは」に該当するC言語の文法は扱いません。そうではなく、「良い文章（プログラム）とはどのような文章なのか」、「物書き（プログラマー）としてどのようなことを知っておくべきなのか」ということ、具体的には組込みソフトウェアのプログラミング、そして、プログラミング前後の工程、つまり、モジュール分割からモジュール結合テストまでを主に扱います。本書を読むことで、組込みC言語プログラミングの特徴はなにか、どのような落とし穴があるのか、プログラムの品質によってどのようなことがポイントなのかをご理解いただけるように意図しました。

【引用終わり】

この本は組込みソフトウェアを設計する際の設計の規範の集大成である。もしも大学の先生が教えることができるのなら、この本に書いてある「設計の規範」を学生に教えて欲しい。

この「設計の規範」は先人達の長年の成功体験、失敗の再発防止策を、組込みソフトというくくりにおいて一般化したものだ。

だから、実際に組込みソフトを作る経験をしたことがないとピンとこないこともあるかもしれないが、言語の使い方を教えるだけのC言語の授業にはない貴重な規範がそこにはある。

品質の高いソフトウェアを作成するために初級のソフトウェア技術者に心がけて欲しいのは、設計の規範を理解し、その規範に沿って設計できるかどうかである。

どんなに、プログラミングテクニックに詳しくてもダメだ。設計の規範を考えずにプログラミングしている個人やプロジェクトが作ったプログラムは品質が高いことを担保できないし、危なくて再利用できない。

製品リリース後にリコールで悩まされたり、再利用を促進して開発効率を高めたいのなら、新人の技術者には「設計の規範」をたたき込んで、「なぜ、設計の規範が必要なのか」を理解させることが絶対に必要だ。

さて、構造化プログラミングということばを聞いたことのある人は多いだろう。PMAJ IT-SIG 特別講義「パートナー満足(PS)とチームビルディング」を聞いたとき、デバッグ工学研究所の松尾谷徹さんが、この構造化プログラミングのルーツについて目から鱗が落ちる話をしていた。

この松尾谷さんの話をいろいろなところで披露すると、いつもみんな「なるほど！」と納得する。

構造化プログラミングを提唱したのは オランダ人の Edsger Wybe Dijkstra（ダイクストラ）で、ダイクストラは1930年ロッテルダムで生まれた。ダイクストラはセマフォ排他制御方式の他に、スタック、ベクトル、Algo60 のコンパイラなどを考え出した物理学、数学を専攻した著名なコンピュータ科学の教授だった。

構造化プログラミングのプラクティスで有名なのは、goto を使ってはいけないとか、プログラムの一行は80文字以内、一つの関数は50行以内にしようなどというルールだ。

構造化プログラミング＝gotoレスなどのルールセット と教わった技術者は多いと思う。自分のその１人で、当時「たぶん、これらのルールはソースコードをわかりやすく、読みやすくするためのルールだろう。」とは思ったが、「でも、それを守ったからといって本当に品質が高くなるのだろうか？」という疑問は残った。

松尾谷さんの講義では、この疑問を実際に実験した人がいたそうだ。

同じ仕様を別々の技術者に与え、片方は構造化プログラミング、もう片方はオレ流プログラミングで作らせバグの数を数えてコード品質を比較したという。

結論は「バグの数はどちらもあまり差がない」という結果が出た。

ではダイクストラが提唱した構造化プログラミングは間違いだったのか？　その答えはこうだ。

ダイクストラはソフトウェア開発の現場を調査したところ、他よりも格段に生産性の高いチームが存在した。そのチームの行動規範を調べて、構造化プログラミングが誕生した。

そのチームの行動規範とは以下のようなものである。

1. チームのメンバが作ったソースコードのすべてをレビューワ（リーダ）がチェックしていた。
2. レビューワのリーダは次から次へと上がってくる、何のルールもないバラバラなソースコードに対してレビューに時間がかかり効率のよいレビューができていなかった。
3. そこで、リーダは自分のこれまでの経験や過去の失敗をベースにコーディングスタイルを定め、チームのメンバにその設計規範に基づいてコードを作成することを指示した。
4. すると、リーダのレビュー効率は格段に高くなり、かつ設計規範がチームに浸透することによりバグが減って生産効率も上がっていった。
   

さて、ここで注目すべき点は、レビューワであるリーダがチームメンバのコードをすべてレビューしており、リーダが自分の経験を基に作成した設計の規範を示していたという点である。

実はこの構造化プログラミングが誕生した背景が後々正確に伝わらずに、gotoレスなどのルールだけが一人歩きしたため、構造化プログラミングはコードレビューしてこそ有効性が得られるという規範が世の中に浸透しなかった。

構造化プログラミングのルールがレビューするための設計規範だと考えれば、一行は80文字に規定したのは当時の標準のディスプレイの横文字の最大が80文字であり、折り返すと見にくいからであり、一つの関数の行数を50行以下にするというルールはソースコードを印刷したときに一つの関数が複数のページにまたがっているとレビューしにくいからそうなっているのだということがわかる。

構造化プログラミングのプラクティスの根拠が理解できていれば、現在の高解像度のディスプレイであれば必ずしも1行を80文字に制限する必要はないことが分かるし、ソースコードを印刷せずにデバッグするのなら絶対に関数の行数を50に制限しなければいけないということではないことがわかる。

極端にいえば、作成したプログラムをコードレビューしないのなら、構造化プログラミングの効果は大して高くないということだ。リーダが設計の規範をメンバに示し、メンバが作成したアウトプットをレビューして、プロジェクトの成果物を設計の規範に近づけることが、生産性を向上させ品質を高める。

学校のソフトウェアの授業で教えて欲しいのはこのことだ。

組込みソフトの世界でオレ流プログラミングを野放しにするようなプログラマ至上主義では品質を確保することは難しいと思う。プロジェクトの規模が大きくなればなるほど、ソフトウェアプロジェクトのチームリーダが設計の規範をメンバに示し、浸透させる必要がある。

『組込み現場の「C」プログラミング―基礎からわかる徹底入門』は、ソフトウェア規模が拡大した現代の「組込みソフトの設計規範」であると言える。

本の中にはかなり多くの規範が書いてあるから、プロジェクトリーダは自分のこれまでの経験を照らし合わせながら、これは伝えておくべきだというところをピックアップしてプロジェクトの設計規範とし、メンバに浸透させるとよいだろう。

もしも、プロジェクトの中に設計の規範を示してくれるようなリーダがいないのなら、この本を師匠だと思って自分自身の成果物が設計の規範にどれくらい適合しているかどうかをセルフレビューするとよい。

日本の組織では数字が一人歩きしやすい。厳しい数値目標を設定してクリアできると、その数値目標を設定した背景が継承されずに、数値目標だけが一人歩きする。

これを防ぐためには、「なぜ、その目標が設定されたのか？」「目標をクリアするとどんな効果があるのか？」「前提条件は何か？」「目標をクリアする目的は何なのか？」をいつ何時でもすぐに答えられるようにしておくことが大事だ。

その問いに答えられないリーダは設計の規範をメンバに示す資格がない。

ただ、残念ながらそのような設計の規範を示すことのできるリーダはそんなにたくさんいないので、学校で学生に設計の規範をたたき込んで欲しいのだ。

学校の先生に『組込み現場の「C」プログラミング―基礎からわかる徹底入門』を教科書にして欲しいとお願いしたいのはそんな背景からである。設計の規範を理解して実践し、効果を肌身で感じたことのある技術者はリーダになったときに説得力を持ってメンバに規範を訴えることができる。

子供にしつけが大事なように、チームで品質の高いコードを効率よくアウトプットするには、組込みソフトエンジニアには設計の規範が必要なのである。
　

ついに来たプロジェクトマネジメントを外部発注する時代

日経ビジネス 2007年4月2日号の特集記事 “抜け殻”正社員－派遣・請負依存経営のツケ－を読んで、ついにここまで来たかと思った。

最近、システム業界では「プロジェクトマネジメント専門会社」が相次いで設立され、派遣人材の管理やスケジュール管理など本来は元請けが担うべき役割を彼らに代行してもらっているというのだ。

プロジェクトが頓挫しそうになると大手の元請けが次々と「プロジェクトマネジメント専門会社」に助けを求めて駆け込んでくるという。

正社員の技術力が空洞化し、プロジェクトマネジメントも外部にやってもらう。そうなると社員は何をやるのだろう。

日経ビジネスの記事では、大きな企業の本社で働く大卒正社員は「業務改革推進室」「顧客満足度向上委員会」「ISO取得準備室」「環境対策委員会」など次から次へとできる新しい組織に回され、「ああしろ、こうしろ」と、どんどん現場にボールを投げるばかりでピッチャーばかりになってしまったとある。

1995年から2005年の10年間に、日本の正社員は405万人減り、請負、派遣などの非正社員が642万人増えたそうだ。この結果、企業は人件費が圧縮され、社会保険や退職金・年金の負担も減り、大したヒット商品もないのに過去最高益を更新する会社が続出した。

当然、企業活動の最前線を非正社員に任せっぱなしにしたのでは、抜け殻化してしまうが、そう分かっていても、一度その“うまみ”を知ってしまうと、やめられなくなるのが請負・派遣依存症の怖さだと記事に書かれている。

組込み業界は、前述のシステム業界のようにプロジェクトマネジメントを外部に委託するところまではいっていないと思うが、このままソフトウェアの規模、プロジェクトの規模が拡大し続けるとシステム業界と同じようになるかもしれない。コアな技術が何かを見極めないまま、協力会社にソフトウェア開発のほとんどを依存し、メーカーの技術が空洞化していることは実感として感じるが、プロジェクトマネジメントまでも外部に委託してしまうと、いったい正社員は何をするのだろう。

組込みの場合、業務ドメインに特化した知識というのは、それなりにたくさんあるので、それらの知識を知っているだけでできることだけが正社員の仕事になってしまう。

このような技術者はその業務ドメインに長くいることだけがアドバンテージとなり、ソフトウェア工学の技術やプロジェクトマネジメントのスキルもない。そんなことは自分たちもうすうす気づいているので、何とかその組織にしがみつこうとする。いろいろ不満や愚痴を言っていても、技術やスキルに自信がなく、その業務ドメインの知識だけがアドバンテージであることが本能的に分かっているので自ら組織を去ろうとはしない。

でも、そんな技術のあるものが評価されずに、業務ドメインの知識だけを持っているものが評価されるような状態は長くは続かない。

メーカーでもサプライヤーでも請負でもなんでもいい。技術を持って、成果を上げることができるエンジニアが高く評価されるべきであり、まともな競争社会である限りその方向に近づいていくはずである。

貧しい時代「教育は人を裏切らない」といい、貧しくても教育だけはきちんと受けさせたいと考えた親がいたように、「技術の修得はエンジニアを裏切らない」と信じたい。