Slide 1

Slide 1 text

歴史ある会社・組織で、VUCA時代に対応できるプロ ダクト作りをするための課題と対応方法とは / Building products for the VUCA era in a long-lasting company
 
 
 NTT Communications 岩瀬 / @iwashi86
 エンタープライズアジャイル勉強会 (2020/10)

Slide 2

Slide 2 text

免責
 ● 本日の講演は個人の見解であり、 所属する組織の公式見解ではありません ● 宣伝(CM)が少しだけ挟まります 


Slide 3

Slide 3 text

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

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

大企業におけるアジャイル開発の壁
 ● 組織文化 ○ 精度高い計画の要求 ○ 頻度の多いレポーティング ○ 失敗を許容しない (口では「許容」と言っても、空気やプロセスがそれを許さない) ● プロセス ○ 重厚な意思決定 ■ e.g. 全リリース毎に会議を通す必要性

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

いやいや、うちにアジャイルチームあるよ!


Slide 12

Slide 12 text

アジャイルチーム拡大の壁
 ・・・ ・・・ あるチームで、 誰かのリーダーシップ + フォロワーシップにより アジャイル開発が始まる!

Slide 13

Slide 13 text

アジャイルチーム拡大の壁
 異動 ・・・ ・・・ 組織的な定期人事異動で、一部のメンバが別チームへ異動

Slide 14

Slide 14 text

理想的には!
 異動 ・・・ ・・・ アジャイルなマインドセットや文化が拡大していく

Slide 15

Slide 15 text

現実には
 ・・・ ・・・ 異動先では、これまで作り上げてきた開発運用プロセスから、 かつ人数の違いからアジャイル開発は実施せず (強烈なリーダーシップがあれば別)

Slide 16

Slide 16 text

アジャイルチーム拡大の壁
 チーム解散 ・・・ ・・・ やがて何らかの要因で、アジャイル開発していた プロダクトがサービス終了となり、チーム解散へ

Slide 17

Slide 17 text

アジャイルチーム拡大の壁
 ・・・ ・・・ チーム解散後は、別々のチームへそれぞれ異動。 その結果、さきほど同じプロセスでアジャイル開発が消滅。

Slide 18

Slide 18 text

続:アジャイルチーム拡大の壁
 ・・・ ・・・ ・大きな会社・組織ともなると、  複数のアジャイルチームが徐々に発生している

Slide 19

Slide 19 text

続:アジャイルチーム拡大の壁
 ・・・ ・・・ ・大きな会社・組織ともなると、  複数のアジャイルチームが徐々に発生している ・ただし、全体としてはマイノリティな状態であり、  結果的にWaterfall / 外注的なプロセスが多く残る状態  ※これでも上手くやっている例もある

Slide 20

Slide 20 text

(CM) RSGT 2021にて!

Slide 21

Slide 21 text

続:アジャイルチーム拡大の壁
 ・・・ ・・・ ・大きな会社・組織ともなると、  複数のアジャイルチームが徐々に発生している ・ただし、全体としてはマイノリティな状態であり、  結果的にWaterfall / 外注的なプロセスが多く残る状態  ⇒ これが環境に歪みを発生させる

Slide 22

Slide 22 text

続:アジャイルチーム拡大の壁
 ・・・ ・・・ ・大きな会社・組織ともなると、  複数のアジャイルチームが徐々に発生している ・ただし、全体としてはマイノリティな状態であり、  結果的にWaterfall / 外注的なプロセスが多く残る状態  ⇒ これが環境に歪みを発生させる ⇒ 何が起こるか?

Slide 23

Slide 23 text

続々:アジャイルチーム拡大の壁
 ・・・ ・・・ ・内発的動機を強烈に損なう ・その結果、優秀なソフトウェアエンジニアが  社外へ転職していく

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

https://unsplash.com/photos/BW0vK-FA3eg シンプルな因果ではない

Slide 26

Slide 26 text

「会社を良くする特効薬はない。  もしあったら良い会社ばかりになるはずだ。」 BMW元会長 エバーハート・フォン・クーンハイム

Slide 27

Slide 27 text

それって誰の仕事なの?
 
 私はエンジニアなので開発を…


Slide 28

Slide 28 text

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


Slide 29

Slide 29 text

スクラムマスターは自己組織化したチームを 構築し、企業のあらゆる階層で基本原則として自 己組織化が行われる努力します。 スクラムマスターはアジャイルコーチ やエンタープライズコーチとして働き、 組織全体を改善します。

Slide 30

Slide 30 text

経営陣を含めたマネージャーたちには、 環境を上手く整えていく義務がある。 そうすれば、管理部門や財務、 セールス、マーケティング、デプロイ、 保守などの各部門との間の 社内調整を進められるようになる。 マネージャーは全体を見据え、 全体をアジャイルの原則に あわせていかなければならない。

Slide 31

Slide 31 text

https://unsplash.com/photos/14AOIsSRsPs ゴールはだいぶ遠い それでもやっていくぞというお話

Slide 32

Slide 32 text

本講演後の皆様の想定状態(ゴール)
 ● 具体的に取り組んできたプラクティスやアイデアを知り 試してみようという気になっている ● 試すための勇気・モチベーションが少しでも上がっている

Slide 33

Slide 33 text

● 岩瀬 義昌 (@iwashi86) ● NTT Communications HR部 人材開発や組織開発、 たまにソフトウェアエンジニア ● Podcaster

Slide 34

Slide 34 text

扱うトピック
 ● 何が課題・原因だったのか、 どのように解決していったのか ● エンタープライズな企業にて 課題解決に向けてどのような取組みを起こしているか? (上記を私自身のストーリーにて)

Slide 35

Slide 35 text

タフな問い


Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

・自分はなぜここにいるのか? ・私たちは何をする者たちなのか? ・そのために何を大事にするのか?

Slide 38

Slide 38 text

あなたは(今の企業で) 何を成し遂げる人ですか?

Slide 39

Slide 39 text

振り返ってみると
 ● NTT東日本に就職 (2009) ○ 回答はなかった ■ ESに書く志望理由は浅い ■ なんとなくNWに関わる開発をして 健康に暮らしたい気持ち ● 本配属後 (2010~) ○ 大規模なシステム開発に携わる ■ VoIPやPSTN

Slide 40

Slide 40 text

当時の愛読書(1987年刊行など)

Slide 41

Slide 41 text

当時の愛読書(1987年刊行など)

Slide 42

Slide 42 text

同じタイムラインを流れる別の世界線


Slide 43

Slide 43 text

当時、憧れたキーワード Chef / Immutable Infra / Docker

Slide 44

Slide 44 text

Developers Summit (2013)

Slide 45

Slide 45 text

https://slide.meguro.ryuzee.com/slides/50

Slide 46

Slide 46 text

ちょうど30歳ぐらい
 ● 社会人としてのキャリアはまだ長い ○ 今の自分のスキル・知識 ■ PSTNやVoIP極振り

Slide 47

Slide 47 text

ちょうど30歳ぐらい
 ● 社会人としてのキャリアはまだ長い ○ 今の自分のスキル・知識 ■ PSTNやVoIP極振り ● 今の会社でのキャリアの先が見えてくる ∵ 先輩方の異動で、どういうPathがあるかわかる ● 一方で、ITを追っているとなんとなく勢いもわかる

Slide 48

Slide 48 text

少なくとも ソフトウェアエンジニアリングが軸にある

Slide 49

Slide 49 text

このままで良いのかな?
 ● Passive ○ やりたいことを伝え、定期異動を待つ ⇒ ガチャに負けたときのリスク

Slide 50

Slide 50 text

このままで良いのかな?
 ● Passive ○ やりたいことを伝え、定期異動を待つ ⇒ ガチャに負けたときのリスク ● Active ○ 社内で異動先を探す ⇒ ざっと見て、要望にあうポジションは無かった ○ グループ全体で異動先を探して応募(公募制度有り) ⇒ 良さそうなところがあった ○ 転職する ⇒ ちょうど良い話もあった

Slide 51

Slide 51 text

このままで良いのかな?
 ● Passive ○ やりたいことを伝え、定期異動を待つ ⇒ ガチャに負けたときのリスク ● Active ○ 社内で異動先を探す ⇒ ざっと見て、要望にあうポジションは無かった ○ グループ全体で異動先を探して応募(公募制度有り) ⇒ 良さそうなところがあった ○ 転職する ⇒ ちょうど良い話もあった

Slide 52

Slide 52 text

(CM) その異動先の上司に出演してもらってます https://fukabori.fm/episode/10

Slide 53

Slide 53 text

その後、ソフトウェアエンジニア業を色々と経験
 ● インフラ・自動化 ○ Chef/Ansible/Docker/Terraform ○ CI/CD w/ JenkinsやCircleCI ○ 各種クラウド(AWS/GCP/Azure/ECL 2.0) ● App ○ DB ○ サーバサイド(PHP/Golang/Node) ○ フロントエンド ● チーム開発 ○ スクラム ○ TechLead

Slide 54

Slide 54 text

その過程でいっぱい発表した
 https://www.slideshare.net/iwashi86/

Slide 55

Slide 55 text

その過程でいっぱい発表した
 https://www.slideshare.net/iwashi86/ FacebookなどでShareされて 社外発表が社員に流れる ⇒ 信頼貯金が貯まる (後から効いてくる)

Slide 56

Slide 56 text

当初R&Dだったプロダクトの出口が見えてきた
 ● (一般に)大企業でのR&Dからの商用化は大変 ○ イノベーションのジレンマにハマりやすい

Slide 57

Slide 57 text

当初R&Dだったプロダクトの出口が見えてきた
 ● (一般に)大企業でのR&Dからの商用化は大変 ○ イノベーションのジレンマにハマりやすい ● でも結果的に商用化できた ○ (数字は出せないが順調) ○ しかもメンバがすごい優秀 ■ Tech Leadである必要がなくなった

Slide 58

Slide 58 text

これらの経験から
 ● システム開発は楽しい! ○ 内製するのは特に楽しい ○ バグが出ても、瑕疵でごまかせないので自分事感MAX

Slide 59

Slide 59 text

これらの経験から
 ● システム開発は楽しい! ○ 内製するのは特に楽しい ○ バグが出ても、瑕疵でごまかせないので自分事感MAX ● チーム開発が上手くいくのは楽しい!

Slide 60

Slide 60 text

これらの経験から
 ● システム開発は楽しい! ○ 内製するのは特に楽しい ○ バグが出ても、瑕疵でごまかせないので自分事感MAX ● チーム開発が上手くいくのは楽しい! ● こういうチームやプロダクトが増えると さらに楽しいはず! ○ (当然アジャイルな働き方も)

Slide 61

Slide 61 text

だからボトムアップで
 身近なところから動き始めた


Slide 62

Slide 62 text

全社の内製チームをつなげる勉強会 ● 物理+論理(Slackコミュニティ) 勉強会写真(削除)

Slide 63

Slide 63 text

全社から参加できるTDD勉強会 by twadaさん 勉強会写真(削除)

Slide 64

Slide 64 text

エンプラ系大企業でソフトウェアエンジニアリング文化を開花させるために https://www.slideshare.net/iwashi86/ss-203448193

Slide 65

Slide 65 text

なぜ横でつなげるのか?


Slide 66

Slide 66 text

いい仕事をする力のある ミドル・マネジャーやトップなら、 組織図と両立するけれども、 それとは別個の自前のネットワークを 会社のなかに(当然、社外や会社にも)作り 出している。 そして、後者のほうが組織図よりも よほど組織と呼ぶにふさわしい ということもありうる。

Slide 67

Slide 67 text

この辺りでの気付き
 ● 社内には決して大多数ではないが ソフトウェアエンジニアは存在しているし、 面白い取組も多くある

Slide 68

Slide 68 text

https://speakerdeck.com/georgeorge/isp-challenges-serverless?slide=29 (初期アーキテクチャであり、現構成ではない)

Slide 69

Slide 69 text

続:この辺りでの気付き
 ● 社内には決して大多数ではないが ソフトウェアエンジニアは存在しているし、 面白い取組もしている ● 意外と社内で色々な行動ができる ○ 役職の高い方々も、その行動を見てくれている (ふとしたときに、言われることがある)

Slide 70

Slide 70 text

あなたは(今の企業で) 何を成し遂げる人ですか?

Slide 71

Slide 71 text

目的の遷移
 ● もともとの目的は曖昧だった

Slide 72

Slide 72 text

目的の遷移
 ● もともとの目的は曖昧だった ● 働いていく上で、IT企業の構造課題や システム開発やSWエンジニアリングの楽しさへの気付き

Slide 73

Slide 73 text

目的の遷移
 ● もともとの目的は曖昧だった ● 働いていく上で、IT企業の構造課題や システム開発やSWエンジニアリングの楽しさへの気付き ● NTT Comが変わることのインパクト ○ 実際にいただいた声 ■ 「Nコムさんがやってたので」 ■ 「真似したい」

Slide 74

Slide 74 text

目的の遷移
 ● もともとの目的は曖昧だった ● 働いていく上で、IT企業の構造課題や システム開発やSWエンジニアリングの楽しさへの気付き ● NTT Comが変わることのインパクト ○ 実際にいただいた声 ■ 「Nコムさんがやってたので」 ■ 「真似したい」 日本のエンジニアがもっと楽しく働けるのでは? また、エンタープライズエンジニア人口は多い ここに人生を投資するのは悪くなさそう

Slide 75

Slide 75 text

スコープを広げて 行動し始める

Slide 76

Slide 76 text

https://unsplash.com/photos/14AOIsSRsPs 現状認識(まだこの辺)

Slide 77

Slide 77 text

まだまだ… 道のりは長い
 ● ボトムアップだけでは限界がある ○ 幹部を巻きこんでトップダウンを併用したい

Slide 78

Slide 78 text

まだまだ… 道のりは長い
 ● ボトムアップだけでは限界がある ○ 幹部を巻きこんでトップダウンを併用したい ● 最終的には個人マインドセットや組織文化に変化を ○ ただし、全員が100%変わる必要もない ■ 企業ミッションとして 失敗しちゃいけない分野も多い (そもそも通信の会社) ■ 働き方や開発方法が混在しても良い

Slide 79

Slide 79 text

力を発揮しやすい 場所はどこか?

Slide 80

Slide 80 text

本格的にポジション変更
 ● もともとは事業部のソフトウェアエンジニア ○ 当初は片手間に、研修企画・実施など ○ 徐々に割合が変わっていった

Slide 81

Slide 81 text

本格的にポジション変更
 ● もともとは事業部のソフトウェアエンジニア ○ 当初は片手間に、研修企画・実施など ○ 徐々に割合が変わっていった ● 全社によりインパクトを出しやすい場所は? ○ より組織・文化づくりしやすい場所は?

Slide 82

Slide 82 text

本格的にポジション変更
 ● もともとは事業部のソフトウェアエンジニア ○ 当初は片手間に、研修企画・実施など ○ 徐々に割合が変わっていった ● 全社によりインパクトを出しやすい場所は? ○ より組織・文化づくりしやすい場所は? ● 自ら上長と交渉  ⇒ Human Resource(人事)へ異動 (2020.4より)

Slide 83

Slide 83 text

エレベーターピッチならぬ懇親会ピッチ
 ● 参考:いわゆるエレベーターピッチ ○ エレベーターにのっている数十秒でプレゼン (一定の信頼があったほうが成功しやすい)

Slide 84

Slide 84 text

エレベーターピッチならぬ懇親会ピッチ
 ● 参考:いわゆるエレベーターピッチ ○ エレベーターにのっている数十秒でプレゼン (一定の信頼があったほうが成功しやすい) ● 懇親会ピッチ ○ 何らかのイベント事後に飛び込んで話すこと ○ 幹部も合間合間で話せるタイミングがある ○ そのときに、自分が持っている課題を当てる ■ 「詳細は別途お時間をください」⇒ 秘書へ連絡

Slide 85

Slide 85 text

頭越しコミュニケーション
 ● 許可をとるな、謝罪せよ に近い (必須ではない。信頼関係に依存) 自分 上長 上長の上長 上長の上長の上長

Slide 86

Slide 86 text

ただ、これでまだまだ… 道のりが長い
 ● 私が言っても効果が弱い (信頼貯金があったとしても、まだまだ) ● 一定の権威付けをして、 私が伝えたいことを代弁してくれる存在

Slide 87

Slide 87 text

技術顧問に代弁してもらう https://www.ntt.com/shines/posts/b-t_20200625.html

Slide 88

Slide 88 text

ランチ勉強会はいいぞ
 ● 幹部は「非常」に忙しい ● ただし、ランチ含みのセミナー(勉強会)であれば 都合をつけていただけることもあり 比較的、参加率が高い!

Slide 89

Slide 89 text

(CM) 実施した内容や質疑を公開中 https://www.ntt.com/shines/posts/b-t_20200828a.html

Slide 90

Slide 90 text

何を伝えてもらったか?
 ● 及川さん ○ 現代のプロダクトマネジメント ○ 実装軽視コア技術の内製化(手の内化) ○ プラットフォーム戦略の失敗

Slide 91

Slide 91 text

何を伝えてもらったか?
 ● 及川さん ○ 現代のプロダクトマネジメント ○ 実装軽視コア技術の内製化(手の内化) ○ プラットフォーム戦略の失敗 ● 吉羽さん ○ Why アジャイル ○ 品質の考え方 ○ 機能しているチームを壊さないこと、内製化

Slide 92

Slide 92 text

何を伝えてもらったか?
 ● 及川さん ○ 現代のプロダクトマネジメント ○ 実装軽視コア技術の内製化(手の内化) ○ プラットフォーム戦略の失敗 ● 吉羽さん ○ Why アジャイル ○ 品質の考え方 ○ 機能しているチームを壊さないこと、内製化 ● 和田さん ○ MTTR vs MTBF ○ 質とスピード ○ 内製化(ローパフォマーは外注しがち)

Slide 93

Slide 93 text

何を伝えてもらったか?
 ● 及川さん ○ 現代のプロダクトマネジメント ○ 実装軽視コア技術の内製化(手の内化) ○ プラットフォーム戦略の失敗 ● 吉羽さん ○ Why アジャイル ○ 品質の考え方 ○ 機能しているチームを壊さないこと、内製化 ● 和田さん ○ MTTR vs MTBF ○ 質とスピード ○ 内製化(ローパフォマーは外注しがち) 意図的にキーワードとして出してもらう

Slide 94

Slide 94 text

補足)別に内製化のみが最適解ではない
 ● 内製化が必要ない領域も多くある ● 内製化しても課題は多い(歴史から) https://comemo.nikkei.com/n/n360cc11aadea

Slide 95

Slide 95 text

一方で内製しなさすぎ問題もある
 ● 歴史的経緯から外注メインにした会社は多い ● 結果、起こる内製人材が希少問題 ○ また、シニアエンジニアがいない問題 ● だから内製化の重要性を強すぎるぐらいに 一度伝えてもらっている

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

twada塾 開講 ● 狙い ○ 今後、NTTコムで必要となるソフトウェア内製開発スキルを習得する ○ PoCで好評であった場合に向け、スケーラブルな実装について学ぶ ● 到達目標 ○ PoCレベルであれば、一人で短期間で高速開発できるレベルになる ● プログラム概要 ○ 社内システムを題材として、 サーバーサイド・フロントエンド・インフラまで一人で開発・運用する ○ 技術顧問の和田氏を中心とした講義、定期的な1on1により 独学では難しいソフトウェア開発スキルを習得

Slide 98

Slide 98 text

何を伝えてもらったか?
 ● 及川さん ○ 現代のプロダクトマネジメント ○ 実装軽視コア技術の内製化(手の内化) ○ プラットフォーム戦略の失敗 ● 吉羽さん ○ Why アジャイル ○ 品質の考え方 ○ 機能しているチームを壊さないこと、内製化 ● 和田さん ○ MTTF vs MTBF ○ 質とスピード ○ 内製化(ローパフォマーは外注しがち)

Slide 99

Slide 99 text

https://www.ryuzee.com/contents/blog/13147

Slide 100

Slide 100 text

道中、予期せぬ出来事もあった
 ● COVID-19の出現

Slide 101

Slide 101 text

道中、予期せぬ出来事もあった
 ● COVID-19の出現 ● 一方でチャンスでもある =変化が起こるタイミングは  新しいアイデアをインストールしやすい ⇒ 2020/5上に内部勉強会

Slide 102

Slide 102 text

https://www.slideshare.net/iwashi86/ss-233430281

Slide 103

Slide 103 text

リモートワーク × アジャイル.
 ● リモートワーク慣れしていたので 働き方のコツをまとめて伝えた

Slide 104

Slide 104 text

リモートワーク × アジャイル.
 ● リモートワーク慣れしていたので 働き方のコツをまとめて伝えた ● リモート下にて、アジャイルな行動や考えを 応用できる箇所は多い(HRでも当然) ● e.g. 透明性 ○ リモートではチームメンバの動きが 見えにくい ○ だから、オンラインカンバンで可視化 ○ タイムボックスを区切りアップデートする

Slide 105

Slide 105 text

No content

Slide 106

Slide 106 text

https://www.ntt.com/business/go-event.html S-11 ニューノーマル時代におけるリモートワークネイティブな働き方とは~多様性を尊重したエンゲージメント向上をめざして~

Slide 107

Slide 107 text

https://www.ntt.com/business/go-event.html S-11 ニューノーマル時代におけるリモートワークネイティブな働き方とは~多様性を尊重したエンゲージメント向上をめざして~

Slide 108

Slide 108 text

https://www.ntt.com/business/go-event.html S-11 ニューノーマル時代におけるリモートワークネイティブな働き方とは~多様性を尊重したエンゲージメント向上をめざして~

Slide 109

Slide 109 text

https://www.ntt.com/business/go-event.html S-11 ニューノーマル時代におけるリモートワークネイティブな働き方とは~多様性を尊重したエンゲージメント向上をめざして~

Slide 110

Slide 110 text

幹部から裏側の想いを伝えてもらう
 ● 淡々とした施策伝達を受け取った側は やらされ感がある

Slide 111

Slide 111 text

幹部から裏側の想いを伝えてもらう
 ● 淡々とした施策伝達を受け取った側は やらされ感がある ● 一方で施策の裏側には想いがある ○ もともと社内Podcastを実施していた ○ 発展させて、動画形式で カジュアルインタビューを実施公開中

Slide 112

Slide 112 text

(CM) 詳しくはRSGT 2021にて!

Slide 113

Slide 113 text

まだまだ壁がある

Slide 114

Slide 114 text

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

Slide 115

Slide 115 text

(壁を乗り越える) 素晴らしい事例も 生まれてきている

Slide 116

Slide 116 text

No content

Slide 117

Slide 117 text

https://ascii.jp/elem/000/004/025/4025904/

Slide 118

Slide 118 text

取締役の工藤氏は、「従来のNTT Comでは、非常に“堅い”開発プロセスを 経てプロダクトが出来上がっていた。今回はそれをガラリと変えて、まずはス ピーディにサービスを提供して、顧客や市場の反応を見ながらアジャイルに 改善していく方法をとった」と説明する。 スピーディな開発を行うために、現場への権限委譲も行ったという。工藤氏 は「コンセプトを決め、社内のコンセンサスをとったあとは、すべて開発チーム にお任せした。週次の進捗報告は受けたが、経営層からは一切口出しをしな かった」と語る。武田氏も、チームが自主的に意思決定をしながらプロジェク トを進められたため「非常にやりやすかった」と振り返る。 https://ascii.jp/elem/000/004/025/4025904/

Slide 119

Slide 119 text

まとめ


Slide 120

Slide 120 text

扱ったトピック
 ● 何が課題・原因だったのか、 どのように解決していったのか ● エンタープライズな企業にて 課題解決に向けてどのような取組みを起こしているか?

Slide 121

Slide 121 text

現在の皆様の想定状態(ゴール)
 ● 具体的に取り組んできたプラクティスやアイデアを知り 試してみようという気になっている ● 試すための勇気・モチベーションが少しでも上がっている 少しでも達成できていれば幸いです。 ということで、おしまい!