車載ソフトウェア開発におけるプロセス改善 ( 株 ) 東海理化エレクトロニクス技術部中田武志, 日高建二 共同執筆 : 日本電気 ( 株 ) コンサルティング事業部福原綾介
目次 1. 会社紹介 2. 小規模ソフトウェア開発のプロセス改善 3. 改善後の開発現場に現れてきた気になる傾向 4. 小集団改善活動 5. 当社が考える小規模開発 1/20
目次 1. 会社紹介 2. 小規模ソフトウェア開発のプロセス改善 3. 改善後の開発現場に現れてきた気になる傾向 4. 小集団改善活動 5. 当社が考える小規模開発 2/20
( 株 ) 東海理化の紹介 会社名 : 株式会社東海理化 ( 商号株式会社東海理化電機製作所 ) 所在地 : 愛知県丹羽郡大口町 ( 本社 ) 設立 : 1948 年 8 月 30 日 資本金 :228 億円 (2010 年 3 月末現在 ) 売上高 ( 連結 ):3,310 億円 (2009 年 4 月 1 日 ~2010 年 3 月 31 日 ) 社員数 ( 連結 ):15,336 名 (2010 年 3 月末現在 ) 主要製品 : 自動車用各種スイッチ, 電装部品 国内拠点 海外拠点 3/20
目次 1. 会社紹介 2. 小規模ソフトウェア開発のプロセス改善 3. 改善後の開発現場に現れてきた気になる傾向 4. 小集団改善活動 5. 当社が考える小規模開発 5/20
小規模ソフトウェア開発のプロセス改善 自動車に搭載されるソフトウェアの開発量増加 より一層の信頼性向上が必要 CMMI モデルを活用し 小規模開発に向いたプロセス改善を実施することにした 一般的な大 中規模開発 管理工数 作業工数 小規模開発に大 中規模プロセスを適用した場合 管理工数 この割合では ソフトをつくっているのか帳票を作っているのか分からなくなる 管理工数 小規模開発が目指す工数割合 作業工数 作業工数 作業工数 > 管理工数作業工数 管理工数作業工数 > 管理工数 管理工数を抑えたプロセス改善 を目標の一つとして取組みを開始 6/20
管理工数を抑えるための仕掛け 例 1. プロジェクトの特性に応じてテーラリング 過去資産, 要求分析結果, 環境, 要員情報など 成果物とマイルストーンのガイドライン テーラリング結果 そのプロジェクトで実施すべき作業, マイルストーンが明確化される そのプロジェクトで何を実施すべきか迷わない 例 2. テンプレート 作業手順 ベストプラクティスを各成果物に用意 テーラリング結果 検証結果報告書の作成が必要 ソフト開発用 HP 検証結果報告書作業手順 検証結果報告書ベストプラクティス 検証結果報告書テンプレート 作成方法に迷わない バラツキの無い成果物判断ができる 7/20
管理工数を抑える仕掛けの効果 何を実施すべきか迷わない どの成果物を作成すべきか迷わない 成果物の作成方法に迷わない 開発計画 成果物構成などの検討時間の低減 バラツキの無い判断が可能 組織標準の制定 開発計画 成果物構成などの手戻り工数の低減 品質レベルが組織的に向上 維持され 管理工数が低減でき 当初の目的が達成できた 8/20
目次 1. 会社紹介 2. 小規模ソフトウェア開発のプロセス改善 3. 改善後の開発現場に現れてきた気になる傾向 4. 小集団改善活動 5. 当社が考える小規模開発 9/20
プロセス改善から約 2 年後 開発現場の一部に 気になる傾向 ( 意識の変化 ) が現れてきた この チェックだけど も関連すると思うが 調べたのか? 機能の設計作業は取り掛かれているか? の事はそのチェックシートに記載されていません 上流工程部署から制御仕様書が発行されていませんので 未実施です 確かにその通りだが 何故考えないのだろう? 手順通りなのになぁ ロジックだけでも提案して始めればいいのに 制御を文書化するのは上流の仕事 傾向 1 深掘りしなくなるのでは? このままだと 傾向 2 受身姿勢が当たり前になるのでは? これらが 品質低下, 手戻り工数増加に繋がる 10/20
意識変化の原因分析 特に新人 ~ 中堅層の一部で現れている ことに着目し 原因を分析した 深掘りしない 受身姿勢が当たり前 決められた事以外は積極的に取り組まない 関連する他の事に気付けない 仕様の提案ができない 役割 範囲が決められている 製品への意識が薄れている 手順で決められている スキルを表現できる機会が少ない 経験が少ない 他業務に関わる機会が無い 組織構成が分業する構成 今まで取り組んでいない事にチャレンジする場をつくる 1 他のプロジェクトのメンバーと改善検討をする 2 プロジェクトの実事例を題材にした討議を行う 3 多階層参加 ( ベテラン 中堅 新人 ) で改善検討をする 11/20
チャレンジする場の形成 1 他のプロジェクトのメンバーと改善検討をする 2 プロジェクトの実事例を題材にした討議を行う 3 多階層参加 ( ベテラン 中堅 新人 ) で改善検討をする 約 5 人のチームを構成し 小集団改善活動 を開始 各チームは プロジェクトを混合した構成 1 3 2 12/20
目次 1. 会社紹介 2. 小規模ソフトウェア開発のプロセス改善 3. 改善後の開発現場に現れてきた気になる傾向 4. 小集団改善活動 5. 当社が考える小規模開発 13/20
小集団改善活動の事例 1 テーマ 過去トラブル未然防止チェックシートに設計留意点追加 活動前 トラブル事例 事例と直結しないから非該当よ 原因と再発防止策 判定非該当 判定理由 類似例を考えて判定しなければいけない 同じ事例で考え方がバラバラ 活動後 トラブル事例 ねらい 原因と再発防止策 判定 判定理由 他のチェック観点 New 効果 関係が無いと考えていた事例でも 自分のプロジェクトでは何に気を付ければ良いかが分かるようになった 他のプロジェクトで行われている良いと思われる事例を 積極的に自分のプロジェクトへ取り入れる姿勢があらわれてきた 14/20
小集団改善活動の事例 2 テーマ 上流工程への積極的アプローチ 活動前 制御仕様書 制御仕様書 まだ完成していない 上流工程の仕事はよく分からない え ~ リリースが遅れるのはシステム屋のせい 活動後 New 制御仕様書 システム要求が分かってきた! 仕様提案 効果 責任を担う事によって 積極的に仕様提案ができるようになった 要求分析時の仕様疑問点抽出作業が軽減された ソフト開発者もエンドユーザー目線で仕様を検討できる良い機会となった どの工程でも積極的な提案をする姿勢があらわれてきた 15/20
小集団改善活動を終えて プロセス整備時代 現在 今後 管理者層, ベテラン層の 技術 失敗事例 ノウハウ etc プレッシャー 短納期でやれ ~ 失敗するなよ ~ ゴールまでの道が用意されている! プロセスに従って進むしかない! 小集団改善活動は 開発現場にこの道に気付いてもらい 実践してもらう活動 自分達が良いと思った事はドンドン提案しよう! より良いゴール プロセス ゴール 16/20
改善活動のポイント 1 プロジェクト / ベテラン層, 中堅層, 新人層を混合したチーム 2 テーマは 実事例を題材に各チームが自主的に決める 3 約 5 人単位で改善活動チームを構成する 4 チームリーダーはベテラン層にしない 5 各チームの改善検討結果は 開発現場へフィードバック 17/20
目次 1. 会社紹介 2. 小規模ソフトウェア開発のプロセス改善 3. 改善後の開発現場に現れてきた気になる傾向 4. 小集団改善活動 5. 当社が考える小規模開発 18/20
当社が考える小規模開発 小規模開発プロジェクトの特徴は 開発者全員が製品開発全体の把握ができる 開発者は要求 要件から製品の完成形をイメージできる ( 開発シナリオを描くことができる ) そして 小規模開発の現場は 開発シナリオを描ける開発者達が集まり 前後工程, システム全体を把握して共同で開発する場 開発メンバー全員の Synergy によって さらにより良いものを作ることができる 19/20
ご清聴ありがとうございました 20/20