🐈

Google Cloud 内製化 Day : Day 1

2022/08/29に公開

Google Cloud

tech

基礎からわかる内製化　～内製化が重要な理由と実現方法について～

顧客行動の変化

PC、スマホ所持率
時間の使い方（新聞→スマホでYouTube）
消費行動全般の変化（体験にお金を出す）
新型コロナウイルス

行動の変化が企業に影響を及ぼす

既存事業が伸び悩む→新規事業へ
将来を見越した収益源を作り出す必要

⇒良いソフトウェアサービスを継続的に提供できることが企業の競争力の源泉に
初回リリースは「ゴール」ではなく「スタート」

４つのキーメトリクスを見ていけばよい

リードタイム
デプロイの頻度
サービス復旧の所要時間（MTTR）
変更失敗率

つまり、顧客に「素早く」「頻繁に」「安定的に」価値を届ける、問題があれば素早く復旧する能力が求められる
＝安定した速いフローを重視し、実現しなければならない

従来の開発スタイル（遅く安定しない）

設計チーム→開発チーム→テストチーム→運用チーム

受け渡しの回数が多く遅くなる
間で情報が欠落していく
間違っているとわかっても止まれない
責任感の欠如を誘発する

「素早く」「頻繁に」「安定的に」価値を届けるには？

アジャイル＝頻繁にサイクルを回す開発の方法
DevOps＝頻繁にサイクルを回す組織的取り組み

開発と運用の分断をなくす

継続的〇〇＝頻繁にサイクルを回すリリースの方法

継続的インテグレーション
継続的デリバリー
継続的デプロイ

クラウド＝頻繁にサイクルを回すインフラ

リードタイムの激減
ビジネスの不確実性に合わせやすく
無駄な初期投資削減、柔軟な変更
「クラウドファースト」がデフォルトに

外部のパートナーに協力してもらうのではだめなの？

チームの重要性

（天才を除いて）１人では物事を成し遂げることはできない
「人の集まり」でなく「チーム」として機能している必要がある

成果を出せるチームとは？

チームが専任していること

マルチタスクによる弊害を防ぐ（パフォーマンスの低下、ストレス）
リードタイムの長期化を防ぐ

チームが安定していること

チームを機能させるには時間がかかる（形成期、混乱期、統一期、機能期、解散期）
人の入れ替えはゆっくり少しずつ（毎回チームを作っていては勝負に勝てない）

チームでやり方を決められること

チームの成熟度によって、適したやり方は変わってくる
過度な標準化やプラクティスの強制はパフォーマンスを下げる

チームが継続的に学習していること

クロスファンクショナル（様々なスキルの人材を抱える）なチームである必要がある
チーム内のボトルネックを減らすことにつながる
継続的な学習は仕事の一環

チームに適切なミッションが与えられていること

チームの効果性の向上には、仕事そのものまたはその成果に対して目的意識を感じられる必要がある

なぜ内製か？

⇒専任していて、安定していて、自律的にやり方を改善し、継続的に学習しながら、ミッションの達成を目指すチームは売っていない

内製化の始め方

少数のチームから始め、効果を見ながらスケールしていく。最初は有識者の支援を受けるのもよい
チームは壊さず、新しく作っていく（最初のチームがCoEとなり新しいチームを支援）

外部から内製支援を受ける場合

支援の目的はスキルトランスファー（プロセスの習得が目的）

内製化を進める領域

社内業務の効率化＜競争領域（ソフトウェアが競争力の源泉である以上、そこでこそ取り組む価値がある）
基盤チーム、技術支援チーム、特定要素技術のチーム＜顧客に直接価値を届けるチーム（フローが重視されるから）

アンチパターン

いきなり大きく始める
社内受発注構造
単なる常駐や準委任契約

Cloud Runと周辺システムで、アプリの内製化を加速させていくために

内製化を始める際に気をつけるポイント

SRE（サイト信頼性エンジニアリング）プラクティスの実践

Googleが提唱しているSREという手法は主に以下でまとめられる。

小さく始めて、繰り返す...小さいチームからPoCを始め開発サイクルを回す
チームを支援する...社内のスキルアップ、チームの新規採用・拡充といったイネーブルメント戦略を検討する
学んだことをスケールする...チームで学んだことをコミュニティや組織全体に広げる
データドリブン型のマインドセットを具体化する...開発しアウトプットしたものからフィードバックを得て、新しい開発に繋げる

運用体制に目を向ける

では、内製化を始め運用体制に目を向ける際に、どのようなことを考えればよいか？

既存システムが大きい場合、リスクが大きい→小さいスコープを決めて始める
どういったスコープがよいのか→費用対効果の高い業務カットをマイクロサービスとして始めるのが良い

運用可能な内製化を実現するために

しかし、実現する上で以下の懸念点が挙げられる。それらは次のように解決すればよい。

自社リソースの体制では、開発と運用が難しい→自社リソースのできる範囲で、内製化メリットのある範囲で小さく始める
実装や構築の専門スキルが不足している→マネージドサービスを活用し、業務フォーカスをする
ビジネスにフォーカスしたい、フォーカスすべきでない範囲の工数を省きたい→サーバーレス環境を活用し、運用部分を人でなくクラウドに任せる

これらは、アプリケーションのモダナイズ、Cloudの活用に繋がってくる。

Cloud Runの活用

Google Cloudでは5つのComputeプロダクトを用意している。

Compute Engine...仮想マシン
Google Kubernetes Engine...フルマネージドKubernetes
Cloud Run...サーバーレスコンテナ実行環境
App Engine...サーバーレスアプリケーション実行環境
Cloud Functions...サーバーレスFunctions as a Service

このなかで、内製化においてはCloud Runを使用することをお勧めする。
理由としては、以下の2点においてバランスが良く、様々なユースケースに対応できるからである。

柔軟性...１から順に柔軟性が高く、やりたいことがチューニングできる
抽象度...５から順に抽象度が高く、インフラの管理や考えることを少なくすることができる

Cloud Runについて

先ほどの説明の通り、Cloud Runはサーバーレスのコンテナ実行環境である。
特徴として以下の点が挙げられる。

コンテナをデプロイするだけで外部から到達可能なURLが発行される
自動的にスケールアウトし、大量のリクエストを捌くことができる
Eventarcと連携しイベント駆動で処理を実行できる
HTTP/2、WebSocket、gRPCへの対応
高度なトラフィック管理が統合

アプリのデプロイなどの流れ

実際にアプリをコンテナ化しCloud Run上でデプロイする場合、このようなプロセスが考えられる。

Build...コンテナイメージをビルド
タグ...タグで各成果物を管理
Push...レジストリへイメージをプッシュ
テスト...イメージが期待通りであるか検査
デプロイ...クラスタへデプロイし動作確認
変更監視...ソースファイルが変更されたらビルドして再デプロイ
ログ監視...アプリケーションが出力するログをリアルタイム監視
メトリクス監視...メトリクスを継続的に監視、アラート

ローカル環境におけるコンテナ開発

VS Code、IntelliJ、Cloud Shellエディタに対応しているプラグインとして、Cloud Codeというサービスが提供されている。
このサービスを使うことで、Cloud Runをローカルでエミュレートすることができる。

アプリがビルドできて確認出来たら、コンテナイメージをデプロイする

デプロイ手順は以下のようになる。

Dockerfileを作成
ソースコードに合わせ、インストールなどの手順をDockerfileに定義
CIパイプラインを記述（Cloud Build、Jenkins、etc...）
a. docker buildコマンドで、コンテナイメージを作成、タグ付け
b. docker pushコマンドで、コンテナイメージをレジストリに登録
gcloud run deployコマンドや、terraformなどで該当イメージをCloud Runへデプロイ

コンテナのビルドの別の方法として、Buildpackesというオープンソースを利用する方法がある。こちらを使うと、Dockerfileを作成、運用する必要がなくDockerfileの定義が簡素化される。だが、サポート言語は限られている。

また、Cloud Runのコンソール画面からボタン１つでCloud Buildを利用したCI/CDと統合することが可能であり、先ほどのプロセスの「1. Build」～「6. 変更監視」まで実現可能である。
さらに、Cloud RunにはCloud LoggingやCloud Monitoringなど運用に必要なプロダクト、SREの思想に基づいたSLOモニタリングも統合されているため、「7. ログ監視」「8. メトリクス監視」

リフトからシフトへ！サーバーレス環境構築の内製化への取り組み

京セラドキュメントソリューションズ株式会社　林　秀樹　さん

ソフトウェア開発部門のインフラ環境の構築・運用において、2020年からGoogle Cloud（GCE）を利用していたが、多大な工数を要していたため、Google社にサーバーレス環境の構築、内製化への取り組みを支援してもらった。

モダナイゼーションへの取り組みを決めた背景

以前は、オンプレミス、プライベートクラウドでシステム環境を行っていたが、

サーバー稼働数が多いこと
それを構築・運用するためのコストが大きいこと
国内のみで構築していたDR環境もグローバル開発を進める上で課題になっていたこと

を踏まえ、2020年にパブリッククラウドへの移行を完了→かかるコストを3割削減
しかし、デバイスの物理的な管理工数は削減できたが、

資産管理が大変
作業工数がかかる
セキュリティの維持・強化に工数がかかる

という課題が残っていた。そこで、ソフトウェア開発環境のモダナイゼーション検討、その対応としてサーバーレス化を行った。

サーバーレス化をどのように進めていったか

まず、出てきた課題は以下である。

システム運用が煩雑で管理工数も多い
セキュリティ管理工数が多い
スピィーディにシステム提供できない

これらの解決のため、サーバーレスの内製化を開始。
しかし、いざ実施しようとしても、実現方法がわからなかった。

IaaSをどうやってサーバーレス化するの？
新規システムをどのようにサーバーレスで構築するの？
誰に何を聞いたらいいの？何を学習したらいいの？

そこでGoogle社に相談したところ、ワークショップ（Tech Acceleration Program）を開催することが決定した。

TAPの実施と結果

TAPの実施により、以下のことがわかった。

これまでの開発手法をサーバーレス化する手法
必要となるスキルのシフトが必要であること
具体的なサービス作成方法
システム間連携の方法
アーキテクチャ決定の仕方
部分開発の方法
新体制が必要であること

成果物としては

全体のフローとテンプレートの選択
動作させるソースコード
ワークフローとしてのスクリプト

が挙げられ、バックエンドのプロトタイプとしての動作確認まで完了した。
しかしこれらは途中の段階であり、すべきことはまだたくさん残っている。

今後の目標

今年度...システムのシフトだけでなく、体制、スキルセットのシフトの実施
来年度...新規システムはサーバーレスで構築

これらを達成しクラウドネイティブを充実させることで、高セキュリティ、高品質、低コストを実現していく。

Google の研究結果から考える内製化のための Tips

Google Cloud アプリケーションモダナイゼーションスペシャリスト塚越啓介さん

内製化を始める際におすすめなプラクティスを、リサーチ結果から3つ紹介する。

良いドキュメントは生産性を向上させる
優れたチームの特徴は自動テスト
怒られることでパフォーマンスは低下する

1. 良いドキュメントは生産性を向上させる

これは言い換えると、ドキュメントをきちんと書いて共有することで、社内に優れた情報が早く伝搬するということである。よって生産性が高くなる。
具体的には、質の高いドキュメントを作成しているチームはそうでないチームに比べ2.4倍も開発効率が高い。

では、質の高いドキュメントとはどのようなものか

それは、以下の4つを満たすものであると考える。

読み手の目的を達成できる
正確かつ最新である
シンプルで読みやすい
見つけやすく整理されている

質の高いドキュメントを作るのにおすすめのサービス

Google Workspaces"Cloud Search"
社内ドキュメント検索システムを簡単に導入できる
Technical Writing Courses
技術ドキュメントの書き方の学習できる
Design Doc
スコープや目標など、ソースに書かれない内容を盛り込みわかりやすいドキュメントを作成することに役立つ

2. 優れたチームの特徴は自動テスト

リサーチより、ハイパフォーマンスなチームほど自動テスト、自動ビルドを実現している（該当チームのうち、自動テストは9割以上、自動ビルドは8割以上）。

デベロッパーがテストに関与することが重要

リサーチでは、デベロッパーが次のような場合にパフォーマンスが向上していた。

一連の自動テストの作成、保守を担当
承認テストの失敗を簡単に修正できる

逆に、関与していないと次のような問題が生じる。

頻繁にテストスイートが破損した状態になる
当然コードの変更に伴いテストの変更も必要であり、テスト担当チームのテスト修正完了までビルドパイプラインが破損した状態になる。
デベロッパーが、テストしにくいコードを生成している
テストを考慮せずコードを書きがちになるので、コストとメンテナンスの手間がかかる。

継続的テストの実装方法

では実際どのようにテストを実装すればよいのか。２つ挙げる。

単体テスト
1つのメソッド、クラス、関数を単独でテストする方法。コードより先に単体テストを作成するテスト駆動型開発(TDD)もよい。
承認テスト
成果物のテスト。

3. 怒られることでパフォーマンスは低下する

チームのパフォーマンスの研究結果から、成果を出せるチームと出せないチームの違いに以下が挙げられた。

平等な発言機会
全員が平等に話すチームの方が、常にリーダーや一部のメンバーのみが話すチームより、集団知能が高かった。
ソーシャルセンシティビティ
良いチームは、非言語的情報を直感する能力が高かった。困っているメンバーへのサポートが平均以上だった。

これらより、心理的安全性を高めるべきであることがわかる。

心理的安全性を高める行動

「心理的安全性を高めるためにマネージャーにできること」より、以下の5点を抜粋した。

積極的な姿勢を示す
理解していることを示す
対人関係において相手を受け入れる姿勢を示す
意思決定において相手を受け入れる姿勢を示す
強情にならない範囲で自信や信念を持つ

DX 推進に必要な「内製化」を加速させ、ビジネス変革を生み出す打ち手とは

伊藤忠テクノソリューションズ株式会社 Buildサービスサービス長　神原宏行さん

DXへの取組みに正解はない。だが取組むべき課題と現実的な"打ち手"は存在する。
最近よくあるお客様の状況を踏まえながら必要なサービスの紹介をするとともに、以下の3点についてみていく。

なぜDXに取組む必要があるのか
多くの企業が直面している状況について
継続的な変革に求められる取組み

1. なぜDXに取組む必要があるのか

結論から言うと、売れるビジネスを作るためでなく、ビジネス環境の激しい変化に対応できる力を身につけるためである。
「今の」製品・サービス・ビジネスが「10年後」も変わらず売れているか？
その問いに答えるために、守りのDXだけでなく攻めのDXに取組む必要がある。

ソフトウェアが人の体験をコントロールする世界

これはプライベートでもビジネスでも言えるが、現在、人はソフトウェアによって自分のなすべき行動を把握したり選択をしたりしている（目的地を調べる、など）。
これより、ビジネスにおいては

ビジネスの競争力≒プロダクトの開発力

であり、さらに言うと、

作って終わりでなく常にアップデートする

これらが必要であり、そのためのマインドセットやスキルを内製化していくことが重要となる。

2. 多くの企業が直面している状況について

現在、多くの企業が考えることや足元硬めが先に来て変革がスタートできていないという状況である。これまでの常識では

期日までに終わらせるようにFIX
失敗しないように事前計画
事前定義した結果→予算と期間

であった。多くの企業、組織、個人の経験が推進のストッパーとなってしまっている。これからは

終わらせないように継続UPDATE
早く小さく失敗するために、とりあえずやってみる
予算と期間→やってみた結果

と考える必要がある。

3. 継続的な変革に求められる取組み

継続的に変革をしていくために取るべき行動とは、今すぐ小さく実行して大きく育てる、そしてプロダクト開発力を自らの力にしていくことである。
新事業≒新プロダクト開発の段階的スケールは

知る・体感する
意味を定める
助走をつける
走り続ける

となる。

build service

とは言われても、実際に始めることは難しい。
そこで、伊藤忠テクノソリューションズでは、お客様のデジタルビジネスを探索・実装・発展し内製化を支援する伴走型テクノロジーコンサルティングサービスを提供している。
お客様自身でプロジェクトマネージメントできるようにするため、まず

ソリューションオーナー
ソリューションアーキテクチャー
エクスペリエンスデザイナー

の3人がクライアントチームに合流し、どのようなものを作るか一緒に定義したのち

ソフトウェアエンジニア
クオリティエンジニア
デブオプスエンジニア

がデリバリーフェーズで合流し、開発をサポートする。

Accelerate to build

まず必要なことは

プロダクト戦略...どんなプロダクトを作っていくのか
エクスペリエンス戦略...どんな体験をお客様にしていただくのか
アジャイル推進戦略...どんな方法でそれを推進していくのか

を理解し戦略を立てること。
よくあるアプローチとして、ダブル・ダイアモンド・アプローチという手法がある。これは、

課題やユーザーが不明確な状態
取り組む課題が特定されている状態
検証内容が明らかになっている状態

の１から２、２から３を発散・収束を繰り返し行ってアイデアを洗練させていくデザインプロセスをとるものである。
このような

Discovery

プロダクト構想を多角的な観点から検証し、開発実行への道筋をつけるフェーズ。
主に次の3つのステップで進める。

LEARN
IDEATE/DEFINE
PLAN

具体的には、これらを図っていく。

どのようなプロダクトを作るのか
最初のMVP定義やそのためのバックログ
予算や体制規模はどのくらいにするのか

Delivery

継続的なリリースを速いスピードと高い品質でいかに提供するかに焦点を当てるフェーズ。
次の3つステップで進める。

AGREEMENT
BUILD & TEST
RELEASE

いわゆるアジャイル開発の段階に入っていく。ここでは最初のMVPに到達することがゴールである。

ここで重要なのが、ディスカバリーチームとデリバリーチームを繋げるということ。
ここが分断されていると、理想と実装の相違などが起こってしまう。
なのでここでは、「考える」と「作る」をバランスよくできるよう、ディスカバリーチームがそのままデリバリーチームとなる。

Transition

お客様メンバーが主体の体制へ移行していくフェーズ。

組織的な準備
ドキュメントフォーマット計画
ナレッジ・スキルトランスファー
事務的な引き継ぎ

これらを終え、内製化支援を終了とする。

基礎からわかる内製化 ～内製化が重要な理由と実現方法について～