ETSSで測れないもの

ETSS（組込みスキル標準：Embedded Technology Skill Standards）が話題になっていて、技術者が自分のスキルをチェックしようという動きが出てきたのは歓迎すべきことであるが、ETSS では測れないものもあるのではないかという考えがずっと頭を離れないでいた。

ヒューマンスキル以外でETSSで測れないものもっと大事なものがあるというのが今回のブログの話題だ。

さて、ソフトウェアに限らず組込み製品の定例ミーティングを横で聞いていると「技術的な話がまったくされていない」という印象を持つことがある。

話だけ聞いていると人のつながりと業務ドメインの知識だけ語っているように聞こえるのだ。悪い言い方をするとえせエンジニアのディスカッションのように見えることがある。

このような人のつながりと業務ドメインの知識だけでメシを食っているえせエンジニアになるのは簡単で、ある特定の市場に対して同じような製品を作り続け、深く考えずにただ流されていけばよい。

このような人は、

1. 問題が起こったら動き出す。
2. 言われたら直す。

という行動パターンを取る人種であり、深く考えない。別な言い方をするとミーティングのときだけしか考えない。ミーティングが終わるとどんなにリスクのある案件であってもすっかり忘れる。精神衛生上はよいと思うが、エンジニアであるとはちょっと言い難い。

では、このような人に足らないものは何だろうか？　ここにないのはPDCA（Plan → Do → Chaeck → Action）を回すカイゼン力である。カイゼン力がないと、仕事を効率化できない。また、再発防止もできない。プロジェクトは決して楽にならない。（誰かにしわ寄せがいくだけ）

そう考えると、組込みソフトエンジニアに必要なのは技術力の修得も大事だが、それ以上に大事なのは現状をカイゼンする能力である。

組込みでカイゼンが有効なのは、やはり同じ市場、同じ顧客に向けて、同じような製品を投入し続けるからだろう。一発勝負の商品は少ないだけに、今回の経験を活かして次回につなげる施策が打ちやすい。

組込みでカイゼンを上手くやるには、優先度付けが重要になる。カイゼンしたいことがいっぱいあっても、時間や工数の制約から全部いっぺんにカイゼンするのは難しい。長期的視点に立って一番大事なところ、一番効果の高いところ、一番やりやすいところはどこなのか、うまく当たりを付けて優先度の高いところからカイゼンすることが大事だ。

カイゼンするには技術力だけではなく、人にネゴしたり、説き伏せたりすることも必要になるので、知識や技術的なスキルだけが高くてもダメだ。

そう考えると、現状の ETSS ではカイゼン力は測れないと思う。テストの点数だけよくて、カイゼン力がゼロの技術者は長い目で見るとプロジェクトにとってそれほど有効ではない存在になってしまう。

プロジェクトメンバーの全員が高いカイゼン力を持っている必要はないと思うが、逆にカイゼン力の高い技術者は高く評価されて欲しいと切に思う。

なぜなら、カイゼン力の高い技術者がプロセスを最適化し、技術の規範を構築し、開発効率を高めてくれるからである。

カイゼン力のない集団は、同じ過ちを何回も何回も繰り返す。

みなさんはカイゼン力高めてますか？
　

組込みソフトで成功できるエンジニアはひとにぎり？

最近、組込みソフトで「成功できる」「楽しく仕事ができる」エンジニアはひとりにぎりではないかと思い始めた。

何を持って成功なのかという話はあるが、ここでは次の2つの条件を含めたい。

1. クリエイティブでやりがいがある。プロジェクトが終わったときに達成感がある。
2. 今は大変でも、次は楽になるという希望がある。

大事なのは「クリエイティブ」というところと「次は楽になる」というところ。

組込みソフトもソフトウェアの規模が小さいときは、どんな組込みの現場でもこんな感じだったと思う。ソフトウェアシステムの全体を把握できたし、自分が作ったソフトウェアがダイナミックに製品の振る舞いに反映された。

プロジェクトが終わったときは達成感があり、そのドメインに特化したスキルが身についたことで次の開発では少し余裕ができ、顧客満足を高めるための新しい工夫を考える楽しみがあった。

ところが、今はソフトウェアシステムの規模が大きいので状況が様変わりしている。

まず、プロジェクトメンバの人数が多いのと、関係会社、協力会社との連携が必要になり、技術よりも人間関係やコミュニケーションに時間が取られる。

技術的なことだけやりたいエンジニアも年を重ねると、人のマネージメントをやらされる羽目になる。そして、製品の仕様は自分ではなく誰かに決めてもらうようになって、仕様変更に振り回される。

自分のプロジェクトが成功すると、周りに火を噴いているプロジェクトが必ずあるので、そっちを手伝わされたり、プロジェクトごと合併されたりする。自分たちが確立した効率化の成果をさらに発展させてくれるようにはならず、ひどい悪循環のプロジェクトにぶち込まれて、こっちも効率化することを強いられる。

大規模化した組込みソフトウェアのプロジェクトを成功させるには3つの要素がどれも優れていないといけない。

1. ソフトウェアの技術力
   
2. 要求の分析力と実現能力
3. チームビルディングの能力
   

ソフトウェアの技術力が高くてもダメ、要求の分析力と実現能力がないとダメ。ソフトウェアの技術力と要求の分析力、実現能力が高くてもチームビルディングの能力がないと、パワーを一つにまとめることができず開発を成功に導けない。

そして、この三つの要素がどれも満たされプロジェクトが成功しても、その様子を見ていた組織の上位層は成功したプロジェクトのメンバを火を噴いたプロジェクトに回してしまう。

プロジェクト内で一際能力の高さを誇るエンジニアがいると、そこに仕事は集まる。どんどん集まって際限がない。効率を上げれば上げるほどより多くの仕事が振られる。

こんなことが成り立つのはお人好しの日本人だけではないだろうか？　仕様が決まってなかろうが、大幅に仕様を変更されようが、ぶつぶつ文句を言いながら残業して製品を仕上げてしまう。自己犠牲をいとわない国民性・・・

こう考えると、優秀な組込みソフトエンジニアは流動すべきなのかもしれない。流動しないから同じ給料で仕事を振りかけられるのだ。我慢しないで自分の能力や実績を可視化して「評価しないとさよならするぞ」と言えるくらいにならないといけない。

日本のエンジニアはみな奥ゆかしいので自分の成果をアピールするのが下手だ。でも、これからはそれができないと、クリエイティブな仕事や達成感、いつかは楽になるといった感覚を得ることはできないのが今の組込みソフトを取り巻く環境だ。

こんな状況だから、組込みソフトの魅力よりもつらさの方が強くなって人材も集まらない。人材が集まらないから残された技術者に負担がのしかかる。

あまり考えたくないのだが、こんな状況では組込みソフトエンジニア全員がパッピィになるのは難しいように思えてくる。

組込みアーキテクトはギルドを作って、自分たちの立場を主張できるようにならないと浮かばれないのではないかとも思う。

技術を磨いただけではダメで3拍子そろっていないといけないのなら、達成できたときの評価や見返りは満足感だけでもいいからたくさん欲しい。

こんなことを思う今日この頃である。ちょっと悲観的すぎかなあ・・・

どうも、エンジニア系のブログや業界の周りの人たちを見聞きしているとこんな感覚になってしまう。
　

組込みでUMLは何のために使う？

あるソフトウェア技術者の方から、UMLについて問い合わせを受けた。その後、UMLツールやこの本を紹介したら次のような追加質問をもらった。

【追加質問】

詳しいご回答をありがとうございました。
書籍は早速購入しました。
ＵＭＬツールを使う上で、オブジェクト指向から学ばなければいけないと思っているのですが、どのようにオブジェクト指向とＵＭＬを勉強していけば良いでしょうか？

【追加質問終わり】

この追加質問の内容で、「ＵＭＬツールを使う上で、オブジェクト指向から学ばなければいけないと思っている」というところにちょっと引っかかりがあった。実質的にはそうなのかもしればいが、安直に UML = オブジェクト指向 関連付けると、組込みの場合特に足を踏み外しそうな気がする。

そこで、以下のような返信を書いた。

【追加質問に対する回答（抜粋）】

UMLは表記法です。極端な言い方をすればフローチャートと同じ表記法です。ただ、フローチャートよりは書き方を修得するのに時間がかかります。

では、なぜ修得に時間のかかるUMLを覚えるのか？　

UMLが国際標準の表記法となりつつあり、UMLで書いたモデルはたぶん10年近くは（UMLの表記法を認知している人の中で）通じます。

通じるというのは、UMLのダイアグラムを見ながらディスカッションすれば、ソフトウェアの静的な構造や振る舞いについて、素早く認識できるということです。ソースコードを見ながら議論するよりは、絶対効率的です。

プロジェクト内部だけで通じるブロック図でもいいかもしれませんが、プロジェクトの規模が大きくなって独特なブロック図の表記法について質問してくる人が増えたり、新しい人が入ってきたりすると毎度毎度説明しなければいけません。説明しないでもいいくらい単純な図だと、複雑なソフトウェア構造を示すことができないでしょう。

また、ソフトウェアの開発を海外を含む外部に委託するような場合も同じです。ソフトウェアの構造や振る舞いを共通の記述方法で示すことができれば、表記法の説明を省いて本題に早く入れるようになります。

でも、そんなに大きなプロジェクトではないチームだってあります。では、非常に狭い範囲だけでUMLを使うメリットはなんでしょうか？

同じ市場に対して、同じような製品を、同じメンバーで作り続けている少人数のチームがあった場合、UMLでソフトウェアの構造や振る舞いを表記する必要があるでしょうか？

答えは YES です。

理由は、自分たちのために必要だからです。同じ市場に対して、同じような製品を、同じメンバーで作り続けている少人数のチームであっても、ソフトウェアの規模は年々大きくなっているはずです。この規模が大きくなってしまったソフトウェアシステムの構造や振る舞いをUMLで表現することには意味があります。

例えば次のような目的のためです。

－UMLを使う目的－

1. 全体を俯瞰して、どのような責任分担でソフトウェアが分割されているのかが分かる。（上記のようなチームであれば、このモジュール分割が技術者の責任分担にもなる）
2. 分割されたサブシステム同士の関係（依存関係、呼び出し関係）が分かる。（サブシステムの独立性を高めるのに役立ちます）
3. システム全体もしくは一部の状態遷移が分かるようになる。（状態遷移図・・・古典的ですがやっぱり分かりやすいです）
4. そのシステムで何かをしたいときのシーケンスを表現できる。（役割分担と手順が分かると、具体的に何をすればいいか見えてきます）
   

いままでの小規模なソフトウェアプロジェクトでは1～4までの内容は、そのシステムの構造や振る舞いを最初に設計した技術者（アーキテクト）の頭の中だけに暗黙知として存在していました。考え方によっては、その技術者（アーキテクト）をチーム内にずっとキープしておければ、次々に新しい製品を開発できるとも言えます。

しかし、ソフトウェアシステムの規模は一人のアーキテクトでは把握しきれないくらいの大きさにまで拡大しており、また、ソフトウェアシステムに対する要求が複雑化すると、システム全体の構造を熟知しているアーキテクトしか分からない仕事が増えてしまい、そのアーキテクトの仕事が集中し、ついには破綻させてしまったり、その組織から逃げ出されてしまったりします。

悪循環から脱しきれないソフトウェアプロジェクトは、代わりとなる優秀なアーキテクトを探そうとし、人材不足の世の中、結局代わりのアーキテクトは見つからない場合もあるでしょう。その場合は、残されたメンバーで全体構造がよく分からないままソフトウェアを付け足し続け、最初のアーキテクチャを崩ししてしまい、悪循環のスピードを速めてしまいます。

また、運良く変わりのアーキテクトを見つけることができた場合、見つけられてしまったアーキテクトは前任のアーキテクトと同じように過負荷にさらされることになります。このとき、ソフトウェアシステムの構造や振る舞いを示すドキュメントが存在しないと、ソースコードからそれらを分析することになり、立ち上がりには相当な時間を要するでしょう。

もしも、ソフトウェアシステムの構造や振る舞いをUMLで表現できれば、次のような可能性がでてきます。

－UMLでソフトウェアシステムの構造や振る舞いを可視化できると・・・－

1. サブシステム単位で力のいれ具合に強弱を付けることができる。（まずは、このサブシステム、このモジュールの信頼性を高めようというアプローチが可能）
2. 再利用資産を抽出することが可能となり、開発の効率を高めることができる。
3. 不具合が起こったときに、原因となるサブシステムやモジュールを特定しやすくなる。（責務で分割されているため、発生した現象から原因を作った犯人を見つけやすい）
4. 新たな要求が降りかかってきたとき、どのサブシステムやモジュールに影響を及ぼすか事前に分析できる。
5. 新たな要求が降りかかってきたときに最小限の変更ですむような、システム構造を変更できる。（アーキテクチャの見直し）

新しい技術を習得しようとする際に大事なのは「何のためにその技術を取り入れるのか」をよく考えておく必要があります。場合によっては、「世の中の流行」や「自分の好み」が理由かもしれませんが、それだけでは、組織やプロジェクトのメンバーを説得するのは難しいでしょう。

新しい技術を習得するためには、時間や費用が必要です。こられのリソースを確保するためには、組織に対しては修得した技術で開発効率やソフトウェア品質を高め、顧客満足を高めることに貢献できることを説明し、プロジェクトメンバーにはその技術の習得が余裕を生み、クリエイティブな仕事ができるきっかけになることを示さなければいけません。

UMLをなぜ使うのかをしっかりと考えて、先に進んでください。

　　：

【追加質問に対する回答の抜粋終わり】

P.S.

上記の回答文章は質問に返信するつもりで書いたが、結局はブログネタとして使い本当の回答文章はもっともっと簡略化した。だって、こんな長い文章をメールで返信したらどう見てもへんでしょ。
　

組込みソフトは「見える化」より「見せる化」

近年、ソフトウェアの分野で要求分析の重要性が叫ばれている。対象となるソフトウェアに求められている要求をしっかり分析することはもちろん重要だが、特定のクライアントがエンドユーザーとなるビジネス系の受託開発ソフトウェアと、特定の分野の不特定多数のお客さんに提供する製品に搭載する組込みソフトウェアでは、ソフトウェアに対する要求についての考え方を変えなければいけない。

組込みソフトにはさまざまな制約条件が科せられるため、要求のすべてを満たすことが難しい。要求が多様になればなるほとリアルタイム性能などの性能要求を満たすことが難しくなるし、性能の高いプロセッサを使うことを余儀なくされコストアップにつながってしまう。

パソコンをプラットフォームとするアプリケーションソフトウェア開発では、組込みソフトウェアに比べれば遙かにリッチなプラットフォームが存在し、競争相手もまったく同じ環境で開発を行うことが分かっているので、要求と制約条件のトレードオフに頭を悩ませるより、ユーザー要求を間違えることなく、できるだけ早くすべて満たすことが目標となる。

ここには、組込みソフトのような強い制約条件や頻繁に発生するトレードオフは存在しない。

ところが、組込みソフトの場合は、エンドユーザーは特定分野の不特定多数のお客さんであり、必ずしも要求は「これだ！」という確約の採れたものではないし、求められるのは機能だけでなく、性能もあるし、安全性や信頼性も要求され、コストは安ければ安いほど喜ばれる。

そうなれば、当然要求に対して何をどれくらい実現すればよいのかについて優先度を付ける必要があり、その分析結果と、自分たちの得意なスキルを照らし合わせて、トレードオフをし、自分たちの商品でどんな機能と性能を実現するのか決断しなければならない。

最近の情報家電を見ると、商品に求められる要求の分析、特に優先度付けやトレードオフが必ずしも十分にできていないように思える。

例えば、5年前に買った　29インチのブラウン管のテレビは5万円台で非常にお買い得だった。ところが、このテレビ買って後悔したことが一つある。電源を入れてから画面が出るまで12秒かかるののだ。音声はタイムラグなしで出力されるのだが、映像が10秒以上かかるのは、せっかちな自分には耐え難いしうちだ。

また、2年前に買った250Gバイトのハードディスク内蔵のDVDプレーヤも5万円台でお買い得だった。こちらは、画面はすぐでるのだが、システムのイニシャライズが終わるのに20秒近くかかり、電源を入れてすぐに録画予約をすることができない。しかも、DVDのディスクが入っている状態で電源を入れるとシステムのイニシャライズ時間は30秒に伸びる。

新しい機能のほとんどを使いこなすことができず、昔使っていた VHSのビデオデッキと同じくらいの機能しか使わない一ユーザーにとって、この状態は性能のデグレードになる。

もちろん、メーカー側にはそれなりの理由があって、多用な要求を満たして他社とカタログスペックで負けないためには、Linuxなどのプラットフォームを搭載する必要があり、さまざまな内蔵デバイスの診断や、メモリチェックや OSの立ち上げをしている間に10秒くらいは立ってしまうのだろう。

でも、自分というユーザーにはそんなことはどうだっていい。電源入れたら早く立ち上がって、基本機能を使えるようにして欲しいのだ。そして、電源の立ち上がり時間で痛い目にあったので次からは素早く立ち上がる機種を選ぶ。もしも、その機種が他社に比べて機能がちょっとくらい少なくたってかまわない。基本機能を早く使う方が自分にとっては大事なのだ。

自分はこのような不満が自分だけの不満だけではないと考えている。だとすると、この情報家電を作ったメーカは先に挙げた、組込みソフトにおける要求の優先度付けに失敗していることになる。

おそらく、パソコンと同じようなプラットフォームを用意した時点で、組込み機器における制約条件やトレードオフのことを忘れてしまったのだろう。

ただ、現場のエンジニアは要求の優先順位に矛盾が生じていることについて、実はよくわかっているという意見もある。プロジェクトが大きくなってしまったり、組織が決めた方針を覆すことができないため、ユーザー要求の優先度がいびつになってしまった商品ができあがってしまっても、自分の力ではどうしようもないというのだ。

一昔前なら、ユーザーニーズの調査や商品企画、プラットフォームの選定などは、組込み機器開発のプロジェクトメンバーが行っていた。その状況なら、お客さんの要求と自分たちの得意な技術を考慮して、要求と機能・性能の実現の最適化が可能だった。

ところが、今ではプロジェクトの規模が大きくなり、要求も多様化してしまったため、要求の正確な分析と要求の実現能力のバランス判断が崩れている。

今、組込みソフトエンジニアの求められているのは、ユーザー要求の分析と自分たちの得意なスキルでどの要求を実現するのかを可視化して、自分たちの技術でどんな商品を作れば顧客満足を最大にできるのかという設計のコンセプトを明確にすることである。

組込みソフトウェア開発の世界では「見える化」をもう一歩踏み込んで「見せる化」が必要になっている。

ユーザー要求・市場要求の正確に分析し、その分析結果を基にソフトウェアシステムをどのように構築するのか、何がこの商品のアドバンテージになっているのか、何かこの商品のコア資産なのかを、組込みソフトエンジニアが可視化し、それを組織に示し、アーキテクチャ設計を主張し、場合によってはそのアーキテクチャを実現するためのプラットフォームを選択して、その選択の実現を組織に迫らなければいけない。

また、すでに自分たちが何世代かにわたって作り上げたソフトウェアシステムの構造を見えるようにして、どの部分がコアな資産であり、そのコア資産の品質を高めるために、何をしなければいけないのかを明確にし、そのために必要な環境や工数、費用を主張する必要がある。

そうしなければ、組織が決めた環境を、顧客満足が最大にできないことを知りながら使い続け、割り切れない気持ちを引きずることになる。

これを避けるために組込みソフトエンジニアがやるべきことは自分たちが「選択したもしくは選択したいアーキテクチャ」が顧客の要求にフィットしているということ可視化して主張するための「見せる化」だ。

それをしないと、プロジェクトはどんどんネガティブになって、メンバーには受け身の考え方が蔓延し、現場は問題解決の力を持っていながら顧客満足の高い商品をアウトプットできなくなり、競合に負け、価格を下げることでしか勝負できなくなり、忙しさは変わらずに給料が下がるという悪循環に陥ってしまう。

この悪循環を断ち切るための組込みソフトウェアシステムにおける要求分析の方法とその実践の仕方については、いずれわかりやすく説明する機会を作りたいと思う。


【組込みソフトで要求の重要度を分析しなければいけない訳】

組込みソフトウェア開発では要求の洗い出しだけでなく、要求の重要度を分析する必要がある。

　　↓なぜ

組込みソフトウェア開発では要求を実現する際にトレードオフが発生しやすいため、要求が示す意味と優先順位を分析し分析した結果を明示的に残しておくことが重要となる。それが、商品の開発コンセプトにつながり、どの他社の商品との差別化につながる。

また、その組織が独自に持っている強み・得意な技術を、顧客要求の強い部分にぶつけることができれば、競争力の強い商品を作り上げることができる。

日経ビジネス編集長の終わらない話 2.0が終わった

人気のポッドキャスト日経ビジネスオンライン『日経ビジネス編集長の終わらない話 2.0』が終わりました。このポッドキャストは日経ビジネスの井上裕編集長が、毎週金曜日に（週刊）日経ビジネス最新号の読みどころを中心に40分から一時間近くフリートークするという内容です。

一年以上の続いていたこのポットキャストが突然終わってしまった理由、それは、井上裕編集長が日経BP社から日本経済新聞社へ転勤（もともと出向していたのかも？）するからです。

このポッドキャスト、最終回で編集長が語っていたように、最初は日経ビジネスの販促のために記事の概要を紹介していたのですが、回を重ねるうちに読者との双方向コミュニケーションが始まり、ビジネスの話題を中心にしたコミュニティのように変化してきました。

このブログサイトも双方向コミュニケーションにしたかったのですが、なかなか難しいものです。日経ビジネス編集長の終わらない話がこれだけ盛り上がった理由は以下のような要因があるのではないかと思います。

1. ネタもとになっている日経ビジネスの記事自体が話題性・先見性がある。（非常に優秀な記者たちを抱えていると思います）
2. 週刊誌なのでポッドキャストも毎週金曜日に定期的に更新される。（定期更新）
3. 井上裕編集長が親分肌で人間的に好感が持てるし、話自体がおもしろい。
4. ラジオ日経のアナウンサーなど少ないながらプロのスタッフが番組を作っている。
5. ポッドキャストはどこでもダウンロードできるので海外でも聞けるため、自称海外特派員から便りがとどき、それを紹介することで空間の壁を越えたコミュニティの感覚が生まれる
6. おそらく変なメールもたくさん届いていると思うが、励ましやおしかりのメールをディレクターがうまく選択することで、結束を高めるような演出をしていた。

この中で一番の重要な要素が、3の井上裕編集長の人柄という部分で、悲しいかなサラリーマンの宿命である転勤が、簡単に代替えが効かないことにつながり、このポッドキャストを終わらせてしまったのです。

新しい日経ビジネスの編集長が引き継げばいいとも考えられますが、もの書きは必ずしもしゃべりが上手いということはなく、一時間近く台本なしのアドリブでしゃべるのは難しいでしょう。

ただ、このポッドキャストによって、日経ビジネスの読者は間違いなく増えており、この一年で読者の平均年齢層が一年から二年若返ったそうです。

自分自身、週刊誌を定期購読などしたら読まないでゴミになることが分かり切っていたので、定期購読はしないと決めていましたが、このポッドキャストを聞くようになってかなり気持ちがグラグラしました。（会社で購読しているので必要な記事は読めていました）

週刊誌の記事をネタにしてポッドキャストで情報を配信し、読者やリスナーを中心に双方向コミュニケーションを作り、それを聞いたリスナーが日経ビジネスの読者になるといういいサイクルが生まれていたと思います。

でも、このようなコミュニティの有効性に企業の上位層は気がつかないものです。

コミュニティの解散は数字的な影響よりも、参加していたものに対して心理的な影響を与えます。

日経ビジネスオンライン『日経ビジネス編集長の終わらない話 2.0』が終わってしまったのは残念ですが、この終わり方の理不尽さが日本の組織の考え方を象徴しているようで印象的でした。

※コミュニティの重要性を理解できないお偉いさんってエンジニアの世界にもいますよね。

P.S.

上記のポッドキャストが盛り上がった要因の6番はかなり効いていると思います。２ちゃんねるのように投稿されきた内容を全部さらけ出してしまうとどうしても番組のポリシーが汚されます。ねつ造ではなく、本当に投稿されてきたもののなかからきれいな賛成意見、反対意見を選択することで番組のイメージを保持することができます。ドキュメンタリーにも演出の要素があるのはこれと同じです。
　

※その後 3月5日から「 新編集長のここだけの話」が始まったようです。（もうやめられなくなったみたいです）