こんにちは、SRE チームの迫田です！ 2024年6月 20日 〜21日に開催された AWS Summit Japan に参加してきましたので、今回の記事ではその時の様子や感じたことをお伝えしたいと思います！ AWS Summit Japan とは？ 当日の様子 参加したセッションの感想 エンタープライズシステムが抱える課題とマイクロサービスアーキテクチャ Amazon Aurora の技術とイノベーション Deep dive 所感など さいごに AWS Summit Japan とは？ 日本で開催される最大規模の AWS のイベントで、 AWS について学習し、ベストプ ラク ティスの共有や情報交換ができる場です。 2012年から毎年開催されており *1 、今年は 幕張メッセ にて行われました。 2024年7月5日までオンデマンド配信もされているようなので、気になる方はぜひ下記ページをチェックしてみてください！ aws.amazon.com 当日の様子 私は1日目はオンラインで ライブ配信 を視聴し、2日目は現地で参加しました。 2日目は雨が降る非常に蒸し暑い気候だったのですが、それでも来場者の方は多く、会場はとても混雑していました！ 過去、2019年に一度参加したことがあるのですが、その時よりも多くの方が参加されていた印象です。 入口に設置された AWS Summit の幕 10時開催に対して、私は大体9時半過ぎくらいには 幕張メッセ に到着していたのですが、会場前にはもう長蛇の列ができていました。 来場特典として先着の方にクッションやお弁当が配布されていたのですが、もちろん私は受け取ることができませんでした。。。 また、 AWS 認定を取得していると入場できる「 AWS 認定者ラウンジ」というものがあり、そこで認定ごとの限定ステッカーなどをもらうこともできるのですが、私が持っている「 AWS Certified Solutions Architect - Professional」のステッカーは2日目午前の段階で品切れになっていました。。。 と、個人的には欲しかったグッズなどが手に入らず悲しい気持ちになりましたが、改めて AWS が、そして クラウド が日本の中で注目を集めているということを実感することができました。 セッションやブースでは、今回の大きなテーマの1つである「生成 AI」が多く取り上げられていました。 1日目の基調講演中でも「Claude 3」が7月に東京リージョンで使えるようになることや、「 Amazon Q for Business」が2024年中に東京リージョンに提供されることが発表され、 AWS としても生成 AI に非常に力を入れていることを改めて感じさせられました。 参加したセッションの感想 ここからは参加したセッションの一部についてご紹介しながら、個人的な感想を書いていきたいと思います。 いずれもオンデマンドで視聴することができますので、お時間がある方はぜひ御覧いただきたいです！ エンタープライズ システムが抱える課題とマイクロサービス アーキテクチャ 内製化組織を立ち上げデジタル化に取り組んでいらっしゃるカインズさんの事例セッションです。 もともと個別機能開発の繰り返しと システム開発 会社への外部依存によって複雑化・ ブラックボックス 化したシステム・組織となっていたところを、システムとしては再利用部品を活用し、組織としてはビジネス部門とシステム部門が一体化したリーダーシップを取ることによって新しい開発の仕組みを推進した、という発表をされていました。 エンタープライズ における内製化のお話ということで、大変参考になりました。システムとしてマイクロサービス化して再利用部品を増やしていくことはもちろん、私としては「オーナーシップ」というところが非常に共感できました。私自身も事業会社に所属するエンジニアとして、技術スキルを磨いていくのはもちろんですが、プロダクト・事業に対する当事者意識を強く持ち、ビジネスを推進するメンバーと一心同体となってお客さまに価値をお届けすることを改めて決意しました、、、！ Amazon Aurora の技術と イノベーション Deep dive Aurora の基本的な仕組みと、近年追加された機能 (Aurora Serverless v2, Redshift とのゼロ ETL 統合, Aurora I/O-Optimized など) を紹介された AWS さんのセッションです。 高い可用性・耐久性を確保する仕組みと、マネージドサービスならではの運用性向上の機能が多数用意されており、ワークロードの特性を見極めて適切な選択をすればコストを抑えつつ信頼性の高いサービスを提供することができそうだと感じました。 一方、この「ワークロードの特性を見極める」というところが大切で、闇雲に新機能を使うのではなく、適材適所で利用することを意識しなければならないと考えております。 例えば Serverless や I/O-Optimized の方が却ってコストが高くなってしまうことは少なくないのではないかと推測しております。 私たちのサービスにも取り入れたい機能はいくつかあるのですが、事前にワークロードの特性を理解し、机上だけではなく実際に検証することで選択していきたいです。 また、その検証結果などはこのブログで紹介できればと思います！ 所感など 当日の様子でも記載しましたが、今回は本当に AI 活用が注目された AWS Summit Japan であったと感じました。 正直、最初は AI のセッションにはさほど関心がなかったのですが、基調講演や現地ブースでの活用方法や事例紹介を聞いているうちに、やはりこれらの活用もどんどん考えていかなければならないと思うようになりました。 SRE の観点でも、AIOps を活用することで出力されたログから障害分析を効率化する事例など、利用できるシチュエーションは多数あることを再認識しました。 私たちのミッションはお客さまへ価値をお届けすることなので、AI 技術についても今一度向き合って取り組んでいきたいと思います、、、！ また、個人的には久々の現地におけるイベント参加となったのですが、やはりオンラインにはない良さがあると感じました。 セッションだけであればオンラインで視聴できるものも多数あるのですが、ブースで直接お話をしたり、以前の職場で一緒だった方にお会いして情報交換ができたり、どういう製品や分野が注目されているのかを確認したりなど、現地に行かないとできないこと、わからないことがたくさんあります。 何より会場の熱気が自身のモチベーションアップにつながりました。 これからもこのようなリアルイベントには定期的に参加していきたいと考えています！ そして、平日にもかかわらずこのようなイベントに参加させてくれるような理解ある組織に所属できて本当に良かったと思います。 イベントに参加することで自身が学びを得て、結果としてお客さまや事業への貢献につながる、という思いで快く送り出してくれる上司、メンバーに改めて感謝したいです、、、！ さいごに 私たちのチームでは、ともに働く仲間を積極的に募集しています。 SRE のみならずソフトウェアエンジニアのポジションもございますので、少しでも興味をお持ちいただけましたら、ぜひカジュアル面談からご応募ください！ Application Developers www.wantedly.com SRE www.wantedly.com 最後までお読みいただきありがとうございました。また次回の記事でお会いしましょう！ *1 : 2023年までは AWS Summit Tokyo / Osaka あるいは AWS Summit Online という名称だったので、" AWS Summit Japan" になったのは実は今年からのようです。

みなさんこんにちは、EMとSREの両立を何とか頑張っている杉山です。最近は Terraform も manifest もレビューしてばかりなので、そろそろ自分も書きたい今日この頃･･･です🥺 さて、去る6月14日(土)、札幌で開催された CloudNative Days Summer 2024 に現地参加してきましたので、今回はその中でも特に印象に残ったセッションについて、感想など書いていきたいと思います！（あくまでも個人の感想です。 CloudNative Days とは？ 参加したセッション感想など クラウドネイティブな省エネサービスの内製開発で、BizDevOpsを実現する リードタイム、コストを最適化しながら回復性を求めるクラウドネイティブ戦略 次世代のクラウドネイティブ基盤、Wasmの今と未来 OpenFeature と自動生成を活用した、フューチャフラグの宣言的集約管理 テレメトリーシグナルの相関、してますか？第一原理からのデバッグを支える計装 マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由 やっぱり現地参加は熱い！ 余談 おわりに CloudNative Days とは？ 公式より以下に引用いたします。 CloudNative Days はコミュニティ、企業、技術者が一堂に会し、 クラウド ネイティブムーブメントを牽引することを目的としたテックカンファレンスです。 最新の活用事例や先進的な アーキテクチャ を学べるのはもちろん、ナレッジの共有やディスカッションの場を通じて登壇者と参加者、参加者同士の繋がりを深め、初心者から熟練者までが共に成長できる機会を提供します。 皆様が クラウド ネイティブ技術を適切に選択し、活用し、次のステップに進む手助けになることを願っています。 クラウド ネイティブで、未来を共に創造しましょう。 https://cloudnativedays.jp/ とにかく最新の活用事例・先進事例が多く、参考になるセッションが多い！！！と感じるイベントです。そして今回は CFP の倍率もとんでもないことになっていましたし、どのセッションも聞いてみたいものばかりでした。私もプレイベントに登壇させていただきましたが、本当に幸運でした･･･改めてありがとうございます。 参加したセッション感想など ここからは、参加したり録画を見たりして、気になったセッションのご紹介を！ クラウド ネイティブな省エネサービスの内製開発で、BizDevOpsを実現する speakerdeck.com 北海道ガス さんの内製開発に関する取り組みです！当チームも参考にしております！しかし当チームと違ってすごいのは、みなさん非エンジニアから始まり、実際のプロダクト開発とリリースまで辿り着いていることだと思います。こういう取り組みは、多くの企業では トップダウン で行われることが多いのではないでしょうか。しかし 北海道ガス さんは、社内の有志メンバーで勉強会・サークル（サークルってのが良いですね！）を立ち上げて、しかも IoT を活用したプロダクトをリリースしている･･･という離れ業を成し遂げており、もう本当に脱帽です。 ただ、非エンジニアでエネルギー事業の ドメイン を持った方々だからこそ、お客さま課題に対してのアプローチができたり、さらに クラウド やコンテナを活用することで、BizDevOps を実現していけたのだな〜と感じました。また、コミュニティ活動が非常に盛んなので、ここは当チームもぜひ見習いたいところです･･･！とにかくバイタリティ溢れるセッションでした！ リードタイム、コストを最適化しながら回復性を求める クラウド ネイティブ戦略 speakerdeck.com 酪農 IoT に取り組まれるエゾウィンさんの取り組みです！日本の農業を次世代に繋げる、という大きなミッションがとても素敵です。冒頭の「Reposaku は5年で解約ゼロです」という言葉が今でも印象に残っています。これは言葉にするのは簡単ですが、ユーザーニーズを汲みながら運用し続けているという、確かな実績と大変な苦労があったのだと思います。また、これまでの酪農における作業の課題を解決するために生まれたプロダクトということで、当たり前のことかもしれませんが、当チームもしっかりお客さまの不を解消するために頑張らないとな、と改めて感じました。 技術的なところでは、 AWS の API -GW 統合 タイムアウト は過去に私も苦しんだので、「これ、あるよね･･･」と共感したり、気温など北海道特有の試される大地が故、デ バイス 側にストレージを持つ構成にしていたりなど、地理的な課題も工夫を凝らして解決しているところがすごいなと思うとともに、個人的には Amazon Timestream を使っているところがめちゃくちゃ気になっています･･･！私自身、時系列 DB は扱ったことがないため、いつか触れてみたいです。 API -GW の統合 タイムアウト は先日の発表で上限緩和申請が出来るようになったみたいですね！ aws.amazon.com 次世代の クラウド ネイティブ基盤、Wasmの今と未来 speakerdeck.com 2023年度未踏IT人材発掘・育成事業で活動されている学生お二人のセッションでした！若い力が躍進されていてすごい･･･ コンテナの次は Wasm！と言われる理由について、ポータビリティや サンドボックス 上で実行されるセキュリティ面、バイナリサイズが小さい軽量さなど、Wasm の売りだったり、開発者体験にまで踏み込んでお話されているのが新鮮で純粋に楽しかったです！ただ、私も手元でめちゃくちゃメモを取っていましたが、まだ完全には飲み込めておらず・・・個人的に興味があるので、深掘りしたいところです。またセッションでも触れていましたが、どう共有するかの仕組みが成熟していない点は、実際の開発では結構クリティカルだなと感じました。このあたりのエコシステムが整ってきたら、本当にコンテナの次は Wasm！になるかもしれないですね。そして学生の方がここまで深掘りしているのを見て、自分もいろんな領域で、技術に dive deep しなければ！と熱くなりました！ ちなみに一番の収穫は WASM ではなく Wasm と略すという事実を知ったことです（ぇ OpenFeature と自動生成を活用した、フュー チャフ ラグの宣言的集約管理 speakerdeck.com 当チーム内でも最近話題になっているフィーチャーフラグについて、 サイバーエージェント さんの取り組み紹介です！ 冒頭でフィーチャーフラグの種類について紹介していますが、ここを適切に理解することが一番重要かつハードルが高そうです。特に当チームですと、他サービスに起因してフラグを削除できず、Release Toggles の推奨をいきなり守れなくなったりしそうで･･･泣　また、 SaaS がこれだけあるのも知らなかったのですが、ベンダーロックインの課題感はあると思っていたので、OpenFeature を知ることが出来たのは有意義でした！なるほど、こんなものが･･･イベント参加してこそ得られるものですね。そしてリアルな課題感からの自動生成！フラグ削除も CI で落として検知してたり・・・学びが多すぎました。環境面についての課題感も、これは当チームで取り組んだら出てくるんだろうな〜ってリアル感満載で本当に濃いセッションでした。 また、登壇者の岩見さんと、セッション後にお話できたのはうれしかったです！そこではさらにリアルな課題感も聞けましたし、当然かもしれませんが、みなさん日々の課題に向き合ってエンジニアリングで解決しているのだな、と痛感しました。私も日々挫けず、またモチベーション高く頑張っていきたいと思った次第です（増え続ける開発環境を見ながら） テレメトリー シグナルの相関、してますか？第一原理からの デバッグ を支える計装 speakerdeck.com Google の山口さんのセッションです！推測だらけの デバッグ で、飛び飛びに事象1と事象3を追いかけるような推測だらけの デバッグ はやめよう！という耳が痛いセッションでした。耳が痛い（二回目）また、ログやメトリクス、トレースをバラバラにしたときにサイロ化する弊害など、相関性をもたせる重要性についても。myTOKYOGAS もリク エス トに相関IDをもたせてフロントエンド・バックエンドでログを検索できるようにはしていますが、シグナルごとの相関性も考えていかなくてはならないなあ、と改めて感じました。まさにセッションで話していたとおり、私を含めた初期からいるメンバーは、なんとなく「こういう順序で追いかけていってアラートの原因を特定できる」って感覚を持っているのですが、あとからジョインしたメンバーにそれを引き継げているかというと･･･やっぱり耳が痛かったです（三回目）しかしここはチームで愚直にやっていきたいなと思います。特にアプリもSREも含め、まだ小規模なチームのうちに一体感をもってやっていきたいですね！ マイクロサービス基盤にフルマネージドサービスではなく Kubernetes を選択する理由 speakerdeck.com ウォンテッドリー さんのマイクロサービスを Kubernetes で運用してきた2016年からの歴史を語るセッションでした！まさにこれからやっていき！な当チームにとっては参考になるセッションです。2016年当時は選択肢が少ない状況だったが、今はどうなのか？ ウォンテッドリー さんは2024年現在でも「マイクロサービス開発の基盤に Kubernetes の拡張性が必要」と考えているとのことですが、これは私たちも同じように考えたので、共感できるものでした。ただ、 Kubernetes を採用した際に必ず言われる「運用負荷」について、改めて細かく紹介してくれたのは、これまた知見の塊でした･･･！やはり内製ツールは必要に応じて作っていかないとな、というのと、 Cluster add-ons の管理からは逃れられないというメッセージは、当チームも胸に刻んで行こうと思います。がんばろう･･･！アップグレード作業だけでなく、取り組み自体をマニュアル化するというのも、取り入れてみたいなーと感じました！ やっぱり現地参加は熱い！ ここまで、気になったセッションを紹介してきました！コロナ禍以降、私自身、イベントの参加はオンラインが主流になっていました。現地参加の熱が戻ってからも、「仕事があるかも」というのを理由にオンライン参加にしてしまい、結果として見られないことが多々…まずは現地参加することで、この枷を外すことが出来たのが一番です。 そして、登壇者の方はもちろん、参加されている多くの方とお話できたことが本当にありがたかったです！みなさん、本当にエンジニアとして楽しんでいる様子が伝わってきて、自分自身の新たなモチベーションにもなりました！改めて、この場を借りてお礼をさせてください！ 余談 札幌での開催！ということで、セッション以外にも色々楽しんできました🍦具体的には、とにかく甘いものを食べまくりました笑 北菓楼のパフェ！ 北菓楼のソフトクリーム！！ きのとや 大通公園 店の限定オムパフェ！！！ そして溢れるいくら！！！！ myTOKYOGAS リニューアル後も、中々羽根を伸ばす機会がなかったのですが、今回は遠方の地での開催ということで、イベント以外の時間に息抜きも出来て良かったです。本当に理解ある上司や仲間に囲まれて、ありがたい限りです…🙇‍♂ おわりに 次回の CloudNative Days Winter は東京での開催！ということで、次回も現地参加出来たらなーと思います！そして CFP も出したい…！今回は東京でのプレイベントに登壇させていただいたので、そこからの進歩とかお話できたら良いな〜。 それでは、最後までお読みいただき、ありがとうございました！！ 当チームは積極的な採用を行っています！ご興味ある方はぜひ以下から応募くださいませ！ アプリケーションエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

みなさんこんにちは、杉山です。気付けば5月も終わりですね。新年度、新しい環境でスタートされた方々も、すっかり慣れてきた頃でしょうか。当チームの4月にジョインしたメンバーも、既にバリバリ活躍してくれており、頼もしい限りです！！ 話題はかわりまして…先日5月22日、「CloudNative Days Summer 2024 プレイベント@東京」というイベントにて登壇してまいりましたので、そのときの様子などを書いてみたいと思います💪 cloudnativedays.connpass.com なぜ登壇したの？ 当チームでは EKS を採用しておりますが、 Kubernetes や OSS に触れていく中で「コミュニティのイベントで取り組みを知ってもらいたい / 課題や取り組みをシェアすることで、少しでも誰かのヒントになってほしい」「コミュニティの皆さんとの交流で新たな学びを得たい」という想いが強くなっており、思い切って「CloudNative Days Summer 2024」に CfP を提出しました。 残念ながら、提出した CfP は不採択だったものの、運営の方に「東京でプレイベントを開催しますので、良かったらいかがでしょうか」と声を掛けていただき、このたび登壇した次第です。 本イベントを札幌で開催する前に、CloudNative Days を盛り上げていこう！という趣旨とのことで、非常にありがたい機会ということもあり、迷うことなく快諾しました！選出ありがとうございます！ 登壇の様子 登壇資料について、以下にアップロードしております！ speakerdeck.com また、動画も残っております！(運営のみなさまありがとうございます🙇‍♂ www.youtube.com 当日お話したこと まずは当社のこと、当チームのことをお話して、myTOKYOGAS リニューアル後の課題感から「 Kubernetes を選択した」という流れでお話をしました。本ブログの過去記事でも内製化を始めた経緯についてご紹介しておりますので、ご興味ある方はぜひご覧いただければと思います。 tech-blog.tokyo-gas.co.jp また、EKS を始めたことについても過去記事でご紹介しておりますので、あわせてご覧いただけましたら幸いです。 tech-blog.tokyo-gas.co.jp tech-blog.tokyo-gas.co.jp 当日は Karpenter x Graviton の利活用について、 SNS でも「エネルギー企業がエネルギーのことを考えてアプローチしていること」に対するポジティブなご意見をいただき、大変うれしかったです。事業にコミットしていくエンジニアとして、会社の理念は非常に大切にしていますし、当社が約140年の歴史を紡いできたのも、この「共通理念」があったからこそだと思っています。 もちろん、時代と市場の変化は激しく、考え方も仕事のやり方も アジャイル に変えていかなければなりません。当社も、ガス・電力に次ぐ第三の柱として新たなソリューションブランドを立ち上げるなど、変化を前向きに受け止めてチャレンジしていこうとしています。ここにエンジニアもコミットしていくにはどうするか。常々考えていることですが、「脱炭素」を掲げる当社のエンジニアがデータセンターのマシンを無尽蔵に使っていては説得力がありませんし、まずは少しでもエネルギー問題へ貢献し、当社理念の「未来をつむぐエネルギー」になっていけたらと考えています。 そして第三の柱として掲げたソリューション事業に対しても、myTOKYOGAS をきっかけに、エネルギーに関するB2C領域をマイクロサービス化することで、様々なア イデア を素早くサービス化し、お客さまに届けられるのではないか ─── こうした未来に向けて、当チームも新たなチャレンジを始めたということが、登壇を通じてみなさまに伝わったのでしたら何よりです。 登壇しての気付き CloudNative Days コミュニティでの登壇は初めてでしたが、運営のみなさまと来場されているみなさまが作る空気感は本当に穏やかで、リラックスして過ごすことができました！また、最初の質問でいただいた「Helm と Kustomize の使い分け」について、登壇終了後にあらためて色々と調べる中で、どういう考え方があるのか学ぶことができました。 AWS などが提供する Chart を Argo CD の Application 内で呼び出すのが現状の主な用途ですが、Helm にパッケージングすることのメリットと Kustomize のメリットを改めて比べてみて、ここはしっかり考え直した方が良いなと感じています。 他にも、Argo CD Image Updater は私が検証をPENDさせたままなので(汗)、これも早々に試してみて、本ブログや年末に出せたらなと…！ いずれにしても、みなさまから多くのご質問をいただけたことが大変ありがたく、こちらが学びを得るばかりになってしまった気もしており恐縮ですが、今後もこのブログをはじめ、アウトプットを続けたいなと改めて感じた次第です！札幌で開催される本番に、私も参加者として現地に向かう予定ですので、現地でお会いした際には仲良くしてくださると嬉しいです🤝 (前夜祭にも参加します…！ そして「イベント現地に行くの・・・良いよね・・・」ということで、今年度はチームの仲間と Platform Engineering Kaigi だったり SRE NEXT 2024 にも参加しようと思っていますので、こちらもまた、ぜひ業界を超えた交流が出来たらと思っています！ それでは、簡単なレポートではありますが、今回はこのあたりで。ここまでお読みいただき、ありがとうございました！また次回の投稿でお会いしましょう👋 当チームは積極的な採用を行っています！ご興味ある方はぜひ以下から応募くださいませ！ アプリケーションエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

こんにちは、ソフトウェアエンジニアリングチームでチームリーダー兼テッ クリード をしております中島です。 4/16(火), 4/17(水)で開催された DevOpsDays Tokyo 2024 に登壇しましたので、今回はそのレポートです！ DevOpsDays Tokyo 2024 にはチームメンバーの相川も参加しておりレポート記事を書いていますので、ぜひそちらもご覧ください！ tech-blog.tokyo-gas.co.jp tech-blog.tokyo-gas.co.jp 登壇のきっかけ 登壇内容 登壇でお伝えしたこと Networking Party 最後に 登壇のきっかけ 東京ガス では他部においても アジャイル 開発や内製化に取り組んでいるチームがあります。そのチームにDevOpsDaysの運営を手伝っている方がおり、 その方からDevOpsDaysが近々開催されるので、「myTOKYOGASの内製化の事例でプロポーザルを出してみたら面白いのではないでしょうか？」というお誘いをいただいたことがきっかけでした。 我々のチームとしてもmyTOKYOGASの開発など内製開発チームの取り組みを発信していきたいと考えており、DevOpsは内製化を実現するために力を入れたポイントでもあったので、ぜひ機会があればということでプロポーザルを提出し、ありがたいことに登壇の機会をいただくことができました。 登壇内容 今回は「エンジニアゼロからのDevOps​ ​ ~ エンジニア文化のない大企業での内製開発成功への軌跡 ~」というテーマで登壇しました。 私自身のキャリアの中で内製化にはいくつかの会社で取り組ませていただき、技術的な取り組みの必要性はもちろんのこと、そこに加えて文化や組織という観点での取り組みが非常に重要であると感じていました。 技術的な取り組みはイベント内でも素晴らしい登壇がありますし、我々独自の知見として伝えられるのは内製化における文化や組織面の話であろうと考え、文化や組織面での話を中心にお話ししました。 speakerdeck.com エンジニアゼロからのDevOps​ ​ ~ エンジニア文化のない大企業での内製開発成功への軌跡 ~ 登壇でお伝えしたこと 昨今、日本の大きな企業でも内製化に取り組んでいる会社が多くなってきたと感じています。 私自身も複数の企業で内製化に取り組んできましたが、どのような体制や文化で開発を進めていくのか？という組織面での取り組みが非常に重要でした。 デジタル化の時代においてエンジニアの活躍が重要なのはいうまでもありませんが、それと同じくらい「ビジネスメンバーの協力や理解が得られたこと」や「文化の醸成」がmyTOKYOGASの内製化の成功の要因となっています。 その中でも特に以下の3点をmyTOKYOGASの内製開発では重視して取り組んでおり、その点について具体的な取り組みなどを中心にお伝えしました。 当事者意識と熱量の重要性 東京ガス はエンジニアを中心とした会社ではありません。そのため、エンジニアが開発に必要なツールが全社的に導入されているわけではありませんでした。 一方で、カンファレンスのメインテーマでもあるDevOpsを実現するには、CI/CDを構築するための環境やツールなどが必要です。しかし、大きな会社で全社導入されていないツールなどを導入することは容易ではありません。 そして、 アジャイル 開発やDevOpsといった取り組みは、今までの外注中心の システム開発 の時とは異なる文化や考え方が必要になります。内製化においては、これらの壁にぶつかることも多いのではないかと思います。 我々がそれらの壁を乗り越えることができたのは、myTOKYOGASのチームにある「当事者意識」と「熱量」が環境や文化を変えていったことが大きな要因でした。 エンジニアとビジネスメンバーの一体化 内製化を進める上において注意しないといけないのは、内部にエンジニアがいてもビジネスとの距離が遠く、社内での受発注関係になってしまうことです。 内製化のメリットは、ビジネスとエンジニアが一体化した体制が作りやすいことだと考えています。 そういった体制が作れることで、エンジニアからビジネス視点を持ったプロダクトに対する意見が出たり、ビジネスメンバーとのコミュニケーションコストを下げ、迅速で柔軟な開発が可能になります。 そのため、myTOKYOGASの内製化ではエンジニアとビジネスメンバーが一体となれるように開発を進めていきました。 その結果、ビジネスメンバーの理解とさまざまな協力が得られたことが非常に大きな成功要因となりました。 価値に基づいて行動する文化 事業会社の内製開発は「システムを作ること」が目的ではなく、「自ら書いたコードや設計したシステムがプロダクトに反映され、その機能がどう事業貢献できるのか？」、 そして「プロダクトを通して世の中をどう変えていけるのか？」というプロダクトが生み出す価値に着目して開発できることが面白さでもあり、メリットであると考えています。 myTOKYOGASのフロントエンドチームでは、品質を維持しながら柔軟な開発を実現するため、かなりの量のテストコードを実装しています。 一方で、DevOpsという考え方は、長く 東京ガス で働くメンバーにとって聞きなれないものであり、テストコードの実装やCI/CDの構築は機能開発とは別に開発 工数 を増やすものでした。 しかし、myTOKYOGASの内製化においては価値に基づいて行動することができたからこそ、「ビジネスに追随できる柔軟な開発体制を構築すること」という中長期的な観点で価値を生み出すための目的に向かって、 ビジネスメンバーの理解を得た上で、テストコードの実装やCI/CDの構築のプライオリティを上げDevOpsの実現につなげることができました。 これらの３つの観点は、エンジニア文化のない会社で理解を得ながらDevOps、そして内製化を進めていく上で非常に重要な要素であったと考えており、同じような取り組みをされている方々の参考になればという想いで登壇しました。 Networking Party 登壇後のNetworking Partyでは、他社で内製化の取り組みを実施されている方々や、内製化に取り組みたいが内製化に踏み切れていない方々など様々な参加者の方々とディスカッションすることができました。 DevOpsDaysはみなさまの登壇の内容も素晴らしく価値のあるものばかりでしたが、このNetworking Partyも登壇ではお伺いすることができなかったより深い話ができたため、登壇と同じくらい貴重な時間となりました。 様々な方々と情報交換できたことは非常に学びのある時間でしたし、何より私自身のモチベーション向上にもつながりました。 最後に 今回はご縁あり、DevOpsDays Tokyo 2024に登壇の機会をいただくことができました。 登壇機会をくださったDevOpsDaysの関係者のみなさま、ありがとうございました！ 内製化に取り組まれている方々、内製化に取り組もうとされている方々の参考に少しでもなれば幸いです。 そして、エンジニアのみなさまに「事業会社でエンジニアをやるのも楽しいよ！」ということが伝われば嬉しいなーと思っております！ DevOpsDaysは登壇者としても参加者としても学びのある素晴らしいカンファレンスでした。 我々内製開発チームの取り組みは、これからも続いていきます！ 来年もまたプロポーザルを提出して登壇機会を得られるよう、DevOpsDaysで得た学びも活かして今年度も頑張っていきたいと思います！ 私たちのチームでは、ともに働く仲間を積極的に募集しています。ソフトウェアエンジニアのみならずSREのポジションもございますので、少しでも興味をお持ちいただけましたら、ぜひカジュアル面談からご応募ください！ Application Developers www.wantedly.com SRE www.wantedly.com 最後までお読みいただきありがとうございました!！

みなさん、こんにちは！myTOKYOGAS フロントエンドチームに所属しております相川と申します。2024年4月16日〜17日に「 DevOpsDays Tokyo 2024 」が開催されましたね！私は初めてのカンファレンス参加だったのでドキドキワクワクしながら参加してきました。   はじめに サービス運用はボールを落とさない競技 : 2009年DevOpsDays の誕生と私の身の回りの話 Value-Driven DevOps Team〜価値貢献を大切にするチームがたどり着いたDevOpsベストプラクティス〜 金融業界で複数チームDevOpsを目指して奮闘している話 まとめ   はじめに 今回の記事では、DevOpsDays Tokyo 2024のDay2に参加した学びを発信していきます。Day1参加レポートは別の記事で書いていますのでぜひご覧ください！ tech-blog.tokyo-gas.co.jp また、当チームの内製開発の様子を紹介した記事もありますのでこちらもご覧ください！ tech-blog.tokyo-gas.co.jp では、Day1に引き続き学びを得たセッションについて書いていきます。   サービス運用はボールを落とさない競技 : 2009年DevOpsDays の誕生と私の身の回りの話 このセッションでは、DevOpsの歴史やDevOpsとはそもそも何かについて知ることができ、大変有意義でした。 セッションの中で、 Flickr 10+ Deploys per Dayの トーク が取り上げられており、その中でも「運用チームの仕事は、サイトを安全で高速に保つことではなく、ビジネスを可能にすることである。」という言葉が心に残りました。また、「ビジネスを成功させるためには、ユーザーのニーズの変化に対応していく必要があります。しかし、変化はほとんどの障害の根本原因でもあり、そのために必要に応じて変化を起こせるようなツールや文化を構築することが重要」だと説明されていました。システムはただ作るだけではなく、ビジネスを成功させるためのものであり、継続的な価値創出にはDevOpsが必要不可欠であることを改めて実感しました。さらに、DevOps文化を根付かせるためには、プロダクトに関わる全員が当事者意識を持って常にプロダクトを改善していく姿勢が重要だと再認識しました。 セッションの中で最も印象に残ったのは、「どのような変更でもサイトの障害や問題を引き起こさないという自信を高めること、そして障害が発生した場合にそれらから迅速に回復する能力を高めることが大切である」という内容です。私の所属するチームでは、テストコードによる早期の問題発見や、Blue/Greenデプロイによるリリースリスクの低減などに取り組んでいます。しかしながら、まだまだ取り組めていない箇所もあり、この考え方をより意識して今後の取り組みを継続していこうと思います。 speakerdeck.com Value -Driven DevOps Team〜価値貢献を大切にするチームがたどり着いたDevOpsベストプ ラク ティス〜 サービスローンチ後にDevOpsに取り組みチームがたどり着いたベストプ ラク ティスについてのセッションでした。仮説検証ループを素早く回すための仕組み作りに取り組んでおり、トランクベース開発を採用しているそうです。また、ボタン一つでデプロイができるような環境を整備し、フィーチャーフラグを導入することで、毎日のデプロイを実現したとのことでした。また、チームの目指す方向性を明確にするために、 インセプション デッキを作成し、医療の世界を変革していくために、価値を届けることを目標に掲げているとおっしゃっていました。ローンチ前は開発に注力していましたが、ローンチ後は仮説検証ループを素早く回せているかを確認するために、毎週振り返りを行っているそうです。振り返りでは、具体的なアクションを出すことよりも、対話を通じて相互理解を深め、学びを最大化することを重視しているとのことでした。 私の所属するチームでは、デプロイの自動化は実現しているものの、他システムとの接続テストやリリースの必要性から、デプロイ手順が複雑になっています。一部自動化、一部手動という状況であり、まだまだ改善の余地があるなと思っています。これらの問題を改善し、よりシンプルにデプロイできる仕組みを構築することでデプロイ頻度向上に取り組んでいきたいと考えています。また、フィーチャーフラグについては、現時点では導入していませんが、デプロイ頻度の向上に課題を感じているため、導入により解決できるかどうか、そもそもチームに適しているかを検討したいと思いました。振り返りの手法に関しては、次のアクションを出すことに意識が偏っているかもしれないと気づかされました。対話を重視することをチームに浸透させ、実践していきたいと考えております。 speakerdeck.com   金融業界で複数チームDevOpsを目指して奮闘している話 このセッションでは、金融業界で複数システムの運用保守と新規開発を担当している開発チームが、ゼロから アジャイル とDevOpsを推進する中で経験した成功事例と失敗事例を共有してくれました。20以上のシステムを50名規模のメンバーで開発運用していく必要があるという環境でどのようにチームを分割し スクラム 開発をしていったかを話してくださっていました。4つの開発チームと1つの運用チームに分割し不要な会議体を減らしていき徹底的に無駄を省くような取り組みを行ったとのことでした。 特に印象に残ったのは、 スクラム チーム間の情報共有の取り組みです。各チームが取り組んだことや改善したことを共有する場を設けることで、チーム間で相互に学び合い、成長できる環境を作り出しておりとても良い取り組みだなと思いました。 チームの規模や構成を適切に設計し、コミュニケーションと情報共有を促進することの重要性を再認識させられる内容でした。   まとめ DevOpsDays Tokyoへの参加は私にとって初めての経験でしたが、この２日間で得られた学びは非常に多く、とても有意義な時間を過ごすことができました。DevOps実践者たちの、生の成功事例や失敗事例を聞くことで良い刺激を受けました。myTOKYOGAS フロントエンドチームでは、CI/CDにおいて自動テストや 脆弱性 診断が実行され、Blue /Greenデプロイによってリリースリスクも低減されています。さらに、Datadogを用いてアプリケーションを常に監視し、異常があれば検知する仕組みも整っています。しかしながら、まだまだ改善の余地があり、今後取り組みたい課題もあります。カンファレンスで得た知見やヒントを最大限に活用し、今後もDevOpsの実践に取り組んでいきたいです！ 最後になりましたが、カンファレンスへの参加を快諾してくださったチームの皆さんに感謝いたします。貴重な機会を与えてくださり、本当にありがとうございました！   私たちのチームでは、ともに働く仲間を積極的に募集しています。少しでも興味をお持ちいただけましたら、ぜひカジュアル面談からご応募ください！ Application Developers www.wantedly.com SRE www.wantedly.com それでは、最後までお読みいただき、ありがとうございました！

こんにちは、myTOKYOGAS フロントエンドチームを担当している中嶋です！ 本稿では、myTOKYOGASの内製開発に取り組むウェブアプリのエンジニアチームがどのように他チームと連携しながら新規機能の開発を行なっているかをご紹介させて頂ければと思います！ 新規機能開発について ビジネスチームとの連携 スプリント・プランニング デイリー・スタンドアップ リファインメント スプリント・レビュー レトロスペクティブ おわりに 新規機能開発について 我々が日々開発や保守・運用を行っているmyTOKYOGASは、現在たくさんのお客さまからご質問やご要望を頂いております。それらを受けてエンジニアチームは、ビジネスチームと密にコミュニケーションを取りながら、開発 工数 、提供できる価値、期待されるコスト削減効果などを考慮して取り組むべき課題の優先度について議論しています。新規機能開発を進めていく際には、前提としてそもそもなぜこの機能を追加する必要があるのか、お客さま視点でどのような不便を解消するものなのかといった背景や動機をビジネスチームと双方に認識を合わせながら進めていくよう努めています。モダンな技術を採用しても、ビジネス上価値に繋がらないものを生み出していては本末転倒です。同じ事業部内に内製開発チームを立ち上げた背景の1つとして、所属するチーム間の垣根を無くしメンバー全員がサービスや事業の価値を念頭に置きながら、チーム横断的に連携して機能開発を行なう体制を作る必要があったことが挙げられると思います。ビジネスチームからの要望に応えて、ただ闇雲に言われた通りのものを開発するのではなく、プロダクト志向で自社サービスの開発にコミットしていける環境ではないかと考えております。 ビジネスチームとの連携 我々エンジニアチームは、 スクラム イベントの中でスプリント・プランニングやデイリー スタンドアップ などの場でビジネスチームと連携しながら開発を行なっています。それぞれの スクラム イベントの中で、どのように開発を進めているかを簡単にご紹介させて頂ければと思います！ スプリント・プランニング まず最初に、開発が必要な背景、開発するスコープの整理、機能の概要、などについて、スプリント・プランニングの場でビジネスチームから説明して頂きます。 業務フロー図の例 このスプリント・プランニングの段階で本機能が実際に使われるユーザーストーリーの全体イメージ、myTOKYOGASサポート窓口やお客さまの視点でどのような不便や業務負荷などを解消する機能なのかといった業務的な内容に対する解像度が上がります。また、画面ごとに詳細な機能要件や非機能要件なども一緒に確認していきます。 画面ごとの要件を整理する Figma による画面遷移フローの確認 また、優先度を検討する上で本機能が追加されることでどのくらいの改善効果が見込めるのかといった費用対効果の観点でも議論します。エンジニアチームは必要な開発 工数 を大まかに見積もり、ビジネスチームはどのくらいの改善効果を見込めるか試算します。エンジニアチームでは、開発タスクの相対見積もりに Hatjitsu というプランニングポーカーシステムを利用しています。相対化の基準となるタスクについてチームのメンバー間で開発 工数 の認識を合わせた上で、新規機能のタスクに対する見積もりの精度を高められるよう改善しながら取り組んでいます。 プランニングポーカーを使った開発タスクの相対見積もり デイリー・ スタンドアップ いざ、新規機能開発を進めていく段階に入ると、デイリー・ スタンドアップ の場で開発の進捗確認を行いながら、要件の再確認なども同時に行なっていきます。 Linearによる開発タスクの進捗確認 実際に開発を進めていく中で要件の不足や考慮漏れが明らかになることもあるかと思いますが、そのような場合でもビジネスチームと連携しながら業務的な観点やお客さま視点での影響を考慮しながら迅速かつ柔軟に対応方針を判断し、開発効率を下げないよう双方に連携しやすい体制が整っていると思います。また、デイリー・ スタンドアップ の中では、毎回雑談の時間を設けることで 心理的 安全性を下げないよう自由に発言しやすい雰囲気作りも行なっています。我々のエンジニアチームでは基本的に在宅で開発業務を行っているため、雑談をする機会を意図的に作らないと会話する機会があまりありません。そのような課題意識から日々のデイリー スタンドアップ の場で軽い雑談の時間を設けて、話したいネタがあれば事前に記載して頂いたり、特にない場合は今日の気分を5段階で入力してもらって体調が悪くないかなどを確認するようにしています。 リファインメント スプリント・プランニングの段階では要件が決まっていなかった機能や差し込みのタスクなどに対応しなければならないことがあるかと思います。我々のチームではそのようなタスクについてリファインメントの場で開発 工数 の相対見積もりや優先度の順位づけを行うようにしています。突発的な差し込みのタスクなどに対応する必要があった際でも、プランニング当初に描いたスケジュールを大きく崩さないように優先度を調整しながら開発を進めていきます。 スプリント・レビュー スプリント・レビューでは、ビジネスチーム以外のメンバーも交えながら全員でレビューを行います。この段階で機能開発が完了していれば実際に開発環境で実装した機能を動かしてもらいながら、機能面やデザイン観点で不備がないかを確認していきます。また、複数のスプリントにまたがって実施するような大型の案件については、途中までの経過を確認しながら、今後改善できる点や他に検討すべき項目がないかを議論することで、プロダクトをより良いものに仕上げていきます。 レトロスペクティブ スプリントの最終日は、メンバー全員でレトロを開催して振り返りを行います。問題があったことの振り返りや議論はもちろん重要なことですが、感謝のコメントやポジティブなフィードバックについても、積極的に書いて頂いているように思います。また、問題として取り上げられた中で特に優先して解決すべきものについてメンバーで投票を行い、次回までに実行する対応策について議論し、具体的なアクションに落とし込んで取り組むようにしています。 Miroを利用したレトロスペクティブ おわりに 今回は スクラム イベントを通じてエンジニアチームがどのようにビジネスチームと連携しながら内製開発を行っているかをご紹介させて頂きました！ スクラム は アジャイル な開発を実現するための手段の1つであって、目的ではありません。エンジニア個人としての成長機会を重視しながらも、チーム全体としての生産性を最大化できるよう、今後も試行錯誤しながら改善をしていきたいと思ってます。直近では、日々の開発業務がマンネリ化してモチベーションを下げないようにするために業務時間の一部を利用して リファクタリング を行ったり、技術書を輪読する会を開催するなどの取り組みを検討しています。 私たちのチームでは、ともに働く仲間を積極的に募集しています。少しでも興味をお持ちいただけましたら、ぜひカジュアル面談からご応募ください！ Application Developers www.wantedly.com SRE www.wantedly.com 最後までお読みいただきありがとうございました。また次回の記事でお会いしましょう！

はじめに、はじめまして。リビング戦略部SREチームのあおしょん（本名：青木）と申します。 2024年4月1日から弊チームにジョインしたピチピチの新人 *1 です。 入社から約一ヶ月過ぎまして、現在も盛りだくさんの情報量と圧倒的当事者意識を持っている弊社の優秀なエンジニアたちに日々圧倒されながらも一刻も早く事業に貢献出来るように歩を進めています。 大きな貢献が出来ている、とは未だ胸を張って言えないのですが入社したてで業務知識が無くてもまずは小さい貢献からコツコツと始めてみよう、ということで弊チームにおけるTerraformバージョンアップの方針と運用について整理したのでご紹介いたします。 ご紹介の前に申し上げておきたいこととして、今回はバージョンアップの運用をこんなテッキーなことをしてクールに自動化してやったぜ～ ワイルドだろ～ という内容ではございません。あくまで現状はこうなっているからこういうことを考慮してこうやってバージョンアップしていくことになった、ということを淡々と説明する泥臭い内容となっています。また、対象の読者は既にTerraformを利用しており一般的な機能や用語を把握している方々となります。 Terraformバージョンアップちゃんと出来てますか？ Terraformバージョンアップの方針 結論 背景 Terraform Version Provider Version .terraform.lock.hcl の取り扱い バージョンアップの流れ、すなわち運用 0. バージョンアップサイクル 1. アップデート情報の確認 2. 事前Terraform Planのためのコード更新 3. 事前Terraform Plan結果確認 4. 既定ブランチへのPull Request, Merge 5. Terraform Apply, 動作確認 全体像 これから取り組んでいくこと 終わりに Terraformバージョンアップちゃんと出来てますか？ いきなりですが本記事をお読み頂いている、かつ業務でTerraformを活用されている方々に聞いてみたいのですが 「Terraformバージョンアップちゃんと出来てますか？」 ここで言うTerraformバージョンは下記のことを指します。 Terraform Version（Terraform本体のバージョン ） Provider Version 「当然出来てるよ」という方であれば貴重なお時間を割いてまで本記事を読む必要はないかと思います。 私の今までの経験ですと大体が下記のような感じでした。（ GitHub ActionsやAzure PipelinesなどのCDパイプラインまたはHCP Terraform（旧Terraform Cloud）を利用している前提です。） バージョン固定（ = ）をしてサービスローンチ時から塩漬け。重い腰を上げてのバージョンアップは年一回程度。 男気溢れる（死語）常に最新バージョン（ >= ）でterraform init。もちろん terraform.lock.hcl は .gitignore に投入済み。 書いてて自分でもなかなかパンチが効いているなとは思った2点目はそこまで見かけなかったですが1点目はまあまあ遭遇しました。 そして漏れなく弊チームも1点目の状態となっていました。これはただ単にバージョンアップをしようとしていない、というわけではなくチームメンバーが少人数、かつ他に優先度が高いタスクがあり手が回っていない状態でした。 当然、このまま放置すると問題は発生します。特に下記の点が悩ましくもどかしい問題となります。 Terraform Versionがバージョンアップして便利な機能がリリースされても使えない日々。importブロックのfor_each、メチャクチャ便利で使えそうな場面があるのだけど使うことが出来ない…とか terraform plan したら知らない差分が出ている。原因はProver Versionのアップグレードでいつの間にかパラメータの既定値が変わっていたり、新規パラメータが追加されていたりとか 上記の問題を解消してチームメンバーが優雅なTerraformライフを送るためにまずは無理なくバージョンアップ出来るような方針を検討しました。 Terraformバージョンアップの方針 結論 まずはバージョンアップ方針は下記の通りとなりました。 メジャーバージョンは破壊的変更（BREAKING CHANGE）、廃止（DEPRECATIONS）を伴う可能性があるため、下記を対応した上でバージョンアップをする。 Release Notesでバージョンアップによる影響の調査 影響がある場合は、バージョンアップのPR (Pull Request) にコード修正を含める バージョンアップのための対応期間は下位互換性の有無と影響度合い、チームメンバー全体のタスク状況を考慮してチームプランニング会 *2 で決める。 マイナーバージョンについても上記と同様の対応をする。但し、メジャーバージョンとは異なり定期的なバージョンアップサイクルを設ける。 パッチバージョンについては 後方互換 性が担保されるため、常に最新のバージョンを維持する。 以降で上記の方針に至った背景をご説明します。 背景 先述した通り本記事では下記の２種類 *3 をTerraformバージョンの対象としています。 Terraform Version Provider Version 両方ともセマンティック バージョニングが採用されていますが、考慮点が異なるのでそれぞれ検討しました。 semver.org なお、以降の項目ではHashiCorp公式ドキュメントの文章の引用、及び日本語訳を記載しています。 日本語訳は Google翻訳 にて翻訳の上、私の方で必要に応じて若干の修正を加えております。 Terraform Version まずは下記の チュートリアル からバージョンアップに関する記載を参考にしました。 developer.hashicorp.com HashiCorp uses the format major.minor.patch for Terraform versions. HashiCorp updates Terraform frequently, so it is common to use configuration written for an earlier version of Terraform. New minor and patch versions of Terraform are backward compatible with configuration written for previous versions. Because of this, you can upgrade to a newer minor version of Terraform and still use your existing configurations. However, upgrading your Terraform version can have other consequences, such as requiring you to update your provider versions. Some version updates may refresh your state file version or require configuration file edits to implement new features. Use the required_version setting to control which versions of Terraform will work with your configurations to ensure that updates to your infrastructure are safe and predictable. 日本語訳） HashiCorp は、Terraform バージョンの形式として major.minor.patch を使用します。 HashiCorp は Terraform を頻繁に更新するため、以前のバージョンの Terraform 用に作成された構成を使用するのが一般的です。 Terraform の新しいマイナー バージョンとパッチ バージョンは、以前のバージョン用に作成された構成と下位互換性があります。 このため、Terraform の新しいマイナー バージョンにアップグレードしても、既存の構成を引き続き使用できます。 ただし、Terraform のバージョンをアップグレードすると、プロバイダーのバージョンの更新が必要になるなど、別の影響が生じる可能性があります。 一部のバージョン更新では、stateファイルのバージョンが更新されたり、新しい機能を実装するために構成ファイルの編集が必要になる場合があります。 required_version 設定を使用して、構成で動作する Terraform のバージョンを制御し、インフラスト ラク チャへの更新が安全かつ予測可能であることを確認します。 要点としては下記となります。 マイナーバージョンとパッチバージョンは前バージョンとの下位互換がある。 但し、メジャー／マイナーバージョンのアップグレードについては下記影響の可能性がある。 Provider Versionのアップグレードが必要になる。 stateファイルのバージョンが更新される。 新しい機能実装のために構成ファイルの編集が必要となる。 上記で「メジャー／マイナーバージョンのアップグレードについては…」としている根拠として、日本語訳中の「Terraform のバージョンをアップグレードすると…」のTerraformのバージョンとは何のことか？という疑問があったのですがマイナーバージョンのアップグレー ドガ イドに下記の記載がありました。 Terraform v1.X honors the Terraform v1.0 Compatibility Promises, but there are some behavior changes outside of those promises that may affect a small number of users. Specifically, the following updates may require additional upgrade steps: 日本語訳） Terraform v1.X は、Terraform v1.0 の互換性に関する約束を遵守していますが、これらの約束以外に、少数のユーザーに影響を与える可能性のある動作の変更がいくつかあります。具体的には、次の更新では追加のアップグレード手順が必要になる場合があります。 ということは結局マイナーバージョンのアップグレードでも少なからずTerraformコードの修正が発生する可能性があるので「メジャー／マイナーバージョンのアップグレードについては…」と定義しました。 また、 チュートリアル 内の下記の点についても考慮が必要となります。 Terraform will only update the state file version when a new version of Terraform requires a change to the state file's format. Terraform will update the terraform_version whenever you apply a change to your configuration using a newer Terraform version. In general, Terraform will continue to work with a given state file across minor version updates. For major or minor releases, Terraform will update the state file version if required, and give an error if you attempt to run an older version of Terraform using an unsupported state file version. If you were to attempt to apply this configuration again using an older version of Terraform that does not support the current state file version, Terraform returns a state lock error and displays the necessary version. 日本語訳） Terraform は、Terraform の新しいバージョンでstateファイルの形式の変更が必要な場合にのみ、stateファイルの version を更新します。 新しい Terraform バージョンを使用して構成に変更を適用するたびに、Terraform は terraform_version を更新します。 一般に、Terraform は、マイナー バージョンが更新されても、指定されたstateファイルを引き続き使用します。 メジャー リリースまたはマイナー リリースの場合、Terraform は必要に応じてstateファイルのバージョンを更新し、サポートされていないstateファイル バージョンを使用して古いバージョンの Terraform を実行しようとするとエラーが発生します。 現在のstateファイルのバージョンをサポートしていない古いバージョンの Terraform を使用してこの構成を再度適用しようとすると、Terraform は状態ロック エラーを返し、必要なバージョンを表示します。 例えば 1.11 のTerraformでPlan/Apply実行した場合、場合によってはtfstate内のバージョンも "terraform_version": “1.11.X” となるため 1.10 のTerraform Plan/Applyを実行したらエラーとなる可能性がある、ということです。（恐らく） 以上のことからメジャーバージョン、マイナーバージョンは固定として定期的にアップグレードするという結論に至りました。 Provider Version Provider Versionについては正直調べるまでもなく…、という気もしましたが念のためちゃんと調べて検討しました。 まずは下記の チュートリアル でVersionを制約しない場合の影響が記載されていました。 developer.hashicorp.com If you do not scope provider version appropriately, Terraform will download the latest provider version that fulfills the version constraint. This may lead to unexpected infrastructure changes. By specifying carefully scoped provider versions and using the dependency lock file, you can ensure Terraform is using the correct provider version so your configuration is applied consistently. 日本語訳） プロバイダーのバージョンを適切にスコープしないと、Terraform はバージョン制約を満たす最新のプロバイダー バージョンをダウンロードします。 これにより、予期しないインフラスト ラク チャの変更が発生する可能性があります。 プロバイダーのバージョンを慎重に指定し、依存関係ロック ファイルを使用することで、Terraform が正しいプロバイダー バージョンを使用していることを確認し、構成が一貫して適用されるようにすることができます。 予期しないインフラスト ラク チャの変更が発生する可能性があります…恐ろしいですね。 また、Style Guideではメジャーバージョン、マイナーバージョンの固定が推奨されていました。 developer.hashicorp.com To prevent providers and modules upgrades from introducing unintentional changes to your infrastructure, use version pinning. Specify provider versions using the required_providers block. Terraform version constraints support a range of accepted versions. Pin modules to a specific major and minor version as shown in the example below to ensure stability. You can use looser restrictions if you are certain that the module does not introduce breaking changes outside of major version updates. 日本語訳） プロバイダーとモジュールのアップグレードによってインフラスト ラク チャに意図しない変更が加えられるのを防ぐには、バージョン固定を使用します。 required_providers ブロックを使用してプロバイダーのバージョンを指定します。 Terraform のバージョン制約は、許容されるさまざまなバージョンをサポートします。 安定性を確保するには、以下の例に示すように、モジュールを特定のメジャー バージョンとマイナー バージョンに固定します。 メジャー バージョンの更新以外でモジュールに重大な変更が導入されないことが確実な場合は、より緩やかな制限を使用できます。 最後にTerraform Providerに登録されるPluginの開発ドキュメントにはバージョン管理のベストプ ラク ティスについての記載がありました。 developer.hashicorp.com Observing that Terraform plugins are in many ways analogous to shared libraries in a programming language, we adopted a version numbering scheme that follows the guidelines of  Semantic Versioning . In summary, this means that with a version number of the form  MAJOR . MINOR . PATCH , the following meanings apply: Increasing only the patch number suggests that the release includes only bug fixes, and is intended to be functionally equivalent. Increasing the minor number suggests that new features have been added but that existing functionality remains broadly compatible. Increasing the major number indicates that significant breaking changes have been made, and thus extra care or attention is required during an upgrade. To allow practitioners sufficient time and opportunity to upgrade to the latest version of the provider, we recommend releasing major versions no more than once per year. Releasing major versions more frequently could present a barrier to adoption due to the effort required to upgrade. Version numbers above  1.0.0  signify stronger compatibility guarantees, based on the rules above. Each increasing level can also contain changes of the lower level (e.g.  MINOR  can contain  PATCH  changes). 日本語訳） Terraform プラグイン は多くの点で プログラミング言語 の共有ライブラリに似ていることに気づき、セマンティック バージョニングの ガイドライン に従ったバージョン番号付けスキームを採用しました。 要約すると、これは、 MAJOR . MINOR . PATCH 形式のバージョン番号では、次の意味が適用されることを意味します。 パッチ番号のみが増加することは、リリースにバグ修正のみが含まれており、機能的に同等であることを意図していることを示しています。 マイナー番号が大きくなるということは、新しい機能が追加されたものの、既存の機能には広範な互換性が残っていることを示しています。 メジャー番号の増加は、重大な破壊的変更が加えられたことを示しているため、アップグレード中に特別な注意が必要です。 実務者がプロバイダーの最新バージョンにアップグレードするための十分な時間と機会を確保するために、メジャー バージョンのリリースは年に 1 回までにすることをお勧めします。 メジャー バージョンをより頻繁にリリースすると、アップグレードに必要な労力が原因で導入に障壁が生じる可能性があります。 1.0.0 より上のバージョン番号は、上記のルールに基づいて、より強力な互換性保証を意味します。 増加する各レベルには、下位レベルの変更を含めることもできます（例: MINOR には PATCH の変更を含めることができます）。 つらつらと公式ドキュメントを引用しましたが 落とし穴 考慮点はマイナーバージョンの互換性はあくまで「広範」となっていることだと思いました。 この記載が気になりいくつかのProviderのRelease Notesを眺めましたが恐らくProviderによって「広範」の捉え方が異なるんだな…と個人的に感じました。 何のことかといいますと、あるProviderのマイナーバージョンのアップグレードにおけるRelease Notesは一貫して FEATURES ENHANCEMENTS BUG FIXES のみなのですが別のあるProviderでは上記と併せて BREAKING CHANGE DEPRECATIONS が含まれていることがありました。 互換性とは一体…と突っ込みたくなりますが 「広範」な互換性であるということはやはりコード修正が発生する可能性があるので度合いは違えどメジャーバージョンのアップグレードとほぼ同じ対応方針でよいのでは、と考えました。 以上のことからメジャーバージョン、マイナーバージョンは固定として定期的にアップグレードするという結論に至りました。 ということでTerraform Versionと同じ結論になったので統一した方針となりました。 .terraform.lock.hcl の取り扱い バージョンアップの方針を取り決めて運用をしていく上で .terraform.lock.hcl を管理するかはチーム内で少し議論になりました。 公式ドキュメントでは リポジトリ 管理を推奨していますね。 developer.hashicorp.com Terraform automatically creates or updates the dependency lock file each time you run the terraform init command. You should include this file in your version control repository so that you can discuss potential changes to your external dependencies via code review, just as you would discuss potential changes to your configuration itself. 日本語訳） Terraform は、terraform init コマンドを実行するたびに、依存関係ロック ファイルを自動的に作成または更新します。構成自体に対する 潜在的 な変更について議論するのと同じように、コード レビューを通じて外部依存関係に対する 潜在的 な変更について議論できるように、このファイルをバージョン管理 リポジトリ に含める必要があります。 結論としてはあえて .gitignore の対象に含めて管理しないことにしました。 理由としては下記となります。 メジャーバージョン、マイナーバージョンはバージョン制約で固定している。 方針に則り、常に最新のパッチバージョンでTerraformを実行する。 Pull Request前に GitHub ActionsでTerraform Planは必須とするのでローカルの .terraform.lock.hcl は管理不要とする。 バージョンアップの流れ、すなわち運用 では実際に日々の業務の中でどうやってバージョンアップをしていくことになったのかを説明します。 0. バージョンアップサイクル 実働メンバーが少人数（本記事執筆時点で３人）、かつ現時点ではほぼ手動作業が主となるためマイナーバージョンのアップグレードサイクルは月次とする。 先述の通り、メジャーバージョンのアップグレードはチームプランニング会で決める。 担当者はチームプランニング会でLinearチケットを アサイ ン、SREチームの全メンバーでローテーション、担当者は以降のプロセスに従いバージョンアップを実施します。 1. アップデート情報の確認 現在の利用バージョンから アサイ ン時点までのアップグレード情報を GitHub リポジトリ のRelease Notesで調査する。 BREAKING CHANGE, DEPRECATIONSの有無を確認し、影響有りであれば備忘として内容をチケットにコメントする。（後続のPull Request Descriptionにも掲載する。） 2. 事前Terraform Planのためのコード更新 作業ブランチをチェックアウトして下記を更新する。 Terraform Blockの下記を更新する。 required_version required_providers.<provider>.version パッチバージョンは常に最新とするため下記の通り ~> x.y.0 のようにバージョン指定する。 terraform { required_version = "~> 1.8.0" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.100.0" } } } Terraform Versionがアップグレード対象の場合、 GitHub ActionsのTerraform Plan/Apply実行用Workflowファイルの下記を更新する。 terraform_version パッチバージョンは常に最新とするため下記の通り ~1.y のようにバージョン指定する。 - name : Setup Terraform uses : hashicorp/setup-terraform@v2 with : terraform_version : ~1.8 Release Notesの内容からバージョンアップ以外の修正が必要であれば更新する。 3. 事前Terraform Plan結果確認 作業ブランチで全環境（develop, staging, prroductionなど）に対してTerraform Plan用Workflowを実行する。 Plan結果に差分があれば（すなわち No changes. ではないのであれば）適宜修正する。 ここでTopicです。 Provider VersionのアップグレードはRelease NoteのBREAKING CHANGE, DEPRECATIONS以外に下記の点でTerraformコード修正が必要な場合があります。 パラメータの既定値が変わることがある。 tfstateに新規パラメータが追加されることがある。 新規パラメータ追加についてはApplyせざるを得ないのでその場合はPull Request Descriptionに実機影響ないことを含めてその旨を記載することにしました。 4. 既定ブランチへのPull Request, Merge 下記をDescriptionに記載してPull Requestを作成、承認後Mergeする。 BREAKING CHANGE, DEPRECATIONSによる更新概要 Plan結果に差分がある場合の説明 5. Terraform Apply, 動作確認 サンドボックス 環境、開発環境、本番環境といったユーザー影響の無い順番でTerraform Apply、動作確認を実施する。 Terraform Applyにより変更が発生してもあくまでtfstateのみが更新される想定ではあるが念のためアプリケーションの動作確認を行う。 全体像 まとめとしてバージョンアップの流れの全体をざっくり フローチャート にすると下記の通りとなりました。 特に複雑な作業項目はありませんが、どのような作業があるかを可視化出来たのでチームメンバーへ進捗状況の共有がしやすくなりました。 これから取り組んでいくこと 今回はバージョンアップをちゃんとはじめるために終始方針を決めて運用を整理したことについてご紹介しましたが先述の通りほぼ手動作業が主となるため実際に数回のサイクルを回してチームメンバー全員が流れを把握出来たら「この部分はこれで自動化出来るよね」とか「ここはこうした方がみんなの負担が減って楽に回していけるよね」ということを議論して運用の改善を続けていきます。 少し先のことにはなりますが、改善のフェーズが進んだらテッキーなことをしてクールに自動化してやったぜ～ ワイルドだろ～ （もちろん、左記が本質ではないですが）という内容についても本ブログでご紹介したいと思います。 終わりに 最後はまとめではなく自身への戒めを込めたポエムで締めます。 Terraformバージョンアップの内容からは外れますが日々の業務の中で別のチームからの依頼、または自発的にそれとなく誰かがこなしている作業というのは少なからずあると思います。所謂「業務の属人化」ですね。普段はその対応者がそれとなく作業をこなしているので他のチームメンバーが意識することはあまりないんじゃないかと思います。ただ言うまでもなく「業務の属人化」はたくさんのリスクをはらんでいます。例えば、その対応者が退職したり事故や病気などで突然の長期休暇になってしまったときなどですね。当然その対応者がいなくなってもシステムは稼働し続けるので他の誰かがその対応者の代わりに属人化されていた作業をしなければなりません。例えほとんどの作業が自動化されており極端な話、クリック一つで完了する形になっていても中身のプロセスを知らなければイレギュラーな事象が発生した時に直ぐ対応することはなかなか難しいと思います。 従って、どんなに単純な作業でも下記を念頭に置くことが大事です。 「チームメンバー全員」が作業の流れを把握するためのドキュメントを作成する。不明点が残らないように「チームメンバー全員」でそのドキュメントをレビューする。 自動化の仕組みはシンプルで分かりやすいようにする。可能な限り誰かの手組した 魔改造 ツールには頼らない。「チームメンバー全員」が把握出来る構成にする、かつREADMEを作成する。 上記の「チームメンバー全員」というのは、今回のTerraformバージョンアップの件はSREチームメンバーのことを指しています。当たり前のことではありますが開発チームやビジネスチームまで対象にするとドキュメントに書くべき情報量が無限に広がっていくので最初にその作業を対応する対象チームの範囲を決めた上でチームのレベルを考慮したドキュメントを作成すれば良いと思います。例えば、弊SREチームの場合は全員Terraformの仕組みや基本的なコマンドは熟知しているのでそういった情報は全て省きました。 上記が整うことで初めて「チームメンバー全員」が本当の意味で「楽」できるようになります。実際Terraformバージョンアップ一つとってもドキュメントを執筆するのは「楽」ではないですしちょいちょいコーディング関連の作業に逃げたくなりました（泣） また、自動化の仕組みはこれからの取り組みになるので「楽」するのはもう少し先になりそうです。 ということで全くTechなBlogになっておらず恐縮ですが、「楽」する前のTerraformバージョンアップ方針と運用整理、でした。 私たちのチームでは、ともに働く仲間を積極的に募集しています。少しでも興味をお持ちいただけましたら、ぜひカジュアル面談からご応募ください！ Application Developers www.wantedly.com SRE www.wantedly.com *1 : 新卒社員ではございません *2 : SREチームでは一週間をサイクルとして各メンバーのタスクを計画しています。その計画をメンバー全員で話し合って決める会です。 *3 : 本記事執筆時点で、弊チームではPublic RegistryのModule、HCP TerraformのPrivate RegistryのModuleは利用していないのでModuleのバージョンについては対象外としています。

みなさん、こんにちは！myTOKYOGAS フロントエンドチームに所属しております相川と申します。2024年4月16日〜17日に「 DevOpsDays Tokyo 2024 」が開催されました。テッ クリード の中島がスピーカーとして登壇するため、ぜひ応援に行かせて欲しいと立候補し無事許可をいただいたので参加してきました！業務調整してくださったチームの皆様本当にありがとうございます！ はじめに DevOpsDaysとは DevOpsのグローバルトレンド 自動生成を活用した、運用保守コストを抑える Error/Alert/Runbook の一元集約管理 トランクベース開発の導入で見えた、DevOpsの技術・プロセス・文化との繋がり セキュリティプラクティスの継続的な実践〜セキュアなシステム構築を目指して〜 まとめ   はじめに 今回の記事では、カンファレンスに参加した学びを、一部セッションをピックアップして発信していきます。ちなみに、相川はDevOpsという言葉は知っていたものの、 フリーランス として勤務していた時は強く意識することはありませんでした。ただ内製開発を進めていく上でDevOpsは重要なテーマであり、 東京ガス に入社してからは特に強い関心を持っていました。私の経歴に興味がある方は入社エントリの記事をぜひご覧ください。 tech-blog.tokyo-gas.co.jp DevOpsDaysとは DevOpsDaysとは、なんですか？という方もいらっしゃると思います。私もそうでした。DevOpsDaysとは、世界各地で開催されているグローバルカンファレンスで、ソフトウェア開発、ITインフラ運用、そしてDevOpsの実践にフォーカスしており、最先端のテク ノロ ジの活用法はもちろん先進企業で必要とされてきた背景までも理解し、正しく組織内に展開するための洗練された知見を得られるとのことでした。また、「DevOpsを実践して得た知見を共有する場である」ともDevOpsDays Tokyoの発起人である川口恭伸さんは話されていました。 Home | devopsdaystokyo から一部抜粋させていただいております。 ちなみに会場は大崎ブライトコアホールというところです。チケット購入時にオンサイトとオンラインの選択ができます。今回私は、オンサイトで参加しました。 余談ですが、お弁当が出ます。しかも、今半です。美味しすぎて感動しました。 それでは、学びを得たセッションについて書いていきます。   DevOpsのグローバルトレンド DevOpsに関するトレンドを知れるセッションでした。The State of DevOps Report2023や国内外の論文・カンファレンスから一部抜粋して話されていました。中でも気になった内容は、以下です。 ユーザー中心で開発を進めるチームはデリバリー速度や仕事への満足度は向上するが、 燃え尽き症候群 になりやすい 機能中心で開発を進めるチームは、より 燃え尽き症候群 になりやすい バランスをとっているチームもいるが、そうなるとデリバリー速度がユーザー中心で開発を進めるチームよりは劣る あまり意識していなかったのですが、これはそうだなと思える経験があったのでユーザー中心と機能中心の開発の進め方のバランスについてはチームで考える必要があるなと気付かされました。 自動生成を活用した、運用保守コストを抑える Error/Alert/Runbook の一元集約管理 こちらのセッションでは、アラートの適切な設定と迅速な対処の重要性を強調しつつ、エラー情報と対処方法を一元管理し、自動化することの利点について話されていました。印象に残っている内容は、アラートの対応を属人化させないことの重要性です。アラートが発生した際に、誰もがすぐに行動に移せるようになるためには、RunBookを用意することが効果的だと話されていました。 当チームでも、RunBookの導入は大きなメリットがありそうだと感じました。アラートへの対応を属人化させず、チーム全体で迅速に対処できる体制を整えることは、サービスの安定運用において重要なので取り組んでいきたいと思いました。 speakerdeck.com トランクベース開発の導入で見えた、DevOpsの技術・プロセス・文化との繋がり トランクベース開発の導入するまでにぶつかった課題やどう乗り越えたかの実体験を共有してくださるセッションでした。フロントエンドのプルリク エス トがマージされるまでに2ヶ月以上かかってしまう課題があり、リリーストグルの実装・タスク細分化の取り組むことでリードタイムの短縮を図ったそうです。また、リードタイム短縮を目的としたFour Keys改善チームを結成したもののメンバーからリードタイム短縮だけがやるべきことではないと反発があったそうです。そこで、チームの目的を「リードタイムの短縮」から、「顧客により多くの価値を届けること」に変更したというエピソードが興味深かったです。 このセッションを通じて、トランクベース開発を導入する理由やリードタイムを短縮する目的などの背景をチームメンバーに伝え、納得感を持ってもらうことの重要性を再認識しました。これは常に意識しておくべきポイントだと感じました。 speakerdeck.com セキュリティプ ラク ティスの継続的な実践〜セキュアなシステム構築を目指して〜 このセッションでは、DevOpsの実践におけるセキュリティ向上のために、OWASPのDevSecOps lifecycleに沿ったプ ラク ティスを取り入れる方法と、その実践における課題と乗り越え方について話されていました。DevSecOps lifecycleの各フェーズで実施をお勧めする手法を紹介し役立つ書籍の紹介をしてくださいました。このセッションで特に興味深かったのは、CI/CDへのセキュリティ活動の組み込み方でSCAやSAST・DASTなどのテスト手法を取り入れることで早期にセキュリティ問題を検出し、対処することが重要であるということでした。 当チームでは、OWASP ZAPを使用したDASTの自動化に取り組んでいるところです。そのため、このセッションで紹介されたセキュリティプ ラク ティスは非常に参考になりました。一方で、カオスエンジニアリングなど、まだ取り組めていない活動もあったのでチームで相談してこれらも取り入れていきたいと思いました。 speakerdeck.com まとめ カンファレンスの参加自体初めてだったので全てが新鮮でした。お弁当も美味しかったし各セッションも学びのある内容が多かったです。当チームに導入できそうな内容もあったので取り入れていきたいなあと思いました。今回はDay1の内容を書かせていただきました。次回はDay2の内容について書いていきます。   もし 東京ガス に興味を持っていただけましたら、ぜひ以下をご覧ください。 Application Developers www.wantedly.com SRE www.wantedly.com それでは、最後までお読みいただき、ありがとうございました！

はじめまして！ 東京ガス リビング戦略部の SRE チームに所属しております迫田と申します。 私は2024年1月に 東京ガス に入社し、現在 myTOKYOGAS フロントエンドのインフラ運用やマイクロサービスプラットフォームの構築を担当しています。 今回の記事では、Terraform を活用したインフラ環境の構築についてご紹介します。 Terraform とは？ チームにおける Terraform の使い方 なぜ AWS 環境でも Terraform を採用したのか 理想と課題 さいごに Terraform とは？ HashiCorp 社が提供する Infrastructure as Code (IaC) ツールで、 パブリッククラウド をはじめ、様々なインフラ設定をコードで管理することができます。 www.terraform.io チームにおける Terraform の使い方 myTOKYOGAS フロントエンドでは、基本的に Terraform を用いて Azure 環境を構築しています。Terraform コードは GitHub 上で管理し、 GitHub Actions を実行することで実際の環境を構築しています。ローカル端末での  terraform apply の実行を避けることで、いつ誰が環境に手を加えたのかといった履歴がすぐにわかるようになっています。 また、現在私たちのチームでは AWS 上で Amazon EKS を中心としたマイクロサービスプラットフォームを構築しているのですが、構築のためのツールとして Terraform を採用しました。 マイクロサービスプラットフォームの詳細については以下の記事をぜひご覧ください。 tech-blog.tokyo-gas.co.jp なぜ AWS 環境でも Terraform を採用したのか AWS における IaC といえば、 AWS CloudFormation や AWS Cloud Development Kit (CDK) も選択肢としてあげられますが、私たちのチームでは、以下の理由で Terraform 導入を決めました。 myTOKYOGAS フロントエンドで Azure を Terraform で構築・管理しており、チーム内にノウハウが蓄積されていること AWS や Azure に限らず、当チームが使用している他のプロダクト (Datadog, PagerDuty 等) も Terraform で構築・管理できること また、4月より Terraform に非常に明るいメンバーが仲間に加わったことも理由の一つです！ ただし、一度 Terraform に決めたからずっと使い続けるというわけではなく、よりチームにとって適したプロダクトがあればチーム内で相談しつつ、常に柔軟性を持って最善な選択をしていきたいと考えています。 理想と課題 IaC の大きなメリットの一つは、インフラの状態を宣言的にコードで表現できることだと考えています。そして一度作成したコードを複製すればすぐに新しい環境が出来上がる、という状態が理想だと思っています。素早くインフラ環境を用意できるようになれば、アプリケーションの改善や新機能追加のスピードも上がり、結果としてお客さまへの価値提供を早めることができます。また、必要なときに必要な環境を用意できるようになれば、 クラウド 利用料の削減にもつなげることができます。 しかし、Terraform 以外の方法で作成するリソースがあると順番を意識して構築する必要があったり、 秘密鍵 やパスワードなどセキュリティリスクを鑑みると Terraform で管理すべきではないリソースがあったりと、単純にコードを複製するだけではすべてのリソースを構築することができない課題に直面しています。 少し細かい話になってしまうのですが、具体例を一つ紹介します。私たちの Amazon EKS クラスタ には AWS Load Balancer Controller が導入されているため、 Kubernetes リソースの Ingress を作成することで、 クラスタ 外部からの通信を受ける Application Load Balancer (ALB) を作成しています。 tech-blog.tokyo-gas.co.jp 独自ドメイン を設定し、 HTTPS で ALB に接続したいため、 Amazon Route 53 での A レコード作成、 AWS Certificate Manager での証明書発行が必要になります。また、外部からの攻撃を防ぐために AWS WAF を ALB に紐づけることも求められます。これらの AWS リソースも Terraform で作成するのですが、A レコードは ALB が作成された後でないと登録できないため、まずは証明書と WAF を先に Terraform で作成し、次に EKS クラスタ 上に Ingress をデプロイすることで ALB を作成し、最後に ALB の DNS 名を A レコードに登録する、という手続き的な方法で構築をすることになります。 *1 今のところ一つ一つの作業の負荷は大きくはないのですが、このように手順に従って構築する項目が増えると、宣言的な表現の良さが失われ、人為的なミスや構築スピード低下につながるので本来は避けたいと考えています。今回の例に限らず、Terraform の世界に閉じないリソースをどう管理していくのかが大きな課題であり、チームで日々ディスカッションしながら自分たちにとって最適なプ ラク ティスを模索しています、、、！ さいごに ご覧いただいたとおり、私たちのチームでは Terraform を活用して AWS や Azure の環境をなるべく宣言的に構築・管理しています。一方、様々な課題にも直面しており、どうすればより早く・正確に環境を用意し、お客さまにいち早く価値を提供できるかを日々チームで議論しながら検討を進めています！ 私たちのチームでは、ともに働く仲間を積極的に募集しています。SRE のみならずソフトウェアエンジニアのポジションもございますので、少しでも興味をお持ちいただけましたら、ぜひカジュアル面談からご応募ください！ Application Developers www.wantedly.com SRE www.wantedly.com 最後までお読みいただきありがとうございました。また次回の記事でお会いしましょう！ *1 : Terraform で Ingress を作成するという方法もありますが、ArgoCD を用いた GitOps を実現するために Kubernetes リソースは Terraform とは別のライフサイクルで管理したいと考えています。これも構築や運用を進める中で柔軟に方針を決めていきたいと思っています。

24年度よりエンジニア リングマ ネージャー兼SREチームリーダーとして活動を開始した杉山です。今回は新年度ということで、ポエムを書いてみました。 我々のチームは、24年度からリビング戦略部という部署に移りました。この部署は B2C 分野における様々な施策を牽引する役割を担っており、我々のチームも myTOKYOGAS の枠を超えて、新たなチャレンジを期待されています。4月には新たな仲間もジョインし、スタート ダッシュ で転ばぬよう、今この瞬間も駆け抜けています。 しかし、掲げている大きなミッションは変わっていません。それは「お客さまに提供するプロダクトの価値をエンジニアリングで向上させること」です。 ソフトウェアファーストの時代と言われて久しいですが、様々な環境変化の中で、ソフトウェアエンジニアに対する期待はますます大きくなっていると感じています。その期待を受け、我々のチームも拡大をし始め、今年度の採用目標もかなりのストレッチゴールが設定されました。しかし、これは会社からの大きな期待値でもあると受け止めています。（もちろん、プロダクトの開発や価値はエンジニアの人数で決まるものではありません。） その中で、ビジョンを掲げ、ミッションを明確にし、同じ価値観・原則をもって働くことは大切だと考えています。ミッションは前述のとおりですが、私たちのビジョンはなにか。 それは「事業とエンジニアの融合」です。事業会社での内製開発は、ただエンジニアが事業会社にいるというだけではありません。ソフトウェアエンジニアとしての技術を高めながらも、事業 ドメイン に deep dive する。これがなければ、外から来た我々が「DX をやるぞ！」と声を大きくしても、「エネルギー事業のそんなことも知らないの？」と言われてしまうからです。 一方、融合というからには、これまでのビジネス部門の方々にも、ソフトウェアのことを知ってもらう必要もあると考えます。正直なところ、以前の中島の投稿 *1 にもあるとおり、私が入社した頃は、今のようなチーム状態になるとは予想もしていませんでした。この化学反応を、新しい部でも続けていきたい。さらに部を横断し、越境して波及させていくことで、 東京ガス という会社での真の DX を実現できると信じています。 それでは、チームの価値観・原則はなにか。大きく三つ定義しました。 お客さま起点 プロダクト志向 圧倒的当事者意識 最後はどこかで見たことがある気もしますが、今の仲間はエンジニアのみならず、PdM/PO はもちろん、デザイナーやプロパーの方々も含め、みなさん本当にお客さまに真摯に向き合っていると感じています。だからこそ、お客さまとの接点がリアルからデジタルに変わっていく中、ソフトウェアの重要性を感じ、みんなが同じ方向を向いていけるのだな、と。 さらに、エンジニアリングも最終的にはお客さまに届けるプロダクトの価値を高めるための手段であるという志向も、結果としてエンジニアリングの力を高めていると考えています。なぜなら、お客さまのことを考えたとき、より速く新しい機能のデリバリーを行い、安定した信頼性あるプラットフォームを構築する必要があり、そのためには高度な技術や自動化の力を活用しなければ、実現できないからです。 これらは、最終的にどれだけ当事者意識をもって行動しているのか次第だと思います。熱い想いを持っているからこそ、行動に変えて、上に述べたようなことを実現できる。 これら価値観をもって、24年度も我々のチームはますますのチャレンジをしていきたいと考えています。私自身のミッションは、チャレンジを実行する仲間が快適に働くことが出来る環境を整え、いわゆる JTC における大きな壁と向き合い、仲間がお客さまへの価値提供に集中できるようにすることです。まだまだ未熟で、力が足りない・・・そう感じる毎日ですが、仲間から「楽しくやれています」「ありがとうございます」と言われると、言葉にするのは恥ずかしいですが、とても嬉しいですし、こちらこそ感謝の気持ちでいっぱいです。 こんなポエムになってしまいましたが、24年度もみなさんに当チームの活動など、このブログでお届けしていきたいと思っていますので、ぜひ読んでいただけたら幸いです。 最後までお読みいただき、ありがとうございました！ 新たな仲間を募集しています！ こんなポエミーなチームは、新たな仲間を募集しています！ともにエネルギー プラットフォーマー を目指したい！事業とエンジニアの融合をしたい！そんな熱い想いをもった方はぜひお気軽にカジュアル面談からご応募ください！ www.wantedly.com www.wantedly.com *1 : Tech Lead 中島の想いが込められた投稿です。未読の方はぜひお読みいただけたらと思います。 tech-blog.tokyo-gas.co.jp

はじめまして！モバイルアプリチームを担当している北沢です！ 内製開発チームは複数のチームで構成されており、私は「モバイルアプリチーム」での開発を担当しています。 東京ガス が掲げている大きな目標である「『CO2ネット・ゼロ』をリード」に貢献すべく、お客さまへの新たな価値提供をモバイルアプリによって実現していくために発足したチームです。 今はまだプロダクトの内容についてはご紹介できないのですが、技術スタックや開発手法などチームがどのような形で日々開発を行なっているのかをご紹介できればと思います。 開発の流れ プロダクトビジョン、行動規範 スクラムイベント コミュニケーション 技術スタック さいごに 開発の流れ モバイルアプリチームでは スクラム を採用し、1 スプリント 1 週間で開発を行っています。 内製開発チームではドキュメント管理にはNotion、オンラインホワイトボードとしてMiro、タスク管理ツールではLinear、コミュニケーションツールにはSlackといったツールが導入されており、私たちのチームでもそれらのツールを有効活用しながら開発を進めていいます。 プロダクトビジョン、行動規範 プロダクトのビジョン、 スクラム で出たワーキングアグ リーメント や DONE の定義やスプリントプランニングやレビューでの議事録、 システム アーキテクチャ やコーディングルール、そしてチームでの行動規範といったものは Notion でまとめて、チーム全員がいつでも確認できるようにしています。   チームのNotion スクラム イベント スプリントプランニング、デイリー スクラム 、スプリントレビュー、プロダクト バックログ リファインメント バックログ は Linear というタスク管理ツールで管理しており、これを用いてプランニング、デイリー スクラム など各セレモニーを行っています。 Linear はサイクル(≒スプリント)と呼ばれる期間を区切った開発管理が可能なツールです。 このサイクルには名前をつけることができ、スプリントプランニングでキャ ラク ターの名前などをつける等を行い、コミュニケーションの促進を図っています。 本来はスプリントゴールを意識できるようなスプリント名をつけるのが良いと思いますが、スプリントプランニングなどで自分がこれだと思うキャ ラク ターをプランニングポーカーのように出し合うのは なかなか面白く、スプリント開始時にチームの盛り上げとして機能していると感じています。 linear.app Linearの画面 レトロスペクティブ レトロスペクティブでは、Miroを使用して振り返り実施しています。「 KPT 」 フレームワーク を用いて振り返りを行うことが多いですが、 不満や不安が溜まっていそうなときは「象、死んだ魚、嘔吐」を行うなど状況に応じて振り返りの フレームワーク を変更しています！ 象、死んだ魚、嘔吐 コミュニケーション スクラム イベント以外でのコミュニケーションは、Slackのハドルを活用しています。 必要に応じてモブプロや ペアプロ をしたり、時には雑談をしたりしながら開発を進めています。 リモートワークが多くオンラインでの対応が多いチームなのですが、ツールを活用しチーム内では活発なコミュニケーションを行うことができています。 技術スタック モバイルアプリチームでは、Flutter を採用して開発を進めています。 昨今のモバイルアプリエンジニアの採用の難しさに加え、 iOS と Android の両方で動作するアプリを同一のコードベースから開発できる クロスプラットフォーム での開発は、少人数で開発を進める内製開発チームにマッチしていると判断しました。 開発を進める中で、単一コードで UI デザインを統一して開発できるため開発効率も良く、必要に応じて OS 別に実装できる柔軟性もあり、何より「こういう UI あるかな、こういう UI の設定できないかな」と思って探すと Flutter 側で実装されており可能だった、というような体験が多いことから、開発体験が良い フレームワーク だと感じています。 今回の記事では詳細な内容についてはお話ししませんが、今後はFlutterの開発事例なども記事にしていきたいと思います。 さいごに 今回はモバイル アプリ開発 チームの開発の流れや技術スタックについて軽くご紹介させていただきました。 内製開発チームでは、モバイルアプリについても内製化を今後推進していきます。 現在ソフトウェアエンジニアやSREのポジションにて積極的に採用を行なっています。 Webエンジニアだけでなく、モバイルエンジニアも対象ですので、ぜひご興味がある方は以下をご覧ください。 Application Developers www.wantedly.com SRE www.wantedly.com

はじめまして！ 東京ガス でmyTOKYOGASフロントエンドチームを担当している中嶋です！ 本稿では、当チームのプロダクト開発において、パッケージ更新とリリース作業を取り上げて、内製開発の様子をご紹介させて頂ければと思います。 パッケージ更新について Dependabotによる自動更新 コンテナのセキュリティ脆弱性診断について リリース作業について テスト用の検証環境 ブランチ運用について デプロイ作業について おわりに プロダクトの技術スタックについては、こちらをご覧ください。 note.com パッケージ更新について パッケージ更新は地味な作業かもしれないですが、更新せずに長期間に渡って放置しておくとセキュリティに関する 脆弱性 の問題や重大なバグの修正が見落とされるリスクがあります。そのため、定期的に更新しながらプロダクトに反映し続けていくための体制や運用を整えていくことが重要かと思います。我々のチームでは基本的に1Sprint2週間のサイクルで回しており、新規機能開発やバグ修正などのリリースがない場合でも、アプリのパッケージ更新やコンテナの 脆弱性 診断を定期的に行いプロダクトに反映していくために、基本的に1Sprintで1回以上は定期リリースを行う方針で開発を行なっております。 Sprintのスケジュール Dependabotによる自動更新 パッケージ更新作業については、基本的には「 dependabot 」を利用しています。dependabotを導入することによって、依存するパッケージのアップデートを定期的にチェックすることができます。また、dependabotによって自動生成されたPull Request（以下、PR）では、 changelog や対応するコミットの内容を確認することができます。 dependabotが自動生成したPull Request また、PRの作成をトリガーとしてテストコードを実行する Github Actions（CIジョブ）を用意しているため、dependabotによるPRが自動生成されると、自動的にテストコードが動いて機能面で リグレッション が発生していないかを確認することができます。 テストコードを実行するCIジョブ 当チームのプロダクトはフロント画面もBFFもTypeScriptを採用しているため、どちらもパッケージマネージャはnpmを利用しています。どちらもマイナーバージョンの更新から検知するように設定しており、BFFは1日1回の間隔で定期実行しています。フロントエンドで利用しているパッケージに関しては更新頻度が多い傾向もあって、現在は1週間に1回の頻度で定期実行しています。npmで管理されるパッケージには実際の稼働環境で使われているdependenciesと、開発時のみに利用されるdevDependenciesの2つがあります。dependenciesのパッケージに関して更新があった場合は、テストコードが全て動いていることを確認し、 changelog の内容をチェックした上でマージするようにしています。一方のdevDependenciesのパッケージに関しては定期実行を待たずnpm-check-updatesなどのツールを使って一括でまとめて手動更新することもあります。 dependenciesのパッケージについては、プロダクトのコードのどの部分で、どの機能に依存しているのかを把握しておくことで、ある程度はパッケージに依存する機能に関するテストコードを書くことも可能かと思います。しかし、メジャーバージョンが更新されて 後方互換 性が失われるような変更が発生してしまうと事前に用意したテストコードも意味がなくなり、テストコード自体を改修するコストが生まれてしまうため、費用対効果としてはあまり採算が合わないと思います。そのためCIで動かすテストコードでは、パッケージが提供する機能に焦点を当てず、あくまでプロダクトとして期待される機能要件を満たしているかという観点で書くように心がけています。 コンテナのセキュリティ 脆弱性 診断について フロントチームの開発領域として、バックエンド API から返却されるデータを統合的に集約してフロント画面に描画しやすいように整形する責務を担うBFF（Backend for Frontends）があります。BFFは、Azure App ServiceのWeb App for Containersの上で動いています。全体の構成としては、以下のイメージになります。 myTOKYOGASのシステム構成 コンテナは VM と比較するとポータビリティの観点で優れている一方でゲストとホストの分離レベルが弱いため、セキュリティ 脆弱性 に対してはより細心の注意を払う必要があると思います。当チームでは、コンテナイメージのリスクについて、CIのテスト実行時と定期的に実行されるジョブを用いて 脆弱性 診断を実施する仕組みを導入しています。CIのワークフローとは別に定期実行のジョブを用意して 脆弱性 診断を行うことで、コンテナイメージの作成時だけでなく作成後に新しい 脆弱性 が見つかった場合にも検知できる体制を整えています。 脆弱性 診断のワークフロー コンテナイメージの 脆弱性 診断ツールとしては、Trivyを利用しています。CIのテスト実行時では、 脆弱性 の重大度レベル（severity）はMEDIUM,HIGH,CRITICAL、 脆弱性 タイプはosとlibraryを設定しています。また、開発の流れを止めないよう修正がまだ提供されていない 脆弱性 に関しては、エラーとしない設定にしております。一方で、定期実行するジョブの方では全ての重大度レベル（severity）を検証して特定のSlackチャンネルに通知する運用を行なっています。 脆弱性 診断結果のslack通知 すでに解消済みのバージョンが存在する 脆弱性 が見つかった場合は、コンテナイメージを再ビルドすることによって最新版のパッケージが反映されて、 脆弱性 のエラーが解消したことを確認できたら、デプロイを行う流れになります。一方で、新たにまだ未解消な 脆弱性 が見つかった場合は、エンジニアが 脆弱性 の内容を精査し、深刻度に応じて個別に対応要否を検討します。 リリース作業について テスト用の検証環境 次に、検証環境について簡単にご紹介させて頂きます。リリースを頻繁かつ継続的に実施していく上で、テストを行うための検証環境の整備は不可欠かと思います。現在はWeb用、モバイル用、社内向けの3種類のデプロイ先があり、それぞれに対して複数の検証環境を用意しています。デプロイ先と環境数を掛け合わせると10種類以上の検証環境で日々の開発と並行しながらテストが実施されています。実際にテ ストアカ ウントを使って動作確認を行うチームがいるため、各関係者と連携しながら機能開発を進めていきます。そのため、基本方針として開発を行うフロントチーム側でレビューが完了し、デプロイ可能な状態になったとしてもすぐにマージはせず、現在の動作確認の対応状況に応じて適宜必要なものだけをマージしていくような流れとなっています。以下が全体のイメージになります。 デプロイ先と検証環境のイメージ ブランチ運用について ブランチ運用については、基本的にdevelopをデフォルトブランチとしてレビュー済みになったPRを取り込んでいき、最新版のdevelopブランチを各検証環境に反映する流れになっています。検証環境には、モック用のサンプルデータを利用する環境とバックエンドや外部サービスの API と疎通して実データを利用する環境に大別されます。検証作業は各機能開発やバグ修正などの内容に応じて、それぞれの環境を適切に使い分けながら実施されています。すべての検証作業が無事に完了したら、mainブランチに反映して本番リリースを実施する流れになっています。 ブランチ運用 開発者はdevelopからfeature, hotfix, pkgなどの 命名規則 に従ったブランチを切り、Linearで管理されたチケット（機能開発, バグ修正, パッケージ更新など）に着手していきます（タスク管理については、 こちら でも触れています）。これらの 命名規則 に従ったブランチを作成することでPRを作成する際に自動的に変更内容を表すラベルが付与される仕組みになっています。 Pull Request(サンプル)に自動付与されるラベル 本番リリースが完了した後にリリースノートを作成します。その際にPRに付与されたラベルごとに変更内容を整理して自動でリリースノートを作成するジョブを動かしています。また、リリースノートを作成する際にはセマンティックバージョニングに基づいてバージョンタグを発行します（ 後方互換 性の有無や修正内容を加味してリリースごとにバージョンを付けて管理しています）。 リリースノートの作成(サンプル) デプロイ作業について デプロイする資材としては、Next.jsの静的なビルド（Static Exports）によって生成されたwebアセットとNestJSを動かすコンテナイメージが基本になります。それぞれAzure Static Web Appsと、Azure App Serviceにデプロイするための Github Actions（CDジョブ）が定義されているため、それらを実行するだけでデプロイ作業は完了します。 Azure Static Web Appsへのデプロイは、ビルドからデプロイまでを 一気通貫 で行ってくれる Github Actions（ Azure/static-web-apps-deploy ）が用意されているため、それを利用するだけで簡単にデプロイ用のワークフローを構築することができます。また、デプロイ前後ではDatadogのRUM Development Trackingを利用して最新版のアプリが適切にエンドユーザーへ配信されたことを確認しています。 Azure Static Web Appsのデプロイ確認 Azure App Serviceへのデプロイは、ダウンタイムを発生させないよう スロット機能 を利用したBlue-Greenのデプロイ方式を採用しています。リリースの前日にプレスロット環境に事前にデプロイしておき、当日は運用中スロットへ スワップ 作業のみを実施する方針にしています。また、リリース直後に何らかの不具合が発生した場合は、再度 スワップ を実行するだけで ロールバック できる状態になっています。 Azure App Serviceにはアプリで利用される 環境変数 を手動で登録しています。一方、アプリ側では.envファイルを利用した 環境変数 の管理を行っています。新規機能開発に伴いアプリ上で新しい 環境変数 が追加されると、Azure App Service側で 環境変数 の追加設定を忘れてしまう可能性が考えられます。そのため、当チームではプレスロット環境へデプロイする際に 環境変数 の差分チェックを行うことで不整合が発生しないようにしています。 環境変数 の差分チェック また、 スワップ 時にも変更前と変更後の 環境変数 の差分をチェックすることで、意図しない変更が発生しないように細心の注意を払っています。 スワップ 時の 環境変数 の差分確認(サンプル) Blue-Greenのデプロイ方式を導入することで、ダウンタイムの発生を防ぎながらデプロイにかかる実行時間も短縮することができます。 おわりに 今回は、パッケージ更新とリリース作業に焦点を当てて、それぞれの詳細に触れるというよりも、全体の流れや大枠のイメージを掴んで頂けるよう、フロントチームにおける開発業務の一部をご紹介させて頂きました。フロントチームはまだ発足したばかりの段階で、定まったルールや方針なども少なく、意見を出し合いながら柔軟に変化しながら成長していく過程にあります。また、解決したい課題や挑戦したいことなどもたくさん抱えている状況です。個人的な感想になってしまいますがチームの雰囲気としては非常に良く、自由に意見を言い合える風土があり、エンジニアとして働きやすい環境だと感じています。 現在ソフトウェアエンジニアのポジションにて積極的に採用を行なっています。 Application Developers www.wantedly.com SRE www.wantedly.com もし少しでも興味を持って頂けたら、カジュアル面談からでも良いのでご連絡頂けると嬉しいです！ぜひ、一緒により良いプロダクトを開発していきましょう！

みなさん、こんにちは！myTOKYOGAS フロントエンドチームに所属しております相川と申します。 2024年1月に 東京ガス の仲間入りをし、早3ヶ月が経ちました。 このエントリでは、 フリーランス から 東京ガス に入社するに至った経緯について、拙い文章で恐縮ですが書いていこうと思いますので最後までお読みいただけたら幸いです。 これまでの経歴 東京ガスとの出会い なぜ東京ガスに入社したのか 入社後の気づき オープンなコミュニケーション文化 フレキシブルな働き方 貸与されるPCのスペックが高い 今、何しているのか さいごに これまでの経歴 入社以前は フリーランス エンジニアとして活動しておりました。 2022年10月に フリーランス の道を歩み始め、約1年後の2024年1月に 東京ガス へ正社員として入社しました。 フリーランス になる前は、SES会社で業務委託エンジニアとして勤務しており、主にバックエンド開発に従事していました。 使用言語は主に Java で、Webアプリケーションの開発を手がけていました。 実は大学卒業後、私のキャリアは多岐にわたっています。 ビルメンテナンス会社で設備管理をしたり、生命保険会社で営業を経験したり、ダーツプロを目指すために会社を辞めてフリーター生活を送ったこともあります。 振り返ると、自分でも驚くほど多彩な経歴を歩んできたと思います。 そうした経験を経てエンジニアとなり、現在に至るまで約5年が経ちましたが、元気に活動を続けています。 東京ガス との出会い フリーランス として活動を始めて間もない頃、myTOKYOGASのフロントエンドリプレイス案件への参画を機に、 東京ガス との初めての出会いを果たしました。 当時、私は Java 以外の プログラミング言語 にも挑戦したいという強い意欲を持っており、特に個人的に学習していたTypeScriptを使用しているプロジェクトを探していました。 面談の際に、NestJSやGraphQLを採用していることを聞き、これはまさに挑戦したい技術だと感じました。 「求めている人物像に合致するのであれば、ぜひ参加させてください！」と熱意を伝え、そのプロジェクトに参加することができました。 プロジェクトで用いられている詳細な技術スタックについては、別の記事で詳しく説明していますので、ぜひそちらもご覧ください。 tech-blog.tokyo-gas.co.jp なぜ 東京ガス に入社したのか 前述の通り、入社前に約1年間 フリーランス としてmyTOKYOGASプロジェクトに参画しておりました。 その間に、 東京ガス で働くエンジニアたちの、プロダクトを改善しようとする熱意と当事者意識の高さに強く影響を受けました。 私自身、なりたいエンジニア像みたいなものが明確ではなかったのですが 東京ガス で働くエンジニアの姿を見て自分がなりたいエンジニア像はこれだ！と思ったのが入社するに至った一番の理由です。 また、myTOKYOGASの開発に関わる中でプロダクトへの愛着がわき、それをさらに良くしていきたいという気持ちが芽生えていたことも大きかったかなと思います。 ただ、正直迷いと不安はありました。 これから技術を磨きながら フリーランス としてやっていくぞ！と息巻いていたタイミングだったのもありますし、プライベートな話ではありますが、子供が生まれたばかりだったので フリーランス のような柔軟な働き方ができる方が都合が良いなと思ったり、、かなり悩みました。 この辺りの悩みはカジュアル面談の機会を設けてくださったことでキャリアのこと、子育てのこと、会社の制度のことなど相談に乗ってもらうことで解消しました。 東京ガス に少しでも興味を持ってくださっているのであればぜひ、気軽にカジュアル面談をしてみてくださいね。 環境が大きく変わることへの不安は最後まで残りましたが、内製開発チームの立ち上げ初期に関われる機会は稀だと思い、また1年間一緒に開発してきたメンバーとまだまだ一緒に働きたいという思いが、入社を決める大きな要因となりました。 最終的には、妻の支えと後押しがあって、入社を決断しました。いつも支えてくれてありがとうございます。 入社後の気づき オープンなコミュニケーション文化 チーム内では、誰もが自由に意見を交換し、 ペアプログラミング やモブプログラミングを通じて知識を共有するオープンな文化が根付いていました。 また、個人のtimesチャンネルも作ってくださり好きなことを呟けるような環境が整っているのでリモートワークをしていてもコミュニケーションは活発に取ることができています。 フレキシブルな働き方 フリーランス 時代の自由な働き方に慣れていた私ですが、所属している組織ではスーパーフレックス制度のおかげで、生活リズムを大きく変えることなく、家族との時間も大切にしながら仕事を進めることができています。 子供のお迎えや通院など、プライベートな用事も気軽に対応できる柔軟性は、働く上で非常に価値があると感じています。 貸与されるPCのスペックが高い 細かな点かもしれませんが、開発PCのスペックは、開発作業を快適に進める上で非常に重要だと個人的に思っています。 私の場合、 Macbook Pro M3（メモリ36GB）を貸与していただきました。 今の所ストレスなくスムーズに開発業務ができています。 今、何しているのか 現在、私はmyTOKYOGASの運用保守と新機能の開発に取り組んでいます。 入社してすぐに、新規機能の開発を任せて頂きユーザーニーズの ヒアリ ングから要件定義、設計、開発、そして無事リリースまですることができました。 当チームでは積極的に意見を出せば新しい挑戦の機会を与えてくれる環境が整っており自分次第でいろいろな経験ができる環境だと感じています。 SESや フリーランス としてプロジェクトに関わってきた時期は、クライアントが求めるものを作ることが仕事でした。 しかし、今はユーザーの課題を解決するためにどうすれば良いかをオーナーシップを持って考えて、提案して、作っていくことができる環境にいます。 ただ作って終わりではなく、プロダクトを育てるという経験をすることができておりやりがいを感じています。 2023年11月にmyTOKYOGASはリニューアルしたばかりでまだまだ課題も山積みですがユーザー目線で考えた時に何を優先すべきかを考えながらより良いプロダクトになるように貢献していきたいと思っています。 さいごに フリーランス から 東京ガス に入社する経緯についてお話させていただきました。 少し特殊な経緯ではありましたが参考になりましたでしょうか？ 私は 東京ガス に入社して良かったと思っています。 プロダクトをより良くしていくぞという熱量を持ったメンバーと日々切磋琢磨しながら過ごすことができてとても充実しています。 もし 東京ガス に興味を持っていただけましたら、ぜひ以下をご覧ください。 Application Developers www.wantedly.com SRE www.wantedly.com それでは、最後までお読みいただき、ありがとうございました！

みなさんこんにちは、杉山です。花粉症に必死に抗う毎日ですが、気づいたら3月も残りわずかですね。同士のみなさん、がんばって乗り越えましょう！ さて今回は、 私の前回記事：Amazon EKS 導入 に続いて、少しだけ深堀りして Ingress の部分について書いてみたいと思います。 Amazon EKS の Ingress を考える ALBC + Istio 全体構成 構築してみる - ALBの作成 - Istio コアコンポーネントのインストール Gateway リソースの作成 Virtual Service の作成 実際にやってみて さいごに Amazon EKS の Ingress を考える ━ クラウド ベンダーが提供するマネージド Kubernetes をやるということは、 Ingress を考えるということだ ━ このような言葉を、偉大なる先人の方に聞いたことがあります。（ないです） EKS の構築について、当初は AWS Load Balancer Controller のみ利用して進めていました。その後、2023年末頃に Kubernetes の Gateway API が GA されたこともあって、そちらに舵を切ろうと考えていた時期もあり、実際 Ingress のことを考えている時間は長かったような気がします。 しかし、 AWS での Gateway API 実装でもある VPC Lattice は、 クラスタ ー同士の通信に使うことを主たる用途としており、外部からの トラフィック を受ける Ingress としては活用できなさそうでした。(2024年3月現在) *1 個人的には、GKE が提供しているようなロール間の責任が明確に分離される構成にしたかったのですが、 AWS ではちょっとまだ早い…ということで、他の手段を考えることに。参考までに、以下が GKE の提供しているものです。とても分かりやすいなーって思います。 引用元: https://cloud.google.com/kubernetes-engine/docs/concepts/gateway-api?hl=ja#platform-managed_gateway_per_namespace cloud.google.com さて、そんな紆余曲折を経て、最終的には AWS Load Balancer Controller (以下 ALBC) を利用したうえで、柔軟な トラフィック コン トロール が可能となる Istio を利用することになりました。前述のとおり、ALBC は最初から利用してはいたのですが、マイクロサービスが追加される際に Namespace の分割を行うと、 Ingress の標準仕様では Namespace を跨いだルーティング設定が出来ません。なので「じゃあ Ingress を Namespace ごとに作成しよう」なんてことをすると、ALBC によって Ingress 単位で ALB が作成されてしまいます。 e.g. Ingress マニフェスト apiVersion : networking.k8s.io/v1 kind : Ingress metadata : # ここで指定した namespace 内のサービスのみパスベースルーティングに指定可能 namespace : service-A name : service-A-ingress annotations : alb.ingress.kubernetes.io/scheme : internet-facing alb.ingress.kubernetes.io/target-type : ip alb.ingress.kubernetes.io/healthcheck-path : / alb.ingress.kubernetes.io/wafv2-acl-arn : arn:aws:wafv2:ap-northeast-1:123456789012:regional/webacl/xxxx-web-acl-ap-northeast-1-dev/xxxx-xxxx spec : # ここで alb と定義することで ALB が作成される ingressClassName : alb rules : - http : paths : - path : / pathType : Prefix backend : service : name : service-A port : number : 80 こういった背景もありながら、さらに今後のサービス拡大も見据えたとき、サービス間通信も発生するでしょうし、このタイミングで Service Mesh の恩恵を受けられるようにしておくのがベストだと考え、Istio を導入することにしました。Istio にした理由は、過去に運用経験のあるメンバーがいたり、 最近認定試験が出たり 、 デファクトスタンダード になっていると感じているのもありますが、最後は「SRE としてお互いにがんばっていこう！」と会話しながら決めたのを覚えています。(脳内補正が入ってるかも…) 話し合いと納得感、大事ですね！私は毎日、色々と教えてもらっており、日々感謝です。 「あれ、 AWS にしたのに、なんで App Mesh 使わないの？」という点については、最後まで悩んだのですが、ちょっとここでは書きづらいので、どこかでお話できたらと…苦笑 ALBC + Istio 全体構成 簡単な構成図は以下のとおりです。 ALBC + Istio 構成図 全体構成としては、ALB Ingress から Istio Ingress Gatewy をターゲットとして構成し、ここまでを Gateway レイヤーとして定義して、アプリケーションへのルーティングには、 Istio Virtual Service を使用しています。 Virtual Service から各マイクロサービスの Service にルーティングさせることで、一つの ALB から各サービスへ流れていくような構成となりました。以下のドキュメントにある Shared gateway のパターンです。 istio.io はじめは Istio Ingress Gateway をそのままプロビジョニングしたため、 Service type が LoadBalancer になっており、 Internal な NLB が出来ていました…これもメンバーから「杉山さん、ﾅﾝﾃﾞｽｶｺﾚ」とありがたい指摘をいただき、急いで Istio Ingress Gateway を定義している Argo CD の values.yaml に以下を追記…！持つべきものは頼れる仲間ですね。 # 一部抜粋... replicaCount : 2 autoscaling : enabled : true minReplicas : 2 maxReplicas : 4 # 急いで追記っっ service : type : NodePort 色々調べているとき、 AWS 公式のブログも非常に参考になりましたので、こちらで紹介したいと思います。 aws.amazon.com aws.amazon.com 構築してみる - ALBの作成 - だいぶ細かくなってしまうのですが、実際の マニフェスト から抜粋しつつ、続きを書いてみます。まず ALBC に ALB を作ってもらうため、以下の マニフェスト を作成します。なお、ALBC 自体は Argo CD + Helm でインストールしています。(一部抜粋しているため、そのまま使うと動かない可能性があります) # alb-istio-ingress-gateway.yaml apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : alb-istio-ingress-gateway namespace : istio-ingress annotations : # 一部抜粋... alb.ingress.kubernetes.io/group.name : istio-ingressgateway # istio ingress gateway service をターゲットとしてヘルスチェックを実施 alb.ingress.kubernetes.io/healthcheck-path : /healthz/ready alb.ingress.kubernetes.io/healthcheck-port : "15021" alb.ingress.kubernetes.io/healthcheck-protocol : HTTP alb.ingress.kubernetes.io/scheme : internet-facing alb.ingress.kubernetes.io/target-type : ip alb.ingress.kubernetes.io/certificate-arn : arn:aws:acm:ap-northeast-1:123456789012:certificate/xxxxxxxx-xxxx-xxxxxxxxx alb.ingress.kubernetes.io/ssl-policy : ELBSecurityPolicy-TLS13-1-2-2021-06 alb.ingress.kubernetes.io/wafv2-acl-arn : arn:aws:wafv2:ap-northeast-1:123456789012:regional/webacl/xxx-wafv2-web-acl-ap-northeast-1/xxxxxxxx-xxxx-xxxxxxxxx spec : ingressClassName : alb rules : - http : paths : - path : /* pathType : ImplementationSpecific backend : service : name : istio-ingressgateway port : number : 80 Istio コア コンポーネント のインストール 次に、Istio のコア コンポーネント をインストールします。具体的には以下の3種類です。 istio-base istiod istio-ingress これらも Argo CD + Helm で導入します。注意点としては、 istio-ingress のデプロイ時に istio-base と istiod が確実にデプロイされていないとエラーになることがある、というところでしょうか。Argo CD で 3種類の コンポーネント を一気に AutoSync させてしまい、依存関係が考慮されず、以下の Issues にあるように派手に転びました。 github.com これで Istio Ingress Gateway のサービスが作成されます。このサービスを前述した Ingress で指定している形となります。( name: istio-ingressgateway のところです) Gateway リソースの作成 続いて Gateway リソースを作成します。これは Helm を利用せず、以下のような マニフェスト を定義します。ここでは Istio Ingress Gateway の Pod と バインディング されるよう、 selector にて istio: ingressgateway を定義してあげます。 # sample-gateway.yaml apiVersion : networking.istio.io/v1beta1 kind : Gateway metadata : name : sample-gateway namespace : istio-ingress spec : selector : istio : ingressgateway servers : - hosts : - "*" port : name : http number : 80 protocol : HTTP 作成したリソースは kubectl get gateway.networking.istio.io -n istio-ingress のコマンドで見つけることが可能です。次は Virtual Service に トラフィック を転送させていく必要がありますが、以下のドキュメントにも記載されているように、Virtual Service が Gateway にバインドされることで、 トラフィック 転送を制御することが可能になっています。 istio.io The Gateway specification above describes the L4-L6 properties of a load balancer. A VirtualService can then be bound to a gateway to control the forwarding of traffic arriving at a particular host or gateway port. 実際の構築時には、ここまで構築するのに結構な時間が掛かってしまいました… Gateway のところが理解が難しく、ドキュメントを読んでいてもイマイチしっくり来なかったので、Virtual Service まで実際に作ってしまい、 Kiali を使って可視化しながら理解していきました。実際に手を動かして作ってしまうのも大切ですね…！ というわけで、ここまでで、以下のオレンジ枠内までが作成されました。最後は Virtual Service の作成です。 Gateway Layer Virtual Service の作成 Virtual Service は各アプリケーション用 マニフェスト の方に定義しています。具体的には以下のような感じです。 apiVersion : networking.istio.io/v1alpha3 kind : VirtualService metadata : name : service-A-virtual-service namespace : service-A spec : hosts : - "*" gateways : # ここでGatewayを指定 - istio-ingress/sample-gateway http : - match : - uri : prefix : /api/v1/service-A route : - destination : host : service-A.service-A.svc.cluster.local port : number : 80 前述のとおり、Virtual Service を Gateway にバインドする必要があります。これは上記コメント箇所で Gateway を指定することで、バインドすることが可能です。ここまでで、無事にサービスまで トラフィック が流れるようになりました！ Virtual Service と Gateway のバインド 実際にやってみて 理解するまでは本当に大変でしたが、実際に構築して動かしていると、こんなに便利なものはない！というのが率直なところです。多くのサービスで Istio が利用されているのも納得しました。ただ、 Kubernetes と違うサイクルでのバージョンアップ（半年ほど）があったり、Istio 自身も Gateway API の実装がベータ版で提供されていたりするので、これで終わりと満足せず、常にアップデートを追いかけ続けないといけないな、と感じています。ちょうど今、 KubeCon + CloudNativeCon Europe 2024 も開催されていますし、 ブログ を拝見して追いかけているところです！ さいごに 今回は内製開発チームの Amazon EKS Ingress について紹介しました。ここは本当に肝になるところなので、SRE チームとしても Priority を上げて対応していきたいです！年内には Istio Gateway API 実装もベータから正式バージョンになりそうですし、今のうちに検証しておきたいですね。 私たちのチームは現在、積極的な採用活動を行っています！ご興味のある方は、ぜひ以下をご覧ください。 www.wantedly.com それでは、最後までお読みいただき、ありがとうございました！また次回の投稿でお会いしましょう！ *1 : ご相談に乗っていただいた SA の方にはいつも感謝しかありません！ありがとうございます！

みなさんこんにちは！ エンジニアリングチームリーダー兼SREの杉山です。 今回は「マイクロサービスプラットフォームとしての Amazon EKS 導入」について投稿します！ 第一弾は導入にいたった経緯などをご紹介、以降は細かいところもご紹介できたらな・・・と思っています。 Amazon EKS とは？ 導入のモチベーション どんな感じで使っているのか？ 監視ツール Karpenter Bottlerocket Kubernetes は大変？ さいごに ともに働く仲間を募集しています！ Amazon EKS とは？ みなさん大好きな AWS が提供するマネージド Kubernetes サービスです。 Kubernetes コン トロール プレーンノードの可用性とスケーラビリティを AWS が自動的に管理することで、チームの運用負荷を大幅に削減してくれる素晴らしいサービスです。私自身、 Kubernetes を勉強して Certified Kubernetes Administrator を取得するまでは、実はマネージド Kubernetes サービスのありがたみをイマイチ理解しきれていませんでした。しかし勉強していく中で「コン トロール プレーンの コンポーネント 管理つらくない・・・？」「 etcd のバックアップを含めた管理まで考えるのか・・・」といったことをひしひしと感じ、改めて クラウド ベンダーが提供してくれる価値に気付き、今では毎日感謝しながら過ごしています。 導入のモチベーション どんな技術もそうかと思いますが、私たちは事業およびプロダクトをグロースさせるためにソフトウェアエンジニアとして活動しています。今回は、サービス変更の柔軟性が損なわれる現在の アーキテクチャ をなんとかするために、マイクロサービスへのチャレンジを決断しました。そしてマイクロサービスのプラットフォームとして、コンテナありきのアプリケーションチームの期待に応えるためには、コンテナ オーケストレーション が必要となります。すでに myTOKYOGAS のフロントエンドは Azure 上で稼働していますが、これは色々な事情があったがゆえ、当時の私に選択権はありませんでした。 しかし、今回のマイクロサービスプラットフォームは、ゼロからのチャレンジが出来るということで、私はもちろん、チームのメンバーも慣れ親しんでいる AWS を採用することとしました。そのため、純粋に Kubernetes のマネージドサービス同士を比較したわけではなく、ユーザーグループなどのコミュニティが活性であること、ナレッジの多さ、なにより SA (Solutions Architect) の方々自身がユーザーにとっての Trusted Advisor であることから、 AWS を選択したという背景があります。もちろん、 AWS の他サービス群も素晴らしいものが多いので、そこで不自由することは無いだろうと思っていますし、 AWS の機能アップデートは9割がお客さまの声から実現されていますので、そのあたりも AWS の強みであると考えています。 ただ、 AWS であれば ECS もありますので、EKS はオーバースペックかもしれない・・・何度かそのように考えました。しかし最終的には継続的に学習するチームの選択として Kubernetes をやっていこう！となったため、 EKS の導入に至りました。 このあたりは JAWS の LT でもお話をさせていただきましたので、以下スライドもご覧いただけたらと思います！ AmazonEKSやっていくことを宣言して自らを追い込むLT speakerdeck.com どんな感じで使っているのか？ EKS 導入にあたって、まずは小さく始めています。すでに多くのマイクロサービスが存在し、それらを移行するわけではありませんので、小さく始めて運用しながら、将来的に待ち受けるビッグイベントも早めに検証し、チームのナレッジをためておきたいと考えています（特に クラスタ ーアップグレードは・・・今から緊張します・・・！） 当初は運用負荷を少しでも削減するため Fargate の利用を考えてもいたのですが、 Istio の サイドカー が上手く機能しなかったり、色々あった末にマネージドノードグループの利用となりました。 AWS や Kubernetes 周りのエコシステムとして主に採用しているものは以下のとおりです。 AWS Load Balancer Controller Istio Argo CD Kustomize まだまだ少ないですね、今後どんどん検証を進めて導入していきたいです！上記については、それぞれ別途記事にできたらなとも思っています。 その他にも、以下のように現在進行系で進めているものもあります。 監視ツール 専用ツールの導入も考えているのですが、 Container Insights with enhanced observability for Amazon EKS を試行し始めたところでして、この評価結果をもって決めていきたいと思っています。23年11月に発表されたばかりですが、割といい感じです。どうしてもログの二 重課金 が発生してしまいますし、小さく始める今のフェーズでは充分かなと感じています。 aws.amazon.com Karpenter また、EKS ではマネージドノードグループを利用しているものの、こちらも並行して Karpenter を検証しています。提供するサービス・今後提供していくサービスは、一日を通して負荷の見込みが立たないため、Karpenter は上手くハマれば絶大な効果を生み出せるものと考えています。 aws.amazon.com Bottlerocket その他にも、プラットフォームチームが利用するマネージドノードグループの AMI として Bottlerocket を採用しています。 aws.amazon.com Bottlerocket はコンテナを実行するために不可欠なソフトウェアのみが含まれており、アタック サーフェス や管理負荷の削減が可能です。一方、ユーザーデータを設定して渡すようなことができないため、必要となった場合にワークロード用ワーカーノードの AMI が統一できなくなってしまいます。そのため、プラットフォームチームが利用するマネージドノードグループの AMI に限定している次第です。今は主に GitHub Actions の Self-hosted Runner 向けのノードグループの OS として利用・検証しており、ここは別途、メンバーから投稿してもらおうと思っています！ Kubernetes は大変？ 大変だと思います。 ただ、それはどんな技術であっても突き詰めれば同じだと思っていますし、チームで納得した上で選択したのであれば、それが最適な選択だと考えています。前述のスライドでも触れていますが、プロダクトはチームで作り上げていくものですので、そこで合意を取って進めていけるのであれば、大変さも楽しみながら進めていけるのかな、と。 また、今は Kubernetes が最適であっても、数年後、また新たな技術トレンドが出てくると思っています。よく振り子のように例えられますが、 Kubernetes に Bet するというよりも、そのときのプロダクトやチーム状況に応じて、数年後も同じ軸で判断出来るようにしていきたいです。 さいごに まずは Amazon EKS 導入の経緯・背景などについてご紹介しました！まだまだ胸を張って「マイクロサービスやってます！ Kubernetes やってます！」と言うには程遠いかもしれませんが、この小さな一歩を着実に進めていきたいと思っています！次回の投稿は、 AWS Load Balancer Controller + Istio Ingress あたりを書こうかなと思っています（予定） GitHub Actions, Bottlerocket はメンバーが書いてくれる…はずです！ ともに働く仲間を募集しています！ 私たちのチームは現在、積極的な採用活動を行っています！ご興味のある方は、ぜひ以下をご覧ください。 Application Developers www.wantedly.com SRE www.wantedly.com それでは、最後までお読みいただき、ありがとうございました！また次回の投稿でお会いしましょう！

こんにちは、 東京ガス のCX推進部デジタル マーケティング グループでテッ クリード をしております中島です。 東京ガス では「myTOKYOGAS」のリニューアルプロジェクトにおいて、事業組織内に内製開発チームを立ち上げ、2023年11月にサービスインまでやり遂げました。今では自動テストやCI/CDの稼働はもちろんのこと、内製開発チームにて２週間1スプリントでの アジャイル 開発と保守運用までを責任を持って行うことができるようになりました。 今回は我々が初めて内製化に挑んだプロジェクトであるmyTOKYOGASのリプレイスと並行して立ち上げを進めた内製開発チームについてお話ししたいと思います。 内製開発チームの立ち上げ 私は2022年5月に、今の組織で初めてのエンジニアとしてジョインしました。しかし、内製化を思い立ち、チームを立ち上げたのは私ではありません。以下の記事を書いた 東京ガス に新卒からずっと勤めているマネージャーの及川です。 note.com もちろん及川はエンジニアではありません。しかし、私がジョインする前から、この及川によってデザインの内製化や外部の方に開発はお願いするものの「自分たちで開発をコン トロール できるようにするぞ」という取り組みが行われていました。まさに、開発のことはわからないなりに「本気で内製をやるんだ」という当事者意識や熱量を持って組織変革をしようと試みている最中でした。 私は 東京ガス が５社目でさまざまな大企業で内製化に取り組んできました。その中で、うまくいったと感じる開発は、エンジニアとビジネスの距離が近く、何より現場に「当事者意識」と「熱量」があるのです。エンジニアも「ただ作る」だけでなく、「こういう機能どうですか？」と一緒にサービスのことを考える。そんなエンジニアが事業に溶け込んだ職場です。それができる空気が 東京ガス にはあるのではないか。そう考えて、面接を受けてみることにしました。 マネージャーの及川との面接は、多くの事業会社で内製化に挑戦してきた私にとって、衝撃的なものでした。「本気で内製化する。DXするんだ。このままではダメなんだ！」という熱量はもちろん、エンジニアではない及川がGraphQLやNestJSなど技術の話を自分 からし てくるのです。DXや内製化をマネージャーとして進めるべく、少しでもエンジニアの気持ちを理解し対等に話すために、 システム開発 の本を読んだり、プログラミングの学習をしたりしていたのでした。この姿に圧倒的な当事者意識と熱量を感じました *1 。それが決め手となり、私はエンジニアとして 東京ガス に入社することを決め、本格的に内製化をスタートさせることになるのでした。 開発環境の構築 入社してまず問題になるであろうと考えていたのが、エンジニアが開発を行える環境です。まずここが整備されていなければ、開発者体験が悪くなり、エンジニアは 東京ガス に来てくれない。何より私も開発ができません。しかし、エンジニアがほとんど勤務していない日系の大企業において、過去の経験からそれらの環境整備が容易ではないと感じており、最初は厳しい環境でも開発を進めていかないといけないことを覚悟していました。しかし、その予想は覆されます。 現在、内製開発チームでは以下のような開発環境で開発を行っています。 開発環境 開発端末 Macbook Pro , Windows 端末 コード管理 Github ドキュメント Notion プロジェクト管理 Linear デザイン Figma , Miro コミュニケーション Slack この中で入社後、私が導入を進言したのは、開発端末だけです。それ以外は、元からいるメンバーが自分たちで導入まで進めていました。偶然か必然か、(クリーン アーキテクチャ の本を読んでいたり)自ら趣味で システム開発 の勉強をしている社員がおり、「開発に VPN いるよね」や「CIを回すには GitHub Actions使いたいよね」などを考えて、導入まで済ませてくれていたのです。それだけではありません。開発端末を揃えるのに必要な社内の手続きはすべて巻き取ってくれたのです。エンジニアは開発に集中してもらえるようにしたいと。すでに内製化を進めようとしてくれていたメンバーのバックアップもあり、私はすぐに開発に着手することができました。 開発スコープを決める 「myTOKYOGAS」はざっくりと次のような構成になっています。 技術スタック フロントエンド React, TypeScript, Next.js, Apollo Client, Tailwind CSS BFF TypeScript, NetsJS, GraphQL, Redis, MongoDB, PostgresDB テスト Jest, Playwright インフラ Azure, AWS その他 Docker, Github Actions, Terraform, Datadog, PagerDuty, Trivy myTOKYOGASの構成 技術スタックは異なるものの、この構成は内製化前も同様であり、このプロジェクトではよりユーザに近いフロントエンドとBFFをまず内製化することでプロダクトの改善をいち早くユーザに届けることができる体制を構築するという判断がされていました。一方で、バックエンドについてはレガシーな基幹システムとのプロキシの役割を果たしていることや 東京ガス の ドメイン 知識が詰め込まれており、一旦内製化は見送られました。しかしながら、バックエンドについては、新機能のための API 開発や速度改善のための改修、老朽化したオンプレミスから クラウド 環境への移行がシステム子会社の 東京ガス iネットにより実施される計画となっていました。 この計画において、内製開発チームが担当する領域は アジャイル での開発を実施することとなっており、 東京ガス iネットが担当する領域においてはウォータフォールで開発を実施することとなっていました。そのため、サービスインは2023年11月と定められていました。開発面以外でも多方面で多くの人たちが動くことになっており、この予定は容易にずらせるものではありませんでした。 みなさん、お気づきでしょうか。そうです。 アジャイル 開発だけど、ウォータフォールに合わせて「お尻」が決まっているのです。お尻の決まった アジャイル 、私はこれを「 尻ジャイル 」と読んでいます。この状況に対して、以下を行いました。 機能の全量をざっくりでも良いので、まず出すこと。 MVPを定義し、現時点で完全に的外れな開発スケジュールとなっていないことを確認すること。 スプリント毎にベロシティを計測し、開発が間に合わないと判断されるものはROIに基づいて優先度を判断し、優先度が低いと判断された機能の開発はサービスイン後とすること。 そして、もう一つ。我々がやりたいことは、ユーザに柔軟かつ迅速に価値を届けることです。 サービスイン 後のチームで、 アジャイル 開発を行うためには、DevOpsの実現は必須。その根幹となる自動テストは必ず実現する必要があると考えていました。 アジャイル 開発を サービスイン 後の体制でも進めるためにもテストコードをしっかり書き、その 工数 も加味して開発を進めていくこと。 内製をしている以上、無尽蔵にエンジニアを増やして、スケジュールの問題を解決することはできません。 東京ガス には、これらを論理的に説明することで、理解してくれる文化がありました。これらの話をした時、「何とかしろ！」ではなく、「今取れる最善策は何か？」を一緒に考えてくれる文化がありました。開発の話だからといって、その解決をエンジニアに丸投げしてくることはありませんでした。プロジェクトの状態を常に可視化して現状を把握をできるようにしてくれたメンバー、サービスインに間に合わない機能が出てきた時、関係各所に迅速に調整に動いてくれたメンバーなど、開発以外のところで多くの人たちが力を貸してくれました。彼らの支援もあり、私はフルスロットルで開発のことに集中することができました。結果的には、開発を進めながら適宜状況判断を行い、いくつかの機能をサービスイン時は実装しないと判断することで、スケジュールに収まりそうな形で開発を進めていくことができました。 開発体制の構築とサービスインへ ある程度開発規模が見えてきた時点で開発メンバーは、私と 東京ガス iネットから出向してきてくれたメンバー、 フリーランス の数名という状況でした。開発体制においては、以下の課題が見えてきました。 インフラを構築できる人材がいない 私自身も AWS で環境構築の経験はあるのですが、主戦場はアプリケーション開発です。加えて、すぐに使えそうな クラウド 環境がAzureしかなく、Azureの勉強を今から始めながら、アプリの開発をしていては、インフラ構築が間に合いそうにありませんでした。そこで、当時 AWS に勤務していた杉山 *2 を勧誘しました。「私は会社の外からDXは起こすのは難しいと考えている。 東京ガス に面白いマネージャーがいる。ここであれば、内製化を成功させられると確信している。」と。マネージャーの及川とも会ってもらい、その熱量に触れて杉山が 東京ガス に来てくれることになりました。それ以来、彼の口癖は「これからは GAFA もいいけど、GASの時代だ！」になっています。 既存のシステム知識や ドメイン 知識が足りない 当然ですが、リプレイスには既存のシステムの知識、 ドメイン 知識が必須でした。私のような中途のエンジニアには、それらの知見がありません。そこで、既存のシステムに詳しい方に声をかけ、チームに参画してもらいました。そこに加え、すでに参画してくれていた 東京ガス iネットのエンジニアにも追加で参画していただきました。彼らの知識や人脈によって、既存システムを少しずつ解きほぐしていきました。特に 東京ガス iネットのエンジニアが内製開発チームにも参画し、既存システムとの接続のためのコミュニケーションをとってくれたこと、日々の システムエンジニア としての業務で獲得していた ドメイン 知識を使ってそれをコードに落としてくれたこと、そして内製化という急進的な取り組みにも関わらず惜しみなく既存のシステムの情報や ドメイン 知識を提供してくれたバックエンドの開発メンバーの協力は今回の内製化成功の一つのキーポイントになっています。 note.com そもそもエンジニアが足りない 開発当初、我々が作るのはBFFとフロントエンドの領域であり、BFFは画面描画などのための薄いロジックだけがのっていることを想定していました。しかし、実際に見てみると、長い歴史の中でBFFと呼ぶには画面描画などに関係ないロジックをあまりに持ちすぎていることに加え、BFFから呼び出すバックエンド API そのものが画面と密結合してしまっているものなどもあり、「料金」などのようなエンティティに相当するような情報を構成することも難しい状況でした。引き続きファットBFFになることは泣く泣く受け入れたものの、これをそのまま別言語に置き換えるようなリプレイスをしてしまっては、何かをやりたいと思った時、その改修がウォータフォールで開発を行うバックエンドにも及んでしまう。 ウォーターフォール と アジャイル 開発が混在する システム開発 において、その２つの結合度が高くなると、 アジャイル 開発はできない。完全には防ぐことはできなくても、それは緩和しないといけないと思いました。しかし、それらの改修もするとなると、それなりの 工数 になることが想定されました。そこで、社員のエンジニア採用を進めるとともに、 フリーランス のエンジニアにもご参画いただき、開発体制を増強していきました。 こうして内製化へのピースが揃い、2023年11月のサービスインに向けて開発が加速していきました。 サービスインと組織に起きた変化 その後、新しいmyTOKYOGASは2023年11月に予定通りサービスインし、自動テストやCI/CDの稼働はもちろんのこと、内製開発チームにて２週間1スプリントでの アジャイル 開発と保守運用までを責任を持って行うことができるようになりました。 しかし、一番の成果は内製化に成功したことではなく、プロジェクトを通して、「エンジニア以外のメンバーが システム開発 を他人事と捉えないようになった」こと。そして、「エンジニアがただ作るだけではなくて、プロダクトがこうすればよくなるのでは？と、ビジネスのメンバーと対等に議論し、チーム全体で良いプロダクトを作っていく」というエンジニアとビジネスメンバーが溶け合った文化ができたことだと思っています。私は「エンジニアが事業に溶け込み、プロダクトが今までにない速度で柔軟に価値提供できるようになり、その結果現場に熱量が生まれ、働き方や文化が変わる。そして、そこから生まれるプロダクトも変わる。そして、顧客体験も変わっていく。」これが巷でいうDXではないのか？と思うのです。文化や働き方を変えなくてはDXなんてできないのではないかと。 プロジェクトと並行して進めていた採用活動で、最初は私しかいなかったエンジニアも徐々に増え開発チームも大きくなってきました。現在は優秀なエンジニアが参画してくれたことで、myTOKYOGASの開発チームを彼らに任せるようにしています。しかし、時折開発チームのプランニングやレトロスペクティブを覗き見することがあります。今もプロジェクトを通して生まれた文化は失われておらず、全員がプロダクトをよくするには？チームがよくなるには？ということを議論し、改善を進めています。そこにはやはり当事者意識と熱量があります。その文化がある限りmyTOKYOGAS開発チームは、これからどんどんユーザの体験を変えていってくれるはずです。 さいごに myTOKYOGASの内製化で、Terraformによってインフラ構築はコード化され、CI/CDで自動テストや 脆弱性 診断が動き、デプロイも自動化されました。Datadogにアプリケーションは常に監視され、何かあればPagerDutyですぐにエンジニアに通知がきます。これらのテク ノロ ジー は、我々がユーザに迅速かつ柔軟に価値を届けることのできる環境を提供してくれました。しかし、結局はそれらの環境があっても、プロダクトに関わる人たち全員が当事者意識を持って「どうすれば顧客体験がよくなるか」を考え、これらを使いこなせるように マインドセット と働き方を変えなければ、意味がありません。そして、それはビジネスを行う自分たち次第であり、「外からDXが必要ですよ。」と言われて変われるものではないと思っています。なぜなら、その「DXが必要」という言葉には熱と当事者意識がない。それを持てるのは当事者である自分たちだけです。技術の導入やエンジニアの採用だけでは、DXも内製化も上手く行かない。DXも内製化も成功させるには、エンジニアもビジネスメンバーもデザイナーも、全員が当事者意識を持って、同じ方向を向ける文化を作らなくちゃならないのだということを私自身改めて感じさせられました。 東京ガス には及川というマネージャーがいました。ここから生まれた「このままじゃダメだ。変わらなくてはならない。」という当事者意識と熱量。これが杉山の参画、 ドメイン 知識を持ったiネットメンバーの参画、その後の続々と参画してくれたエンジニア、そして現場への当事者意識と熱量の伝播につながっていきました。これらが全部繋がったからこそ、 東京ガス の内製化の取り組みは成功させることができました。この熱量と当事者意識がなければ、どこかで成功へのピースが欠けて内製化は失敗していたのではないかと思います。 我々はまだまだ小さな組織で、myTOKYOGAS内製化は、 東京ガス がデジタルの世界でも選ばれる会社であるための、はじめの一歩です。しかし、大きな一歩だと思っています。 入社後わかったことですが、 アジャイル 開発や内製化の取り組みは我々のチームだけでなく、他の部などでも取り組まれているところもあるようです。 東京ガス のいろいろなところで、開発を「手の内化」しようという動きが生まれてきているのではないかなと思います。我々も現場から生まれた熱量と当事者意思を絶やさぬよう、 東京ガス のDXを進めていきたいと思います。 *1 : マネージャーの及川は他にも記事を書いています。ぜひ、読んでいただきたい。ただのサラリーマンとして日々を過ごすのではなく、会社を通して世の中を良くしたい、その熱量が伝わるのではないかと思います。 note.com note.com *2 : のちに私の上司になります。今は内製開発チームのTeam Leadです。私自身上司を リファラ ルするというのは初めての経験です。

みなさん、はじめまして！ 東京ガス CX推進部デジタル マーケティング グループでエンジニアチームのリーダーをしております杉山です。 このたび、当チーム（以下、内製開発チームと呼びます）での技術的な取り組みについて紹介するため、 Tech Blog を開設しました！ 実は私たち内製開発チームは note の方でも投稿しているのですが、このブログではソフトウェアエンジニアの内容に特化したものを投稿していく予定です💪 東京ガス 内製開発チームって？ 私たちのチームは myTOKYOGAS を中心としたお客さま接点のあるプロダクトを扱っております。23年11月、 myTOKYOGAS のリニューアルにあたって、私たちのチームはフロントエンド部分をフルリプレイスしました。 チームや部署、内製開発を始めた経緯については、ぜひ以下の note もご覧いただけたらと思います。 note.com myTOKYOGASへのリンクは以下となっております。ぜひこの機会にご登録ください。 （すでにご利用いただいているお客さまは、いつもありがとうございます。） members.tokyo-gas.co.jp リニューアル当日は一部のお客さまでアクセスしづらい状況が発生し、モバイルアプリの表示が出来ないなど、ご迷惑をおかけしてしまい大変申し訳ありませんでした。現在は安定稼働しており、オンコールが鳴ることも少なくなりましたが、まだまだサービスの信頼性を高めていく必要があります。また、内製開発をするに至った理由でもある、素早い価値提供を行うにあたって、リニューアルはスタートに過ぎません。 今後、お客さまに素早く価値を提供するにあたって、ソフトウェアエンジニアがどのような技術をもって実現していくのか、ぜひこの後の投稿もご覧いただけたらと思います！ また、当チームの取り組みについて、日経クロステックさまにもご紹介いただきました！ありがとうございます🙇‍♂ 第一弾の記事はこちら xtech.nikkei.com 第二弾の記事はこちら xtech.nikkei.com 今後に向けて これから myTOKYOGAS フロントエンドで採用している技術でもある Next.js / React や、BFF が採用している NestJS / GraphQL 、インフラで利用している Azure / Terraform はもちろん、次のフェーズに向けて開発を進めているマイクロサービスやモバイルアプリ、新たなプラットフォームとして構築している AWS などの技術的な取り組みについても発信していけたらと思っています！ぜひご期待ください！ ともに働く仲間を募集しています！ 私たちのチームは現在、積極的な採用活動を行っています！ご興味のある方は、ぜひ以下をご覧ください。 Application Developers www.wantedly.com SRE www.wantedly.com それでは、最後までお読みいただき、ありがとうございました！また次回の投稿でお会いしましょう！