開発文書による 組込みソフトウェア開発の見える化 ESD21 TPS/Agileソフトフォーラム 組込みソフト開発のカイゼン 2013年11月12日 名古屋大学 大学院情報科学研究科 附属組込みシステム研究センター(NCES) 山本雅基 © Masaki YAMAMOTO 配付資料 ver.1 1 目次 1. 2. 3. 4. 5. 6. 7. ソフトウェア開発プロセス 製造業成功の秘訣TPS ソフトウェア開発プロセスと開発文書 システム開発文書の3S 開発文書の3Sには文書技術が必要 開発文書のTPS⇒人材育成＋プロジェクト推進 アジャイル考 © 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・エドワード・デミング １９００年 １９２１年 １９２５年 １９２７年 １９２８年 １９３９年 １９４６年 １９５０年 １９６０年 １９８０年 １９８１年 １９８７年 １９８８年 １９９３年 © Masaki YAMAMOTO アメリカ・アイオワ州生まれ ワイオミング大学 電気工学 学士号 コロラド大学ボルダー校 数理物理･数学 修士号 アメリカ農務省 イエール大学 物理･数学 博士号 学生時代に，ベル研究所でインターンシップ アメリカ国勢調査局 ニューヨーク大学経営学部大学院 日本において「統計的プロセス制御と品質の概念」の講義 日本において瑞宝章を受章 米国NBCTV番組「If Japan can... Why can‘t we?」にて紹介 フォードにおける指導を皮切りに，米国各企業で指導 アメリカ国家技術賞を受賞 全米科学アカデミーが表彰 デミング賞（1951年-） 死去．享年９３ 画像引用：日科技連デミング賞 http://www.juse.or.jp/deming/ 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 製造業の智恵をソフトウェア開発へ • モノ作りの先輩である製造業に，謙虚に学ぶ • 次のキーワードを，ソフトウェア開発へ活かす 知恵の泉 TPS Pull カイゼン 三現主義 見える化 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を実践してきた人々によるさらなる発展 TPS Pull カイゼン 三現主義 見せる化・魅せる化 5S • 要求仕様書で開発を「Pull」する • XPやScrumを従順に守るだけでなく 組織に適合するように，プロセスを「カイゼン」する • プログラム（実装結果）だけにとらわれず， 要求定義や設計の「現物」に立ち返る – 本当にその設計は技術的に優れているのか？ • 付加価値の本質である文書の「見せる化・魅せる化」 – アジャイルは不要な文書の作成を止めよと言うだけであり， 付加価値を生む開発文書の作成を否定していない • ソフトウェア開発の「5S」（診断・診療含む）を追求する 丁寧に開発文書に取り組むことが重要 © Masaki YAMAMOTO 43 本資料に関するお問い合わせ先 名古屋大学大学院情報科学研究科 附属組込みシステム研究センター（NCES） 山本雅基（やまもと まさき） [email protected] © Masaki YAMAMOTO 44
© Copyright 2024 Paperzz
