ISO 26262との向き合い方 (7) 自動車ソフトの未来予想図 - ある組込みソフトエンジニアの日記
正月休みの間、自動車業界が直面するであろう安全ソフトウェアの問題(=自動車ソフトウェアの未来予想図）について二つのシナリオ考えてみた。まずは、これら未来のシナリオを読んでみていただきたい。 ■シナリオ1 電気自動車の時代 の不具合 2020年、電気自動車用の充電プラグは家庭やコンビニエンスストアにも普及が進み、郊外には電気スタンドもよく見かけるようになってきた。充電場所が増えるにつれて、それまで聞いたこともない電気自動車メーカー、ブランドの車も数多く現れてきた。電気自動車の販売価格帯は二極化しており、老舗の自動車メーカーの150万円以上のブランド車と、アジアのメーカーの100万円以下の車に人気が集中している。低価格電気自動車は安いものなら50〜60万円で買えるようになり、都心の若い世代ではこのような低価格電気自動車を個人で購入するのではなく、電気自動車がシェアカーとして用意されているマンシ
ソフトウェア系の国際規格はどのように使うのか(2)？ (ISO 26262 が - ある組込みソフトエンジニアの日記
前回に引き続き、ソフトウェア系の国際規格（ISO 26262）がどのように使われるのかを解説したいと思う。 自分は自動車ドメインの仕事はしていない。しかし、ソフトウェア系の国際規格には長いことつきあっているので、おそらくこの見解は当たっていると思う。もしも、自動車業界の方で間違っているところに気がついた方は是非お知らせ願いたい。このブログ上で訂正したい。 まず最初に読者に認識して欲しいのは国際規格はそれだけでは法的な拘束力はないという点だ。国際規格と聞くと国際法のように守らないと罰則がある、当局に捕まるというイメージを持っている人が大勢いるようだがそうではない。 国際規格は各国の規制当局が規制に使うと宣言したときに初めて法的拘束力が生じる。日本のトヨタ自動車が ISO 9001 を取得していないという事実は有名だが、だからといって誰からも咎められることはない。トヨタは ISO 9001 に
問題解決の方法を100パターン作っておかないと動けない人材 - ある組込みソフトエンジニアの日記
今、組織が欲しい人材は、目的を示すことで自分の持ち駒（経験）を組み合わせて実現する方法を見つけ出すことができる人だ。 その対極に具体的な手順を示さないと動けない人がいる。例えば、目的はひとつ、工程が2つあって、それぞれの工程内での活動の選選択肢が10パターンずつあったら、サンプルのパターンを一つか二つ例示するのではだめで、今自分が置かれている立場にぴったり合う10×10=100のパターンの中から最も近い一つを示せと言われてしまうケースだ。 その程度はまちまちで、いくつかのケーススタディをするだけで済む場合もあれば、手取り足取り手順を示さないと動けない場合もある。 問題解決能力が高い人は、経験値が低くても工程を何回か繰り返すうちに具体的な手順から抽象度の高い解決方法を体系化することができる。 だから、組織は問題解決能力の高い人材が欲しい。 【1. 問題解決能力を身に付ける方法】 達成すべき目
『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』を見て - ある組込みソフトエンジニアの日記
『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』という映画をTSUTAYAでレンタルして見た。あまりに内容がドラマティックだったので、これはどこまで脚色されているのだろうかと思って、もとのスレッドがまとめられているwikiサイトで記述をざっと読んでみた。驚いた。ほとんどスレッドに書かれていることが忠実に再現されているように見える。 考えさせられたのが、ここに描かれているのは組込みとITの違いがあるにせよ、同じソフトウェアを作るエンジニアの日々の風景だということだ。 この話しは本やコミック、映画になっているが、知らない人もタイトルを見れば、だいたい中身の予想は付くだろう。映画の中では R25 にブラック会社の条件が6つ書いてあり、主人公のマ男君が入社初日で全部当てはまることに絶句する。 【ブラック会社の条件】 就業規則があるにも関わらず残業が当たり前 何日も徹夜が続くことがある 社
CAPAができていない組織の先行きは危うい - ある組込みソフトエンジニアの日記
CAPA （Corrective Action and Preventive Action：是正・予防措置）とは問題が起こったときに再発を防止するための考え方である。 【CAPAのプロセス】 問題点を明らかにする 是正アクションの実行 類似した問題が起こらないようにするための予防アクションの実行 予防アクションのデータによる検証 いたって当たり前のように見えるが、これが組織的にはなかなかできない。日本では「問題点を明らかにする」と「是正アクションの実行」を個人的にやるところまでしかいかないことの方が多いように思う。 組織的に再発を防止するためには「類似した問題が起こらないようにするための予防アクションの実行」と「予防アクションのデータによる検証」が必要だ。CAPAはシステマティックにやらないとうまくいかない。犯人捜し、個人攻撃のような様相を呈するようになると、みんな積極的に動かなくなる。
なぜドキュメントを書かない？ - ある組込みソフトエンジニアの日記
久しぶりに『ジョエル・オン・ソフトウェア』を読んだ。Amazon で調べたら、最近、この本の続編である『モア・ジョエル・オン・ソフトウェア』が出たようだ。 ジョエル・オン・ソフトウェアの著者である Joel Spolsky はソフトウェア業界での豊かな経験を持つ開発者で、彼のウェブログ "Joel on Software" はプログラマ向けサイトとしては最も人気のあるものの一つで、彼はマイクロソフトの開発者だったころ Microsoft Excel 等多くの有名なソフトウェア製品の開発に携わった。 彼がブログで記事にしたことをまとめた最初の本が『ジョエル・オン・ソフトウェア』である。もともとはブログの記事であり。アメリカ人でないとわからないようなスラングや引用（例えばジョージ・ブッシュ大統領の口癖 Not gonna do it! 「それをやるつもりはない」等）がふんだんにちりばめられてお
組織はソフトウェアエンジニアに投資できるか - ある組込みソフトエンジニアの日記
このブログで、日本のソフトウェア技術者は試行錯誤的アプローチで組込みシステムのソフトウェアを作ってきたと書いてきた。それでも組込み機器の品質が保たれているのは、日本人に特有の「あたたかい人間関係の中のやさしい一員」という性質と職人気質、そして品質を心配する強い意識があるからだとも書いてきた。 これらの日本人の特性プラス「何かあったらソフトウェアをすぐ修正」という行動によって、日本の組込みソフトウェアは今のところかろうじて高品質を維持していると思う。しかし、これらの状況は、ソフトウェアの規模が小さいことと、日本のソフトウェア技術者が劣悪な環境を我慢（高収入を求めずにオーバーワークに耐えるということ）しているからまだ破綻していないのであって、システムソフトウェアの規模が増大（例えば実行コード行数ベースで30万行を超えるような規模）し、技術者がその過酷な労働に耐えきれなくなってきたときには、組込
技術伝承の鎖が切れてしまった組込みソフト開発の現場 - ある組込みソフトエンジニアの日記
製造業における技術伝承は、ベテランが初級者にくっついて実際に作業をやらせ、失敗を繰り返しながら技術が習得できるまで指導を続けるというものだ。 一方でマニュアルを使って一律に技術習得させるという方法もある。マクドナルドがよい例だ。マクドナルドはマニュアルによる指導、トレーニングを徹底させるために世界のどこのマクドナルドに行っても同じレベルのサービスを受けることができる。これはまさに欧米的な技術の習得方法だと感じる。 日本でも工場では手順書による作業指示があるので、マクドナルドのマネージメントと似ているように見えるが、QC活動などでマニュアルを逸脱した独自のくふうも許しているところがちょっと違う。逆に言えば、一応手順書やマニュアルはあるものの、実際には冒頭で紹介したベテランが初心者に対して技術を習得できるまで指導し、その指導の方が手順書よりも優先されることが多い。 トレーニングの方法として学校
ソフトウェア資産の価値を可視化すべし - ある組込みソフトエンジニアの日記
ソフトウェア開発の効率化、高品質化がなかなか進まない。なかなか進まないと言っているのは、普通はどんな組織でも何か問題が起これば特に何らかの手法を使わなくても緩やかではあるが改善の方向に進むのだが、ことソフトウェアの開発では放っておいてもいっこうによくならない、よくならないどころか放っておくと悪い方向に向かってしまうということだ。そこには、メカやエレキの世界にはないソフトウェアだけの問題というのがありそうなような気がする。 メカ（機械設計）、エレキ（アナログ、デジタルを含む電気設計）、ソフト（ソフトウェア設計）の3つを比べたとき、開発の効率化、高品質化がやりやすいのは、メカ＞エレキ＞ソフトの順番ではないかと思う。 たぶん、その理由は各設計ドメインにおける開発の成果が見えやすいか否かの違いだろう。メカはできあがったものを見て動かしてみればできの善し悪しを判断できる。評価はできあがったものをみん
日米エンジニアの満足度の違い - ある組込みソフトエンジニアの日記
2009年最初の記事は、「日米エンジニアの満足度の違い」についてである。このデータはフリー情報誌の EE Times の昨年の記事から引用した。 EE Times は多くの記事が米国発の情報で、今回のデータは米国と日本の読者からのアンケートの集計結果である。 EE Times の読者はどちらかというとデジタル系のハードウェアエンジニアが多いと思うが、ソフトウェアエンジニアも読んでいると想像する。ということでアンケートの対象はハードウェアとソフトウェアの両方のエンジニアを包含したものだと考えればよいと思う。 【日本のエンジニアの特徴（回答者 1420人）】 平均年齢：43.6歳 平均年収：758万円 平均勤務時間:51.3時間/週 平均職務年数:18.3年 平均転職回数：0.8回（転職経験あり:44%) 【米国のエンジニアの特徴（回答者 1158人）】 平均年齢：46.0歳 平均年収：11.
組込みソフト開発失敗の見分け方 - ある組込みソフトエンジニアの日記
大規模組込みソフト開発で開発が失敗する可能性が高いかどうかを見分ける方法を見つけた。 このブログでは何度となく、日本の組込みソフト開発は試行錯誤的だと書いてきたが、試行錯誤的なアプローチが必ず開発の失敗に結びつくわけではない。 要素技術の検討や、小規模なソフトウェアの開発では試行錯誤的なアプローチは必要だ。試行錯誤的アプローチが失敗するのは10万行を超える中規模以上のソフトウェア開発の場合だ。そして、ソフトウェア開発が失敗しそうかどうかを見分けるには、ソフトウェアプロジェクトリーダーかソフトウェアアーキテクトに相当するエンジニアにその製品に求められている要求は何か？と聞いて、さらっと答えられるかどうかで判断する。 試行錯誤的なアプローチで付け足し付け足しを重ねて組込みソフトを作っていくと、ソフトウェアの Specification は答えられても、Requirements は答えられなくな
何も指導しないとプログラミングはこうなる - ある組込みソフトエンジニアの日記
久しぶりにC++のコードを書いた。過去に作った Visual C++ 6.0 で作ったソフトウェアをまた、使わなければいけなくなったのだが手を入れるためには、Visual C++ 2005 に乗せ替えなければいけなかったからである。 ちなみに、なぜVisual C++ 2008 にしないのかというと、ソフトウェアの場合は流行物に飛びつくと痛い目に会うことがあるので自重しているからだ。Windows もXPで購入した数々のアプリケーションソフトウェアがそのまま動くかどうか不安なので、まだ Vista に乗り換える決心が付かない。 さて、久しぶりにプログラムのソースコードに触れることで、プログラミングのやり方について常々考えていたことがふつふつとわき上がってきた。 技術者はどのようにプログラムを書くのかということだ。次に自分が一般的だと思うパターンを書いてみるので眺めてみて欲しい。 【何も指導
モデル駆動開発 - ある組込みソフトエンジニアの日記
SESSAMEで一緒のにしさんがブログでソフトウェアの自動生成を話題にしているので、今回は自動コード生成、モデル駆動開発について考えてみたい。 ソフトウェアの自動生成といっても設計行為がいらないわけではない。実際にはUMLなどでモデルを作ってそのモデルからコードを自動に生成するという話だ。ようするにソフトウェアシステムの抽象度を一段上げようという世の中の傾向のことである。 ソフトウェアをアセンブラで書いていた時代からC言語などの高級言語で書くように時代はシフトしたので、次は言語で記述せずにモデルを記述して、モデルからC言語、C言語からアセンブラといった変換の部分をツールにやらせようという考え方だ。 その背景には、10万行を超える高級言語で書いた組込みソフトウェアは絡まり合い、収拾が付かなくなり、不具合が起こっても問題の原因を追及しきれないことが多いことにある。 手続き型の言語に慣れてしまっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
