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

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

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

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（品質機能展開）を使ったソフトウェア開発の方法論は、市場要求やユーザーニーズを分析して、商品の価値が最大になるような方向にソフトウェアを収束させようとする。これはまさに顧客満足を高めるための方法論であり、商品に求められる価値が異なる、業務ドメインが異なるソフトウェア開発でも顧客満足や商品の価値を最大にできるはずである。

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

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

モデル駆動開発

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もバグがないかとか信頼性は高いかとか考えないといけないのと同じように、アーキテクチャ変換ツールの信頼性について心配しなければいけない。

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

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

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

さて、技術評論社の 組込みプレス 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人も集まれば，それぞれの好みや癖により，ソフトウェア開発の方法論やアーキテクチャの選択に差異がでてきます．この差異を組織や会社間の上下関係により押さえつけてしまうこともできるでしょうが，それでは心技体の「心（技術者のモチベーションや改善への欲求）」や「体（チームビルディング力）」を下げてしまいます．

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

【引用終わり】

以上、宣伝でした。

インドのソフト会社

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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