Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ビジネスと現場活動をつなぐソフトウェアエンジニアリング~とあるスタートアッププロダクトの成長記...

みずのり
February 07, 2025

 ビジネスと現場活動をつなぐソフトウェアエンジニアリング~とあるスタートアッププロダクトの成長記録より~

QDG2025の発表資料
新規事業・スタートアップのプロダクトで発生する様々な問題に対して、ソフトウェアエンジニアリングの各種知見を使って改善していく事例を紹介します。
※当日発表とは異なり、キレイなバージョンです

みずのり

February 07, 2025
Tweet

More Decks by みずのり

Other Decks in Technology

Transcript

  1. 自己紹介:ソフトウェアエンジニアリング 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ロボコン実行委員など
  2. 自己紹介:思考技術、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)
  3. 自己紹介:テスト/要件定義関連 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+プロトタイピングおよび仕様化時に役立つ技術、事例紹介
  4. ゼロとイチ以降は異なる 10 ゼロイチのイチ以降は必要となされる状況が大きく変化する ビジネスができるソフトウェア提供状況から、大きく乖離した… とにかくアイデアを試す 思いついたものをとにかく作る →共有されないものが入る 高速にスクラッチ&ビルド 作り直しが何度も入ることでデグレへ 不具合は許容・テスト不要

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

    7.監視システム強化 変更の把握と管理 × 仕様に書いても実装されない 報告されていないものが入っている 変更失敗率 × デグレ多発+触れるたびに不具合発生 失敗の復元まで × 再現しない不具合は調査しない ログもないのでそもそも調査できない 開発組織&担当+支援 開発 (外部)
  6. 閑話休題:Phase1通過状況 16 <初期フェーズの効果:ビジネスとして最小限な状況へ> ・毎月のリリースペースがつくられる ・対顧客サービスは多少安定 ※ただし、あくまで出口戦略的 ・受入時のテストを含めた作業負担は大きい状況 開発組織&担当+支援 開発 (外部)

    変更の把握と管理 △ 根本問題は解決しきれていないが、 顧客提供前の段階での管理状況は改善 変更失敗率 △ 継続的なリグレッションテストの改善で 少しずつ安定も、問題は継続して発生 失敗の復元まで × 再現しない不具合は調査不可、は変わらず
  7. 閑話休題:ビジネス状況 17 このころ、ビジネス的にはピボットにより 「カスタマイズができるサービス」が中心となる。 ※ターゲット顧客に対して親身に運用を含め て丁寧なサービスが重要となった 結果として、(営業&)現場のインテグ提供力が売上の限界を決めることなった。 →ボトルネックは一時期インテグ側となる マーケ (餌をまく)

    営業 (捕まえる) 交渉・デモ (カスタム) インテグ テスト 運用・アフター サービス 営業 インテグレーション 契約 ここの処理量が 売上の要因となる <顧客提供までのビジネスプロセス> 開発組織&担当+支援 開発 (外部) このメンバーが インテグ作業兼務 雑ポジショニング (VS 緑の何か) 自分で おまかせ 何でも可能 専門 プロダクト
  8. 閑話休題:現場状況 18 (営業&)インテグ提供力が売上へ影響する状況となったが…? ・不具合対応、受入時の問題対処もパッシブな対処で負担となる ・受入側の負担は多く、本来のビジネスにも影響する状況 ※開発のカバーではなく、顧客提供のインテグがメインの仕事…のはず 開発組織&担当+支援 変更の把握と管理 △ 根本問題は解決しきれていないが、

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

    7.監視システム強化 開発組織&担当+支援 変更の把握と管理 △ 根本問題は解決しきれていないが、 顧客提供前の段階での管理状況は改善 変更失敗率 △ 継続的なリグレッションテストの改善で 少しずつ安定も、問題は継続して発生 失敗の復元まで × 再現しない不具合は調査不可、は変わらず インテグ顧客提供可能数 × 顧客要求への対応工数が大きい 開発 (外部)
  10. 各種改善活動:Phase2 22 5.ツール~拡張システム~ <プロセスとマネジメント> ・基幹システムとの連携は有期性のあるプロジェクト型の活動 ・顧客側とは旧態依然のマネジメントの形式をとりつつ、 実際の開発はインクリメンタル、いつでもリリース可能な形を実現 開発組織&担当+支援 顧客側との 契約・計画

    実際の開発 の進め方 事前調整 開発・テスト 契約1 契約2 1stプロト 課題調査 インクリメンタル・ 反復的に開発を進める リリース テスト 見積り 仕様調整 運用確認 仕様調整 デモ版 提供 継続して インクリメンタル開発 (運用開始) 第2期開発 事前調整 ・・・ 正式版 リリース 不具合対応版 リリース 特定タイミングからいつでもリリース可能な状況へ 開発 (外部)
  11. 各種改善活動:Phase2 23 5.ツール~拡張システム~ <モデリング・設計> 実体の開発モジュールは2層に分ける、テストも役割を分ける 開発モジュール分を利用した派生形式で提供を可能とする ビジネスロジック側の自動テストは、若い担当者にも作成を任せる 開発組織&担当+支援 Scenario:ビジネスロジックをまとめる Python

    ツール バックエンド 自動テスト フロント 拡張システム 監視システム Connector:内部のインタフェースを担当 自動テスト ※モジュール毎にテストの責務も明確化 顧客提供の 機能チェック 連携先システムの 変化・健全性確認 派生してサービス提供を可能とする 開発 (外部)
  12. 基幹システムに利用するデータを設定後に削除、 その後連携の処理をするとエラー発生 通常使わないパスなので、 別の仕様追加とあわせてデプロイ DynamoDBで再帰呼び出し(お作法)が 入っておらず、DBからのデータ取得でエラー エラー報告後、次の日リリースで修正 (運用時間を回避して次の日となった) 承認後に設定を変更するという特殊パスにて デグレによってエラーが発生した

    通常使わないパスなので、 別の仕様追加とあわせてデプロイ システム管理会社がLambdaで利用している ロールを削除してしまい拡張システム停止 作業連絡が無かったこともあり、 調査に時間がかかり4時間後復旧 初期構築で使うツールにて、特定のデータ量が 多い場合にて、データ処理ができない問題発生 エラー報告後、次の日リリースで修正 状況(参考) 28 拡張システムの1年間の顧客指摘の不具合は5件、こんな感じ ※報告後、運用影響のない形で極力短時間で完了させた(つもり) 開発組織&担当+支援 その他、顧客から指摘されていない改善を自主的に多数実施 ・「報告されない問題」が多数あることも監視システムから判断 ・利用者の動線で無駄な操作をしていた状況を判断し、メッセージ調整で別行動を促す →受け身的な不具合対応から、アクティブな不具合対応・改善が可能となる 開発 (外部)
  13. 状況(参考) 29 ・既存のシステムは大きく変わらないとして、 拡張システム側で安定した開発をできるような状況を構築 ・あわせて自動テストも充実させ、人数を増やさずに インテグの生産量を増やすことができる状況ができた(はず*) 開発組織&担当+支援 変更の把握と管理 △ 〇

    拡張システム側は適切に把握 変更失敗率 △ △ 拡張システム側でも2/5件のデグレが あり、今後の課題となる 失敗の復元まで △ 〇 拡張システム側で即時解決、報告前段階 の解決も可能、既存システム問題も検知 インテグの 顧客提供可能数 △ 改善余地はあるが、ツール支援により、 対応可能な数は増えた(はず*) 拡張システム フロント バックエンド Python ツール * 「はず」なのは数値的な根拠はない定性的な内容のため 開発 (外部)
  14. さらなる成長へ向けて 30 ビジネスは少しずつ成長中、ボトルネックは前半側に移動 開発よりもマーケティング側の強化が必要となってくる状況へ マーケ (餌をまく) 営業 (捕まえる) 交渉・デモ (カスタム)

    インテグ テスト 運用・アフター サービス 営業 インテグレーション 契約 成長のボトルネック はより前段へ <顧客提供までのビジネスプロセス>
  15. おまけ: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向上の例 ・社内イベントや懇親会により コミュニケーション活性化を図る ・(業界内で相対的に)給与を増やす ・勤務時間短縮・休暇を増やす ※過去の情報なので現在の解釈は異なる可能性もある?
  16. 各活動とソフトウェアエンジニアリングのおはなし 33 問題解決を知り、必要な知識・技術を取り出す(計画する) 特に変化が多く、多数の問題が発生する状況では、外れた活動を減らすことが大事 ▪プラクティスの本質は問題解決 書籍の序盤で、問題解決の本質の重要性に触れている。 (How to solve it(いかにして問題を解くか)を参照)

    問題解決の手続:(ソフトウェア開発との対応、第1章) 1.問題を理解する 2.解決策を計画する 3.計画を実行に移す 4.結果が正しいことを確認する ※実際には、クリティカルシンキングやTOC思考プロセスの影響が大きい 対象だけではなく、タイミングも重要→問題解決・問題の理解が大事 実践ソフトウェアエンジニアリング(第9版) Roger.S.Pressman他(著)
  17. 各活動とソフトウェアエンジニアリングのおはなし 34 ソフトウェアエンジニアリングは開発に 必要な活動を体系化したもの(道具箱)となる ~当たり前を適切に適用できるだけでよいのです 実践ソフトウェアエンジニアリング(第9版) Roger.S.Pressman他(著) 第1章ソフトウェアとソフトウェアエンジニアリング 第1部 ソフトウェアプロセス

    第2章 プロセス 第3章 アジャイルとプロセス 第4章 推奨のプロセスモデル 第5章 ソフトウェアエンジニアリングの人間的側面 第2部 モデリング 第6章 プラクティスの指針となる原則 第7章 要求エンジニアリング 第8章 要求分析モデリングの推奨手法 第9章 設計の概念 第10章 アーキテクチャ設計の推奨手法 第11章 コンポーネント設計 第12章 ユーザエクスペリエンス設計 第13章 移動体端末におけるソフトウェアの設計 第14章 パターンに基づく設計 第3部 品質とセキュリティ 第15章 品質の概念 第16章 レビューの推奨手法 第17章 ソフトウェア品質保証 第18章 ソフトウェアセキュリティエンジニアリング 第19章 ソフトウェアテスト-コンポーネントレベル 第20章 ソフトウェアテスト-統合レベル 第21章 ソフトウェアテスト-移動体端末と…に対するテスト 第22章 ソフトウェア構成マネジメント 第23章 ソフトウェアメトリクスと分析 第4部 ソフトウェアプロジェクトのマネジメント 第24章 プロジェクトマネジメントの概念 第25章 実行可能で役立つソフトウェア計画 第26章 リスクマネジメント 第27章 ソフトウェアサポート戦略 第5部 先進的な話題 第28章 ソフトウエアプロセス改善 第29章 ソフトウェアエンジニアリングの新興トレンド 第30章 おわりに 付録1 UML入門 付録2 ソフトウェアエンジニアリのためのデータサイエンス ソフトウェア プロセス 1.テストを含めたプロセスの改善 5.ツール~拡張システム~ 常時、プロセスの調整・改善は実施 モデリング 4.ツール~運用改善~ 5.ツール~拡張システム~ ※各種の選択など その他、各種要件整理・仕様化など 品質と セキュリティ 1.テストを含めたプロセスの改善 2.テストの環境整備 6.テスト改善的改善と自動化 プロジェクト マネジメント &サポート戦略 3.一部監視の仕組みを構築 5.ツール~拡張システム~ ※顧客との対応 7.監視システム強化 その他、変更管理など ※当たり前になりすぎて触れない部分も多いかも
  18. 各活動とソフトウェアエンジニアリングのおはなし 36 確かにこんなプロセスをやっていた、という感触も(無意識ですが)。 ※実践ソフトウェアエンジニアリング第4章「推奨のプロセス」より引用 実践ソフトウェアエンジニアリング(第9版) Roger.S.Pressman他(著) 顧客側との 契約・計画 実際の開発 の進め方

    事前調整 開発・テスト 契約1 契約2 1stプロト 課題調査 インクリメンタル・ 反復的に開発を進める リリース テスト 見積り 仕様調整 運用確認 仕様調整 デモ版 提供 継続して インクリメンタル開発 (運用開始) 第2期開発 事前調整 正式版 リリース 不具合対応版 リリース
  19. さいごに:より高品質なソフトウェア開発を。 37 問題を適切に見極める力 × 道具箱の多様性・専門性 クリティカルシンキング ロジカルシンキング 問題解決・仮説思考 TOC、TOCfE など

    ※今回は特に言及せず ビジネス 現場/オペレーション 適切な道具を活用することで、現場を、そしてビジネスを改善していきましょう! ソフトウェアエンジニアリング 他にも、各種開発技術 経営・ビジネス関連知識 など