【レポート】情報子会社のクラウドジャーニー〜違和感ではじまったクラウド運用からクラウドネイティブまでの軌跡〜 #AWSSummit

【レポート】情報子会社のクラウドジャーニー〜違和感ではじまったクラウド運用からクラウドネイティブまでの軌跡〜 #AWSSummit

Clock Icon2020.09.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

DA事業本部の春田です。

AWS Summit Online絶賛開催中!ということで、本記事では「CUS-82: 情報子会社のクラウドジャーニー」の内容についてまとめていきます。

セッション情報

  • NRI システムテクノ株式会社 デジタル事業企画部 大甲 隼土 氏
  • NRI システムテクノ株式会社 デジタル事業企画部 座間 哲也 氏

情報子会社としてSoRシステムを運用してきたメンバーがコテコテの価値観でクラウド活用の第一歩を踏み出したものの、今までの価値観で上手く回らない疑問から「もっとクラウドを活用できるのでは?」と思い立ち、少しつずつクラウドネイティブな仕組みづくりを始めてきた、クラウドジャーニーをご紹介いたします。取組を継続的に推進するにあたって、どの様にしてクラウド活用組織への変革を、クラウド人材の育成を行ってきたのか、その取組に関しても併せて紹介いたします。

※セッション動画は以下リンク

アジェンダ

  1. はじめに
  2. クラウドジャーニー始めの一歩
  3. クラウドネイティブへの道

はじめに

  • 本日お話しする事(サマリ)
    • とある情報子会社がクラウドに触れ利用を始めたが、従来の価値観の中では上手くクラウドを使えていないのではと疑問に思う
    • より価値を引き出すための活動と、意識の変革に関する7年の活動の軌跡のお話
  • 想定している視聴者
    • これからクラウドを使ってみようと思われている方
    • クラウドを使ってみたは良いものの、使い方に違和感を感じられている方
  • 視聴しても得るものが少ない方
    • クラウドをバリバリ使って、ブイブイ言わせている方
    • 組織全体が技術マインドに溢れ、自走されている方

→ 皆様がよりクラウドを活用できる組織となる為の一助となれば幸いです

  • NRI System Technoについて
    • 創業: 1990年
      • 味の素(株)の情報システム子会社として設立
    • 従業員数: 363年
    • 業種: 情報サービス業
    • ITで顧客の事業価値向上に貢献
      • 主に味の素(株)本社向け
  • 出資状況
    • (株)野村総合研究所(NRI): 51%
    • 味の素(株): 49%
  • 2020年3月末時点

クラウドジャーニー始めの一歩

’13夏 クラウドを使ってみると、良いことがあるんじゃないかと触れてみた

  • ある日(2013年頃)お客様より「クラウドを使ってみたい」との相談があった
  • 動き出しの流れ
    • クラウドの使い方を学ぶ
    • クラウドに移行したらどうなるのか?のシミュレーション
    • クラウド移行を計画
    • 移行プロジェクトの実施
  • クラウド移行を数ヶ月・短期間でできたという話をよく聞くが、一歩一歩やっていったため約1年もかかっている
  • 最初から何から何まで全てうまくいくわけではないが、着実にすすめれば移行も完了できる

  • 移行環境
    • Amazon EC2 × 17台
    • Elastic Load Balancing × 12台
    • Amazon RDS × 3台
  • → データセンターにある物理マシン7台破棄できた
    • 仮想化マシンが稼働していたため、インスタンスの台数は増えた

→ 実際使ってみてどうだったか?

’15春 違和感を感じ始めるクラウド運用1

  • 作業実施時は手順書に基づいて作業
    • 何か構成に変更を入れる場合は、まず手順書を作り、それに沿って作業するのが取り決めだった
    • しかしクラウドの進化は速いため、頻繁に手順書の書き換えが発生
    • → 手順書を作成する意味が懐疑的になった
  • 自分たちの既存の考え方も変わっていかなければならない
  • 以下は、2014年当時の作業手順書より抜粋

’15春 違和感を感じ始めるクラウド運用2

  • 何かがあるとすぐにアラート
    • EC2インスタンスを立てたあとも、社内の監視センターで監視を行っていた
    • 何か問題が発生すると、システム運用担当者に夜中でも休日でもアラートが飛ぶ
    • オンプレでのインシデントと、クラウドでのインシデントの違いを認識できていない
  • マネージドサービスなのに、任せられない
    • セキュリティインシデントを監視している社内CSIRTが、脆弱性を発見した際に点検を指示
    • AWS側が管理してくれていることではあるのだが、オンプレの価値観のままではなかなか任せられない状況
    • 最終的にAWSサポートに問い合わせることに
  • まずはクラウド移行前に、社内が抱えるオンプレの価値観自体を、クラウドの価値観へと変えるべきだった

’15春 違和感を感じ始めるクラウド運用3

  • 憧れのオートスケーリング
    • オンプレミスではほぼ実現できない機能
    • 積極的に導入すべく検証を進めていたが、結局もともとあったシステム構成をそのまま持ち込んだ形に
    • 結果、スケーリング時のEC2インスタンスの立ち上げに30分も要する状態に
  • 何のためにオートスケーリングで、どんな価値があるのかを見定める必要がある
  • オンプレ環境をそのまま上げるのではなく、クラウドに合わせたシステムを考える必要がある

’16春 もっといいクラウドの使い方があるんじゃないかと気づいた

  • クラウド使ってるけど、なんか違う気がしてきた
    • ちょっとやってみよう
      • AWS LambdaのVPC対応が2016年2月にローンチされたのでやってみた
      • もともとはメールを受信して応答するためだけのEC2インスタンスがあった
      • それを廃止し、SES・S3・Lambdaの構成に切り替え
  • 新しい使い方を考えれば、料金も運用コストも下げることができる

クラウドネイティブへの道

’16冬 クラウドネイティブに対する不安

  • クラウド導入に伴い最新の開発手法を導入することもできるが、未知の領域やステークホルダーへの説明などに不安がのこる
  • いきなり受託開発での採用は厳しかった
    • 使ったことが無い技術を試すのにお客様を巻き込むわけには……
    • でもそう言ってるといつまで経っても使えないし……

  • はじめの一歩として、開発合宿を開催
  • 会社公認イベントで、マネージドサービスやサーバレスを使い倒すことができた
    • お客様には迷惑かけない
    • けれども「ちょっと触ってみた」ではなく「本気で開発」

  • 開発合宿で学んだこと
    • ①サーバレスアーキテクチャ
      • スモールスタート向きの課金モデル
      • 小さなチームがインフラからアプリまで一括管理
        • 普段は社内にアプリ屋やインフラ屋といった担当部署があり、その間を申請書ベースにコミュニケーションを取っていた
        • サーバレスなら、サーバー管理やネットワーク管理が最小限なため、3〜5人ぐらいのチームで完結できる点が魅力
        • 意思決定がしやすい
    • ②AWS Cloud9とモブプログラミング
      • AWS Cloud9 = クラウド上にアプリの開発環境を立てて、メンバーと共有できるサービス
      • 従来の価値観を変えるプログラマの働き方改革
        • 開発環境は各々のPCに作らなくてはいけない
        • プログラマは各々役割分担して仕事を進めるべきである
      • 一つの課題を、全員が協力して解決するという価値観が浸透

自社サービスの開発へ

  • 何度かの開発合宿やその他研究活動を通じて自信がついた
    • 次なる展開 → 自社サービス
  • NST Digital labor Service(NDS)
    • 帳票画像からOCRを通して文字起こし
    • 読み取った文字から商品コードなどの引当て
    • RPAを通じて顧客業務システムなどへ連携
  • 社内サービスのアーキテクチャとして採用したメリット
    • スモールスタート向けの課金体系
      • サービス開始直後のまだユーザーが少ない状態でもコストが負担にならない
      • 冗談でAWS利用料が月$100を超えたらお祝いする予定だったが、達成したのはサービスインしてから1年以上立った後
    • 小さなチームで一括管理
      • 迅速かつ柔軟な意思決定が出来るためで「使って頂いて気付く」問題に対処しやすい

  • 自社サービス化で乗り越えた壁
    • ①人材育成
      • モブプログラミングをベースにしたチームビルディング
      • とにかく初心者を独りにしない
        • Not 個人の進捗 But チームの進捗
        • Not 個人の責任 But チームの責任
        • Not 「自分だけ分からない...」 But 「みんなで分かろう!!」
    • ②ガバナンス
      • 自動化 = 効率化 × ガバナンス
        • 徹底した自動化は「効率化」だけでなく、ガバナンスにも効果的
      • システム管理台帳や利用申請といった従来の価値観を捨てる
        • 手作りのリソース一覧表管理
        • 手作業によるリリース
        • 画面ショットによる証跡管理
      • CloudFormationを中心とした、コード化された構成管理と徹底した自動化は必要

ついにクラウドの全社推進へ……!

  • 次のステップへ → クラウド推進組織
  • 「NRIシステムテクノ株式会社 2020-22年度中期計画」 より
    • 「アジャイルで、クラウドネイティブなシステム構築の推進」
    • 「クラウド時代のITインフラの構想、構築の推進」
  • 2020年4月
    • 「事業本部デジタル事業企画部クラウド推進企画グループ」設立
    • → 会社全体でクラウド化を押し進めていくことに
      • 安心・安全なパブリッククラウド基盤の整備・提供
      • デザイン思考型開発による開発テーマの推進と人材育成
      • 新技術の調査・研究開発
      • クラウドシステム企画化・コンサルティング支援
      • 社内外向け広報によるブランド力強化
  • クラウド推進組織で挑戦していること
    • ①「暖簾分け方式」の人材育成
      • モブプログラミング・モブプロチームをベースに、事業部メンバーに知見や価値観を社内に広めていく
    • ②AWS CDKを用いた一時作業用権限の管理
      • 構成管理だけでなく、権限周りも自動化
    • ③AWS AmplifyとReact Nativeによるモバイルアプリ開発
      • マネージドのバックエンドサービスを利用することで、誰でもセキュアなアプリ開発が可能に
    • ④AWS CDKを用いた”よくある構成”のテンプレート化
      • 効率化だけでなくガバナンスにも有効

  • こういったクラウドジャーニーを歩むことができたポイント
    • すべてのステップを会社公認で行えたこと
    • エンジニアの間にも期待と不安がある → 会社がそれをどう後押しするか?

我々でも出来ました!!次は皆さんの番です!!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.