内製開発とパートナー厗創体勧で実勶する awsファーストへ … · 2019. 7....

Copyright© NTT SMILE ENERGY,Inc All Rights Reserved.

内製開発とパートナー共創体制で実現するAWSファーストへのLift&Shift

株式会社NTTスマイルエナジー価値づくり本部システム開発グループ

林⽥悠基鷲塚仁

Copyright© NTT SMILE ENERGY,Inc All Rights Reserved.1

株式会社NTTスマイルエナジー

林⽥悠基（ハヤシダユウキ）

価値づくり本部システム開発グループ担当課⻑

所属

キャリア

業務内容

⾦融系SE、研究開発、⺠需・公共SEを経て2014年7月にNTTスマイルエナジー出向2018年4月より現職

・開発/運用チームのマネジメント・社内外のシステム開発、運用全般・新サービス、新技術の調査及び評価

自己紹介


本日のお話

2

AWSを活用する事で組織が変わった話


本日のお話

3

組織を変えるためにAWSをどの様に活用したか、の話


本日お伝えしたいこと

4

AWS導入は単なるコスト削減やシステム改善に非ず開発・技術部門を変えるきっかけに活用すべし

NTTスマイルエナジーは面白いことやってる会社です


1. 会社概要2. AWSとの出会い BEFORE / AFTER3. NTTスマイルエナジー流内製開発＆パートナー連携術4. 大規模なLift&Shiftプロジェクトから得た学び5. 変革を遂げた開発チーム6. まとめと今後の展望

5

本日の内容


会社概要


NTT⻄⽇本の通信技術とオムロンの制御技術により、エネルギー情報と通信を融合したサービスを提供し、来るべき「スマートグリッド社会」の実現に貢献するため、2011年6月にNTTスマイルエナジーを設⽴。

7

NTTスマイルエナジーの成り⽴ち


平成30年10月1⽇時点会社概要


企業理念


７つの⾏動指針

10


②再エネの最大限導入

①⻑期安定稼働

③系統安定化

・遠隔監視サービス・メンテナンスサービス

家庭向けPPA

・出⼒制御・蓄電池調整⼒

・太陽光無償設置プロジェクト・蓄電池制御サービス

エネルギーIoTサービス

産業住宅

企業 etc.

学校ＰＶブロックチェーン

④CO2削減価値流通

⑤P2P電⼒流通

家庭オフィス（ＶＰＰ）

AI

＜5万件、1.5GW＞ご縁ソーラーPJ＜53基、3.5MW＞＜8,000設備、27万kW＞

O&M

「通信・クラウドと制御」による環境・エネルギーサービスを展開


オフィス風景


AWSとの出会いBEFORE/AFTER


御社の「開発・技術」部門はどんな業務をされていますか︖


組織の役割ビジネス・システムの「企画」に特化し、

開発は強みのある協業パートナーに業務委託基本的に自前主義（スクラッチ開発）

開発体制インフラ基盤は某社クラウドを利用インフラ基盤の構築、運用は協業パートナーに業務委託アプリ開発は協業パートナー（複数）に業務委託

BEFORE

NTTスマイルエナジーにおける開発部門の役割


市場変化にサービスレベルが追従できない実開発はほぼパートナー頼みのため、

QCD（品質・コスト・納期）のコントロールが難しい「とりあえず新しい事やってみる」がほぼ無理

ツギハギ改修の積み重ねでシステムトラブル＆運用負荷増大都度改修が招いた複雑怪奇なシステム構成属人運用＆ノウハウの非継承（やってる時間がない）トラブル続きで運用担当者の負荷増改修デススパイラル

抱えていた課題


これ、もう無理ゲー


失意の我々にそっと微笑みかけるAWSとの出会いin AWS SUMMIT TOKYO 2016


AWS SUMMIT TOKYO 2016での衝撃①DJでアゲアゲな基調講演!!!


AWS SUMMIT TOKYO 2016での衝撃②

壇上で切腹を豪語する某社代表のプレゼン︕


AWS SUMMIT TOKYO 2016での衝撃②

使えそう＆挑戦してみたい公開事例が多数︕


というわけで

いつ変わるんですか︖今でしょ︕︕︕


組織の役割AWSを活用した内製開発をやれる組織になる︕パートナーと技術的に対等な関係性を築けるレベルになる︕自前主義から脱却する︕

開発体制AWS中心の自社運用体制AWS採用前提の開発体制（基本的に例外を認めず） SRE（Site-Reliability-Engineering）チーム発足

AFTER

まずはこう変わる︕という⽅向性を決めました


どうやって実現したか︖


NTTスマイルエナジー流内製開発＆パートナー連携術


理想と現実のギャップ

26

AWS使って開発︕

理想現実

パートナー企業と対等に議論を交わして開発︕

スクラッチ開発は不要︕

AWSよくわからない orz

今まで任せっきりなので今更対等になれるの︖︖︖

社内の要望を完璧に実現するには

スクラッチ以外手段なし


やっぱ、無理ゲー︖︖︖


そんな時にこそAPNパートナーにまず相談︕


良いパートナー企業探しでやった事

29

パートナー企業主催のセミナー参加

有志の勉強会に参加

JAWS-UGのイベントに参加

※AWS主催のイベント参加も有益


パートナー企業との協業⽅針

30

一方的に要望を伝える関係にしない→一緒に開発する仲間と捉えた信頼関係の構築

パートナーの良いところから学ぶ→良いやり⽅やツール等はどんどん真似させてもらう

パートナー企業のメリットに繋がる仕事にする→初事例や実績につながるもの、

他社への紹介に繋がる、等

共創


組織変革の３ステップ

31

① ホップ社内のAWS事例（難易度︓低）積み上げAWS社内布教活動

※NTTスマイルエナジーの場合

② ステップ難易度︓中（Lift施策）にチャレンジ実績報告による経営層の理解浸透

③ ジャンプ内製開発の動きを加速（チーム設⽴）難易度︓⾼（Shift施策）にチャレンジ


状況「AWS」に興味があるのは自分＋１名のみ開発チームの内製開発経験は皆無

この時は私＋１名のみでPoC等を地道に推進

①ホップ

施策（３ヶ⽉程度）① AWS関連ニュースの共有

︓社内AWSファンの醸成② 小規模PoCの実施

︓パートナー企業のサポートを有効活用③ PoC施策の実績共有

︓やった事だけでなく、従来と何が違うかを共有


BEFORE AFTER

何が違うの︖変える必要あるの︖

AWSって...楽しそう使ってみたい開発したい

変化が見えてきたところで ②ステップへ

徐々に変化する開発メンバー


状況 AWS利用の意欲はあるが、⾊々わからなくて不安経営陣のAWS理解は「従量課⾦で⾼い」「使い勝手悪い」

②ステップ

ベストプラクティスを真似る施策がベスト施策（３ヶ⽉程度）

① AWS適用施策の検討とアサイン︓⽅向性等はこちらで決定、開発は担当者に一任

② 開発者への積極的なサポート︓APNパートナーとの協業＆積極的なサポート

③ 経営陣への定期的な実績報告︓AWS施策とコストに関して適宜報告


AWSだと⾊々できるかも︕ 自分で⾊々できるのでやりがい・楽しさを感じる︕

開発者・経営陣ともに変化が見え始めたところで③ジャンプへ

AWSは経営環境を変える可能性があるのかも︖

自信がつき始める社内開発メンバー&認識が変わる経営陣


状況社内での活用事例が両手ぐらいはある EC2/CLB/S3/RDSぐらいなら少しは使える従来システムの置き換え程度の開発経験しかない

③ジャンプ

施策①SREチーム設⽴②３つの挑戦的施策を企画・実⾏（i〜ⅲで約1年程度）

i. MS SQL Server 2008R2→Amazon Aurora(MySQL）へのDBマイグレーション

ii. CloudEndureによるVPS→EC2移⾏iii. サーバレスによる新規サービス開発


SRE (Site-Reliability-Engineering)チーム設⽴

37

チーム設⽴の目的

とにかく高速に改善を回してサービスの質を向上する

属人業務を排除し、誰がやっても同じ結果が出せる様業務プロセスを標準化する

自社対応を可能とし、外部依存による品質・スピード低下を改善する

AWSを活用する事で対応が自社完結可能に


MS SQL Server2008 R2

実施当時は日本国内でもかなり珍しい

DBマイグレーション事例

ⅰ) Amazon Aurora(MySQL)へのDBマイグレーション


自社単独で完結した事例

ⅱ) CloudEndureによるVPS→EC2移⾏


初めてのサーバーレス開発事例

ⅲ) サーバレスによる新規サービス開発


（補足）パートナー企業から学ぶ

41

パートナー企業の取り組みで良いものはどんどん真似て取り込み＆カスタマイズして運用︕

Slack導入＆活用⽅法

backlog活用⽅法

リモートワークの導入 etc...


AWSを使うことに間違いはない︕

AWSを使えば自分たちで開発を最適化できそう︕

社内のAWS利用が確固たるものとなったところで④更なる高みを目指して

更なる事業拡大にAWSは不可⽋なものだ︕

AWS活用が自社ビジネスを変えるという確信


現在取組中

①高速開発を実現する開発環境の整備︓CI/CD環境の整備と開発ルールの策定

②開発委託におけるアーキテクチャ検討への関与︓共にシステムを開発する「共創パートナー」へ

③DevSecOpSの推進︓DevOpSは取組が出てきた

これからはDevSecOpSで更に⾼度で効率的な開発へShift︕

④更なる⾼み


① 開発メンバーのスキルアップ︓AWS以外の分野への興味と学習意欲の向上

② 開発スピードの向上︓AWSの更なる活用による開発期間の短縮

③ 開発稼働の省⼒化︓マネージドサービスの利用による開発省⼒化

CI/CD環境の整備による効率化

社内に起きた変化


そして大規模なLift&Shiftプロジェクト

を進⾏中


大規模なLift&Shiftプロジェクトから得た学び


株式会社NTTスマイルエナジー

鷲塚仁（ワシヅカヒトシ）

価値づくり本部システム開発グループ

所属

業務内容・SREチームリーダー・社内外のシステム開発

自己紹介


このパートのお話

• AWS移⾏という大規模テーマを、協業パートナーと内製開発チームでどのように協⼒、完遂させたか

• 本プロジェクトにより、現状システムの課題をどのようにして解決したかとそこから得た学び

48


AWS移⾏への背景と課題


AWS移⾏を決めた背景

• 新機能リリースのスピード向上、コスト削減• ロールバック等におけるストレスが無いリリース実現• 従来型の保守運用業務からの解放

（サーバ、DBのストレージ管理、バックアップ管理）

50

性能改善

運用改善

• データ計算処理時間性能• Webサイトの表示時間性能• DB処理性能


AWS移⾏を決めた背景

一番実現したい事

もっと新サービス開発に注⼒できる開発体制を築く︕︕︕

51


AWS移⾏によって実現される事

• サーバ管理不要– RDS(Aurora)、Lambdaを活用し、サーバ管理から解放

アプリケーション開発や新サービス検討に集中

• リリースのストレスから解放– CloudFormation、CodePipeline、CodeBuildを利用することで

CI/CD環境を構築、リリースのストレスから解放

• リソース調達不要– センサ増加、周辺サービスの拡張に対して、スケールアップやス

ケールアウトで柔軟に対応

52


現状システムの課題• 課題① : データベース管理負荷増

– 複数のデータベース管理、I/O負荷、ストレージ不足の発生。データ抽出・解析、リリース等にも常に配慮が必要な状況。

• 課題② : 密結合なシステム– システム全体への影響を考慮したリリース計画の検討が必要。

• 課題③︓性能限界– 演算処理性能の問題で処理時間が増加し、他サービスへ影響発生。

• 課題④︓EOL問題– OSやミドルウェアのEOL問題に直面

53


移⾏⽅針• AWSサービスを活用したShift

– 演算の課題には、AWS Lambdaを活用– DBの課題には、Amazon Auroraを活用– データ移⾏は、AWS Database Migration Serviceを活用

• 無理なShiftはしない（一部のLift）– 課題解決しなくてもよいサーバ群はそのまま移⾏

• PoCの実施– AWS移⾏の不安箇所の事前検証– 課題の早期発⾒と解決– 新しいOSや新バージョンの事前検証

54


その結果・・・


収集計算保存活用

AWS

AWS移⾏後アーキテクチャ概要図

56

SensorSensor①

SensorSensor②

SensorSensor③

SensorSensor④

IF

IFIF

IFIF

APIAPI

AlertAlert

MailMail

Web②Web②

IFIF

IFIF

MonitorMonitor

Web①Web①


プロジェクトにおける取り組みと学び


取組①︓複数チーム間の連携

58

AWS

プロジェクト管理NSE@大阪

内製開発チームNSE@大阪

Web移行開発パートナーD@ベトナム

AWS移行インフラパートナーC@大阪

インフラパートナーB@大阪

AWSアプリ移行パートナーA@横浜

AWS技術相談AWSJ

運用パートナーA@大阪



59

AWSプロジェクト管理

NSE@大阪


Web移行開発パートナーD@ベトナム

AWS移行インフラパートナーC@大阪

インフラパートナーB@大阪


AWS技術相談AWSJ

運用パートナーA@大阪

「課題・タスク」は、Backlogのチケットで管理

「コミュニケーション」は、TEL & Slack。

「会議」は、TEL会議のほか、HaungoutMeets/Skypeを利用して実施「成果物」は、

BacklogのGit & Wikiで管理

AWSサービスは、各ベンダーさまに必要な権限はIAMで管理



• 取り組み事例– Backlog, Slack, Hangout Meet, Gitなど、コラボレーションアプリを活用– Amazonサービスの利用には、各ベンダーさまに対し、適切な権限をIAMで付与する

60

ツールの使い方よりももっと、大事なことが・・・



• 信頼関係が最も大事︕︕– 特に緊急性、致命的な問題を要する、「トラブル発⽣時の報告」、「課題の共有」、「仕様変更／コスト増の相談」など

61

【学び①】複数チーム＆ロケーションを跨る開発において

ロケーションに縛られないチームとしての一体感の構築が重要︕


取組②︓バッチ処理(C#)からLambda(Python)への切り替え

• バッチ処理の課題– センサ数の増加に伴い、現⾏システム（アプリ）が処理性能の限界に。

特定のバッチ処理時間が当初の3倍︕︕︕

• 解決策の方向性– センサ数増加に影響しない仕組みを実現しつつ、

今後の改修も迅速かつ簡単に実施可能なCI/CD環境も実現させる︕

62

Pythonを使ったAWS Lambdaで解決！


鷲塚



AWS技術相談AWSJ

システム責任者兼プロジェクト責任者

説得

お願い

お願い

相談説得とAWSJから得た技

術検証を依頼

OK

OK

OK

OK



収集計算保存活用

AWS64

SensorSensor①

SensorSensor②

SensorSensor③

SensorSensor④

IF

IFIF

IFIF

APIAPI

AlertAlert

MailMail

Web②Web②

IFIF

IFIF

MonitorMonitor

Web①Web①Pythonで

実装



1. 処理性能が向上– 計算処理性能の向上・・・従来処理時間 1／20 に向上

2. デプロイにおける制約からの解放– 他システムの状況を配慮する必要がなくデプロイ可能

3. 内製開発チームのスキルとモチベーション向上– 新しい技術への挑戦によりPython言語を習得– CI/CDのメリットを実感し、さらなる改善に向けて自ら⾏動

65




• 初めからShiftを恐れない︕• 言語が変わるなど、開発者にとっては苦労が多いのも事実だが、得られる

ものも多く、メリット、デメリットを比較してバランスよく判断すべし

【学び②】新技術への切り替えコストが高くとも

得るものが多い場合もある（切り替えをしやすい仕組みがAWSにはある）


まとめ

AWS移⾏プロジェクトを通じて、

の重要性を改めて気づかされた。

67

同じ目的に向けたチーム作り

新しいことに挑戦する勇気


まとめ

68

AWSを活用する事で...

1. 注力するべき問題のみフォーカスできる様になる。2. 新しいことに挑戦する意欲を与えてくれる。

AWS

コストスピード

拡張性セキュリティ


変革を遂げた開発チーム


変革を遂げた開発チーム

70

AWSを活用した（一部）内製開発が当たり前パートナー提案を鵜呑みにせず、

こちらからも提案・議論し、より良いものを作っていく姿勢他社の先進事例を積極的に取り込み、

自前開発にこだわらない合理的な姿勢新しいことへのチャレンジを恐れない姿勢


まとめと今後の展望


まとめ

72

新しい事にチャレンジしやすいAWSだからこそ組織改革のきっかけに活用すべき

AWSを十二分に活用するなら（少しでもいいから）自社開発・運用を目指せ

リソースの限られる中小企業は「クラウドの選択と集中」で取り組むべし

AWSは関連情報が多すぎるので、APNパートナーやAWSサポートをフル活用すべし


今後の展望

73

AWSの活用をさらに進め、世界一の分散型再エネシステム

技術者集団を目指します︕


さいごに


・服装自由・オフィス（北浜・淀屋橋スクエア）・社会貢献、イベント多数・・・

電⼒業界に革命を起こす仲間を募集中︕

詳しくはNTTスマイルエナジーHPへhttps://nttse.com/

内製開発とパートナー厗創体勧で実勶する awsファーストへ … · 2019. 7....

Documents