ちなみに、この本は韓国語版では『品質を考えている組込みソフトウェアの設計』というタイトルになっていることに初めて気がついた。
ハングルはまったく読めないのだが、Google のお陰でちょっとでもヒントがあれば目的の情報に到達することができる。Google Chrome なら他言語で書かれたページも母国語に翻訳できる。これはすごい技術革新だと思う。意味が完全に通らないところもあるが、これまでならまったくあきらめていたハングルのページも読めるようになった。
言語の壁を少しでも下げてくれたことはとてもありがたい。知らぬ間に世界は広がったのだ。Google に感謝しよう。
さて韓国人のjhrogueさんの書評を少し引用させてもらおう。『読書好き:品質を考えている組込みソフトウェアの設計』(たまたま、jhrogueさんが使っているのもこのブログサイトと同じ blogger だ)
※Goggle 翻訳なので日本語の表現が少し変かもしれないがそこはご愛敬。([鈎括弧]は注釈)
ドングリ出版社[今回韓国語版の本書を出版してくれた韓国の出版社]からの技術書籍をたくさん受けたので義務感(うん?)半好奇心半分で読破し始めた。その結果、今日は久しぶりに埋め込まれた書籍を紹介しようと思う。1番打者はまさに "品質を考えている組込みソフトウェア設計"だ。この本は、従来のハードウェア大国である日本で出てきたソフトウェアを優先的にアクセスするアメリカン組み込み本とは異なり、国内情緒にもよく合致するという利点があるので、用語などがちょっと日本な点を除いては(むしろ電子側アクセスする場合利点になるかもしれない)国内書読んで感じを受けるかもしれない。
この本を面白く読むにはこの本の最終的な目標を知っている必要がありますが、原書のタイトルが "組込みソフトウェアエンジニアを極める"ということが重要なヒントを提供する(個人的には、原書のタイトルが胸に届く)。この本は、組込みソフトウェアの分野でプロフェッショナルなエンジニアになるための長い道のりを説明している。序文で提示した "組込みエンジニアの上手になるためのロードマップ"を見ると、大きく組込みソフトウェアエンジニア個人としての目標と組込みソフトウェアプロジェクトとしての目標という二つの大分類に分けて、それぞれの障害物/壁を説明し、これを超える方法を鳥瞰している。次の図を見ると、もっと理解が容易である。
組み込み関連書籍を執筆してみたB級プログラマの観点から見ると、この本は、組込み開発の過程で直面する難しさを非常によく取って出して体系的に整理したという考えである(率直にたくさん驚いた)。もちろん、オブジェクト指向設計手法を適用する過程で(組み込み分野に入るマトチュリョダてみると)少しぎこちない部分が出たりしかし大勢には大きな支障はない。何よりも抽象的な話ではなく、現場で接して見たらそうな例で話を解いていく方法を使用しているので理解するのが容易だ。一例として、1部と2部では、感熱式プリンタに印刷するケースが徐々に発展され展開される、組み込み分野でのリアルタイムの重要性をよく表している例なので、ファームウェアを開発やっ組み込み開発者であれば十分に共感して読むことができるだろう。また、多少流れる雲とるような再利用と品質関連の既存の理論を組み込みに合わせて減らし変更して実践可能な形で一目瞭然に提示した3章と4章でも、いくつかの良い例が出てくるのでかゆい部分を掻き与える。
[日本の初版本に掲載したイラスト]
結論:初中級組込み開発者であれば1部と2部を読んで技術的な知識を習得することができ、中高級組込み開発者であれば3部と4部を読んで開発文化を忠実に固めることができる。久しぶりに出てきた楽しみながら有益な組込み開発の書籍なので強くお勧めします。jhrogueさん、書評をありがとうございます。
さて、この書評の中で「この本は、従来のハードウェア大国である日本で出てきた本で、ソフトウェアを優先的にアクセスするアメリカの組み込み本とは異なり、韓国の国内事情にもよく合致するという利点がある」(一部意訳)というところが一番うれしかった。
自分は組込みソフトウェアの品質を高める、組込み機器の価値を高めるために欧米発のプロセスアプローチを使うことを完全否定している訳ではない。
ソフトウェアシステムはソフトウェアエンジニアの日々の積み重ねの成果だから、エンジニアの性格やプロジェクトの習慣や、その国の文化がソフトウェアの品質に大きな影響を与える。
だから、欧米で上手くいくプロセスアプローチがアジアのエンジニアにも有効だとは限らない。しかも、日本の組込み機器の品質は世界一だと言われているのに、なぜ日本のソフトウェアの品質が高いのか答えを追求せず、欧米のアプローチをそのまま受け入れようとする人達が大勢いることに自分は納得がいかない。(自分達の作品に自信がないのだろうか?)
なお、アメリカだってプロセスアプローチだけがよいと言われているわけではない。次のような本を読めばソフトウェア開発にはプロセスアプローチとは別の重要な視点があることに気がつくはずだ。
また、Agile プロセスは『リアルタイムOSから出発して組込みソフトエンジニアを極める』で紹介しているボトムアップのアプローチに近いかも知れない。
日本人はどうして欧米で開発されたソフトウェアの方法論が優れていると疑いもせずに受け入れてしまうのだろう。日本で培われた品質管理の方法論は今では日本よりもアメリカで有名になっていることを知らないのだろう。 MBAを取った友人が開発の上流工程で "The 5 whys method" を使った方がよいと言ったことがある。そのとき、それって、トヨタが生産現場で始めた「なぜなぜ分析」(なぜを5回繰り返す)手法 ※1 じゃないかと思った。どうして最初に考えた人や実践した人達を敬おうとしないのか、どうして英語だと格上と決めつけてしまうのだろうか。アメリカ人は最初に考えた人達を Respect しているのに、日本人がそうしないのが不思議だとも思った。
※1 なぜなぜ分析(なぜを5回繰り返す):ある問題とその問題に対する対策に関して、その問題を引き起こした要因(『なぜ』)を提示し、さらにその要因を引き起こした要因(『なぜ』)を提示することを繰り返すことにより、その問題への対策の効果を検証する手段
タグチメソッドも品質機能展開(QFD)もそうだ。先日、YouTubeでアメリカ人が FTA をレクチャーしている映像で ポカヨケをそのまま "Poka-yoke" って言っているのを聞いてすごく驚いた。ポカヨケは英語でそのまま通じるのだ。
今の時代、欧米発ではなくアジア発のソフトウェア開発論、ソフトウェア品質論があってもいいはずだ。どっちがいいかではなく、どうすれば品質の高い、価値の高い商品を開発できるかを考えることが重要だ。
自分はソフトウェアの開発ではソフトウェアエンジニアの性格、プロジェクトの習慣、その国の文化を考慮しなければ効果的に目的を達成することはできないと信じている。
欧米の文化で最適なアプローチがアジアの国々のソフトウェア開発プロジェクトでも最適であるとは限らないと思うのだ。それは、ISO 26262 についても同じだと思っている。
『リアルタイムOSから出発して組込みソフトエンジニアを極める』で書いたことが、韓国のソフトウェアエンジニアにも同意してもらえるのならば、それがアジア発の開発アプローチの一端なのかもしれない。
0 件のコメント:
コメントを投稿