Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

iwashi
October 15, 2020

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

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

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

iwashi

October 15, 2020
Tweet

More Decks by iwashi

Other Decks in Technology

Transcript

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



    NTT Communications 岩瀬 / @iwashi86

    エンタープライズアジャイル勉強会 (2020/10)

    View Slide

  2. 免責

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

    View Slide

  3. 定義

    ● 「VUCA時代に対応できるプロダクト」とは

    ○ お客様がハッピーになり

    ○ 自社にも利益があがり

    ○ 従業員が楽しく働いて作れるプロダクト
    のこと

    View Slide

  4. 今日お話すること


    View Slide

  5. 扱うトピック

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

    View Slide

  6. 扱うトピック

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

    View Slide

  7. どれに当てはまりますか?


    どの壁が立ちはだかっていますか?


    View Slide

  8. 大企業におけるアジャイル開発の壁

    ● 組織文化
    ○ 精度高い計画の要求
    ○ 頻度の多いレポーティング
    ○ 失敗を許容しない
    (口では「許容」と言っても、空気やプロセスがそれを許さない)

    View Slide

  9. 大企業におけるアジャイル開発の壁

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

    View Slide

  10. 大企業におけるアジャイル開発の壁

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

    View Slide

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


    View Slide

  12. アジャイルチーム拡大の壁

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

    View Slide

  13. アジャイルチーム拡大の壁

    異動
    ・・・ ・・・
    組織的な定期人事異動で、一部のメンバが別チームへ異動

    View Slide

  14. 理想的には!

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

    View Slide

  15. 現実には

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

    View Slide

  16. アジャイルチーム拡大の壁

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

    View Slide

  17. アジャイルチーム拡大の壁

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

    View Slide

  18. 続:アジャイルチーム拡大の壁

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

    View Slide

  19. 続:アジャイルチーム拡大の壁

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

    View Slide

  20. (CM) RSGT 2021にて!

    View Slide

  21. 続:アジャイルチーム拡大の壁

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

    View Slide

  22. 続:アジャイルチーム拡大の壁

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

    View Slide

  23. 続々:アジャイルチーム拡大の壁

    ・・・ ・・・
    ・内発的動機を強烈に損なう
    ・その結果、優秀なソフトウェアエンジニアが
     社外へ転職していく

    View Slide

  24. 再掲:大企業におけるアジャイル開発の壁

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

    View Slide

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

    View Slide

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

    View Slide

  27. それって誰の仕事なの?


    私はエンジニアなので開発を…


    View Slide

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


    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  32. 本講演後の皆様の想定状態(ゴール)

    ● 具体的に取り組んできたプラクティスやアイデアを知り
    試してみようという気になっている
    ● 試すための勇気・モチベーションが少しでも上がっている

    View Slide

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

    View Slide

  34. 扱うトピック

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

    View Slide

  35. タフな問い


    View Slide

  36. View Slide

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

    View Slide

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

    View Slide

  39. 振り返ってみると

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

    View Slide

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

    View Slide

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

    View Slide

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


    View Slide

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

    View Slide

  44. Developers Summit (2013)

    View Slide

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

    View Slide

  46. ちょうど30歳ぐらい

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

    View Slide

  47. ちょうど30歳ぐらい

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

    View Slide

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

    View Slide

  49. このままで良いのかな?

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

    View Slide

  50. このままで良いのかな?

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

    View Slide

  51. このままで良いのかな?

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

    View Slide

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

    View Slide

  53. その後、ソフトウェアエンジニア業を色々と経験

    ● インフラ・自動化
    ○ Chef/Ansible/Docker/Terraform
    ○ CI/CD w/ JenkinsやCircleCI
    ○ 各種クラウド(AWS/GCP/Azure/ECL 2.0)
    ● App
    ○ DB
    ○ サーバサイド(PHP/Golang/Node)
    ○ フロントエンド
    ● チーム開発
    ○ スクラム
    ○ TechLead

    View Slide

  54. その過程でいっぱい発表した

    https://www.slideshare.net/iwashi86/

    View Slide

  55. その過程でいっぱい発表した

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

    View Slide

  56. 当初R&Dだったプロダクトの出口が見えてきた

    ● (一般に)大企業でのR&Dからの商用化は大変
    ○ イノベーションのジレンマにハマりやすい

    View Slide

  57. 当初R&Dだったプロダクトの出口が見えてきた

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

    View Slide

  58. これらの経験から

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

    View Slide

  59. これらの経験から

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

    View Slide

  60. これらの経験から

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

    View Slide

  61. だからボトムアップで

    身近なところから動き始めた


    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  65. なぜ横でつなげるのか?


    View Slide

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

    View Slide

  67. この辺りでの気付き

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

    View Slide

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

    View Slide

  69. 続:この辺りでの気付き

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

    View Slide

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

    View Slide

  71. 目的の遷移

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

    View Slide

  72. 目的の遷移

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

    View Slide

  73. 目的の遷移

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

    View Slide

  74. 目的の遷移

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

    View Slide

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

    View Slide

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

    View Slide

  77. まだまだ… 道のりは長い

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

    View Slide

  78. まだまだ… 道のりは長い

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

    View Slide

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

    View Slide

  80. 本格的にポジション変更

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

    View Slide

  81. 本格的にポジション変更

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

    View Slide

  82. 本格的にポジション変更

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

    View Slide

  83. エレベーターピッチならぬ懇親会ピッチ

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

    View Slide

  84. エレベーターピッチならぬ懇親会ピッチ

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

    View Slide

  85. 頭越しコミュニケーション

    ● 許可をとるな、謝罪せよ に近い
    (必須ではない。信頼関係に依存)
    自分 上長 上長の上長 上長の上長の上長

    View Slide

  86. ただ、これでまだまだ… 道のりが長い

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

    View Slide

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

    View Slide

  88. ランチ勉強会はいいぞ

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

    View Slide

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

    View Slide

  90. 何を伝えてもらったか?

    ● 及川さん
    ○ 現代のプロダクトマネジメント
    ○ 実装軽視コア技術の内製化(手の内化)
    ○ プラットフォーム戦略の失敗

    View Slide

  91. 何を伝えてもらったか?

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

    View Slide

  92. 何を伝えてもらったか?

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

    View Slide

  93. 何を伝えてもらったか?

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

    View Slide

  94. 補足)別に内製化のみが最適解ではない

    ● 内製化が必要ない領域も多くある
    ● 内製化しても課題は多い(歴史から)
    https://comemo.nikkei.com/n/n360cc11aadea

    View Slide

  95. 一方で内製しなさすぎ問題もある

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

    View Slide

  96. 再掲:大企業におけるアジャイル開発の壁

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

    View Slide

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

    View Slide

  98. 何を伝えてもらったか?

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

    View Slide

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

    View Slide

  100. 道中、予期せぬ出来事もあった

    ● COVID-19の出現

    View Slide

  101. 道中、予期せぬ出来事もあった

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

    View Slide

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

    View Slide

  103. リモートワーク × アジャイル.

    ● リモートワーク慣れしていたので
    働き方のコツをまとめて伝えた

    View Slide

  104. リモートワーク × アジャイル.

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

    View Slide

  105. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  110. 幹部から裏側の想いを伝えてもらう

    ● 淡々とした施策伝達を受け取った側は
    やらされ感がある

    View Slide

  111. 幹部から裏側の想いを伝えてもらう

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

    View Slide

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

    View Slide

  113. まだまだ壁がある

    View Slide

  114. 再掲:大企業におけるアジャイル開発の壁

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

    View Slide

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

    View Slide

  116. View Slide

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

    View Slide

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

    View Slide

  119. まとめ


    View Slide

  120. 扱ったトピック

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

    View Slide

  121. 現在の皆様の想定状態(ゴール)

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

    View Slide