SQiP2010 C1-3 半導体事業部製品紹介 半導体外販事業 SEPGによる ハードウェア開発プロセス改善事例 Automobile 半導体内販事業 Automobile Graphic PDA ヤマハ株式会社 Electronic Musical Instruments LCD/PDP TV 半導体事業部商品開発部プロセス支援G Mobile phone ○中村 直文 杉浦 聡 加藤 恒 Portable GPS ・H/W: チップそのもの（デジ タル、アナログ、混載） Audio Robot Amusement Copyright(c) 2010 Yamaha Corporation AV/IT ・S/W：チップ組み込み／顧客 システムに組み込み／コンテ ンツ制作用ツール 2 Copyright(c) 2010 Yamaha Corporation なぜH/Wのプロセス改善に取り組むことになったのか？ 当社でのプロセス改善取り組みの歴史 2000～ 2005 2006 2007 2008 2009～ H/Wの品質が良くなら ないとS/W側の努力 が報われない S/Wでのプロセス 改善の成功 <トータル的改善活動> “Opti@Doc” 生産移行後の不具合 これまでも改善活動を 実施してきたが なかなか成果が出ず <H/Wプロセス改善> “Opti@LSI” =H/Wプロセス改善 Qプロジェクト(2nd) Qプロジェクト(1st) ・兼任者による ボトムアップ ・開発計画の適正化と 計画外試作の撲滅 ・プロジェクト支援、QA、 プロセス改善により品質 向上 プロジェクトの遅延は 常態化 試作回数増加傾向に よりコストアップ H/Wにおいても 短納期化、モデル数増 への対応必須 <S/Wプロセス改善> “Opti@soft” “HSQC” ・継続的な改善活動 ・トップダウン的 ・専任SEPGを置く プロセス改善が経営課題であり、ビジネス成功の鍵 3 Copyright(c) 2010 Yamaha Corporation 改善活動の基盤作り(1/4) －体制－ 改善活動の基盤作り(2/4) 書式、ツール、 トレーニング、 メンタリング 改善 活動 ・ISO9001に基づきそれなりには回っ ているだろう ・ドキュメント化やレビュー文化はH/W の方が進んでいるであろう ・洗練されたプロセスの尺度が存在す るだろう ・先行開発や事前検討が重要であろう QA活動 プロセス の課題 標準（規定、 手順、ガイド） －改善手法－ まずはCMMIレベル２程度はやって当たり前。 レベル３やPMBOKも選 択的に。 ISO9001の既存の仕組みも利用。 まずは、現状分析から行い、段階的に成熟度を上げていく方針で 仮説に基づく改善 品質保証部の中の一機能として開発プロセスGが発足。 （当初メンバー：S/W担当３名、H/W担当３名） 支援、審査、改善の三本柱を定義（2010/5からは商品開発部内にチーム ごと異動） プロジェクト の課題 4 適用した改善手法（S/Wで用いた手法を適用） 体制（品質保証部門に改善活動推進の機能を置いた） プロジェクト 支援活動 Copyright(c) 2010 Yamaha Corporation ・エンジニアリング系プロセスは新た に勉強するしかないだろう（不安） ・要求仕様は比較的明確であろう ・ウォーターフォール型であろう（仕様 変更も少ないだろう） ・抵抗勢力はいるであろう 【主活動の定義】 【改善チームの体系図】 Copyright(c) 2010 Yamaha Corporation 5 Copyright(c) 2010 Yamaha Corporation 6 SQiP2010 C1-3 改善活動の基盤作り(3/4) －活動母体－ 改善活動の基盤作り(4/4) －コンサルティングの導入－ 改善活動の母体 コンサルティングの導入 改善活動は、ボトムアップでもなくトップダウンでもない、ミドルマネー ジャーを中心とした”ミドルアップダウン”で。 Topと現場の双方を巻き込み、効率的な改善を目指す。 →Opti(Organized Process and Technology Innovation)を結成 問題プロジェクトに対してはコンサルティングを導入し、個別の改善 活動を実施した 他事業部でS/Wプロセス改善の指導実績もあり当社の風土もよく 知っているコンサルタントに依頼 ＝社内他事業部のSEPGからの 紹介（社内の改善コミュニティは当社の強み！） Top ・品質方針 ・期待（必要な時に必要 な製品を顧客に！） ・改善状況の報告、提案 ・新たな仕組みへの参画要請 LSI Soft Doc Opti ・新しい規定・手順の教育 ・品質状況（試作回数、遅延） ・プロジェクト支援 ・トライアルへの協力要請 ・各種課題 ・ニーズ把握 ・トライアルへの協力 ・改善要求・提案 開発部門 LSI開発G 改善テーマ： 1 標準作業手順の整備 (標準作業テンプレートの整備) 2 変化点設計の確立 3 グループ全体進捗管理のしくみ確立 4 開発戦略、企画工程の確立 5 リスク管理の高度化 引用 ソフト開発G 7 Copyright(c) 2010 Yamaha Corporation 現状分析 －QCD－ ３回 QCD全てに関わる尺度として採用 予実績に大きな差 ●● ● 実 績 試 作 ２回 回 数 プロセスの遵守率は低調 計画外試作 ●● 品質管理に対する意識 不具合である、と確定した時点で 管理が始まる（解決してから登録す るケースも） ●●● ●●● ●●● ● １回 プロジェクト遅延 －風土－ 標準プロセスの遵守率 ● ●● ●● 8 Copyright(c) 2010 Yamaha Corporation 現状分析 計画外試作回数 ；http://www.microsoft.com/japan/office/2007/project/showcase/yamaha.mspx ほとんどのプロジェクトにおいて、初 期計画に対する遅延が顕著 1回 ２回 ３回 （不具合を発見してから登録するまでの日数 を測定） 計画 試作回数 プロジェクト遅延のばらつき ヒストグラム 登録遅れ日数 (登録日-発見日) 12 生産移行後に見つかった不具合 現場の声 遅延ゼロ 10 8 頻度 H/Wとしての改修が不可能なケースが目 立つ やむを得ず仕様化 6 「計画は天から 「なぜ計画 「作ってみな 降ってくる」 が必要な いとわからな の？」 い」 「いつも雑用 「もともと ばかり」 実現性が低い」 4 ソフトで修正 2 ランニングチェンジ 0日 1-5日 6-9日 10日以上 改善前 0% 20% 40% 60% 80% 100% 0 -300 -270 -240 -210 -180 -150 -120 -90 -60 -30 0 30 60 90 120 150 180 210 240 270 300 9 Copyright(c) 2010 Yamaha Corporation 主な改善テーマ 【課題】 計画精度が低い （計画軽視の文化） 商品企画プロセスの改善例 【改善テーマ】 計画の適正化と 意識改革 【具体的改善策】 ・マネジメントに適したツー ルをテンプレート化 ・リスク管理に関しては徹 底したトレーニング実施 実現性の低い状態で 開発開始される 商品企画プロセ スの改善 ・技術開発や実現性検討 は商品企画プロセスと並 行して行うように定義 開発に対する品質保 証体制が整備されて いない プロセスの再設 計とQAゲートの 設置 ・入出力の再定義とDRタ イミングの明確化 ・試作や生産への移行を QAゲートとして厳格化 Copyright(c) 2010 Yamaha Corporation 商品企画プロセスの改善 ・標準プロセスに則った書 式を準備。トレーニングも ・見積りが困難なプロジェ クトは３点見積りで 基本的なPM手 法の導入(リスク、 品質、課題) プロジェクトにマネジメ ントが存在しない 10 Copyright(c) 2010 Yamaha Corporation プロセス化して見える化 企画検討と技術検討を並行に行う リスク管理の高度化 商品企画段階でリスクを洗い出し 製品開発にリスクを持ち込まない 予防策とコンティンジェンシープラ ンを明確化 11 Copyright(c) 2010 Yamaha Corporation 企画開始レビュー 企画検討 技術検討 企画レビュー 技術レビュー 企画審査会 製品開発開始 12 SQiP2010 C1-3 適用したS/W改善手法や経験 改善活動の成果 計画書のテンプレート化 ： S/Wの書式を流用 QCD改善（計画外試作回数、遅延日数） 役割の明確化、工数見積り、マールストーン設定、リスク管理の重視 計画外試作回数 （2005年度を1とする） 不具合管理、課題管理 ： S/Wのツールをそのまま適用 遅延日数 （2005年度を1とする） 1.80 1.60 1.40 1.20 1.00 0.80 0.60 0.40 0.20 0.00 BTS(Mantis)やテンプレートの導入、インシデント管理という意識付け、信 頼度成長曲線や不具合分析にもトライ リスク管理 ： S/Wのツールをそのまま適用 リスク管理シート運用とトレーニング、実現性検討段階からリスク管理を 開始 1.20 1.00 0.80 0.60 0.40 0.20 0.00 2005 品質保証の仕組み ： S/Wのエッセンスを流用 2006 2007 2008 2009 2005 2006 2007 2008 2009 意識改革（プロセス遵守率、不具合登録日数） 作業成果物やマイルストンの監視、QAゲートを設けて品質リスク（小・中・ 大・NG）を提示 登録遅れ日数 (登録日-発見日) プロセス遵守率推移 1 0% 改善後 0% 8 測定と分析 ： まずは適正な尺度の選択を 0日 1-5日 6-9日 10日以上 0% 6 工数、試作回数、遅延日数、品質リスク 等 0% 4 改善前 Copyright(c) 2010 Yamaha Corporation 0 9/ 7 0 9/ 4 0 9/ 1 0 8/ 7 0 /84 0 8/1 13 08 /1 0 0 7/ 7 0 7/ 4 7 /1 0 07 /10 0 6/ 7 0 6/ 4 0% 06 / 10 0% 2 0% 20% 40% 60% 80% 100% Copyright(c) 2010 Yamaha Corporation 14 H/Wプロセス改善活動から得られた知見 （仮説と検証） 結論 ソフトウェア開発のプロセス改善手法はハードウェア開発に も適用可能（CMMIだけでなく、PMBOK、ISO9001、コーチ ング、ファシリテーション等との組み合わせで） しかし、 H/W特有のエンジニアリング系プロセスをある程度は理解 する必要がある（FMEA、FTA等の不具合の未然防止手法 なども） ISO9001に基づきそれ なりには回っているだろ う 既存の仕組みが存在するとやり難い面が・・ プロセスが冗長で目的化してしまっていた。 既存の業務プロセスを理解するのには役立った 文書化やレビュー文化 はH/Wの方が進んでい るであろう 文書化やレビュー文化はH/Wの方が進んでい る、という誤解 レビュー手法を知らないエンジニアは多かった 洗練されたプロセスの尺 度が存在するだろう PDCAを回し難い”品質目標”は存在した 良いモノサシをみつけることはやはり重要 我々の場合は計画外試作回数 先行開発や事前検討が 重要であろう 先行開発や実現性検討は確かに重要 不十分な実現性検討や技術確立できていない 状態での製品開発着手は非常にリスキー さらに、 商品企画プロセスや実現性検討プロセスの改善も実施す る必要がある Copyright(c) 2010 Yamaha Corporation 15 H/Wプロセス改善活動から得られた知見 （仮説と検証） エンジニアリング系プロ セスは新たに勉強するし かないだろう その通り。勉強するしかない FMEA、FTA、直交表を使う局面があるが、論理 的思考やS/Wテストでの経験は生かせた 要求仕様は比較的明確 であろう それほど明確ではなかった。出来高の場合も・・ 要求分析が不十分 やはり商品企画プロセスに問題。 ウォーターフォール型で あろう（仕様変更も少な いだろう） H/W開発はウォーターフォールとは限らず プロトタイピングに近い。仕様変更もあり。シミュ レーション技術が進めばアジャイルも可か。 抵抗勢力はいるであろう 改善活動に対しては普通は開発の現場が抵抗 勢力になりうるのだが 意外な抵抗勢力が・・ Copyright(c) 2010 Yamaha Corporation Copyright(c) 2010 Yamaha Corporation 16 最後に 自己の経験に基づく最近のプロセス改善に対する仮説： 製品開発の現場において、ハードウェア開発の成熟度よりもソフトウェア 開発の成熟度の方が高くなってしまった組織もあるのではないか？ ソフトウェア開発のプロセス改善を推進し経験を積んできた人達がミドル 層や経営に近いポジションに活躍の場を移しているのではないか？ 一方で、プロセス改善がビジネスや経営に貢献できることをうまく説明で きていないのではないか？ 以上を踏まえて SEPGは、改善のエキスパートとしてソフトウェア以外の領域にも 積極的に踏み込んでいくことをおすすめしたい ミドルアップダウンで、開発の現場だけでなくビジネスや経営に貢 献できるプロセス改善を！ 17 Copyright(c) 2010 Yamaha Corporation 18
© Copyright 2024 Paperzz
