サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
衆院選
embeddedsoftwaremanufactory.blogspot.com
IoTとは、「ありとあらゆるモノがインターネットに接続する世界」 らしい。ネットワークはすでに整備・構築されているので，センシングしたデータや入力した情報をつなげることで新たなサービスを提供するという発想だろう。 ちなみに，そのサービスにはクラウドかどうかは別にして情報を集約するデータサーバーが不可欠だ。だとすると，サーバーのメインテナンスやサービスソフトウェアのアップデートの管理費用がかかる。 IoT のビジネスの例として，BtoB で人的負荷の軽減によりコストダウンを計ることができると言う。でも，それってすでにかなりの分野でやっていることではないだろうか。 例えば，自動販売機の中のジュースや缶コーヒーがなくなると販売の機会損失となるので，サービス員が品物が切れていないかとうか見回ることになる。でも，その見回り作業はすでに，PHSやG3のモジュールに置き換わっている。IoTというキーワー
三菱自動車の燃費偽装問題では、不正なデータの操作が行われた軽乗用車４車種の実際の燃費が、カタログなどに記していた公表値と大幅に異なる可能性が出ていて、5～10%ぐらいの乖離があり、大幅に異なる場合には型式指定の取消しがあるかもしれないとのことである。 ｅＫワゴンの当初の燃費目標は2011年2月の時点で26.4km/リットルだったが、スズキが2012年9月に28.8km/リットルのワゴンＲを発売すると、三菱自動車内の目標は29km/リットルに引き上げられ、ダイハツ工業が2012年の12月に売り出した「ムーヴ」の燃費が29km/リットルになるという情報が伝わると、目標は29.2km に引き上げられた。 もしも、燃費目標と根拠となるメカニズムがセットで語られていなかったのだとしたら「手段を選ばず目標を達成せよ」と命じたのと同じだと思う。直接不正を指示してはいなくても、結果的にはそうせざるを得ない
機能安全は安全について間違った認識を植え付ける元凶となっている。これは事実だ。だから、表題で機能安全のバカと書いた。 先日、あるソフトウェアミドルウェアメーカーがソフトウェアを売り込みに来た。営業技術という肩書きだったと思う。 「この商品はISO26262の機能安全の認証を取っているんですよ。」という。そして、IEC62304の認証も取る予定ですと来たから、「IEC 62304 の対象は医療機器ソフトウェアだから、部品で認証を取ることはできない。」と指摘した。 寝耳に水だったようで、キョトンとされてしまった。IEC 62304 医療機器ソフトウェア－ソフトウェアライフサイクルプロセスは、ISO 13485 と ISO 14971 を引用規格としている。引用規格というの参照しているという意味ではなくて、IEC 62304 に適合するということは、引用規格にも適合していることを求めるということ
ロイターの記事によると、24日にフィアット・クライスラー・オートモービルズが米国で140万台をリコールしたそうだ。 高速道路を走行中のフィアット・クライスラー車両のテレマティクス（自動車のコンピューターと無線通信を組み合わせたカーナビなどのサービス）にハッカー攻撃を加え、エンジンやステアリング、ブレーキを遠隔操作ができたので、そのままにしておくのは危ないからリコールしたのだ。 サイバーセキュリティが原因で自動車がリコールされたのは、これが始めてだという。 最近、どこもかしこもサイバーセキュリティのことが話題になっており、サイバーセキュリティの対策をしないと危ないぞと、「親切に」教えてくれる正義の味方の方達があちこちにいる。 多くの製造業者は時代の流れで機器をネットワークにつないで多様なサービスを提供しようとしており、利便性の裏でネットワーク越しのサイバー攻撃を受けるリスクが高まるというわけ
【タカタのエアバッグの問題に思うこと】 タカタのエアバッグの問題が話題になっている。ロイターの記事『特別リポート：タカタ欠陥エアバッグ、尾を引く「メキシコの誤算」』を読むと大量の不良品が出回ってしまったのはメキシコでの生産工程の問題が原因だったらしい。 タカタは、2000年頃エアバッグの基幹部品であるインフレーター（ガス発生装置）のコストダウンのため、インフレ―ター生産を米国の2つの工場からメキシコへ移管させた。その結果、インフレ―ター生産の1個当たりの労働コストは2ドルから約75セントに低下。2006年までの5年間に、同社は7000万ドルの労働コストを削減した。タカタの顧客である完成車メーカーにとっても、インフレータ―の購入コストが1個当たり20ドル未満と20%以上も引き下げとなり、大きな恩恵が及んだ。 しかし、記事によると生産現場の環境はさまざまな問題があったようで、結果的にこの工場移
ホンダが2013年に発売した「フィット」のハイブリッド車で、2月10日に3回目のリコールが出た。1回目が2013年10月に起きたデュアルクラッチ自動変速機の制御プログラムの不具合で、モータ走行モードでドグとスリーブがかみ合わず走行できなくなる恐れがあるというもの。 2回目が2013年12月に発覚したエンジンECUや変速機ECUにおけるプログラム不具合によって、エンジンがストールしたり、駐車状態から起動しなくなる恐れがあるもの。 そして、3回目が2014年2月で1速歯車のハブ上をスリーブが滑らかに動かず、1速がかみ合わなかったり、突然発進する可能性があるとのこと。最後の1件はソフトウェアの不具合ではないようだが、1速ギヤがかみ合いやすくなるようにエンジン制御ユニットのプログラムを変更するため、これも制御ソフトウェアの変更で対処する。 東洋経済のWEBサイトに【ホンダ｢フィット｣に不具合が多発
トヨタが2月12日にプリウスを世界で約190万台、ハイブリッドシステムを制御するプログラムに不具合があるということでリコールを発表した。 【Tech On! 「プリウス約190万台をリコール、昇圧回路の素子に想定外の熱応力」より引用】 トヨタ自動車は、2009年5月から販売を始めた3代目プリウス（ZVW30）約190万台をリコールすることを明らかにした。2009年3月から2014年2月までに生産したもので、日本市場向けの約100万台、海外市場向けの約90万台が対象になるという。 トヨタ自動車の説明によれば、プリウスのハイブリッドシステムにおいて、制御ソフトが不適切なため、加速時などの高負荷走行時に昇圧回路の素子に想定外の熱応力が加わる恐れがあるという。このとき素子が損傷し、警告灯が点灯して「フェールセーフのモータ走行」になってしまう。加えて、素子損傷時にノイズが発生すると、ハイブリッドシ
最近、どうしてもペンを取りたいと思わせることが二つ起こった。ひとつは、マツダの安全装備の体感試乗会で起きた「CX-5」の事故で、もうひとつは2007年に起こったトヨタの急加速事故に関するトンデモ検証記事だ。 マツダの安全装備の体感試乗会で起きた「CX-5」の事故 【Car Watch NEWS より】 マツダは11月12日、埼玉県内でマツダオートザム店を展開する坂田自動車工業が開催した安全装備の体感試乗会で、11月10日に発生した人身事故についての第一報を発表した。 埼玉県深谷市の坂田自動車工業 駐車場内で発生した今回の事故では、「CX-5」に装備されている「スマート・シティ・ブレーキ・アシスト（SCBS）」の機能を体感するイベントのなかで参加者が運転する車両がフェンスに衝突。車内にいた参加者と販売店従業員の2人が負傷し、参加者が頚椎捻挫（軽傷）、販売店従業員が右腕骨折（重傷）となっている
2011年12月1日から1年半、27回に渡り続けてきた特集記事「ISO 26262との向き合い方」をいったん終了にすることに決めた。 書きたいネタはまだまだあるのだが、6/7 に開催した SESSAME のソフトウェア安全分析・設計セミナの参加された自動車ドメインの方達と接して、ハタと気がついたのだ。 薄々気がついていたのだが、自動車業界は業界構造がサプライヤが部品を作りメーカ（OEM）がアセンブリするというスタイルが出来上がっている。 だから、ソフトウェア安全分析・設計セミナで訴えている「現代の大規模・複雑化したシステムでは Fault Avoidance（個々の構成要素の信頼性を高めることで安全を確保しようとする設計）は無理で、Fail Safe, Fault Tolerance, Error Proof(Fool Proof) の設計を目指しましょう」という主張が肩すかしにあう。 サ
ISO 26262 Part 8: Supporting processes （支援プロセス）には「ソフトウェアツールの使用への信頼」という章がある。 いろいろな国際規格を見てきたが、商業目的につながることが目に見えているツール種別の推奨やツール使用の条件のような内容を規格の本文に書いているのは、IEC 61508-7(Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 7: Overview of techniques and measures) と、ISO 26262-8 (Supporting processes) だけではないかと思う。 ET2012 で富士設備工業（株）の浅野さんに FAA(アメリカ連邦航空局：Federal Aviatio
ISO 26262 が2011年に発行されてから時間が経過し、今になって自動車の設計開発の現場で混乱が起こり始めたような気がする。 ソフトウェアの開発経験のないハードウェアエンジニアにもISO 26262の存在がクローズアップされるようになり、ソフトウェアエンジニア達に規格適合できているの問いただすような視線を送るようになってきた。 ISO 26262 は基本的にプロセスアプローチだから、規格が要求するプロセス通りにもの作りをし、エビデンスとなるドキュメントが作成していないと規格に適合していると認めてはもらえない。 規格適合について監査したり、自分達でアセスメントをしたりすると、いろいろと漏れが出てくる。そうすると、ソフトウェアのことを分からない人達は「なんだ、ダメじゃないか」「どうして、国際規格の要求ができていないんだ」「怠慢だ」とソフト屋さんを責める。 電気的安全性のように試験で白黒が
ちょっとでも危険がある製品を開発するエンジニアが安全の概念について理解することは非常に重要だと思っている。※1 なぜなら、安全が必要なもの作りをしている者にとって空気のように当たり前と思っていたことが、安全に関わったことのない人には十分に理解してもらえず、話しがすれ違うことに気がついたからである。 ※1 危険、リスクは思いもよらないところに潜んでいるので、自分が作ったソフトウェアが危険にはまったく関係ないと思っていても、思わぬ事故が起こることはよくある。安全ソフトウェアを目指す仕事をしていると、どんなリスクがあるが臭いで分かるようになる。 そして今では、安全とは何かについての考えが深まっていない人々に対して、どうすれば安全の概念についての考えを深めることができるのかを伝えることが自分の責務だと考えるようになった。 Microsoft の社員の肩書きで Evangelist（エバンジェリスト
仕事ともコミュニティ活動とも直接関係ないが、ジャーナリズムについて昔からずっと考えていた。 ジャーナリストになりたかったわけではないが、ジャーナリストは何となくあこがれていたところがあった。命をかけてまで報道しなければいけないこととは何なのだろうと漠然と考えていたし、報道の自由と民主主義が結びついていることは何となく分かってはいたけれども、報道の自由が当たり前となっている日本にいて、それを実感することはできなかった。 しかし、中国の大気汚染の問題を目の当たりにして、ジャーナリズムの重要性について実感が湧いてきた。あのスモッグの状態を見てこのままでいいとは誰も思っていないだろう。しかし、今の中国で公害を止めるためには政府（中国共産党）が規制を強くするしかない。個人の努力ではすぐに限界が来てしまう。（デモで国を動かせるか？） 粉じんの排出には利害関係が絡んでいるため、政府に頼っていると埒があか
ISO 26262の世の中の動きをウォッチしていくこと自体にいささか疲れてきた。正直言って、本当にユーザーのことを考えて安全や安心を実現したいのなら、自動車業界の規格適合に関する浮かれた熱が冷めるのを2～3年待った方がよいと考えるようになってきた。若しくは機能安全に群がる商魂たくましい人たちとは一線を画して、クリティカルデバイス、クリティカルソフトウェアに役立つことは何かに集中していくかだ。 今回は後者を選択して、FTAとFMEAの歴史を調べてみたいと思う。リスク分析のツールとしてFTA,, FMEA, HAZOP などいろいろあるが FTA と FMEA は特に歴史が古い。 FTA や FMEA がそもそも軍事産業から開発されたことは何となく知っていたが、今回、Wikipedia などで調べて改めてその歴史的背景を知ることで、いろいろ思うことがあった。 FTAの歴史 FTAとは、Faul
正月休みの間、自動車業界が直面するであろう安全ソフトウェアの問題(=自動車ソフトウェアの未来予想図）について二つのシナリオ考えてみた。まずは、これら未来のシナリオを読んでみていただきたい。 シナリオ1 電気自動車時代の不具合 2020年、電気自動車用の充電プラグは家庭やコンビニエンスストアにも普及が進み、郊外には電気スタンドもよく見かけるようになってきた。充電場所が増えるにつれて、それまで聞いたこともない電気自動車メーカー、ブランドの車も数多く現れてきた。電気自動車の販売価格帯は二極化しており、老舗の自動車メーカーの150万円以上のブランド車と、アジアのメーカーの100万円以下の車に人気が集中している。低価格電気自動車は安いものなら50～60万円で買えるようになり、都心の若い世代ではこのような低価格電気自動車を個人で購入するのではなく、電気自動車がシェアカーとして用意されているマンションを
今週、下記のような記事が Tech-On! に掲載された。（読むには無料のユーザー登録が必要） 【専門記者が振り返る】要件管理とトレーサビリティ、この1年――ISO 26262適合で日本でもツール基盤の導入進む 変更管理や構成管理はここ10年で浸透した。要件管理はこれからで、ISO 26262 への適合がトリガーになって、導入が進むのではないかという内容だ。 要件管理のツールとして「Rational DOORS」、米PTC社の「Integrity」、フランスDassault Systemes社の「Reqtify」が挙げられており、国内のツールとしては経済産業省から約5億円の助成を受け、組み込みソフトウエア開発ツール・ベンダーのキャッツなどが中心となって、「TERAS」というツール基盤を目下、開発中であると書かれている。 ※そういえば Google が検索エンジンのスタンダードになりつつあっ
まず、自分が ISO 26262 にこだわっている理由を書こうと思う。 自分は医療機器ドメインのソフトウェアエンジニアとしてのキャリアが24年である。そして、約20年前、自分がソフトウェアを担当した製品が、FDA（アメリカ 食品医薬品局）の定期査察で査察の対象となり、Warning Letter を受け、約1年間アメリカ向けの出荷が停止された。 その当時、一人で製品のソフトウェアを作っており、システム全体を完全に把握できていたし、ソフトウェアの検証についても我流ではあったが自信があった。実際、その製品でソフトウェアの問題はほとんど起こらなかった。（唯一、たった1ビットの設定ミスでソフトウェアを改変したことがあったので完璧ではなかった） 1990年頃、すでに、FDA は医療機器や医療機器に搭載されているソフトウェアに対して V&V (Validation & Verification）を客観
ソフトウェアエンジニアでない人にはピンとこないかもしれないが、ソフトウェアのアーキテクチャ（構造）を改善するということには意味がある。 家が完成してしまうと外面からはどのようなアーキテクチャ（構造）でその家ができているのかがよく分からなくなってしまうのは実際の建築物もソフトウェアシステムも同じだ。でも、そのアーキテクチャの善し悪しが災害に対する強度だったり、住みやすさに大いに影響する。テレビ朝日の『大改造!!劇的ビフォーアフター』で、古い家屋を骨組みだけにする過程で、基礎がいい加減だったり、支えとなる柱が途中で切られていたりするケースをたまに見かけるが、これらの手抜き工事は外からでは見られないから恐ろしい。 ソフトウェアの場合、アーキテクチャが悪いと、非常にわかりにくいバグを生んだり、ソフトウェアの再利用によく多くの時間と工数がかかる。こちらも、それらの問題がソフトウェアのことに詳しくない
小倉 広著『任せる技術』を読み進んだので前回に続き感想と思ったことを書こうと思う。 小倉氏は CHAPTER 3 任せる、と伝える の中で、「人生のビジョンがない部下には任せられない」と書いている。仕事を任せる時には部下に自分からジャンプさせ選ばせる。しかし、そうするためには絶対に必要な条件があり、それが、自分なりの「判断基準」を持っていることだという。そして、その「判断基準」が長期的な「人生のビジョン」であることが必要というのだ。 【CHAPTER 3 「任せる、と伝える」 より引用】 部下の立場に立って考えてみよう。上司から仕事を任せたい、と申し出があった。どうやら今よりも仕事が増えそうだ。しかし、すぐに給料が上がるわけではない。目先の損得だけを考えれば、これは間違いなく「損」だ。 「給料が上がるわけじゃないないし、だったら面倒だから断ろう」 このように考えるのがごく普通の判断というも
いま『任せる技術』という本を読んでいる。プレイングマネージャを自負している方には是非読んでいただきたい一冊だ。まだ最初の方だけしか読んでいないが、とても心に響いている。 【CHAPTER1 ムリを承知で任せる より 引用】 そもそも部下の仕事とは「今日」の食いぶちを稼ぐことにある。一方で上司の仕事とは「今日とは違う明日」をつくることである。例えば、業務フローを標準化し改善する。営業戦略を立案し実行する。未来のビジョンを策定し部下を勇気づける。部下育成をする。これまでとは違うやり方を示し、より良い未来へ踏み出すのだ。 部下の仕事を奪っている上司は、これを怠っているということになる。目先の忙しさにかまけて本質的な上司の仕事を一切していないことになるのだ。先に掲げた「高い給与で部下の仕事を奪うこと」が目に見える損失だとすれば、「今日とは違う明日」づくりを放棄するということは目には見えない大いなる
深夜のサッカーの試合を生で見る元気がなく、朝起きてから結果を見ようと思ってテレビをつけたらたまたま、NHKで『課外授業 ようこそ先輩』をやっていてついつい見入ってしまった。 【番組ホームページより】 さまざまなジャンルの第一線で活躍する著名人が、ふるさとの母校を訪ね、後輩たちのためにとっておきの授業を行います。授業は通常２日間、リハーサルなしの真剣勝負です。内容や仕掛けは、先輩によって実に多彩。人生で得たこと、創造の秘密、専門分野の面白さなどを、独自の方法で解き明かします。そんな先輩の思いがこもった授業を、子どもたちはどう受け止めるのか？そこには毎回、思いがけない発見と感動があります。１９９８年に番組がスタートして以来、これまでに４００人を越える先輩が、母校の子どもたちに熱いメッセージを送ってきました。 今回の先生役の有名人、どこかで見たことがある。芸能人ではない。誰だっけと思い出していた
クルマ関係の仕事をしている技術者は日経エレクトロニクス 2011.1.10 の特集記事『クルマの電子安全始まる-ISO26262を越えて-』を必ず読んでほしい。 機能安全規格IEC61508と自動車の電子制御系に関する安全規格ISO26262の概念について詳しく解説されている。 自分自身、機能安全ということばがどうしてもすっきり理解できずもやもやしていたが、この記事を読んですっきりした。 だいたい、「機能」と「安全」の結びつきが直感的にイメージできない。Safety は functional ではない、安全は機能的に実現するのではなく、あらゆる使用環境、ハザードを想定してシステム全体で確保するものだと思っていたから、どうしても機能安全(functional safety)ということばがしっくりきていなかった。その疑問点をこの特集記事はクリアにしてくれている。 この記事がいいところは規格の内
日経ものづくりはソフトウェアには関係ないと思っている人も日経ものづくり8月号は単品(1400円）でも買った方がよい。 なぜなら、プリウスのブレーキ制御問題について、これまでになく詳細な情報が掲載されており、問題がなぜ起こったのかを推察できるからだ。 詳しくは 日経ものづくり8月号の特集記事『ソフトが揺さぶる製品安全』を読んでいただくとして、この記事のコラム「プリウスに見る、ソフトの落とし穴」の感想を書いてみたい。 まず、このブログの『プリウスブレーキ制御ソフト改変についての考察』の記事でも書いたように、何しろプリウスのブレーキシステムは非常に複雑だ。 これはプリウスだからではなく、現在のハイブリッド車はみな、このように複雑な制御でブレーキの機能や性能を実現しているのだと思う。 何が複雑化というとざっとこんなところだ。 そもそもブレーキペダルを踏むとブレーキオイルの圧力が伝達されブレーキパッ
あるセミナーでおもしろい図を見た。「じんざい」を四つの象限で表した図だ。縦軸はモチベーション、横軸はスキル。 モチベーションが高く、スキルもある場合は組織の財産という意味で人財 スキルは高いが、モチベーションが低い場合は単なる材料という意味で人材 モチベーションは高いがスキルが低い場合は、居るだけだから人在 モチベーションも低く、スキルもない場合は居るだけで罪だから人罪 もう一つの図。会社がリストラの必要性に迫られたときに、誰を残すかという指標。縦軸はビジョンを共有。横軸は仕事ができる。 組織とビジョンを共有し、仕事ができる社員は残す。 ビジョンを共有できているが仕事はできない社員も残す。 仕事ができるがビジョンが共有できない者は会社を滅ぼす。 ビジョンも共有できず、仕事もできない者は不要。 【楽に生きていきたいと思っていると楽に生きていけないというロジック】 楽に生きていきたい 責任を負
技術評論社さんから『リコールを起こさないソフトウェアのつくり方』を出版しました。『組込みソフトエンジニアを極める』を2006年にリリースして以来4年ぶりの新刊本です。 ※今回はですます調でいきます。 タイトルがタイトルだけにやけにタイムリーと思いになる方が多いかと思いますが、この本の企画は2008年の5月に提出したもので2年弱かけてじっくり仕上げた内容であり熟成の味の自信を持ってお届けいたします。 本に書いた内容は過去に技術評論社の組込みプレスに書いた記事が主体となっています。今回はソフトウェアの安全や信頼をテーマに、大規模、複雑化したソフトウェアにどのようにして問題が入り込むのかを実例をもとに解き明かし、日本のソフトウェアプロジェクトにフィットしたマネージメント技術および、ソフトウェアの品質と開発効率向上の両立を実現するためのソフトウェアの資産化の技術を解説します。また、付録で自動車分野
20年以上前アメリカ人の監査官とソフトウェア品質についてやり合ったことがある。自分の作ったソフトウェアに対していろいろ質問され、こんな性格だから自信持ってキッチリ答えたつもりだった。 だけど、判定はクロだった。そのときはなぜダメなのかまったく理解できなかったが、後から彼らが求めていることについて調べていくうちにだんだん分かってきた。 【判定クロの理由】 エンジニア個人の成果はその個人に由来するものであって、組織的な安全性や信頼性を担保するものではない。検証結果があるだけではダメで、検証の範囲、合否判定基準を明確化し、漏れなく実施するという組織的ルールが存在し、それが実行されていることが求められる。 アメリカ人はあらかじめルールを公開している。そのルールを事前に読んでいない、知らなかったは許されない。フェアーに対してアンフェアーな対応は絶対に許されない。 責任あるものの承認行為が必要である。
プリウスのブレーキ制御に関しては次々に新しい事実が分かるので過去の考察を訂正していかないといけない。 【いろいろな事実を総合して分かったこと（訂正を含む）】 この問題はたぶんソフトウェアのデグレード（変更によって今まで動いていたところが動かなくなるミス）ではない。 この問題は複雑化していたブレーキシステムの軽量化、低コスト化により、ブレーキシステムのハード・ソフトが変わった際に Validation（妥当性確認）の 漏れが生じたことからきている。 漏れがあったからといってトヨタやアドヴィックスがV&V(Validation & Verification)を十分に行っていなかった訳ではなく普通の企業に比べればよっぽど念入りにやっていた。（と予想する。） 軽量化やコストダウンの検討は悪ではなくエンジニアがトライすべきことだから、その流れは間違っていない。（だからデグレードではない。もとに戻して
(トヨタは社長と副社長が 2月9日の記者会見で、今回の問題について客観的なデータをもとに論理的に発生する現象及び原因を説明していた。 新聞やテレビの記者はエンジニアではないから、この技術的な説明の部分を全部すっ飛ばしてしまう。ラジオで聞いた制動力がが回復するまでの時間 0.4秒 というキーワード＋プリウス＋ABS で検索したら、今回の記者会見の技術的な説明が書かれている記事を見つけた。 Car Watch というサイトだ。この記事を読んでエンジニアとしては分からなかったことが全部分かってスッキリした。Car Watch さんありがとう。 詳細はこの記事を読んでもらうとして、自分が理解したポイントを書いていきたいと思う。 【今回の問題で制動距離が伸びるのか】 →想定する条件下において70cm伸びる ブレーキペダルの踏力をそのまました場合、通常のABSが0.4秒で作動するところ、0.46秒かか
ジョエル・オン・ソフトウェアの著者である Joel Spolsky はソフトウェア業界での豊かな経験を持つ開発者で、彼のウェブログ "Joel on Software" はプログラマ向けサイトとしては最も人気のあるものの一つで、彼はマイクロソフトの開発者だったころ Microsoft Excel 等多くの有名なソフトウェア製品の開発に携わった。 彼がブログで記事にしたことをまとめた最初の本が『ジョエル・オン・ソフトウェア』である。もともとはブログの記事であり。アメリカ人でないとわからないようなスラングや引用（例えばジョージ・ブッシュ大統領の口癖 Not gonna do it! 「それをやるつもりはない」等）がふんだんにちりばめられており、読みにくいと言えば読みにくいが、ところどころで「まさにその通り！」と膝を打ちたくなる部分がある。
次のページ
このページを最初にブックマークしてみませんか？
『Embedded Software Manufactory』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
