『組込み現場の「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レスなどのルールセット と教わった技術者は多いと思う。自分のその１人で、当時「たぶん、これらのルールはソースコードをわかりやすく、読みやすくするためのルールだろう。」とは思ったが、「でも、それを守ったからといって本当に品質が高くなるのだろうか？」という疑問は残った。
松尾谷さんの講義では、この疑問を実際に実験した人がいたそうだ。
同じ仕様を別々の技術者に与え、片方は構造化プログラミング、もう片方はオレ流プログラミングで作らせバグの数を数えてコード品質を比較したという。
結論は「バグの数はどちらもあまり差がない」という結果が出た。
ではダイクストラが提唱した構造化プログラミングは間違いだったのか？ その答えはこうだ。
ダイクストラはソフトウェア開発の現場を調査したところ、他よりも格段に生産性の高いチームが存在した。そのチームの行動規範を調べて、構造化プログラミングが誕生した。
そのチームの行動規範とは以下のようなものである。
- チームのメンバが作ったソースコードのすべてをレビューワ（リーダ）がチェックしていた。
- レビューワのリーダは次から次へと上がってくる、何のルールもないバラバラなソースコードに対してレビューに時間がかかり効率のよいレビューができていなかった。
- そこで、リーダは自分のこれまでの経験や過去の失敗をベースにコーディングスタイルを定め、チームのメンバにその設計規範に基づいてコードを作成することを指示した。
- すると、リーダのレビュー効率は格段に高くなり、かつ設計規範がチームに浸透することによりバグが減って生産効率も上がっていった。
実はこの構造化プログラミングが誕生した背景が後々正確に伝わらずに、gotoレスなどのルールだけが一人歩きしたため、構造化プログラミングはコードレビューしてこそ有効性が得られるという規範が世の中に浸透しなかった。
構造化プログラミングのルールがレビューするための設計規範だと考えれば、一行は80文字に規定したのは当時の標準のディスプレイの横文字の最大が80文字であり、折り返すと見にくいからであり、一つの関数の行数を50行以下にするというルールはソースコードを印刷したときに一つの関数が複数のページにまたがっているとレビューしにくいからそうなっているのだということがわかる。
構造化プログラミングのプラクティスの根拠が理解できていれば、現在の高解像度のディスプレイであれば必ずしも1行を80文字に制限する必要はないことが分かるし、ソースコードを印刷せずにデバッグするのなら絶対に関数の行数を50に制限しなければいけないということではないことがわかる。
極端にいえば、作成したプログラムをコードレビューしないのなら、構造化プログラミングの効果は大して高くないということだ。リーダが設計の規範をメンバに示し、メンバが作成したアウトプットをレビューして、プロジェクトの成果物を設計の規範に近づけることが、生産性を向上させ品質を高める。
学校のソフトウェアの授業で教えて欲しいのはこのことだ。
組込みソフトの世界でオレ流プログラミングを野放しにするようなプログラマ至上主義では品質を確保することは難しいと思う。プロジェクトの規模が大きくなればなるほど、ソフトウェアプロジェクトのチームリーダが設計の規範をメンバに示し、浸透させる必要がある。
『組込み現場の「C」プログラミング―基礎からわかる徹底入門』は、ソフトウェア規模が拡大した現代の「組込みソフトの設計規範」であると言える。
本の中にはかなり多くの規範が書いてあるから、プロジェクトリーダは自分のこれまでの経験を照らし合わせながら、これは伝えておくべきだというところをピックアップしてプロジェクトの設計規範とし、メンバに浸透させるとよいだろう。
もしも、プロジェクトの中に設計の規範を示してくれるようなリーダがいないのなら、この本を師匠だと思って自分自身の成果物が設計の規範にどれくらい適合しているかどうかをセルフレビューするとよい。
日本の組織では数字が一人歩きしやすい。厳しい数値目標を設定してクリアできると、その数値目標を設定した背景が継承されずに、数値目標だけが一人歩きする。
これを防ぐためには、「なぜ、その目標が設定されたのか？」「目標をクリアするとどんな効果があるのか？」「前提条件は何か？」「目標をクリアする目的は何なのか？」をいつ何時でもすぐに答えられるようにしておくことが大事だ。
その問いに答えられないリーダは設計の規範をメンバに示す資格がない。
ただ、残念ながらそのような設計の規範を示すことのできるリーダはそんなにたくさんいないので、学校で学生に設計の規範をたたき込んで欲しいのだ。
学校の先生に『組込み現場の「C」プログラミング―基礎からわかる徹底入門』を教科書にして欲しいとお願いしたいのはそんな背景からである。設計の規範を理解して実践し、効果を肌身で感じたことのある技術者はリーダになったときに説得力を持ってメンバに規範を訴えることができる。
子供にしつけが大事なように、チームで品質の高いコードを効率よくアウトプットするには、組込みソフトエンジニアには設計の規範が必要なのである。
0 件のコメント:
コメントを投稿