講演の様子

講演

1. ソフトウェア事業基盤専門委員会2006年度活動報告
2. 大規模化、短納期化、多機種開発にどう立ち向かうか
3. 質疑応答

1. ソフトウェア事業基盤専門委員会2006年度活動報告

• 組込み系ソフトウェア開発における品質施策および品質確保のための開発プロセスについて の調査結果の分析および課題解決に向けた提言。 ソフトウェア事業基盤専門委員会の 2006年度報告書 の要点を紹介したものである。

講演１

• 品質施策への提言
  • コストと効果を考慮した品質対策要
    • 費用対効果
    • 「品質とは何か」というゴールを設定した上での効果検証
  • 上流工程へシフトすべき
    • 品質対策はより効果の大きい上流工程へとシフト
    • 品質の定量化と計測・分析
  • 多機種開発への適用
    • 複数の派生製品開発を前提として、水平展開可能なツール整備
  • 品質関連標準化の共有
    • 品質に関する手法・ツールは外部委託先と共有
• 開発プロセスに対する提言
  • 大規模化に対応する開発プロセスの事例収集・展開
    • 88%のプロジェクトでソフトウェア規模は増加
    • 実践的な大規模化・再利用性向上の事例収集が必要
  • 多機種開発を考慮した開発プロセスの研究取組み
    • アーキテクチャ指向、ソフトウェアプロダクトライン等
  • アーキテクト育成が急務
    • 役割明確化と育成プログラム整備によって、戦略的に養成すべき

2. 大規模化、短納期化、多機種開発にどう立ち向かうか

• 2007年7月に開催された「IESE/ JEITA共同ワークショップ」で行われた『組込み系ソフトウェア開発の今後の進むべき道とは』と題したパネルディスカッションでの討議結果を発展させて、組込み系ソフトウェアの現状と開発現場で起こっている事例の紹介の後に、現状認識の重要性、今後の進むべき方向、日本の強みとしてのプロアクティブな擦り合わせへの挑戦が述べられた。

講演２

• 組込みソフトウェアの現状：デジタル家電
  • 小規模であった頃の開発文化を引きずりながら、デジタル化（機器制御→デジタル信号処理→ネットワーク化）による急激な規模拡大に遭遇
• 組込みソフトウェアの現状：車両制御
  • 車両制御システムの電子化が進み、制御ユニットソフトウェアが大規模・複雑化
  • 各社の取り組み
    • 開発効率向上：モデルベース開発、コード自動生成
    • 開発量削減：ソフトウェア再利用
    • オブジェクト指向設計、社内標準アーキテクチャ
  • 各社個別の対応に限界　→　業界標準によるソフト再利用へ
• 商品ライフサイクルの短縮：デジタル家電
  • アナログ家電：成熟期以降の製品寿命が長かった
  • デジタル家電：
    • 開発した機能の陳腐化が早く、常に付加価値部分を積上げての価格維持
    • 多様な顧客層への対応による機種の増加
  • 短納期化、多機種化の加速
• 現場で起こっていること (1)：
  • 小規模時代の開発のなごり、短納期のプレッシャから、コーディング主体の開発が横行
    • 以前の機種のソフトウェアをコピーし、必要な部分のみを修正・追加（差分開発、コピー＆ペースト開発）
  • 要求からコードへのブレークダウン過程が開発者の頭の中（属人的な開発）
  • 場当たり的な修正によるコードの複雑化
  • 機種開発数の増加、担当者の変更で急激に開発効率が低下
• 現場で起こっていること (2)：
  • 生産性向上には再利用が効果的であるが、再利用が有効に機能していない
    • 流用率は高いが、生産性は思った程向上していない
      • 修正箇所特定のためのコード解析に時間がかかっている
      • 修正による影響範囲が不明なための全体再テストと改造が繰り返される
  • 作ってからの再利用（アドホック再利用）の限界
• 現場で起こっていること (3)：
  • 分担のみ決まっており、全体把握ができていない
  • 曖昧な要求に基づき、全体構造が不明確なまま開発が進行
  • 分担間の仕様調整がｎ対ｎの掛け算になり時間がかかる、見切り発車的に実装が開始される
  • システムテスト工程で不整合多発。手戻り工数、テスト工数の増大を招く
• 有効な施策と現実のギャップ
  • 開発規模の拡大・多機種開発への対処として、本来は再利用が有効なはずだが、下流工程での擦り合せ開発が横行
    • 既存ソフトを流用、上手く行く筈・・・でも、現実には動かない！
    • 再利用は昔から叫ばれているが、現場に定着した例は？
    • キーマンが変れば、元の木阿弥・・・
  • 作ってからの再利用は効果が薄く、再利用を考えた戦略的な開発への発想転換が必要 →　『再利用を考えたアーキテクチャ設計とコンポーネント設計』
• 組込みソフトウェア開発の課題：まとめ
  • コーディング主体の開発形態が浸透
    • 小規模時代の開発のなごり、短納期のプレッシャ
    • 資源制約下での開発が長かったため、最適化のためのコーディング技法が重要視されてきた
    • 統合後の擦り合せが不可欠というハードウェア制御の特性が全体を支配
  • 全体を俯瞰する仕組みが確立されていない
    • 全体構造をコーディング前に確定するアーキテクチャ設計がなされていない、またアーキテクチャ設計を実施するアーキテクトが不明確
    • 組込み分野でのアーキテクトとしての要件が未確立であり、育成ができていない
  • トップダウン設計の全面採用は難しい
    • 擦り合せ開発の要素は排除できない
    • ハードウェア制御、日本の強みである擦り合わせによる高品質開発、集団合議による意思決定体制など
  • 既存資産を捨てることはできず、新アーキテクチャへの移行が難しい
    • 既存駅舎を使用しながら新しい駅舎に変質していくような）“新横浜駅方式”でソフト開発ができるか
• 現状認識の重要性
  • 開発レベルの認識とレベルに合った処方箋が必要
    • 個人中心開発の状況から、いきなり戦略的な再利用（プロダクトライン）には行けない
    • まだまだコード中心開発の現場が多いのではないか？
  • ｢コード中心開発｣から｢アーキテクチャ中心開発｣への移行にはエンジニアリングスキルが必要であり、大きなギャップが存在する
• 今後の進むべき方向
  • ステップ1：コード中心開発からの脱却
    • ボトムアップアプローチによる既存ソフトウェアの資産価値向上（リバース設計）
  • ステップ2：戦略的アーキテクチャ主導開発へ
    • 既存資産の設計・構造が明確になってから、はじめて、プロダクトラインエンジニアリングやモデル駆動開発の導入が容易となる
  • ステップ１、ステップ２を支えるアーキテクトの育成施策の確立が急務
• 日本の強み・弱み
  • 擦り合せによる高品質開発が日本の競争力の源泉
    • しかし、全体が見えない時点からの「アドホックな擦り合わせ」では、大規模化・短納期化に対応できない
  • アドホックな擦り合わせから、プロアクティブな擦り合わせへ
    • 組み合わせ（設計・アーキテクチャ力）の補完により、8割まですぐにできるようにする
    • 残りの2割を擦り合わせる
• 今後のJEITAの活動
  • 日本の強みを活かしたベストプラクティスの調査を実施

3. 質疑応答

• 上記の講演に対しての質疑応答が行われた。

質問を受けている講演者

• 組込み系ソフトウェア開発は世界のどこが強いのか?
  • 欧州が、米国に負けないという意思が働いて、頑張っている。東欧、インドへのオフショア開発も行われている。
• 中国や韓国などの日本以外のアジアで組込み系ソフトウェアの技術が進歩しているのではないか（日本は相対的に弱くなるのではないか）?
  • 確かに強くなっている。ハードウェアでは既に強い。ソフトウェアも強くなっていくと思われる。
• アドホックな擦り合わせからプロアクティブな擦り合わせへ、と言われたが、プロアクティブな擦り合わせの具体的な施策はどのようなものか?
  • 欧米では8割のところで出荷するといった感じではないかと推測している。残り2割をきちんとやることが強みになるのではないかと思う。
  • 具体的な施策は、これからソフトウェア事業基盤専門委員会でベストプラクティスの事例を収集するので、その後で考えていくことになる。日本全体で考えなくてはならないと思う。
• ハードウェアとソフトウェアの分かるシステムアーキテクトをどうやって育てて行けば良いのか?
  • 組込み系のアーキテクト育成は難しい。今後どうすれば良いかを調査して行きたい。
  • 一つの考えとして、システムアーキテクトは斯くあるべきという形でトップダウンに育てる方法もあるかも知れないが、現在のものをリバースエンジアリングさせて、あるべき構造のアーキテクチャを考えさせていく、構築させていく、といったことによって育てていくのも一つの方法かもしれない。
• ソフトウェア業界の元請け、子請け、孫請けといった下請け構造の中で、下請け層にアーキテクトの素質を持っている人がいてもそれが生かされないことがある。そうした実力のある人を採用していくにはといったあたりに切り込んで検討し、提言を行うといったことはないのか?
  • 個人的な意見であるが、そのような人材を擁する会社を子会社化して協力会社の壁を取り払うというアプローチと、そのような才能のある技術者がフリーエンジニアとして活動するという両極端のアプローチがあると思う。
  • 現状の教育はOJTが主で職人スタイル（背中を見て育つ）である。大学の教育で工学的なやり方の設計を教えて、6割とか8割程度は皆がやれるようにすることが必要ではないか。社会全体で考えるべきである。

質疑応答