モノづくり品質珍道中

Scrum Fest Mikawa 2024 登壇資料
https://confengine.com/conferences/scrum-fest-mikawa-2024/proposal/20372

Transcript

1. モノづくり品質珍道中 木﨑 周子
2. この資料に登場する団体および人物は実在のものではなく、 秘密情報の保護やプライバシーの確保を目的として、 事実を脚色したり、一部変更を加えています。
3. 引き出しを増やせ!
4. 入社3年目 組込みソフトウェアエンジニア ⿁嵜（きさき）
5. ソフトウェア詳細仕様書 コードレビュー指摘一覧
6. 入社25年目 組込みソフトウェアエンジニア 銅鑼（どら） 共通.lib Common Standalone
7. Strategy Facade
8. T F
10. 入社15年目 プロジェクトマネージャー 根津（ねづ）
13. 2013.04  電機総合メーカー子会社  日系  官公庁向け組込みシステム開発  ベンチャー企業  日系  WEBセキュリティーサービス開発  自動車部品メーカー  日系  Lv4自動運転R&D  電気・電子計測機器メーカー  外資系  ウエハー計測器R&D 2018.09 2019.04 2024.03 Work Experience Wモデル カンバン カンバン (+特になし) 基本 ウォータフォール 引き出しを探していたら 色々な選択を することになりました
14. そもそも、 改善に引き出しは必要って? 必要ない スクラムの 3 本柱 透明性 適応 検査 ココを しっかりすることの方が が重要
15. 検査なしに行う改善なんて、 だいたい的が外れてしまう 検査 ＞＞＞＞＞ 引き出し  引き出しが役立つ事はありますが、 必要になってから探しに行けばいいんです  「引き出し」≒「経験」と仮定したとき、 改善に引き出しの多さはそんなに関係ないから、 Newcomerでも、誰でも、 改善はできるのです  「品質改善」も同様です
16. Side Note  このモデルのお客様は、 本当に優秀で良い方々でした  お客様が見えてるロードマップを考慮し、 受注する我々、開発現場の 人手不足とか、開発しやすさを考え、 要求を出してくれていました
17. われわれ人間はわかり合えない存在だからこそ
22. 入社8年目 組込みソフトウェアエンジニア 從二（じゅうに）
23. スキップ！！
25. 入社3年目 社会人8年目 組込みソフトウェアエンジニア 担当係⾧ ⿁嵜（きさき）
26. ココ
27. いきなり中身を見るのではなくて、 状況把握の出力と、 そもそも前提条件が正しいのかの入力 を確認しよう! で、今、 出力は何Hzに なってしまっているの? 30Hzです… ? そうです! でも、我々の出力を受け取る装置のチームが、 彼らの装置が30Hzじゃ足りなかったので、 60Hzになるように我々のチーム入力を変えたらしいです Input Function Output 状況把握 前提条件 60Hz欲しい！ ３0Hz このシステム、 出力は30Hzの仕様じゃなかった?
28. え? 入力を30Hzのセンサーから60Hzのセンサーに変えたらしいです! それ不具合でも、 何でもなくない? Input Function Output 状況把握 前提条件 60Hz? ３0Hz まずまず、理論上は出来るとしても、 仕様にない、テストもしてないものを 出来る前提で要求してくるのがおかしいよ! （プログラムが本当にそれに対応できる実装になっているかも分からないのに…） そんなの、一部を変えたら、 システム全体で、 タイミングとかせっかく設計したのに、 整合性が取れる保証がなくなるよ! でも、理論上は確かにおかしくないから、 すぐに対応しないと!! → 60Hz
30. われわれ人間はわかり合えない 存在だからこそ、 信じるしかないのです  アルフレッド・アドラー（Alfred Adler） オーストリアの精神科医、精神分析学者、心理学者  この言葉は、  人間の関係性や相互理解の限界を認識しながらも、 他者を理解しようとする努力が重要であること  コミュニケーションや協力の必要性 を強調しています
31. そもそも、 彼女は、 理解ができないことがあることも 理解できていない 皆がどうしてこのような考えに至るのか について、 彼女は理解できていない
32. レビューやテストなどの品質活動は、 お互いを信じる為のアプローチの1つだ 品質の追及は、 工学的な理論だけでは限界があって、 人間はどうなのか？まで思いを馳せた方が良い 理解ができないことは起きる レビューやテストは、 理解しようと努力する為の コミュニケーションや協力のツールに成りうる
33. なので、 彼女は、 理解ができないことがあることも 認知して、 どの様にアプローチしようか考えるべき 理解できないことに 向き合うのは辛い 理解できないんだ！と ゆるく折り合いをつける方が楽になる
34. Side Note  言葉で言うのは簡単ですが、 いざ現場で目の当たりにすると、 学んできた知見は活用できないものです  そのもどかしさは、 教科書のように理論整然と書くと 伝えずらいと思い 今回は漫画形式にしてみました
35. フロントローリング
36.  概要  プロジェクトの早期段階で、品質に関連する活動やタスクを集中的に行うアプローチ  後半の段階での問題発生を防ぎ、全体的な品質を向上させるための戦略  目的と利点  問題の早期発見と修正:  開発の初期段階で問題を早期に発見し、修正することで、 後の段階で発生する可能性のある重大な問題やバグを減少させる  コストの削減:  問題が早期に解決されることで、後の開発フェーズやテストフェーズでの 修正作業やバグ修正のコストを削減する  修正が早いほど、費用対効果が高くなる  リスクの軽減:  初期段階で品質リスクを評価し、対策を講じることで、後半のリスクを軽減し、 開発の成功率を高める フロントローリング
37. フロントローリング 引用：経済産業省（2020）「ものづくり白書」
38. フロントローリング 引用：山下昭裕，前川隆昭：設計プロセス革新による開発効率化，三菱電機技報，Vol.84，No12，660～663（2010）
39. このお話、 そもそもコードレビューをちゃんとしていれば、 もっと早くに対処できていた When 結合試験,
40. 当たり前だが、 開発の後半になればなるほど、 手戻り工数は大きくなる 実装 単体試験 詳細設計 結合試験 このケースの場合、
41. 手戻りの何が嫌かと言うと... 設計が完了した後の仕様変更は、自由度が低い 複雑で理解しづらい実装になっていく 頭のワーキングメモリがガリガリ減って疲れる 時間が少なくなっていく 労働時間が増大していく 体力がだんだん減って疲れる 疲れからヒューマンエラーが多発してくる 疲れが品質への一番の天敵だ!!
42. 誰でもできるテンプレート?!
46. 彼女は、何に戸惑い、どう思った、のか?  開発の進め方が不明  確認がしずらい  トレーサビリティが取れない  共通言語がないので、コミュニケーション取りづらい  開発工程が欲しいなー  開発の目的がテンプレートを 穴埋めすることになっている  テンプレートの本来の意味・目的 が失われている  テンプレートの賞味期限が 切れている 状況  どの様なものを、どの様に開発しているのか不明 戸惑い どう思った  開発者同士の調整が取れない  成果物の種類と書き口のテンプレートが欲しいなー
47. テンプレートは必要か? 必要である ここら辺を解決できるから
48. 彼女は逆方向に経験している...？ 多くの現場の「始まり」は、 ココなのかもしれない 彼女の経験した方向
49. と言うことは、 テンプレートにはライフサイクルが存在する ライフサイクルの方向 死 誕生
50. テンプレートは、 品質の良い開発の為に生まれ、 品質の良い開発を支えられなくなり死んでいく テンプレートも意識して継続的改善を! 透明性 適応 検査
51. 何でも見てやろう
52. ※
53. 本当に世界で優秀と言われる人達も こんな感じなんだろうか... 見てみたいなぁ... そうだ！
54. 何でも見てやろう!
55. 続く！ 参考文献 水木しげる. 墓場の⿁太郎. 講談社, 1960. 士郎正宗. 攻殻機動隊. 講談社, 1989. ラレコ. やわらか戦車. DLE, 2004. 小田実. 何でもみてやろう. 河出書房新社, 1961. モノづくり品質珍道中