開発文書による組込みソフトウェア開発の見える化
ESD21 TPS/Agileソフトフォーラム
組込みソフト開発のカイゼン
2013年11月12日
名古屋大学 大学院情報科学研究科
附属組込みシステム研究センター(NCES)

山本雅基© Masaki YAMAMOTO

配付資料 ver.1
1

目次
1. ソフトウェア開発プロセス
2. 製造業成功の秘訣TPS
3. ソフトウェア開発プロセスと開発文書
4. システム開発文書の3S
5. 開発文書の3Sには文書技術が必要
6. 開発文書のTPS⇒人材育成＋プロジェクト推進
7. アジャイル考© Masaki YAMAMOTO

2

1. ソフトウェア開発プロセス© Masaki YAMAMOTO

3

ソフトウェア工学の成果「ESPR」
システム・エンジニアリング・プロセス
システム要求定義

システムテスト

システム･
アーキテクチャ設計

安全性
要求定義

安全性テストソフトウェア要求定義

ソフトウェア総合テスト

ソフトウェア･アーキテクチャ設計

ソフトウェア結合およびソフトウェア結合テスト

ソフトウェア詳細設計

ソフトウェア・
エンジニアリング・プロセス

システム結合およびシステム結合テスト

単体テスト
実装

ESPR(Embedded System development Process Reference)
ソフトウェア開発の標準類に組込みシステムに関連する項目を追加したプロセス（IPA/SEC）© Masaki YAMAMOTO

引用：IPA/SEC「改訂版組込みソフトウェア向け開発プロセスガイド」

4期待される効果
効果1：ソフトウェア・エンジニアリング– プロセス品質を向上する– 製品品質を向上する– 生産性を向上する

効果２：規格準拠– 参入障壁を乗り越える– 説明責任を果たす© Masaki YAMAMOTO

特に最近重視されがちISO26262, 9001…

5

導入が進むにつれて見えてきた
不都合な真実真のプロセス品質・製品品質・現場の意欲・・・

幻想？
日本企業

欧米の企業証明できる品質© Masaki YAMAMOTO

規格準拠は達成
しかし，エンジニアリングの効果は出ない

アジャイルについては最後に考察する

引用（一部改）：高田広章「機能安全と安全システム技術」NCES

6

2.製造業成功の秘訣TPS© Masaki YAMAMOTO

7

東洋の奇跡
国内総生産（兆円）
600

500

昭和31年
400
もはや戦後ではない
300⇒戦前の水準を超える
200

昭和30年ごろから，急速に経済成長を遂げた

100

平成9年度

平成7年度

平成5年度

平成3年度

平成元年度

昭和62年度

昭和60年度

昭和58年度

昭和56年度

昭和54年度

昭和52年度

昭和50年度

昭和48年度

昭和46年度

昭和44年度

昭和42年度

昭和40年度

昭和38年度

昭和36年度

昭和34年度

昭和32年度

昭和30年度0

元データ：内閣府1998年度国民経済計算
http://www.esri.cao.go.jp/jp/sna/data/data_list/kakuhou/files/h10/12annual_report_j.html© Masaki YAMAMOTO

8経済成長を支えた「製造業」
徹底的な品質の追求• メイド・イン・ジャパン
悪かろう・安かろう ⇒ 高品質・高性能・安価• 円高に対しても，国際競争力を維持– 1949年-1971年8月 1ドル = 360円
– 1971年8月 ニクソン・ショック– 1972年2月から変動相場制– 1980年 1ドル = 250円
– 1986年 1ドル = 160円
© Masaki YAMAMOTO

9品質管理の父 W・エドワード・デミング
１９００年 アメリカ・アイオワ州生まれ
１９２１年 ワイオミング大学 電気工学 学士号
１９２５年 コロラド大学ボルダー校 数理物理･数学 修士号
１９２７年 アメリカ農務省
１９２８年 イエール大学 物理･数学 博士号
学生時代に，ベル研究所でインターンシップ
１９３９年 アメリカ国勢調査局
１９４６年 ニューヨーク大学経営学部大学院
１９５０年 日本において「統計的プロセス制御と品質の概念」の講義
１９６０年 日本において瑞宝章を受章
１９８０年 米国NBCTV番組「If Japan can... Why can‘t we?」にて紹介
１９８１年 フォードにおける指導を皮切りに，米国各企業で指導
１９８７年 アメリカ国家技術賞を受賞
１９８８年 全米科学アカデミーが表彰
デミング賞（1951年-）
１９９３年 死去．享年９３
画像引用：日科技連デミング賞
http://www.juse.or.jp/deming/© Masaki YAMAMOTO

10品質は，プロセスで制御せよ
× 製品制御方式（テイラー）

F・テイラー(1856-1915）
米国，科学的管理法の父

開発工程
出荷
科学的管理法：ノルマの設定，標準化，成果主義 全数検査
マネジメント・スタイル：官僚主義○ プロセス制御方式（デミング）
開発工程
プロセスの制御
マネジメント・スタイル：民主主義

出荷
検査

品質の追求は，我が国で独自の発展を続ける© Masaki YAMAMOTO

11

TPS(Toyota Production System)• ジャスト・イン・タイム（JIT）– 必要な物を，必要な時に，必要なだけ造る（運ぶ）– かんばん• 自働化– 品質・設備に異常が生じた時，機械が自ら検知して止まり，不良品の発生を防止する– アンドン（電光表示盤）

プロセス制御の一つの完成形© Masaki YAMAMOTO

12

Pull system is the best
• Pull system– 必要なときに必要な材料や情報を，後工程が前工程に取りに行く• TPSを理解する上での重要な考え方– JIT• 後工程から前工程へ，かんばんが渡される．前工程はかんばんを発注書として受け取り，製品を加工し，後工程へ納入する– カイゼン• 「必要なときに必要な材料や情報」にムダはない

様々な場面へ応用が可能© Masaki YAMAMOTO

13

カイゼンにより日々進化（深化）• カイゼンには限りがない– 工程は，常にカイゼンされなければならない• 全員で取り組む– 設計者 ＋ 生産技術者 ＋ 現場の技能者• ちょっとした工夫– 例：同期台車（部品・工具を乗せた台車を連動）• 技術進歩– 例： e-かんばん（電子化．バーコード，ICチップ版も）カイゼンを継続⇒持続可能な成長© Masaki YAMAMOTO

14

三現主義
• 三現主義– 現地（現場） ：現地へ行く– 現物（現状） ：現物を知る– 現実：現実的であること• 机上の空論は非効率であるとの共通認識
カイゼンは三現主義に立脚して進める© Masaki YAMAMOTO

15

見える化
• 課題解決には，現物の可視化が必要– 現物を知る重要性は，三現主義で説かれている開発工程

プロセス制御のためには見える化が必要© Masaki YAMAMOTO

16

3S• 整理(Seiri)：必要なモノと，不要なモノに分類する• 整頓(Seiton)：直ぐに利用できるように定位置へ収める• 清掃(Seisou)：ゴミをとる• 目的
1. 事故を予防する
2. 気持ちよく作業する環境を整える
3. 作業効率を高める
4. 問題が起きたときに原因を発見しやすくする
ちなみに私は，工場実習時に現場の班長に「４」の目的を教え込まれ，なるほどと感動した事を覚えています．「３S」は「見える化」につながるのです．
© Masaki YAMAMOTO

17

３. ソフトウェア開発プロセスと開発文書© Masaki YAMAMOTO

18

「開発プロセス」は工学の成果
システム・エンジニアリング・プロセス
システム要求定義

システムテストシステム･アーキテクチャ設計

安全性
要求定義

安全性テストソフトウェア要求定義

ソフトウェア総合テスト

ソフトウェア･アーキテクチャ設計

ソフトウェア結合およびソフトウェア結合テスト

ソフトウェア詳細設計

ソフトウェア・
エンジニアリング・プロセス

システム結合およびシステム結合テスト単体テスト
実装

工業製品としてQCDを高い水準で管理する
Page 19
何か，見逃していませんか？
© Masaki YAMAMOTO

引用：IPA/SEC「改訂版組込みソフトウェア向け開発プロセスガイド」

19

つな「開発文書」が工程を繋ぐ
工程
システム･アーキテクチャ設計

ソフトウェア要求定義(補足)工程をアクティビティと呼ぶ場合もある© Masaki YAMAMOTO

ソフトウェア･アーキテクチャ設計

改訂し引用：IPA/SEC「改訂版組込みソフトウェア向け開発プロセスガイド」

20

プロセスは「開発文書」で満ちている
システム・エンジニアリング・プロセス
システム要求定義

システムテスト

システム･
アーキテクチャ設計

安全性
要求定義

安全性
テスト

ソフトウェア要求定義

ソフトウェア総合テスト

ソフトウェア･アーキテクチャ設計

ソフトウェア結合およびソフトウェア結合テスト

ソフトウェア詳細設計

ソフトウェア・
エンジニアリング・プロセス© Masaki YAMAMOTO

システム結合およびシステム結合テスト

単体テスト
実装

改訂し引用：IPA/SEC「改訂版組込みソフトウェア向け開発プロセスガイド」

21

製造業の智恵をソフトウェア開発へ• モノ作りの先輩である製造業に，謙虚に学ぶ• 次のキーワードを，ソフトウェア開発へ活かす
知恵の泉

TPSPull
カイゼン
三現主義
見える化
3S
今日は，時間が限られているので，「3S」を中心に取り上げます．
なお，「Pull」「三現主義」「見える化」には少し言及します．
© Masaki YAMAMOTO

22

４．システム開発文書の3S© Masaki YAMAMOTO

23

工学の根幹である開発文書の実態• 良質な開発文書が書かれていない– 分かりやすくない．曖昧さが残る ⇒ 品質，生産性の低下• 後工程で読まれていない– エビデンスに過ぎない ⇒ 開発に寄与しない，意欲低下• レビューで使われていない– 口先の言い訳が横行 ⇒ 技術に関心が集中しない• 管理者や経営者の開発文書に対する意識が低い– ソフトウェア開発に対する無知 ⇒ マネジメントの低下

工学的にソフトウェア開発を行う基盤が破壊され，開発プロセスの効果が発揮されない© Masaki YAMAMOTO

24

開発文書を書く技術者の現状• 学生時代に開発文書を書いた経験が少ない• 社会人になってから書き始める• プログラミングは好きだが，文書作成は不得意• 何を書けば良いか，本当はわかっていない• 既存の開発文書を真似て書いている• 他者の書いた文書には，分からないことが多い• 開発文書を書く自信がない…
「書きたくない」を放置していてはソフトウェア開発は工学にならない25© Masaki YAMAMOTO

ゴミのような記述が混じる開発文書• 文書は「整理」「整頓」されていない• 文書の「清掃」が行われていない

ゴミだらけの製造工場に等しい状況
知識労働に対する冒涜
TPSを推進する上での致命的な欠陥開発文書の清掃（朱を入れて書き直しを要求）事例© Masaki YAMAMOTO

26

知恵の泉

開発現場の立て直し• 製造業で培った智恵をソフトウェア開発へ適用する• まずソフトウェア開発現場を立て直す• 現場において最も基本である「3S」をソフトウェア開発に適用する

TPS
Pull
カイゼン
三現主義
見える化
3S

開発文書の3Sに取り組む
注：私は，掃除をしましょうと言っているわけではありません© Masaki YAMAMOTO

引用：http://www.sg-loy.com/3s/shitsuke/

27

システム開発文書の3S• 整理– 必要な情報だけが，十分に記述されている– 曖昧なことが書かれていない• 整頓

文書技術で，整理・整頓– 文書（電子ファイル，紙文書）が，整頓されている– 文書体系が整っている– 章構成が整っており，情報を直ぐに取り出せる– 論旨を読み取りやすい– 技術内容のトレーサビリティがとれている• 清掃– 文書の書き直し© Masaki YAMAMOTO

他者による清掃は朱入れ（後述）28

開発文書の 3S でQCDが向上する
3Sの目的をシステム開発に対応づけて解釈する
1. 事故を予防する–

仕様や設計の誤解釈を予防する

2. 気持ちよく作業する環境を整える–

欠陥を見つけ易い・仕様変更し易い環境をつくる

3. 作業効率を高める–

文書による必要十分な情報の受け渡しで，無駄な問い合わせや手戻りを回避する

4. 問題が起きたときに原因を発見しやすくする–

明確に技術内容を記述し，トレーサビリティが取れた文書があれば，欠陥の原因を見つけやすい

開発文書の3S活動は即効性がある© Masaki YAMAMOTO

29他者による文書の清掃＝朱入れ
朱入れの事例： 下記は指摘事例
朱入れでは，書き直すことも行われる．

朱入れを集約した情報を踏まえて技術者の傾向を分析し，教育カリキュラムを作成し横展開する
引用：開発中の演習教材に対する塩谷氏の朱入れ事例

朱入れ結果の活用： 集計し横展開
項番 指摘箇所
指摘種別
指導内容(1)～(8) 資 料 内 に 文・文章の表現 基礎的な記述力の育成が必要。特に多い問題点を示す。
(9) (14) 指示
基本表記ルール
・あいまい表現 ・修飾節のかかり受け(17)(18)
構成・展開
・主語の不在・2文に分けるべき長文(20)(21)
・見出しと本文の適切な関係記述
・用語の統一 ・用語の定義(7)
全体像とその中での開発対象の位置づけの記述が必要。
資 料 内 に 構成
指示
とくにシステムとプログラムの関係を明確にすること。

© Masaki YAMAMOTO弱点の傾向
30

５. 開発文書の3Sには文書技術が必要© Masaki YAMAMOTO

31

ソフトウエア開発の文書技術
定義：
ソフトウェア開発文書の作成・利用技術（ソフトウェア開発の見える化技術）
文書技術の訳： The Art of documentation
Art とした思い•深く思考し創作することを表現したい•文書技術には奥行きと広がりがある•美意識にも繋がる•体系化は今後の課題© Masaki YAMAMOTO

32

知恵の泉

何を書く
• 自分が生み出す付加価値の根源• 何を書くかを追求すれば，着実にソフトウェア技術力が身に付き，付加価値を高めることができる• コツは，読み手（後工程）を意識すること

TPS
Pull
カイゼン
三現主義
見える化
3S

– 自工程は後工程が必要とする情報の提供に応えると考えると，IEEE830やESPRの理解が深まる「後工程から Pull されること」を書くという視点を持つ© Masaki YAMAMOTO

33

どのように書く
感想文ではなく，実用文を書く• 必要十分な情報
• 論理的
我々は，
• 非あいまい
感想文を書く練習はしてきたが，実用文を書く練習はしていない．
• 無矛盾
実用文を書くための学び直しが必要• 変更容易• 追跡可能…
「どのように書く」は文書技術の基本© Masaki YAMAMOTO

34

文書技術の学習• 練習方法– 書籍を読む• TC協会「日本語スタイルガイド第2版」• 阿部「明文術 伝わる日本語の書きかた」 など– 実際に書く• まずは Email を明確に書くことから始める– 開発文書の３S活動を組織で行う（朱入れ文化の定着）• 環境を整える– 仕事における開発文書の価値や意味を再確認する– 経営者・管理者が率先して開発文書の重要性を示す• コミュニティを活用する– ASDoQ，TC協会など，文書技術に関する活動に参加する© Masaki YAMAMOTO

35

分かってきた効果的な朱入れ法• 初級者には「どのように」書くの指導が必要• 書き方から開発プロセス指導までの朱入れと，
ドメイン技術の指導を異なる者が行う• 朱入れ指導者は，プロセスの理解，論文の執筆経験，開発文書の作成経験などが必要• 書き直すよりも，指摘するだけの方が効果的
ドメイン技術指導は，上司や専門家の仕事© Masaki YAMAMOTO

36

６. 開発文書のTPS⇒人材育成 + プロジェクト推進© Masaki YAMAMOTO

37

知恵の泉

（１）朱入れを仕事に組込む

TPS
Pull
カイゼン
三現主義
見える化
3S

ドメイン技術指導は，上司や専門家の仕事• 朱入れを多角的に行う– 仕事で作成する開発文書に朱入れを行い，具体的に，「何を」「どのように」書くかを指導– アプリケーション・ドメインの技術指導は，上司やドメインの専門家が行う• 開発者は，朱入れを踏まえ開発文書を改訂⇒ 直ちに品質・生産性が向上 ＋ 人材を育成© Masaki YAMAMOTO

38

知恵の泉

（２）3S⇒5Sで成長し続ける• 診断（Shindan）

TPS
Pull
カイゼン
三現主義
見える化
3S5S

– 朱入れ（掃除）の実態を踏まえて，開発文書やそれを作成した技術者の課題を見いだす．

• 診療（Shinryou）– 診断結果に基づいて，技術者や組織を健全に成長させる
教育やコンサルティングを行う．
診断と診療を「文書診断」と呼び，教育やコンサルティングを行う事例がある．
参考文献
・塩谷敦子「理系のための文書作成術」CQ出版社
・藤田，山本，中澤，塩谷，池田，楡井「組込みソフトウェア開発文書診断法」
情報処理学会研究報告，Vol.2010-EMB-16，No.37（2010）

製造業の5Sは，開発文書の5Sは，© Masaki YAMAMOTO

整理・整頓・清掃・清潔・躾
整理・整頓・清掃（朱入れ）・診断・診療
39

知恵の泉

（３）コア資産をカイゼンし続ける• コア資産プログラムの開発文書に何度も朱を入れて，質を高める

TPS
Pull
カイゼン三現主義
見える化
5S– プログラムだけではなく，開発文書もコア資産にする– プロダクトライン開発の生産性が向上する
可変部

可変部

コア資産

可変部
コア資産の開発文書を育てる• 良質な開発文書は，社内教育でも活用可能© Masaki YAMAMOTO

40

知恵の泉

（４）開発文書で見える化・三現主義• 技術的成果（文書）を見える化せよ– ソフトウェア技術の本質は開発文書で表現される• ニコカレなども必要だが，開発文書を書いてからの話

TPS
Pull
カイゼン
三現主義
見える化
見せる化・魅せる化
5S– 「見える化」から「見せる化」「魅せる化」を目指せ• 三現主義能動的に仕事をする風土づくり– 文書が書かれた「現地（開発現場，人）」へ行け• 開発現場へ行き技術者と話し合え– 文書という「現物」を直視せよ• 要求定義や設計の内容を議論せよ– 文書に書かれた「現実」を無視するな• 何が決まり何がTBDかを見よ．現実を見つめTBDとなる真因を探せ© Masaki YAMAMOTO

41

７．アジャイル考© Masaki YAMAMOTO

42

知恵の泉

TPSで進化させる
TPSを実践してきた人々によるさらなる発展

TPSPullカイゼン三現主義
見せる化・魅せる化
5S• 要求仕様書で開発を「Pull」する• XPやScrumを従順に守るだけでなく組織に適合するように，プロセスを「カイゼン」する• プログラム（実装結果）だけにとらわれず，要求定義や設計の「現物」に立ち返る– 本当にその設計は技術的に優れているのか？

• 付加価値の本質である文書の「見せる化・魅せる化」– アジャイルは不要な文書の作成を止めよと言うだけであり，付加価値を生む開発文書の作成を否定していない• ソフトウェア開発の「5S」（診断・診療含む）を追求する

丁寧に開発文書に取り組むことが重要© Masaki YAMAMOTO

43

本資料に関するお問い合わせ先名古屋大学大学院情報科学研究科
附属組込みシステム研究センター（NCES）
山本雅基（やまもと まさき）
myamamoto@nces.is.nagoya-u.ac.jp© Masaki YAMAMOTO

44