Tweet
Tweet

Slide 1

Slide 1 text

モノづくり品質珍道中 木﨑 周子

Slide 2

Slide 2 text

この資料に登場する団体および人物は実在のものではなく、 秘密情報の保護やプライバシーの確保を目的として、 事実を脚色したり、一部変更を加えています。

Slide 3

Slide 3 text

引き出しを増やせ!

Slide 4

Slide 4 text

入社3年目 組込みソフトウェアエンジニア ⿁嵜（きさき）

Slide 5

Slide 5 text

ソフトウェア詳細仕様書 コードレビュー指摘一覧

Slide 6

Slide 6 text

入社25年目 組込みソフトウェアエンジニア 銅鑼（どら） 共通.lib Common Standalone

Slide 7

Slide 7 text

Strategy Facade

Slide 8

Slide 8 text

T F

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

入社15年目 プロジェクトマネージャー 根津（ねづ）

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

2013.04  電機総合メーカー子会社  日系  官公庁向け組込みシステム開発  ベンチャー企業  日系  WEBセキュリティーサービス開発  自動車部品メーカー  日系  Lv4自動運転R&D  電気・電子計測機器メーカー  外資系  ウエハー計測器R&D 2018.09 2019.04 2024.03 Work Experience Wモデル カンバン カンバン (+特になし) 基本 ウォータフォール 引き出しを探していたら 色々な選択を することになりました

Slide 14

Slide 14 text

そもそも、 改善に引き出しは必要って? 必要ない スクラムの 3 本柱 透明性 適応 検査 ココを しっかりすることの方が が重要

Slide 15

Slide 15 text

検査なしに行う改善なんて、 だいたい的が外れてしまう 検査 ＞＞＞＞＞ 引き出し  引き出しが役立つ事はありますが、 必要になってから探しに行けばいいんです  「引き出し」≒「経験」と仮定したとき、 改善に引き出しの多さはそんなに関係ないから、 Newcomerでも、誰でも、 改善はできるのです  「品質改善」も同様です

Slide 16

Slide 16 text

Side Note  このモデルのお客様は、 本当に優秀で良い方々でした  お客様が見えてるロードマップを考慮し、 受注する我々、開発現場の 人手不足とか、開発しやすさを考え、 要求を出してくれていました

Slide 17

Slide 17 text

われわれ人間はわかり合えない存在だからこそ

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

入社8年目 組込みソフトウェアエンジニア 從二（じゅうに）

Slide 23

Slide 23 text

スキップ！！

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

入社3年目 社会人8年目 組込みソフトウェアエンジニア 担当係⾧ ⿁嵜（きさき）

Slide 26

Slide 26 text

ココ

Slide 27

Slide 27 text

いきなり中身を見るのではなくて、 状況把握の出力と、 そもそも前提条件が正しいのかの入力 を確認しよう! で、今、 出力は何Hzに なってしまっているの? 30Hzです… ? そうです! でも、我々の出力を受け取る装置のチームが、 彼らの装置が30Hzじゃ足りなかったので、 60Hzになるように我々のチーム入力を変えたらしいです Input Function Output 状況把握 前提条件 60Hz欲しい！ ３0Hz このシステム、 出力は30Hzの仕様じゃなかった?

Slide 28

Slide 28 text

え? 入力を30Hzのセンサーから60Hzのセンサーに変えたらしいです! それ不具合でも、 何でもなくない? Input Function Output 状況把握 前提条件 60Hz? ３0Hz まずまず、理論上は出来るとしても、 仕様にない、テストもしてないものを 出来る前提で要求してくるのがおかしいよ! （プログラムが本当にそれに対応できる実装になっているかも分からないのに…） そんなの、一部を変えたら、 システム全体で、 タイミングとかせっかく設計したのに、 整合性が取れる保証がなくなるよ! でも、理論上は確かにおかしくないから、 すぐに対応しないと!! → 60Hz

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

われわれ人間はわかり合えない 存在だからこそ、 信じるしかないのです  アルフレッド・アドラー（Alfred Adler） オーストリアの精神科医、精神分析学者、心理学者  この言葉は、  人間の関係性や相互理解の限界を認識しながらも、 他者を理解しようとする努力が重要であること  コミュニケーションや協力の必要性 を強調しています

Slide 31

Slide 31 text

そもそも、 彼女は、 理解ができないことがあることも 理解できていない 皆がどうしてこのような考えに至るのか について、 彼女は理解できていない

Slide 32

Slide 32 text

レビューやテストなどの品質活動は、 お互いを信じる為のアプローチの1つだ 品質の追及は、 工学的な理論だけでは限界があって、 人間はどうなのか？まで思いを馳せた方が良い 理解ができないことは起きる レビューやテストは、 理解しようと努力する為の コミュニケーションや協力のツールに成りうる

Slide 33

Slide 33 text

なので、 彼女は、 理解ができないことがあることも 認知して、 どの様にアプローチしようか考えるべき 理解できないことに 向き合うのは辛い 理解できないんだ！と ゆるく折り合いをつける方が楽になる

Slide 34

Slide 34 text

Side Note  言葉で言うのは簡単ですが、 いざ現場で目の当たりにすると、 学んできた知見は活用できないものです  そのもどかしさは、 教科書のように理論整然と書くと 伝えずらいと思い 今回は漫画形式にしてみました

Slide 35

Slide 35 text

フロントローリング

Slide 36

Slide 36 text

 概要  プロジェクトの早期段階で、品質に関連する活動やタスクを集中的に行うアプローチ  後半の段階での問題発生を防ぎ、全体的な品質を向上させるための戦略  目的と利点  問題の早期発見と修正:  開発の初期段階で問題を早期に発見し、修正することで、 後の段階で発生する可能性のある重大な問題やバグを減少させる  コストの削減:  問題が早期に解決されることで、後の開発フェーズやテストフェーズでの 修正作業やバグ修正のコストを削減する  修正が早いほど、費用対効果が高くなる  リスクの軽減:  初期段階で品質リスクを評価し、対策を講じることで、後半のリスクを軽減し、 開発の成功率を高める フロントローリング

Slide 37

Slide 37 text

フロントローリング 引用：経済産業省（2020）「ものづくり白書」

Slide 38

Slide 38 text

フロントローリング 引用：山下昭裕，前川隆昭：設計プロセス革新による開発効率化，三菱電機技報，Vol.84，No12，660～663（2010）

Slide 39

Slide 39 text

このお話、 そもそもコードレビューをちゃんとしていれば、 もっと早くに対処できていた When 結合試験,

Slide 40

Slide 40 text

当たり前だが、 開発の後半になればなるほど、 手戻り工数は大きくなる 実装 単体試験 詳細設計 結合試験 このケースの場合、

Slide 41

Slide 41 text

手戻りの何が嫌かと言うと... 設計が完了した後の仕様変更は、自由度が低い 複雑で理解しづらい実装になっていく 頭のワーキングメモリがガリガリ減って疲れる 時間が少なくなっていく 労働時間が増大していく 体力がだんだん減って疲れる 疲れからヒューマンエラーが多発してくる 疲れが品質への一番の天敵だ!!

Slide 42

Slide 42 text

誰でもできるテンプレート?!

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

彼女は、何に戸惑い、どう思った、のか?  開発の進め方が不明  確認がしずらい  トレーサビリティが取れない  共通言語がないので、コミュニケーション取りづらい  開発工程が欲しいなー  開発の目的がテンプレートを 穴埋めすることになっている  テンプレートの本来の意味・目的 が失われている  テンプレートの賞味期限が 切れている 状況  どの様なものを、どの様に開発しているのか不明 戸惑い どう思った  開発者同士の調整が取れない  成果物の種類と書き口のテンプレートが欲しいなー

Slide 47

Slide 47 text

テンプレートは必要か? 必要である ここら辺を解決できるから

Slide 48

Slide 48 text

彼女は逆方向に経験している...？ 多くの現場の「始まり」は、 ココなのかもしれない 彼女の経験した方向

Slide 49

Slide 49 text

と言うことは、 テンプレートにはライフサイクルが存在する ライフサイクルの方向 死 誕生

Slide 50

Slide 50 text

テンプレートは、 品質の良い開発の為に生まれ、 品質の良い開発を支えられなくなり死んでいく テンプレートも意識して継続的改善を! 透明性 適応 検査

Slide 51

Slide 51 text

何でも見てやろう

Slide 52

Slide 52 text

※

Slide 53

Slide 53 text

本当に世界で優秀と言われる人達も こんな感じなんだろうか... 見てみたいなぁ... そうだ！

Slide 54

Slide 54 text

何でも見てやろう!

Slide 55

Slide 55 text

続く！ 参考文献 水木しげる. 墓場の⿁太郎. 講談社, 1960. 士郎正宗. 攻殻機動隊. 講談社, 1989. ラレコ. やわらか戦車. DLE, 2004. 小田実. 何でもみてやろう. 河出書房新社, 1961. モノづくり品質珍道中