インドのソフト会社

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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