中国オフショアソフトウェア開発 【株式会社クルー】

今年から中国人のブリッジエンジニアが東京、大阪、京都で合計13人になりました。

未だ全員が日本語完璧という状況ではありませんが、技術力が高いので日本のメーカーさんの好意で日本での業務とブリッジとしての業務をさせて頂いています。

最近はさらにUMLを使った開発が増えているようで、言葉の壁がさらに低くなったようです。

今後の彼らの活躍に期待ですね。

身内に不幸事があり、暫くブログ更新していませんでした。

最近の製品開発について、開発と評価という切り分け、連携で感じたことを書きます。

開発チームは評価チームを格下に見ている。

こういう場合、ほぼ１００％開発チームの技術力は標準以下です。

例えば、
　１．不具合の内容に対して、非効率的な調査要求をしてくる。
　２．再現方法を、こと細かに評価チームにレポートさせる。
などです。

自分で開発したシステムについて不具合報告があれば、大抵は想像が出来るはずです。想像できない設計、開発をしているのなら大問題です。

責任逃れをする為に、評価チームに無理な調査依頼をすることは、開発全体で非効率的で、不利益になります。こういう開発と評価のチーム関係は改善しなければなりません。

評価チームは不具合があったかも知れない？と報告をすれば良いのです。
不具合の無いシステムを開発するのは、開発チームの責任。
不具合が改修されなければ、評価チームは試験合格させなければ良いのです。

後は、開発チームが自分で調べて、改修して、評価をお願いするか、開発チームの責任で出荷してしまえば良いことで、評価チームは合格か不合格だけを開発チームに報告すれば良いのです。

でなければ、評価チームに協力を依頼するべきです。

開発チームは進んで、品質の良いシステムを開発する義務があります。
評価チームの評価が不十分なので不具合が直らない、品質が悪いなどと言うのは、『自分は能力がありません』と宣言しているようなものです。

開発がスムースに進んでいるプロジェクトでは、開発チームと評価チームの関係は対等か、評価チームの方が格上という感じがします。

思いつくままに書いてみましたが、如何でしょうか・・・。
　

今、メタフレームの環境を構築しています。

ファーム屋の私にしては久しぶりのサーバーに関係する作業となりました。

Windows2003Serverを使って、リモートディスクトップの機能を拡張した、サーバー＆クライアントシステムになるのですが、通常のWindowsアプリケーションをサーバーにインストールしておけば、クライアントにはアプリケーションをインストールする必要なく、今までと同様にサーバー上でアプリケーションを動作させることができます。

極端に言えば、100台のPCがあってもサーバー1台にアプリケーションをインストールすれば良いだけなので、運用管理は非常に楽になります。

バージョン管理も、ライセンス管理も個々に行う必要はありませんので、非常に手間が省けます。

ただ問題なのは、最初の環境構築の難しさにあります。どういう環境に導入するか、どういう構成で構築するかを誤ると、とても使いにくいシステムになってしまいます。

それでも、メタフレームは運用管理の便利さから魅力的ですね。
一度導入してしまえば、大幅に管理を手抜きすることができそうです。

中国は下請からパートナーへ、そしてライバルに！

多くの日本人が中国は単なる生産工場であると、未だに信じているようで情けなく感じることが良くあります。

中国が安い労働コストで生産工場を行っていたのは昔のことであり、安価で優秀なエンジニアが世界中を相手にビジネスをしかけてきています。

中国に技術を盗まれるという日本人に対し、他の国では中国に技術を提供しながら共同でビジネスを進めていました。そして、今では中国の技術をもって世界でビジネスを展開しはじめています。

日本は中国にとても近いというメリットがあるのに、何故か中国と上手くビジネスをやっている企業が少ないようです。

もう直ぐ、日本でなければならない開発というものが限りなく少なくなると予想しています。

日本の技術者はこれから先、どうやって中国、その他の国と付き合っていけばよいのでしょうか。。。

中国と親しくなることは今後の生き残りの為には必須かも知れませんね。

詳しくは、中国の技術開発力を味方に（日経エレクトロニクス2007年6月4日号）　をご覧下さい。

続きを読む »

ソフトウェアの品質向上は『設計』と『検証』のペアで実現させる

最近、ソフトウェアの品質について話題になることが多いと感じます。

特に評価・検証ビジネスはブームのようになっていますが、設計と評価・検証をトータルに考えないで評価・検証にだけ注力しても本末転倒になるだけだと考えているエンジニアは多いと思います。

私もそんな考えを持つエンジニアの1人で、2年前に設計から開発、評価・検証までをワンストップで行うビジネスモデルを提案したことがありました。

いくら評価・検証をきっちりやっても、ベースのソフトウェアの品質が悪ければ製品にはなりません。不良品を市場に出さないガードはできても、企業としては市場に出せる製品を作らなければ意味がありません。

となると、

１）設計では不具合の発生し難い設計を、

２）設計では評価・検証を考えた設計を、

３）開発では評価・検証の工数を減らすデバックを、

４）評価・検証では設計、開発時のデータをベースに抜け無く、無駄の無い評価・検証を、

と、全体を見渡して開発を行うことが必要だと思うのですが、皆さんは如何思われますか？

手法やノウハウは色々ありますが、これらが出来てソフトウェアの品質が向上すると私は考えています。

その手法の主なものは、『品質の可視化（品質メジャー／開発ガイドライン）』であると考えています。

組込みソフトウェア評価・検証サービス　のご紹介

やはり、ソフトウェアの品質管理には、品質の可視化は必須だと感じています。

それには、品質を見えるようにする手法とデータが必要です。

しかし、それだけで品質改善、品質向上が見込めるかというと、どうも不十分であることに最近気づきました。

開発工程、各種仕様書、ガイドライン。しかし、それ以外に必要なノウハウ。。。。

続き＞＞　ソフトウェア品質管理（３）

ソフトウェアの品質管理については、かなり昔から議論されてきましたが、未だ決定的な手法は見出せていないように感じます。

しかし、最近では決定的ではありませんが、かなりの成果が期待できる手法が形作られてきたような気がします。

それは何故かというと、20年近くもシステム開発を行っている中からの経験的な感触でもあるのですが、ある手法を行うことによって格段に不具合を減らすことができると実感したからです。

続き＞＞　ソフトウェア品質管理（２）