**********************************************************************
分科会 S3-b
テーマ：プロダクトラインへの道のり 実践するためのキーポイント
講師：安部田 章(九州日立マクセル)
      宇佐見 雅紀(イーソル)
      佐藤 洋介(デンソー)
      山崎 進(北九州カーエレセンター)
      吉村 健太郎(日立研究所)
日時：2007/08/31 10:40〜12:20
参加者数：30人程度
**********************************************************************

まず、チュートリアルで挙げた各テーマ(やや変更)のなかで、どのセクションについて
議論したいか挙手によるアンケートを取り、議論順序を決める。

PLへの移行=20+α人
    プロダクトラインと差分開発の違いって結局何か？
    プロダクトライン開発への移行の目安って？
PLとマーケティング=2人
    商品企画ってどんなことをしているのか？
    商品企画はプロダクトライン開発に生きているか？
PLと品質(非機能要求)=20-α人
    非機能要求を実現するためには？
    非機能要求を定義するにはどうすればいいのか？
PLと運用=7人
    スコープ外の要求が発生したらどうすればいいのか？
PLとアジャイル=8人
    agile開発では必要になりそうなものは先に作り込んでは
    いけないという原則があるが、PLと矛盾するのでは？

◎PLへの移行
    Q.プロダクトラインと差分開発の違いって結局何か？
        A.製品のバリエーションを開発するとき、同時並行的におこなわなければ
          ならないことが異なる(吉村)
        A.製品のスコープを考えて開発を行うのがプロダクトライン的な開発である(安部田)

    Q.プロダクトライン開発への移行の目安って？
        A.時間軸を固定して考えたとき、マーケットに対してパラレルに開発を行なう
          必要があるとき(吉村)
            Q.組織だけではなく、製品によってもPL移行の目安があるのでは？(山崎)
            A.その通りです(吉村)
        意見:プロダクトライン開発の一歩手前が差分開発である。差分開発抜きで
             プロダクトライン開発を行うのは無理がある。(吉村)
    Q.設計と実装間のトレーサビリティをどうやって取るのか？
        A.膨大なトレーサビリティの文書を作ったとしても管理したりロードしたり
          するのは困難(吉村)
        A.トレーサビリティマトリクスと呼ばれるものもあります(安部田)
        Q.要求にシリーズ番号、シリアル番号を付けていますか？(山崎, To会場): いる=3人
    
    Q.あらゆる製品に対応できるように可変性を配置しすぎることでデメリットが起こるのか？
        A.起こります。
        Q.うまい妥協点は？
    
    Q.派生製品を考慮して基盤製品を作らなければいいのではないか？
        A.派生製品を考慮する必要はない。基盤製品を分析して可変部分を適切に
          分析することが重要です。
        A先行開発でコア資産を作ることはある（戦略、マーケティングなどが関係）。

    Q.基盤製品からリファクタリングをしなければならないのか？
        A.現状ではそうせざるを得ない
        Q.じゃぁ、うまい手法は？
            A.経営戦略とも関係するので難しい。経営層を説得するためにも
              マーケティングが必要ではないのか？

    Q.コア資産を変更しなければいけないときがあるか？
        A.理想は変更ないほうがいいのだが、ビジネスを考慮すると手を入れざるを得ない。

    Q.コア資産開発、利用などでブラックボックス開発をしてしまうと、組み込み
      技術者が育たないのではないか？
        議論がありましたが、議事録NGにつき空白

◎PLと品質(非機能要求)
    Q.非機能要求の定義ってなんですか？(To会場)→(定義している人:0人)
    Q.きちんと非機能要求を書くってどういうことなんですか？
        A.担当者が気合いで書いている。

    Q.でちゃったミスはしょうがないけど、そこから非機能要求の定義を見直す
      アプローチはないか？

    Q.非機能要求を定義すると、何がうれしいのか？
        A.アーキテクチャ設計ができるようになります。
        A.アーキテクチャの評価ができるようになります。→評価できるように
          非機能要求を定義することが重要である。

    Q.非機能要求の評価って、どのプロセスでやればいいのですか？
        A.できればアーキテクチャでやりたいところですが、実際にはプロセスの
          各工程で実施します。
        （アーキテクチャ設計、詳細設計、テスト、各段階で評価できます）

    Q.非機能要求の種別に応じて、アーキテクチャ段階で評価できないものが
      あるのではないか？
        A.非常に難しい問題です。性質に応じてコア資産で評価したりすることもあるでしょう。
        意見：あまり品質などはコスト的にメリットがないので、できるだけ
              共通部分に埋め込みたい

    Q.非機能要求とグレード(車など)の関係は？
        A.共通部なので非機能要求では差はないのではないだろうか？
          やはりお客さんに見える機能で差を付けた方がいいと思う。

    Q.コストによる制約と他の非機能要求の関係はどうすればいいのか？

    Q.システムに対する制約をソフトウェアとハードウェアのどちらの制約に
      振り分ければいいのか？
        A.開発コストの意識をハードウェア屋さんに意識させなければならないのではないか？
        A.ソフトウェア屋さんの開発コストとハードウェア屋さんの製造コストを
          お互いが認識しなければならない

    Q.機能要求の評価は比較的見えやすいが、非機能要求の評価が人によって異なる
        A.重要度定めて、非機能要求を機能要求にすることで、目に見えるように
          することが重要
        A.ステークホルダ間の合意を得る努力をすることが重要ではないか？

以上です。