開発文書による...

© Masaki YAMAMOTO

開発文書による組込みソフトウェア開発の見える化

ESD21 TPS/Agileソフトフォーラム組込みソフト開発のカイゼン

2013年11月12日名古屋大学大学院情報科学研究科

附属組込みシステム研究センター(NCES)山本雅基

1

配付資料 ver.1

© Masaki YAMAMOTO

目次

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

2. 製造業成功の秘訣TPS3. ソフトウェア開発プロセスと開発文書

4. システム開発文書の3S5. 開発文書の3Sには文書技術が必要

6. 開発文書のTPS⇒人材育成＋プロジェクト推進

7. アジャイル考

2

© Masaki YAMAMOTO

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

3

© Masaki YAMAMOTO

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

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

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

安全性要求定義

安全性テスト

ソフトウェア要求定義

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

ソフトウェア詳細設計

システム要求定義

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

実装

単体テスト

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

ソフトウェア総合テスト

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

システムテスト

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

© Masaki YAMAMOTO

期待される効果

効果1：ソフトウェア・エンジニアリング

– プロセス品質を向上する

– 製品品質を向上する

– 生産性を向上する

効果２：規格準拠

– 参入障壁を乗り越える

– 説明責任を果たす

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

5

© Masaki YAMAMOTO

導入が進むにつれて見えてきた不都合な真実

証明できる品質

真のプロセス品質・

製品品質・

現場の意欲・・・欧米の企業

幻想？

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

日本企業

規格準拠は達成しかし，

エンジニアリングの効果は出ない

6

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

© Masaki YAMAMOTO

2.製造業成功の秘訣TPS

7

© Masaki YAMAMOTO

東洋の奇跡

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

0

100

200

300

400

500

600昭

和30

年度

昭和

32年

度

昭和

34年

度

昭和

36年

度

昭和

38年

度

昭和

40年

度

昭和

42年

度

昭和

44年

度

昭和

46年

度

昭和

48年

度

昭和

50年

度

昭和

52年

度

昭和

54年

度

昭和

56年

度

昭和

58年

度

昭和

60年

度

昭和

62年

度

平成

元年

度

平成

3年度

平成

5年度

平成

7年度

平成

9年度

国内総生産（兆円）

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

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

8

© Masaki YAMAMOTO

経済成長を支えた「製造業」

徹底的な品質の追求

• メイド・イン・ジャパン

悪かろう・安かろう ⇒ 高品質・高性能・安価

• 円高に対しても，国際競争力を維持

– 1949年-1971年8月 1ドル = 360円– 1971年8月ニクソン・ショック

– 1972年2月から変動相場制

– 1980年 1ドル = 250円– 1986年 1ドル = 160円

9

© Masaki YAMAMOTO

品質管理の父 W・エドワード・デミング

１９００年アメリカ・アイオワ州生まれ

１９２１年ワイオミング大学電気工学学士号

１９２５年コロラド大学ボルダー校数理物理･数学修士号

１９２７年アメリカ農務省

１９２８年イエール大学物理･数学博士号学生時代に，ベル研究所でインターンシップ

１９３９年アメリカ国勢調査局

１９４６年ニューヨーク大学経営学部大学院

１９５０年日本において「統計的プロセス制御と品質の概念」の講義

１９６０年日本において瑞宝章を受章

１９８０年米国NBCTV番組「If Japan can... Why can‘t we?」にて紹介

１９８１年フォードにおける指導を皮切りに，米国各企業で指導

１９８７年アメリカ国家技術賞を受賞

１９８８年全米科学アカデミーが表彰

１９９３年死去．享年９３デミング賞（1951年-）画像引用：日科技連デミング賞http://www.juse.or.jp/deming/

10

© Masaki YAMAMOTO

品質は，プロセスで制御せよ

開発工程

全数検査

出荷

× 製品制御方式（テイラー）

○ プロセス制御方式（デミング）開発工程

検査

出荷

プロセスの制御

科学的管理法：ノルマの設定，標準化，成果主義

マネジメント・スタイル：官僚主義

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

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

マネジメント・スタイル：民主主義

11

© Masaki YAMAMOTO

TPS(Toyota Production System)

• ジャスト・イン・タイム（JIT）– 必要な物を，必要な時に，必要なだけ造る（運ぶ）

– かんばん

• 自働化

– 品質・設備に異常が生じた時，機械が自ら検知して止まり，不良品の発生を防止する

– アンドン（電光表示盤）

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

12

© Masaki YAMAMOTO

Pull system is the best

• Pull system– 必要なときに必要な材料や情報を，後工程が前工程に取りに行く

• TPSを理解する上での重要な考え方

– JIT• 後工程から前工程へ，かんばんが渡される．前工程はかんばんを発注書として受け取り，製品を加工し，後工程へ納入する

– カイゼン

• 「必要なときに必要な材料や情報」にムダはない

13

様々な場面へ応用が可能

© Masaki YAMAMOTO

カイゼンにより日々進化（深化）

• カイゼンには限りがない

– 工程は，常にカイゼンされなければならない

• 全員で取り組む

– 設計者＋生産技術者＋現場の技能者

• ちょっとした工夫

– 例：同期台車（部品・工具を乗せた台車を連動）

• 技術進歩

– 例： e-かんばん（電子化．バーコード，ICチップ版も）

カイゼンを継続⇒持続可能な成長14

© Masaki YAMAMOTO

三現主義

• 三現主義

– 現地（現場）：現地へ行く

– 現物（現状）：現物を知る

– 現実：現実的であること

• 机上の空論は非効率であるとの共通認識

カイゼンは三現主義に立脚して進める

15

© Masaki YAMAMOTO

見える化

• 課題解決には，現物の可視化が必要

– 現物を知る重要性は，三現主義で説かれている

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

開発工程

16

© Masaki YAMAMOTO

3S• 整理(Seiri)：必要なモノと，不要なモノに分類する

• 整頓(Seiton)：直ぐに利用できるように定位置へ収める

• 清掃(Seisou)：ゴミをとる

• 目的

1. 事故を予防する

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

3. 作業効率を高める

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

17

ちなみに私は，工場実習時に現場の班長に「４」の目的を教え込まれ，なるほどと感動した事を覚えています．「３S」は「見える化」につながるのです．

© Masaki YAMAMOTO

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

18

© Masaki YAMAMOTO

「開発プロセス」は工学の成果

システム・エンジニアリング・プロセス



安全性テスト






実装

単体テスト





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

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

19

© Masaki YAMAMOTO

「開発文書」が工程を繋ぐつな




工程

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

(補足)工程をアクティビティと呼ぶ場合もある

© Masaki YAMAMOTO

プロセスは「開発文書」で満ちている

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

システム・エンジニアリング・プロセス



安全性テスト






実装

単体テスト





21

© Masaki YAMAMOTO

製造業の智恵をソフトウェア開発へ

• モノ作りの先輩である製造業に，謙虚に学ぶ

• 次のキーワードを，ソフトウェア開発へ活かす

22

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

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

知恵の泉

© Masaki YAMAMOTO

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

23

© Masaki YAMAMOTO

工学の根幹である開発文書の実態

• 良質な開発文書が書かれていない

– 分かりやすくない．曖昧さが残る ⇒ 品質，生産性の低下

• 後工程で読まれていない

– エビデンスに過ぎない ⇒ 開発に寄与しない，意欲低下

• レビューで使われていない

– 口先の言い訳が横行 ⇒ 技術に関心が集中しない

• 管理者や経営者の開発文書に対する意識が低い

– ソフトウェア開発に対する無知 ⇒ マネジメントの低下

24

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

© Masaki YAMAMOTO

開発文書を書く技術者の現状

• 学生時代に開発文書を書いた経験が少ない

• 社会人になってから書き始める

• プログラミングは好きだが，文書作成は不得意

• 何を書けば良いか，本当はわかっていない

• 既存の開発文書を真似て書いている

• 他者の書いた文書には，分からないことが多い

• 開発文書を書く自信がない…「書きたくない」を放置していてはソフトウェア開発は工学にならない

25

© Masaki YAMAMOTO

ゴミのような記述が混じる開発文書

• 文書は「整理」「整頓」されていない• 文書の「清掃」が行われていない

開発文書の清掃（朱を入れて書き直しを要求）事例

26

ゴミだらけの製造工場に等しい状況知識労働に対する冒涜

TPSを推進する上での致命的な欠陥

© Masaki YAMAMOTO

開発現場の立て直し

• 製造業で培った智恵をソフトウェア開発へ適用する

• まずソフトウェア開発現場を立て直す

• 現場において最も基本である「3S」をソフトウェア開発に適用する

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

開発文書の3Sに取り組む


知恵の泉

注：私は，掃除をしましょうと言っているわけではありません

© Masaki YAMAMOTO

システム開発文書の3S

• 整理

– 必要な情報だけが，十分に記述されている

– 曖昧なことが書かれていない

• 整頓

– 文書（電子ファイル，紙文書）が，整頓されている

– 文書体系が整っている

– 章構成が整っており，情報を直ぐに取り出せる

– 論旨を読み取りやすい

– 技術内容のトレーサビリティがとれている

• 清掃– 文書の書き直し

28

文書技術で，整理・整頓

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

© Masaki YAMAMOTO

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

1. 事故を予防する– 仕様や設計の誤解釈を予防する

2. 気持ちよく作業する環境を整える– 欠陥を見つけ易い・仕様変更し易い環境をつくる

3. 作業効率を高める– 文書による必要十分な情報の受け渡しで，

無駄な問い合わせや手戻りを回避する

4. 問題が起きたときに原因を発見しやすくする– 明確に技術内容を記述し，トレーサビリティが取れた文書があれば，

欠陥の原因を見つけやすい

29

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

© Masaki YAMAMOTO

他者による文書の清掃＝朱入れ

項番指摘箇所指摘種別指導内容

(1)～(8)(9) (14)(17)(18)(20)(21)

資料内に指示

文・文章の表現基本表記ルール構成・展開

基礎的な記述力の育成が必要。特に多い問題点を示す。・あいまい表現・修飾節のかかり受け・主語の不在・2文に分けるべき長文・見出しと本文の適切な関係記述・用語の統一・用語の定義

(7) 資料内に指示

構成全体像とその中での開発対象の位置づけの記述が必要。とくにシステムとプログラムの関係を明確にすること。

朱入れの事例：下記は指摘事例

朱入れ結果の活用：集計し横展開

弱点の傾向

朱入れでは，書き直すことも行われる．

朱入れを集約した情報を踏まえて技術者の傾向を分析し，教育カリキュラムを作成し横展開する

30

引用：開発中の演習教材に対する塩谷氏の朱入れ事例

© Masaki YAMAMOTO

ソフトウエア開発の文書技術

定義：ソフトウェア開発文書の作成・利用技術（ソフトウェア開発の見える化技術）

文書技術の訳： The Art of documentationArt とした思い

•深く思考し創作することを表現したい•文書技術には奥行きと広がりがある•美意識にも繋がる•体系化は今後の課題

32

© Masaki YAMAMOTO

何を書く

• 自分が生み出す付加価値の根源

• 何を書くかを追求すれば，着実にソフトウェア技術力が身に付き，付加価値を高めることができる

• コツは，読み手（後工程）を意識すること

– 自工程は後工程が必要とする情報の提供に応えると考えると，IEEE830やESPRの理解が深まる

「後工程から Pull されること」を書くという視点を持つ

33


知恵の泉

© Masaki YAMAMOTO

どのように書く

感想文ではなく，実用文を書く

• 必要十分な情報

• 論理的

• 非あいまい

• 無矛盾

• 変更容易

• 追跡可能…

我々は，感想文を書く練習はしてきたが，実用文を書く練習はしていない．

実用文を書くための学び直しが必要

34

「どのように書く」は文書技術の基本

© Masaki YAMAMOTO

文書技術の学習

• 練習方法

– 書籍を読む• TC協会「日本語スタイルガイド第2版」

• 阿部「明文術伝わる日本語の書きかた」など

– 実際に書く• まずは Email を明確に書くことから始める

– 開発文書の３S活動を組織で行う（朱入れ文化の定着）

• 環境を整える

– 仕事における開発文書の価値や意味を再確認する

– 経営者・管理者が率先して開発文書の重要性を示す

• コミュニティを活用する

– ASDoQ，TC協会など，文書技術に関する活動に参加する35

© Masaki YAMAMOTO

分かってきた効果的な朱入れ法

• 初級者には「どのように」書くの指導が必要

• 書き方から開発プロセス指導までの朱入れと，ドメイン技術の指導を異なる者が行う

• 朱入れ指導者は，プロセスの理解，論文の執筆経験，開発文書の作成経験などが必要

• 書き直すよりも，指摘するだけの方が効果的

ドメイン技術指導は，上司や専門家の仕事

36

© Masaki YAMAMOTO

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

• 朱入れを多角的に行う

– 仕事で作成する開発文書に朱入れを行い，具体的に，「何を」「どのように」書くかを指導

– アプリケーション・ドメインの技術指導は，上司やドメインの専門家が行う

• 開発者は，朱入れを踏まえ開発文書を改訂⇒ 直ちに品質・生産性が向上＋人材を育成

38

ドメイン技術指導は，上司や専門家の仕事


知恵の泉

© Masaki YAMAMOTO

（２）3S⇒5Sで成長し続ける

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

• 診療（Shinryou）– 診断結果に基づいて，技術者や組織を健全に成長させる教育やコンサルティングを行う．

39

診断と診療を「文書診断」と呼び，教育やコンサルティングを行う事例がある．参考文献・塩谷敦子「理系のための文書作成術」CQ出版社

・藤田，山本，中澤，塩谷，池田，楡井「組込みソフトウェア開発文書診断法」情報処理学会研究報告，Vol.2010-EMB-16，No.37（2010）

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

知恵の泉

製造業の5Sは，整理・整頓・清掃・清潔・躾開発文書の5Sは，整理・整頓・清掃（朱入れ）・診断・診療

© Masaki YAMAMOTO

コア資産

（３）コア資産をカイゼンし続ける

• コア資産プログラムの開発文書に何度も朱を入れて，質を高める

– プログラムだけではなく，開発文書もコア資産にする

– プロダクトライン開発の生産性が向上する

• 良質な開発文書は，社内教育でも活用可能

コア資産の開発文書を育てる

可変部可変部可変部

40


知恵の泉

© Masaki YAMAMOTO

（４）開発文書で見える化・三現主義

• 技術的成果（文書）を見える化せよ– ソフトウェア技術の本質は開発文書で表現される

• ニコカレなども必要だが，開発文書を書いてからの話

– 「見える化」から「見せる化」「魅せる化」を目指せ

• 三現主義

– 文書が書かれた「現地（開発現場，人）」へ行け• 開発現場へ行き技術者と話し合え

– 文書という「現物」を直視せよ

• 要求定義や設計の内容を議論せよ

– 文書に書かれた「現実」を無視するな• 何が決まり何がTBDかを見よ．現実を見つめTBDとなる真因を探せ

41

TPSPullカイゼン三現主義見える化見せる化・魅せる化5S

知恵の泉

能動的に仕事をする風土づくり

© Masaki YAMAMOTO

TPSで進化させる

• 要求仕様書で開発を「Pull」する

• XPやScrumを従順に守るだけでなく組織に適合するように，プロセスを「カイゼン」する

• プログラム（実装結果）だけにとらわれず，要求定義や設計の「現物」に立ち返る

– 本当にその設計は技術的に優れているのか？

• 付加価値の本質である文書の「見せる化・魅せる化」

– アジャイルは不要な文書の作成を止めよと言うだけであり，付加価値を生む開発文書の作成を否定していない

• ソフトウェア開発の「5S」（診断・診療含む）を追求する

43

TPSPullカイゼン三現主義見せる化・魅せる化5S

知恵の泉

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

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

開発文書による...

Documents