内製化を目指す事業会社が、システム開発会社と共に進める「開発生産性改善」の取り組み事例 #devsumi

Transcript

1. 内製化を目指す事業会社が、 システム開発会社と共に進める 「開発生産性改善」の取り組み事例 #devsumi
2. 1 AGENDA 本 日 お 話 し す る こ と 01 02 03 04 05 06 はじめに 07 08 09 株式会社アンビシャスについて 対象システム・開発体制・プロセス 開発体制の変遷 開発生産性 成果の大きい課題の設定 開発プロセス 開発チームより 文化・雰囲気・大切にしていること 10 現状の課題と今後
3. はじめに Copyright © 2024 Ambitious Co., Ltd. All Rights Reserved.
4. 3 資料公開について 01 本日の資料はSpeakerDeckにて公開し、 X（旧Twitter）にて展開します。
5. 4 はじめに 01 - エンジニア・開発者っぽくない内容も含みます。 - FourKeysやSPACE等、開発生産性のフレームワークの話は ほぼしません。 - 開発生産性の向上をバリバリ試行している方には物足りない 内容かもしれません。 少しでも皆様の参考になり、何かしらお持ち帰り頂き、 明日からの業務を、人生をより良く、 「新しいスタンダード」に活かして頂けますと幸いです。
6. 5 堀江 優仁（ほりえ ゆうじ） 経営管理部 システム課 課長 大阪本社勤務 システムインテグレーターにて製造業・小売業の業務システム開発において、SEと して全フェーズを10年以上経験した後、2019年にアンビシャスへ入社。 アンビシャスでは、収納ピットサイト開発、トランクルーム店舗のIT化・システム 構築、各種社内システム管理、クラウド活用といったIT全般、及びエンジニアの組 織作りなど広く担当。 ベンチプレスのMax記録は95kg 自己紹介 01 @Yuwji
7. 株式会社アンビシャスについて Copyright © 2024 Ambitious Co., Ltd. All Rights Reserved.
8. 7 会社名 株式会社アンビシャス 創立年 2006年7月 大阪本社所在地 大阪市中央区南船場1丁目3-5 リプロ南船場8階 東京支社所在地 東京都中央区日本橋茅場町2丁目11-8 茅場町駅前ビル5階 主な事業内容 トランクルーム「収納ピット」の運営、及び同サービスのFC運営 代表取締役社長 徳永 暢也 従業員数 90名（正社員58名・アルバイト32名、2024年6月時点） 資本金 4,000万円 24年6月期 売上高／営業利益 約25億円 ／ 約2.5億円 はじめに 02 https://ambitious8.biz/ https://www.syuno-pit.biz/ https://fc-pit.biz/ 会社概要 FC募集
9. 8 トランクルーム事業とは スペースの提供を通じて住環境を改善 するサービスです。 コンテナやパーテーションで区切ったス ペースを貸し出し、お客様にご利用いた だいております。 8
10. 9 - 日本全国で６７０店舗 - 大阪市中央区で３０店舗 - 年間１００店舗出店 はじめに 02
11. 10 会場周辺にも沢山あります！！ 02
12. 11 出典：セルフストレージの将来展望（一般社団法人日本セルフストレージ協会）より引用。 出典：Selfstorage.org, Selfstorage.com.au, FEDESSA.org, 日本セルフストレージ協会, CSSA.ca, SSAUK.comより引用。 出典：SELF STORAGE UK ANNUAL REPORT DATA COMPILED FROM 2023 CALENDAR YEARより引用。 出典：U.S. Self-Storage Industry Statisticsより引用。 諸外国の普及率をベースに考えると、アンビシャスは世帯普及率が約3% （市場規模約2400億円）まで成長すると考えています。 2 0 1 1 年 2 0 1 1 年 世界のトランクルーム普及率 02 2 0 2 3 年 2 0 2 3 年 10世帯に1室 約2兆円市場 100世帯に1室 約400億円市場 300世帯に1室 約200億円市場 30世帯に1室 約800億円市場 9世帯に1室 約4兆円市場 100世帯に1室 約800億円市場 40年前（1970年頃）の米国と同程度の成長率で日本も普及しています。狭い住宅事情に加え、物を捨てず に大切にする文化がある日本では、今後もこのサービスの需要は大きくなっていくと推測されます。
13. 12 20年 21年 22年 23年 24年 25年 26年 27年 28年 29年 30年 735億 765 797 825 854 886 918 954 990 1029 1069 ✱ 出典：矢野経済研究所（2023年版 拡大する収納ビジネス市場の徹底調査の中位推計）より引用 2020-2030 成長率：約4% 日本のトランクルーム市場 02 中位推計に基づくと2024年から5年後には約20％市場規模が拡大される見込み。 認知度は確実に向上しており、利用者の増加とともに成長中です。
14. 13 日本のトランクルーム市場（少し古いデータ） 02
15. 対象システム 開発体制 開発プロセス Copyright © 2024 Ambitious Co., Ltd. All Rights Reserved.
16. 15 対象システム 03 - トランクルーム「収納ピット」のサービスサイト - 埋まり状況の閲覧や契約締結ができる - SEO対策、UI/UX改善、サービス追加・改善、BO等
17. 16 開発体制 03 PdMチーム（3名） 案件担当チーム（2名） マネージャー（1名） 要件定義担当（1名） 開発チーム（5名） 当初、要件定義はアンビシャスが担っていましたが、 現在は一部システムアイ社へも依頼しています。 事業・BO・システム
18. 17 開発プロセス 03 # 共通 - アジャイル（非スクラム） - 本番デプロイは週次 - 定例会（週次） - 要件定義打合せ（週次） # 各社実施 - 朝会 - 週次ふりかえり # アンビシャス - リファインメント（隔週）
19. 18 開発プロセス 03 PdM 要件定義担当 課題の 発見・定義 企画・ 要件定義 開発 テスト デプロイ 運用 新たな 課題 PBL PdM 案件担当 開発チーム PdM 案件担当 検証環境 本番環境 PdM 現場 課題設定 PBI発行 リファインメント 設計・開発・ テスト・レビュー デプロイ 検証・レビュー 要件定義 デプロイ 運用 課題抽出
20. 19 開発プロセス 03 PdM 要件定義担当 課題の 発見・定義 企画・ 要件定義 開発 テスト デプロイ 運用 新たな 課題 PBL PdM 案件担当 PdM 案件担当 検証環境 本番環境 PdM 現場 課題設定 PBI発行 リファインメント デプロイ 検証・レビュー 要件定義 デプロイ 運用 課題抽出 週次 適宜 適宜 適宜 週次MTG 隔週 適宜 常時 常時 設計・開発・ テスト・レビュー 適宜 開発チーム
21. 開発体制の変遷 Copyright © 2024 Ambitious Co., Ltd. All Rights Reserved.
22. 21 開発体制の変遷 04 2019年9月 2023年1月 2023年11月 2024年3月 2024年4月 2024年7月 収納ピットサイトでの契約（Web契約）を開始 エンジニア追加アサインの相談 SESメンバーのアサインを開始 システム開発会社の変更（意思決定は晩春） SESメンバーのアサインを解消 システム開発会社の体制強化 ※要件定義メンバー システム開発会社の体制強化 0.7人 1.7人（0.7+1.0） 3.0人（2.0+1.0） 2.0人（2.0+0.0） 2.0人 5.0人 開発者数(マネジメント系を除く)
23. 22 開発体制の変遷 04 2019年9月 2023年1月 2023年11月 2024年3月 2024年4月 2024年7月 収納ピットサイトでの契約（Web契約）を開始 エンジニア追加アサインの相談 SESメンバーのアサインを開始 システム開発会社の変更（意思決定は晩春） SESメンバーのアサインを解消 システム開発会社の体制強化 ※要件定義メンバー システム開発会社の体制強化 0.7人 1.7人（0.7+1.0） 3.0人（2.0+1.0） 2.0人（2.0+0.0） 2.0人 5.0人 開発者数(マネジメント系を除く) 内製化したいが、エンジニア採用が上手く行かず、 試行錯誤を繰り返してきた。
24. 23 開発体制の変遷 04 2019年9月 2023年1月 2023年11月 2024年3月 2024年4月 2024年7月 収納ピットサイトでの契約（Web契約）を開始 エンジニア追加アサインの相談 SESメンバーのアサインを開始 システム開発会社の変更（意思決定は晩春） SESメンバーのアサインを解消 システム開発会社の体制強化 ※要件定義メンバー システム開発会社の体制強化 0.7人 1.7人（0.7+1.0） 3.0人（2.0+1.0） 2.0人（2.0+0.0） 2.0人 5.0人 開発者数(マネジメント系を除く)
25. 24 2023年11月～：システム開発会社を変更 04 # 課題（変更を意思決定した理由） - エンジニアの追加アサインができない - 施策がスタック - 施策が提起されなくなる - 競合他社にWeb活用が追いつかれ始める - 内製化を経営層に説得できない状況 - スキル・リソースが不足（インフラ・マネジメント） # 改善施策 - 事業成長を第一に、安定して開発・保守を担え、アサインの柔軟 性・技術力を持った開発会社に変更し、事業を進めることに。
26. 25 開発体制の変遷 04 2019年9月 2023年1月 2023年11月 2024年3月 2024年4月 2024年7月 収納ピットサイトでの契約（Web契約）を開始 エンジニア追加アサインの相談 SESメンバーのアサインを開始 システム開発会社の変更（意思決定は晩春） SESメンバーのアサインを解消 システム開発会社の体制強化 ※要件定義メンバー システム開発会社の体制強化 0.7人 1.7人（0.7+1.0） 3.0人（2.0+1.0） 2.0人（2.0+0.0） 2.0人 5.0人 開発者数(マネジメント系を除く)
27. 26 2024年3月：SESメンバーのアサインを解消 04 # 課題 - 新開発会社が当初の想定以上に機能 - 新開発会社、SESメンバーとマネジメントラインが2つある ことで、リソースが圧迫され機能不全気味に。 # 改善施策 - SESメンバーのアサインを解消
28. 27 開発体制の変遷 04 2019年9月 2023年1月 2023年11月 2024年3月 2024年4月 2024年7月 収納ピットサイトでの契約（Web契約）を開始 エンジニア追加アサインの相談 SESメンバーのアサインを開始 システム開発会社の変更（意思決定は晩春） SESメンバーのアサインを解消 システム開発会社の体制強化 ※要件定義メンバー システム開発会社の体制強化 0.7人 1.7人（0.7+1.0） 3.0人（2.0+1.0） 2.0人（2.0+0.0） 2.0人 5.0人 開発者数(マネジメント系を除く)
29. 28 2024年7月：システム開発会社の体制強化 04 # 課題 - 機能しているとは言え、旧開発会社時代の残留チケット・ 新チケットの数が多く、中々消化しきれない。 - 一定以上の規模の案件・施策は別メンバーをアサインして 頂いていたが、プロジェクト終了に伴い、離脱するため、 ナレッジ・ドメイン知識が溜まりづらい。 # 改善施策 - 常時開発チームを増員し、チーム内で全ての施策の開発を進 めるよう体制を変更。（開発メンバーの固定）
30. 29 こうして今の形へ 04 PdMチーム（3名） 案件担当チーム（2名） マネージャー（1名） 要件定義担当（1名） 開発チーム（5名） 事業・BO・システム
31. 30 これまでの変遷からの学び 04 1. 名が知れていないリアル系企業のエンジニア採用は難しい。 まずは開発会社に頼るのもアリ。 2. 施策がスタックし続けると、無意識下で競争力が落ちる。 3. エンジニアリングに纏わるスキルは重要。 安定稼働している状態で、スキル・リソースが整わない中で既存システム の内製化はリスク。 （インフラ・マネジメント・要件定義・設計・進行管理）
32. 31 これまでの変遷からの学び 04 4. 案件毎のアサインは、ナレッジ・ドメイン知識が溜まりづらく、 開発生産性の低下に繋がる。開発案件が続くことが予定・予想されるなら、 開発チームの固定・増員が良い。 5. 1リポジトリなら、開発体制が2ピザルールを超えるまでは、 チーム数・マネジメントラインは増やさない方が良い。
33. 32 これまでの変遷からの学び 04 4. 案件毎のアサインは、ナレッジ・ドメイン知識が溜まりづらく、 開発生産性の低下に繋がる。開発案件が続くことが予定・予想されるなら、 開発チームの固定・増員が良い。 5. 1リポジトリなら、開発体制が2ピザルールを超えるまでは、 チーム数・マネジメントラインは増やさない方が良い。 極々当たり前なことの重要性を再認識
34. 33 契約形態 04 # 従来 - 保守契約＋請負契約 # 現在 - 準委任契約 - 完成物を定義する請負契約とアジャイルは親和性が低い - 内製化を考慮し、派遣契約に変更する可能性あり
35. 34 契約形態 04 # 従来 - 保守契約＋請負契約 - PLを考慮した会計処理がしやすい - 保守契約＝費用計上、請負契約＝資産計上 # 現在 - 準委任契約 - 完成物を定義する請負契約とアジャイルは親和性が低い - 内製化を考慮し、派遣契約に変更する可能性あり - 会計処理が煩雑 - チケット毎に資産or費用を管理し、請求時に内訳記載頂く
36. 開発生産性 Copyright © 2024 Ambitious Co., Ltd. All Rights Reserved.
37. 36 「開発生産性」を測る指標 開発生産性 05
38. 37 FourKeys/DORAメトリクス 05 DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフト ウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。 ・デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 ・変更のリードタイム - commit から本番環境稼働までの所要時間 ・変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%） ・サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
39. 38 SPACEフレームワーク 05 SPACEは生産性を多面的に評価するためのフレームワークである。「開発者の状況や測定した い内容に合わせて、正しいメトリクスのセットを特定するためのフレームワークとして定義さ れている」とフォースグレン氏は説明する。また「SPACEとDORAは補完的な関係にある」と いう。DORAを使用して改善したい項目を特定した後、SPACEを使用してどのメトリクスを使 用するかを決定するのである。つまりSPACEは開発者が行いたい作業や、働く文脈に適したメ トリクスを選ぶためのフレームワークと言える。 - 満足度と健康状態（Satisfaction and well-being） - パフォーマンス（Performance） - アクティビティ（Activity） - コミュニケーションとコラボレーション（Communication and collaboration） - 効率とフロー（Efficiency and flow） - https://codezine.jp/article/detail/18241
40. 39 そもそも「開発生産性」とは 開発生産性 05
41. 40 「生産性」 05 - 資源から付加価値を産み出す際の効率の程度 - 生産性 = 産出量 / 投入量 https://ja.wikipedia.org/wiki/%E7%94%9F%E7%94%A3%E6%80%A7
42. 41 開発生産性 05 課題の 発見・定義 企画・ 要件定義 開発 テスト デプロイ 運用 新たな 課題 資源・インプット 付加価値・アウトプット
43. 42 資源を一定と仮置きして、 「システム開発プロセス全体を通して、 アウトプットを生み出す度合い」とします。 開発生産性 05
44. 43 システム開発プロセス 05 課題の 発見・定義 企画・ 要件定義 開発 テスト デプロイ 運用 新たな 課題
45. 44 開発生産性向上策のイメージ 本題 05 課題の 発見・定義 企画 開発 テスト デプロイ 運用 新たな 課題 開発に関わるプロセスの改善
46. 45 開発生産性向上策のイメージ 本題 05 課題の 発見・定義 企画 開発 テスト デプロイ 運用 新たな 課題 開発に関わるプロセスの改善 ここだけで良い？？
47. 46 資源を一定と仮置きして、 「システム開発プロセス全体を通して、 アウトプットを生み出す度合い」とします。 開発生産性 05
48. 47 2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフ トウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。 ・まったく使わない: 24% ・ほとんど使わない: 56% ・よく使う: 8% ・いつも使う: 12% つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさ んの人を集めて、たくさんの機能を作るのは、ムダである可能性が高いと言えます。 アウトプット？ 05 https://www.ryuzee.com/contents/blog/14563 システムの機能の利用状況
49. 48 本題 05 ・使われない機能は、成果には繋がらない ・アウトプット（生産量）を多く出しても、 成果には繋がらない →アウトプット（生産量）≠アウトカム（成果量）
50. 49 資源を一定と仮置きして、 「システム開発プロセス全体を通して、 アウトプットアウトカムを生み出す度合い」 とします。 開発生産性 05
51. 50 開発生産性 05 課題の 発見・定義 企画・ 要件定義 開発 テスト デプロイ 運用 新たな 課題 資源・インプット 付加価値・アウトカム
52. 51 開発生産性 05 課題の 発見・定義 企画・ 要件定義 開発 テスト デプロイ 運用 新たな 課題 資源・インプット 付加価値・アウトカム ①課題の成果量が小さければ ②如何に生産性が高くても ③アウトカムは小さくなる
53. 52 開発生産性 05 課題の 発見・定義 企画・ 要件定義 開発 テスト デプロイ 運用 新たな 課題 資源・インプット 付加価値・アウトカム ここの改善だけでは 実現できない
54. 53 開発生産性 05 課題の 発見・定義 企画・ 要件定義 開発 テスト デプロイ 運用 新たな 課題 資源・インプット 付加価値・アウトカム ここが重要
55. 54 05 「アウトカムの高い課題」 を設定することが重要
56. 55 本題 05 課題の 発見・定義 企画 開発 テスト デプロイ 運用 新たな 課題 PdMチームが成果の大きい課題を設定し、 課題の 発見・定義 企画 開発 テスト デプロイ 運用 新たな 課題 開発チームが、安心して、素早く、品質の高い システムを開発する
57. 56 開発生産性を高くするには 05 成果量の高い課題 を設定 開発に関わる プロセス・仕組みを改善 ✕ ＝ 高い開発生産性 低 低 ✕ ＝ 低 低 高 ✕ ＝ 中 高 低 ✕ ＝ 中 高 高 ✕ ＝ 高 両輪の改善が重要
58. 57 ちなみに２ 05 ※ビルドトラップの話でした ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行 き詰まっている状況のことです。実際に生み出した価値ではなく、機能の開発とリリースに集 中してしまっている状況です。
59. 58 開発生産性 05 その為に取り組んできたことをお話します
60. 成果の大きい課題の設定 Copyright © 2024 Ambitious Co., Ltd. All Rights Reserved.
61. 60 「成果」の定義や優先順を チーム・組織内で揃える必要がある。 「成果」の大きい課題設定 06 売上が大事 業務効率化が大事 お客様の利便性 向上が大事 チーム・組織内で「成果」の優先順の定義・認識が 合っていないと、纏まらない・ブレる
62. 61 アンビシャスの場合 ①営業利益・お客様の利便性向上 ②業務運用の効率化 ③上場準備 ※社内外の状況によるが基本は上記の順 ※法対応は当然に優先のため割愛 「成果」の定義・優先順 06
63. 62 利益を出すことで、3つのことが実現できる ①社員への還元 ②研究開発・次への投資 ③納税 …税金を通して、国・自治体が 社会貢献・還元してくれる なぜ営業利益 06
64. 63 「社会への貢献」が企業理念の中心にある なぜ営業利益 06
65. 64 利益を出すことで、3つのことが実現できる ①社員への還元 ②研究開発・次への投資 ③納税 …税金を通して、国・自治体が 社会貢献・還元してくれる なぜ営業利益 06
66. 65 道徳なき経済は犯罪であり、経済なき道徳は寝言である （二宮尊徳） 「社会貢献したい」と事業活動をしていても、 利益が出なければ、いつかは資金不足となり、 永続的に事業活動を行えなくなる ＝社会貢献できなくなる →社会貢献を続けるには利益を出さないといけない なぜ営業利益 06
67. 66 ①営業利益＝本業での利益 ②営業利益＝売上－売上原価－販管費 ③課題・施策がいずれなのかを見極める 試算し、数値化する ・売上を上げる ・売上原価を下げる ・販管費を下げる 営業利益とは 06 売 上 高 売 上 総 利 益 営 業 利 益 経 常 利 益 税 引 前 当 期 純 利 益 当 期 純 利 益 売上 原価 販売 管理費 営業外 損益 特別損益 法人税等
68. 67 ①営業利益＝本業での利益 ②営業利益＝売上－売上原価－販管費 ③課題・施策がいずれなのかを見極める 試算し、数値化する ・売上を上げる ・売上原価を下げる ・販管費を下げる 営業利益とは 06 売 上 高 売 上 総 利 益 営 業 利 益 経 常 利 益 税 引 前 当 期 純 利 益 当 期 純 利 益 売上 原価 販売 管理費 営業外 損益 特別損益 法人税等
69. 68 ①営業利益＝本業での利益 ②営業利益＝売上－売上原価－販管費 ③課題・施策がいずれなのかを見極める 試算し、数値化する ・売上を上げる ・売上原価を下げる ・販管費を下げる 営業利益とは 06 売 上 高 売 上 総 利 益 営 業 利 益 経 常 利 益 税 引 前 当 期 純 利 益 当 期 純 利 益 売上 原価 販売 管理費 営業外 損益 特別損益 法人税等
70. 69 ①お客様の利便性を向上 06 お客様の利便性を向上 売上（契約） 自ずと売上に繋がるため重要
71. 70 ・人件費は販管費内 ・営業利益インパクト＝ （現在掛かっている時間－改善後の時間） ✕ 人数 ✕ 人件費 →組織が小規模な間はインパクト少 ※組織拡大を見据えて、 先手で効率化を図ることも。 ②業務運用の効率化 06 売 上 高 売 上 総 利 益 営 業 利 益 売上 原価 販売 管理費
72. 71 当然大事 ③上場準備 06 ※上場の目的によるかも知れない。
73. 72 アンビシャスの場合 ①営業利益・お客様の利便性向上 ②業務運用の効率化 ③上場準備 ※タイミングによって、②③の重要度が増す。 ※状況や戦略を鑑みて、重要度・優先順を判断する。 「成果」の定義 06
74. 73 「成果」の定義 06 「成果」の定義や優先順が 企業レベルで統一されている
75. 74 「成果」の定義 06 「成果」の定義や優先順が 企業レベルで統一されている めちゃ助かる
76. 75 「成果」の定義 06 システム開発会社メンバー向けにも共有し、 オンボーディングの一貫として、場を持って説明。 意思決定が似てくる
77. 76 リファインメント 06 リファインメント スクラムガイドの記述をまとめると、プロダクトバックログリファインメントでは以下のよう なことを行うとあります。 - プロダクトバックログアイテムを新たに作る - プロダクトバックログアイテムを分割する - プロダクトバックログアイテムを詳細にする - プロダクトバックログアイテムの説明を追加・更新する - プロダクトバックログアイテムの並び順を更新する - プロダクトバックログアイテムのサイズを追加・更新する（見積もる） https://www.ryuzee.com/contents/blog/14584
78. 77 リファインメント 06 リファインメント スクラムガイドの記述をまとめると、プロダクトバックログリファインメントでは以下のよう なことを行うとあります。 - プロダクトバックログアイテムを新たに作る - プロダクトバックログアイテムを分割する - プロダクトバックログアイテムを詳細にする - プロダクトバックログアイテムの説明を追加・更新する - プロダクトバックログアイテムの並び順を更新する - プロダクトバックログアイテムのサイズを追加・更新する（見積もる） https://www.ryuzee.com/contents/blog/14584
79. 78 リファインメント 06 # 出席者 - PdMチーム、案件担当者 # 通常のリファインメント（隔週開催） - 開発未着手のBacklogチケットに対して、優先順位の整理・調整・メンテ - 優先度が低いと判断したチケットは対象外 - チケットの滞留漏れチェック（PdM・開発チーム両面） # クレンジング会（四半期開催） - 全てのBacklogチケットに対して、優先順位の整理・調整・メンテ
80. 79 リファインメント 06 定期的なリファインメントにより、 - 開発チームが何から着手すれば良いか分かるようにする - 着手時にできるだけすぐ手を動かせるようにする
81. 開発プロセス Copyright © 2024 Ambitious Co., Ltd. All Rights Reserved.
82. 81 - 開発プロセスの改善は、開発チームだけの責務ではない。 - 事業サイド（PdM）からのアプローチも必要。 - 特に、顧客企業と開発会社という関係性のため、 開発チームは改善の提案をし辛い。 - 改善の土壌・文化作りが重要。 前提 07
83. 82 開発生産性指標を測定する 07 # 課題・目的 - 開発プロセスにおける開発生産性を向上したい - 測定しなければ改善できない。 - 手動測定は大変すぎる # 解決策 - FindyTeam+を導入 - FourKeys、その他メトリクスを簡単に測定できる
84. 83 # 経緯 - 本番リリース時、トランクルーム契約導線上の障害が発生 - リリース作業中に気づけず、現場部門からの連絡で気づき、後手に回った - せめてハッピーパスはリリースの流れで確認したい - 障害発生時は即時自動で切り戻したい - リリース時、毎回手動で全て確認するのは大変 - 自動でE2Eテストしたい - ステージング環境で毎日ハッピーパスのテストができると、 安心して開発に集中できる。DX（開発者体験）が向上する。 →2024年8月導入開始。 E2Eテストツールの導入 07
85. 84 CICDの導入 07 # 経緯 - 本番リリース時、トランクルーム契約導線上の障害が発生 - リリース作業中に気づけず、現場部門からの連絡で気づき、後手に回った - せめてハッピーパスはリリースの流れで確認したい - 障害発生時は即時自動で切り戻したい - リリース時、毎回手動で全て確認するのは大変 - 自動でテストし、自動で切り戻したい - リリースにかかる作業を減らし、開発チームの負荷を下げ、より価値に繋 がる活動に注力してもらう →CDパイプラインを構築中（もうすぐ）
86. 85 チケットやリリースの粒度を小さくする 07 1,000line 10file 100line 1file ・どっちがより早く本番デプロイできるか？ ・どっちがより早くアウトカムに繋がるか？ ・どっちが障害が発生し辛いか？
87. 86 チケット内容をある程度詳細化する 07 アンビシャスとの付き合いが短いメンバーが多い ドメイン知識が十分でないメンバーが多い チケット内容をある程度詳細化する 迷いなく実装できる
88. 開発チームより Copyright © 2024 Ambitious Co., Ltd. All Rights Reserved.
89. 88 開発チームより 08
90. 89 - ソースの整備 - リファクタリング工数を（ある程度）許容する - リリースまでの運用手順見直し - 運用ルール・フローの話し合い - リリースミス解消 最初に行った施策 08
91. 90 - 不要なブランチとPRの整理 - PR作成からApproveを2営業日以内を目標に。 - 目標が目的化しないように注意 - レビュー依頼用Slackチャンネル作成 - コードレビューと動作レビューの分離 - 週次ふりかえり - ふりかえり工数を許容（内製なら当然） - PRボリュームを伝える 開発生産性向上の取り組み 08
92. 91 - 内製でも外注でも、大切なことは変わらない - 一方のみの責務ではなく、 対話・話し合いによってより良くしていく - 勿論、締めるとこは締める 事業サイド（発注側）として 08
93. 雰囲気づくり Copyright © 2024 Ambitious Co., Ltd. All Rights Reserved.
94. 93 - 後から内製化したいことを伝えると、信頼を損ないかねない - お互いに信頼し、未来に向かって協力していくことが大切 - 筋を通す 前提：内製化したいことは先に伝える 09 開発会社変更検討時に先に伝えていた
95. 94 - トランクルーム業界の未来、更にその先 - 当事者になり、一緒に作っていくワクワク感 - 「アレ俺」と言えるように ワクワクする未来を共有する 09 内発的動機付けを意識
96. 95 個人の成長にも繋がることを伝える 09 - 開発生産性を上げる努力・取り組みは、 アンビシャスとの取引を離れることになっても、 開発者のスキル・経験として必ず活きる - 離れたとして、 その経験を業界や開発者や顧客の為に活用し、 貢献してほしい（恩送りしてほしい） 内発的動機付けを意識
97. 96 意思決定の背景を伝える 09 意思決定の結果だけ伝える 納得感の低下 一体感の低下 意思決定が似てこない 失敗増・ コミュニケーションコスト増 意思決定の背景・理由も伝える
98. 97 前向きな失敗は歓迎 09 - アンビシャスの文化 - 基本的には、前向きなチャレンジによる失敗は歓迎 - ただし、お金に関わる機能（決済機能）などは、 お客様の信頼を損なってしまう為、NGな領域。
99. 98 「人格者」（≒良い人）になることを目指している 人格者 09
100. 現状の課題と今後 Copyright © 2024 Ambitious Co., Ltd. All Rights Reserved.
101. 100 アンビシャス側が滞留している 10 PdM 要件定義担当 課題の 発見・定義 企画・ 要件定義 開発 テスト デプロイ 運用 新たな 課題 PBL PdM 案件担当 開発チーム PdM 案件担当 検証環境 本番環境 PdM 現場 課題設定 PBI発行 リファインメント 開発・テスト ・レビュー等 デプロイ 検証・レビュー 要件定義 デプロイ 運用 課題抽出 週次 適宜 適宜 適宜 週次MTG 適宜 隔週 適宜 常時 常時
102. 101 - 具体的な対策は固まっていない 1. 人的リソースの追加アサイン・育成 - (超)上流工程の知見のある方の採用 2. ちゃんとアジャイルする - 開発チームで小さく作って、 週次で動く物を見ながら詰めていく。 - 但し、アーキテクチャには注意。 要件定義の滞留 10
103. 102 検証・レビューの滞留 10 - 具体的な対策は固まっていない 1. 人的リソースの追加アサイン・育成 2. ちゃんとアジャイルする - スプリントレビューを設ける ※そもそもスプリント（タイムボックス）に なっていないため、そこから変更必要。 知見が殆どない。 3. 開発チームに委譲する
104. 103 内製化を進める 10 - 内製化をいつ・どう進めるか。 - 内製化したからと言って、 開発会社様との取引を止めるつもりではない。 - 事業をドライブさせることが目的で、内製化は絶対ではない - 手の内化できていない状態はリスク - 開発生産性向上は、内製化した時に移植できる状態を作るこ とも目的の１つ。
105. 最後に Copyright © 2024 Ambitious Co., Ltd. All Rights Reserved.
106. 105 システム開発会社と共に進めてきた 「開発生産性改善」の取り組み事例と今後 についてお話しました。 何かしら参考になることがあれば幸いです。
107. 106 - もうちょっと（もっと）詳しい話を聞いてみたい - ちょっと面白そうやん - 成長業界に飛び込みたい - 一緒に成長したい - 内製化してやるぜ！！ エンジニア募集中 Webアンケートでご連絡下さい https://l.pit-sy.uno/240918devsumi
108. 107 https://l.pit-sy.uno/240918devsumi 有難う御座いました