価値のある機能をユーザに早く届けるための大企業エンジニアの挑戦 / Achieving Faster Delivery of Customer Value Features in a Siloed Organization

024年6月28日に開催された 開発生産性Conference 2024 の講演資料です。 講演詳細についてはこちらをご覧ください。 https://dev-productivity-con.findy-code.io/2024

1. © NTT Communications Corporation All Rights Reserved. 価値のある機能をユーザに早く届けるた めの大企業エンジニアの挑戦
 エヌ・ティ・ティ・コミュニケーションズ株式会社 
 牧志 純
 川瀬 弘嗣

2. © NTT Communications Corporation All Rights Reserved. 2 自己紹介
 川瀬 弘嗣
 NTTコミュニケーションズ株式会社 
 プラットフォームサービス本部 
 クラウド＆ネットワークサービス部 
 2016年NTTコミュニケーションズ入社。
 主にクラウドやネットワークサービスのオーケストレーションを 通じたサービス開発に従事。
 バックエンドの開発を主軸としつつ、サービスの磨き込みのた めのデータ収集や分析、エンジニア育成施策の企画や運用も 担当。

3. © NTT Communications Corporation All Rights Reserved. 3 自己紹介
 牧志 純
 NTTコミュニケーションズ株式会社 
 イノベーションセンター 
 テクノロジー部門
 社内プラットフォームQmonus Value Streamのアーキテクト兼 エンジニアリングマネージャ
 @JunMakishi
4. © NTT Communications Corporation All Rights Reserved. 4 ドコモビジネス と NTT コミュニケーションズ 
 NTT コミュニケーションズはドコモグループの一員として、エンタープライズ向けの ワンストップ ICT ソリューションを提供
 

5. © NTT Communications Corporation All Rights Reserved. 5 docomo business RINK 
 クラウド型セキュリティと一体化した統合型ネットワークサービスでICTのレジリエンスを強化

6. © NTT Communications Corporation All Rights Reserved. 6 大企業でアジャイル開発を始めたが・・・ 
 エリート企業は1日に数回リリースしているらしい 開発エンジニア

7. © NTT Communications Corporation All Rights Reserved. 7 大企業でアジャイル開発を始めたが・・・ 
 エリート企業は1日に数回リリースしているらしい 自分の組織では年4回のリリースが限界だ （すでにアジャイルじゃない気がする） 開発エンジニア

8. © NTT Communications Corporation All Rights Reserved. 8 大企業でアジャイル開発を始めたが・・・ 
 エリート企業は1日に数回リリースしているらしい 企画チームはなかなか仕様を決めてくれな いし、運用チームの判定会議は重いし、自 分たちにできることはない 自分の組織では年4回のリリースが限界だ （すでにアジャイルじゃない気がする） 開発エンジニア

9. © NTT Communications Corporation All Rights Reserved. 9 本発表で伝えたいこと 
 開発工程の中でいくら素早く開発したとしても、開発前後のプロ セスが重い場合、顧客に早く価値を届けることはできない。 プラットフォームサービスのソフトウェア開発 の現場において、 縦割り組織と開発プロセスの制約がある中で、現場のエンジニ アの奮闘でリリース頻度を3倍以上にした取り組みを紹介しま す。 ※ネットワークサービスを制御するAPI/ソフトウェアなど ※
10. © NTT Communications Corporation All Rights Reserved. 10 目次
 1. エンドエンドのバリューストリームを把握する 2. 素早く開発するための企画と開発の越境 3. 開発したものを早くリリースする 4. 組織として素早いリリースを再現する 5. 早くて精度の高い価値提供のために
11. © NTT Communications Corporation All Rights Reserved. 11 目次
 1. エンドエンドのバリューストリームを把握する 2. 素早く開発するための企画と開発の越境 3. 開発したものを早くリリースする 4. 組織として素早いリリースを再現する 5. 早くて精度の高い価値提供のために
12. © NTT Communications Corporation All Rights Reserved. 12 サービス開発が遅いのはシステム開発が遅いから？ 
 自社
 エンジニア
 顧客
 よく
 わからない
 世界
 課題
 価値
 仕様
 開発物
 「もっと開発早くならない の？」って言われることが あるんだけど......おれたち もがんばってるんだけど なあ
 仕様化が遅いことが遅い 原因のように思えるんだ けど、そもそも開発の全 体像がわからないから、 それが根本原因かわか らないな

13. © NTT Communications Corporation All Rights Reserved. 13 バリューストリームマップ 
 サービスがユーザに届くまでの一連のプロセスを視覚的に表現する方法
 各プロセスの担当者、リードタイム（LT）およびプロセスタイム（PT）も記載
 リードタイム(LT) ＝ プロセスタイム(PT) ＋ 待ち時間(WT)
 サービス仕様作成 LT: 5 days PT: 4 days システム仕様作成 LT: 5 days PT: 3 days
14. © NTT Communications Corporation All Rights Reserved.
15. © NTT Communications Corporation All Rights Reserved. 15 大きな組織ほどVSMはうれしい 
 • 価値提供に至るプロセスの全体像がわかる
 → どこにどれだけの伝言ゲームが発生しているのか、誰が何に一番詳しい かがわかる
 • 各プロセスにどれくらい時間がかかっているかわかる
 → 開発フロー全体の中のボトルネックを特定できる
 • 組織を跨った改善策の検討ができる
 

16. © NTT Communications Corporation All Rights Reserved. 16 バリューストリームマップをどう作るか 
 • 「みんなでmiroに非同期に書いていきましょう」は難しい
 • 会ったこともない人が何をやっているか、こそ大切
 • まずはプロダクトマネージャーにアクセスする 
 • 多くのステークホルダーとのつながりがあるはず
 • 地道にヒアリングしていく
 • 「え、そんなことまでやってたんですか！？」という発見がある
 • LTやPTを算出する上で、業務ツールのログは役に立たないことがある
 • 見えていないプロセスの解像度をグッと上げるいい機会と捉える

17. © NTT Communications Corporation All Rights Reserved. 17 VSM分析から、開発の前後でスピードを妨げる壁があることが分かった
 開発フロー 
 ヒアリング コンセプト作 成 仕様化 設計 実装 テスト リリース 企画チーム 開発チーム 運用チーム
18. © NTT Communications Corporation All Rights Reserved. 18 目次
 1. エンドエンドのバリューストリームを把握する 2. 素早く開発するための企画と開発の越境 3. 開発したものを早くリリースする 4. 組織として素早いリリースを再現する 5. 早くて精度の高い価値提供のために
19. © NTT Communications Corporation All Rights Reserved. 19 素早く開発するための企画と開発の越境 
 ヒアリング コンセプト作 成 仕様化 設計 実装 テスト リリース 企画チーム 開発チーム 運用チーム
20. © NTT Communications Corporation All Rights Reserved. 20 企画と開発の分断により生じる課題① 
 開発チームだからこそ気づける仕様の抜け漏れに気づくのが遅れる
 • 仕様の説明を受け、実際に作っ てからやっと仕様の漏れや違和 感に気づき手戻り
 • 提示される仕様の完成度が低 いのでは？
 仕様書第x版まで完成させてから話 を持ってきてください 
 価値提供までの期間 が長期化

21. © NTT Communications Corporation All Rights Reserved. 21 企画と開発の分断により生じる課題② 
 過度に安全側に振った開発期間の見積もりをしてしまう
 • 開発チームの責務は「機能開発 の期限内での完了」
 • 手を動かす前に開発期間の見 積もりを提示する必要あり
 • 見積もりの提示が「この期限内 にやります」という宣言に
 開発が遅れたら自チームの責任が 問われる...。余裕を持ったスケ ジュールを提示するしかない な。
 価値提供までの期間 が長期化

22. © NTT Communications Corporation All Rights Reserved. 22 完璧な「受け渡し」を目指すのをやめ、企画チームをプロダクトオーナーとして迎え、スプ リントごとにレビューをしてもらう形に
 企画メンバーによるレビュー 
 ヒアリング コンセプト作 成 仕様化 設計 実装 テスト リリース 企画チーム 開発チーム 運用チーム スプリントごとにレ ビュー

23. © NTT Communications Corporation All Rights Reserved. 23 企画メンバーによるレビュー 
 良い点 • フィードバックを得る頻度が上がり、早期に手戻りできる • 完璧に仕様を作り込まなくても作り始められる 課題 • 開発チームが仕様やスコープを企画に提案しても、ビジネス観 点を強く持つ企画チームの意向が優先されがち • レビューでの指摘事項がほとんど見た目（UI）のみ 企画メンバーにレビューしてもらうことで受けられる恩恵もあったが、「考える人と 作る人」という構図は変わらない

24. © NTT Communications Corporation All Rights Reserved. 24 企画チームの一員として、ヒアリングから実装/テストまで一貫して担当
 エンジニアが完全に企画に入り込む 
 ヒアリング コンセプト作 成 仕様化 設計 実装 テスト リリース 企画チーム 開発チーム 運用チーム
25. © NTT Communications Corporation All Rights Reserved. 25 エンジニアが完全に企画に入り込む 
 早い段階からループを回し、気づきを得られる
 • 引き渡しの手間なく違和感や抜け漏れを早期に発見できる
 • 仕様とその背景、技術的観点を考慮しながら、現実的なスコープの検討ができ る
 • インタビューやリサーチを通じて獲得したドメイン知識を反映した設計・実装がで きる
 仕様化
 設計・実装
 プロダクトの検証
 ソフトウェアの開発
 ドメイン知識
 (市場環境、業務 プロセス等)
 ヒアリング
 リサーチ

26. © NTT Communications Corporation All Rights Reserved. 26 企画でも活躍するエンジニアを実現するために 
 • 他のチームとの強い繋がりを持つPdMとタッグを組む
 • 他のチームを信頼関係を結びながら牽引していく能力はPdMの方が優れている
 • エンジニアはPdMと積極的にコミュニケーションをとり、あらかじめ信頼関係を構 築しておく
 • 企画に飛び込むこと、それ自体を評価する制度を作る
 • プロダクトの成功失敗だけで評価しない

27. © NTT Communications Corporation All Rights Reserved. 27 目次
 1. エンドエンドのバリューストリームを把握する 2. 素早く開発するための企画と開発の越境 3. 開発したものを早くリリースする 4. 組織として素早いリリースを再現する 5. 早くて精度の高い価値提供のために
28. © NTT Communications Corporation All Rights Reserved. 28 開発と運用の間にある壁が素早いリリースを阻害している
 開発したものがすぐにリリースできない 
 ヒアリング コンセプト作 成 仕様化 設計 実装 テスト リリース 企画チーム 開発チーム 運用チーム
29. © NTT Communications Corporation All Rights Reserved. 29 早いリリースを阻害する壁の実体：　引き渡し 
 開発から運用へ「引き渡す」ことに重きをおいたリスクを小さくするための合理 的なプロセス
 
 • 開発したソフトウェアを運用チームへ「確実に」引き渡す
 • 例：　誰でもできる手順書の用意
 
 • 「失敗なく」リリースするための各種手続き
 • 例：　リリース判定会議、リリース審査会

30. © NTT Communications Corporation All Rights Reserved. 30 リリースの悪循環 
 プロセスが重いので機能・バグ修正を まとめてリリースしよう リリースのスコープが大きくリスクが高 いので入念にチェックしよう 実装した機能がリリースされるまでに数ヶ月かかることも プロセスが重くなる 1つのリリースに含まれ る改修が多くなる
31. © NTT Communications Corporation All Rights Reserved. 31 リリースの実態 
 設計 実装 テスト リリース 開発チーム 運用チーム 設計 実装 設計 実装 判定 会議 手順 引き 継ぎ
32. © NTT Communications Corporation All Rights Reserved. 32 エンジニアの熱意を原動力に立ち上がる 
 縦割り組織において、開発チームは生産量／エンジニア効率で評価されがちの ため、悪循環から抜け出せない。
 が、よく考えるとおかしい。
 作った機能を早く使ってもらいたい 本番環境で動いている数ヶ月前のコードの 保守が難しい リリースの手続きが面倒だ（本音） 現場のエンジニア
33. © NTT Communications Corporation All Rights Reserved. 33 リリース作業の引き渡しを撤廃 
 ステージング デプロイ テスト 本番 デプロイ リリース 判定 会議 正常性 確認 実装 開発チームが熱意を持ってリリース作業を徹底的に自動化
 • 開発チームだけでリリース作業ができる形にする
 開発チーム 運用チーム 自動化
34. © NTT Communications Corporation All Rights Reserved. 34 リリース判定会議の簡素化に向けたチャレンジ 
 判定会議は「失敗させない」仕組みではなく、会社と個人を守る仕組み。過度な ハックや迂回は逆効果のため、正攻法で簡素化の条件を詰める。
 自動化によるリリース実績を元に信頼を獲得し、できるだけ委譲したいと思って もらう。
 トラブルの際に自分たちのせいにするためにも 判定会議はあったほうが良いのでは 信頼しているので、リリースに判定会議が要る・要らない条 件を提案してくれ ステークホルダー
35. © NTT Communications Corporation All Rights Reserved. 35 マネージャーやステークホルダーの支援をうけ、条件をすり合わせていく
 根気強いすり合わせ 
 条件B
 判定会議
 なし
 条件A
 判定会議
 簡易判定会 議
 • 具体的な工程ごとに判定する必要がないことを示す。 • リスクが小さいことを示す。（要実績！） • リリースタイプごとに判定不要な条件を詰める 
 （例）自動化ツールによりリリース手順の検証が毎回できている ためリリース手順検証結果の判定が不要である。 
 （例）Blue Greenデプロイメントを採用しており、トラブル時に素 早く戻すことができる。 
 （例）リリース時にユーザ影響が見込まれる場合は判定会議を 必須とする。

36. © NTT Communications Corporation All Rights Reserved. 36 まとめ：　リリースフロー効率化の取り組み 
 判断が委譲されスピーディにリリースできるようになり、一月に1回以上のペー スでソフトウェアリリースが可能に。
 
 学び
 • エンジニアの熱意をもとにリリース作業の徹底的に自動化する。
 ◦ 実績を積み上げることが重要。
 • 既存プロセスを尊重し、条件をすり合わせ、判定会議を簡素化する。
 ◦ 既存プロセスおよびステークホルダーが持つ観点を理解しているマネージャー のバランスが重要。

37. © NTT Communications Corporation All Rights Reserved. 37 目次
 1. エンドエンドのバリューストリームを把握する 2. 素早く開発するための企画と開発の越境 3. 開発したものを早くリリースする 4. 組織として素早いリリースを再現する 5. 早くて精度の高い価値提供のために
38. © NTT Communications Corporation All Rights Reserved. 38 素早いリリースフローを他チームへ展開する 
 自動化ツールおよび簡素化されたプロセスを活用し、組織内の複数のプロダクト 開発でリリースを早くしたい

39. © NTT Communications Corporation All Rights Reserved. 39 リリースを開発チームが担うことによる課題 
 プロダクト開発に時間が割けないジレンマが発生
 • 自動化ツールの維持に時間が取られる
 • 必ずしも自動化に長けているエンジニアを各チームに配備できない
 • 「自動化」ツールが力のあるエンジニアしか触れない秘伝のタレに
 自動化ツールが複雑になってきたので、 他のエンジニアにメンテしてもらえない またテスト環境へのデプロイメントが失敗した。最近、クラウド基盤と自 動化ツールのデバッグに時間が取られている気がする。
40. © NTT Communications Corporation All Rights Reserved. 40 プラットフォームチームの発足 
 組織のベストプラクティスを社内サービスとして提供するプラットフォームを開 発する
 • 専任メンバで構成
 • 自動化ツールのSaaS化からはじめる
 プラットフォームチーム プロダクト開発者 サービスを利用するだけでアプリケー ションのリリースが自動化できた！ サービス提供
41. © NTT Communications Corporation All Rights Reserved. 41 開発チームに入り込んで丁寧な支援を進めることで、サービスを押し付けること なく導入を推進する
 プロダクトチームのイネーブルメントに力を注ぐ 
 プラットフォーム開発チーム （プラットフォームチーム） ソリューションチーム （イネーブリングチーム） サービス提供 導入サポート トレーニング コンサル *1 書籍「チームトポロジー」で定義されているチームタイプ （マシュー・スケルトン ,マニュエル・パイス,（訳）原田 騎郎,永瀬 美穂,吉羽 龍太郎,「チームトポロジー」 ,日本能率協会マネジメントセンター ,2021） *1 *1 *1 プロダクト開発チーム （ストリームアラインドチーム） 社内プラットフォームチーム
42. © NTT Communications Corporation All Rights Reserved. 42 まとめ：　組織としての早いリリースの再現 
 プラットフォームチーム発足から3年で30以上の開発チームを支援し、組織の リリース高速化に貢献
 
 学び
 • 開発チームのイネーブルメントにコミットする体制を構築する
 ◦ プロダクト開発チームの直面している課題を一つ一つ解決するような手厚い支援 により開発チームの信頼を得る

43. © NTT Communications Corporation All Rights Reserved. 43 組織のDevOpsを強化するために 
 大きな組織では、バリューストリーム全体をみてフローを妨げる ボトルネックを取り除き、それを組織として再現していくことで、 真のDevOpsのケイパビリティが向上する
 開発チームに閉じた 生産性のみを議論する バリューストリーム 全体を見て議論する 顧客
44. © NTT Communications Corporation All Rights Reserved. 44 Qmonus Value Stream 「要件を選ぶだけでクラウドアーキテクチャとCI/CDパイプラインが作れる」 
 統合DevOpsプラットフォームサービス (クモナス バリュー ストリーム) 
 「DevOpsを導入支援して欲しい」 
 「基盤構築を楽にしたい」 
 「基盤担当が採用できない」 
 広告
 ®
 NTTコムのDevOpsスペシャリストが 
 無料でDevOps導入を支援 
 トライアル相談
 CI/CDパイプライン 
 構築ウェビナー

45. © NTT Communications Corporation All Rights Reserved. 45 目次
 1. エンドエンドのバリューストリームを把握する 2. 素早く開発するための企画と開発の越境 3. 開発したものを早くリリースする 4. 組織として素早いリリースを再現する 5. 早くて精度の高い価値提供のために
46. © NTT Communications Corporation All Rights Reserved. 46 組織の壁を越えた結果 
 組織の壁を越え、素早い価値提供が実現できたかと言うと、できなかった 
 企画と開発の壁を越える
 ドメイン知識を反映した変 更容易性の高い設計
 理想：素早い価値提供
 プラットフォームの開発を 通じた高速なリリース
 開発と運用の壁を越える
 現実：それでも早く提供できない... 

47. © NTT Communications Corporation All Rights Reserved. 47 なにが起きているのか？ 
 市場の反応が大前提を崩壊させ、大規模な作り直しを求めることがある
 （例）マネージドなクラウドリソースパッケージのマーケットプレイスを パッケージの種別を簡単に拡張できるように作りリリースした。 パッケージは売れず、マーケットプレイスは廃止されることになった が、その部品であるクラウドリソース構築機能単体がほしいという ユーザが見つかった。 しかし構築機能のみの利用を想定しておらず、大幅な作り直しが必 要になった。

48. © NTT Communications Corporation All Rights Reserved. 48 市場の不確実性への向き合い方 
 前提を崩壊させる市場の不確実性に対して、2つのアプローチがある
 
 1. 仮説の精度を高める
 2. 前提の崩壊に素早く適応できる開発力をつける
 
 エンジニアでもこれら2つのアプローチどちらにも取り組んでいけるのではないか

49. © NTT Communications Corporation All Rights Reserved. 49 仮説の精度を高めるために企画に渡る 
 これまでの企画に渡る意義
 • 仕様の明確化
 • 見積もりの精度向上
 • ソフトウェアの内部品質の向上
 これから狙う意義
 • プロダクトを売っていくための新 たな仮説を見つける。
 仕様化
 設計・実装
 プロダクトの検証
 ソフトウェアの開発
 ドメイン知識
 (市場環境、業務 プロセス等)
 新たな仮説
 ヒアリング
 リサーチ

50. © NTT Communications Corporation All Rights Reserved. 50 現状の取り組み：仮説に気づくためのアイデア 
 • Architecture Decision Recordを着想のきっかけにできないか？
 • このアーキテクチャ決定により、どんな可能性を捨てているか
 • 捨てる可能性を仮に採用した場合、どのようなユーザが喜ぶか
 → 本当にそのユーザが存在しないのかの仮説検証を提案できる
 例：典型的なクラウドリソースの組み合わせを構築・運用・削除を 行うサービスを提供するシステムは、クラウドリソース群の構築機 能を内包することとする • リソース構築機能のみ利用される可能性を捨てている • 構築機能単体でもインフラ構築支援チームは嬉しいかも • 本当にそんなユーザがいるかどうか検証しよう！
51. © NTT Communications Corporation All Rights Reserved. 51 前提の崩壊に素早く適応できる開発力をつける 
 壁を越えて開発チームの担当範囲が増えたことで、開発チームの開発生産性を向上させ なければ手が回らないが、個人の開発体験も損ねたく無い
 PRがOpenされてから30分以内 にReviewすることを目標にしま しょう！ 素早いReviewが大事なのはわか るけど、割り込みが増えるのもキ ツいんだよな......
52. © NTT Communications Corporation All Rights Reserved. 52 現在の取り組み：継続性のある生産性改善の実践 
 改善策を押し付けず、個人/チーム/プロジェクトの状況に合わせた改善策を チーム全体で決めることで、継続性を持たせる
 例
 • Review着手が遅く、チームとしては開発を進 めづらくなっている
 • 各メンバーは開発時間帯が異なり、割り込み なく集中できる時間も大切にしたい 
 • プロジェクトは切迫していない
 始業後30分、および終業前1時間 をreviewの時間とする 測定
 振り返り
 開発

53. © NTT Communications Corporation All Rights Reserved. 53 • 組織の壁を越えても早く世にプロダクトを出せるとは限らない
 • 市場の反応が前提を崩壊させる
 
 • 現場のエンジニアが市場の不確実性に向き合う二つのアイデア
 • 仮説の精度をあげるためのADRの活用
 • 前提が崩れても早く立ち直るための継続性のある開発生産性改善
 
 まとめ：早くて精度の高い価値提供を目指す 

54. © NTT Communications Corporation All Rights Reserved. 54 おわりに
 顧客に価値を早く届けるためには、バリューストリームを可視 化し、組織の壁・制度の壁を越えていく必要があり、それは現 場のひとりのエンジニアから始めることができる 組織や制度の壁を越えても、市場の不確実性が素早い価値提 供を阻む。仮説の精度やチームの開発生産性を高め、不確実 性と闘っていく
55. © NTT Communications Corporation All Rights Reserved. 55