【全文公開】Anthos Dayで「GKE導入事例～パーソナルダッシュボード開発～」というタイトルで登壇してきました

##はじめに
本記事は2020年1月30日に開催された[Google Cloud Anthos Day](https://inthecloud.withgoogle.com/anthos-day-2001/register.html)で発表したセッション**「NTTドコモ情報システム部におけるGKE導入事例　～パーソナルダッシュボード開発～」**でお話しした内容を文字に起こしたものです🎉

スライドだけをご覧になりたい方は[こちら](https://speakerdeck.com/kishiyyyyy/gke-case-study)へ💪

スライドと原稿をWebで公開した理由は、

- セッション中、話に集中してもらえるように
- わざわざ私が話したことをメモしなくて済むように
- カンファレンスに参加できなかった人にも聞いて欲しかったため  

出来るだけ多くの方（特にエンタプライズ企業に関わっている方）にこの記事が届くと嬉しいです。


##本セッションで伝えたいことサマリ

- パーソナルデータダッシュボードを支えるGCP基盤について
- GCP（GKE）導入の背景、決め手
- エンタープライズ企業で新たな取り組みを成功させるポイントと、これからのチャレンジ

##表紙
<img width="1051" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/69b58f22-f609-81d7-f2c6-9d66d6f4b0d6.png">


##自己紹介、会社紹介
<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/5fa2bfda-1033-e4dc-2fd6-361c0d8a0814.png">


NTTドコモでプロダクトマネージャをやっている岸と申します。
[Twitter](https://twitter.com/kishiyyyyy)はこちら。

これまでの経歴と今やっていることを簡単に。

- 2014年4月にドコモ入社
- 入社してから4年ほどは基幹系のシステム開発に従事
- 2017年10月に現在の所属先でもある**アジャイル開発組織の前身となるチームの立ち上げ**を行いました
- 現在は、**プロダクトマネージャとしてWebアプリケーションの企画・開発**および**SREチームのリーダとしてわれわれチームで扱うプロダクトのアーキテクチャ設計**などを行ってます
<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/2df43c77-de65-f89b-7231-8601b13121f4.png">

NTTドコモは1992年に設立された移動体通信事業を生業とする会社、いわゆる通信キャリアです。われわれは通信事業とスマートライフ領域の２つの事業を手がけています。

- 通信事業では、**お客さまとのつながりを強固にし顧客基盤の拡大**を目指し
- スマートライフ事業では、**外部のパートナーとの協創を行い非通信事業の成長**を図っています。

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/19c21bc1-0337-c20e-1466-9767ebf762d2.png">

その中で、私が所属する情報システム部の役割は、これら**事業に必要となるプロダクトをBizと共に開発して、お客さまへ届けること**です。手がけるシステムは SoR / SoE の２種に大別されます。

- SoRとは顧客システムや料金計算システムといったいわゆる基幹系のシステム
- SoEとはコンシューマ向けのサービス、あるいは社内向けの業務支援システムといったフロントエンドのシステム

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/153672a2-c310-7f67-eb66-3a28effcc69e.png">

それぞれの特徴を一言で表すと、**SoRは変わりにくくSoEは変わりやすい**。全く特性が違うものです。そこで弊部ではこちらの戦略を取っています。

- **SoR/SoEは疎結合にし分離して考える**
- **SoRは標準技術に徐々に移行しSoEは積極的に差別化をしていく**

<img width="1000" alt="スクリーンショット_2020_01_29_10_40.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/af0d00dc-326b-f3c6-c222-8fa98b53e745.png">

その戦略の一環で、われわれは2018年7月に情報システム部内にSoE開発を担う専門チームを新設しました。これまで**SoRに最適化されてきたやり方を抜本的に見直し**、変化の激しい市場に対応するために、**アジャイル的な開発、すばやく・スケールする基盤を活用**しています。後者はいわゆるクラウドネィティブと総称される技術たちのことです。

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/d150335f-8543-4e4e-1eec-eeca3a7a8011.png">

改めまして本日お話することは３点です。

- パーソナルデータダッシュボードを支えるGCP基盤について
- GCP（GKE）導入の背景、決め手
- エンタープライズ企業で新たな取り組みを成功させるポイントと、これからのチャレンジ

##パーソナルデータダッシュボードを支えるGCP基盤

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/e04a9f3b-04e9-ee37-82ab-d16e12d65256.png">

まずは、パーソナルデータダッシュボードを支えるGCP基盤について。

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/9a711051-2e5d-010b-1833-da56aee6287d.png">

プロダクトを紹介する前に、そもそもなぜこのようなプロダクトを提供するに至ったのかという背景を簡単に。

現在、**パーソナルデータを取り巻く外部環境が大きく変化**しています。パーソナルデータとはお客様の個人情報や位置情報などイメージしていただけると分かりやすいかと。

ドコモしてはお客さまへ驚きと感動を提供するために、5GやAIなどの最新技術を活用するはもちろんのこと、**お客様それぞれに合ったサービスを提供するにはパーソナルデータを活用させていただくことが必要不可欠**となります。

さらに、社会全般でパーソナルデータの活用が進展し、**個人のプライバシーへの関心が高まっております**。

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/716077fa-4f35-5817-711b-9a4cb45e2ee0.png">

そのような背景を踏まえ、ドコモは2019年8月に[パーソナルデータ憲章](https://www.nttdocomo.co.jp/utility/personal_data/charter/)を公表しました。お客さまのパーソナルデータを適切に取り扱うための意思決定基準を6つの行動原則として表したものです。

例えば、

- コミュニケーションを大切にし、透明性を確保する
- お客さま一人ひとりの意思を尊重する

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/c01f5cc0-03c7-2508-3f8a-6e7589e9262d.png">

こちらの行動原則を形にしたものの１つが、**2019年12月、昨年末に提供を開始した[パーソナルデータダッシュボード](https://datadashboard.front.smt.docomo.ne.jp/)です**。コンシューマ向けサービスなので、弊社のお客さまであればどなたでもご利用いただけます。

具体的にダッシュボードではどんな機能を提供しているのかというと、

- パーソナルデータの取扱いについて同意いただいた内容を確認したり、
- ドコモ内でのデータ利用目的、パートナーなどへの第三者提供を一定の範囲でお客さま自ら設定・変更できるようになりました

これまでは個別サービスごとに機能や情報を管理していたのですが、お世辞にも利便性が高いものではありませんでした。そこで、これら情報を一元管理し、お客様自身で設定変更できるようにしたことで利便性はもちろんのこと、透明性の確保に貢献しております。

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/6664fd89-a7a3-80db-46fa-0f2ac9e6b20d.png">

では、本プロダクトを支えるGCP基盤について、具体的なアーキテクチャも紹介しつつお話していきます。

GCP基盤の中心となっているのがこの２つのコンポーネントです。

- コンテナ化したアプリケーションのデプロイ環境としてk8sのマネージドサービスである**GKE**
- 7,600万ものお客様データの一時的な格納先としてNoSQLデータベースである**Firestore**



<img width="1057" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/f466aef9-417a-d5cc-2dcf-f6fd5031c5ff.png">


こちらがアーキテクチャ全体像です。単なるWebアプリケーションなので構成図自体はとてもシンプルです。アプリケーションは全てGKE上で稼働しています。

特徴的なのがSoR系システムとの連携です。

本プロダクトは複数のSoRシステムとの連携のもと成り立っていまして、API連携とファイル連携の２つの連携方式を採用しています。

そのほぼ全てがAPI連携なのですが、一部でファイル連携を採用したのは

- データ鮮度が最新であることが業務上必須でなく
- SoR側のAPI開発コストが多くかかるためでした。

ファイル連携で受領したデータをわれわれのFirestoreに格納し利用しております。データインポート処理の解説はまた後ほど。

では続いてGKE、Firestore周りについてもう少し詳細に解説していきます。

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/fc66885e-6ca9-2519-0012-eff4bb6b0f02.png">

先ほど述べた通り、全てのアプリケーションはGKE上で稼働しています。**GitLab CI / Cloud Buildを使い継続的インテグレーション**を、**Argo CDを使った継続的デリバリー**を実装しています。なお、商用環境の**監視ツールとしてDatadog**を使っています。

<img width="1051" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/49068389-d3bf-9ac3-8210-6dc7ba3ead39.png">

続いて、Firestore周辺のアーキテクチャです。SoR系システムからファイル転送されたデータをどのように扱っているか。処理の流れとしては、SoRのシステムがS3にデータを置いてくれた後、われわれの手でS3からGCSへ転送し、Dataflowを並列で使いFirestoreへインポートしています。これらワークフローのオーケストレーションとしてCloud Composerを利用しています。

このインポート処理がなかなか曲者でして。今回はSoRの制約上、**お客様総数にあたる7,600万件のレコードを日次で洗い替える**必要がありました。障害復旧の観点からすると差分より全件の方が楽なのですが、気になるのは処理の時間です。

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/36ff4e0c-388b-a10f-2a63-2d1cf145827d.png">

Google社とも議論した結果、あらゆる業務要件を加味するとデータベースとしてFirestoreを利用するのがベストと決めたものの、いざ実際構築してからの**性能チューニング**が今回一番苦労した点です。

短時間でFirestoreにデータをインポートするために実施したことをご紹介します。

まず、今回Dataflowを並列で走行させデータを流し込んでいるのですが、並列処理の場合、**リクエストが正しくてもエラー応答となる場合があるためリトライの機構が必要**です。例えばリクエストの上限数超過、Firestore側が過負荷によってたまたまエラーになることが起きえるので。

とはいえ、リトライ処理だけに頼ればいいかというとそうではなく、短時間で処理は済ませるためには、**エラーを極力起こさないよう努めること**が大事です。

工夫した処理のうちもっとも印象的だったのが、「**500/50/5ルール**」です。Firestoreはリクエスト量に応じて段階的にスケールする仕組みなため、一度に多くのリクエストを送るとスケールが間に合わずエラーとなります。これはFirestoreの仕様です。もっとも効率よくFirestore側が処理できるように、この「500/50/5ルール」に乗っ取りリクエストを投げることが肝です。

具体的には新しいコレクションに対するオペレーションは、**毎秒 500 回を上限とし、5 分ごとにトラフィックを 50% 増やす**という考えです。公式ドキュメントにはちゃんと書いてあるものの、初めて知ったルールだったので驚きでした。

それを知らずに無邪気に大量のリクエストを投げてしまいですねGoogle社のSREチームをびっくりさせてしまったので、みなさんも大量のリクエストを投げる際はぜひこのルールを覚えておいてください。

この性能チューニングの工夫話はもっと色々あるのですが時間がないため割愛します。詳細は私たちのチームのSMがQiitaにまとめてくださったので興味ある人はぜひご覧になってください。

[Firestoreの性能チューニング(Qiita)](https://qiita.com/syagi/items/298efd47c6757843e0eb)
[Cloud Firestoreのベストプラクティス](https://firebase.google.com/docs/firestore/best-practices?hl=ja)

今回お伝えしたかったのが、**SoRとの連携は制約の中で最善を探し求めるということが大事**ということ。SoRのシステムは標準技術に移行できていないことも多く、制約がつきものです。そうなると完璧なアーキテクチャは組めないかもしれませんが、その中で**最善を見つけるのがアーキテクトとしての腕の見せ所**なのかなと思います。

##GCP (GKE) 導入の背景と決め手
<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/2a4d54bc-f471-7d08-adde-9a7d6505e6e2.png">

続いて、GCP (GKE) 導入の背景と決め手です。われわれのチームは今回のプロダクトではじめてGKEを利用しました。そもそもなぜ使うに至ったのかをお話していきます。

<img width="1054" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/ddf61c7a-6eb7-9c17-fe0b-a710346feee6.png">

Kubernetes自体は初めてではなく、2017年10月に組織が発足してからKubernetesベースのPaaSをずっと利用してきました、パブリッククラウド上に構築して。

当時、マネージドk8sを採用しなかった理由は、構築中であった社内のプライベートクラウド上の存在によるところが大きいです。将来的にはパブリッククラウドではなくできるだけ自社のクラウドへお引越することという大前提があったため、IaaSと疎な製品を採用しました。

注意して欲しいのでが、パブリックかプライベートかどちらか一方が正義という話ではなく、安心感のためか当時はできるだけプライベートに載せたいという考えの方が多勢だっただけです。あと、マネージドk8sの導入事例自体も少なかったかなと。

その結果、あえてIaaSとPaaSを分離した構成を採用したのですが、１年半の運用を経て、**運用面、機能面、コスト面で改善ポイントが浮き彫り**になっていました。

<img width="1054" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/8db8b0fe-6963-efcd-642b-f6fd538f6b14.png">


当時の環境が抱えていた改善点は大きく３点です。

1. **もっと手間なく、楽に効率的に運用したい**  
管理対象範囲はIaaSレイヤ以上のすべてとなり、運用コストが大きかったです。基盤のアップグレードやノードのオートスケールするのも一苦労な状況でした。

2. **周辺機能を手軽に利用したい**  
CI／CD周りのサポートやロギング、モニタリング機能を実装しようと思うとどうしても他製品を使わなくては実現できないことが多く、商用利用を想定すると周辺機能が心もとない印象でした。

３. **必要な時に必要な分だけ費用を払いたい**   
ライセンスベースの課金体系（コア数・年単位）のため、開発ピークに合わせてライセンスの事前購入が必要なため、遊びが発生している状況で。

これら課題はPaaSとIaaSが分離しているが故なことが多かったため、改めて2019年4月からマネージドk8sのPoC/評価を実施しました。

<img width="1000" alt="スクリーンショット_2020_01_29_10_51.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/98f1a92f-fc46-db55-d406-9d25b8a04b41.png">

第一に、そもそもPoCすることができたのは、ミッションクリティカルなシステムでのパブリッククラウドの導入実績が増えたことが後押しがあったからです。あらゆるものを自社で持つのではなく、オンプレとパブリッククラウドを使い分けようという時代の流れに乗れたのはあります。

われわれはGKEを含むマネージドk8sをいくつかPoCしたのでしが、大きな観点は３つ。

- マネージドk8sでも今までできていたことが実現できるか
- 課題が解決できるか
- 自分たちだけで構築、運用保守が賄えるか

細かな評価観点は割愛します。正直、よっぽど特殊な要件がない限り、マネージドk8sのサービスの何を選んでも間違いではないです。大きな機能的な差異もないと思っています。

<img width="1000" alt="スクリーンショット_2020_01_29_10_52.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/e28e7513-7b40-bdcf-6ebb-e0098e1a733f.png">

ではなぜ、われわれはGKEを選んだのか？決め手はこちらです。

- **ランニングコストが安いこと**  
GKEはmaster nodeにお金がかからないため、他製品と比べて安価に維持できました。
- **ドキュメントが豊富で分かりやすいこと**  
実はGKEを触ったことがあるメンバーはゼロだったが、Qwiklabsや公式ドキュメントを参考にスキルを習得できたのは大きな自信にもなりました。
- （ミーハーではあるが）**k8s生みの親である安心感**

このような理由からわれわれはこのプロダクトにおいてGKEを採用しました。

今現在、他のプロダクトでもGKEを基本使うことにしていますが、今後はGKEだけではなくGAEやCloudRunといったより運用が楽に手間なくできる基盤も採用していきたいと思っています。

## エンタープライズ企業で新たな取り組みを行う上でのポイント
<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/228db80f-a99b-4771-962c-c0113f42cd2b.png">

続いて、われわれのようなエンタープライズ企業で新たな取り組みを成功させるポイントについて経験談交えてお話していきます。

この中でにもエンタープライズ企業に勤めている人、もしくはその人たちを支援するいわゆるSIの方多くいますよね。エンタープライズ企業でアジャイルやDevOpsといった新しい概念や文化を導入するのは難しいなというイメージを持たれているんじゃないかなと。その原因って何だろうかすこし頭の中で考えてみてください。

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/fd877189-53b9-f494-e158-d383c42e7cd5.png">

私が考えるエンタープライズ企業ならではの事情、壁はこちらです。

もっとも大きいのが**エンジニアリングリソースがないこと**かなと。アジャイルやDevOpsの文脈では、ユーザ企業やSIといった**会社の垣根なんて関係なく１チームであることが大前提**です。会社が分断されている方が望ましいと思う人はこの会場に誰もいないと思います。この前提のもと、**外部のパートナー企業の力を借りてどのようにアジャイルなマインドや文化を築いていくか？**

もうひとつが、これまでの実績や既存システムが多くある中で、**新しい取り組みをどう提案・導入していくのか**です。同規模の他社事例も多くはない中で、どう合意形成していくのか。

他にも色々あると思いますが、間違いなく当てはまる２つかなと。

<img width="1000" alt="スクリーンショット_2020_01_29_10_53.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/fdf16bbc-426a-e62e-b9bd-9cfa4fd95497.png">

私が大事だと思うのは、「**内製開発チームに近い環境を作る**」ことと「**小さく始める、まずは試す**」を実践することです。

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/fc58bbdf-b13e-2f4f-88ad-ba47012c4954.png">

具体的に何を意味するのかをを話す前に、まずはこちらの写真をご覧ください。

左の大きな写真は私たちの組織が発足した当時の使っていた小部屋です。机とイス、パソコンしかなく、メンバーもたった5人でして、この部屋の中でスタートしました。POが私、パートナーからSM1名、Devloper3名という体制です。

小さく写っているのが現在のフロアで、パートナー含めメンバーは100名弱にも拡大しました。本プロダクト含め、複数のスクラムチームで複数のプロダクトを開発、運用しています。

歴史とともにチームの人数も環境も変わってきましたが、内製開発に出来るだけ近づけるためにやってきたことがこちらです。

<img width="1058" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/59dbd06b-08f1-b368-aee0-64ef0206981d.png">


- **全員が同じ拠点で、同じフロアで、一緒に働く**  
超基本的な考えですが、全員が同じ拠点で、同じフロアで、一緒に働くことです。会社間の壁などなく、違いは首から下げているストラップの色ぐらい。会話量がチームの結束力を高める、意思疎通がスムーズになることは間違いないです。組織が成熟してきたらリモート開発も良いかもしれませんが、まずは対面で働くことを優先しました。また、秘匿情報を除き、あらゆる情報をオープンし情報の非対称性をなくすことも大事です。

- **会社の垣根を超えてコミュニケーションする** 
パートナーも１社だけではなく多くの会社からきてくれているので、会社の垣根を出来るだけなくすようコミュニケーションの回数も意図的に増やしてきました。バザー形式のプロダクトレビューを開催したり、週１回持ち回りで開催している勉強会をやったりですね。

- **パートナーと一緒にスキルを伸ばす風土を作る**    
正直な話、われわれはもちろんのことパートナーもアジャイルやDevOpsにチャレンジしている最中で、スキルをもっているひとばかりではありません。なので、パートナーと一緒にスキルを伸ばす風土も大事です。例えば、生々しい話をすると、われわれの予算でチーム全員で社外の研修を受けたり、外部講師を呼んで勉強会したり。このようなバックアップをしてくれている組織、上位層にとても感謝してます。

<img width="1000" alt="スクリーンショット_2020_01_29_10_55.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/7675a9ce-f454-30c2-83c1-1ccc1fecae70.png">

２つ目が小さく始める、まずは試すことです。

今まで組織に無い技術なので、使って試して効果を見せるしかないです。われわれは新たな手法や技術は小さく試し徐々に適用範囲を広げていきました。

われわれがアジャイル開発手法を導入した際は

1. トライアル案件
2. 社内向けアプリ
3. コンシューマ向けアプリ

という順に適用しました。並行して社内のルールなども整備してきたため、ここに至るまで＊＊約2年半**かかっています。＊＊根気のいる工程ですが合意形成のためには避けられない＊＊こともあります。

また、机上検討で頑張りすぎないことですね。技術の移り変わりも早いことと、安価にすぐ試せる技術ばかりなので、まずはやってみる精神が大事です。

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/e9ce295c-5a04-a468-c42b-d0ddd2352684.png">

加え、会社が複数にまたがる状況を踏まえ、私個人が重要だと感じたのが**エンタープライズ企業のメンバーも最低限のエンジニアリングスキルを身に着けること**です。

パートナーにはできない社員しかできない役割は、**スピード感を持って判断し、説明責任を果たすこと**。裏を返すと、これができず意思決定をのんびりしていたら今までの話は水の泡です。**社員がボトルネックになってはダメ**です。

そのためにも、最低限のスキル習得は必要だと思います。恥ずかしいかな、私自身チームを立ち上げた際はアジャイルのアの字も知らない、プログラミングもしたことのない状態でした。私がやった具体的な学習方法はこちらです。やり方は何でもいいです。

- 認定資格やカンファレンスを通して机上で学ぶ
- Webアプリケーションをひとりで作ってみる
- Qwiklabsなどのオンライン学習サイトでGCPの基礎を学ぶ


決して、社員がエンジニアになれといっているわけでなく、パートナーと対等に会話をし、意思決定さえできる状態であれば十分です。~~意思決定するには当然権限も必要なので、上位層の方々はちゃんと現場に権限を移譲してくださいね。~~

<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/38a06785-b2f3-b27b-e50b-1e23398e8f81.png">

とはいえ、われわれも道半ばで、やることは盛りだくさんです。

Bizを巻き込み、会社全体でアジャイルなチームを作るにはどうすればいいのかは模索中です。われわれはたかが開発部でしく、Bizもセットでアジャイルなチームにならないと片手落ちです。彼らをどう巻き込んでいくのかが今後の課題です。

また、大規模プロジェクトにおける最適な開発の進め方も模索中です。

例えば

- 基幹系システムの開発も伴うケース（手戻りが許容できない）や
- 多くの部署が絡む利害関係者が多いケース

において、意思決定をどうデザインするのがいいかの解をまさに今探している最中です。

こう見ると、エンタープライズ企業ではいわゆるWeb系企業にはない課題や壁が多くあります。ただ、**まず最初の第一歩さえ踏めれば先が見えてきますし、伸び代しかない**です。こういうカンファレンスでもユーザ企業の事例発表がどんどん増えると嬉しいなと思います。

## NTTドコモ、自組織のこれからのチャレンジ
<img width="1000" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/45e16431-4a10-cc4a-577d-abb0ee599541.png">

最後に、NTTドコモ、自組織のこれからのチャレンジです。

<img width="1000" alt="スクリーンショット_2020_01_29_10_56.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/185f4492-bcde-7a07-b59d-4a84f5c2afb1.png">

- **パーソナルデータダッシュボードは新たな価値をお客様に提供するするための第一歩**です。これからデータを活用し**お客さまや社会へ新たな価値の継続的な提供**をしていきます。

- 開発組織としては、**変化の早い市場に対応するためにサーバレスも活用**していきたいと思います。
あとは、**情報システム部全体でシステムをモダナイゼーション**ですね。SoEだけでなくSoRも含めて最適化する必要があるので、APIの拡充、SoRの標準技術移行も行なっている最中です。

<img width="1054" alt="_Session_06__NTTドコモ情報システム部におけるGKE導入事例　～パーソナルデータダッシュボード開発～_-_Google_スライド.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/145685/40c989aa-549d-502e-7f29-b00507139897.png">


本日の講演のまとめです。

- 当社情報システム部では**SoEとSoRを分離**し、SoEはアプリケーションをいかに早くできるかを追求し、**アジャイルな開発体制を築いています**
- SoRとの連携は**制約の中で最善なアーキテクチャを見つける**ことが大事
- エンジニアリングリソースを持たないエンタープライズ企業での工夫点
    - **内製開発組織に近づける環境づくり**が第一歩
    - パートナーと一緒に**社員自身のスキル向上**も必須
- Biz含め**会社全体でアジャイルなチーム**を作るのが次のステップ

エンタープライズ企業でこれからチャレンジしようとしている方へ、少しでも前に進むきっかけとなる話ができていたのなら嬉しいです。本日お話した話はGoogle社の事例インタビュー記事にもしていただいたので、もしよろしければこちらもご覧いただければと思います。2月中旬公開予定とのこと。

## あとがき
登壇後、多くの方に声をかけていただいたりTwitterでもコメント頂いたりと反響が大きく、みな同じ悩みを抱えながら前に進もうとしているんだなぁと実感しました。発表の中でも述べたように、エンタープライズ企業で新たな取り組みをしようと思うと壁やハードルが多いのは否めません。ただその中でも模索しながら前に進むことが大事であるし、大変だからこそのやりがいもあるのかなと。

今回のカンファレンスでは主にGCP周りについてお話ししましたが、今回のプロダクト開発は他にも話すネタはたくさんあるのでどこかでいつか話してみたい。

- ステークホルダーが多く意思決定のデザインに超絶苦労した話
- Bizと一緒にワークショップ形式で仕様を徐々に固めていった話
- ウォータフォールで開発するSoRと足並みを揃えて無事サービス開始までこぎつけた話
- LeSSという大規模スクラムを組織として初導入した話
- アジャイルにおける品質の考え方、担保の仕方を真面目に考えてみた話

最後に、チーム発足からこれまでに関わってくれたメンバー全員に感謝です。何もないところから組織を一緒に作り上げてくれたみなの頑張りをこうやって日の目を見させることができて本当に嬉しいです。僕らのやるべきことはいいプロダクトを作ることです。まだまだやることは盛り沢山、引き続きチャレンジしていきましょう。

## IT系メディアによるレポート
[「Google Cloud Anthos Day」ユーザー事例セッションレポート@クラウドWacth](https://cloud.watch.impress.co.jp/docs/event/1232998-4.html)