組込みソフト開発とクラウドソフト開発の違い
30年近く組込みソフトウェア開発に携わってきたが、ここに来てクラウドソフトウェアサービスの開発に関わっている。 そこでだいぶ様子が違うことが分かってきた。今回はその違いについて書いてみたい。 IoT機器（組込みソフトウェア機器）を無線/有線ネットワークでクラウドに接続し、クラウドアプリケーションソフトウェアでサービスを提供するというスタイルが増えつつある。 かつて、組込みソフトウェアは出荷時のソフトウェア品質を担保するためウォーターフォール的な開発プロセスが取られてきたが、ソフトウェアの規模が増大するにつれて、組込みソフトウェアでも一部または全体にアジャイル的なプロセスが適用されるようになった。 一方で、クラウドアプケーションソフトウェアの開発はどうだろう。クラウドアプリケーションソフトウェアの開発は DevOps だと言われる。 DevOps については、『DevOpsとは何か？ そのツ
ソフトウェア系国際規格の認証の現状について
機能安全規格の IEC 61508(Functional safety of electrical/electronic/programmable electronic safety-related systems) や ISO 26262 (Road vehicles — Functional safety )や、医療機器ソフトウェアのソフトウェアライフサイクルプロセス規格 IEC 62304(Medical device software - Software life cycle processes)に 「適合しました！」とか、「準拠しています！」といったニュースリリースをよく見る。 しかし、ブログでは『汎用ソフトウェア製品（製品開発プロセス）は IEC 62304(JIS T 2304) に適合できない』で書いたように、医療機器ソフトウェアでは、汎用ソフトウェア製品や汎用ソフトウェ
個別最適の時代は完全に終わった（ソフトウェア品質のパラダイムシフトについて考える）
サイバーセキュリティのことにクビを突っ込んでいると，ソフトウェア品質の概念が根底から変わったのではないかと感じる。 今や製品にOTSソフトウェア（Off The Shelf Software: 即利用可能な商用ソフトウェア）やオープンソースのソフトウェアを使うのは当たり前になっている。 組込みソフトウェアであっても何十万行にもなるソフトウェアにOTSを使わないケースはほとんどない。OSだってOTSだ。 そして，OTSには長い間使っているとサイバーセキュリティ上の脆弱性が見つかる。ここでよく考えた欲しいのはセキュリティの脆弱性は，ソフトウェアのバグ（欠陥）なのかという点だ。 脆弱性となった時点で修正が必要になるのだから，バグ（欠陥）と言えるかもしれないが，これまでソフトウェア品質の中で語られてきた決定論的原因故障(Systematic Failures) とは違うように思うのだ。 Syste
エンジニア社会主義 日本
技術系の新人向けにC言語の研修を外部講師を頼んでやっているのだけれど、ふと、これって海外の企業なら「C言語でプログラムを書ける人」とか「○○のスキルを持っている人」といった採用条件で人材を募集するんだろうなと思った。 プログラミングをほとんどやったことない人材を企業で教育してソフトウェア開発にアサインするなんてことやっているのは日本だけじゃないかと思う。 実際、LinkedIn に自分のスキルや実績を書いておくと、たまに海外の会社のリクルーターからコンタクトがくる。海外の企業はリクルータと契約していて開発に必要なスキルを持つ人材を常に探しているように見える。実際，海外の企業ではクビになる可能性も高いから転職の市場もそこそこ大きいのだろう。 日本の企業って、どうして商品開発に必要な知識やスキルがほとんどない状態の人材を採用して、自前で教育するスタイルをずっと昔から変えないのだろうと思う。たぶ
組込み機器のサイバーセキュリティどこまでやればいいか考える際の3つの視点
組込み機器のサイバーセキュリティ，どこまでやればいいのか判断するのが難しい。 商品の価値という目で見れば，多くの組込み機器に取ってサイバーセキュリティは潜在的価値（=ユーザーにとって当たり前に出来ていて欲しいこと）なので，できればコストをかけずに達成したい。 一方で，悪意を持ったハッカーは何をやってくるのか分からないと考えると，最悪のケースが次々を浮かんできて，どこまでサイバーセキュリティの対策をやればいいのか見当が付かない。 組込み機器のサイバーセキュリティはどこまでやればいいのかは，１つの視点だけで考えていたら答えがでないような気がする。 そこで，「1. 危害の大きさ」「2. 悪用の可能性」「3. 製品のライフサイクル」の3つの視点で，どこまでやればいいのか，最低限のハードルはどこかを考えてみる 1. 悪用による危害の視点 マルウェアや悪意を持ったハッカーの攻撃で，機器が受ける危害の大
医機連から公開されたIEC 62304適用に関する質疑応答集（Q&A）
医機連（一般社団法人日本医療機器産業連合会）が2017年5月17日に厚労省から発出された『医療機器審査管理課長通知：医療機器の基本要件基準第12条第2項の適用について』の運用に関する留意点について，質疑応答集（Q&A）を公開した。 ようするに，IEC 62304(JIS T 2304)への適用に関する通知が5月17日に厚労省から出たが，その通知だけではよく分からない点があるので，業界の総意として質疑応答集（Q&A）を公開したということである。 『医療機器審査管理課長通知：医療機器の基本要件基準第12条第2項の適用について』では，2017年11月25日から適用される医療機器の基本要件基準(平成17 年厚生労働省告示第122 号)の第12 条第２項の規定（プログラムを用いた医療機器に対する配慮）に適合するためには，基本的に JIS T 2304（IEC 62304）に適合することや，薬事申請時
組込み機器の情報セキュリティは何のため？
組込み機器の情報セキュリティの対応に対するモチベーションがなかなか上がらない。誰のために何のためにやっているんだろうと自問自答し，さらに，どこまでやればいいのか見当が付かないためやる気が起こらない。 そもそも，悪意を持ったハッカーなんかが居なければ，セキュリティ対策なんてしなくてよかったのではないか。5月に世界中で蔓延したランサムウェアのWannaCry は米国家安全保障局（NSA）から流出した Windows の脆弱性 EternalBlue を使ったものと言われている。 EternalBlue は流出するまで，諜報機関により米国の監視活動に利用されていたらしい。アメリカは脆弱性の元を作っておきながら，米国に機器を売る者に対しては情報セキュリティのハードルを世界最高の水準に上げている。本当に迷惑な話だ。 こんなことだから情報セキュリティの取り組みにはやる気が起きない。しようがないので，次
IoTというバズワードに踊らされている方々へ
IoTとは、「ありとあらゆるモノがインターネットに接続する世界」 らしい。ネットワークはすでに整備・構築されているので，センシングしたデータや入力した情報をつなげることで新たなサービスを提供するという発想だろう。 ちなみに，そのサービスにはクラウドかどうかは別にして情報を集約するデータサーバーが不可欠だ。だとすると，サーバーのメインテナンスやサービスソフトウェアのアップデートの管理費用がかかる。 IoT のビジネスの例として，BtoB で人的負荷の軽減によりコストダウンを計ることができると言う。でも，それってすでにかなりの分野でやっていることではないだろうか。 例えば，自動販売機の中のジュースや缶コーヒーがなくなると販売の機会損失となるので，サービス員が品物が切れていないかとうか見回ることになる。でも，その見回り作業はすでに，PHSやG3のモジュールに置き換わっている。IoTというキーワー
サイバーセキュリティって誰のためにやっているの？
最近、自分の業務ドメインにてサイバーセキュリティの問題に取り組んでいる。 数年前まではまったくのシロウトだったが、エキスパートの方達と活動していく中でそこそこ詳しくなったと思う。 そして常に考えているのは「これは一体誰のためにやっているのか？」という疑問だ。 なぜ、そんなことを考えているのかというと、サイバーセキュリティの分野ではその道で飯を食っている人達がいて、彼らは「こんなことも知らないのか」とか「こんなこともやっていないのか」とか「こんなことされるんですよ」などと、目に見えない脅威に対して恐怖を煽ってくれる。 幸いにも現実に悪意を持ったハッカーによって患者さんの健康被害に至ったという事例はまだ聞いたことがない。 上記の図は、そういった状況の中で機器の製造業者がどのようなプレッシャーにされされているのかを表したものだ。 専門的な知識が必要。 世の中で話題になっている。 規制またはそれに
Embedded Software Manufactory: 機能安全のバカ
機能安全は安全について間違った認識を植え付ける元凶となっている。これは事実だ。だから、表題で機能安全のバカと書いた。 先日、あるソフトウェアミドルウェアメーカーがソフトウェアを売り込みに来た。営業技術という肩書きだったと思う。 「この商品はISO26262の機能安全の認証を取っているんですよ。」という。そして、IEC62304の認証も取る予定ですと来たから、「IEC 62304 の対象は医療機器ソフトウェアだから、部品で認証を取ることはできない。」と指摘した。 寝耳に水だったようで、キョトンとされてしまった。IEC 62304 医療機器ソフトウェア－ソフトウェアライフサイクルプロセスは、ISO 13485 と ISO 14971 を引用規格としている。引用規格というの参照しているという意味ではなくて、IEC 62304 に適合するということは、引用規格にも適合していることを求めるということ
要求分析と安全設計との関係（機能安全の致命的な欠陥）
日本の組込み系のソフトウェアエンジニアに担当製品に対するユーザー要求は何かを聞くとすぐさま答えられないことが多い。 顧客の要求に基づき日々ソフトウェアを開発しているIT系のソフトウェア技術者には驚きかもしれないが、事実そうなのだ。 なぜ、組込み系のソフトウェアエンジニアは自分の製品のユーザー要求を答えられないのか。それは、過去の製品のソフトウェアを追加、修正しながら新しい製品を作っているから、大元のユーザー要求を把握していなくとも、製品開発が出来てしまうからだ。 継承するソフトウェアの中に基本機能、基本性能がすでに入っているから、付加機能を付け足すぶんには元の要求を知らなくても作業はできるのだ。 さながら、老舗旅館の旧館、新館、別館、アネックスといったようなもので、結果、継ぎ足しで成り立っている迷路のような構造になることもしばしばだ。 継ぎ足し、修正ばかりやっているソフト技術者はユーザー要
ISO 26262との向き合い方 (27) 最終回：何に向き合いますか？
2011年12月1日から1年半、27回に渡り続けてきた特集記事「ISO 26262との向き合い方」をいったん終了にすることに決めた。 書きたいネタはまだまだあるのだが、6/7 に開催した SESSAME のソフトウェア安全分析・設計セミナの参加された自動車ドメインの方達と接して、ハタと気がついたのだ。 薄々気がついていたのだが、自動車業界は業界構造がサプライヤが部品を作りメーカ（OEM）がアセンブリするというスタイルが出来上がっている。 だから、ソフトウェア安全分析・設計セミナで訴えている「現代の大規模・複雑化したシステムでは Fault Avoidance（個々の構成要素の信頼性を高めることで安全を確保しようとする設計）は無理で、Fail Safe, Fault Tolerance, Error Proof(Fool Proof) の設計を目指しましょう」という主張が肩すかしにあう。 サ
ISO 26262との向き合い方 (24) ソフトウェア安全分析・設計2
SESSAMEで6月7日に開催するソフトウェア安全分析・設計セミナの資料を作っているところだ。 4月17日に募集要項を公開してから2日間で事務局宛に11名の応募があったようだ。（定員は30名なので参加を検討されている方は早めに申し込んで欲しい） 東京近郊以外の遠方から申し込んでいただいた方も半分くらいおられるので、その方達の期待に添う内容にしたいと思っている。 セミナで使うスライドはまだまだこれから作成、ブラッシュアップしていくので、参加を希望されている方達の業務ドメインを眺めながらそれぞれの実務でイメージが湧くような事例を多く紹介しようと思っている。 なお、このブログで ISO 26262 の特集記事を書いていることもあって、現在のところ自動車系のドメインの方の申し込みが多い。（自動車ドメインに特化した内容ではないので、他のドメインの方も来て欲しい） この記事では、『ソフトウェア安全分析
ISO 26262との向き合い方 (23) ソフトウェア安全分析・設計セミナ
ISO 26262 が2011年に発行されてから時間が経過し、今になって自動車の設計開発の現場で混乱が起こり始めたような気がする。 ソフトウェアの開発経験のないハードウェアエンジニアにもISO 26262の存在がクローズアップされるようになり、ソフトウェアエンジニア達に規格適合できているの問いただすような視線を送るようになってきた。 ISO 26262 は基本的にプロセスアプローチだから、規格が要求するプロセス通りにもの作りをし、エビデンスとなるドキュメントが作成していないと規格に適合していると認めてはもらえない。 規格適合について監査したり、自分達でアセスメントをしたりすると、いろいろと漏れが出てくる。そうすると、ソフトウェアのことを分からない人達は「なんだ、ダメじゃないか」「どうして、国際規格の要求ができていないんだ」「怠慢だ」とソフト屋さんを責める。 電気的安全性のように試験で白黒が
ISO 26262との向き合い方 (8) リスク分析しないでいいの？
今回の記事は リスク分析、リスクアセスメントについての話題である。 最初に、医療機器ドメインのリスクマネジメントに関する国際規格である ISO 14971:2007 Medical devices — Application of risk management to medical devices のリスク評価の定義について見て欲しい。 リスクは、危害の発生確率（the probability of occurrence of harm）と、危害の重大度（the consequences of that harm, that is, how severe it might be. ）により評価されるというのが ISO 14971 の考え方である。一般的にも、リスク = 発生確率 × 重大度 などと書かれる。 例えば、ハードウェア部品の故障による障害などでは、発生確率はすなわち部品の故障率
サイバーセキュリティで初の自動車のリコール
ロイターの記事によると、24日にフィアット・クライスラー・オートモービルズが米国で140万台をリコールしたそうだ。 高速道路を走行中のフィアット・クライスラー車両のテレマティクス（自動車のコンピューターと無線通信を組み合わせたカーナビなどのサービス）にハッカー攻撃を加え、エンジンやステアリング、ブレーキを遠隔操作ができたので、そのままにしておくのは危ないからリコールしたのだ。 サイバーセキュリティが原因で自動車がリコールされたのは、これが始めてだという。 最近、どこもかしこもサイバーセキュリティのことが話題になっており、サイバーセキュリティの対策をしないと危ないぞと、「親切に」教えてくれる正義の味方の方達があちこちにいる。 多くの製造業者は時代の流れで機器をネットワークにつないで多様なサービスを提供しようとしており、利便性の裏でネットワーク越しのサイバー攻撃を受けるリスクが高まるというわけ
安全性と信頼性
SEC journal 38号で安全学で著名な明治大学 名誉教授の向殿 政男先生が「信頼性と安全性」の記事を書いている。無償でPDFにて読めるので是非読んでいただきたい。 【まえがき より引用】 ・・・とくに、個々の構成部品の信頼性を追求して行くだけで、私たちの安全な生活は保証できるのであろうかという疑問が湧く。主として信頼性はハードなどの施設・設備の問題であるが、安全性は私たちの身体的な傷害や精神的な障害の問題である。最終目的は安全性のはずであるが、信頼性だけを追求して、安全性が実現できると考えるのは素朴すぎるのではないだろうか。本来、信頼性と安全性は異なった概念と技術であるからである。システムが大型になって全体を把握するのが困難になると共に、いったん事故が発生すると取り返しがつかないような場合には、安全性のほうを重視して追求する観点が不可欠なはずである。とくに、ソフトウェアを含んだコン
「部下に任せないとダメだ」と考えさせられる一冊（その2）
小倉 広著『任せる技術』を読み進んだので前回に続き感想と思ったことを書こうと思う。 小倉氏は CHAPTER 3 任せる、と伝える の中で、「人生のビジョンがない部下には任せられない」と書いている。仕事を任せる時には部下に自分からジャンプさせ選ばせる。しかし、そうするためには絶対に必要な条件があり、それが、自分なりの「判断基準」を持っていることだという。そして、その「判断基準」が長期的な「人生のビジョン」であることが必要というのだ。 【CHAPTER 3 「任せる、と伝える」 より引用】 部下の立場に立って考えてみよう。上司から仕事を任せたい、と申し出があった。どうやら今よりも仕事が増えそうだ。しかし、すぐに給料が上がるわけではない。目先の損得だけを考えれば、これは間違いなく「損」だ。 「給料が上がるわけじゃないないし、だったら面倒だから断ろう」 このように考えるのがごく普通の判断というも
国際標準との向き合い方
ソフトウェアの世界でも国際標準への対応が求められる機会が今後増えてくると考えられる。ISO 9001などが最もポピュラーだが、各業務ドメインにおいてもソフトウェアを意識した個別の規格がでてきた。日本のエンジニア特にソフトウェアエンジニアは国際基準・国際規格との付き合い方が下手だ。 それは、おそらくソフトウェアエンジニアが自分たちの日々の取り組みを外部にさらす機会がほとんどなかったからだと推測される。今回はソフトウェアエンジニアが国際標準とどのように向き合っていけばよいのかを考えてみる。 【国際標準との向き合い方】 国際標準の策定に対して、日本のエンジニアは自分たちとは縁遠いもの、天から振ってくるものだと考えがちだが、実際にはそうではない。国際標準は各国の代表が意見を出し合って議論し、投票によって内容を決定する。もちろん日本も代表として標準の策定に参画しているので、意見を主張することができる
日本の組込みソフトウェア開発はこうすればよい
あるセミナーで、アメリカの有名企業が採用するような学生は、学生時代に『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』を教科書として学んでいるという話を聞いた。『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』は650ページの分厚い本で日本語版は7980円である。 セミナーの講師曰く、学生もこの本をすべて頭の中にたたき込んでいるのではなく、どこに何が書いてあるのかを知っており、必要なときに参照するのだそうだ。 そういえば、ソフトウェア系の海外規格を見ているとソフトウェアの開発計画を立てる際に、どんな方法論(Methodology)を使うのか書く欄があったりする。日本の組込みソフトウェア開発を始める前に、どんな方法論を使うのか？と聞かれて即答できるプロジェクトはいくつあるのだろうか。 欧米の企業がソフトウェアを開発する際にソ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
