改善活動事例発表

組込み系ソフトウェア開発現場におけるプロセス改善～品質向上、生産性向上を図る
現場の改善施策と今後の課題～
2007年7月3日
セイコーエプソン株式会社
ビジネス機器事業推進部
川瀬 真

対象製品の紹介
セイコーエプソン株式会社
ビジネス機器事業部 ビジネス機器事業推進部
ＴＭ（ターミナルモジュール）のファームウェア開発（レシートプリンタ、ラベルプリンタの開発）
業務用小型プリンタのファームウェア開発
・レシート・ラベル・チェック
開発対象としての特徴と課題・派生商品開発が多い（顧客要望への対応）
・ハード環境に合わせ開発を行っている（メカ、ＡＳＩＣ・・・）・人（チーム）、機種に依存した構造

2007/7/3 IESE/JEITA共同ワークショップ

2

はじめに


品質と生産性向上には効果的な開発プロセスが必要
プロセスを設計する技術の取得

品質向上には上流工程の改善が必要
要求を仕様化する技術の取得

ソフトウェアプロセス改善には継続した活動が必要
継続のためにルールを作る



改善を実施するためには計測が必須
計測結果を分析しフィードバック 技術・知識の導入
知識を取得して、練習し、実践する機会を設ける。
 プロセスを設計する
設計の工程を事前に見える化、個人のノウハウを見えるようにする。
 要求を仕様化する
上流工程の品質を向上させる。
 できたことをルール化する
後戻りしない仕組みを組織内に作り込む

2007/7/3 IESE/JEITA共同ワークショップ

3

目次
１．知識と技術の導入
２．プロセスを設計する
３．要求を仕様化する
４．計測する
５．プロセスを見直す
６．改善を継続する
７．課題・・・・これから
2007/7/3 IESE/JEITA共同ワークショップ

4

１．知識・技術の導入


自前の技術やり方からの脱皮
外部にある優れた技術に触れる機会を設ける
知識を練習で実践できるものに・・・取得して：練習して：実践

知識取得のために外部講師を招いてセミナー（知識の取得）
２年間延べ人数６００名の講習



セミナー内容を実践する演習（練習）実プロジェクトをベースにした演習（３名チームを６組）
実行力のあるメンバーを指定して練習の機会を与えた



新しい技術と考え方の必要性を啓蒙する活動
技術交流会・・・外部の先進事例に触れる機会（社内外含めて実施）



計測の必要性を理解してもらう啓蒙活動
計測しなければ結果の良し悪しは判断できない

設計プロセスを構築できる技術の必要性を理解してもらう啓蒙活動
プロジェクトの進め方を明確にしなければ計画はできない
リーダーによって成果の良し悪しが分かれる・・・人に依存する

2007/7/3 IESE/JEITA共同ワークショップ

5

１-１．知識・技術の導入
演習を基本にしたセミナーの計画

セミナーと演習をセットにして得た知識を練習する場の提供
2007/7/3 IESE/JEITA共同ワークショップ6

２．プロセスを設計する


個人のスキルに頼ったプロジェクト推進からの脱皮
設計プロセスを見えるようにする
優秀なリーダーのやり方が残る担当したプロセスの成果を誰が（どのプロセスが）使うのか見える

同じ製品でも参加メンバーが変わればプロセスは変わる
全く同じプロセスはない・・・内因･外因で変わるプロセスはプロジェクト毎に設計しなければならない

プロセスを定義する
設計手順を明確にする
プロセスが必要な背景を明確にする



成果物を定義するプロセスが出力するアウトプットを明確にする

プロセス設計を補助するツール・・プロセスフローダイヤグラム
プロセスと成果物の関連を見せるフロー
フロー図を描く事が目的ではない・・・プロセスと成果物の関連を明確にする

2007/7/3 IESE/JEITA共同ワークショップ

7

２-１．プロセスを設計する
プロセス・フロー･ダイヤグラム（ＰＦＤ）

作業をプロセスと成果物の連鎖で表現する
2007/7/3 IESE/JEITA共同ワークショップ

8

２-２．プロセスを設計する
プロセス定義・成果物定義

プロセスと成果物を明確にする
2007/7/3 IESE/JEITA共同ワークショップ

9

３．要求を仕様化する

曖昧な要求から設計する手法からの脱皮要求を仕様化する（誤解を生まない記述）
あいまい性を排除することで手戻りをなくす

要求の背景を明確にする
後に仕様を確定した理由が理解できるようにする



要求仕様のレビューを充実する
曖昧な仕様の排除
曖昧な表現の排除
要求の漏れを検出

要求仕様書が評価仕様書
評価の確実性を確保する



要求仕様をベースに設計の漏れを検証
設計の漏れによる手戻りをなくす



要求の漏れを検証
後の仕様変更による手戻りをなくす

2007/7/3 IESE/JEITA共同ワークショップ 10

３-１．要求を仕様化する要求仕様書サンプル要求の背景を明確にする
１行に１つの仕様を記入する
2007/7/3 IESE/JEITA共同ワークショップ 11

４．計測する


結果の良し悪しを判断できないやり方からの脱皮
自分の実績を数値で残す
定性的な評価を定量評価に変える

工程単位の工数計測作業の実績を計測する
ドンブリ勘定からの脱皮→見積もり精度の向上



障害の計測
曖昧な仕様が手戻りを発生させている事実を知る
障害の発生原因を分析してプロセスの改善

自分たちの能力を知るためには計測が必須
工程別の工数実績
障害の発生原因
ソースコード品質
生産性

2007/7/3 IESE/JEITA共同ワークショップ 12

４-１．計測する
計測結果例示
35%

30%

25%

20%

15%

10%

設計・レビュー
実装・レビューの各プロセスに欠陥がある可能性が高い
このプロセスにある不具合原因を改善できれば、６割の手戻りを削減できる。

アルゴリズムミス実装設計モデリング
要求仕様実現漏れ
要求分析
その他
設計モデリング
アーキテクチャ設計
評価ミス
パッケージインタフェース調整
不具合修正
タイプミス
仕様変更
デバッグ
評価設計
分析モデリング

5%0%

障害発生の原因別分類
2007/7/3 IESE/JEITA共同ワークショップ 13

５．プロセスを見直す

同じ過ちを繰り返さない
他の良い事例を見せることができる
間違ったやり方（プロセス）がわかる



実施したプロセスが見えるようになる
リーダー個人に依存していた推進方法からの脱皮
個人の持っていた暗黙知が形式知になる

プロジェクトメンバー全員の理解度が向上する
自分の成果物が何に使われるのかが見える
自身の遅れがどこに影響するかが見える

計測結果を分析しプロセスにフィードバック
障害発生原因から見直すべきプロセスを特定できる
次回のプロセス設計時に対応施策を入れ込むプロセス以外の原因に対する必要な施策が分かる
例えばレビュー技術の向上、育成など
設計プロセス以外の要因に対応する施策が分かる

2007/7/3 IESE/JEITA共同ワークショップ 14

６．改善を継続する

データを基にした改善
データを基にした分析ができる
効果を数値変化で表現できる

プロセスを見直しする
実績をベースに何が良かったか？
実績をベースに何が悪かったか？

上流工程でするべきことが分かる
下流工程の不具合は上流工程に原因がある

プロジェクトのポストモーテムで計測データを活用
プロジェクトの振り返りに説得力のある数値が使える

プロジェクト実績データを収集公開する
過去のデータ・他プロジェクトのデータが参照できる

結果をベースに目標値を設定し改善する
改善目標は過去の自分自身を対象・・・納得性のある目標設定
例えば部門の目標計画に反映・・・水平展開

2007/7/3 IESE/JEITA共同ワークショップ 15

７．課題・・・これから改善を計測する仕組みを洗練する
変わっていく環境に対応する外部の知識を取得し仕組みの改善を図る！



プロセスを設計する異なるドメインでも使える標準化が必要では？
プロセス定義、成果物定義の粒度をあわせる必要はないか？
共通で使用できる雛形を作りたい！

要求仕様書の標準化及び粒度の統一要求仕様書が品質を向上させている・・・見合った工数でできたか？
時間をかければ品質は上がるが・・・・
どの粒度まで落とせば良いのかメジャーを作りたい！



計測する項目の継続的な見直しが必須
現在の数値データは絶対値か？
相対的な数値では効果を表現できないのでは？
改善の効果を定量的に表現できないか？
生産性を表現できる数値を持ちたい！！
2007/7/3 IESE/JEITA共同ワークショップ 16

最後に

小さくても良いので改善のサイクルを回す
仕組みを作れば自然に改善が回る
人に依存しない仕組み・・・・改善リーダーが代わっても継続できる

できたことをルール化して定着
ルールはできたことを後戻り防止のために作るルール自体も改善の対象

基本は設計して計測して見直す
設計しなくては計測の項目が分からない
計測しなくては効果は把握できない
計測の背景を明確にしないと協力してもらえない

改善の仕組み自体も改善の対象
環境が変われば仕組みも変わらなければならない

2007/7/3 IESE/JEITA共同ワークショップ 17