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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© NTT Communications Corporation All Rights Reserved. 9 本発表で伝えたいこと   開発工程の中でいくら素早く開発したとしても、開発前後のプロセスが重い場合、顧客に早く価値を届けることはできない。プラットフォームサービスのソフトウェア開発の現場において、縦割り組織と開発プロセスの制約がある中で、現場のエンジニアの奮闘でリリース頻度を3倍以上にした取り組みを紹介します。 ※ネットワークサービスを制御するAPI/ソフトウェアなど ※

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© NTT Communications Corporation All Rights Reserved. 12 サービス開発が遅いのはシステム開発が遅いから？   自社  エンジニア  顧客  よく  わからない  世界  課題  価値  仕様  開発物  「もっと開発早くならないの？」って言われることがあるんだけど......おれたちもがんばってるんだけどなあ  仕様化が遅いことが遅い原因のように思えるんだけど、そもそも開発の全体像がわからないから、それが根本原因かわからないな 

Slide 13

Slide 13 text

© NTT Communications Corporation All Rights Reserved. 13 バリューストリームマップ   サービスがユーザに届くまでの一連のプロセスを視覚的に表現する方法  各プロセスの担当者、リードタイム（LT）およびプロセスタイム（PT）も記載  リードタイム(LT) ＝プロセスタイム(PT) ＋待ち時間(WT)  サービス仕様作成 LT: 5 days PT: 4 days システム仕様作成 LT: 5 days PT: 3 days

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© NTT Communications Corporation All Rights Reserved. 15 大きな組織ほどVSMはうれしい   • 価値提供に至るプロセスの全体像がわかる  → どこにどれだけの伝言ゲームが発生しているのか、誰が何に一番詳しいかがわかる  • 各プロセスにどれくらい時間がかかっているかわかる  → 開発フロー全体の中のボトルネックを特定できる  • 組織を跨った改善策の検討ができる   

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© NTT Communications Corporation All Rights Reserved. 20 企画と開発の分断により生じる課題①   開発チームだからこそ気づける仕様の抜け漏れに気づくのが遅れる  ● 仕様の説明を受け、実際に作ってからやっと仕様の漏れや違和感に気づき手戻り  ● 提示される仕様の完成度が低いのでは？  仕様書第x版まで完成させてから話を持ってきてください   価値提供までの期間が長期化 

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© NTT Communications Corporation All Rights Reserved. 29 早いリリースを阻害する壁の実体：　引き渡し   開発から運用へ「引き渡す」ことに重きをおいたリスクを小さくするための合理的なプロセス    • 開発したソフトウェアを運用チームへ「確実に」引き渡す  • 例：　誰でもできる手順書の用意    • 「失敗なく」リリースするための各種手続き  • 例：　リリース判定会議、リリース審査会 

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© NTT Communications Corporation All Rights Reserved. 32 エンジニアの熱意を原動力に立ち上がる   縦割り組織において、開発チームは生産量／エンジニア効率で評価されがちのため、悪循環から抜け出せない。  が、よく考えるとおかしい。  作った機能を早く使ってもらいたい本番環境で動いている数ヶ月前のコードの保守が難しいリリースの手続きが面倒だ（本音）現場のエンジニア

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© NTT Communications Corporation All Rights Reserved. 34 リリース判定会議の簡素化に向けたチャレンジ   判定会議は「失敗させない」仕組みではなく、会社と個人を守る仕組み。過度なハックや迂回は逆効果のため、正攻法で簡素化の条件を詰める。  自動化によるリリース実績を元に信頼を獲得し、できるだけ委譲したいと思ってもらう。  トラブルの際に自分たちのせいにするためにも判定会議はあったほうが良いのでは信頼しているので、リリースに判定会議が要る・要らない条件を提案してくれステークホルダー

Slide 35

Slide 35 text

© NTT Communications Corporation All Rights Reserved. 35 マネージャーやステークホルダーの支援をうけ、条件をすり合わせていく  根気強いすり合わせ   条件B  判定会議  なし  条件A  判定会議  簡易判定会議  ● 具体的な工程ごとに判定する必要がないことを示す。 ● リスクが小さいことを示す。（要実績！） ● リリースタイプごとに判定不要な条件を詰める   （例）自動化ツールによりリリース手順の検証が毎回できているためリリース手順検証結果の判定が不要である。   （例）Blue Greenデプロイメントを採用しており、トラブル時に素早く戻すことができる。   （例）リリース時にユーザ影響が見込まれる場合は判定会議を必須とする。 

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© NTT Communications Corporation All Rights Reserved. 39 リリースを開発チームが担うことによる課題   プロダクト開発に時間が割けないジレンマが発生  ● 自動化ツールの維持に時間が取られる  ● 必ずしも自動化に長けているエンジニアを各チームに配備できない  ● 「自動化」ツールが力のあるエンジニアしか触れない秘伝のタレに  自動化ツールが複雑になってきたので、他のエンジニアにメンテしてもらえないまたテスト環境へのデプロイメントが失敗した。最近、クラウド基盤と自動化ツールのデバッグに時間が取られている気がする。

Slide 40

Slide 40 text

© NTT Communications Corporation All Rights Reserved. 40 プラットフォームチームの発足   組織のベストプラクティスを社内サービスとして提供するプラットフォームを開発する  ● 専任メンバで構成  ● 自動化ツールのSaaS化からはじめる  プラットフォームチームプロダクト開発者サービスを利用するだけでアプリケーションのリリースが自動化できた！サービス提供

Slide 41

Slide 41 text

© NTT Communications Corporation All Rights Reserved. 41 開発チームに入り込んで丁寧な支援を進めることで、サービスを押し付けることなく導入を推進する  プロダクトチームのイネーブルメントに力を注ぐ   プラットフォーム開発チーム（プラットフォームチーム）ソリューションチーム（イネーブリングチーム）サービス提供導入サポートトレーニングコンサル *1 書籍「チームトポロジー」で定義されているチームタイプ（マシュー・スケルトン ,マニュエル・パイス,（訳）原田騎郎,永瀬美穂,吉羽龍太郎,「チームトポロジー」 ,日本能率協会マネジメントセンター ,2021） *1 *1 *1 プロダクト開発チーム（ストリームアラインドチーム）社内プラットフォームチーム

Slide 42

Slide 42 text

© NTT Communications Corporation All Rights Reserved. 42 まとめ：　組織としての早いリリースの再現   プラットフォームチーム発足から3年で30以上の開発チームを支援し、組織のリリース高速化に貢献    学び  ● 開発チームのイネーブルメントにコミットする体制を構築する  ○ プロダクト開発チームの直面している課題を一つ一つ解決するような手厚い支援により開発チームの信頼を得る 

Slide 43

Slide 43 text

Slide 44

Slide 44 text

© NTT Communications Corporation All Rights Reserved. 44 Qmonus Value Stream 「要件を選ぶだけでクラウドアーキテクチャとCI/CDパイプラインが作れる」   統合DevOpsプラットフォームサービス (クモナスバリューストリーム)   「DevOpsを導入支援して欲しい」   「基盤構築を楽にしたい」   「基盤担当が採用できない」   広告  ®  NTTコムのDevOpsスペシャリストが   無料でDevOps導入を支援   トライアル相談  CI/CDパイプライン   構築ウェビナー 

Slide 45

Slide 45 text

Slide 46

Slide 46 text

© NTT Communications Corporation All Rights Reserved. 46 組織の壁を越えた結果   組織の壁を越え、素早い価値提供が実現できたかと言うと、できなかった   企画と開発の壁を越える  ドメイン知識を反映した変更容易性の高い設計  理想：素早い価値提供  プラットフォームの開発を通じた高速なリリース  開発と運用の壁を越える  現実：それでも早く提供できない...  

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

© NTT Communications Corporation All Rights Reserved. 50 現状の取り組み：仮説に気づくためのアイデア   • Architecture Decision Recordを着想のきっかけにできないか？  • このアーキテクチャ決定により、どんな可能性を捨てているか  • 捨てる可能性を仮に採用した場合、どのようなユーザが喜ぶか  → 本当にそのユーザが存在しないのかの仮説検証を提案できる  例：典型的なクラウドリソースの組み合わせを構築・運用・削除を行うサービスを提供するシステムは、クラウドリソース群の構築機能を内包することとする ● リソース構築機能のみ利用される可能性を捨てている ● 構築機能単体でもインフラ構築支援チームは嬉しいかも ● 本当にそんなユーザがいるかどうか検証しよう！

Slide 51

Slide 51 text

© NTT Communications Corporation All Rights Reserved. 51 前提の崩壊に素早く適応できる開発力をつける   壁を越えて開発チームの担当範囲が増えたことで、開発チームの開発生産性を向上させなければ手が回らないが、個人の開発体験も損ねたく無い  PRがOpenされてから30分以内にReviewすることを目標にしましょう！素早いReviewが大事なのはわかるけど、割り込みが増えるのもキツいんだよな......

Slide 52

Slide 52 text

© NTT Communications Corporation All Rights Reserved. 52 現在の取り組み：継続性のある生産性改善の実践   改善策を押し付けず、個人/チーム/プロジェクトの状況に合わせた改善策をチーム全体で決めることで、継続性を持たせる  例  • Review着手が遅く、チームとしては開発を進めづらくなっている  • 各メンバーは開発時間帯が異なり、割り込みなく集中できる時間も大切にしたい   • プロジェクトは切迫していない  始業後30分、および終業前1時間をreviewの時間とする測定  振り返り  開発 

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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