会場の様子

講演

1. 開会の挨拶： ソフトウェア事業基盤専門委員会の活動について、
   ワークショップ2010の狙いと課題認識
2. 基調講演： 商品開発方法の革新策 - 前向き擦り合わせ開発と組合せ開発 -
3. 事例講演1： 組込みソフトウェア開発における設計改善の事例紹介
4. 事例講演2： 富士通の組込みソフト開発技術者から見た、擦り合わせ開発の強み
5. 事例講演3： 発電監視制御システムにおけるプロダクトライン構築事例

1. 開会の挨拶：ソフトウェア事業基盤専門委員会の活動について、
ワークショップ2010の狙いと課題認識

【ソフトウェア事業基盤専門委員会の活動について】

• ソフトウェア事業基盤専門員会の活動の出発点となった課題認識は、『擦り合わせなるものが日本の開発力の強みと言われているが、急激に増大している開発規模や短納期化の中で、「擦り合わせ」が強みになっているのであろうか。何を強くすれば、我が国の組込み系ソフトウェア開発力の国際競争力を強化し、真に我が国の強みの源泉たりうるものにできるのであろうか』であった。
• この課題認識に基づいた2005年度からの活動を総括して、2009年度までの活動内容の要点と今年度(2010年度)の活動の狙いについて、同専門委員会委員長 五味氏より紹介された。
  JEITAソフトウェア事業基盤専門委員会委員長 五味氏

【ワークショップ2010の狙いと課題認識】

• 2009年度のワークショップでは日本の組込み系の課題を中心に議論してきた。 そして今回は課題＝弱みだけでなく、強みもテーマに加えて、「日本型組込み開発における強みと弱み」をテーマにしたワークショップを開催した。
• 日本の組込み開発における強みと弱みとは何であろうか。どのようにすれば弱みを克服し、強みを拡大していけるのか。 これから、本ワークショップにおいて、開発者視点に立脚して、組込み系ソフトウェア開発の多様な特性/課題を、参加された方々との議論の中から明らかにしたい旨が同専門委員会副委員長 春名氏より紹介された。
  JEITAソフトウェア事業基盤専門委員会副委員長 春名氏

2. 基調講演：商品開発方法の革新策 - 前向き擦り合わせ開発と組合せ開発 -

• 「商品開発方法の革新策 - 前向き擦り合わせ開発と組合せ開発」をテーマにして、基調講演がプロセスネットワークの金子氏より行われた。
• 前門の虎（先進国）、後門の狼（新興国）に挟まれた日本が差別化できるのは擦り合わせ型アーキテクチャ商品群である。
• 前向き擦り合わせ開発と組合せ開発が成功への道である。
• 国際競争に勝つための対策 日本の戦略？！
• 擦り合わせ指向開発の重要性
• 擦り合わせは企画プロセスのレビューに参加し、戦略他を確認し、それに基づいた要求の定義・仕様の定義を行う。
• 前向き擦り合わせでは、要件分析を行い、レビューを行う際に擦り合わせを行う。
• 前向き擦り合わせではテスト工程間で何をテストするかなどについて擦り合わせを行う。
• 前向きな擦り合わせでは上流工程の段階で下流工程のためのテスト仕様書を作成し、上流工程の成果物のレビュー時のテスト仕様書と整合する。
• 商品戦略、市場戦略、顧客戦略、人的資源戦略で明確に行う。
• 利害関係者との前向き擦り合わせ、その成果物であるニーズ・期待について商品計画、プロジェクト計画、プログラム計画プロセスで擦り合わせを行う。
• 上流工程で擦り合わせを減らす方法として、ハードウェア技術、ソフトウェア技術およびシステム技術の出来る技術者を育成確保し、担当させる。
• 暗黙知が設計の際に多いと他の技術者との間で暗黙知の不整合による擦り合わせが発生することがある。
• マネジメントプロセスでは前向き擦り合わせはマネジメント課題ごとにリスクマネジメント技術を用いる。
• 擦り合わせから組み合わせへ、組み合わせから擦り合わせへ
• 革新のシナリオ「改革」「進化型：連続的改善」

プロセスネットワーク 　金子氏

【Q&A】

• 日本は擦り合わせ手法が強い、と言っているが、何故そうなったのか？
  なぜ日本は擦り合わせ手法を採用したのか？
  • 欧米と比べて日本のソフトウェア開発者の専門性は低く職人の分化であり、 経験的なやり方をしてきた。できたものを直して行くというやり方であり 擦り合わせが起きてくる。 どういう技術でどうやったかをきちんと説明できないとエンジニアリングには ならない。
• 組み合わせをやったほうが日本は強くなれるのか？
  • エンジニアリングによるアーキテクチャを開発するには組み合わせ型の 技術の方向で勉強する必要がある。組み合わせ型の技術を修得した上で 擦り合わせを行なうことが成功に繋がる。擦り合わせだけでは 職人のやり方になってしまう。
• 8割方を組み合わせで残り2割を擦り合わせで開発するという考え方は間違っていないか？
  • 設計工程では合っているが、その前の要求段階ではお客様との 擦り合わせが成功の秘訣である。
• 「擦り合わせのスタート地点を変える」「日本人は決めないで帰る」 ということを講演されていたが、そもそもこれらの対応は日本企業の 文化的に不得意であると思う。どうやって変えていけば良いのか？
  • プロジェクトの中で絶対的な存在になることができる人材を 英才教育し、その人材がプロジェクトを担わせること（即ち絶対的 エリートをプロジェクトに配置すること）をしないと、いつまで たっても擦り合わせ手法は減らない。 集団合議的な活動では上流工程の改善は困難である。
• 優秀な人材はどうやって確保するのか？
  • 優秀な人材は経営者自ら面接などを行い選抜するしかない。 大学の授業で何を一番充実してやったかを聞く。その答えで 職人型に行くのか、アーキテクチャ型に行くのか判断できる。 マネジメントは高校時代の価値観。技術者の素質は大学時代に 培った価値観で決まる。

3. 組込みソフトウェア開発における設計改善の事例紹介

• 組込みソフトウェア開発における設計改善の事例〜大規模リファクタリングによる設計改善〜について、リコーの牧氏より紹介された。
• デジタルカメラ開発の特徴
• 従来の開発
• ソースコードの再利用
• ソースコードの再利用(Clone and Own)の問題点
• 目指す姿：変動点の明確化
• 目指す姿：設計プロセス・共通資産の確立と製品からのフィードバック
• 複数機種の開発効率向上の必要性
• 設計構造改善とは？
• アーキテクチャリファクタリングによる設計構造改善
• 目標アーキテクチャ：レイヤ
• 大規模リファクタリング：実際にやったこと・改善の効果・効果の持続
• 設計改善を成功させるには・・やりつづけこと、目指す姿の共有、マネージャーの理解、強力な推進者の存在

リコー　牧氏

【Q&A】

• 共通資産を永遠に共通資産として扱うことは稀だと思うが、共通部として活用可能な期間を教えて欲しい。
  • 何年も持たせるのは厳しい。デジカメでは1年位である。 １年というのは商品企画が見える期間で、どこが変動するのかが わかり設計として作り込んでいくことが出来る。
• １年経つと全部作り変えるのか？
  • そうでは無く共通部分は使う。但し共通部分の範疇は変わるので 共通部分の鮮度を保つために変えていく。
• この活動を行ううえでのメトリクスとしてどのようなものがあるか？
  • 静的解析のサイクロマティック複雑度やコーディング規約の ガイドラインからの逸脱度などを測定している。
• 好ましくない依存関係を測定した後、実際のコード修正は 　　どのようにしているのか？ルールやプロセスはどうなっているのか？
  • どのように直すかは特にガイドラインは設けていない。 担当者によっては問題になることもある。

4. 富士通の組込みソフト開発技術者から見た、擦り合わせ開発の強み

• 「富士通の組込みソフト開発技術者から見た、擦り合わせ開発の強み」のテーマで富士通九州ネットワークテクノロジーの撰氏より講演が行われた。
• 通信機器の組込みシステム開発の課題
• マルチコア・フレームワーク開発の取組み（プロダクトライン開発のコア資産としてタスク管理通信手段を隠蔽するフレームワークを開発）
• 擦り合わせ型の製品開発としての強みの源泉が何処にあるのか？（日本と英・米の組織文化の対比を通して考察）
• 組込みソフト開発の特殊事情
• 組織文化の比較 日本 v.s. 米（英）
• インタフェース改善を擦り合わせる速さ
• 疎なインタフェースを適切に（無用な擦り合わせ削減）
• 組織の垣根を越えて歩み寄り（組織同士擦り合わせ）
• 英・米の開発組織、日本の開発組織：擦り合わせ易さ考察
• 擦り合わせ型の製品開発としての強みの源泉が組込みソフト開発の何処にあるか？
  ハード/ソフト間、機能間のインタフェース策定時・性能確認時にある。全体最適を考え機動的に動ける組織(連携)が鍵。

富士通九州ネットワークテクノロジーズ　撰氏

【Q&A】

• 「対話」と「擦り合わせ」の定義の違いをもう少し詳しく教えて欲しい。
  • 「対話」することは「擦り合わせ」の一部と考えている。 インターフェースが合わないときに、合わせることによって 最適な状態に持っていくことが擦り合わせの一部と考えている。 「Nonアドホック」な対話は日本型が良く、「アドホック的」な対話は 英米型が良いと考えている。
• 今後ソフト開発を海外にアウトソースすることを考えたときに、日本的な擦り合わせは有効なのか？
  • グローバルな開発では、アウトソース先とは対話密度が低い 為、インタフェースを組み合わせ型にしておかないと仕様や インタフェース擦り合わせに時間が掛かるので駄目である。 如何に「擦り合わせ」易くするかについて発表したが、組み 合わせ型も必要である。逆に英米でも組み合わせ一辺倒と いう訳ではなく擦り合わせもやっているという理解。
• 英米を同じ文化で評価しているが、英と米の文化の違いはあるか？
  • 英国での経験から英国は直ぐにはアドホックにはならない。 日本に似ているところがある。アメリカほどオープンではない。 というところに違いがある。 個人主義、専門力主義、流動的な雇用、などでは同じである。 アドホックな対話ということでは英国とアメリカは違うが 英国は日本とアメリカの中間（アメリカ寄り）に位置すると思っている。

5. 発電監視制御システムにおけるプロダクトライン構築事例

• 「発電監視制御システムにおけるプロダクトライン構築事例」として、東芝の小田川氏より講演が行われた。
• ソフトウェアプロダクトラインとは
• 先行流用開発（システム複雑度の増大）からプロダクトライン開発（コア資産と製品を分離）
• ソフトウェアプロダクトライン殿堂入り（ドメイン固有言語（DSL）構築とコア資産化、事業的成功、学術的貢献）
• 発電プラントの概要
• 発電監視制御計算機システムの特徴（長期開発・長期保守・プラント・顧客運用の差異の機能への反映、実プラント挙動への柔軟な対応）
• 発電監視制御計算機システムの構成例・変遷(OS/ハードウェアの変化に応じたソフトウェア開発)・機能（プラント自動化）
• プロダクトラインの構築
  • プラント自動化機能の概要・歩み(操作をカード形式で表現)
  • プラント自動化機能の構築（発電用DSLの構築、自動化用テーブル設計の品質・生産性向上、プラント全自動化運転の実現）
• ソフトウェアプロダクトラインとしての特徴
  • ソフトウェアのコア資産化
  • 自由度の高いシステム構築
  • プロダクトライン型開発工程
  • コア資産の管理（倉庫管理）（構成管理）
• 発電監視制御計算機システムに、徹底したＳ／Ｖ（Standard/Variable）分離によるプロダクトラインを構築

東芝 　小田川氏

【Q&A】

• プラントテーブルがプラント固有で修正時はテーブルのみ変更 ということだが、変更はどこまで許されるのか？ データだけか、項目を追加しても良いのか？
  • どちらも可であり、最終的にきちんと動くということに 変えていく。ステップを変えていくということもあり得る。
• インタープリタも項目を追加することで処理も変わっていくのでは？ 　　処理も固有の部分に入っていくのでは？
  • 想定外の処理は作らないといけないが、一般的な運用は事前に 整理しているので、インタプリタは原則として共通部のままで運用している。
• 共通部はシステム毎のANDをとったものを目指しているのではなく、 あれもやるかもしれない、これもやるかもしれない、といった ORを想定して作っているのか？
  • 共通部コアとしてはORとして持っている。
• コア部の試験はどうやっているのか？ プラントでの結合試験ででたバグ改修はどうしているのか？
  • 新規開発のコア対象の試験としては、できるだけ大きなシステムの データを使って試験を行い、その後プラントシステムとしての 製品試験を行う流れで試験を行っている。バグ発見時は当然、水平展開を行う。
• コアを長い間、流用し続けていると、バグが出た時に影響の出る システムとそうでないシステムが出てきて、ソフトのバージョンが 膨大になって管理が出来なくなってしまうのではないかと考えるが、 そういうことは起きていないのか？
  • 起きていない。何処にどのようなシステムが入っているかは管理できている。
• バグの改修が適切に行なわれないで問題になることは無いのか？
  • バグが発生したときに影響する資産/システムの情報を即座に把握 できるようにしている。この管理システムによって、バグ未改修 の資産をリリースするようなことは無い。