ビジネスと現場活動をつなぐ ソフトウェアエンジニアリング ～とあるスタートアッププロダクトの成長記録より～ 1 Software/System Engineering Practitioner @NoriyukiMizuno みずのり（みずののりゆき） TOC/TOCfE北海道 RDRA MeetUp、TEF道など 8th長崎QDG（2025/2/7）

自己紹介：ソフトウェアエンジニアリング 2 水野昇幸（みずののりゆき） ・Twitter（X）：@NoriyukiMizuno ソフトウェアエンジニアリング関連 ・（監訳/共訳）実践ソフトウェアエンジニアリング（第9版）、オーム社、2021 ・8th長崎QDG（2025）：ビジネスと現場活動をつなぐソフトウェアエンジニアリング ・WACATE2024 Summer招待講演：モデリングのそだてかた ・ソフトウェア品質シンポジウム2022：演習で学ぶ実践ソフトウェアエンジニアリング ・JaSST22東京：（パネル）ソフトウェア開発にかかわる全てのエンジニアの一般教養 「ソフトウェアエンジニアリング体系」における品質技術 ・ET＆IoT2021：米国修士課程ベストセラーに学ぶ 体系的ソフトウェアエンジニアリングの必要性 保有資格とか ・簿記3級、2級、JTSQB-FL、ALTM、ALTA、 ・情報処理エンベデッド、プロマネ ・TOC-CCPMスペシャリスト（インプリメンター資格） 国際NPO TOC for Education, Inc 認定「ファシリテータトレーニング」 「思考及びコミュニケーションツールトレーニング」修了 コミュニティ系 ・TOC/TOCfE北海道、TEF道、JaSST北海道実行委員 ・ETロボコン実行委員など

自己紹介：思考技術、TOC/TOCfEなど 3 TOC（制約理論：Theory of Constraints）関連発表 ・TOCセミナー長崎（2024）：仕事でもコミュニティでも役立つTOC 約15年の活動から ・第11回教育のためのTOCシンポジウム（2022）： 500ページ超（原書650ページ超）の訳書の出版へ向けてATTで考えて活動したお話し ～TOCfEとソフトウェア開発技術の組合せ活用 ・JaSST’18東京：SaPIDTOC～未来予想型チーム運営ワークショップ（チュートリアル） ・SQiP2014：CCPMの考え方を活用したテストフェーズにおける課題解決 ～課題発見、解決までのケーススタディ～ ・SQiP2013：システムテスト実施フェーズにおけるボトルネック/クリティカルチェーンを 特定した残日数管理マネジメントとその効果 TOC関連の講演資料・ワークショップ ・プロジェクトマネジメントの概要とCCPMによる工期短縮の仕組み ・提案を検証する技術（TOC マフィアオファー（URO）活用技術） ・SaPIDTOC～未来予想型チーム運営ワークショップ ・CCPM折り紙ワークショップ ※2014年から12回くらい実施、300名以上が受講 ・CCPMカレーワークショップ ・SaPIDTOC～未来予想型チーム運営ワークショップ TOCおよびTOCfEイベント企画・運営 ・TOC/TOCfE北海道立上げ（2016） ・TOCfE国際認定プログラム北海道開催（2018）

自己紹介：テスト/要件定義関連 4 ソフトウェアテスト/テスト自動化関連（海外） ・（共著）InSTA2019＠西安：Coexistence of test execution efficiency and test ・（共著）InSTA2018＠Sweden：Proposal for Enhancing UTP2 with Test Aspects ・（共著）InSTA2017＠東京：Test Conglomeration - Proposal for Test Design Notation like Class Diagram ・（共著）6WCSQ＠ロンドン（2014）：Stepwise Test Design Method ソフトウェアテスト/テスト自動化関連（国内） ・JaSST’21東京： （チュートリアル）価値につながる要件・仕様からテストを考える ・ET⁻WEST2018：なぜ組込みシステムにおけるテストは難しいのか ～ 2つのテストアーキテクチャによってテストを組立てる ～ ・JaSST’17関西：納得できるテストをつくるアプローチ ・STAC2015：自動家は見た～自動化の現場の真実～ ・テスト設計コンテスト優勝：2017年 STUDIO IBURI ・テストカタマリーの紹介/活用したテスト設計プロセス案 要件定義関連 ・JaSST’21東京： （チュートリアル）価値につながる要件・仕様からテストを考える ・DevSumi関西2020：伝統的食品工場エンジニアリング会社が挑むDXへの ビジネスアイデアをRDRAによる要件定義でプロダクト開発へつなぐ～Side：要件定義 ・RDRA+プロトタイピングおよび仕様化時に役立つ技術、事例紹介

自己紹介：おしごと 5 ■過去 ・某電機メーカーで宇宙・防衛系の システム設計・プロマネなど 開発～保守まで全工程に対応 ・大規模プロジェクトでの開発 ■現在（2016～） ・流しのソフトウェアエンジニア（フリーランス） ソフトウェア開発のなんでも支援 ※PjM/PdM、要件定義、実装/インフラ、テスト、保守 ・支援企業は車・食品・旅行業など ・現状は企業内スタートアップ的な プロダクト開発を支援中

今回のおはなし 6 とあるスタートアッププロダクトで発生するさまざまな課題解決を ソフトウェアエンジニアリング技術等を駆使して突き進んでいく感じのおはなしです。 よくあるプロダクトライフサイクルの流れには従っているかなと思われます。

（参考）企画フェーズ～初期プロダクト開発まで 7 経営幹部の方とイントレプレナーの担当者のみでひたすら高速対応。 企画・稟議書作成、投資の許可までこぎつける。 RFP→提案書で開発会社を決定へ。 最初は提案書に従って開発、リリース後、大々的な紹介もあったが、 1年はお客さんがつきそうでつかない。 （参考）DevSumi関西2020：伝統的食品工場エンジニアリング会社が挑むDXへのビジネスアイデアをRDRAによる要件定義でプロダクト開発へつなぐ 経営＆担当者

（参考）初期プロダクト開発での活動 8 （探索が必要な状況における）初期プロダクトでは、以下のような活動を繰り返す。 とにかくアイデアを試す 顧客に魅力的な要素を提供する必要あり 作るよりペーパープロトの方が速いことも多い 適切な顧客候補がいると効果的に進む ※CVP（顧客提供価値）が明確に把握できないと特に苦労する 高速にスクラッチ＆ビルド 試行錯誤の結果、高速に作り直すケースが多発 ※ある意味高速の犬小屋づくり 不具合は許容・テスト不要 よほどのことが無い限りテストはいらない 不具合はあっても使う人がいないので許容可能

そして顧客獲得、状況が大きく変化する 9 そして顧客獲得をするが… 俺たちの戦いはここからだ！（大変な状況になりました…）

ゼロとイチ以降は異なる 10 ゼロイチのイチ以降は必要となされる状況が大きく変化する ビジネスができるソフトウェア提供状況から、大きく乖離した… とにかくアイデアを試す 思いついたものをとにかく作る →共有されないものが入る 高速にスクラッチ＆ビルド 作り直しが何度も入ることでデグレへ 不具合は許容・テスト不要 不具合を他責にしてしまいがちに… 開発組織＆担当＋支援 開発 (外部) 変更の把握と管理 × 仕様に書いても実装されない 報告されていないものが入っている 変更失敗率 * × デグレ多発＋触れるたびに不具合発生 失敗の復元まで * × 再現しない不具合は調査しない ログもないのでそもそも調査できない * Four Keysにおける指標からPickUp

簡単に言いやがってシリーズ 11 改善への活動についてまとめます。 1．テストを含めたプロセスの改善 2．テストの環境整備 3．一部監視の仕組みを構築 ＜閑話休題＞ 4．ツール～運用改善～ 5．ツール～拡張システム～ 6．テスト改善的改善と自動化 7．監視システム強化 変更の把握と管理 × 仕様に書いても実装されない 報告されていないものが入っている 変更失敗率 × デグレ多発＋触れるたびに不具合発生 失敗の復元まで × 再現しない不具合は調査しない ログもないのでそもそも調査できない 開発組織＆担当＋支援 開発 (外部)

各種改善活動：Phase1 12 1．テストを含めたプロセスの改善 元々のカウボーイ的なリリース状況を月1回リリースとする。 バックログに応じた内容に対し、テストを通過させてリリースへ ＜プロセス状況（概要）＞ ・バックログを明確にして進捗管理、実施内容を共有 ・ステージングリリース→本番リリースを必須とする ・ステージングでのリリース前の確認を必須とする（受入作業） - 個々のバックログについて想定の内容か確認 - （手動）リグレッションテストを必ず実施 開発組織＆担当＋支援 開発 (外部) バックログ 仮決定 ステージング リリース 本番環境 リリース ステージング 受入テスト 1か月周期 バックログ 仮決定…

各種改善活動：Phase1 13 2．テストの環境整備 ステージング環境を整備 リグレッションテスト（手動）を整備→枠を構築（TestRail） ・顧客は少ないため、顧客が使う部分・データに絞る ・継続的なテスト管理とテストの資産化、システムの仕様記録への活用も想定 ・不具合対策の記録も取り込むことも考慮して環境を構築 開発組織＆担当＋支援 開発 (外部) ※最初期のテスト構造

参考：テストは言い訳？行動？それとも…？ 14 てすとづくり～質の高いテスト設計の原理～ より引用 https://qualab.jp/materials/stdc-kansai2012.121103.bw.pdf 不具合が多数発生する状況下にて、テストを適用するような場合には、 やみくもに実施したり、言い訳のためにやるのではなく、 納得のいく/必要なテストを考えて設計・実施することが効果的となる。

各種改善活動：Phase1 15 3．一部監視の仕組みを構築 ・発生した不具合の収集、蓄積により傾向・予測を可能とする ※時刻関連・ログイン操作周りの不具合が多いなどの傾向あり ・将来のスケーリングへ向けてデータボリューム/性能に懸念 →利用アクセス状況を調査する仕組みを取り込み、毎月確認（以下は例） 開発組織＆担当＋支援 開発 (外部)

閑話休題：Phase1通過状況 16 ＜初期フェーズの効果：ビジネスとして最小限な状況へ＞ ・毎月のリリースペースがつくられる ・対顧客サービスは多少安定 ※ただし、あくまで出口戦略的 ・受入時のテストを含めた作業負担は大きい状況 開発組織＆担当＋支援 開発 (外部) 変更の把握と管理 △ 根本問題は解決しきれていないが、 顧客提供前の段階での管理状況は改善 変更失敗率 △ 継続的なリグレッションテストの改善で 少しずつ安定も、問題は継続して発生 失敗の復元まで × 再現しない不具合は調査不可、は変わらず

閑話休題：ビジネス状況 17 このころ、ビジネス的にはピボットにより 「カスタマイズができるサービス」が中心となる。 ※ターゲット顧客に対して親身に運用を含め て丁寧なサービスが重要となった 結果として、（営業＆）現場のインテグ提供力が売上の限界を決めることなった。 →ボトルネックは一時期インテグ側となる マーケ （餌をまく） 営業 （捕まえる） 交渉・デモ （カスタム） インテグ テスト 運用・アフター サービス 営業 インテグレーション 契約 ここの処理量が 売上の要因となる ＜顧客提供までのビジネスプロセス＞ 開発組織＆担当＋支援 開発 (外部) このメンバーが インテグ作業兼務 雑ポジショニング （VS 緑の何か） 自分で おまかせ 何でも可能 専門 プロダクト

閑話休題：現場状況 18 （営業＆）インテグ提供力が売上へ影響する状況となったが…？ ・不具合対応、受入時の問題対処もパッシブな対処で負担となる ・受入側の負担は多く、本来のビジネスにも影響する状況 ※開発のカバーではなく、顧客提供のインテグがメインの仕事…のはず 開発組織＆担当＋支援 変更の把握と管理 △ 根本問題は解決しきれていないが、 顧客提供前の段階での管理状況は改善 変更失敗率 △ 継続的なリグレッションテストの改善で 少しずつ安定も、問題は継続して発生 失敗の復元まで × 再現しない不具合は調査不可、は変わらず インテグの 顧客提供可能数 × 顧客要求への対応工数が大きい 開発のお守りによる負担も発生 開発 (外部)

簡単に言いやがってシリーズ：Phase2へ 19 改善への活動についてまとめます。 1．テストを含めたプロセスの改善 2．テストの環境構築 3．一部監視の仕組みを構築 ＜閑話休題＞ 4．ツール～運用改善～ 5．ツール～拡張システム～ 6．テストの継続的改善と（ようやくの）自動化 7．監視システム強化 開発組織＆担当＋支援 変更の把握と管理 △ 根本問題は解決しきれていないが、 顧客提供前の段階での管理状況は改善 変更失敗率 △ 継続的なリグレッションテストの改善で 少しずつ安定も、問題は継続して発生 失敗の復元まで × 再現しない不具合は調査不可、は変わらず インテグ顧客提供可能数 × 顧客要求への対応工数が大きい 開発 (外部)

各種改善活動：Phase2 20 4．ツール～運用改善～ 顧客単位のインテグ作業（事前データ登録）で特にチーム負担大 ※Excelを使った登録機能があったが限定的で使いづらい状況だった 対象のシステムはSPA、趣味でPython/requestsベースの支援ツール構築 顧客側へ提供が必要なデータの登録の工数を減らし、負担削減/提供可能数を改善 開発組織＆担当＋支援 フロント バックエンド Excel登録機能はあるが 限定的＆改善困難→手間となる 特定パターンの大量 データ登録等に対処 趣味＋αで学習してた Pythonでツール作成 ※勝手にハック Excel登録機能 Python ツール 開発 (外部)

拡張システム 各種改善活動：Phase2 21 5．ツール～拡張システム～ 特定顧客から基幹システムとの連携の話が発生 トレードオフし、作成していたPythonツールを活用・洗練して Lambda化、自社開発（？）の拡張システムとして構築する方向へ ついでに、このシステムを活用して、一部（API）テスト自動化の仕組みを構築 開発組織＆担当＋支援 Pythonツール ＋Lambda（＋α）を活用 Python ツール 基幹システム （外部） フロント バックエンド pytest 自動化 APIテスト 趣味＋αで学習してた AWSで環境構築 開発 (外部)

各種改善活動：Phase2 22 5．ツール～拡張システム～ ＜プロセスとマネジメント＞ ・基幹システムとの連携は有期性のあるプロジェクト型の活動 ・顧客側とは旧態依然のマネジメントの形式をとりつつ、 実際の開発はインクリメンタル、いつでもリリース可能な形を実現 開発組織＆担当＋支援 顧客側との 契約・計画 実際の開発 の進め方 事前調整 開発・テスト 契約1 契約2 1stプロト 課題調査 インクリメンタル・ 反復的に開発を進める リリース テスト 見積り 仕様調整 運用確認 仕様調整 デモ版 提供 継続して インクリメンタル開発 （運用開始） 第2期開発 事前調整 ・・・ 正式版 リリース 不具合対応版 リリース 特定タイミングからいつでもリリース可能な状況へ 開発 (外部)

各種改善活動：Phase2 23 5．ツール～拡張システム～ ＜モデリング・設計＞ 実体の開発モジュールは2層に分ける、テストも役割を分ける 開発モジュール分を利用した派生形式で提供を可能とする ビジネスロジック側の自動テストは、若い担当者にも作成を任せる 開発組織＆担当＋支援 Scenario：ビジネスロジックをまとめる Python ツール バックエンド 自動テスト フロント 拡張システム 監視システム Connector：内部のインタフェースを担当 自動テスト ※モジュール毎にテストの責務も明確化 顧客提供の 機能チェック 連携先システムの 変化・健全性確認 派生してサービス提供を可能とする 開発 (外部)

各種改善活動：Phase2 24 開発組織＆担当＋支援 6．テストの継続的改善と（ようやくの）自動化 テストの構造は規模の拡大に応じて継続的に改善 1：各顧客単位で最低限のテスト 2：共通項目＋特殊企業という構成へ変更 3：構造見直し＋手動テストの負担削減でテスト自動化を充実化 →今後も定期メンテが続く予定 開発 (外部)

各種改善活動：Phase2 25 開発組織＆担当＋支援 6．テストの継続的改善と（ようやくの）自動化 テストの構造は規模の拡大に応じて継続的に改善 3：構造見直し＋手動テストの負担削減でテスト自動化を充実化 拡張システムのAPIテストを大幅活用して、自動化の仕組みを段階的に強化 Scenario：ビジネスロジック バックエンド 自動テスト Connector：内部インタフェース 自動テスト 顧客提供の 機能チェック 連携先システムの 変化・健全性確認 Python ツール 拡張 システム 監視 システム 派生してサービス提供 開発 (外部)

各種改善活動：Phase2 26 開発組織＆担当＋支援 6．テストの継続的改善と（ようやくの）自動化 自動テストの環境も少しずつ改善 ・最初は最低限→内部のAPIをある程度カバーする範囲へ拡大 ・並列で自動テスト実施で問題→プロダクト側の弱点として改善 →この仕組みベースで信頼性の高い拡張システムの構築へつながった ・ビジネスロジック側をカバーすることにより、手動テストの削減へ 日本語の多い構成→若いメンバーも短時間で理解して対応可能 趣味で学習してた GitHub Actionsで CI環境構築 Scenario：ビジネスロジック バックエンド 自動テスト Connector：内部インタフェース 自動テスト 顧客提供の 機能チェック 連携先システムの 変化・健全性確認 （バックエンドのテスト込み） 自動テスト ｲﾝﾀﾌｪｰｽ 自動テスト 顧客ｼﾅﾘｵ 開発 (外部)

拡張システム 各種改善活動：Phase2 27 7．監視システム強化 拡張システム側において、利用者の操作状況をログ取得可能へ WARNING/ERROR状況を毎日取得・傾向調査や 問題発生時の顧客への影響を判断できる状況へ（改善中） 開発組織＆担当＋支援 フロント バックエンド Python ツール 趣味で学習してたEventBridge （+Lambda/fargate）で環境構築 開発 (外部)

基幹システムに利用するデータを設定後に削除、 その後連携の処理をするとエラー発生 通常使わないパスなので、 別の仕様追加とあわせてデプロイ DynamoDBで再帰呼び出し（お作法）が 入っておらず、DBからのデータ取得でエラー エラー報告後、次の日リリースで修正 （運用時間を回避して次の日となった） 承認後に設定を変更するという特殊パスにて デグレによってエラーが発生した 通常使わないパスなので、 別の仕様追加とあわせてデプロイ システム管理会社がLambdaで利用している ロールを削除してしまい拡張システム停止 作業連絡が無かったこともあり、 調査に時間がかかり4時間後復旧 初期構築で使うツールにて、特定のデータ量が 多い場合にて、データ処理ができない問題発生 エラー報告後、次の日リリースで修正 状況（参考） 28 拡張システムの1年間の顧客指摘の不具合は5件、こんな感じ ※報告後、運用影響のない形で極力短時間で完了させた（つもり） 開発組織＆担当＋支援 その他、顧客から指摘されていない改善を自主的に多数実施 ・「報告されない問題」が多数あることも監視システムから判断 ・利用者の動線で無駄な操作をしていた状況を判断し、メッセージ調整で別行動を促す →受け身的な不具合対応から、アクティブな不具合対応・改善が可能となる 開発 (外部)

状況（参考） 29 ・既存のシステムは大きく変わらないとして、 拡張システム側で安定した開発をできるような状況を構築 ・あわせて自動テストも充実させ、人数を増やさずに インテグの生産量を増やすことができる状況ができた（はず*） 開発組織＆担当＋支援 変更の把握と管理 △ 〇 拡張システム側は適切に把握 変更失敗率 △ △ 拡張システム側でも2/5件のデグレが あり、今後の課題となる 失敗の復元まで △ 〇 拡張システム側で即時解決、報告前段階 の解決も可能、既存システム問題も検知 インテグの 顧客提供可能数 △ 改善余地はあるが、ツール支援により、 対応可能な数は増えた（はず*） 拡張システム フロント バックエンド Python ツール * 「はず」なのは数値的な根拠はない定性的な内容のため 開発 (外部)

さらなる成長へ向けて 30 ビジネスは少しずつ成長中、ボトルネックは前半側に移動 開発よりもマーケティング側の強化が必要となってくる状況へ マーケ （餌をまく） 営業 （捕まえる） 交渉・デモ （カスタム） インテグ テスト 運用・アフター サービス 営業 インテグレーション 契約 成長のボトルネック はより前段へ ＜顧客提供までのビジネスプロセス＞

おまけ：ES（従業員満足）とCS （顧客満足）の関係性～サービス・プロフィット・チェーン 31 改善活動の中で、内部のチーム・従業員の活動改善をする場合、 サービス業務ではESを上げる仕組みがCSひいては収益向上にもつながることもある とはいえ、適切なES向上施策が必要となることに注意！ サービスプロフィットチェーン（SPC）とは？：https://emotion-tech.co.jp/column/2019/what_is_service_profit_chain 大本の出典：「サービスプロフィットチェーンの実践法」（ヘスケット、他著、DHBR 94年7月号） 内部（従業員） サービス品質 従業員 満足 従業員 ロイヤルティ 従業員の 生産性 顧客への サービス品質 顧客 満足 顧客 ロイヤルティ 企業成長 収益拡大 ■ES→CS向上策の例 ・切磋琢磨できる他の従業員と一緒に働く ・一定の制限の中で、顧客ニーズに 対応するための裁量が与えられる ・必要な訓練や技術サポートを受けられる … ■単独では生産性に寄与しないES向上の例 ・社内イベントや懇親会により コミュニケーション活性化を図る ・（業界内で相対的に）給与を増やす ・勤務時間短縮・休暇を増やす ※過去の情報なので現在の解釈は異なる可能性もある？

各活動とソフトウェアエンジニアリングのおはなし 32 実践ソフトウェアエンジニアリング（第9版） Roger.S.Pressman他（著） 適切な知識をもって、適切な適用箇所（問題）を見極めることがだいじ。 この際、ソフトウェアエンジニアリング＋αが役立ってます。 各活動との対応を紹介します。

各活動とソフトウェアエンジニアリングのおはなし 33 問題解決を知り、必要な知識・技術を取り出す（計画する） 特に変化が多く、多数の問題が発生する状況では、外れた活動を減らすことが大事 ■プラクティスの本質は問題解決 書籍の序盤で、問題解決の本質の重要性に触れている。 （How to solve it（いかにして問題を解くか）を参照） 問題解決の手続：（ソフトウェア開発との対応、第1章） 1．問題を理解する 2．解決策を計画する 3．計画を実行に移す 4．結果が正しいことを確認する ※実際には、クリティカルシンキングやTOC思考プロセスの影響が大きい 対象だけではなく、タイミングも重要→問題解決・問題の理解が大事 実践ソフトウェアエンジニアリング（第9版） Roger.S.Pressman他（著）

各活動とソフトウェアエンジニアリングのおはなし 34 ソフトウェアエンジニアリングは開発に 必要な活動を体系化したもの（道具箱）となる ～当たり前を適切に適用できるだけでよいのです 実践ソフトウェアエンジニアリング（第9版） Roger.S.Pressman他（著） 第１章ソフトウェアとソフトウェアエンジニアリング 第１部 ソフトウェアプロセス 第２章 プロセス 第３章 アジャイルとプロセス 第４章 推奨のプロセスモデル 第５章 ソフトウェアエンジニアリングの人間的側面 第２部 モデリング 第６章 プラクティスの指針となる原則 第７章 要求エンジニアリング 第８章 要求分析モデリングの推奨手法 第９章 設計の概念 第１０章 アーキテクチャ設計の推奨手法 第１１章 コンポーネント設計 第１２章 ユーザエクスペリエンス設計 第１３章 移動体端末におけるソフトウェアの設計 第１４章 パターンに基づく設計 第３部 品質とセキュリティ 第１５章 品質の概念 第１６章 レビューの推奨手法 第１７章 ソフトウェア品質保証 第１８章 ソフトウェアセキュリティエンジニアリング 第１９章 ソフトウェアテスト－コンポーネントレベル 第２０章 ソフトウェアテスト－統合レベル 第２１章 ソフトウェアテスト－移動体端末と…に対するテスト 第２２章 ソフトウェア構成マネジメント 第２３章 ソフトウェアメトリクスと分析 第４部 ソフトウェアプロジェクトのマネジメント 第２４章 プロジェクトマネジメントの概念 第２５章 実行可能で役立つソフトウェア計画 第２６章 リスクマネジメント 第２７章 ソフトウェアサポート戦略 第５部 先進的な話題 第２８章 ソフトウエアプロセス改善 第２９章 ソフトウェアエンジニアリングの新興トレンド 第３０章 おわりに 付録１ UML入門 付録２ ソフトウェアエンジニアリのためのデータサイエンス ソフトウェア プロセス 1．テストを含めたプロセスの改善 5．ツール～拡張システム～ 常時、プロセスの調整・改善は実施 モデリング 4．ツール～運用改善～ 5．ツール～拡張システム～ ※各種の選択など その他、各種要件整理・仕様化など 品質と セキュリティ 1．テストを含めたプロセスの改善 2．テストの環境整備 6．テスト改善的改善と自動化 プロジェクト マネジメント ＆サポート戦略 3．一部監視の仕組みを構築 5．ツール～拡張システム～ ※顧客との対応 7．監視システム強化 その他、変更管理など ※当たり前になりすぎて触れない部分も多いかも

各活動とソフトウェアエンジニアリングのおはなし 35 個人的に好きなのはプロセス系。どんな状況でも改善につなげることができます。 実践ソフトウェアエンジニアリング（第9版） Roger.S.Pressman他（著） ＜某白い本の内容（第一部：ソフトウェアプロセス）と役立つ部分＞ ・プロセスの構成、どんな場合に効果的かなどが歴史的背景を含め理解できる - ウォーターフォール VS アジャイルとか馬鹿らしくなります ・プロセスを自在に選定・コントロールできる能力を身につけることが重要 - 清水吉男さんの次のURLの資料もあわせて読むと相互に知識が補完されます https://affordd.jp/koha_hp/process/PFDform3.pdf

各活動とソフトウェアエンジニアリングのおはなし 36 確かにこんなプロセスをやっていた、という感触も（無意識ですが）。 ※実践ソフトウェアエンジニアリング第4章「推奨のプロセス」より引用 実践ソフトウェアエンジニアリング（第9版） Roger.S.Pressman他（著） 顧客側との 契約・計画 実際の開発 の進め方 事前調整 開発・テスト 契約1 契約2 1stプロト 課題調査 インクリメンタル・ 反復的に開発を進める リリース テスト 見積り 仕様調整 運用確認 仕様調整 デモ版 提供 継続して インクリメンタル開発 （運用開始） 第2期開発 事前調整 正式版 リリース 不具合対応版 リリース

さいごに：より高品質なソフトウェア開発を。 37 問題を適切に見極める力 × 道具箱の多様性・専門性 クリティカルシンキング ロジカルシンキング 問題解決・仮説思考 TOC、TOCfE など ※今回は特に言及せず ビジネス 現場/オペレーション 適切な道具を活用することで、現場を、そしてビジネスを改善していきましょう！ ソフトウェアエンジニアリング 他にも、各種開発技術 経営・ビジネス関連知識 など