歴史ある会社・組織で、VUCA時代に対応できるプロダクト作りをするための課題と対応方法とは / Building products for the VUCA era in a long-lasting company

エンタープライズアジャイル勉強会 2020年10月に発表資料です。

Ref:
https://easg.smartcore.jp/C22/notice_details/QVdCVVkxWnM

Transcript

1. 歴史ある会社・組織で、VUCA時代に対応できるプロ ダクト作りをするための課題と対応方法とは / Building products for the VUCA era in a long-lasting company
 
 
 NTT Communications 岩瀬 / @iwashi86
 エンタープライズアジャイル勉強会 (2020/10)
2. 免責
 • 本日の講演は個人の見解であり、 所属する組織の公式見解ではありません • 宣伝(CM)が少しだけ挟まります 

3. 定義
 • 「VUCA時代に対応できるプロダクト」とは
 ◦ お客様がハッピーになり
 ◦ 自社にも利益があがり
 ◦ 従業員が楽しく働いて作れるプロダクト のこと
4. 今日お話すること

5. 扱うトピック
 • 何が課題・原因だったのか、 どのように解決していったのか • エンタープライズな企業にて 課題解決に向けてどのような取組みを起こしているか？ （上記を私自身のストーリーにて）
6. 扱うトピック
 • 何が課題・原因だったのか、 どのように解決していったのか • エンタープライズな企業にて 課題解決に向けてどのような取組みを起こしているか？ （上記を私自身のストーリーにて）
7. どれに当てはまりますか？
 
 どの壁が立ちはだかっていますか？

8. 大企業におけるアジャイル開発の壁
 • 組織文化 ◦ 精度高い計画の要求 ◦ 頻度の多いレポーティング ◦ 失敗を許容しない （口では「許容」と言っても、空気やプロセスがそれを許さない）
9. 大企業におけるアジャイル開発の壁
 • 組織文化 ◦ 精度高い計画の要求 ◦ 頻度の多いレポーティング ◦ 失敗を許容しない （口では「許容」と言っても、空気やプロセスがそれを許さない） • プロセス ◦ 重厚な意思決定 ▪ e.g. 全リリース毎に会議を通す必要性
10. 大企業におけるアジャイル開発の壁
 • 組織文化 ◦ 精度高い計画の要求 ◦ 頻度の多いレポーティング ◦ 失敗を許容しない （口では「許容」と言っても、空気やプロセスがそれを許さない） • プロセス ◦ 重厚な意思決定 ▪ e.g. 全リリース毎に会議を通す必要性 • リソース ◦ アジャイル開発のおける内製Devメンバが不足 ▪ e.g. エンジニアといっても、プロマネ系が多い
11. いやいや、うちにアジャイルチームあるよ！

12. アジャイルチーム拡大の壁
 ・・・ ・・・ あるチームで、 誰かのリーダーシップ + フォロワーシップにより アジャイル開発が始まる！
13. アジャイルチーム拡大の壁
 異動 ・・・ ・・・ 組織的な定期人事異動で、一部のメンバが別チームへ異動
14. 理想的には！
 異動 ・・・ ・・・ アジャイルなマインドセットや文化が拡大していく
15. 現実には
 ・・・ ・・・ 異動先では、これまで作り上げてきた開発運用プロセスから、 かつ人数の違いからアジャイル開発は実施せず （強烈なリーダーシップがあれば別）
16. アジャイルチーム拡大の壁
 チーム解散 ・・・ ・・・ やがて何らかの要因で、アジャイル開発していた プロダクトがサービス終了となり、チーム解散へ
17. アジャイルチーム拡大の壁
 ・・・ ・・・ チーム解散後は、別々のチームへそれぞれ異動。 その結果、さきほど同じプロセスでアジャイル開発が消滅。
18. 続：アジャイルチーム拡大の壁
 ・・・ ・・・ ・大きな会社・組織ともなると、 　複数のアジャイルチームが徐々に発生している
19. 続：アジャイルチーム拡大の壁
 ・・・ ・・・ ・大きな会社・組織ともなると、 　複数のアジャイルチームが徐々に発生している ・ただし、全体としてはマイノリティな状態であり、 　結果的にWaterfall / 外注的なプロセスが多く残る状態 　※これでも上手くやっている例もある
20. (CM) RSGT 2021にて!
21. 続：アジャイルチーム拡大の壁
 ・・・ ・・・ ・大きな会社・組織ともなると、 　複数のアジャイルチームが徐々に発生している ・ただし、全体としてはマイノリティな状態であり、 　結果的にWaterfall / 外注的なプロセスが多く残る状態 　⇒　これが環境に歪みを発生させる
22. 続：アジャイルチーム拡大の壁
 ・・・ ・・・ ・大きな会社・組織ともなると、 　複数のアジャイルチームが徐々に発生している ・ただし、全体としてはマイノリティな状態であり、 　結果的にWaterfall / 外注的なプロセスが多く残る状態 　⇒　これが環境に歪みを発生させる　⇒　何が起こるか？
23. 続々：アジャイルチーム拡大の壁
 ・・・ ・・・ ・内発的動機を強烈に損なう ・その結果、優秀なソフトウェアエンジニアが 　社外へ転職していく
24. 再掲：大企業におけるアジャイル開発の壁
 • 組織文化 ◦ 精度高い計画の要求 ◦ 頻度の多いレポーティング ◦ 失敗を許容しない （口では「許容」と言っても、空気やプロセスがそれを許さない） • プロセス ◦ 重厚な意思決定 ▪ e.g. 全リリース毎に会議を通す必要性 • リソース ◦ アジャイル開発のおける内製Devメンバが不足 ▪ e.g. エンジニアといっても、プロマネ系が多い
25. https://unsplash.com/photos/BW0vK-FA3eg シンプルな因果ではない
26. 「会社を良くする特効薬はない。 　もしあったら良い会社ばかりになるはずだ。」 BMW元会長 エバーハート・フォン・クーンハイム
27. それって誰の仕事なの？
 
 私はエンジニアなので開発を…

28. Scrum Master Product Owner Dev スクラムの3ロール

29. スクラムマスターは自己組織化したチームを 構築し、企業のあらゆる階層で基本原則として自 己組織化が行われる努力します。 スクラムマスターはアジャイルコーチ やエンタープライズコーチとして働き、 組織全体を改善します。
30. 経営陣を含めたマネージャーたちには、 環境を上手く整えていく義務がある。 そうすれば、管理部門や財務、 セールス、マーケティング、デプロイ、 保守などの各部門との間の 社内調整を進められるようになる。 マネージャーは全体を見据え、 全体をアジャイルの原則に あわせていかなければならない。
31. https://unsplash.com/photos/14AOIsSRsPs ゴールはだいぶ遠い それでもやっていくぞというお話
32. 本講演後の皆様の想定状態（ゴール）
 • 具体的に取り組んできたプラクティスやアイデアを知り 試してみようという気になっている • 試すための勇気・モチベーションが少しでも上がっている
33. • 岩瀬 義昌 (@iwashi86) • NTT Communications HR部 人材開発や組織開発、 たまにソフトウェアエンジニア • Podcaster
34. 扱うトピック
 • 何が課題・原因だったのか、 どのように解決していったのか • エンタープライズな企業にて 課題解決に向けてどのような取組みを起こしているか？ （上記を私自身のストーリーにて）
35. タフな問い

37. ・自分はなぜここにいるのか？ ・私たちは何をする者たちなのか？ ・そのために何を大事にするのか？
38. あなたは（今の企業で） 何を成し遂げる人ですか？
39. 振り返ってみると
 • NTT東日本に就職 (2009) ◦ 回答はなかった ▪ ESに書く志望理由は浅い ▪ なんとなくNWに関わる開発をして 健康に暮らしたい気持ち • 本配属後 (2010~) ◦ 大規模なシステム開発に携わる ▪ VoIPやPSTN
40. 当時の愛読書(1987年刊行など)
41. 当時の愛読書(1987年刊行など)
42. 同じタイムラインを流れる別の世界線

43. 当時、憧れたキーワード Chef / Immutable Infra / Docker
44. Developers Summit (2013)
45. https://slide.meguro.ryuzee.com/slides/50
46. ちょうど30歳ぐらい
 • 社会人としてのキャリアはまだ長い ◦ 今の自分のスキル・知識 ▪ PSTNやVoIP極振り
47. ちょうど30歳ぐらい
 • 社会人としてのキャリアはまだ長い ◦ 今の自分のスキル・知識 ▪ PSTNやVoIP極振り • 今の会社でのキャリアの先が見えてくる ∵ 先輩方の異動で、どういうPathがあるかわかる • 一方で、ITを追っているとなんとなく勢いもわかる
48. 少なくとも ソフトウェアエンジニアリングが軸にある
49. このままで良いのかな？
 • Passive ◦ やりたいことを伝え、定期異動を待つ ⇒ ガチャに負けたときのリスク
50. このままで良いのかな？
 • Passive ◦ やりたいことを伝え、定期異動を待つ ⇒ ガチャに負けたときのリスク • Active ◦ 社内で異動先を探す ⇒ ざっと見て、要望にあうポジションは無かった ◦ グループ全体で異動先を探して応募（公募制度有り） ⇒ 良さそうなところがあった ◦ 転職する ⇒ ちょうど良い話もあった
51. このままで良いのかな？
 • Passive ◦ やりたいことを伝え、定期異動を待つ ⇒ ガチャに負けたときのリスク • Active ◦ 社内で異動先を探す ⇒ ざっと見て、要望にあうポジションは無かった ◦ グループ全体で異動先を探して応募（公募制度有り） ⇒ 良さそうなところがあった ◦ 転職する ⇒ ちょうど良い話もあった
52. (CM) その異動先の上司に出演してもらってます https://fukabori.fm/episode/10
53. その後、ソフトウェアエンジニア業を色々と経験
 • インフラ・自動化 ◦ Chef/Ansible/Docker/Terraform ◦ CI/CD w/ JenkinsやCircleCI ◦ 各種クラウド(AWS/GCP/Azure/ECL 2.0) • App ◦ DB ◦ サーバサイド(PHP/Golang/Node) ◦ フロントエンド • チーム開発 ◦ スクラム ◦ TechLead
54. その過程でいっぱい発表した
 https://www.slideshare.net/iwashi86/
55. その過程でいっぱい発表した
 https://www.slideshare.net/iwashi86/ FacebookなどでShareされて 社外発表が社員に流れる ⇒ 信頼貯金が貯まる (後から効いてくる)
56. 当初R&Dだったプロダクトの出口が見えてきた
 • （一般に）大企業でのR&Dからの商用化は大変 ◦ イノベーションのジレンマにハマりやすい
57. 当初R&Dだったプロダクトの出口が見えてきた
 • （一般に）大企業でのR&Dからの商用化は大変 ◦ イノベーションのジレンマにハマりやすい • でも結果的に商用化できた ◦ （数字は出せないが順調） ◦ しかもメンバがすごい優秀 ▪ Tech Leadである必要がなくなった
58. これらの経験から
 • システム開発は楽しい！ ◦ 内製するのは特に楽しい ◦ バグが出ても、瑕疵でごまかせないので自分事感MAX
59. これらの経験から
 • システム開発は楽しい！ ◦ 内製するのは特に楽しい ◦ バグが出ても、瑕疵でごまかせないので自分事感MAX • チーム開発が上手くいくのは楽しい！
60. これらの経験から
 • システム開発は楽しい！ ◦ 内製するのは特に楽しい ◦ バグが出ても、瑕疵でごまかせないので自分事感MAX • チーム開発が上手くいくのは楽しい！ • こういうチームやプロダクトが増えると さらに楽しいはず！ ◦ （当然アジャイルな働き方も）
61. だからボトムアップで
 身近なところから動き始めた

62. 全社の内製チームをつなげる勉強会 • 物理＋論理(Slackコミュニティ) 勉強会写真（削除）
63. 全社から参加できるTDD勉強会 by twadaさん 勉強会写真（削除）
64. エンプラ系大企業でソフトウェアエンジニアリング文化を開花させるために https://www.slideshare.net/iwashi86/ss-203448193
65. なぜ横でつなげるのか？

66. いい仕事をする力のある ミドル・マネジャーやトップなら、 組織図と両立するけれども、 それとは別個の自前のネットワークを 会社のなかに（当然、社外や会社にも）作り 出している。 そして、後者のほうが組織図よりも よほど組織と呼ぶにふさわしい ということもありうる。
67. この辺りでの気付き
 • 社内には決して大多数ではないが ソフトウェアエンジニアは存在しているし、 面白い取組も多くある
68. https://speakerdeck.com/georgeorge/isp-challenges-serverless?slide=29　（初期アーキテクチャであり、現構成ではない）
69. 続：この辺りでの気付き
 • 社内には決して大多数ではないが ソフトウェアエンジニアは存在しているし、 面白い取組もしている • 意外と社内で色々な行動ができる ◦ 役職の高い方々も、その行動を見てくれている （ふとしたときに、言われることがある）
70. あなたは（今の企業で） 何を成し遂げる人ですか？
71. 目的の遷移
 • もともとの目的は曖昧だった
72. 目的の遷移
 • もともとの目的は曖昧だった • 働いていく上で、IT企業の構造課題や システム開発やSWエンジニアリングの楽しさへの気付き
73. 目的の遷移
 • もともとの目的は曖昧だった • 働いていく上で、IT企業の構造課題や システム開発やSWエンジニアリングの楽しさへの気付き • NTT Comが変わることのインパクト ◦ 実際にいただいた声 ▪ 「Nコムさんがやってたので」 ▪ 「真似したい」
74. 目的の遷移
 • もともとの目的は曖昧だった • 働いていく上で、IT企業の構造課題や システム開発やSWエンジニアリングの楽しさへの気付き • NTT Comが変わることのインパクト ◦ 実際にいただいた声 ▪ 「Nコムさんがやってたので」 ▪ 「真似したい」 日本のエンジニアがもっと楽しく働けるのでは？ また、エンタープライズエンジニア人口は多い ここに人生を投資するのは悪くなさそう
75. スコープを広げて 行動し始める
76. https://unsplash.com/photos/14AOIsSRsPs 現状認識（まだこの辺）
77. まだまだ…　道のりは長い
 • ボトムアップだけでは限界がある ◦ 幹部を巻きこんでトップダウンを併用したい
78. まだまだ…　道のりは長い
 • ボトムアップだけでは限界がある ◦ 幹部を巻きこんでトップダウンを併用したい • 最終的には個人マインドセットや組織文化に変化を ◦ ただし、全員が100%変わる必要もない ▪ 企業ミッションとして 失敗しちゃいけない分野も多い （そもそも通信の会社） ▪ 働き方や開発方法が混在しても良い
79. 力を発揮しやすい 場所はどこか？
80. 本格的にポジション変更
 • もともとは事業部のソフトウェアエンジニア ◦ 当初は片手間に、研修企画・実施など ◦ 徐々に割合が変わっていった
81. 本格的にポジション変更
 • もともとは事業部のソフトウェアエンジニア ◦ 当初は片手間に、研修企画・実施など ◦ 徐々に割合が変わっていった • 全社によりインパクトを出しやすい場所は？ ◦ より組織・文化づくりしやすい場所は？
82. 本格的にポジション変更
 • もともとは事業部のソフトウェアエンジニア ◦ 当初は片手間に、研修企画・実施など ◦ 徐々に割合が変わっていった • 全社によりインパクトを出しやすい場所は？ ◦ より組織・文化づくりしやすい場所は？ • 自ら上長と交渉 　⇒ Human Resource(人事)へ異動 (2020.4より)
83. エレベーターピッチならぬ懇親会ピッチ
 • 参考：いわゆるエレベーターピッチ ◦ エレベーターにのっている数十秒でプレゼン （一定の信頼があったほうが成功しやすい）
84. エレベーターピッチならぬ懇親会ピッチ
 • 参考：いわゆるエレベーターピッチ ◦ エレベーターにのっている数十秒でプレゼン （一定の信頼があったほうが成功しやすい） • 懇親会ピッチ ◦ 何らかのイベント事後に飛び込んで話すこと ◦ 幹部も合間合間で話せるタイミングがある ◦ そのときに、自分が持っている課題を当てる ▪ 「詳細は別途お時間をください」⇒ 秘書へ連絡
85. 頭越しコミュニケーション
 • 許可をとるな、謝罪せよ　に近い （必須ではない。信頼関係に依存） 自分 上長 上長の上長 上長の上長の上長
86. ただ、これでまだまだ…　道のりが長い
 • 私が言っても効果が弱い (信頼貯金があったとしても、まだまだ） • 一定の権威付けをして、 私が伝えたいことを代弁してくれる存在
87. 技術顧問に代弁してもらう https://www.ntt.com/shines/posts/b-t_20200625.html
88. ランチ勉強会はいいぞ
 • 幹部は「非常」に忙しい • ただし、ランチ含みのセミナー（勉強会）であれば 都合をつけていただけることもあり 比較的、参加率が高い！
89. (CM) 実施した内容や質疑を公開中 https://www.ntt.com/shines/posts/b-t_20200828a.html
90. 何を伝えてもらったか？
 • 及川さん ◦ 現代のプロダクトマネジメント ◦ 実装軽視コア技術の内製化（手の内化） ◦ プラットフォーム戦略の失敗
91. 何を伝えてもらったか？
 • 及川さん ◦ 現代のプロダクトマネジメント ◦ 実装軽視コア技術の内製化（手の内化） ◦ プラットフォーム戦略の失敗 • 吉羽さん ◦ Why アジャイル ◦ 品質の考え方 ◦ 機能しているチームを壊さないこと、内製化
92. 何を伝えてもらったか？
 • 及川さん ◦ 現代のプロダクトマネジメント ◦ 実装軽視コア技術の内製化（手の内化） ◦ プラットフォーム戦略の失敗 • 吉羽さん ◦ Why アジャイル ◦ 品質の考え方 ◦ 機能しているチームを壊さないこと、内製化 • 和田さん ◦ MTTR vs MTBF ◦ 質とスピード ◦ 内製化（ローパフォマーは外注しがち）
93. 何を伝えてもらったか？
 • 及川さん ◦ 現代のプロダクトマネジメント ◦ 実装軽視コア技術の内製化（手の内化） ◦ プラットフォーム戦略の失敗 • 吉羽さん ◦ Why アジャイル ◦ 品質の考え方 ◦ 機能しているチームを壊さないこと、内製化 • 和田さん ◦ MTTR vs MTBF ◦ 質とスピード ◦ 内製化（ローパフォマーは外注しがち） 意図的にキーワードとして出してもらう
94. 補足）別に内製化のみが最適解ではない
 • 内製化が必要ない領域も多くある • 内製化しても課題は多い（歴史から） https://comemo.nikkei.com/n/n360cc11aadea
95. 一方で内製しなさすぎ問題もある
 • 歴史的経緯から外注メインにした会社は多い • 結果、起こる内製人材が希少問題 ◦ また、シニアエンジニアがいない問題 • だから内製化の重要性を強すぎるぐらいに 一度伝えてもらっている
96. 再掲：大企業におけるアジャイル開発の壁
 • 組織文化 ◦ 精度高い計画の要求 ◦ 頻度の多いレポーティング ◦ 失敗を許容しない （口では「許容」と言っても、空気やプロセスがそれを許さない） • プロセス ◦ 重厚な意思決定 ▪ e.g. 全リリース毎に会議を通す必要性 • リソース ◦ アジャイル開発のおける内製Devメンバが不足 ▪ e.g. エンジニアといっても、プロマネ系が多い
97. twada塾 開講 • 狙い ◦ 今後、NTTコムで必要となるソフトウェア内製開発スキルを習得する ◦ PoCで好評であった場合に向け、スケーラブルな実装について学ぶ • 到達目標 ◦ PoCレベルであれば、一人で短期間で高速開発できるレベルになる • プログラム概要 ◦ 社内システムを題材として、 サーバーサイド・フロントエンド・インフラまで一人で開発・運用する ◦ 技術顧問の和田氏を中心とした講義、定期的な1on1により 独学では難しいソフトウェア開発スキルを習得
98. 何を伝えてもらったか？
 • 及川さん ◦ 現代のプロダクトマネジメント ◦ 実装軽視コア技術の内製化（手の内化） ◦ プラットフォーム戦略の失敗 • 吉羽さん ◦ Why アジャイル ◦ 品質の考え方 ◦ 機能しているチームを壊さないこと、内製化 • 和田さん ◦ MTTF vs MTBF ◦ 質とスピード ◦ 内製化（ローパフォマーは外注しがち）
99. https://www.ryuzee.com/contents/blog/13147
100. 道中、予期せぬ出来事もあった
 • COVID-19の出現
101. 道中、予期せぬ出来事もあった
 • COVID-19の出現 • 一方でチャンスでもある ＝変化が起こるタイミングは 　新しいアイデアをインストールしやすい ⇒ 2020/5上に内部勉強会
102. https://www.slideshare.net/iwashi86/ss-233430281
103. リモートワーク × アジャイル.
 • リモートワーク慣れしていたので 働き方のコツをまとめて伝えた
104. リモートワーク × アジャイル.
 • リモートワーク慣れしていたので 働き方のコツをまとめて伝えた • リモート下にて、アジャイルな行動や考えを 応用できる箇所は多い（HRでも当然） • e.g. 透明性 ◦ リモートではチームメンバの動きが 見えにくい ◦ だから、オンラインカンバンで可視化 ◦ タイムボックスを区切りアップデートする
106. https://www.ntt.com/business/go-event.html S-11　ニューノーマル時代におけるリモートワークネイティブな働き方とは～多様性を尊重したエンゲージメント向上をめざして～
107. https://www.ntt.com/business/go-event.html S-11　ニューノーマル時代におけるリモートワークネイティブな働き方とは～多様性を尊重したエンゲージメント向上をめざして～
108. https://www.ntt.com/business/go-event.html S-11　ニューノーマル時代におけるリモートワークネイティブな働き方とは～多様性を尊重したエンゲージメント向上をめざして～
109. https://www.ntt.com/business/go-event.html S-11　ニューノーマル時代におけるリモートワークネイティブな働き方とは～多様性を尊重したエンゲージメント向上をめざして～
110. 幹部から裏側の想いを伝えてもらう
 • 淡々とした施策伝達を受け取った側は やらされ感がある
111. 幹部から裏側の想いを伝えてもらう
 • 淡々とした施策伝達を受け取った側は やらされ感がある • 一方で施策の裏側には想いがある ◦ もともと社内Podcastを実施していた ◦ 発展させて、動画形式で カジュアルインタビューを実施公開中
112. (CM) 詳しくはRSGT 2021にて!
113. まだまだ壁がある
114. 再掲：大企業におけるアジャイル開発の壁
 • 組織文化 ◦ 精度高い計画の要求 ◦ 頻度の多いレポーティング ◦ 失敗を許容しない （口では「許容」と言っても、空気やプロセスがそれを許さない） • プロセス ◦ 重厚な意思決定 ▪ e.g. 全リリース毎に会議を通す必要性 • リソース ◦ アジャイル開発のおける内製Devメンバが不足 ▪ e.g. エンジニアといっても、プロマネ系が多い
115. (壁を乗り越える) 素晴らしい事例も 生まれてきている
117. https://ascii.jp/elem/000/004/025/4025904/
118. 取締役の工藤氏は、「従来のNTT Comでは、非常に“堅い”開発プロセスを 経てプロダクトが出来上がっていた。今回はそれをガラリと変えて、まずはス ピーディにサービスを提供して、顧客や市場の反応を見ながらアジャイルに 改善していく方法をとった」と説明する。 スピーディな開発を行うために、現場への権限委譲も行ったという。工藤氏 は「コンセプトを決め、社内のコンセンサスをとったあとは、すべて開発チーム にお任せした。週次の進捗報告は受けたが、経営層からは一切口出しをしな かった」と語る。武田氏も、チームが自主的に意思決定をしながらプロジェク トを進められたため「非常にやりやすかった」と振り返る。 https://ascii.jp/elem/000/004/025/4025904/
119. まとめ

120. 扱ったトピック
 • 何が課題・原因だったのか、 どのように解決していったのか • エンタープライズな企業にて 課題解決に向けてどのような取組みを起こしているか？
121. 現在の皆様の想定状態（ゴール）
 • 具体的に取り組んできたプラクティスやアイデアを知り 試してみようという気になっている • 試すための勇気・モチベーションが少しでも上がっている 少しでも達成できていれば幸いです。 ということで、おしまい！