Embedded Software Manufactory: 2007

2007-12-21

ソフトウェア開発工程の区切りが見えない

ソフトウェア開発の場合、開発工程の区切りがよく見えないことがある。例えば、次のような工程（プロセス）の区切りを明確に見分ける方法は存在するだろうか？

1．ソフトウェア開発計画
2. ソフトウェア要求分析
3. ソフトウェアアーキテクチャ設計
4. ソフトウェアユニットの実装と検証
5. ソフトウェア結合
6. ソフトウェアシステム試験
7. ソフトウェアリリース

別にウォーターフローのプロセスじゃなくてもいい、インクリメンタルでも、ユニファイドプロセスでもなんでもいいが、どこが区切りかどうやって内外に示すのか？

電気回路の設計なら、プリント基板の完成や部品の実装という形で明確に一次試作や二次試作の工程のくぎりが見える。部品が実装され一通りのテストが終わったら「じゃあ、飲みに行こうか」と言える。

しかし、ソフトウェア開発の場合、工程の区切りが曖昧なので、「ソフトウェア開発計画が完成したから一区切りついた」とか、「ソフトウェア要求仕様ができあがったので飲みに行こう」という感じにはなかなかならない。ソフトウェア開発の工程で区切りが明確に分かるのはソフトウェアをリリースするときだけなのだろうか。

ソフトウェア開発の上流工程は特に少数の技術者、場合によってはひとりの技術者の作業に集約されてしまうことが多いから達成感や区切りが見えにくい。

ソフトウェア開発の工程の区切りを見るのに一番分かりやすいのが、アウトプットとなるドキュメントの完成だ。ソフトウェア開発計画工程のアウトプットとしてソフトウェア開発計画書、ソフトウェア要求分析工程のアウトプットとしてソフトウェア要求仕様書を作成する。これらのドキュメントが完成したことで工程の区切りを判断することができる。

ところが、これらのドキュメントで明確に分かるのは書類があるかないかであって、その工程内で実施すべきアクティビティがキチンと実施されたのかどうかはドキュメントの中身を精査したり、プロジェクトにインタビューしたりしないとわからない。電気設計のように「回路図がを出図した！」とか「実装されたプリント基板が動いた！」というほど工程が完了したというインパクトがない。

ソフトウェア開発の場合、悲しいかなドキュメントの中身をキチンとレビューできるレビューワーがいないと、各工程でやるべきことが実施されたかどうかも分からない。工程の区切りが明確でなく、工程のアウトプットドキュメントをきちんレビューできないと、結果としてぐだぐだになってしまりのない開発になる。

しまりがないというのは、計画通りにプロジェクトを進めるとか、ここから先は要求仕様の変更はしないとか、アーキテクチャは大幅に変更しないとかいった判断ができず、プロジェクトリーダーやプロジェクトメンバの個人的な判断、個人的な折衝力で、変更要求をはね返したり、プロジェクトの舵取りをしなければいけない状態のことだ。

ソフトウェアプロジェクトの内外から「ソフトウェアはいつでも変更できる」と見られていると、変更がソフトウェアシステムに与える影響を考えずに開発工程の後半であっても、プロジェクトは変更要求を受け入れてしまう。

複雑な仕事を成し遂げるには、当然のごとく最初の段取りをしっかりしておかないといけないが、開発工程の最初の方がぐだぐだのプロジェクトは開発の後工程で相当苦労する。

日本の組込みソフトウェア開発では、20年も30年も前は、もともと明確な「プロセス」を設定して、ひとつずつ前に進む仕事の進め方ではなく、試行錯誤でソフトウェアを作成し、プロトタイプを動かしてみて問題があったらすぐ直すという作り方をしてきてその進め方が体に染みついているので、にわかルールで開発プロセスが定めてもすぐに形骸化してぐだぐだの開発になりがちだ。

メインフレームのソフトウェア開発の世界では、ソフトウェアの規模と複雑性が限界を超えた時点で、試行錯誤的なやり方では開発が完了しないことがわかり、プロセスアプローチの重要性が認識された。

組込みソフトウェア開発の世界では、ソフトウェアの規模と複雑性が限界を超えていない開発が多いので、まだ、試行錯誤的なやり方では開発が完了しないという事態にまでは至っていないのではないだろうか。

そして、日本ではそんなぐだぐだな開発プロジェクトがたくさんあるはずなのになんだかんだいって製品はちゃんとリリースされていく。

おそらく、ギリギリのところで破綻していない理由は開発の前工程がぐだぐだでも、後工程で残業してがんばってなんとかつじつま合わせているのだと思う。表面的には破綻していないように見えて、プロジェクトメンバーの中には倒れている者もいるかもしれない。

このぐだぐだの先の見えない開発スタイルの流れはこのブログでも何度となく言っているように実際に開発に関わっている技術者が幸せになる目がない。毎回、前工程ぐだぐだで後工程でがんばるというやり方を繰り返していると、ソフトウェアの規模が増大し複雑化していくので、後工程でがんばる部分の負担がどんどん増えていく。

開発を重ねるたびに楽になっていくとか、クリエイティブなことを考える時間が増えるとかいった感じがしない。自分が不思議なのはこの悪循環な状況を改善したいと考える、もしくは、改善しなければ自分たちに明日はないと考える組込みソフトエンジニアが驚くほど少ないということだ。

なぜ、少ないのかはいろいろ理由があると思うが一番大きな理由は、このままではダメだと思っても状況を改善するには各方面に働きかけをしないといけない、人間系の壁を動かさないといけない、自分たちはソフトウェアを作るのは好きだけれど、人を動かすのは得意じゃないし面倒だと考えいるからではないだろうか。または、改善をして開発が楽になるというイメージを想像することができないのか。

自分が考える「開発を重ねるたびに楽になっていく開発」「クリエイティブなことを考える時間が増える開発」とは、その製品や製品群の価値が凝縮されているソフトウェア資産を明確にし、その資産の完成度を高めて再利用し、再利用資産を徐々に積み重ねていく開発だ。

これは一回の開発ではうまくいかない。何回か開発を重ねていくたびに徐々に楽になっていく。そして、再利用資産を抽出して隔離するときが一番時間も工数もかかる。だから、約三回の開発を経て効果がでることをプロジェクトの内外に説明して納得してもらう必要がある。

ぐだぐだの開発から抜け出せない理由は、複数の開発という長期レンジの視点を組織上位層もプロジェクトも持てていないのと、「最初は時間がかかるが、次かその次には開発効率とソフトウェア品質は確実に改善する」と宣言する自信とか気迫がないからだと思う。

組込みソフト開発の現状を打開するには、複数回の製品開発のプランとソフトウェア開発の技術の修得と変革を宣言して実行するリーダーシップのすべてが必要となる。
　

2007-12-08

日本の組込みソフトウェア開発はこうすればよい

あるセミナーで、アメリカの有名企業が採用するような学生は、学生時代に『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』を教科書として学んでいるという話を聞いた。『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』は650ページの分厚い本で日本語版は7980円である。

セミナーの講師曰く、学生もこの本をすべて頭の中にたたき込んでいるのではなく、どこに何が書いてあるのかを知っており、必要なときに参照するのだそうだ。

そういえば、ソフトウェア系の海外規格を見ているとソフトウェアの開発計画を立てる際に、どんな方法論(Methodology)を使うのか書く欄があったりする。日本の組込みソフトウェア開発を始める前に、どんな方法論を使うのか？と聞かれて即答できるプロジェクトはいくつあるのだろうか。

欧米の企業がソフトウェアを開発する際にソフトウェア工学の知識・スキルを持ったものを採用し、基本的なソフトウェア開発の方法論を知っているという前提なら、ソフトウェア開発計画を立てる際にどんな方法論を使うのかという質問をするのは理解できる。以前書いた「インドのソフト会社」のときも同じように、ソフトウェアの開発者は基本的なソフトウェア工学の知識を身につけているというようなことを言っていた。

日本でもソフトウェアを開発する技術者は『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』を熟読しろとは言わないが、ソフトウェア工学にはどんな方法論があるのかくらいは知っておいた方がよいのだろう。

でも、今回の記事のテーマは日本のすべてのソフトウェアエンジニアがソフトウェア工学の知識を身につける必要があるという主張を否定するところから始まる。

アメリカの一流企業では学生時代からソフトウェア工学の知識を見つけているという話を聞いたときに、欧米のソフトウェアエンジニアはソフトウェア工学の基礎知識くらいは誰もが身につけている、日本の技術者は不勉強で、その不勉強さがソフトウェア品質の問題を引き起こしていると言われているように感じた。

確かにそういう面もあるだろう。しかし、そこで疑問に思ったのは、「それでは、なぜ、日本の組込み機器のソフトウェア品質は平均的にどれも高いのか？」という点だ。欧米の組込み機器を使う機会はそれほど多くないが、一般的な評価として日本の組込みソフトの品質は高く、欧米や他のアジア諸国で作られた組込みソフトの品質には当たり外れがあるということをよく聞く。

このことについて、自分は何年も「なぜだろう」と考え続けている。何となく確信が膨らんでいるのは、そこには国民性や技術者の気質が関係しており、そこに差がある以上、欧米で効果を上げているソフトウェア工学の方法論を日本にそのまま適用しても同じような効果が得られるとは限らないと考えている。

欧米と日本で何が違うのか、どんな気質の違いがあるのか、何をどうテーラリングすれば欧米で成功したといわれるソフトウェア工学が日本の組込みソフトウェア開発にも役に立つのか？

ここにひとつの仮説がある。日本のエンジニアは自分の失敗、ミスを恥と感じる。だから、自分が作ったソフトウェアに問題があると分かると、それを恥と感じすぐに直す。これは、個人だけの話ではなく、仲間が起こした問題であってもそれをプロジェクトの問題であると感じ、プロジェクトや製品の信頼を回復するために寝食を忘れて問題の解決にあたる。

また、日本の消費者は非常に品質にうるさい。品質が悪い状態を決して許さない。食品の原材料の表記の順番が間違っていただけで自主回収する。消費者が製品の品質に対して敏感であり、問題が発覚するとその問題を自分やプロジェクトの恥と考え、自分の都合は横に置いてユーザーの信頼を回復しようとする。

この性質は日本特有のものであり、欧米や他のアジア諸国にはないと仮定する。すると、この性質が組込みソフトの品質を高めるケースと、逆に品質を低下させるケースが見えてくる。

－日本に特有の条件が組込みソフトの品質を高めるケース－

ソフトウェアの規模が小さい（10万行以下）の場合。ソフトウェア工学や方法論を使わずに試行錯誤で作ったとしても、問題が発覚した後の修正のスピードが速く、すべてのエンジニアがどんなに残業しても何とか納期と品質を守ろうとするため、リリースしたソフトウェアの品質が高い。また、フィールドで問題が起こってもすぐに修正し対応を終えるため、リリースしてから時間が経過するほど安定性が増す。

おそらく日本の組込みソフトはほとんどがこのパターンだったのだと思う。問題が発生してもすぐに直すので問題は大きくならず、対応を早くすることでエンドユーザーの信頼も上がる。

このような10万行以下のソフトウェア規模の場合、冒頭で紹介した『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』を読まなくても、何か起こったらすぐ直せば問題を解決できるのだ。ただ、「修正が別の不具合を生む」危険性はある。問題が起こるとすぐに直してしまうので、別の不具合を引き起こしてしまう可能性が高い。

だから、日本の組込みソフト開発では、ソフトウェア構成管理や変更管理、レグレッションテストがソフトウェア品質の劣化防止に役立つ。これらの方法論はもちろん、基本的なソフトウェア工学の教科書に載っているが、ソフトウェア設計の方法論を使わなくてもソフトウェア品質が保つには、問題が発生したときの対応のスピードが早くして、かつ、修正が他の問題を起こさないことに注力を注ぐとよい。

でも、こんなソフトウェアの作り方はソフトウェア工学の基礎を学んできた人にとっては、理解しがたいと思う。試行錯誤で作って問題が発生したらさっさと直す。こんなのソフトウェアエンジニアリングじゃないといわれれば「その通り」というしかない。でも、できあがった組込みソフト製品の品質を見れば、そんな作り方したソフトウェア製品の方が、機能や性能が最適化され品質もよかったりする。

－日本に特有の条件が組込みソフトの品質を低下させるケース－

ソフトウェアプロジェクトやソフトウェア自体の規模が30人、30万行を越えてくると、発生した不具合が複数の人間のサブシステム、モジュールにまたがることが多くなる。一人のエンジニアでは問題の解決を帰結できなくなる。こうなるととたんに日本特有のエンジニア気質はソフトウェア品質の劣化防止に対して機能しなくなる。自分のパートの不具合はすぐに直すが、他人のパートの不具合かもしれない場合、積極的にその指摘をしない。たとえ、他人のパートの不具合であることという確信があっても、その技術者に「恥をかかせるかもしれない」という心理がはたらくからだ。

また、ソフトウェアも30万行を越えてくると、ソフトウェアシステムの設計図がないとさすがに一人のアーキテクトではシステム全体を把握しきれない。問題を起こったときにどこを調べればよいのか分からないこともある。

30人、30万行を超えるソフトウェアプロジェクト、ソフトウェアシステムでは、問題が起こったらすぐに直すというアプローチだけでは、ソフトウェアの品質を保つことができない。もし、かろうじてソフトウェア品質を保てているのなら、それは何かあったらすぐ直すというアプローチを徹夜してでも繰り返して納期に間に間に合わせているだけだ。単純な修正アプローチを時間をかけ繰り返すことで、力ずくで収束させようとしている。

ちなみに、この作り方はソフトウェアを付け足し続ける、ソフトウェアを修正し続けるため、機能ばかりたくさんあってコンセプトが不明確な商品になることが多い。最初からソフトウェアシステムのコンセプトを明確にして着手していないのだから、ソフトウェアの付け足しでシステムの規模が大きくなれば、商品コンセプトがぼけてくるのは当たり前といえば当たり前だ。

－じゃあ、どうすればいい？－

今後、日本の組込みソフトウェア開発は30人、30万行を超えるプロジェクトが多くなるだろう。日本人のエンジニア全員が品質に対する意識が高く、問題が起こったときに素早く対応しする特長を活かしながら、ソフトウェアの大規模、複雑化に対応するにはどうすればいいか、ここでアイディアを提言しておこうと思う。

【日本の組込みソフトウェア開発はこうすればよい】

まず、ソフトウェア開発のプロジェクトをグループ分けし、ひとつのグループが10万行以下になるようにする。そして、それぞれのグループの開発ソフトウェアの責務を明確にする。

そのこころは、問題が発覚したときの修正のスピードが早いことが日本のエンジニアの特長なら、問題が発覚したときにどのサブシステムの問題か一発で分かるような機能分割をしておき、そのサブシステムを作ったグループをすぐに特定して問題の解決に当たらせるためだ。少人数のグループで他のサブシステムにまたがった不具合でなければ修正のスピードは速いはずだ。

次に、システムをサブシステムに分割するときに、その商品の価値が凝縮されている部分をくくり出し、このサブシステムを開発、保守するメンバには優秀な技術者をアサインする。

この方法で注意しなければいけないのは、サブシステムとサブシステムのインタフェースの明確化と、サブシステム間のインタフェースは簡単に修正してはいけないという点だ。日本人の特長である、問題が発覚したらすぐに修正するという習性には、修正していいところと簡単に修正してはいけないところの明確な区別がない場合が多い。サブシステム間のインタフェースまで簡単に修正してしまったら、大規模システムを責務のあるサブシステムに分けた意味がない。サブシステム間のインタフェースの修正には、その修正の妥当性を確認する工程を設け、簡単には実施できないようにする必要がある。

また、システムをサブシステムに分割する役目は優秀なアーキテクトが行うとして、きれいにサブシステムが責務に分かれたとしても、インターフェースのオーバーヘッドが大きくなって製品に求められる性能要件が満たせなくなる危険性はある。

この問題の解決方法は、『組込みプレス vol.8 』の特集1 Part 2 の再利用資産の抽出法を読んでいただきたい。すでに、製品に求められている市場要求を分析し、すでに実現できているソフトウェアシステムの構造をマッピングして、製品の価値が凝縮されている重要なソフトウェア資産を抽出する方法を解説している。

「じゃあ、どうすればいい」のエッセンスをまとめると次のようになる。

製品に求められる要求品質とすでに実現しているソフトウェアシステムの構造を分析して、ソフトウェア再利用資産を抽出しておく。
抽出したソフトウェア再利用資産をベースに、システムをサブシステムに分割し、ひとつのサブシステムの規模が10万行以下になるようにする。
10万行以下のサブシステムに対して、特定の技術者をアサインする。
サブシステムの重要度に応じて、優秀な技術者をアサインする。
システムのアーキテクチャとサブシステム間のインタフェースは簡単に変更してはいけないことを、プロジェクトメンバ全員に伝える。

上記のアプローチで欧米のソフトウェア開発のメソッドにない点は、すでにあるソフトウェアシステムのアーキテクチャを分析するというリバースエンジニアリングが先頭にある点と、サブシステムを分割するだけでなく、そのサブシステムを開発するエンジニアも固定すべしと主張している点だ。

このアプローチでは、ソフトウェア工学を熟知している必要があるのは、極端に言えばアーキテクトだけでよい。ただ、アーキテクトは一般的なソフトウェア工学だけでなく、市場要求の内容や製品に求められる機能要件と性能要件も熟知している必要がある。

したがって、今、日本に求められるのはその業務ドメイン、製品群を取り巻く環境、ハードソフト合わせた要求の実現手段を知っているアーキテクトを育て、そのアーキテクトにシステムのアーキテクチャとサブシステムの分割を行わせ、サブシステムを担当する技術者を特定してしまうことだ。

以前、トヨタのソフト戦略の記事を書いたときにECUの統合戦略が危ない方向に向かっているのではないかと思ったのは今思い返せば、統合すればするほどサブシステムと技術者がセットになって他のサブシステムと切れているという一体感が薄れることが、日本の技術者の気質に合っていないのではないかと感じたからだと思う。

P.S.

図らずも、一般のエンジニアはソフトウェア工学を学ばなくてもよいような論調になってしまったが、決してそう主張したいのではない。自分自身 SESSAMEやEEBOFに参加して2003年頃から相当ソフトウェア工学を勉強したつもりだ。でも、2003年以前15年以上に渡って、自分の業務ドメインに関する領域でどんなやり方が最もふさわしいか考え続けたことが、最適なソフトウェアアーキテクチャの構築に貢献したように思う。

この記事で言いたいのは、もしも、現在組込みソフトウェア開発の品質で大きな問題が発生しているのなら、日本の技術者の特性をよく考えて、いま上手くいっているところがどこなのかをおさえた上で、欧米で培われたソフトウェア工学の方法論を適用するべきだということである。日本の技術者の特性を考えれば、まずはボトムアップの視点で役に立ちそうなものに着目し、その一方で今回の記事に書いたようなトップダウンで改善すべき点を探るのが効果的だと思うということである。
　

2007-11-26

組込みソフト開発失敗の見分け方

大規模組込みソフト開発で開発が失敗する可能性が高いかどうかを見分ける方法を見つけた。

このブログでは何度となく、日本の組込みソフト開発は試行錯誤的だと書いてきたが、試行錯誤的なアプローチが必ず開発の失敗に結びつくわけではない。

要素技術の検討や、小規模なソフトウェアの開発では試行錯誤的なアプローチは必要だ。試行錯誤的アプローチが失敗するのは10万行を超える中規模以上のソフトウェア開発の場合だ。そして、ソフトウェア開発が失敗しそうかどうかを見分けるには、ソフトウェアプロジェクトリーダーかソフトウェアアーキテクトに相当するエンジニアにその製品に求められている要求は何か？と聞いて、さらっと答えられるかどうかで判断する。

試行錯誤的なアプローチで付け足し付け足しを重ねて組込みソフトを作っていくと、ソフトウェアの Specification は答えられても、Requirements は答えられなくなる。

ソフトウェアが巨大になればなるほど、ユーザーにとってはっきりいってどうでもいい機能、いや、すべてのユーザーがその商品に求める根源的な機能以外の機能がどんどん入ってくる。機能を付け足し続けていると、だんだん、ソフトウェアエンジニアは機能や性能にプライオリティを付けられなくなってくる。

この状態に陥ると、声の大きな一部のユーザやステークホルダや、独裁的なプロジェクトリーダに「重要だ」と言われた機能や性能の優先度が上がり、彼らの意見がころころ変わると、それに呼応するようにソフトウェアプロジェクトは右往左往する。

日本の組込みソフトエンジニアは、ソフトウェア開発の上流工程で仕様（Specification）は定義できても、要求（Requirements）を定義するのが下手だ。

規模の小さいソフトウェアでは仕様（Specification）は要求（Requirements）とイコールになることが多いが規模が大きくなってくると、仕様（Specification）と要求（Requirements）は必ずしもイコールではなくなってくる。

仕様（Specification）は開発者サイドの視点で決まるものだが、要求（Requirements）はユーザーサイドの視点で分析するものだ。大規模ソフトウェアには必ずしも強いユーザー要求（Requirements）ではない仕様（Specification）が少なからず紛れ込んでくる。

大規模組込みソフトを完璧なまでに検証するには無限に時間がかかる。だから、ソフトウェアの検証、妥当性確認のステージでは、ユーザー要求（Requirements）が満たされているかどうかを最優先で確認するべきだ。仕様（Specification）を満たしているかどうかを検証しているといくら時間があっても足りないが、ユーザー要求（Requirements）が満たされているかどうかを確認する時間は有限なはずだ。

仕様（Specification）と要求（Requirements）を区別できていない組込みソフトウェア開発プロジェクトは失敗する確率が高いと考えるのはそういった理由からだ。いまある組込みソフトの仕様をそぎ落としていって最後に残るもの（=Requirements）は何かと聞いてみて答えられないようなら、製品開発の途上であってもその製品に求められる要求は何かを今一度分析してみることをお勧めする。
　

2007-11-18

組込みソフトウェアに求められる安全対策

翔泳社さんが「組込みZine 」という情報サイトを立ち上げた。そちらに、『組込みソフトウェアに求められる安全対策』という記事を書いたので今回はそれを読んでいただきたい。この記事は第一回から第四回に分かれており、第一回目は「組込みソフトウェアに求められる安全対策」というテーマになっている。

さて、先日 ET2007の特別講演で、工学院大学グローバルエンジニアリング学部教授畑村洋太郎氏の「危険学のすすめ」の講演を聴いた。

畑村先生はシンドラーのエレベータの事故の状況を現地までいって調べたそうで、その話を聞いてシンドラーのエレベータの事故でソフトウェアは関係していないかもしれないことが分かった。

事故現場のエレベータのブレーキは車のブレーキのように動いているものを止めるのではなく、止まっているときのその状態をホールドする役割だったらしい。そして、エレベータはかごと釣り合いをとるために釣り合い重りがつり下がっている。この重りの重さはエレベータの最大乗員の重量の1/2である。そうするとエレベータが静止しているときにホールドするブレーキが摩耗して抑えられないときに、乗員が一人しかいないと釣り合い重りの方が重いためにゆっくりとかごが上昇する。当時、事故にあった高校生は自転車に乗ったままだったため、自転車が半分エレベータから出たところでかごが上に上がってしまい釣り合い重りの重みで体が長時間圧迫されてしまったというのだ。

こうなると、ソフトウェアは内部ではかごが止まっていると認識しているので為す術がない。畑村先生の話が事実ならば、ブレーキの摩耗はエレベータシステムにとって非常に大きいリスクとなる。点検が十分でなければどのエレベータも危ないということになってしまう。

このリスクに対する安全対策はいろいろあるが、ソフトウェアでなんとかしようと思ったら「目」となるセンサーがいる。エレベータが物理的に動いているかどうかを検出するセンサを持っていれば、CPUが認識するかごの状態と実際のかごの状態に差異がないかどうか判定できる。

なにはともあれ、エレベータのブレーキの摩耗という一次故障でかごが動いてしまうという事故を起こしてしまうのは、システムとしての安全性が低いと言わざるを得ないだろう。実際にはそんなに簡単な原因ではなく複合要因で起きた事故なのかもしれないが、事故が起きた原因を調査した結果をオープンにしてもらわなければ事故の再発防止は進まない。

このことはソフトウェアの不具合についても同じことが言える。お客さんに迷惑をかけるような事故を起こしたら、それが起きた原因を追及して再発防止の対策を立てることが重要だ。ソフトウェアの場合、たったひとこと「バグ」とか個人のミスといった原因にされやすいが、そうではなく、開発工程のどこでどんな施策をとれば同じような問題を防止できるのかといった目で見ることが大切である。
　

2007-11-12

「理想なき現実」と「現実なき理想」・・・どちらも役に立たない

「理想なき現実」と「現実なき理想」・・・どちらも役に立たない。このことばは、最近メールを交換させてもらっている、ジョイント・ノアの国広卓生さんのことばだ。まだ、実際にお会いしたことはないのだが、組込みソフト開発での苦労と実績をたっぷり積まれているとあってことばの意味が深い。

【国広卓生さんの文章から引用】

・理想なき現実・・・つまり、ソフトウエアとは「工学」である、と言う観点を全く無視してひたすら「納期」「コスト」「ビジネス」と現実路線を突っ走る考え方。

「ものづくり」に対して理念も思想もなく、単に政治的な力学だけでプロジェクトを駆動させる世界。この世界が末期的局面を迎えると、バグは「見つけるもの」ではなく「隠すもの」になります。

・現実なき理想・・・・どこかの本の受け売りや、海外から仕入れた新しい技術、あるいは教条主義的なルールの遵守で、理想だけを追いかける考え方。

　実務をしない人間が、プロセスを構築すると必ず、このタイプになります。UMLとか、アジャイル開発と言った名前をまるで呪文のように唱える人々。その結果、訳の分からぬ仕様書を作ってみたり、本業よりも報告書作成の時間が長かったり、テストの中味よりも、テスト成績表の紙の厚さが問題となったり・・・
　
本来、プロセスや手法は「手段」ですが、これが目的化してしまう現象。肝心の成果物（製品）の品質が上がるどころか、もっとひどくなります。「決めたことを守る」のは大切ですが、「守れないことを決めている」ことに歯止めがない世界

【引用終わり】

ひたすら「納期」「コスト」「ビジネス」と現実路線を突っ走る「理想なき現実」は、当事者達は夢中なので分からないかもしれないが、外側から客観的に見る、もしくは、嵐が去った後に冷静に振り返るとむなしいものだ。「理想なき現実」路線で時を過ごしてしまうと残るものがない。ただ忙しかった日々が残る。キャリアパスとしてのステップにならないから、技術リーダーにもプロジェクトマネージャにもなれない。

あえて言えば、業務ドメインの知識だけが蓄積されるのだが、「理想なき現実」からは効率化やカイゼンは生み出されないので、何回も何回も非効率な試行錯誤のアプローチを繰り返すことになる。業務ドメインの知識が豊富というだけで、プロジェクトマネージャやプロダクトマネージャになった管理者は自らの力で効率化やカイゼンを成し遂げることは難しい。だから、理想を掲げて現実に実行しようとする者をじゃましないでくれればまだいい。そのような行動が自分の成功体験の辞書にはないという理由だけで否定しまうことも少なくないので、「理想なき現実」のアプローチしか経験していないものが管理職になってしまうと問題は残る。

また、「現実なき理想」は別な意味で問題がある。国広さんが言うように「守れないことを決めている」ことに歯止めがない。別な言い方をすれば実現できないこと、実施しようとしてもメリットがないことを洗脳されたかのようにヤレと繰り返す。

では、我々はどうすればいいのか？　答えはひとつ、理想を理解した上で、何とか現実に展開する努力をするしかない。

ただ、理想を理解するというのはそんなに簡単なことではない。現実を繰り返す間に、問題点を分析しどうすればこの問題は解決できるのかを考える習慣がないと、理想はそう簡単には理解できない。それは、おそらく理想となるソフトウェア工学を体系化した先人が現実に問題にぶち当たりながら解決方法を構築していったからだろう。問題に正面から当たることもなく、すでに体系化されてしまった理想だけを理解しようとするのは難しいものだ。

別な言い方をすれば失敗の体験、失敗の引き出しと、解決の体験、解決の引き出しをいっぱい持っている技術者は、理想も理解できるし、理想を現実に展開することもできる。

失敗と解決の引き出しを増やすためには、何しろ「考える」ことが必要だ。今日作ったプログラムは本当にこれでいいのか、もっとエレガントにすることはできないか「考える」くせを付けることが大切だ。若い技術者は引き出しが増えるまでは、寝ても覚めても、もっともっとよいソフトウェアにするにはどうすればよいのか「考える」必要がある。

これと真逆の行為は、答えを探して見つかったと感じた時点で考えることをやめてしまうことだ。

時間はかかってもいいから、もっと一つのテーマに対して考えることが大事なのに、学生時代に決められた時間内に答えを見つけることばっかり訓練してきた若者は時間をかけて「考える」ことが苦手なように見える。

若いエンジニアには「理想なき現実」や「現実なき理想」にならないように、失敗と解決の引き出しを増やすべく今抱えている問題について時間をかけて深く考える習慣をつけて欲しいと思う。
　

2007-10-27

活用力がないのは大人も同じ

今年4月に小学６年生と中学３年生およそ２２０万人を対象に、国語と算数・数学の２つの教科で行われた全国学力テストの結果が報告された。

算数では左図のような地図上にある長方形と平行四辺形の２つの公園のどちらが広いかを説明させる問題の正答率が最も低く、5人に1人の18％にとどまった。単純な平行4辺形の面積を求める問題の正答率が96％だったことと比べ、基礎的な知識を日常の場面で具体的に活用する力が不足している実態が浮き彫りになっている。

公式に当てはめるだけの問題なら96%の子供が解けるが、公式をどこに使うべきか考える必要のある問題にすると正解率が18%に落ちる。

公園の問題の解法は長方形は縦×横で、平行四辺形の面積は底辺×垂直方向の高さで計算し、計算した面積を比較することなのだが、いつもは図形のすぐ脇に書いてある長さがこの問題ではちょっと遠いところに書かれている。長さを平行移動して平行四辺形の底辺と垂直方向の高さがどれに当てはまるのか考えないといけない。

この問題の点数が低い（＝活用力がない）原因は、子供にあらかじめ答えが決まっているペーパーテストばっかりやらせているからだと思う。

この公園の面積を比較する問題も、公式を使った応用問題のテストを山ほど実施すれば解けるようになるはずだ。人間の記憶のメカニズムを考えればそれはうなずける。でも、それはあくまでも記憶をたよりにした問題解決であり、記憶の引き出しの中にない問題を解決することはできない。

短い時間、たとえば90分とか、4時間とかいった限られた時間の中で、テストの点数を高くするには、早く正しい答えを見つけるしかない。この記憶にたよった問題解決方法だと問題を早く解けるようになるが、たくさんパターンを覚えなければならない。一方、記憶の引き出しにはパターンがそれほど蓄積されていなくても、対象となる問題について考えて考えて考える問題解決方法なら、時間はかかるがいろいろな問題に対応することができる。平行四辺形の面積を計算する公式を知らなくても、その公式さえ思いつくことも可能だろう。前者の記憶をたよりにしてパターンの中から正解を見つける方法だと、記憶の中に今回のパターンらしきものがないとすぐにあきらめてしまう。その問題に時間をかけているより、より多くの別の問題を解いた方がテストの点数が高くなるからだ。

これを10年以上訓練してきた子供が大人になってエンジニアになると、長期的なレンジに立った問題解決能力の低い技術者になってしまう可能性が高い。この近視眼的な問題解決しかできない、解決のパターンが記憶にないとすぐにあきらめてしまう技術者はカイゼンが苦手だ。今そこにはない正解のパターンを自らが作り上げるということができない。

大学生の場合、卒業論文や修士論文などが長い時間をかけた問題解決の練習になると思うが何しろそれ一回限りだとまったく訓練が足りない。あるテーマに対してレポート提出を要求する方法だって、1分でも早く終わらせるために google で検索してコピペで終わらせてしまう。

だからこそ、今大学の教育で見直されているのがPBL(Project Based Learning）なのだろう。プロジェクトが達成すべき目標に向かって、長い時間をかけて解決を見いだしていくという学習方法だ。

活用力が下がっているのは、簡単に言えば「考えること」が不足しているのだと思う。ひとつのテーマに対して、考えて考えて考えて、いろいろなアプローチで考えて、出した答えの根拠を明確にしていき、他の問題にも活用できるかどうかをまた考え体系化していく。この訓練が必要だ。

ちなみに、そのようなアプローチで考えを体系化した人は、その知識を論文に書いたり、書籍にしたりする。そのような人達はもれなく「考える人」である。

そして、先人の知恵であるソフトウェア工学を自分の現場に適用しようと考える技術者は、考えを体系化した人ほど「考える人」である必要はないが、そこそこ「考える人」になっていないといけない。

前述の記憶をたよりにしてパターンに当てはめることしかしない人は、先人が体系化した知恵が自分の現場の問題にピッタリ当てはまっていないとすぐにさじを投げる。そこそこ「考える人」は、先人がなぜそんなことを考えたのかを考えたりしながら、どうやって自分の現場に応用したらいいのか考えを巡らすのだ。

果たして、みなさんは常日頃簡単には答えのでない問題について考える習慣を持っているだろうか？自分は、このブログに記事を書くことでその訓練をしている。

NASAゲームという、考えを巡らすのにぴったりの問題があるので、それを紹介して今回の記事を終わりにしたい。

「月で遭難した時に何を持っていくか？」あなた達は月旅行宇宙船のメンバーです。計画では"明るい方の月面上"で迎えに来る母船とランデブーすることになってました。ところが、あなた達の乗った宇宙船が機械の故障で着陸予定地点（母船とのランデブー地点）から、"200キロメートル"離れた所に不時着してしまいました。

あなた達は損害を免れた品々のなかから、必要な物を選んで、月面上を200キロメートル移動し、母船まで辿り着かなければなりません。

と、いう中で、課題は「残された携帯可能な品々である"下の15品目"に、その必要度（重要度）に応じて順位をつけなさい。」というものです。

携帯可能な15品は次の物です。[   ]の中に優先順位を書いてください。

[    ] マッチとマッチ箱
[    ] 宇宙食（月面移動中でも摂取可能）
[    ] ナイロンのロープ15m
[    ] パラシュート（地球に帰る時に開く）　　　
[    ] ポータブルの暖房機（月面でも使用可）
[    ] 45口径のピストル2丁
[    ] 粉乳　１ケース
[    ] 100ポンドの酸素入りボンベ2個。
[    ] 月から見た星座図。
[    ] 救命いかだ　ガスボンベ付（海上へ着陸したとき使う）
[    ] 磁石のら針儀。
[    ] 5ガロンの水。（補給可能）
[    ] 発火信号（月面でも使用可）
[    ] 救急箱。（応急用のテープやビタミン剤、注射器等入り）
[    ] 太陽で作動するFMの受信機。

ちなみに、この問題は個々に考えた優先順位を複数人で付き合わせてコンセンサスを得る訓練のためのものだが、必ずしも答えが一つではない問題にたいして、いろいろなシチュエーションを考えながら自分が考えた優先順位の根拠を明確にしていくという過程は、「考える人」になる訓練にもなる。
　

2007-10-19

マーケティングと商品コンセプト

日経ビジネスオンラインに「ハンズは30年前からロングテールだった！」という和田けんじさんの記事が載っていた。

ロングテールとは簡単に言えば、それほど売れ筋ではない商品でもインターネットのようなバーチャルストアーで扱うことで、ながーい期間棚に陳列しておけば、トータルで十分に儲かるということだ。需要曲線が長い尾を引くことからロングテールと呼ばれる。

さて、和田けんじさんは16年間東急ハンズに勤めた経験から、マーケティングの考え方について記事を書いている。

【「市場調査が個性を殺す」より引用】

　企業は、市場を調査し需要を確認してから店舗を展開します。需要が存在しないところに大切な資金を投入したくありませんから、「顧客はいるのか」「利益は見込めるのか」しっかり調査します。

　しかし、大抵の企業のマーケティングの結果にそれほどの違いはありません。その結果を基本に店作りをするわけですから、名前が違うだけで、同じような品揃えの、同じようなコンセプトのお店ばかりになってしまいます。

　これでは、消費者にとって魅力のあるおお店にはなりません。

【引用終わり】

東急ハンズは言わずと知れた、売れ筋のみに固執せず、豊富かつ専門的に商品を展開する店で、現在のネット通販に見られるロングテールビジネスを30年も前から店頭でやっている。

和田けんじさんは15年前に、バス・トイレタリー用品の担当だった時、バス用品の売り上げの90％以上を占める大定番のプラスチック製の製品とは別に高価な上に使わない時は日陰干しにするなどしないと、すぐカビが生えたりヒビが入ったりする檜の風呂椅子・風呂桶・ひしゃく・石鹸台・湯かき棒を仕入れたそうだ。

プラスチックの風呂椅子が高くても2000円くらいなのに対し、檜のそれは1万円を超えていた。今でこそ、バスタイムを楽しもうという提案も珍しくないが、「オーガニックブーム」でも「癒やしブーム」でもなかった頃に、そうやすやすとは檜のバス用品は買ってもらえなかった。

売れ筋を後ろに下げて、この檜シリーズを棚の一番目につくところに陳列までしてもすぐには売れなかった。それでも、上司は、そんな売れない檜シリーズの展開をやめろとは言わなかったそうだ。

むしろ、品物の良さをすぐ理解し、慈しむように眺めては、「買っていただけた？」と目を輝かせて毎日のように聞いてきたとのこと。

そうこうするうち、次第に商品の良さが理解されるようになり、結果的には大変多くの客様にご購入いただくことができた。

当時の和田さんの考えは、プラスチックという品揃えに物足りなさを感じ、せっかくの一日のリラックスタイムを、もっと楽しんでいただきたい。何か、もうひとつお風呂に入る時間を豊かな時間にできるものはないかというものだった。

今日のブログのテーマはこの話から学ぶ「組込み機器開発のマーケティングと商品コンセプト」についてである。

和田けんじさんは「市場調査が個性を殺す」と書いているが、組込み機器開発ではものを作ることから始まるので、最初から市場で売れ筋の他社製品のマネだけすることは少ない。

多くのメーカーは（商社ではないので）商品の仕入れ方で独自性を出すのではなく、機能や性能で独自性を出すことを考えている。もっとも安易な開発手法として、市場で売れ筋の商品とまったく同じ機能でコストを安く、販売価格を下げるという戦略はあるが、その方法はアジア諸国と勝負できないし、人件費が高くなってしまった日本では利益がでないのでもう誰もやらない。

そうなると、次に考えるのが売れ筋の他社製品にプラスアルファの機能を付けて、カタログスペックで機能や性能を表にしたとき一つだけ抜きんでるようにするという作戦だ。これを繰り返し行くと同じ市場に同じような商品を投入するA社、B社、C社、D社が次々に同じことをするので、機能比較の表がどんどん長くなってくる。

この安易な商品戦略の考え方（戦略と呼べるようなものではないが・・・）は、日本の組込みソフトエンジニアに長い間習慣として染みついてしまった試行錯誤・付け足しのソフトウェア開発のスタイルにベストフィットする。

商品群を何世代にも渡って、機能を付け足し続け、ユーザークレームを払拭するように改善し続ける。この取り組みは一見顧客満足を高める方向にしか進まないように見えるが、実はそうではない。

デメリットは2つ。

ユーザーサイドのデメリットは、本当に欲しい機能以外の機能がたくさんついていて使いこなせなくなるというデメリットだ。使わない機能は放っておけばよいという考え方もあるが、使わない機能のユーザーインターフェースが本当に使いたい機能の操作を迷わせることも多々あるのでそう簡単ではない。

普通に考えれば商品に機能を追加していけばコストが高くなるはずだが、ソフトウェアで機能を追加していく場合、材料費アップにはつながらず開発費だけがアップするので、開発費のアップぶんをエンジニアのオーバーワークであらかたカバーしてしまえばメーカーサイドの痛手は少ない。

となると、メーカーサイドのデメリットは、ソフトウェア資産の再利用性の低下だろう。機能を付け足し付け足ししていくということは、すなわち明確な商品コンセプトがなく、長期的な再利用戦略がないままに最初に考えたアーキテクチャを引きずりながら、だましだまし進んでいくということになるため、結果的に再利用資産を中心に派生開発を行うことができない、もしくは難しい。

ようするに、売れ筋商品を思い浮かべてプラスアルファする、そのとき流行のデバイスを使ってみる、といったそれほど頭を使わないマーケティング、商品開発を続けていると、顧客満足も高まらない、開発効率も上がらないという悪循環の道に入り込んでいく可能性が高い。商品の外見を変えると一瞬、市場やユーザーも振り向くが、本当に使い勝手がよい商品でないと支持が長続きしない。長続きしないから、また短期間に付け足し商品を開発しようとする。

このような悪循環から脱出するには、「プラスチックという品揃えに物足りなさを感じ、せっかくの一日のリラックスタイムを、もっと楽しんでいただきたい。何か、もうひとつお風呂に入る時間を豊かな時間にできるものはないか」というユーザーサイドに立った商品コンセプトを打ち立て、そのコンセプトを開発の最初から最後まで貫くことが必要だ。

コンセプトを明確にして商品開発を行うのが得意なのは食品や生活用品の開発者だろう。商品コンセプトの善し悪しが売り上げに明確に反映するような商品の場合、自ずと商品コンセプトの重要性は開発チームに伝わる。

ところが、組込み機器、組込みソフトウェアの開発には商品開発に多くの知識・技術が必要なため、商品コンセプトよりもどうやって機能や性能を実現すべきかという方法論の方に技術者の興味が向かいがちだ。しかし、組込み機器の開発では制約条件と機能・性能とのトレードオフが必ず発生するので、商品コンセプトが明確でないと開発チームの方向性が右に左に揺れて、大きなソフトウェアの仕様変更が何回も発生してしまう。

自分のスキルを駆使して機能や性能を実現することに生き甲斐を感じている組込みソフトウェアエンジニアにとっては、右に左に揺れる仕様変更さえ「やったるぜ」と張り切って取り組む者もいるだろう。

でも、その付け足しアプローチを続けていると、開発効率は上がらず、ソフトウェア品質は下がり、ユーザーにも「使えない」商品になってしまう。

だからこそ、組込み機器開発者は「プラスチックという品揃えに物足りなさを感じ、せっかくの一日のリラックスタイムを、もっと楽しんでいただきたい。何か、もうひとつお風呂に入る時間を豊かな時間にできるものはないか」といった視点を持つべきなのだ。

残念ながら、このことはどんなソフトウェア工学の本を読んでも書いていない。（と思う）

でも、ものづくりに生き甲斐を感じたい＝組込み機器を使ってくれるユーザーの満足を高めたいという気持ちと、そのためには何をすればよいかということをよくよく考えていけば、自ずと商品コンセプトを明確に持って、ソフトウェアシステムのアーキテクチャを考え、再利用資産を何にすべきか明確にすることの重要性が分かると思う。

組込みソフトエンジニアの盲点は、技術やスキルを高めることに夢中になって、顧客満足の高い商品を作るために必要なことは何かを日々考えることを怠ってしまうことだと思う。

その危険を回避するためには、自分が作っている商品がエンドユーザーにどんな風に受け入れてもらえるだろうかということをいつも気にしていることが大事だ。そのことをいつも心に留めておくと、不思議と身につけるべき技術や迷ったときのトレードオフの選択の方向性が見えてくる。

そのドメインのエキスパートになるということは、要求を実現する技術を持つことも大事だが、自分の成果物がお客さんに喜んでもらえるはずという自信と、本当にそうだろうかかという不安と緊張の両方持ちながらものづくりに邁進することなのだと思う。

2007-10-13

顧客満足と価値

10月11日WBCフライ級タイトルマッチで内藤大介と亀田三兄弟の二男亀田大毅の試合が行われ、チャンピオンの内藤大介が初防衛を飾った。亀田大毅は試合中、頭突きやサミング（グローブの指を相手の目に入れる行為）、太ももを狙ったローブローなど反則行為を連発。12回には相手を投げるレスリング行為を2度繰り返し、計3点を減点された。

でも、この試合ファイトマネーは亀田大毅がチャンピオン内藤大介の10倍も高いのだという。悪名高き亀田親子が話題を作り興業を成功させたからだというのだ。

この話を聞いて、顧客満足と価値は必ずしも一致しないことがるのだと思った。チャンピオンの内藤大介が名も知れぬ外国人ボクサーと試合をしてもこれだけ注目を引くことはなかっただろう。悪役の亀田親子が世間の注目を集め興業として利益を生み出した。結果的に興業としては顧客満足（観客やテレビの視聴者を引きつけたという意味で）が高かった。

しかし、この試合「価値」の高い試合だっただろうか。歴史に残る名勝負だったろうか。もちろん、その答えはNOであり、後味の悪い（よい意味で）語り継がれることのない試合だった。

そう考えると、ものづくりで生きている者にとっての顧客満足は持続性のあるものでなければいけないことがわかる。一回こっきりの成功は継続的な価値につながらない。組込み製品は継続的に使われるため、買ったそのときに満足してもらっても商品を使うこむうちに「ああ、やっぱり使いにくいなあ」と思われると次にその製品群や場合によってはそのメーカーの商品すべてがその消費者に選択されない。組込みの世界では継続的な顧客満足がブランドととしての価値を生むのだと思う。

継続的な顧客満足と価値を生み出す商品開発を続けていなければ、顧客や市場に見放される羽目に合う。製造年月日を偽装した赤福しかり。
　

2007-10-08

エンジニアの品格

今回は時事ネタを2つ。

その前に、WEBブラウザでこのブログを見ている人はこのブログサイトの右上の「あなたのプロフィールは？」の投票に是非参加していただきたい。このブログサイトを最初に作ったとき、できれば読者との双方向コミュニケーションを実現したいと思っていた。でも、実際にはたまに少数の方がコメントを書いてくれるとき以外はほとんど一方向の情報発信となっている。そこで、せめてどんな人がこのブログを見てくれているのかをリサーチして、その結果を見ながら話題を変えていきたいと考えている。(Let's vote!)

【エンジニアの品格】

さて、一つめの話題。先週、時津風部屋の序ノ口力士、時太山＝当時（１７）、本名斉藤俊さん＝がけいこ後に死亡した問題で日本相撲協会が時津風親方を解雇した。

この事件でTVやラジオやインターネットでいろいろな方がコメントを寄せているが、どれにも「品格のある行動だったかどうか」という視点がないのが不思議だった。

朝青龍が出場停止になったとき、世間はあれだけ「横綱の品格」のことを話題にしておきながら、相撲部屋での親方や兄弟子達の振る舞いには品格を問わないのか？　親方や相撲部屋での力士達の行動に品格があれば、今回のような制裁と思われる行動は起こらなかったのではないだろうか。

厳しい稽古、時には竹刀で叩くような行為は力士を鍛えるための叱咤激励か、制裁行為かどっちにも取れるように思うが、叩いている方に品格があるかどうかで、強くなるための試練か、制裁行為かある程度判断できると思う。開かれた相撲部屋では近所の人たちが稽古をのぞきに来ることがしょっちゅうあるそうだ。このような相撲部屋では、近所の人たちの目が暗黙に親方や力士達の行為に品格があるかないかをチェックしていたのではないだろうか。いじめや制裁は閉鎖された空間で起こりやすい。でも、品格のある人たちであればいじめは抑えられる。

品格のない相撲部屋から品格のある横綱が誕生するとは考えにくい。もしも、それが実現したのならその横綱の品格は表面的に繕っているもののように見える。日本相撲協会は今後相撲部屋にも品格を求め、品格のない部屋は相撲の世界から去ってもらうと宣言して欲しい。そこまで言って品格を持った行動が大事だというのなら、横綱に品格を求めるという話にも自然に同意できる。強くなるまではどんな行動をしてもよく、横綱になるときだけ品格を求めるというのでは説得力がない。

似たようなシチュエーションが組込みソフトの世界にもあるように思う。組込みソフトの世界もプロジェクトリーダーの進め方によっては閉鎖された環境になりがちだ。ハードウェア出身のプロダクトマネージャからはソフトウェアの開発はブラックボックスに見えるので、ソフト屋さん達が何をやっているのかよく見えない。成果物もソースコードだけだといいのか悪いのか分からないから見る気にもならない。

かくして、ソフトウェアプロジェクトは閉鎖された空間となり、品格のないエンジニアがいじめを始めたりする。ターゲットになりやすいのは、立場上反論しにくい協力会社だ。メーカーやクライアントサイドの仕様が曖昧であることが原因で詳細仕様の勘違いやバグが発生しても悪者はソースコードを納品した協力会社の人間にされたりする。

メーカーサイドの能力のない発注者が自分自身の問題点を棚に上げて開発の遅れや品質の低下を協力会社のせいにするのを見ると、無性に腹が立つ。こういうときに「こいつはエンジニアとしての品格がない」と思う。相撲における品格と同じで、品格のあるエンジニアが他人を責めるときには、厳しい言葉であっても責められた方も周りも納得がいく。しかし、品格のないエンジニアが他人を責めるときの言葉は、誰が見てもいいわけがましく、自分の失敗を他人に押しつけているように見える。

エンジニアの品格とは、技術的な裏付けに基づいた言動・行動、長期的展望、リーダーシップ、揺るがない信念のようなものから生まれるのだと思う。自分の成果が外に見えにくいだけに、エンジニアとしての品格のある言動・行動がソフトウェアエンジニアにも求められるのだと感じる。

日本人が『あたたかい人間関係の中のやさしい一員』という特徴を持っている中で、組込みソフトエンジニアやソフトウェアプロジェクトはエンジニアとしての品格を堅持しておないと、目的を失い、ともすれば弱い者いじめをする集団と化してしまう危険性があるように思う。

日本人が欧米人のように、明確な責任と権限を持たず、曖昧な上下関係の中で、品質の高いものづくりができるのは、「あたたかい人間関係の中のやさしい一員」という気質にエンジニアとしての品格がプラスされているからではないかと感じる。

【携帯電話のソフトウェアの規模が拡大したカラクリ】

2つめの話題。ａｕブランドの携帯電話を展開するＫＤＤＩが、携帯電話機の大幅な値下げ原資となっている「販売奨励金」制度を適用しない新料金プランを導入するとのこと。

ＫＤＤＩが新プランを導入するのは、総務省が携帯各社に対し、2008年度をめどに、販売奨励金と通話料を分離し、利用者が、コスト負担を判断できる料金体系を設けることを要請したためだ。

販売奨励金の存在は前々から知っていたが、このところの各方面からの報道でその金額が4万円にもなるという話を聞いた。ようするに、2万円で売っている携帯電話の本体価格は本当は6万円、3万円の携帯電話の価格は7万円だったということだ。

この話、携帯電話を製造するメーカーから見ると自分たちは希望小売価格6万円、7万円で売って欲しいと思っている商品を、すべての消費者が、頭金2万円、3万円で残りの4万円をローン契約で買ってくれていたということになる。

本当なら店頭に表示される価格は6万円とか7万円なのに、消費者は勝手に長期ローン契約にされてあたかもメーカーの希望小売価格が2万円とか3万円かのように見せかけていたということだ。今後携帯電話のキャリア各社とも KDDI と同様に、販売奨励金をなくしたプランを出してくると思う。それによって、携帯電話の本当の価格が消費者に見えてくる。

ちなみに、自分は携帯電話がもし6万円も7万円もするものだったら、購入するかどうか悩むと思う。2万円か3万円で基本機能だけの機種を探すだろう。実際、販売奨励金をなくしていく方向に動いた場合、携帯電話の市場では安い基本機能だけの機種が増えると予想されている。

このニュースを聞いたときに、日本が携帯電話の機能が異常に多く、ソフトウェアの規模が大きかった原因は「コレだ！」と思った。

ユーザーは携帯電話の価格を表面上低く見せられていたので、価格と製品の機能とのバランスが崩れていた。高機能なものがより安価に買えるので、たいして使わない機能があってもカタログスペックで他社より上回っているものを買っていた。メーカーサイドもハイエンドの機種がバンバン売れるのでお金をかけたコマーシャルを打つことができる。それによって消費者はハイエンド機種に誘導される。

ユーザーは携帯電話のラインナップの中で高機能なハイエンド機種群を見かけ上安く買っていた（買わされていた）。通常商品ラインナップの中でハイエンド機種は高価で一番出荷台数が少ないものだが、携帯電話の場合は、ハイエンド機種の出荷台数が一番多かったということになる。

そんな状態が何年も続けば、そりゃソースコードの規模も600万も700万もいくだろう。でも、その裏には販売奨励金によって見かけ上4万円も小売価格を低くするカラクリがあった。

もしも、最初から端末の価格表示が実勢にあったものであれば、携帯電話におけるソフトウェアの規模の爆発はこれほどではなかったのではないか。携帯電話下請けソフトウェアエンジニアが女工哀史のようになることはなかったのではないだろうか。

ただ、携帯電話キャリア各社のこの作戦で、高機能な携帯電話が日本中に短期に爆発的に普及し、携帯電話が技術革新を生んだのも事実だろう。携帯電話のおかげで、高密度、大容量のバッテリや、小型振動デバイス、高精細カラー液晶などが開発されたし、ソフトウェアの世界でもオブジェクト指向設計の普及を後押ししたのではないかと思う。

でも、この異常状態がこの後解消されていけば、市場やユーザーは価格と機能のバランスを考えて携帯電話を購入するようになる。使わない機能が満載のかっこいい機種ではなく、自分の収入に見合った価格の中から必要な機能が入っている機種を購入するようになる。

携帯電話メーカーの売れ筋商品はハイエンドからミドルレンジ、ローエンドの機種に移ってくるため当然利益も減ってくる。商品群の中で共通なソフトウェアコア資産を再利用するソフトウェアプロダクトライン戦略も組織的に取り組んでいかないと利益を維持できなくなっていくだろう。

これまでカタログやCMに踊らされていた消費者は、財布の中身を気にしながら本当に自分に必要な機能は何かをじっくり考えるようになる。そして、そのニーズをいち早くくみ取ってそこにターゲットを合わせ、その機能や性能の価値に消費者が納得できる価格を付けることができたメーカーが市場で生き残るだろう。もちろん、他社にはない自分たちの得意技術をウリにできなければ差別化することはできないが・・・

そう考えると、携帯電話業界における異常なほどの技術者の残業、ソフトウェア規模の急激な拡大、人材不足は、消費者がそうとは知らずに高い携帯電話を買わされていたためだと考えられないだろうか。いびつに形成された市場が生み出した負の側面ということだ。

前にも書いたけれど、海外でNOKIAの携帯電話をレンタルしたりすると、本当に基本的な機能しか入っていないことに気がつく。いくら日本人が新しもの好きだからといって、みんながみんなこんなにたくさんの機能が付いている携帯電話を持っているのは絶対異常だと思っていたが、今回の話でその裏事情が見えてきた。

メーカーは市場と製品、機能・性能とその価値を適正に把握できないと、商売に失敗するだろうし、そこにいるエンジニアもしあわせにはなれないと思う。市場やユーザーから本当に求められているものを適正な価格（開発費）で提供するためには、エンジニアは制約条件の中で何ができるか、よーく考えなければいけない。その前提が崩れると正しい判断ができなくなり、考える能力が鈍ってくる。

ユーザーニーズと商品の価値と価格、この関係をきちんと分析できた者が、その市場で成功を収めることができるのだと思う。
　

2007-09-29

組込みソフト開発悪循環の構図

組込みソフトウェア開発の悪循環のシナリオを考えてみた。想定する具体的なシチュエーションを示してから、その問題の解決方法について考えていきたい。

【組込みソフト開発悪循環のシナリオ】

1970年代、組込み機器開発の世界で、ソフトウェアはハードウェアとハードウェアをつなぐつなぎ役だった。組込み機器にはセンサーやアクチュエータが使われ、これらをいかにうまく制御して、顧客満足の高い製品を作ることができるかどうかが組込みソフトエンジニアの腕の見せ所だった。組込みソフトエンジニアという職種は確立しておらず、エレクトロニクスの勉強をしてきた技術者がマイコンのアセンブラを覚えて制御ソフトを書いていた。ソフトウェアの規模はせいぜい1000行くらい。ソフトウェア技術者はプログラムを試行錯誤で作り、実機レベルでランダムテストを行い実機で検証をしていた。

※好循環の道を歩むソフトウェア技術者はフローチャートやブロック図を描いてソフトウェアの構造を分析していた。その程度でなんとかなるくらいの規模だった。構造化プログラミングを意識している者もいた。

1980年代、8ビット、16ビットのCPUが次々と登場し、さまざまなペリフェラルデバイスが組み込まれたワンチップマイコンを組込み機器に使うことが多くなってきた。ソフトウェアを記述する言語はC言語が主流となり、リアルタイムOSも徐々に普及しはじめ、ハードウェアエンジニアとソフトウェアエンジニアは職種を分けるようになってきた。リアルタイムOSが普及することにより、ソフトウェアエンジニアがソフトウェアをモジュールに分割することを考えなければいけなくなる。悪循環の道を歩むソフトウェア技術者は相変わらずプログラムを試行錯誤で作り、実機レベルでランダムテストを行い実機で検証をしていた。LCDなどの表示用のユーザーインタフェースデバイスも普及し、プログラムサイズは数千行くらいに増加していた。

※好循環の道を歩むソフトウェア技術者はソフトウェアの振る舞いについて分析する際に状態遷移図や状態遷移表、データの流れを考えるために構造化分析手法が使っていた。

1990年代、組込み機器におけるユーザーインタフェースは飛躍的に向上し、スタンドアロンで動くだけでなく他の機器と通信をしたり、ネットワークにつながったりするようになった。CPUも16ビット32ビット64ビットと次々に高性能なものが登場し、ソフトウェアの規模が数万行になっても処理はオーバーフローしなくなっていた。悪循環の道を歩むソフトウェア技術者はソフトウェアの規模が数万行になっても相変わらずプログラムを試行錯誤で作り、実機レベルでランダムテストをしていた。コードレビューも言葉は知っていたがプロジェクト内で習慣化するところまでには至っていなかった。ソフトウェアシステムの増大の対応策としては、過去に使ったソフトウェアの一部を流用したり、前回担当した機能を作った技術者を今回もアサインするなど、特定の技術者に役割を分担させ、その技術者を何世代もの製品開発に使い続けるというアプローチを取った。そのため、社員や協力会社の社員が担当から外れるととたんに開発の効率や品質が下がったりした。担当者を外したプロジェクトマネージャ本人もその原因がよく分かっていなかった。

ソフトウェアの規模が数十万行にもなり、複雑度が高くなって、分かりにくいバグが増えてきた。ソフトウェア開発の工程が進めば進むほど、ソフトウェア技術者の残業が増えるようになり、新しい技術を学ぶ余裕がなくなってきた。

※好循環の道を歩むソフトウェア技術者は、ソフトウェアの大規模・複雑化に対して何か手を打たなければいけないと気づきはじめ、ソフトウェアシステムをサブシステムに分割する方法や、サブシステム同士のインターフェースをきちんと決めて役割を分担するなどくふうをするようになる。

2000年代、組込み機器にも多様な要求が降りかかってきて、組込みソフトの規模も数万行から数百万行まで幅広くなってきた。規模が大きいソフトウェアシステムほどプロジェクトが遅れたり破綻したりするようになる。ソフトウェアエンジニアの残業時間はピークに達しており、月あたりの残業時間が100時間、200時間という者も増えてきた。しわ寄せは、特に下請け、孫請けの協力会社の技術者がかぶることが多く、ソフトウェア技術者になりたくないと考える若者も増えるようになる。失敗プロジェクト、開発日程の大幅遅延プロジェクトの開発スタイルと見ると、1970年代と同じプログラムを試行錯誤で作り、実機レベルでランダムテストを行い検証をしていた。設計工程の後半で発生する月に100件以上のバグのうちのいくつかは非常に分かりにくい複数のモジュールが関係する不具合であり、数日もしくは一週間以上かけないと原因がわからないようなバグであった。

2000年代になると組込み機器のユーザーインタフェースも多種多様な表現方法ができるようになり、試作品ができた後に、試作器を手にしたステークホルダーが「もっと、こういうインタフェースにしよう」などと言って大幅な仕様変更を指示することも多くなるようになった。ソフトウェアプロジェクトにおいてプロセスを切って、確認してから前に進むことの必要性を認識していない上司（1970年代の試行錯誤でソフトウェアを作っていて特に問題が起こっていなかった世代）が上にいると、ソフトウェアの変更容易性から最後の最後で右に向いていたものを左にしろなどということがあった。

ここから、『熊とワルツを』（トム・デマルコ/ティモシー・リスター）より引用

・・・約束した納期に間に合わなくてもよい、大幅に遅れてもかわまないが、その日までの間、期日に間に合いそうにもないと言ってはならないということだ。事前に失敗するかもしれないことを認めるという大罪を犯さなければ、失敗は容認される。このルールを言い換えると、遅れたことに対して後から「赦し」を請うのはかまわないが、遅れることに対して前もって「許し」を求めてはならない。

　：

このような制約があると、「選択的近視」という感染症になりやすくなることがある。この条件を突きつけられたプロジェクトでは、小さな問題しか見えない。健全なプロジェクトでは視野の真ん中に見えるようなおおきな問題がすぐそこに迫っていても、選択的近視にかかった人にはまったく見えない。

－引用終わり－

ソフトウェアプロジェクトのリーダーとメンバは、製品の開発計画を突きつけられたとき直感的に「（いままでの試行錯誤的な開発を行っていたのでは）この日程では間に合わない」と感じる。しかし、『熊とワルツを』にあるように、運がリスクを消し去ってくれるのではないかと期待している。期待するだけでリスクと正面から向かい合うことはしない。また、楽観主義（嘘をつくこと）があたりまえの環境でプロジェクトマネージャーだけが真実のリスクを話すと、「やる気がない」とか「あいつはネガティブだ」という烙印を押される。そういう環境ではその日が来るまで期日に間に合いそうにもないと言えないので、プロジェクトリーダーはダメだと分かっていても、その日まで最大限努力したというポーズを作ろうとする。メンバは組織上位層にポーズを取る必要はないが、期日に間に合わないことを知っているから、「組織は、また、無理な日程を押しつけている」と感じ、プロジェクトリーダーがかわいそうだと思いつつ残業を続ける。（あたたかい人間関係の中のやさしい一員の特徴）　そして、プロジェクトメンバは組織上位層のことを「無理な日程を押しつけるソフトウェアを理解していない人種」と考え、ソフトウェア開発の現場でどんな問題が起こっているのか説明しても無駄だと考えるようになる。

この状況においてソフトウェア開発の現場がやっていることは、1970年代と同じ「試行錯誤的開発アプローチ」だけだ。場合によっては、構造化設計をちょっとだけやっていたり、ソフトウェアの構成管理だけに力を入れている状態かもしれない。いずれにせよ、ソフトウェアの規模・複雑化の増大に対する抜本的な対応は取っていないので、日程にも間に合わないし品質も上がらない。

この状態が長く続くと、組織上位層も原因は分からないが、ソフトウェア開発に問題があることに気がついてくる。品質に関する問題でお客さんに迷惑をかけることが多くなり、開発日程についても「事前に失敗するかもしれないことを認めるという大罪を犯さなければ、失敗は容認される」とは言えなくなってくる。

そうなると問題の矛先は特定の個人や協力会社に向いてくる。「やっぱりあいつじゃダメか」とか「あそこに仕事を出したのが間違いだった」ということになり、人やソフトウェアの発注先を入れ替えたりする。しかし、試行錯誤的な開発アプローチでは、ソフトウェアシステムの機能・責務の分割と割り振りを人ベースで行っているため、人の入れ替えは開発効率や品質悪化の原因になってしまう。

かくして、組込みソフトの開発は遅れに遅れ、品質は下がり、組込みソフトエンジニアの残業は増え、職種として若者から敬遠されるようになり、優秀であればあるほど仕事が降りかかってくるようになり、中にはプレッシャーに潰れてしまう者もでてくる。労働力を補充することで状況が打開できると勘違いする組織が協力会社や派遣社員に頼るようになり、技術的にも空洞化する。

これが、組込みソフト開発悪循環のシナリオ＆構図である。

【組込みソフト開発の悪循環から抜け出す方法】

組込みソフト開発の悪循環から抜け出す方法が簡単に分かれば苦労はしないが、悪循環脱出のきっかけは特に組込みソフトの歴史や日本人の特性を考えると、「意識改革」と「技術導入」をセットで進めることが重要ではないかと最近考えている。テーマは多すぎると散漫になるので3つだけだ。

－組込みソフト開発の悪循環から抜け出すためにすべきこと－

品質文化と設計の規範の確立
価値観の一致
試行錯誤的アプローチからの脱却

<品質文化と設計の規範の確立>

組織やプロジェクトに品質文化がないとルールは形骸化し新しい方法論は難しいからイヤだと敬遠される。また、設計の規範がないと、過去に発生した問題を教訓にすることができず、プロジェクトリーダーが技術的なリーダーシップを発揮することができない。

品質文化と設計の規範の確立という「意識改革」の具体的施策の第一歩としては、ソースコードの行数を数えグラフを描いて可視化し、不具合（バグ）を紙や電子的に管理することをおすすめする。ちなみに、この2つがキチンと行われていない状態から習慣・慣習化するのはとても大変なことである。もしも、この2つがクリアできたなら、変更管理、構成管理についてできるようにしよう。

品質文化と設計の規範の確立におけるポイントは、どんな小さなことでも習慣・慣習化するまであきらめないことだ。

<価値観の一致>

次のテーマは価値観の一致だ。悪循環のシナリオに書いたように、問題は組織上位層とプロダクトマネージャ、ソフトウェアプロジェクトリーダー、プロジェクトメンバ間の間で、言葉が通じ合っていないことに原因がある。

ソフトウェア特有の言葉や環境が通じないから説明しても無駄だと感じ、上はとんちんかんな要求をし、下は無視（最初から無理だと考え思考停止）し、中間層は板挟みになって苦しんでいる。

この状態を打開するには、この三者が共通の価値観のもとに問題に正面から向き合わなければいけない。その価値観の共有は、製品に対する市場要求・ユーザー要求を実現しているソフトウェアの機能や性能が何かを可視化することで実現できると考えている。（組込みプレス vol.8 特集1 を参照のこと）

価値観の一致に対するキーワードは徹底した顧客志向だ。お客さんのため、顧客満足を高めるために○○の技術を導入したいとか、ツールを買いたいとか、教育を受けたいという主張が悪循環からの脱出につながる。

<試行錯誤的アプローチからの脱却>

21世紀になっても試行錯誤でソフトウェアを作り、ランダムテストでバグ出ししているようでは、悪循環から抜け出すことはできない。まず、そのことを認識する、意識改革しなければソフトウェア技術者としても成長が見込めない。組込みソフトの場合は黙っていてもその仕事に関わっているだけでドメインの知識が蓄積されるため、一見成長しているように錯覚することがあるが、技術的にはほとんど1970年代と変わっていないという状況もあると推測する。

試行錯誤的アプローチから脱却するためには、まずはソフトウェア開発のプロセスアプローチがなぜ必要なのかを自分の頭で考えることが必要だろう。開発の後工程で大きな仕様変更を受容してしまえば、多大な後戻りが発生し、バグを生み、日程を遅らせることくらい少し考えれば分かる。問題は、それを防ぐために工程を切って、どの工程で何をやるのか決めてそれを守ることができるかどうかだ。

開発の後工程での仕様変更を受容したり、跳ね返すためには、変わりにくい部分と変わりやすい部分を分離するソフトウェアシステムのアーキテクチャ設計が必要になる。また、ユーザーインタフェースの変更要求に対しては、商品コンセプトを明確にし、最初の計画したユーザーインタフェースがその商品コンセプトに基づいて作られていることを説明できるようになることも必要だろう。テスト技術がソフトウェア品質の向上に付け焼き刃ではなく、本質的に効いてくるのはプロセスアプローチがキチンとできるようになってからだ。

組込みソフトウェア開発の悪循環から脱出するには、意識改革と技術導入をセットで推し進める必要がある、これは本当にそうだと思う。
　

2007-09-21

ソフトウェアシステムの分割法

先日、豆蔵のコンサルタントでEEBOFのメンバーでもある井上樹さんと、ソフトウェアシステムの規模のことで話をしていた。自分はプロセスネットワークの金子龍三氏が語っていた30人、30万行以上というソフトウェアプロジェクト、ソフトウェアの規模が分岐点になるという話をしたら、井上さんも同じような別の指標を教えてくれた。

まず、プログラマが自分の作ったソフトウェアについて誰かに聞かれたとき、あのモジュールのあの関数の部分とパッと頭の中に浮かぶソフトウェアの規模はだいたい5000行くらい、そして一人のソフトウェアエンジニアがソースコードだけで保守できる範囲はせいぜい10000行くらいとのこと。また、プロジェクトチームは人数が増えてきたらチームリーダを含めた一チーム6人に分割し、プロジェクト全体では最大5～6チーム以上にはしないようにした方がよいだろうという話だった。これを超えるようならプロジェクト自体を分割して別々のプロジェクトになるようにマネージメントした方がよいのだそうだ。

井上さんの話から、プログラマのソースコードレベルでの守備範囲が10000行だとすると、1プロジェクトの限界が30人で30万行となり、冒頭の30人、30万行の話を符合する。30人、30万行の指標はソースコードレベルで把握できるレベルの限界であるというのは、ソフトウェアエンジニアの管理限界の平均値に近いのだろう。

ちなみに、プロジェクトメンバの数は簡単に数えられるが、ソフトウェアのコードの規模としてコード行数を数えるのはそれほど簡単ではない。自分の中ではソースコードの行数と言えば、コメント行や宣言文を除いた実行コード行数ということになる。実行コード行数を目視でカウントするのはあまり現実的ではない。そうなると何らかのツールを使わないとある程度正確なカウントができない。でもツールがないからといってコード行数をカウントしないとソフトウェアシステムの規模が把握できない。組込みソフトの場合、実機にアップロードするときのコードサイズをソフトウェア規模の指標にする場合もあるが、プログラミングをソフトウェアエンジニアの文章書き作業だと考えると、ソフトウェアの複雑性を計る意味ではプログラムサイズよりも実行コード行数の方が実態に近いのではないかと思う。

もしも、実行コード行数を計るツールを持っていない場合は、C,C++,java,htmlプログラムの行数を計算する C&C というフリーツールがあるので参考にしてはどうかと思う。（このツールはSESSAMEメンバーの國方さんに教えてもらった。このブログでツールを使うときは宣伝文句に惑わされるなといったことを何回も書いているが、できるエンジニアは大抵いくつかのツールを上手に使いこなしている。常にアンテナを張っているので、ツールの選び方も上手い。）

さて、30人、30万行の規模に達していないプロジェクトは何もしなくてよいのだろうか。それは、もちろんそうではない。ソフトウェアの規模が徐々に拡大して何の危機感も感じることなく試行錯誤的なアプローチで30人、30万行の規模に達してしまったら、もう身動き取れないし、その状態からソフトウェアの構造やプロジェクトを立て直すのは相当大変だと思う。

感覚的には10人、10万行くらいの規模に達したら、何かしないとまずいと感じないといけないし、その時点から対策を打っていけば、30人、30万行に達したときでも破綻することはないと予想する。そもそも組込みソフトでゼロからスクラッチで作ることはないので、一回の開発で作るソフトウェアの量はそんなに多くないと思っていると、いつの日か痛い目にあうときがくる。もともと先々のことまでよく考えずにスクラッチでソフトウェアを作っていると CPUやOSが変わったとたんに、これまで作ったソフトウェアのいろんなところに手を入れないといけなくなる。結果的にスクラッチでゼロから作り直したのと同じぐらいの時間がかかってしまうこともある。

さて、そうなると最初に考えるべきはソフトウェアシステムをどのように分割すべきかということだ。ソフトウェアシステムのモジュール分割については30年以上も前から不文律がある。それは「システム分割に際しては分割したモジュールを高凝集、疎結合にすべし」という考え方だ。

【凝集の種類】　（数字が大きくなる方がよいとされる）
暗号的凝集度プログラムを単純に分割しただけで、モジュールの機能を定義できない。または、複数の機能をあわせもつが、機能間にまったく関連はない。
論理的凝集度関連した複数の機能をもち、モジュールが呼び出されるときの引数（機能コード）で、モジュール内の１つの機能が選択、実行される。
時間的凝集度初期設定や終了設定モジュールのように、特定の時期に実行する機能をまとめたモジュール。モジュール内の機能間にあまり関連はない。
手順的凝集度複数の逐次的に実行する機能をまとめたモジュール。
連絡的凝集度手順的凝集度のうち、モジュール内の機能間にデータの関連性があるモジュール。
情報的凝集度同一のデータ構造や資源を扱う機能を１つにまとめ、機能ごとに入口点と出口点をもつモジュール。
機能的凝集度１つの機能だけからなるモジュール。
※参考文献：平成16年度　ソフトウェア開発技術者合格教本　ISBN4-7741-1882-6

組込みシステムでよく見られるのは、3の時間的凝集を意識したモジュール分割だ。リアルタイム性を重視する余り、10ms毎、100ms毎、1秒毎に起動するモジュールといった感じで時間的な視点のみでモジュールを分割する。リアルタイム性が非常に強いシステムでは当然時間的凝集を意識したモジュール分割も必要だが、ソフトウェアシステムが巨大化した場合は、時間的凝集や手順的凝集だけを意識していると移植性や保守性、再利用性が悪くなる。

巨大化したソフトウェアシステムに立ち向かうには、機能的凝集の考え方が必要であり、責務ごとにモジュールを分割する必要がある。システム全体を責務に分割し、機能的凝集に成功すると分割したモジュールの内部でやっていることについて、モジュールの外部は意識する必要がなくなり、そのモジュールが外部に対して公開しているサービスについてのみ考えればよくなる。ようするにシステムの上位層から見たときにモジュール内部の（不要な）データや処理を隠蔽していかないと、システム全体を把握することが難しくなる。人間が一度に把握できる構造には限界があるので階層的にソフトウェアシステムを眺めていくには、機能的凝集のモジュール分割、責務に基づいたモジュール分割が必要になる。

このようなモジュール分割の考え方は、ビジネス系でオブジェクト指向設計を行う際には普通に行われていると思うが、組込み系のシステムで制約条件のことに考慮せずに機能的凝集のことだけ考えてモジュール分割を行っていると、リアルタイム性やメモリ容量、CPUパフォーマンスをクリアできない場合もあるから注意が必要だ。だから、『組込みソフトエンジニアを極める』では、第1章で時間分割のハードルを越える第2章で機能分割のハードルを越えるといった順番で、時間分割、機能分割の考え方を書いた。

だから10万行を超えた組込みソフトウェアシステムでは、いろいろな凝集についての考え方があることをきちんと理解しながら、トップダウンの視点（機能分割）とボトムアップの視点（時間分割）の両方の視点でシステムを眺めることが大事だ。組込みソフトエンジニアは機能分割と時間分割の最良のバランスポイントを見つけなければいけない。

次に、結合の種類 6種類を挙げておく。ちなみに、この分類は最初に提唱したのは、G.J. マイヤーズだと思う。

【結合の種類】　（数字が大きくなる方がよいとされる）
内容結合絶対番地を用いて直接相手モジュールを参照したり、相手モジュールに直接分岐する。
共有結合共通領域（グローバル領域）に定義されたデータを参照する。
外部結合必要なデータだけを外部宣言し、ほかのモジュールから参照を許可し共有する。
制御結合機能コードなど、モジュールを制御する要素を引数として相手モジュールに渡し、モジュールの機能や実行を制御する。モジュール凝集度の論理的凝集度がこれに相当する。
スタンプ結合相手モジュールで、構造体データ（レコード）の一部を使用する場合でも、構造体データすべてを引数として相手モジュールに渡す。
データ結合相手モジュールをブラックボックスとして扱い、必要なデータだけを引数として渡す。
※参考文献：平成16年度　ソフトウェア開発技術者合格教本　ISBN4-7741-1882-6

G.J. マイヤーズがこの6つの結合を分類したのは30年以上前のことだ。だから、この結合の分類はC言語ならば関数と関数の結合といった関係のことしか書かれていない。オブジェクト指向設計で考慮の対象になる、結合の方向性（結合の方向性は一方向にした方が結合度が低い）については考えられていない。

何はともあれ、巨大化してしまったソフトウェアシステムは何らかの視点でシステムを分割していかないとすぐに手に負えなくなる。何らかの視点の何らかの部分は組織や商品やプロジェクトによって異なるのだか、多くの場合は機能的な分割をベースに、時間的分割を考慮する方法がセオリーになると思われる。

また、データの取り扱いが重要とされるシステムでは、プレゼンテーションレイヤー、ドメインレイヤー、データソースレイヤーといったレイヤリングの分割視点が有効な場合もある。

さらに、商品に求められる価値をQFD（品質機能展開）で分析して、その要求・価値を実現する機能や性能をモジュールとして括りだすという視点もある。

どっちにしても、大規模・複雑化した組込みソフトウェアシステムでは、どんな視点でシステムを分割するかといった戦略（＝アーキテクチャ）が、製品の開発を効率化し、信頼性や安全性を高めるカギとなるのは間違いない。
　

2007-09-17

理系白書から考えるソフトウェア工学（つづき）

『理系白書から考えるソフトウェア工学』の記事のつづき。ソフトウェア工学が自然科学で証明できるものでなく、先人の知恵を体系化したものであるならば、ソフトウェア工学を現場で普及、適用させようとする人々は、ソフトウェア工学が現場にもたらす効果や組織への貢献について丁寧に説明しなければならない。

正しいか、正しくないかではない。現場にどんな効果をもたらすか、組織にどんな貢献をするのかがキチンと説明できないといけない。

今、自民党の総裁選挙のまっただ中だが、新しいソフトウェア開発手法や検証技術を現場で普及させようとしている人は政治家と似たところがあると思った。

政治家は政策を国民に説明し理解を求める。政策がより多く支持された方が選ばれる（べきだ）。これが、その人の人柄とか人気とか風貌とかで支持してしまうと、最初はよくても後で問題になることが多い。

自然科学のように効果効能の是非を白黒付けることが難しいソフトウェアの世界では、ソフトウェア工学をいかに現場の技術者が理解できることばで説明し、習慣づけるところまで持って行けるかどうかがカギとなる。そのときの流行とか有名な人がいいと言っているとか、あの企業が採用したからという持って行き方は、人・者・金を動かす権限を握っているハードウェア出身の組織上位層には使ってもいいかもしれないが、現場のエンジニアには使わないほうがいい。（そういうステークホルダの人たちとは提案する施策に対する価値観を共有できるようにしたい）

物理や化学の方法論の場合、その方法論の効果はやろうと思えばその場で実験できる。環境さえ整えればいつでも再現できるのが自然科学の強みだ。でも、ソフトウェア工学は人が相手なので、どんなに著名な人が提唱した方法論でも、どんなに参照回数の多い論文でも、目の前にいるプロジェクトで効果を発揮するかどうかはわからない。（もちろん、多くのプロジェクトが取り入れて成功した方法論は成功の確率が高い）

そう考えると、ソフトウェア工学の適用を現場に説明する際に一番大事なのは「いま、このプロジェクトに足らないものは何か」「なぜ、それが必要なのか」「これを適用するとこのプロジェクトにどんな効果をもたらすのか」を説明することだと思う。そして、その方法論をプロジェクトに適用し、何らかの形で効果を計測しなければいけない。やりっぱなしではいけない。だから、ソフトウェアの世界で小さいながらも組織やプロジェクトでイノベーションを起こしたいと考えている人は、適用しようとしている方法論についてまず、考えて、考えて、考えて、考えて、理解して、説明できるようになることが大事だ。間違っても、ツール屋さんの宣伝文句を右から左に流してはいけない。

プロジェクトマネージャとして経験を積んでいる方やソフトウェアプロジェクトを支援している組織内外のコンサルタントの方達に話を聞くと、みな「現場に方法論を押しつけてはいけない」「納得させながら一歩一歩進むことが大事」という。

開発現場からプロジェクトを支援する立場に移ると何かとイライラすることが多い。自分が主導権を持ってやっていたときの時間の流れ方とプロジェクトを側面から支援して必要なことをやってもらうときの時間の流れ方がまったく違う。プロジェクトマネージメントのベテランは過去を振り返ると、最初は自分の経験をベースにあれやれこれやれと現場に支援・指導するのだが、しばらくするとそれではうまくいかないことに気づくという。現場が「今のままではまずい、新しい何かが必要だ」と感じさせることがまずは大事だというのだ。

このことがよく分かっていなかったころ、『ここが変だよ日本の管理職』や『日本人はリスクを表に出すのが嫌い？』といった記事で、現場のプロジェクトマネージャやプロジェクトメンバの問題点について愚痴を書いていた。しかし、問題点は問題点として、今後もその状況ではまずいということを自分だけでなく現場にも気づいてもらわなければいけないし、そうしないとカイゼンは進まない。

『ここが変だよ日本の管理職』的な考え方は、ひとつは欧米的にトップダウンでカイゼンを推し進めることができないのかという問いかけなのだが、日本人は『アメリカ人と日本人』の記事で書いたように「あたたかい人間関係の中のやさしい一員」的気質であるため、もともと『ここが変だよ日本の管理職』的な進め方がうまくいきにくい環境なんだと思う。だから、カイゼンが早く進まないことに対してブツブツと愚痴をこぼし、プロジェクトマネージャのふがいなさを嘆くのではなく、ほんの少しでもプロジェクトが今とは違うカイゼンの一歩を踏み出す方策はないのかについて、何とか知恵を絞ることの方が大事だ。

このことに気がついた、というよりはそんな心境になったはプロジェクト支援の仕事をするようになって1年を過ぎたころだろうか。新しい職務に就けば誰だって早く成果を上げ、組織に貢献していることを示したいものだが、ことソフトウェアの開発効率アップとか品質向上の成果を示すのには根気もいるし時間もかかるということがだんだん分かってきた。

今現在、これは正しいといえるのは、何か新しいことをプロジェクトにやってもらいたいと思うのなら最初は大変でもできるだけ環境を整え敷居を低くして、さんざん文句を言われても「がんばれ」「効果はでてきたぞ」と現場を励ましながら、新しいことをルーチンワーク化して、結果的にその施策をプロジェクトの習慣にさせることだ。習慣になると自然と何がよくなったのかが見えてきて文句も言わなくなる。この明確な計画なしに「あたたかい人間関係の中のやさしい一員」の中で慣習化させるどちらかと言えばボトムアップ的なカイゼンこそ、日本的プロセス改善なんだと思う。

さて、ピーター・F・ドラッカーは著書『プロフェッショナルの条件』で、イノベーションの成功の条件として次の3つを挙げている。（こちらの記事も参照のこと）

【イノベーションの成功の条件】
第一に、凝りすぎてはならない。イノベーションの成果は、普通の人間が利用できるものでなければならない。多少とも大きな事業にしたいのであれば、さほど頭のよくない人たちが使ってくれなければ話にならない。つまるところは、大勢いるのは普通の人たちである。組み立て方や使い方のいずれについても、凝りすぎたイノベーションは、ほとんど確実に失敗する。
第二に、多角化してはならない。散漫になってはならない。一度に多くのことを行おうとしてはならない。これは「なすべきこと」の一つとしての的を絞ることと同義である。
第三に、未来のためにイノベーションを行おうとしてはならない。現在のために行わなければならない。たしかに、イノベーションは長期にわたって影響を与えるかもしれないし、20年たたなければ完成しないかもしれない。だが、「25年後には、大勢の高齢者がこれを必要とするようになる」というだけでは十分ではない。「これを必要とする高齢者はすでに大勢いる。もちろん時間が味方だ。25年後には、もっと大勢の高齢者がいる」と言えなければならない。
※ピーター・F・ドラッカーは著名な経済学者で『プロフェッショナルの条件』は6年間で44刷りもしている。ここでドラッカーを引用したのは自分が考えていたことと、この本に書かれていたことに共通点があり、ドラッカーを引用することで、その考え方の根拠がより広範囲に裏付けられると考えたからである。

ちなみに、ここで論じていることはとどのつまり組織成熟度と組織成熟度に応じて適用すべき適切な施策のことを言っている。それって、CMMIのことかっていうことになるが、そのとおりCMMIと同じことを言っている

CMMI（Capability Maturity Model Integration）

米カーネギーメロン大学ソフトウェア工学研究所が公表したソフトウェア開発プロセスの改善モデルとアセスメント手法であるCMM（Capability Maturity Model）に、有識者の意見や多くのプロセス改善事例を反映させて作成された新しい能力成熟度モデルのこと。

でも、日本の組織でCMMIのレベル○○を取るように頑張ろうというと、多くの場合うまくいかず、無理にごり押しするとすぐに形骸化する。形骸化する理由は、ドラッカーが言っているイノベーションの成功の条件に合っていないからであり、凝りすぎて、散漫であり、現在のための施策になっていないからだ。凝りすぎて、散漫であるというのは、すなわち CMMI のレベルが低いということになるのだが、そもそも CMMI で組織成熟度を格付けすることが、そのプロジェクトやその組織の“現在のための施策”かという点が引っかかる。（皮肉にも日本ではCMMIを受けいられるくらい組織が成熟している場合のみCMMIの効果がでる）

さらに、日本人の気質は「あたたかい人間関係の中のやさしい一員」であるため、特に格付けや監査を毛嫌いする傾向があると思う。ようするに格付けされたり、監査で重箱の隅をつつかれてカイゼンするのではなく、誰とは言わず自分たちのプロジェクトの内側から問題を解決することを望む傾向があるということだ。

そして内側からのカイゼン力が低い組織・プロジェクトに外側から格付けや監査をしようとすると、バリアを高くしてどんどん殻に閉じこもる。これが、『日本人はリスクを表に出すのが嫌い？』といった状態だ。こうなってしまった場合は外側から殻をこじ開けようとするのではなく、内側のカイゼン力を回復させてあげることに注力を注ぐべきだと思う。（『カイゼンを実現できる多能工を目指そう！』を参照のこと）

こういう場合、一番いいのはプロジェクトリーダのリーダシップで引っ張ってもらうことだが、プロジェクトメンバ全員がリーダも含めて「あたたかい人間関係の中のやさしい一員」的気質である場合は、支援者が小さなカイゼンの方法論と環境を提供し、その小さなカイゼンを自分たちのものになる（ルーチンワーク化する）までサポートしてやるといいと思う。その心は「内側からのカイゼンに対して自信を付けさせる」ということだ。

日本の製造業においてQC活動は生産品質向上に大きく貢献した。おそらく、内側からのカイゼンで組織の成熟度を高めるというやり方が、「あたたかい人間関係の中のやさしい一員」的気質にピッタリ合っていたからだと思う。CMMIも目指しているところは同じだと思うのだが、対象としているのが人間であり、その人間は地域や組織によって気質が違うということを考慮しなければいけないのだ。

ソフトウェア工学は先人の知恵を体系化したものであり、対象は人間である、だからソフトウェア工学をプロジェクトに適用するときは、凝りすぎず、散漫にならないように気をつけ、現在の問題の解決のためになることを明確にする、そして、終わってみればそのカイゼンがプロジェクト内部のエネルギーで成就したことになっていることが大事である。

ちなみに、本当にこの通りうまくいくと、そのプロジェクトは成果を内外で発表したくなる。このように成果を発表して振り返ることはその組織やプロジェクトにとって非常に大事なことであり、積極的に行うべきだ。

でも、その発表を聞いたカイゼンが進んでいないプロジェクトはこの成果を取り入れる前に、方法論採用の是非をこの記事に書いた原理原則に照らし合わせてよく考えてみる必要がある。自分のプロジェクトに対して凝りすぎていないか（難しすぎないか）、現在の問題の解決のためになっているかチェックしなければならない。

ソフトウェアにおけるカイゼンは対象が人間であるが故に、技術的な施策にも増して意識改革への取り組みが重要なことが多い。ソフトウェア工学は自然科学では証明できない部分が大きいということに着目すると、現場に対して何を支援・指導すべきかが見えてくる。

P.S.

ソフトウェアの世界でも産学の協調がよく話題になる。産学の協調でうまくいったケースとして、1960年代、1970年代の品質機能展開(QFD）の技術があったと思う。（『組込みソフトで勝ちたい人に捧ぐ』参照のこと）　企業は自分たちの製品の品質表を作成し、研究者が現場が一体となって改善点を探り、改善点をQFDの理論として体系化していった。ソフトウェアの世界では対象が人間であるため、産学連携が成功するには研究者が開発現場にどれだけ関われるかにかかっていると思う。また、研究者はある現場で成功した方法論が他の現場でもうまくいくかどうかよく考え、うまくいく根拠を明示して欲しいと思う。
　

2007-09-06

トヨタのソフト戦略

ソフトウェア品質シンポジウムの基調講演でトヨタ自動車常務役員の重松崇氏の話を聞いた。トヨタの重松氏はESECなどの組込み系、ソフトウェア系のイベントでよく講演しているのを見掛ける。

もともと重松氏はソフトウェア技術者としてのたたき上げではなく、根っからの車屋から車載ソフトウェアを任されたという経歴を持つ。では、なぜバリバリのソフトウェア技術者ではない重松氏が組込みソフトウェア系、品質系のイベントに呼ばれるのか？　それはもちろんトヨタ自動車が日本だけでなく世界的に高い業績を上げている企業であり、トヨタ式と呼ばれるハードウェアの生産方式と同じように、ソフトウェアの開発にもトヨタ式と呼ばれるものが存在し、それを真似すれば高品質のソフトウェアをアウトプットできるだろうと多くの人が期待しているからだ。

さて、重松氏は90分の講演時間のうち、半分以上を使って現在と未来の自動車に求められること（エネルギー効率のよいモビリティの追求と安全の確保）を語った。さすがだと思う。つい最近、JR のSuicaのプロジェクトを牽引した椎橋氏の話を聞いたが、椎橋氏も講演のほとんどの時間、鉄道を利用するお客さんの利便性を向上するために自分がやってきたことをとうとうと語っていた。

ようするに組込みは業務ドメインを知り尽くし、顧客要求（トヨタの場合は顧客というより地球や人類のことを考えているとのこと）を高める意志と戦略を持った者が、ソフトウェア開発のどこに力を入れればよいのかわかるということだ。（これはビジネス系のソフトも同じか）

でも、なぜ重松氏は車に特化したソフトウェア開発戦略をわざわざあっちこっちでレクチャーするのだろうか。その情報の公開はトヨタにとってどんなメリットがあるのか？　

これは予想だが、トヨタはトヨタのソフトウェア戦略を公の場でしゃべることで、トヨタ社内やサプライヤのソフトウェアエンジニアに対して自分達の考え方を浸透させたいのだと思う。トップの方針を末端まで届けたいという意志があるに違いない。それに重松氏がしゃべった内容は、すぐに日経エレクトロニクスなどに取り上げられちまたの話題となる。なぜなら、冒頭で書いたように日経エレの読者はトヨタ式のソフトウェア開発方式がすべての業務ドメインに使えるだとうと期待しているからだ。

でも、特に組込みソフトの世界ではすべてのドメインに共通して有効な解法はない。なぜなら、業務ドメインや組織によって、市場要求や得意な技術、リアルタイム性などの性能要件、メモリ、CPUパフォーマンスなどの制約条件、組織成熟度、エンジニアのスキルがバラバラだからだ。でも、ツールベンダーやプラットフォーム提供者は、必ず自分たちのソリューションがすべて組込み開発に有効であるかのように宣伝するので気をつけた方がいい。こういうのにコロッとやられてしまう鴨ネギタイプのエンジニアやマネージャは組織の中に必ずひとりやふたりはいるものだ。

さて、重松氏は自動車に搭載する約60のECU群を今後4群に減らしていくと言っていた。自動車におけるECUのプラットフォームを共通化し、ソフトウェアの連携によって多様な要求（交通インフラから上がってくる情報を使って危険回避するような要求）に対応していくそうだ。

この施策の最大のリスクは、エネルギー効率のよいモビリティの追求と安全の確保のうち「安全の確保」の方が危うくなる可能性があるという点だ。

ECUが物理的に分かれ責務分割されている状態では、各ECUが起こす不具合、バグの責任は明確で、ECU別に責務の重さやソフトウェア品質の検証のハードルの高さを変えることができた。でもECUの数が少なくなってしまうと、責務の分割や安全の重要性はソフトウェアの中を見ないと分からなくなる。アーキテクチャを可視化して、システムの安全を確保するための安全アーキテクチャが確立されていることをソフトウェアの範疇で証明しなければいけない。安全クラスの低いアプリケーションソフトがメモリリークを繰り返して、重要なソフトに影響を与えないことを証明しなければいけない。ソフトウェアは人間が作っているモノなので絶対大丈夫とは言い切れないし、誰かがちょこっとなおした1行の変更がシステムに大打撃を与える可能性も否定できない。

ECUの数を極力少なくするのなら、ソフトウェアの安全設計、安全アーキテクチャが絶対に必要だと思う。大規模・複雑化したクリティカルデバイスにおいては、安全アーキテクチャは今後重要なテーマになっていくだろう。また、プラットフォームの共通化のメリットがデメリットを上まわる自信がないといけない。組込みソフトはいろいろなトレードオフのバランスの上で顧客満足を確保しているのだ。

さて、重松氏はモデル駆動開発についてサラッと問題点を口にしたが、自分は大事なその一言を聞き逃さなかった。それは「戦略なきプラットフォームの共通化は失敗（プラットフォームベンダにいいようにやられる）する」ということばだ。

プラットフォームの共通化・モデル駆動開発ということばに踊らされて、商品の価値を高めることができるという確信がないままに、共通プラットフォームを採用してしまうと後々商品開発の基盤をプラットフォーム提供者に握られてしまうことに気がつく。重松氏はこの例として、ヨーロッパの共通規格団体 AUTOSAR が Windows を車載ソフトの共通プラットフォームとして採用する提案をしてきたので、日本の共通化団体の JasPar で使えない部分があることを証明してAUTOSARに進言したという例で語っていた。

重松氏の話を聞いていてトヨタは自前で自動車のソフトウェア全部を作り上げるつもりはないように聞こえた。サプライヤからのソフトウェア供給は今後も続くという考えのようだ。そうなると、クライアントとなる自動車メーカは難しくなっていくソフトウェアの理論についてどんどんうとくなり、サプライヤ側は自動車を取り巻く環境の詳細を把握しきれなくなる。トヨタの重松氏やJRの椎橋氏のように車や鉄道のことを知り尽くし、ソフトウェアの品質がどうあるべきかがわかる技術者がだんだんいなくなって顧客要求をよく理解しないソフトウェア技術者が作ったプログラムを自分たちの商品に実装せざるを得なくなってくると思う。

これはかなり危ない。車や鉄道の特性やリスクを知らない、意識しない技術者が作ったソフトウェアは間違いなく危ない。その機器が使われる場面においてどんな危険やリスクがあるのか知らないツールメーカのツールやプラットフォームも危ない。どうしてもそれらを使うのなら、それらが危なくないことを証明する責任は採用した側にある。それだけは忘れてはいけない。

P.S.

「トヨタはソフトウェアでもトヨタ式を提唱していくつもりなのか？」という会場からの質問（電通大のにしさんより）に対して、重松氏は「生産方式には自信があるが、ソフトウェアについてはむしろ外部の知恵（例えばソフトウェア工学で培われたプロセスアプローチなど）を取り入れていきたいというようなことを語っていた。トヨタ式ソフトウェア開発は参考にするべきもので、生産方式のように安易に真似してはいけないということだ。

Blogger のコメントは読みにくいので本文の方に入れてしまいました。

自動車エンジニアさんさんは書きました...

先日、コメントを書かせて頂きました『自動車エンジニア』です。

また、コメントさせて頂きます。

-----------------------------------
プラットフォームの共通化・モデル駆動開発ということばに踊らされて、商品の価値を高めることができるという確信がないままに、共通プラットフォームを採用してしまうと後々商品開発の基盤をプラットフォーム提供者に握られてしまうことに気がつく。
----------------------------------

確かにそのとおりだと思います。
自動車業界でいうと、モデルベース開発がMATLABという１つのツールに依存しすぎると、ツールベンダーに主導権を握られるリスク当然はあります。

実際そうなりつつありますが...
MathWorksがマイクロソフト状態にならないように、MAAB、J-MAABなんかでも、MathWorksにソフト改良への要求などを（強気に?）行って、かなり牽制しようとしてますが...

デンソーなんかは、ツールベンダーに依存しなくてよいような方向を志向しているのかどうかわかりませんが、最近はプラットフォーム環境を内製化しようとしてしいる感じは、各公演等から感じられます。
トヨタでも同じようなことは考えられているかもしれません。

----------------------------------
重松氏の話を聞いていてトヨタは自前で自動車のソフトウェア全部を作り上げるつもりはないように聞こえた。サプライヤからのソフトウェア供給は今後も続くという考えのようだ。
----------------------------------

参考までに、トヨタは自前で組み込み用のＯＳの開発を行っているようです
あくまで、メディアの情報です。

【トヨタ、「クルマＯＳ」独自開発】

【50人体制の開発組織・トヨタ正発表】

【経済産業省、車載標準OSを開発へ--トヨタや日産らが参加】

トヨタも現状は、サプライヤーにソフトの供給を依存しているかもしれませんが、もしかしたら、将来的に自前でいくことも考えているのかしれませんね。

ただ、本当の戦略？？です

-----------------------------------
これはかなり危ない。車や鉄道の特性やリスクを知らない、意識しない技術者が作ったソフトウェアは間違いなく危ない。その機器が使われる場面においてどんな危険やリスクがあるのか知らないツールメーカのツールやプラットフォームも危ない。
----------------------------------

自動車業界にいる者として、真摯にご指摘を受け止めなければなならないと思います。
現状、車メーカー側には組み込みのエキスパートは少ないように感じます。
いくつかの車メーカーはグループ内にＥＣＵメーカーをもっていて、組み込みは子会社のＥＣＵメーカーに任せて、車メーカーはシステムのアルゴリズム開発に注力するという方向かもしれませんが、それが、大問題の原因になるとのご指摘かと思います。

車メーカー：組み込みの素人、制御アルゴリズムや車両の特性には詳しく、ロジック開発のみやる
⇒どんどん、組み込みに疎くなる。
⇒【組み込み技術】と【制御ロジック/制御対象特性】の両方を把握するエンジニアがいなくなる。
システム/組み込み開発で全体を把握でる人がいなくなり、部分分のみの知識/経験しかない人だけになると絶望的になる。

さらに、自動車の特性に関する知識に疎いツールベンダーが、人命を預かって走る車において、ＥＣＵの組み込みの根幹を握るようにると、さらに怖いというご指摘かと思います。
（間違っていたらご容赦ください）

車メーカー側は組み込み技術の向上（組み込みエンジニアの育成も含めて）を真剣に考えていかなければいけなかと思います。
最後は車メーカーが全ての責任をとらなければいけませんので、組み込みＥＣＵの責任も最後は車メーカーが持たなければなりません。

私も、組み込みに関する知識不足を痛感しています。
最近、組み込み関連の本を何冊か購入して勉強していますが...

『組込みソフトエンジニアを極める』も今、読ませて頂いております！

ＥＣＵメーカーの組み込みエンジニアとも情報交換及び、今後のシステム/組み込み開発のやり方を議論する場なども定期的にもっていたりします。

----------------------------------
こういうのにコロッとやられてしまう鴨ネギタイプのエンジニアやマネージャは組織の中に必ずひとりやふたりはいるものだ。
----------------------------------
私もそんな１人ですね（笑）
ベンダーの営業トーク（いいことしか言わない）によくコロッといったりします（笑）

9月 08, 2007

sakai さんは書きました...

自動車エンジニアさん、コメントありがとうございます。

自動車エンジニアさんは本当に自動車のソフトウェア開発にお詳しいですね。

自動車のソフトウェア安全については、ISO 26262 の策定が進んでいると思いますが、ソフトウェアの安全性を分析する考え方として MISRA-SA というのもあります。

どっちにしても、ソフトウェアの安全性は電気的安全性のようにはっきりと白黒つけることは難しいので、エンジニアがどれだけ客観的な根拠・証拠をもってシステムの安全性や信頼性を証明できるかどうかにかかっていると思います。

自動車ソフトウェアの安全性は、これまでソフトウェアエンジニアがユーザーの要求や機器のメカニズムを熟知しており、どんな風に使われるのか、どんな風にハードソフトが動くのか知っていてソフトウェアを作っているということで担保されていた部分が大きかったと思いますが、これからは誰がどんなソフトウェアを作り込んでしまうか分からないという前提で、ソフトウェアの安全性や信頼性が確保されていることを客観的に示していかないといけないと思います。

モデルベース開発は安全を客観的に示すための有力な方策の一つだと思いますが、モデル変換のソフトウェアを作っているエンジニアが特に車のメカニズムを意識していない場合、意図しない洩れや抜けにより変なコードが埋め込まれてしまう可能性はあると思います。

ただ、「理系白書から考えるソフトウェア工学」で書いたように、モデルベース開発が自然科学を相手にしているうちは正しく変換できているという信頼性をVerification（検証）することは難しくないと思います。

しかし、自然科学以外のすり合わせ的ソフトウェアアーキテクチャをモデル駆動開発に取り込んでいった場合は、信頼性の証明やシステム全体のValidation（妥当性確認）は難しくなってくると予想します。

組織内部の Closed のすり合わせ的アーキテクチャ・アルゴリズムの安全性や信頼性は、そのハード・ソフトが使われる場面や要求を実現するメカニズムを熟知しているソフトウェアエンジニアの「慎重さ」「そのソフトウェアが安全を担っているという使命感」のようなものが確保していたのが本当のところでしょう。（要求通りに作られているかどうかを検証するのは Verification です）

これからは、その安全アーキテクチャ、安全ソフトウェアをカプセル化して、他の安全クラスの低いソフトウェアから隔離し、影響を受けにくいソフトウェアの構造を作っていかないといけないと思います。

これは ECUが物理的に分かれていることで責任分担され証明しやすかった状態に比べると、自信を持って「安全です」と言えるところまで持っていくのに時間も手間やソフトウェア的工夫もいるだろうと予想しています。

自分は自動車ドメインのエンジニアではありませんが、このブログでもその方策について考えていきたいと思います。

9月 08, 2007

2007-08-28

理系白書から考えるソフトウェア工学

理系白書には、何しろたくさんの研究と研究者が登場する。研究者達の苦労や待遇、評価の低さについての現状についても興味深く読んだが、自分はこの本が訴えたい内容とは別のところで考えさせられることがあった。

それは同じ理系でも自然科学と情報工学・ソフトウェア工学では、導かれた成果の性質や寿命がかなり違うのではないかということだ。

Wikipedia で「工学」を引くと冒頭に次のような定義が書いてある。

工学（こうがく、engineering）は、科学、特に自然科学の蓄積を利用して、実用的で社会の利益となるような手法・技術を発見し、製品などを発明することを主な研究目的とする学問の総称である。大半の分野では数学と物理学が基礎となる。

工学と理学の違いは、理学がある現象を目の前にしたとき「なぜそのようになるのか?」を追求するのに対して、工学は「どうしたら目指す成果に結び付けられるか」を考えることにある。

また、自然科学については、次のように書いてある。

自然科学（しぜんかがく、natural science）とは、科学的方法により一般的な法則を導き出すことで自然の成り立ちやあり方を理解し、説明・記述しようとする学問の総称。

自然科学の法則は寿命が長い。きちんと証明されると訂正されることはほとんどなく、自然科学の法則同士に矛盾も生じない。自然科学の研究の根拠となるデータがしっかりしていれば疑いの余地がないことが多い。

工学（エンジニアリング）は科学、特に自然科学の蓄積を利用して、実用的で社会の利益となるような手法・技術を発見し、製品などを発明することを主な研究目的とする学問だとすると、ソフトウェアエンジニアリングの何の科学の蓄積を利用していると言えるのだろうか？

プロセッサの構造や電気的特性にまでさかのぼれば、物理学や化学が関係してくると思うが、ソフトウェア工学がテーマとして扱っているのは自然科学から遠いところの話がほとんどではないかと、理系白書を読んで思った。ようするにソフトウェア工学が扱っている対象はなく突き詰めれば人間ではなかろうかということだ。

無理矢理自然科学に結びつけるとすれば、人間の頭の中、脳の情報処理の生化学となるのだろう。でも、脳神経の生化学的な研究と、脳の情報処理の仕組みとの関係はまだまだ解明できていないことが多く人間が考えること、考えるしくみを自然科学で十分に説明できるところまでには至っていない。（そうはいうものの『考える脳考えるコンピューター』ではかなり踏み込んでいる）

そうなると、工学が実用的で社会の利益となるような手法・技術を発見することが目的であり、ソフトウェア工学に至っては、よりどころになる自然科学の法則がほとんど使えず、思考や行動が必ずしも論理的でない人間を研究の対象にするしかないということになる。

そこで最初の疑問に戻る。自然科学で解明された法則は安定しており寿命は長いが、自然科学に立脚した説明がほとんどできないソフトウェア工学は必ずしも安定ではなく寿命もそう長くはない（例えば50年以上はもつものは本当に少ない）のではないかと思う。

今、『ソフトウェア・テスト技法』で有名なJ．マイヤーズが1978年に書いた『ソフトウェアの複合/構造化設計』という本を読んでいる。マイヤーズ自身、1974年に書いた著書で「源泉・変換・吸収（STS）型の分割法」だけを紹介していたが、4年後に書いたこの本では、STS型の分割法に加えてトランザクション分割、共通機能分割、データ構造分割といった分割法も紹介している。巨匠と呼ばれる人でさえ築き上げた方法論を何年かたつと修正したり付け足したりすることが分かる。

別な見方をすれば、ソフトウェア工学は対象となる人（エンジニア）の性質や考え方に変化がなければ、構築した法則の寿命は長い。でも、地域による人の考え方の差や気質などが異なると同じ法則が有効に働くとは限らない。もしも、同じ法則がどの地域でもどのプロジェクトでも有効に働いているように見えるのであれば、それは地域や人がその法則を受け入れた、もしくは染まっただけなのではないあろうか。

その見極めをするのは非常に難しい。自然科学がベースにないと、方法論の有効性を検証したデータの再現性は高いかどうかわからない。ある方法論をソフトウェアプロジェクトに適用してよい成果が出たとしても、デマルコが言うようにプロジェクトメンバのそれぞれが失恋して落ち込んでいたり、気になることがあって気もそぞろな状態でデータを取ったらまったく違うメトリクスになるかもしれない。

対象としているのが論理的とは言い難い人なのだからしょうがない。

そうであるなら、ソフトウェア工学は先人の知恵と考えればよいのではないか。先人が失敗したり成功したりして、失敗を繰り返さない、次は効率よく進めようと考え、編み出した先人の知恵、それがソフトウェア工学だと考えるのだ。

そう考えると、その先人の知恵が自分たちにも有効に作用するかどうかという視点で見るようになる。場合によっては、欧米発の先人の知恵は日本では有効に働かないかもしれない。民族の気質が大いに関係するようなアクティビティの実践を促しているようなものは特に気をつけなければいけない。

また、その組織やプロジェクトの気質とは少しずれがあるけれども、先人の知恵に乗っかってやりきってしまうという方法もある。やりきって成功体験となれば、自分たちの気質自体が変わってくることもある。

30年前に書かれた『ソフトウェアの複合/構造化設計』の主張が今でも当てはまるかどうか見てみよう。

「代表的なプログラムで、その構造が設計されているものはほとんどない。その構造は、コーディング途上でそれ独自の方法で作られるのが普通である。」

【コメント】未成熟なプロジェクトではそのような状況はまだ生きていると思うが、Noと言えるプロジェクトも増えてきてはいるだろう。モデル駆動開発が進めば払拭される可能性もある。

「ほとんどのプログラムは、要件とか環境の変化に対応できないようなつくりかたをされている」

【コメント】これも同じで、未成熟なプロジェクトではYESと言える。

「プログラムはほとんどの時間をまちがいを修正するために費やしている」

【コメント】またまた、これも同じで、未成熟なプロジェクトではYESと言える。

「我々は他人の成果を利用しようとはしない」

【コメント】もろ人間系の問題でその性質は今でも変わっていないと思う。

「n人のプログラマを抱えたプロジェクトは、通常、一つ一つ違ったn個の目標を持つ」

【コメント】この問題を解決するためにプロジェクトマネージメントの技術が構築されていったのだろう。

ちょっと脱線するが、30年前に J.マイヤーズの『ソフトウェアの複合/構造化設計』に書かれていることが、21世紀の現代でも未成熟なプロジェクトではほとんど当てはまるというのは一体どういうことだろう。

オリンピック記録は毎回毎回更新され、新しく生まれてきた未来のアスリート達のハードルは自分の意志とは関係なく上がっていく。（こちらの記事を参照のこと）それでもオリンピックレコードが更新されるのは、選手達の努力もさることながら用具の進化、トレーニング技術の進化があるからに違いない。

ではなぜ、ソフトウェアの世界では30年前の憂いが払拭されていないのか？　それは用具（ツール）の進化はあっても、トレーニング技術（教育）が進化していないからではないだろうか。だからこそ、SEESAMEは技術者教育のコンテンツを開発しているのだけれど、教育機関ももっと頑張って欲しい。オリンピックのように多くの人に注目されるような機会がないこともソフトウェア技術者の基礎体力が上がらない理由があると思う。

さて、自然科学も話題に戻ろう。ちなみに、組込みソフト開発では大抵の場合センサやアクチュエータを使う。センサやアクチュエータは自然科学の法則を使ってできているので、センサやアクチュエータの動作について分析・設計するときは人間の曖昧さを考える必要はない。だから、解決の方向性は大抵一つの向きに収束する。でも GUI でどこに何を表示すると使い勝手がいいとか、どんなデザインパターンを使った方が開発効率がいいとかいう議論は好き・嫌いの要素も多分に含まれており大激論になって収束しないことも多々ある。

人間系の問題を考慮しないとソフトウェア工学が効かない理由はこんなところにあるのではないだろうか。

だからこそ、何らかのソフトウェアの方法論を使いたいと主張するときはその根拠を明確にし、関係者全員に共通する価値観をベースに説得すべきなんだと思う。組込み機器開発の場合、その共通の価値観とは顕在的価値と潜在的価値によって満たされる顧客満足であり、顧客満足を高めるために有効な方法論であることを説明できれば受け入れられる確率が高い。別な見方をすれば、商品に求められる価値が違う（例えば業務ドメインや制約条件の異なる）ソフトウェア開発で同じ方法論が有効に作用するとは限らない。

組込みプレス vol.8 の特集記事で書いた、QFD（品質機能展開）を使ったソフトウェア開発の方法論は、市場要求やユーザーニーズを分析して、商品の価値が最大になるような方向にソフトウェアを収束させようとする。これはまさに顧客満足を高めるための方法論であり、商品に求められる価値が異なる、業務ドメインが異なるソフトウェア開発でも顧客満足や商品の価値を最大にできるはずである。

物理法則やコンピュータを相手にしているときは仕事がサクサク進むのだが、相手が人間になるととたんにスピードが減速するように感じる。人相手のときは共通の価値観、共通の目的を一生懸命バックグラウンドで考えているのだが、だからといってうまくいかないこともある。

そんな頭の切り替えを一日の中で何回もしなければいけないからこそ、理系の研究者よりもソフトウェアエンジニアはガス抜きの機会を作らないともたないのではないかと思う。
　

2007-08-25

モデル駆動開発

SESSAMEで一緒のにしさんがブログでソフトウェアの自動生成を話題にしているので、今回は自動コード生成、モデル駆動開発について考えてみたい。

ソフトウェアの自動生成といっても設計行為がいらないわけではない。実際にはUMLなどでモデルを作ってそのモデルからコードを自動に生成するという話だ。ようするにソフトウェアシステムの抽象度を一段上げようという世の中の傾向のことである。

ソフトウェアをアセンブラで書いていた時代からC言語などの高級言語で書くように時代はシフトしたので、次は言語で記述せずにモデルを記述して、モデルからC言語、C言語からアセンブラといった変換の部分をツールにやらせようという考え方だ。

その背景には、10万行を超える高級言語で書いた組込みソフトウェアは絡まり合い、収拾が付かなくなり、不具合が起こっても問題の原因を追及しきれないことが多いことにある。

手続き型の言語に慣れてしまった組込みソフトエンジニアはC++などのオブジェクト指向言語を使うことに尻込みし、また、オブジェクト指向言語を使っても従来の手続き型の言語でも試行錯誤的プログラミングをやってしまう。

そういう状況を見ていると、いっそモデルしか書けないようにして、モデルからコードへの変換のアーキテクチャの中にアーキテクトのノウハウを隠蔽してしまった方が品質が上がるんじゃないかと思うこともある。

でも、何年かまたは何十年かして、もしそういう時代がきたとしても必ずモデルからコードへの変換がどうなっているのか、今使っているモデル変換のアーキテクチャを変化させる必要がないのかを常に考る技術者が必要になる。今でもC言語とCPU、アセンブラに精通し、Cからアセンブラへ変換するコンパイラを開発しなければいけない人たちが必要なのと同じだ。

ちなみに、組込みソフトエンジニアでハードウェア寄りのソフトを書いている人たちは今でもCPUやグラフィックコントローラなどのデータブックをぼろぼろになるまで読み込む。多くのソフトエンジニアのソフトウェア記述の抽象度を上げても、誰かが抽象度の上がったモデルと下層レイヤのソフトウェアやハードウェアとの橋渡しをしなければいけない。

ソフトウェアプラットフォームがPCの場合は、モデルからコードへの変換のアーキテクチャは一般化しやすいだろうが、組込みの場合、変換アーキテクチャを一般化し、変換アーキテクチャの寿命を長持ちさせようとすると犠牲にしなければいけないことが生じる。

組込みシステムの場合、市場要求が千差万別で機能だけでなく性能要件やコストの要件などもあり、制約も多いからトレードオフが頻繁に発生する。コスト要求からくるメモリやCPUパフォーマンスの制限をクリアするためのトレードオフは手続き言語のレベルなら何とかなることが多い。でも、モデル変換のアーキテクチャの中にトレードオフのパターンが隠蔽されていると最適なすり合わせができない。

モデル変換のルール・アーキテクチャにその製品や製品群特有のすり合わせ要素を注入することは可能だが、トレードオフのポイントが頻繁に変わるような商品だった場合、モデルベースの開発はうまみがなくなってしまう。

モデル変換のルール・アーキテクチャを変えない、プラットフォームを変えないことに固執すると、ソフトウェアの開発効率は上がるが、トレードオフバランスの調整やすり合わせによるまねされにくい強みを作り上げるというアドバンテージは減る。プラットフォームが共通になり、数少ないモデル変換アーキテクチャが組込みソフト開発の世界にも普及するようになると、組込みもアプリケーションソフトだけで勝負することになる。これでは他社がまねしにくいソフトウェアのコアコンピタンスを作り上げることが難しい。

プラットフォームの共通化、フレームワークの共通化は、PC+Windows の現状を見れば分かるように、エンドユーザとアプリケーションソフトウェア開発者にはメリットが大きい。でも、そのメリットとは裏腹にPCのハードウェアメーカは辛いだろう。ユーザはPCを買うときにSONYでも東芝でもNECでもDELLでもどのメーカのパソコンを選んでも使い勝手にさほど変わりがない。変わりがないというよりは変えられないのだ。ここまでプラットフォームや共通クラスライブラリが普及してしまうとハードメーカは独自の特徴を出すことができない。

組込みシステムに対するモデル駆動開発のポイントはトレードオフやすり合わせの必要がないGUIなどのアプリケーションソフトに絞って実施することではないだろうか。組込みソフトウェア開発では開発環境の選択であっても常にトレードオフのことを考え、顧客満足を最大にするポイントを探り続ける必要がある。

P.S.

にしさんのブログのコメントに自動車エンジニアさんが、【MATLAB/Simulink/Stateflow】を使った自動コード生成の実態を書いている。MATLAB/Simlink についてはこのブログでも『MATLABのビジネスから見る知的生産性とは』に記事を書いているが、自動車エンジニアさんの記述によると自動車の世界ではMATLAB/Simlinkを使ったモデルベース開発/自動コード生成は実用段階まで進んでおり、実際の車のソフトにも自動コード生成で作られたソフトウェアが実装されているそうだ。日経エレなどの雑誌の記事では読んだことがあるが、現場の生の声でその実態を聞くとリアリティがある。

モデルベース開発によってコードを自動生成する行為が商品の価値を押し下げる可能性がなく※1、実際の商品の動きからモデルやチューニングパラメータを類推されないのなら、モデルベース開発に移行した方がいいというのは理解できる。

※1 パフォーマンスを低下させたり余計にメモリを食ったり、自動コード生成を実現させるためにCPUのランクを上げてコストアップになったりすることが顧客満足を低くする可能性のこと）

また、高級言語でプログラミングするエンジニアの割合が減って、モデル駆動開発するのが常識になったなら、高級言語ですり合わせ開発してまねされにくいソフトウェア資産を作ることより、開発の効率化や品質向上のメリットの方が大きくなる時代もくるだろう。やっぱりトレードオフのバランスポイントが大事になる。

ただ、一つ気になるのはMATLAB/Simlinkのように、モデルベース開発のツールが一社独占になってしまうことのリスクだ。万が一何かの理由でつぶれてしまったり、IBMやMicrosoftなどの巨人に飲み込まれていきなりツールや保守の価格を10倍ぐらいにされても、その条件を飲まざるを得なくなる。

ソフトウェアは複製コストがほとんどかからないので何万台も何十万台も製品を作って売るメーカーなら開発ツールが少々高くてもエンドユーザーへの負担は少ない。逆にメーカーは高価なCPUを使ったり、メモリ部品を余計に追加したりして材料費が10円でも20円でも高くなることを嫌う。原材料費のアップはエンドユーザーまで行くと数倍の負担になってしまうからだ。

一般的な会社においては開発ツールの価格の高さに加えて、開発ツールのセカンドソースも考えておかないといけないところが辛い。競争相手が次々現れたとしてもコンパイラやRTOSもバグがないかとか信頼性は高いかとか考えないといけないのと同じように、アーキテクチャ変換ツールの信頼性について心配しなければいけない。

やっぱり自動車業界のように業界内での示し合わせができないと普及するのに時間がかかると思うなあ。　

2007-08-09

組込みソフトで勝ちたい人に捧ぐ

今回は宣伝が入っているのでへりくだってですます調でいきますです。

さて、技術評論社の組込みプレス Vol.8 が8月11日に発売になります。特集1－制約の多い組込みソフト開発－『効率化と品質向上2つのアプローチ』に寄稿＆特集記事をプロデュースしたので内容を紹介したいと思います。

この特集1のサブテーマは「組込みソフト開発の心技体を鍛える」なんですが、開けてびっくり、特集2のテーマは「設計力」ブート★キャンプでした。組込みソフトもスポーツなんですね。

記事を読んでもそんなに疲れるものでもないので、今回の特集記事は夏休みの間にじっくり読んでいただきたいと思います。

今回の号は組込みソフトで「勝ちたい」人に最適です。もしも、あなたが組織の内外で認められ、発言力を増し、出世したいのなら実績を上げることが一番の近道です。組込みの世界で実績を上げるためにはヒット商品を開発したプロジェクトのメンバになっている必要があります。どんなに美しいアーキテクチャを構築しても、どんなに読みやすいコードを書いても残念ながらその成果を認めてくれる人は組織内にはほとんどいません。

組込みの世界では、どれだけたくさんの商品を売り、お客さんに満足してもらい、また次の新しい製品を買ってもらえるかどうかが勝負の分かれ目となります。あなたがサプライヤーの社員だったとしても同じです。ヒット商品のソフトウェアを供給できればそれが実績となります。

火消しが上手い人はかわいそうですが一つ火消しが終わると、もっと大きく燃え上がっている現場に投入されてしまいます。そうならないいためには、ヒット商品のソフトウェアの開発チームにいることが大切です。

今回の特集記事はQFD（Quality Function Deployment：品質機能展開）の技術を使って、市場要求や商品に求められる品質を分析し、組込みソフトの実装技術に結びつける方法を紹介しています。

ようするに売れる商品の要素を分析して、自分たちの得意な技術、他社がまねしにくい商品価値が凝縮されているソフトウェア資産を開発する方法なのです。これがうまくいけば、エンジニア個人としての自分も仕事が楽しくなるし、組織も売れる商品ができてありがたいし、お客さんにも喜んでもらえます。

特集記事の執筆者は酒井と、EEBOFのメンバーである安部田章さんと、QFD研究の第一人者である山梨大学の新藤久和先生です。安部田さんは QFD を基礎から丁寧に解説し、どのように組込みソフト開発に活かしていけばよいのかを書き、酒井は現状のソフトウェアシステムを分析してそのアーキテクチャを可視化した上でQFDを使うことで再利用資産を抽出する方法を示し、新藤先生はQFDの歴史と最新の研究を紹介しています。

安部田さんはトップダウン、酒井はボトムアップ、新藤先生はバックとフロントエンドの視点でQFDを解説するという、この一冊でQFDが丸ごと分かるというお得な特集となっています。

（特集2 では、SESSAME WG2 のメンバーである、山田、森、國方トリオが設計力強化のためのブートキャンプを張っていますのでこちらも注目）

もしもあなたが組込みソフトで勝ちたいのなら是非ご一読を。（ちなみに、商売とは関係のない研修者、学生のみなさんが読むと勝つ組込みソフトってどんなものかが分かります。）

【組込みプレス Vol.8 特集1 第1章特集のはじめにより引用】

　ユーザー要求や市場要求が明確になれば，組込み製品を使ってくれるユーザーの満足を高めるために何をすればよいのかが分かり，モチベーションの向上や改善への意欲につながります．ユーザー要求や市場要求を実現することができれば，自分自身の満足も高まり，商品が売れることで自分やプロジェクトの成果を組織に認めてもらうことができます．また，要求を満たすための技術が明確になれば，その技術を習得するという目標が定まり必要な技術を身につけるために最短の道筋を進むことができます．

　そして，ソフトウェア開発の途上でソフトウェアプロジェクトチームの意見が別れ，不協和音が聞こえてきても，「ユーザーや市場の要求をより満たすにはこちらの選択の方がよい」という導き方ができます．ソフトウェアエンジニアが10人も集まれば，それぞれの好みや癖により，ソフトウェア開発の方法論やアーキテクチャの選択に差異がでてきます．この差異を組織や会社間の上下関係により押さえつけてしまうこともできるでしょうが，それでは心技体の「心（技術者のモチベーションや改善への欲求）」や「体（チームビルディング力）」を下げてしまいます．

　市場やユーザーが商品に求める要求や品質が明確になっており，それらの重要度があらかじめ分かっていれば，そのときプロジェクトチームは何を取捨選択すればよいのか，どんな技術を習得すればよいのか根拠を持って判断することができます．プロジェクトリーダーの個人的な趣味や声の大きい技術者の好みではなく，ユーザー要求をベースにプロジェクトチームの舵を切ることができるようになります．欧米の責任と権限が明確に分けられたドライなソフトウェアプロジェクト運営と，パフォーマンスの高いうまくいく日本の組込みソフト開発のプロジェクトのあり方の違いは「誰のために仕事をしているのか」「今の仕事は何のためやっているのか」という部分の気持ちの持っていき方の違いであると言えるでしょう．

【引用終わり】

以上、宣伝でした。

2007-08-04

インドのソフト会社

あるところでインドのソフト会社（組込み系だけも1500人以上いるかなり大きい会社）の話を聞いた。（どんな会社かはこのブログ記事を参照のこと）

ソフトウェアの場合、オフショア開発で失敗した話はよく聞くし、CMMのレベル5を取っているからといって組込みソフトの世界でも通用するのかどうか懐疑的だったのであまり期待はしていなかったが、今後の大規模組込みソフト開発へのヒントをいくつか見つけた。

まず、前提条件としてこの会社の場合技術者は入社したときからソフトウェア工学の成績が高い者を採用している。まず、この点が日本と違う。日本では現状、入社した後に実践に必要なソフトウェア工学を教育することが多く、場合によっては大学でも会社組織でもソフトウェア工学を教わることなくなんとなく流されるまま中堅となってしまうことがある。

次に、組織内の技術者がみなソフトウェア技術者であり、日々勉強してスキルレベルを保っていないと給料が下がってしまうような仕組みを持っている。自社のスキル体系を構築しており定期的にテストを実施しているという。この点は、プロフェッショナルの条件の記事で書いたように21世紀では知識労働者が40%なのだから、常に鍛えておかないとプロフェッショナルとしての仕事はできないという課題に対してキチンと取り組んでいると言える。

また、この会社は言語のギャップを埋めるために、トランスレーターの組織を持っており、ソフトウェア技術・知識はそれほど持っていないが日本語はぺらぺらというグループがいて、テレビ会議やインドまで日本人が出向いていって打ち合わせをするときは彼らを仲介役に付けてくれるのだそうだ。

多種、多様な仕事を受けた実績があるため扱ったことのあるCPU、統合開発環境、OS、言語、ツール類の種類が非常に多い。一人の技術者が全部できるわけではないが組織としてかなり多くの開発経験を持っていることがうかがえる。ドラッカーが言うように知識労働者は自分の頭が生産手段なのだが、組織がうまくコントロールすれば生産手段を頭の中から引っ張り出して、その一部をプロセスやツールに埋め込むこともできる。イメージ的にはそれができているような印象を受けた。

そしていくつかの質問をしてみた。まずは、「クライアントから受けた仕事で作ったソフトウェア資産を他のクライアントで使うことはあるか？」という質問。もちろん答えは「No」。次に、「自分たちで作ったUSBのドライバとか、ファイルシステムなどをソフトウェア資産として再利用することはあるか？」と聞いた。答えは「クライアントと相談して、この部分の開発は開発費はいらないので自分達の資産にさせて欲しいといい、自組織の資産とする場合はある。」と言っていた。

ようするに、ソフトウェアの資産化、再利用についても考えているという答えだ。ただ、自分自身が商品を企画、販売する訳ではないので、商品群の長期販売戦略に基づいたソフトウェア再利用資産の構築を計画することはできていない。そこが惜しいなあと思う。（日本でもほとんどの組織でできていないと思うが・・・）

でも、明らかに日本の多くのソフトウェアプロジェクトと違うのは、冒頭に掲げた絵にあるように、日本ではハード部隊とソフト部隊が近い関係にあるが故に、ソフトウェアのプロセスとプロセスが曖昧になりがちで試行錯誤的にソフトウェアを作ってしまうのに対し、このインドの会社ではキッチリプロセスを分けて前に進んでおり、ソフトウェア技術者がソフトウェア工学を学んでいて、それぞれが Methodology に基づいて作業をしているというところだ。

ただ、組込みソフトの開発では、そのトップダウン的アプローチにはデメリットがある。要件定義はきちんとできていて、アーキテクチャも考えているが、実装してみたらCPUパフォーマンスやメモリリソースが足らないというような制約条件をクリアできていないという事態をまねく場合があるという点だ。

「開発を進めていくと、制約条件をクリアできずにアーキテクチャを見直すことはないのか。」と聞いてみた。そうすると「それは、いつも悩んでいることでありアーキテクチャを修正することはある」という答えが返ってきた。

ここですごいと思ったのは、このインドの会社が「制約条件をクリアできないときはアーキテクチャ設計まで戻ってアーキテクチャの見直しをする」というアプローチを取っているということだ。日本の場合は、自分のシステムのアーキテクチャ自体がどんなものか分かっていない場合が多い。なぜなら試行錯誤的アプローチでソフトウェアを作り込んでしまうからだ。だから、制約条件をクリア出来ない場合は、アーキテクチャに立ち戻るのではなく、その場しのぎの対策をしてしまう。これでは、ソフトウェアはスパゲッティ状態になってしまっても不思議ではない。

また、このインドの会社では、要件定義が固まるまでは正確に工数が見積もれないので作業にかかった時間だけ費用をもらい、要件定義が固まった後は仕事量に対して見積もり金額を請求すると言っていた。非常にリーズナブルな回答であり、日本のソフトウェア受託開発会社でそのような方針を取っているところはあるだろうかと考えてしまった。

このような対応をするためには開発の前工程で要求分析を十分にし、要求仕様の確度を高くする必要がある。そのため、クライアントに対し仕様面で分からないところ、曖昧なところは徹底的に質問してクリアにするように心がけているそうだ。

インドはハードウェアの生産手段を持たずにソフトウェアの効率的生産で勝負しようとしている。ハード、ソフトのすり合わせ的な部分でのメリットは出しにくいが、ソフトウェア開発の効率化のメリットがそのデメリットを上回りそうな勢いを感じる。実際、このインドの会社はハードソフトのすり合わせ的な部分の設計についての重要性も理解しており、ちゃんと対応もするがソフトウェアの開発効率は落ちるので、その部分を日本に常駐して作業する際のコストはインド国内での作業の約倍のコストがかかると説明していた。うーん、実にリーズナブルな回答だ。

このインドの会社から日本が学ぶべきことは次のようなことになる。

ソフトウェアの規模が大きくなり複雑化してきたら（目安は30万行、30人）ソフトウェア部隊だけの組織体制を作るべき（日本のメーカーでもそのようにしている会社が増えてきている）
ソフトウェア技術者への組織的なソフトウェア工学の教育を行い、スキルレベルを定期的にチェックすべし（日本では技術者のリソースの数が少ないので優秀な人間を選択できないところがネック）
要件定義は開発の前段階で確度を高めておく。後工程での仕様変更にはコストがかかるため安易に応じないという姿勢も必要。

最後に個人的な感想は、「自分が組込み製品を作る会社の経営者だったらこのインドの会社にソフトウェア開発を丸投げした方が手戻りコストのことなども含めて考えれば安いだろうな」といったものだ。

でも、ソフトウェアのコア資産までもインドの会社に出してしまったら、ソフトウェア再利用資産を使った開発の効率化は難しいかもしれない。また、組込みソフトウェアエンジニアとしての最大の問題はソフトウェア開発をまるごと外に出してしまったら自分たちがやること、くふうのしがいがなくなってしまうという点だ。そんなことになったらモチベーションは著しく下がるだろう。
　

2007-07-29

プロフェッショナルの条件

先日記事の中でピーター・F・ドラッカーの本は斜め読みしにくいと書いた。実際、『マネジメント - 基本と原則 [エッセンシャル版]』
は斜め読みしにくいと思ったが、買っておいてまだ開いてもいなかった『プロフェッショナルの条件―いかに成果をあげ、成長するか』を斜め読みしたら、こっちはすごく読みやすかった。

しかも、書いてあることが逐一納得できる。この本はネタ本としては最適であることが分かったので、これから少しずつ記事の中で小出しにしていきたい。

【ピーター・F・ドラッカー】

Peter Ferdinand Drucker、1909年11月19日-2005年11月11日）はオーストリア生まれの経営学者・社会学者。なお、著書『すでに起こった未来』(原題"The Ecological Vision")では、みずからを、生物環境を研究する自然生態学者とは異なり、人間によってつくられた人間環境に関心を持つ「社会生態学者」と規定している。ベニントン大学、ニューヨーク大学教授を経て、2003年まで、カリフォルニア州クレアモント大学院教授を歴任。「現代経営学」、あるいは「マネジメント」 (management) の発明者と呼ばれる。ドラッカーの著書の日本での売り上げはダイヤモンド社刊行分だけで累計400万部余り。

【『プロフェッショナルの条件』　はじめに　より引用】

　今日あらゆる先進国において、最大の労働人口は、肉体労働者ではなく知識労働者である。20世紀の初め、最先端の先進国でさえ知的労働者はわずかだった。全労働人口の3%を超える国はなかった。だが今日アメリカでは、その割合が40%を占める。2020年には、ヨーロッパ諸国や日本もそうなる。このように大量の知識労働者は、歴史上初めての経験である。彼らは生産手段を所有する。知識を所有しているからである。しかも、その知識は携行品である。頭の中にある。

　：

　もう一度繰り返すならば、知的労働者とは、他のいかなる者とも二つの点で大きく異なる存在である。第一に、彼らは生産手段を所有する。しかも、その生産手段は携行品である。第二に、彼ら（そしてますます多くの彼女ら）は、雇用主たる組織よりも長生きする。加えて、彼らの生産手段たる知識は、他のいかなる資源とも異質である。高度に専門分化して、初めて意味を持つ。脳外科医が真価を発揮するのは、脳外科に専門分化しているからである。おそらく、膝の故障は直せない。熱帯の寄生虫にいたっては、手もでない。

　：

　1950年代、60年代のアメリカでは、パーティで会った人に何をしているかを聞けば、「GEで働いている」「シティバンクにいる」など、雇用主たる組織の名前で返ってきた。当時のアメリカは、今日の日本と同じだった。イギリス、フランス、ドイツその他あらゆる先進国が同じだった。ところが今日、アメリカでは「冶金学者です」「税務をやっています」「ソフトウェアの設計です」と答えが返ってくる。少なくともアメリカでは、知識労働者は、もはや自らのアイデンティティを雇用主たる組織に求めなくなっており、専門領域への帰属意識をますます強めている。今日では日本においてさて、若い人たちが同じ傾向になる。

　：

　今や唯一の意味のある競争力要因は、知識労働の生産性である。その知識労働の生産性を左右するものが知識労働者である。雇用主たる組織の盛衰を決めるものも、一人ひとりの知識労働者である。
　これらのことが何を意味するのかが、本書の主題である。・・・・

【引用終わり】

本を斜め読みするときでも、「はじめに」はじっくり読むことにしている。なぜなら、「はじめに」は著者が示したその本のコンセプトであることが多いからだ。『プロフェッショナルの条件』の「はじめに」はハッと思ったのは、21世紀においては知識労働者の割合が40%を超しているというところだ。

コミュニティ活動で組込みソフトエンジニアの教育コンテンツを作る活動をするにあたって、ソフトウェアの世界で技術者教育が大事であることは直感的に分かっている。当然、いい教育を提供するためには費用もかかるし管理工数もかかるのだが、組織内でその費用を確保する際に「それだけの費用をかけるのなら効果についても示せ」などと言われることがある。有効な教育コンテンツを作成することに心を砕いている人は、教育に対する費用対効果を示すことほど難しいことを知っており、「それだけの費用をかけるのなら効果についても示せ」などと言われると「ああ・・・分かってないなあ」と感じる。

しかし、ピーター・ドラッカーが書いているように先進国では労働者の40%が知識労働者であることが認知されていれば、白いキャンバスの状態で入ってきた新入社員に必要な教育を提供することがいかに重要であるのかがわかる。

新入社員・初級技術者への教育の重要性が理解できない理由は体系的な教育、体系的なOJTを実施しなくても、職場で働いていれば必要な技術が身に付くと考えているからに他ならない。

しかし、現在の組込みソフト開発は、20年前の数人のプロジェクト、1年から2年あった開発期間のときとは規模、複雑性からしてまったく状況が異なる。試行錯誤的なアプローチで30人、30万行の組込みソフトウェアを品質よくスケジュール通りにリリースすることはほとんど不可能である。（30人以上のプロジェクトはプロがマネージメントしないと倒れるの記事を参照のこと）

ただ、そうはいうもののビジネス系のソフトウェア開発と違って、組込みソフトの開発では、新しいデバイスを使うときや要素技術的な検討をするときは試行錯誤的なアプローチも必要だ。なぜなら、すでにできあがっているソフトウェアモジュールを組み合わせて商品が作れるような状況では、その組織にしかできないコアな資産があるとは言えず、結局は競争力の弱い製品しか作れないからだ。

だから、新しいデバイス、新しい技術、自分たちにしかない技術を使ったソフトウェアを試行錯誤的なアプローチで作り、再利用可能な資産となるように洗練させるという工程が必要になる。組込みソフトの世界では試行錯誤的アプローチも必要だし、要求を分析してシステムの構造を考えるといったトップダウン的アプローチも必要なのだ。

ところが、その両方のバランスを考えるまでもなく10万行を超えるような組込みソフトを試行錯誤的なアプローチでだけで作りきってしまうプロジェクトも世の中には存在する。このような組込みソフトで起こるバグは非常に見つけにくいし、再利用もしにくい。

そんなプロジェクトのメンバーが、『プロフェッショナルの条件』の「はじめに」に書いてあるように、パーティの席で見ず知らずの人に自己紹介する様子を見ていれば、おそらくほとんどの技術者は「○○株式会社に勤めています」とか「○○株式会社のソフトウェアエンジニアです」と答えるだろう。

自分自身はこんなときには「組込みアーキテクトです」と答えたいと常々考えている。ピーター・ドラッカーが書いているように所属ではなく専門領域を言いたい。その深層には自分は組織に所属していることでステータスを示したいのではなく、専門領域のプロフェッショナルとしてのステータスを主張したい気持ちがある。

そう考えると、技術者個人が勉強するのはパーソナルスキルを高めるためではなく、プロフェッショナルスキルを高めるためということになる。パーソナルスキルを高めることで終わってしまうと「USBコントローラを使いこなしたい」とか「オブジェクト指向設計を身につけたい」とか「UMLを覚えたい」という目標になるが、プロフェッショナルスキルを高めるためと考えると、「顧客満足を高めるために必要な技術はなんだろう」とか「上司を納得させてこの提案を通すためにプレゼンテーション能力を上げたい」といった一段高い視点で考えるようになる。

ピーター・ドラッカーの本を読むということ自体も同じだ。ソフトウェアエンジニアがマネジメントの神様の本を読む必要はないと考えるか、それもと組込みソフトエンジニアとしてプロの仕事をするためには知識労働者がすべきことを学ぶ必要があると考えるのかは、組込み製品開発のプロフェッショナルを目指しているかどうかで変わる。

知識労働者が生産手段を所有し、それが頭の中に入っているとなると組織はその頭の中の知識を表に出して資産化する必要がある。そうしないと、知識労働者が組織を去ると同時にその知識労働者の頭の中にある大事な資産までも持って行かれてしまうからだ。ソフトウェア技術者を代替えが可能な部品のように考えているマネージャはこのことを理解していない。

協力会社の社員が入れ替え可能なように見えるのは、新たにアサインされた代わりの優秀なエンジニアがソースコードに埋め込まれた設計情報を読み取っているか、もしくは再設計しているのかのどちかだ。どちらにしても、無駄な人件費がかかっている。そんな無駄な工数がかかっていても開発費が抑えられているのは、仕事を出しているクライアントの会社の社員よりも何倍も優秀であっても、会社間の上下関係だけで不当に安い賃金でこき使われているからだ。優秀なエンジニアがその能力を正当に評価されていない状況を見るのは辛いものだ。

さて、昨年のソフトウェア品質シンポジウムの講演でものづくり経営研究センター長藤本隆宏先生は、「ものづくりとは設計情報の転写である」と言った。（「人工物に託して、設計情報＝付加価値を創造し、転写し、発信し、お客に至る流れを作り、顧客満足を得ること」であるという意味。（ものづくり戦略とソフトウェア品質参照のこと）

組込みソフトにおいて、設計情報とは設計プロセスであったり、UMLで示したアーキテクチャであったりする。（ソースコードは粒度の細かい設計情報であり、再利用という観点からすると資産価値は低い）

ソフトウェア技術者がプロフェッショナルスキルを意識していれば、価値の高い設計資産をアウトプットすることに重要性を感じるはずである。

『プロフェッショナルの条件』には、30年以上繁栄し続ける組織は滅多にないと書いてある。知識労働者の寿命はもっと長いので、組込みソフトエンジニアは組織への帰属を意識するよりも、専門領域のプロフェッショナルとしてどう成長すべきかを考えることが大事なのである。
　

2007-07-24

こころの処方箋

元文化庁長官で臨床心理学者の河合隼雄氏が19日午後2時27分、脳梗塞のため死去した。

河合隼雄氏は 1928年、兵庫県生まれ。京都大理学部数学科卒業後、米国留学を経て、1962～1965年にスイスのユング研究所に留学し、日本人で初めてユング派分析家の資格を取得した。帰国後、ユング心理学を基礎にした心理療法の「箱庭療法」を完成・普及させ、日本にユング派心理療法を紹介した。

私的諮問機関「21世紀日本の構想」懇談会の座長や、教育改革国民会議委員など政府関係委員を歴任し、2002年1月、史上3人目の民間人として文化庁長官に就任しており、テレビでもよく姿を見ることがあった。

河合隼雄さんは人を包み込むような雰囲気を持っており、その著書の多くを読んだ。今回は、なぜ、河合隼雄氏の本を読んでいたのかを書きたいと思う。

プログラムは正確でないと動かない、曖昧なままでは期待したような動きにはならない。C言語などの高級言語ではやや曖昧さを受容するようにもなったが、アセンブラの時代などでは一命令でも間違っていればまったくプログラムが動かなかった。

そのような状況下ではソフトウェアエンジニアはロジカルな思考を求められる。ロジカルであればあるほど間違いの少ないプログラムを書くことができる。逆に言えば、いい加減な性格の人はソフトウェアエンジニアには向かない。

地道にこつこつこつこつとプログラムを書き論理的な問題点や、仕様が曖昧な部分があるとすぐに質問しすべてクリアにしてから前に進むような性格のエンジニアがプログラマに向いている。ことプログラマという職種に限って言えば、完全主義者であればあるほど早くて正確な仕事をし優秀であると評価される。

ところが、人間の脳は本質的にはロジカルな思考システムではない。脳神経学的に言えばコンピュータが０か１かの判断をするのに対し、人間の脳は多数決で判定を下す。また、その多数決に使われる入力はいつも同じではないため、必ず一定の結果になるとは限らない。

ようするにソフトウェアエンジニアは仕事上ロジカルであることが求められているにもかかわらず、本質的にはロジカルではないのだ。

そのギャップはときに社会生活を送る上で障害を起こすことがある。コンピュータがロジカルであるが故に生身の人間もロジカルな思考であるかのように勘違いしてしまうのである。その勘違いが進むと、人間もロジカルにコントロールできるという錯覚に陥ってしまう。そして、現実の人間はまったく論理的ではないため、コンピュータのように正確に予測したようには動かず、予測と現実が異なるためそのギャップに苦しむことになる。

例えば、野球で1点差で負けている試合、9回2アウト、ランナー2、3塁で最後のバッターを送り出す監督は選手に何というと成功に結びつくか？

「何が何でもここでヒットを打って逆転しろ」というのが監督の本音だ。でも、ベテランの監督なら「三振してもいいから思い切って振ってこい」などと言うだろう。三振しては困るのだがプレッシャーを与えないために、まったく逆のことを言った方が結果がよかったりする。人間とはそんなものだ。

また、ソフトウェアが大規模複雑化すると、ソフトウェアプロジェクトには多くのソフトウェアエンジニアが関わり合う。ロジカルでない人間が集まってロジカルにプログラムを作らなければいけない。そんな状況で問題が起こらないはずがない。このブログで顧客満足を高めることが大事と言っているのは、ロジカルと非ロジカルの矛盾を抱えながら組織やプロジェクトや個人がともに成功するためには、共通の価値観である顧客満足を高めることを目標にすれば、非ロジカルな部分のずれを修正して方向性を一つにできると考えるからである。

さて、ソフトウェアエンジニア個人が河合隼雄氏の本を読むとどんなよいことがあるのか。

それは、若いとがった気持ちで日々の仕事の黙々と取り組んでいるソフトウェアエンジニアがいるとする。自分だけの範疇ではこのような技術者はいい仕事をしている場合が多い。ところが、このような論理的でとがった気持ちをずっと解除しないでいると、複数人で共同作業をする場面やプライベートな時間で人と接するときに空回りしたり、他人を精神的に傷つけたりする。

河合隼雄氏の本をこんなエンジニアが読むとこのようなとがった気持ちを鈍らせて、所詮人間なんてそんなもんなんだということを気づかせてくれる。

河合隼雄氏の著書の中で読みやすく、もっともコンパクトな文庫本が『こころの処方箋』（420円）だ。こころの処方箋の中の一節を紹介したいと思う。

【こころの処方箋－こころの中の勝負は51対49のことが多い－　より】

　中学生や高校生のなかには、私のところに無理矢理に連れられてくる生徒がいる。たとえば、登校拒否の子など、心理療法家のところなど行っても仕方ないとか、行くのは絶対嫌だと言っているのに、親や先生などが時にはひっつかまえてくるような様子で連れて来られる。嫌と思っているのをそんなに無理に連れてきても仕方がないようだが、あんがいそうでもないところが不思議なのである。

　あるとき、無理に連れてこられた高校生で、椅子を後ろに向け、私に背を向けて座った子が居た。このようなときには、われわれはむしろ、やりやすい子がきたと思う。こんな子は会うやいなや、「お前なんかに話しをするものか」と対話を開始してくれている。そこで、それに応じて、こちらも「これはこれは、僕とは話す気が全然ないらしいね」などと言うと、振り向いて、「当たり前やないか。こんなことしやがって、うちの親父はけしからん・・・」という具合に、ちゃんと対話がはずんでゆくのである。

　こんなときに私が落ち着いていられるのは、心のなかのことは、だいたい51対49くらいのところで勝負がついていることが多いと思っているからである。この高校生にしても、カウンセラーのところなど行くものか、という気持ちの反面、ひょっとしてカウンセラーという人が自分の苦しみをわかってくれるかも知れないと思っているのだ。人の助けなど借りるものか、という気持ちと、藁にすがってでも助かりたい、という気持ちが共存している。しかし、ものごとをどちらかに決める場合は、その相反する気持ちの間で勝負が決まり、「助けを借りない」という方が勝つと、それだけが前面に出てきて主張される。しかし、その実はその反対の傾向が潜在していて、それは、51対49と言いたいほどのきわどい差であることが多い。

　51対49というと僅かな差である。しかし、多くの場合、底の方の対立は無意識のなかに沈んでしまい、意識されるところでは、2対0の勝負のように感じられている。サッカーの勝負だと、2対0なら完勝である。従って、意識的には片方が非常に強く主張されるのだが、その実はそれほど一方的ではないのである。
　このあたりの感じがつかめてくると、「お前なんかに話しをするものか」などと言われたりしても、あんがい落ち着いていられるのである。じっくり構えていると、どんなことが生じてくるか、まだまだ分からないのである。

　：
　：

【引用終わり】

河合隼雄氏のような包み込むような語り口で人間の心理は1か0では判断できないと言ってくれる人は他にはいないと思う。河合氏が亡くなって生の声を聞くことができなくなったのがとても残念だが、氏が残した言葉は本の中で生き続けており、ふとたまに読み返すとコンピュータの思考になっている自分を現実の世界に引き戻してくれるのである。

2007-07-14

トム・デマルコの「プロジェクト管理」がわかる本

昨日、久しぶりに池袋のジュンク堂に行った。コンピュータ関連のフロアを一通り眺めてみた感じたのは、組込みソフトの本とテスト系の本がここ2～3年でかなり増えたなあということだ。

組込みソフトの本で痛切に感じたのは、組込みソフトだからといって作る対象製品を特定せずに、CPUや周辺デバイスをインタフェースするドライバや、ソフトウェアの作り方を一冊の本で説明してしまうのはどうかなということだ。

なぜかというと、組込みソフトは制約条件や業務ドメイン、商品群、商品を投入する市場によって、アーキテクチャが変わるし、目的を達成する方法も一つではないので、どんな組込みソフトの分野にも効くゴールドスタンダードはないからだ。

ゴールドスタンダードがあるように読者に期待させると嘘になると思う。だから、『組込みソフトエンジニアを極める』では電子レジスタ商品群という具体的なモデルを対象にして、要素技術から商品群全体のアーキテクチャ、品質向上技術、再利用施策について書いた。、『組込みソフトエンジニアを極める』の読者が、自分たちの業務ドメインでそこに書かれている内容を現場で活かすためには、電子レジスタのモデルで展開された具体的な例を、自分たちのプロダクトだったらどういう風に適用すればよいのか、どのように投影すればよいのか考えないといけない。

どんな組込みソフト開発でも「こんな風にやれば成功しますよ」とは書いていないので、もどかしいと思う方もいるかもしれない。仮想の電子レジスタの開発という具体例で、組込みソフト開発の全体の流れや、技術者としての考え方、モチベーションの持ち方をつかんでもらい、自分達の開発現場にその考え方を投影し、展開する必要がある。

そして、この本の中に出てくる個々のソフトウェア工学の技術、たとえば、リアルタイムOS、オブジェクト指向設計、要求分析技術、テスティング技術などはそれぞれ専門書で勉強して欲しいと思う。「こういときに、こういう専門技術が必要なのだ」というあたりをつけて欲しい。

『組込みソフトエンジニアを極める』は組込みソフト開発に対してエンジニアがどのようなスタンスで取り組めばよいのかを考えるガイドラインとしてとらえてもらえるとありがたい。そういう視点で見てもらうと、組込み系では他に類似する本はまだないと思う。

組込みソフトで難しいのは、ここの技術を深く掘り下げて解説する本は書きやすいのだけれど、それらの技術を使って個別の開発を成功させるにはどうすればよいのかについては、その商品をどんなもので、どんな市場に対してどんな制約下で作ろうとしているのかが分からないと最適な方法論をサジェスチョンできないという点だ。

だから、組込みソフトの商品開発に深く入り込んで、開発を成功に導いたコンサルタントはその方法論を知っている筈だが、守秘義務があるのでその核心部分を公にはできない。

さて、前置きが長くなったが、ジュンク堂で良い本を見つけた。『トム・デマルコの「プロジェクト管理」がわかる本―ポケット図解』（吉平健治著）￥735- だ。

この本は、トム・デマルコの著書『ピープルウェア』『デッドライン』『熊とワルツを』のエッセンスを図解で分かりやすく示してくれている。同じシリーズに『ピーター・ドラッカーの「マネジメント論」がわかる本－ポケット図解』もあるので、これも後で買おうと思う。（ピーター・ドラッカーの原本の方は斜め読みがしにくくめげている）

『トム・デマルコの「プロジェクト管理」がわかる本―ポケット図解』もまだ、読み始めたばかりだが、最初の1-1がプロジェクト管理の本質を示していると思うので、最初の部分から全体を推し量ってもらうべくここで紹介したい。

【『トム・デマルコの「プロジェクト管理」がわかる本―ポケット図解』 1-1 プロジェクト失敗の本当の原因は？より】

1. 本当の原因は人間の中に存在する社会学的問題

　確かに生産性や品質は向上したでしょうが、実際、プロジェクトに対する要求の複雑化、規模の増大は、このような技術の対応だけでは追いつかないところもあります。デマルコは、プロジェクトの失敗の原因は技術的な問題ではなく、実は、プロジェクトとそのチームの「社会学的」な問題によって引き起こされていると宣言しています。チームメンバーの意思疎通が疎かになったり、働く意欲が欠如したり、あるいは退職してしまったり、プロジェクト管理者への不信感が募ったりなどなど、人そのものと人に関する問題がトラブルの原因になっているのです。そらに事態を悪くしているのは、この事実を管理者たちが理解していないことだと彼は言います。

2. 開発者は交換可能な部品ではない

　ソフトウェアは結束したチームによって開発され、他の多くのチームや部署とコミュニケーションしながらでき上がるものです。本当にハイテク技術を使っているのは一部の「研究者」と呼ばれる人たちで、ソフトウェア開発者は実際には「人間関係ビジネス」に携わっているのです。したがって、開発者を機械のように交換可能な部品として考えるのは大変危険です。この危険な傾向が管理者たちの間でまかり通っていると、デマルコは警鐘を鳴らしています。

【引用終わり】

他にもさまざまなベストプラクティスについて書かれているので、まず、この本を眺めてからデマルコの原書を読むとよいと思う。

2007-07-07

30人以上のプロジェクトはプロがマネージメントしないと倒れる

PMI東京支部月例テクニカルセミナー組込み系プロジェクトの現状と課題－プロジェクトマネジメントの専門家への要請－（講師株式会社プロセスネットワーク金子龍三氏）に参加し、今後、組込みソフトエンジニアがどのように対応していけばよいのかイメージがわいてきた。

冒頭の絵は、30人30万行以上のプロジェクトでは、プロのプロジェクトマネージャがぐいぐいと引っ張らないと凧（プロジェクト）空に上がらず、地に落ちるというイメージだ。30人30万行という数字は目安でありソフトウェアの複雑度によっても変わると思うが、30人30万行の規模でプロジェクトマネージメントの技術を使わずに、品質の高いソフトウェアをスケジュール通りにアウトプットすることはほとんど不可能だろう。

もしも、この規模のソフトウェアプロジェクトで、なんとかスケジュールが間に合っているのであれば、それは、プロジェクトメンバーの誰か（全員か一部か、それともサプライヤか）が死ぬほど働かされているはずだ。要するに人海戦術的なアプローチで乗り切ろうとしているのだ。そして、苦労してリリースしたソフトウェアの品質はかなり危うい状態にある。

大きな組込みソフトウェアプロジェクトで必要なプロジェクトマネジメント技術とは次のようなものだ。

技術戦略、技術マネジメント
プロダクトリスクマネジメント
予算統制
再利用資産開発
専門家集団との連携

このようなプロジェクトマネジメント技術なしに、「あたたかい人間関係の中のやさしい一員」（アメリカ人と日本人の記事を参照のこと）が、プロジェクトを進めようとしても、凧は空に舞い上がることはない。風（エンジニアリングを受け入れる環境）が吹いていない状況で、にわかプロジェクトリーダーがプロジェクトという凧を揚げようとすると、スピードが出ないため凧をずるずると地面を引きずってしまう。

さて、プロジェクトマネージメントの技術はプロジェクトマネージャがその道の専門家から学び実戦経験で培ってもらうとして、組込みソフトエンジニアを目指す若者は30人30万行のソフトウェアプロジェクトの中でどういう心構えで毎日の仕事に臨めばよいのだろうか？

組込みシステムでプロの組込みソフトエンジニアとして成功するにはどうすればいいのかという観点で考えてみた。

【－大規模組込みシステムで－プロの組込みソフトエンジニアとして成功するには？】

<自分が選んだ業務ドメイン（業界）の知識、技術を徹底的に身につけ、その道のプロと呼ばれるようになる>

自分がこれからずっと関わる領域がストレートに好きであり、自分の技術を磨いてよりスキルが高まることに喜びを感じられることが一番大事
業務ドメインのプロと、ソフトウェアエンジニアとしての両方のプロになることが必要
その道のプロとして終わりなき技術鍛錬に挑み続ける覚悟もないとダメ

<自分が作ったソフトウェア資産が、顧客満足を高めていることを実感できること>

一回切りではない、長く使われる品質の高いソフトウェア資産をアウトプットし、その資産が顧客満足を高めることに貢献することが、エンジニアとしてのモチベーションの源泉となる
そのためには、ソフトウェアシステムのアーキテクチャ（構造）を可視化する技術が必要
自分が構築したソフトウェア資産はコレで、この資産が、商品のこんな機能や性能を実現しており、その機能・性能が商品のウリにつながっていると説明できるようにならねばならない
それができないと、大きな組織の歯車の一つとして扱われ、一生日の目を見ない技術者になってしまう危険性がある

<組織を動かせるエンジニアになること>

組込みソフトの世界には、ハードウェア出身、工場出身の上長、組織上位層がたくさん存在する
ソフトウェアの特徴（複雑性や不具合の見つけにくさ）などを知らない者を相手に主張を通せるようにならなければいけない
ソフトウェアは見えにくいため、自分や自分たちが構築したソフトウェア資産が、商品を通じてどのように顧客満足を満たしているのかを説明し、これを維持発展させるために必要なリソース、時間、資金を勝ち取らなければいけない
交渉し、主張し、提案や意見を通すことができなければ、よく働く都合のよい作業者となってしまう

じゃあ、そこまでして組込みソフトエンジニアを目指すのはなぜだろうか？

【なぜ組込みソフトエンジニアになろうとするのか】

<好きなこと（市場・ドメイン）にずっと携わっていられる>

車好きでエンジン制御のソフトを作っている
カメラが好きでカメラのソフトを作っている
音楽が好きで電子ピアノのソフトを作っている

<ものづくりの楽しみ>

何もないところから少しずつ組み上がって完成する様を体感できる
自分のくふうが商品の機能や性能に反映される
いろいろな商品から自分が作ったものをお客さんが選んで、満足してくれている喜び
ヒット商品を世に出すことができたときの満足感
民生品ならば見ず知らずの人が自分が作った商品を手にしているところに遭遇することもあるかも

<社会に貢献しているという喜び>

社会インフラを支えている裏方としての誇り
自分の仕事の成果が多くの人々の役に立っているという喜び

ソフトウェアの規模が大きくなってくると、自分が作っているところが実感しにくくなり、自分のくふうが見えにくくなり、役割分担が必要になってソフトウェアシステム全体を個々の技術者が把握できなくなってくる。

そうなると大事なのは、顧客満足の向上と技術者のスキルのスパイラルアップ（左図）を実現させることだ。

ニーズを分析
技術的困難を克服
ユーザーニーズを実現し満足を得る
新たな技術獲得への欲求が生まれる

このサイクルを繰り返しながら、スキルを高め、顧客満足を高めることに貢献していることを組織に示していく。

そして、顧客満足を高めることを示すには、ソフトウェアシステムのアーキテクチャを可視化しニーズを実現しているソフトウェア資産を指し示すことができないといけない。

日本の組込みソフトエンジニアは同じ市場に同じような商品を投入し続け、他社製品のよいところや市場クレームを吸い上げて、性能を落とすことなくソフトウェアを最適化する能力を持っている。しかも、作り上げたソフトウェアの品質が高い（規模が小さい場合）。

でも、今のままのすり合わせ的組込みソフト開発アプローチにはデメリットもある。デメリットを克服しながら日本の強みを生かす方法はこちらの記事を参照していただきたい。

これまで築き上げた職人技をアーキテクチャとして可視化し、再使用資産を抽出した上で他社がまねできないコアアセットを軸に商品コンセプトや強みを前面に押し出す。もともと品質は高いので、開発効率も上がり他社に負けない商品となる。

今後、大規模・複雑化した組込みソフトウェアのアーキテクチャは組込みソフト開発にとって重要な要素となり、場合によってはソフトウェアエンジニアの組織構造の方を、商品群のソフトウェアアーキテクチャに合わせていく必要も出てくる。（コアアセットを開発するチームをアプリケーション開発部隊から切り離すなど）顧客満足を十分に実現しているアーキテクチャは組織の重要な資産であり、優れたアーキテクチャは美しくもある。

ただ、組込みアーキテクトは商品開発の中で、泥臭い部分も飲み込んでいかなければいけない。組込みソフトがどんなに大規模化しても、昔も今も関係なく組込みアーキテクト・組込みプロジェクトのリーダーには、大工の棟梁としての素養が求められる。

しがらみや制約条件の中で舵取りができる決断力
ハードウェア出身、工場出身の上司・関係者との交渉力　
アーキテクチャ（ソフトウェアの構造）の善し悪しを判断し悪い所を指摘し、良い例を提示できる実績と経験

組込みソフトプロジェクトを成功させ、組込みソフトエンジニアとして成長するには、さまざまな素養を身につけないといけないのだ。そして、プロジェクトが30人30万行の規模以上なら、プロジェクトマネージメントの技術も学んでいかなければならないということだ。
　

2007-06-30

自分の成果物は点数で評価してもらえると考える新人

今、「設計の規範の重要性を技術者に実感してもらう」　演習コンテンツをSESSAMEで開発している。内容はいずれ SESSAMEで公開されると思うが、次のような流れを想定している。

【Cプログラミングの初心者に対して】

ある簡単な仕様を満たす関数をC言語で設計させる。
数時間するとなんとか要件を満たす関数ができる。
時間を切って、あらかじめ漏れのないように設計した11程度のテストケースを対象者が作った関数に通し、テストフレームワークを使って関数の仕様満足度を採点する。
プログラミングの経験年数で点数がばらつく。
採点結果を公表すると受講者達はとたんに目の色が変わり、用意した11のテストケースをクリアできるように関数を作り直し始める。
ここで、ほとんどの受講者が11のテストケースをクリアする100点の関数を作ってくる。

これは、受講生が小学生以来何度となくテストを通じて経験してきた、「ハードル見せて全部越えられるまでやってみろ、ほら、あっちの生徒は全部クリアできているぞ」という学習パターンを再現したものだ。

上記の作業では、仕様満足度が100%になるようなブラックボックスのテストケースを用意して、中身プログラムコードの内容について深く考えるより、テストケースを通すことが目的になってしまう場合が多い。とりあえず動くものを作ることを目標にするという学生にありがちなパターンだ。

そうなると、変数は必ず初期化してから使うとか、関数の出口は一つにするとか、フェイルセーフの設計を心がけるといった、設計の規範がおろそかになる。（大学のソフトウェア教育では、取りあえず動くプログラムを作るのではなく、設計の規範を教えて欲しいと切に願う。こちらの記事参照のこと。）

そこで、次に以下のようなアプローチを試みる。

11のテストケースをクリアした関数に対して、あらかじめ用意した「変数は必ず初期化してから使う」などの設計の規範に対する適合度を100点満点で点数化し、優良可不可の判定を行う。
大方の受講生はテストケースをクリアしていても設計の規範には十分に適合できていないため、可や不可の評価になる。
それまで自信満々だったのに落第と言われ、ちょっとしたショックを受ける受講生もいる。
場合によっては求めてもいないのに課題を再々提出してくる者もいる。
そこで、最後の最後に回答例と回答例の設計コンセプトについて解説講義をする。

最後の解説講義のときに、冒頭に掲げたSystems Engineer Vol.1 特集1 SEが20代で身につけておきたいこと(技術評論社¥1280円）の一節を紹介する。

【学生時代とはまったく異なる社会】
　周囲にいる同僚や先輩は、過去の背景が異なれば、現在やっている仕事も異なり、個別の価値観を持っています。背景がほぼ同じで評価は試験によるという、条件が平等だった学生時代の環境から、平等性を取り払われた途端に感じる不公平感からくる不満。また、学生時代とは異なり、「ああしなさい」「こうしなさい」と指示してくれる先生もいません。そのため、自分はいったいどうしたらいいのかと、途方にくれてしまうのが20代です。

【考え方の転換】
　学生時代は、履修科目をまんべんなく勉強していれば、いい評価を得ることができましたし、周囲が自分に期待している役割も明確でした。しかし、社会に出てソフトウェア技術者として仕事を始めた途端に、勉強すべき範囲は無限にあり、周囲からの期待も不明確になるため、自分の果たすべき役割は自分自身で考え、つくっていくことになります。それは、資格や職種など、「外から見た姿」をつくることではありません。自分の内側を成長させ、力をつけることです。

【勉強をする】
　優れたソフトウェア技術者や、勉強することが習慣になっているソフトウェア技術者は、勉強に対してまったく異なるイメージを持っています。
　まず、「勉強＝何かを覚えること」とは考えていません。学生時代と違ってテストはないのですから、読んだり聞いたりすることを、すべて頭に詰め込んでおく必要はないのです。
　システム開発・ソフトウェア開発という仕事は知的労働であり、ソフトウェア技術者は「考える」ことを求められる職業です。一つの事柄に対し、複数の考え方を持っていることは、思考を柔軟にします。

--- 引用終わり ---

新人技術者は長いことテストで評価されることに慣らされてしまっているため、会社に入っても先輩や上司が自分の成果物を事細かに精査し、よい評価になるまで付き合ってくれると考えてしまう。

ところが、多くの職場では関数の一行一行に対して、設計コンセプトにまで立ち入ってレビューしてくれることはほとんどないので、自分自身で自分の成果物の完成度をどこまで高めなければいけないのか考えなければいけない。（eXterm Programming のペアプログラミングは、先輩がコード一行一行に対してアドバイスできるので設計の規範を伝承する効果が非常に高い）

このとき大事なのは、たった一つの関数であっても揺るぎない設計のコンセプトや設計の規範をベースにしてプログラムの作成に望むことだ。設計の規範はプロジェクト内で、コーディングルールを示したり、コードレビューをする際にたたき込まれると思うが、ソフトウェア設計にはいろいろなケース、パターンがあるので、例外や規範を逸脱した方がかえってプログラムが読みやすくなったり、効率的であったりすることもある。だから、確固たる設計コンセプトが自分の中に固まっていないと迷う場面が出てきて自信をもって設計を進められない。安定したトレードオフを行うには設計の規範とともに、設計ポリシーや設計コンセプトが必要になる。

受講生の中には「どんどん指摘して欲しい」と言ってくる新人がいる。一見積極的でよい姿勢のように見えるが、実はヒントを与えた後じっくりと考えて、自分の成果物を洗練させてくる技術者の方が組織にとってはプラスになる。

前者は他人への依存性が高く、後者が自立しているということだ。テストで良い点を取ることに慣らされてしまうと依存体質になってしまうことが多い。

組込みソフトウェアエンジニアに求められているのは単に言われたことを実行する、仕様を満たすプログラムを作るということではない。たった一つの関数であっても、自分の成果物がインプリメントされた商品を使うユーザーに満足を与え、成果物の価値が市場で認められ、再利用に値する資産になっているかどうかを考えてソフトウェアを設計することだ。

もしかすると、それができるのは日本の組込みソフトエンジニアだけであり、職業プログラマしか確保できない地域ではこのようなアプローチはできないのかもしれない。職業プログラマしか確保できない地域では、要求仕様の漏れをなくす、プロセスを切ってインプット、アウトプットに不整合がないかどうかチェックするようなアプローチを取るしかない。しかし、日本の組込みソフト開発のように同じメンバーで同じ市場に同じような製品を投入し続ける環境であれば、自分の成果物がインプリメントされた商品を使うユーザーに満足を与え、成果物の価値が市場で認められ、再利用に値する資産になっているかどうかを考えてソフトウェアを設計することができる可能性がある。

そして、PDCAが上手く回ればがちがちにプロセスで開発に縛りをかけなくても、品質の高いソフトウェアをアウトプットできる可能性もある。

ただ、現在は組込みソフトも規模が大きくなって、複雑度が増しているので、このような取り組みだけでは品質を高めることはできないし、明確なコンセプトを持って設計ができるソフトウェア技術者が減っていくのなら、プロセスアプローチを強化するしかないだろう。

さて、新人教育の話題に戻ると、成果物の価値を最終的に判断するのは先輩や上司ではなく、エンドユーザーだと考えると、たった一つの関数でも設計コンセプトとして何を考えなければいけないのかが見えてくる。これを身につけるために有効なのは次のようなサイクルを回せるようにすることだ。

焦点をあてる問題領域を選択する
集中して作業できる環境を整える
エンジニアが達成感を感じる
改善点を冷静に分析し洗練させる

3の時点ではまずは動くものを作ることをめざし、その後、自分の成果物を冷静に分析して、自分の成果物がインプリメントされた商品を使うユーザーに満足を与え、成果物の価値が市場で認められ、再利用に値する資産になっているかどうかを考えて洗練させることができるかどうかが、非常に重要になる。

「改善点を冷静に分析し洗練させる」を実行するには精神的な余裕が必要だ。たった一つの関数の作成でもいい加減にせず、きっちりプロとしての仕事をして、その成果を積み重ねていけば、徐々に設計の効率が上がってきて精神的な余裕を作ることができる。だから、組込みソフトウェア技術者は最初が肝心だ。20代は負荷がかかったとしても設計の規範を身につけ、自立し、30代以降に成果物を洗練させる余裕を生み出せるように努力する期間だと思う。

【参考になる記事】

組込みソフトの品質を高めるには設計の規範が必要
スキルの伝承は8割以上の企業が不十分な状況
仕様は変化しやすいが、要求の寿命は長い
日本の組込みソフトの作り方の特徴
働くことの本質は貢献であるという考え方
アメリカ人と日本人

登録: 投稿 (Atom)