2020-07-07

組込みソフト開発とクラウドソフト開発の違い

30年近く組込みソフトウェア開発に携わってきたが、ここに来てクラウドソフトウェアサービスの開発に関わっている。

そこでだいぶ様子が違うことが分かってきた。今回はその違いについて書いてみたい。

IoT機器(組込みソフトウェア機器)を無線/有線ネットワークでクラウドに接続し、クラウドアプリケーションソフトウェアでサービスを提供するというスタイルが増えつつある。

かつて、組込みソフトウェアは出荷時のソフトウェア品質を担保するためウォーターフォール的な開発プロセスが取られてきたが、ソフトウェアの規模が増大するにつれて、組込みソフトウェアでも一部または全体にアジャイル的なプロセスが適用されるようになった。

一方で、クラウドアプケーションソフトウェアの開発はどうだろう。クラウドアプリケーションソフトウェアの開発は DevOps だと言われる。

DevOps については、『DevOpsとは何か? そのツールと組織文化、アジャイルとの違い』の解説がわかりやすい。
DevOpsとは「開発チーム(Development)と運用チーム(Operations)がお互いに協調し合うことで(図1参照)、開発・運用するソフトウェア/システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」という概念である。
【引用おわり】

ようするに、開発しながら運用も行うという、組込みソフトウェアを長年やってきたエンジニアとしては、ちょっと衝撃的な開発スタイルだ。

これが実現可能となっているのは、クラウドサービス提供各社(Microsoft Azure や Amazon AWS等)のクラウドアプリケーションが、クラウド上での各種サービスアプリケーションの組み合わせで、目的を果たせるようになっているところにある。

最終的なUI部分の作り込みは必要だが、IoT機器との接続や、アーカイブ、二次処理、データからのトリガー、セキュリティ確保等々、すでにあるサービスの組み合わせでかなりことができる。

これらのサービスの組み合わせの開発もクラウド上で行うので、クラウドアプリの開発にはPCとインターネットがあれば、それだけでできてしまう。

ただ、クラウドアプリの開発には、各社がクラウドサービスで提供するサービス群を使いこなすためのノウハウ(多くはWEBに情報があるが、使いこなすには経験が必要)をもったエンジニアが必要であり、この主の知識・スキルはかつての組込みソフトエンジニアが持っている知識・スキルとは異なると感じている。

ちなみに、Microsoft は今後のもうけの種をIoT や PC に搭載する Windows OSの販売から、クラウドサービス(Azure)の使用料に大きく舵を切っている。今や、Microsoft Office も Microsoft 365 でクラウドサービスになりつつある。

Microsoft は IoTのOSは Windows にこだわっておらず、Linux でもよいと考えている。だから、最新のWindows 10には WSL(Windows Subsystem for Linux)を追加できるし、Linux から Azure への接続もまったく問題にしていない。

実際やってみてわかるのは、IoTからクラウドへの接続費用とクラウドサービスの使用料はそれなりにかかる。クラウドへの接続のセキュリティレベルを高くしようとすると、それだけ接続料は上がるし、クラウドサービスは使用するサービスの組み合わせでどんどん料金が上がっていく。

エンドユーザは、さまざまなクラウドサービスが無償で提供されている気分になっているが、実際にはかなりのコストがかかっていて、商品の代金やサブスクリプション費用にそのコストが上乗せされている。

商品の価格にクラウドサービスのコストを転嫁すると、商品を売り続けないとダメなので、各企業ともサブスクリプションでエンドユーザからお金をもらいたい。そのためには、Eコマースのサービスを導入する必要があり、その投資も馬鹿にならない。

また、一度、クラウドサービスをエンドユーザに提供し始めると、そう簡単にはやめられなくなる。クラウド業者をスイッチするこは理論的には可能だが、各種提供されるクラウドサービスのインタフェースがまったく同じではないので、実質的には難しい。

よって、クラウドサービス提供業者はクラウドサービスの利用企業を囲い込むことができる。クラウドサービスの提供にはかなりの費用がかかると思うが、それに見合った利益も確保できるので、おいしい商売だと感じる。

さて、DevOps の話にもどると、クラウドサービスでエンドユーザにどんな価値が提供できるのかは、実際やってみないとわからない部分が多い。

また、クラウドへアクセスする部分のUIは比較的簡単に変更可能であるため、ユーザの要望に応じて、運用しながら変更していくこともできる。

そこが、組込みソフトウェアの開発との大きな違いだと感じる。組込みソフトウェアの場合、ネット経由でシステムソフトウェアのアップデートがやりやすくなったとはいえ、リリース時のソフトウェア品質の担保は必須であり、変更にもかなり気を遣うし、検証や妥当性確認の工数も必要だ。

一方でクラウドアプリケーションの場合は、すでに完成されたサービスを組み合わせるため、個々のサービスの信頼性は確保されており、データの流れを変えていくようなイメージで変更ができる。

同じことを組込みソフトウェアで実現することも、ソフトウェアアーキテクチャ次第で可能ではあるが、最初のシステムアーキテクチャの構築が難しい。クラウドアプリケーションの場合は、すでにシステムアーキテクチャが用意されている状態で利用を始めるので、最初の苦労はない。

ちなみに、クラウドアプリケーションで提供される個々のサービスの完成度が高いからといって、試行錯誤的な開発をしていたのでは、エンドユーザの対する品質は担保できない。

アジャイルを単純な試行錯誤的な開発開発スタイルだと思っているエンジニアはさすがに少数になったと思うが、ひょっとして今でもそれなりの数いるのではないかと疑っている。

そういう方には、『アジャイル開発のプロジェクトマネジメントと品質マネジメント: 58のQ&Aで学ぶ』を読むことをお勧めする。

日立製作所でアジャイル開発の品質保証を実践してきた筆者らが、本当の意味での品質を担保したプロのアジャイル開発とは何かについてレクチャーしてくれている。

自分もまだ全部腹に落ちておらず勉強中だが、クラウドアプリケーション開発において実践しないといけないと思っている。

IoT(組込み)ソフトエンジニアとクラウドソフトエンジニア、この二種類のソフトウェアエンジニアが協力しないと、今どきのクラウドサービスが成り立たない。

この二種類のエンジニアは似て非なる者だと思うので、これらの開発をうまくコーディネイトできる人材が成功の鍵となるのではと思っている。

ソフトウェアとハードウェアのつなぎについても、両方の知識や経験をもった技術者(=組込みソフトエンジニア)の存在が重要だったが、IoT と クラウドについても両方の知識・スキルを持ったエンジニアがシステムの全体を俯瞰しながら、適宜最適となるようにソフトウェア開発プロセスを選択的に適用していく必要があるし、二つの文化の違いを理解した上で、それらを上手にマネジメントする必要がある。

明らかに10年前、20年前とは、ソフトウェアの開発スタイルが変わりつつある。クラウドサービスに関しては、クラウドアプリを開発できるエンジニアをどれだけ増やせるかがクラウドサービス提供者の売り上げアップの鍵となるため、クラウドサービスの技術を学ぶための教育コンテンツが驚くほど豊富にWEB上に存在する。それもすべて無償だ。

かつて組込みソフトエンジニアのための教育教材がないということで、SESSAMEが作られたのだが、クラウドエンジニアの教材は豊富に提供されている。このソフトウェアエンジニアのトレーニングという部分での進化もすさまじい。

ただ、勉強することが山ほどあって、分業しないとやってられないという現実はある。だからこそコーディネータの役割は重要だと感じる。

DevOpsを成功させるには、エンドユーザの対する価値と時代による価値の変化を敏感に感じ取るセンスも必要だし、価値をビジネスに結びつけるための戦略を考え、その戦略を実現するための技術が何であるかがわかるようでないとうまくいかない。

組込むソフトウェアとクラウドソフトウェア、新しい時代のソフトウェアエンジニア像について、今後も考えていきたい。

2020-05-15

IoT(組込み系)のソフトウェア技術の e-Learning コンテンツが新型コロナウイルス感染症緊急対策で助成金を利用できます(東京都)

SESSAMEがリリースした 組込みソフトの e-Learning コンテンツについて、東京都が用意した新型コロナウイルス感染症緊急対策で、費用の4/5(上限32万円)の助成申請ができます。

東京都に事業所がある資本金3億円以下、従業員300人以下の企業であれば、新型コロナウイルス感染症緊急対策の中小企業人材オンラインスキルアップ支援助成金を使い、e-Learning 費用の4/5(上限32万円)の助成を申請することができます。

SESSAMEの e-Learning WEBコンテンツは 月額3000円で見放題なので、およそ100名のエンジニアに下記のコンテンツを一か月間 約6万円の費用で受講させることができます。

現在リリースされているタイトル
o.カテゴリ 講義タイトル リリース時期詳細
WB-01初級 プログラミング/テストの基礎 2020年04月
WB-02 構造化分析・設計の基礎 2020年04月
WM-01中級 組込みシステム開発における知的財産権 2020年04月 
WM-02 構成管理(理論編/実践編) 2020年04月
WM-03リアルタイムシステム設計(理論編/実践編)プラットフォーム選定の観点(RTOS編) 2020年04月
WM-04テスト・レビュー・インスペクション 2020年04月

申請期間は第6回の最後が 9月21日なので、申請する企業はお早めに。

------------- SESSAME の e-Learning コンテンツについて ----------

組込みソフトウェア管理者・技術者育成研究会(SESSAMEは) これまで CD-ROM で提供してきた SESSAME e-Learning Series のコンテンツを WEBコンテンツに移行しています。(すべてのコンテンツの移行が完了するまで、CD-ROMでの販売も継続します。) 

今回、初級コンテンツ2講座と中級コンテンツ 5講座を WEBコンテンツ化しました。これまで CD-ROM 1コンテンツ 5000円で、さらに、多人数で視聴する場合は上映権を設定していましたが、WEBコンテンツではひとりのユーザがすべてのリリースコンテンツを 1ヶ月3000円+税で視聴できるようになります。

これにより、短期集中的に組込みソフトウェアを学習したい方、長期に渡り学習したい方の両方にニーズに対応できるようになります。

この機会に是非 SESSAME e-Learning Series (WEBコンテンツ版)をご利用ください。


2020-04-21

『ソフトウェア系国際規格の認証の現状について』の記事に対するコメントと回答

2019-10-20に投稿した『ソフトウェア系国際規格の認証の現状について』の記事に対して2020-02-10にコメントをもらっていて、確認&承認を忘れており、昨日気が付いて承認をしました。2ヶ月以上放置してしまい申し訳ありません。

改めて、コメントの内容をここで紹介し、回答も書きたいと思います。

ーーーーコメント ーーーー

匿名 さんのコメント...
いつも有益な記事をありがとうございます。
汎用ソフトウェアが医療ソフトウェア規格の認証を受けることは意味が無いということは、ソフトウェアを含む医療機器開発には、汎用OSはもちろん、コンパイラが提供するライブラリも使用できないということですね?
リアルいタイムOSはもちろん、Linuxのような巨大なOS相当も、意図する使用を考慮してフルスクラッチが必要であるということですね?もしくは、LinuxクラスのOSは使用してはいけないということですね?
C言語ならいざ知らず、C++やJava 等の言語のメカニズムに相当する部位も汎用ソフトウェアと言えますから、それも使えないということですね?

ーーーーコメントに対する回答 ーーーー

さて、「汎用ソフトウェアが医療ソフトウェア規格の認証を受けることは意味が無いということは、ソフトウェアを含む医療機器開発には、汎用OSはもちろん、コンパイラが提供するライブラリも使用できないということですね?」のご質問に回答します。

汎用ソフトウェア(OTS: Off The Shelf Software)は OTS として検証・評価を行います。IEC 62304 はリスクベースアプローチを採っているため、何に使うのかが定まっていない状態で、リスクベースアプローチのプロセス規格を適用することは意味がないと言っているのであり、医療機器にOTSを使用できないとは一言も言っていません。

米 FDA は 医療機器に使用するOTSに対するガイダンスを発行しており、このガイダンスでは「そのOTSを医療機器に使用したときの懸念レベルを定めて、ハザード分析すること」を医療機器の製造業者に求めています。また、OTSの検証・評価も必要です。これもリスクベースアプローチです。

これについても勘違いしているOTSベンダーが多いのですが、OTSベンダーができるのはOTSの検証(=Verification)の部分であり、OTSが医療機器に使われたときの懸念レベルの推定やハザード分析は、医療機器製造業者が行います。正確には、その OTSを何に使うのか知っている医療機器製造業者しか、懸念レベルの推定やハザード分析はできないということです。

もちろん、Windows や Linux を医療機器に使用することもできますが、それらOTSを医療機器に使用したときのリスクの分析(OTSに障害が起きたときの患者への危害の重大さや発生確率の分析と評価)がもとめらます。

記事の中でも説明したつもりですが、機能安全のアプローチである認証が取れたOTSを使用することを求めるという考え方と、意図する使用(=Intended Use)を明確にした上で、リスクベースアプローチでOTSを使用するという考え方は、元のコンセプトが異なるということです。

リスクベースアプローチの考え方であっても、OTSが使えないということはありません。OTSがどんな用途の医療機器に使用するのかを分析した上で、必要な検証、評価を求めています。

また、コンパイラは 医療機器に組み込まれるソフトウェアではないものの、製品の品質に影響を与えるQMSソフトウェアであることから、そのリスクレベルに応じてバリデーションを求められます。(ISO 13495:2016 より)

さらに、近年の医療機器規制の中のサイバーセキュリティ要求により、汎用ソフトウェアの脆弱性の監視とパッチ対応は医療機器製造業者に対する義務となりつつあります。

いずれにせよ、汎用OSやコンパイラが医療機器に使えないということは一切ありません。