20240519 Nagoya Embeded Study session / About the development process.
- 1. 小規模でも 開発プロセスの勉強をしよう （for 名古屋組込(ET)勉強会LT Vol.2） ミイシステム株式会社） 稲玉 繁樹 Rev.)2024/05/19 いなたま しげき ALL Pages Photo OK! 四の人(IoT) @InatamaS
- 2. Mii system Co.,Ltd. ミイシステム株式会社 (Mii System Co.,Ltd.) 代表 ：稲玉 繁樹 （イナタマ シゲキ） 設立 ：2017年1月20日 本店 ：三重県四日市市 About 2 趣味 ・マラソン ・電子工作 ・立飲めぐり 個人経歴 電気関係(計装) → ソフト(IT) → 大手電機(研究開発)→2017年独立 電気学会 D部門 推進委員(2015-2017) 工学部・電気電子専攻 過去の実績 鉄道の重要部品を研究開発， ５万台～採用と安全に貢献 元モータ制御の研究開発 （サーボAMPの回路，ソフト） 四の人(IoT) @InatamaS 稲玉繁樹 有楽町 東宝ツインタワービル
- 3. Mii system Co.,Ltd. 小規模案件でも開発プロセスを意識しよう！ 本日のテーマ 3 → ウチはスピード優先でやってるので → ドキュメントなんか面倒 → すぐ納品だし，内容は覚えてるし こんな人ほどプロセスを意識してレベルアップ Agenda 1. 開発プロセスの基礎 手順とか名称とか 2. 開発プロセスを定義しよう メリットとかルールとか 3. 小規模向けSDPの例 当社のフォーマット 4. 運用に向けて
- 4. Mii system Co.,Ltd. 開発プロセスの基礎 section-1 Basic knowledge of SDP 4
- 5. Mii system Co.,Ltd. なぜ開発プロセスを定義するのか 5 品質と信頼につながる プロジェクトの成功率が向上，品質が保証しやすい リスクやリソースの効率的な管理 不具合調査や背景調査のスピード・正確性UP 見積精度が上がり，適切な価格で競争力も上がる →顧客満足度と競争優位性が向上します 優秀なエンジニアとして 技術背景，現象，結果，質問をドキュメントで説得できる（No!くちだけ) 体系的なチェックにより不具合も少なく信頼される 追加・改造・変更を最適最短でこなす → すべて任せられ，信頼されるエンジニアになろう
- 6. Mii system Co.,Ltd. 色々な開発プロセスの概要をまとめてみた いろいろな開発プロセス 6 https://qiita.com/ryota_i/items/676dc21b380a78c858b5
- 7. Mii system Co.,Ltd. ウォーターフォールモデルとは？ V字モデルでよく知られる あれこれディスられるけど，結局優れている ウオーターフォールモデル 7 https://service.shiftinc.jp/column/4850/
- 8. Mii system Co.,Ltd. アジャイル開発で採用される5つの手法 小さい単位で開発・リリースを繰り返す 良さそうに見えるが無能が混ざると破綻する アジャイル 8 https://www.qbook.jp/column/1650.html
- 9. Mii system Co.,Ltd. プロトタイプ開発とは？ 実機に近いものを作って評価する 実物を見てクライアントと仕様を詰める感じ コストが高くなるが良いものが出来そう スパイラルモデル 機能単位でリリース，FBして品質を向上 だんだん完成度を高める 全体が分かりづらく，とんでもない方向へ行く場合も オレ様開発 好きな所，難しい所から作っていく 動いたら満足して納期を過ぎる 趣味開発に向いている その他 9 https://sucsak.com/contents/prototype/
- 10. Mii system Co.,Ltd. Q:何に従い、何を作り、何を確認して、何を納品している、 その過程が全て記録されていますか？ 要求仕様書は 変更履歴は 成果物は 試行/失敗の履歴は 開発環境履歴は ファイルバージョン管理は どのバージョンで試験したの 今のプロセスを再確認（ヒヤリング） 10
- 11. Mii system Co.,Ltd. 1. 仕様遵守と変更 海外: 仕様に完全に準拠し、仕様外の変更は認められない 日本: 良かれと思い、勝手に改良や変更を加えることが多い 2. ドキュメントとノウハウ 海外: 体系立てたドキュメントを作成し、誰もが理解できるようにする 日本: ドキュメントは各社固有のノウハウに依存 3. レビューと承認プロセス 海外: レビューによる承認ルールがしっかりしており、レビュアーのスキルも高い 日本: 定期レビューが少なく、承認者は上長で内容を十分に理解していないことが多い どちらが優れているとは言い切れないけど 違う視点での経験はスキルが広がった 日本と海外の開発意識の温度差 11
- 12. Mii system Co.,Ltd. 開発プロセスを定義しよう section-2 Define the development process 12
- 13. Mii system Co.,Ltd. メリット 定義されていれば見積も開発も穴埋めだけ 見積・スケジュール精度が向上 漏れ，変更，手戻りの減少 不具合，質問，調査の工数減，正確性UP デメリット 初期導入コスト，管理・教育工数がたいへん 柔軟性が下がり複雑さが増加 最後までやり遂げないと意味が無い → 中途半端なPMでは実現できず迷惑になる → 作る事はスタート，運用する事が大切 設計基準書 (System Desing Procedure) 13
- 14. Mii system Co.,Ltd. 工程 要件定義 外部設計 内部設計 コーディング テスト リリース 運用・保守 一般的なシステム開発プロセス 14 あるあるな実情 →言われるがまま →脳内 →脳内 →いきなり始める →思いつき →バイナリーのみ →風が吹くまま ・難しいところばかり注力 ・変化・変更のルールが思いつき ・やっといてと注文，出来たものにクレーム 炎上パターン
- 15. Mii system Co.,Ltd. CMM® | CMMI®とは CMMI を見てみよう 15 https://www.compita-japan.com/kaisetsu/what-cmmi-2.html ほとんどがLV1(LV0) 気持ちとしては， ・定義したルールで ・繰り返し開発を効率化 ・記録が管理され ・調査・変更を効率的に やってるので安くて良い製 品を作ってます…
- 16. Mii system Co.,Ltd. フェーズごとのINPUT/OUTPUTを理解する レビュー記録を残す，レビュー結果の承認をする バージョンアップ（保守運用）も2周目～を回す V字モデル運用 16
- 17. Mii system Co.,Ltd. V字モデル 各フェーズの入出力 17 Phase INPUT OUTPUT Review 要件定義 ユーザーや要求 ビジネスニーズ 要求仕様書 レビュー記録 外部設計 要求仕様書 システム仕様書 レビュー記録 内部設計 システム仕様書 詳細設計書 レビュー記録 コーディング 詳細設計書 ソースコード レビュー記録 テスト ソースコード チェックリスト テストレポート レビュー記録 リリース 合格したシステム リリースノート バージョン管理表 レビュー記録 保守 改善案 不具合情報 変更仕様書 レビュー記録 レビューで仕様書を確定し次フェーズのINPUTにする ドキュメントはアウトラインを定義し穴埋めするだけ
- 18. Mii system Co.,Ltd. とある小規模向けSDPの例 section-3 A Sample of small SDP 18
- 19. Mii system Co.,Ltd. ポイント1（意識している所） エクセルにまとめ，いつでも振り返れる 履歴を楽に残す 各フェーズのドキュメントを定義 フェーズ毎のレビューと記録 ポイント２（工夫点） 試行も失敗も残す(場所を作る) テストは必ず３段階 ワークシートは顧客と共有 当社のSDP例 19
- 20. Mii system Co.,Ltd. SRS 要求仕様書 何に基づいて開発を進めるかを徹底的に確定させる 顧客に提出してもらう，または承認をもらう SFD 機能仕様書 システム構成，ハード構成，ソフト機能などをまとめる 見積前に作る場合もある，最終版に合わせて細かく修正する 顧客とSFDの読み合わせレビューを行い，すり合わせを深める WBS 業務リスト 作業を細かくリスト化する，各作業に工数を割り振り見積ベースにする 作業進捗のチェックと実績メモを兼ねる SDD 詳細仕様書 完成ドキュメントとしてソフト説明を兼ねた文章 開発ツール，システムフロー，状態遷移，通信コマンド，変数リストなど ソース納品の場合は重要 各ドキュメントのポイント1 20
- 21. Mii system Co.,Ltd. UT 単体テスト＆結果 デバッグ時の作業メモ的に記入する 実験結果，性能メモ，失敗情報なども記載する 結果をレビューで実物を触っていない顧客にあーすればこーなるを伝えやすい IT 結合テスト＆結果 Module間，Hard-Soft間，など組み合わせた試験項目とする ホワイトボックステストとしてエンジニアがコードを意識して試験するレベル FT 機能テスト＆結果 機能テストとしてSFDの裏返しで全機能確認と機能の逆を意識する ブラックボックステストとして作業員や顧客ができるレベル 機能漏れ，限界値，禁止条件なども明確にする 各ドキュメントのポイント2 21
- 22. Mii system Co.,Ltd. SRTP&R 要求テスト＆結果 顧客からの要求テスト，顧客に出してもらう FTのレビューで省略される場合が多い ATP&R 受入テスト＆結果 納品時の受け入れテスト，顧客に作成してもらう 立会&動作確認にて代替する場合が多いが承認履歴を残す Review レビュー履歴 打ち合わせ毎に必ず残す 手短にキーワードを残し，開発の経緯が分かる事が重要 レビューのレビューにて計画通り実行できたかを確認し完了 各ドキュメントのポイント3 22 ・顧客が決める部分を明確にし責任を持たせる ・やったこと全てを残しているから，もう１回やってなど言わない ・不具合は悪くない，不具合に至るプロセスが悪い，それが分かる仕組みを
- 23. Mii system Co.,Ltd. 運用に向けて section-4 Advice for operation 23
- 24. Mii system Co.,Ltd. 自分で決めたことも守れないヤツは開発に向かない 議題・進捗が無くてもレビュー計画どおりに開催 何もなかったなら，無かったことを記録に残す 内容３行程度でも規定文章は作成する 面倒くさい，ムダ，納期など関係なく基準に従う 誰のため？ 顧客にしっかりしたプロセスを感じてもらう プロセスをこなしている姿は信頼性が高まる コーディング以外の作業工数の方が多いが，正しい 正しい工数と費用を顧客が納得したうえで品質に金をかける → 開発・運用は大変だが，全員が幸せになれる → 自分で作り運用を回す，徐々に使いやすくしていく 強い決意で淡々とこなす 24
- 25. Mii system Co.,Ltd. 小規模でもなんとなく開発から脱却しよう ドキュメントは面倒でなくプロジェクトの資産になる プロセスを評価してもらい信頼を上げよう まとめ 25 www.mii-system.com inatama-shigeki@mii-system.com ご清聴ありがとうございました！ Sildeshare します。 いなたま しげき 代表：稲玉 繁樹 四の人(IoT) @InatamaS BOOTH公式SHOP https://mii-system.booth.pm/