プレゼンテーション：グリーンITを始める時に知っておきたかったこと
Bpifrance DigitalのCTOであるLudi Akue氏は、Green IT導入における7つの教訓を共有し、LCA評価やマイクロサービスのジレンマ、FinOpsと環境負荷の非対称性など、技術部門が気候目標達成に貢献するための実践的指針を提示している。
キーポイント
Green ITの重要性と現状認識
テクノロジーセクターの増加する排出量がグローバルな気候目標に与える影響を指摘し、技術リーダーとしての責任を強調している。
ライフサイクルアセスメント（LCA）の活用
環境影響を測定・管理するために、ソフトウェア開発の全ライフサイクルにおけるLCA（Life Cycle Assessment）評価を適用する重要性について言及している。
マイクロサービスの環境的ジレンマ
スケーラビリティと柔軟性をもたらすマイクロサービスアーキテクチャが、予期せぬリソース消費や複雑さにより環境負荷を高める「パラドックス」が存在することを示唆している。
FinOpsとGreen ITの乖離
コスト最適化（FinOps）が必ずしも環境負荷の低減（Green IT）につながるとは限らないことを指摘し、経済的効率性と環境持続可能性のバランスを取る必要性を説いている。
気候危機とIT部門の責任
自然災害の激甚化によりデジタルシステムへの影響が深刻化する中、技術セクターは世界の温室効果ガス排出量の6%を占め、AIの普及により2030年までに排出量が3倍になる見込みであり、パリ協定の目標達成には技術部門の積極的な対応が不可欠である。
グリーンITの設計制約としての認識
現代のテクノロジー構築は不安定な世界という新しい運用コンテキストで行われる必要があり、排出量、地球の限界、規制は新たな設計制約として捉えなければならない。
ライフサイクルアセスメント（LCA）の重要性
グリーンITへの第一歩として、原材料から製造、使用、廃棄に至るサプライチェーン全体の排出量を評価する標準手法であるライフサイクルアセスメント（LCA）と、Scope 1-3の排出枠組みを理解することが重要である。
影響分析・編集コメントを表示
影響分析
このプレゼンテーションは、単なるコスト削減ではなく「環境持続可能性」を技術指標として組み込むべきという業界のトレンドを示しており、特に金融や大規模システムのようなリソース集約型分野での実装ガイドラインとして重要である。FinOpsとGreen ITの不一致を指摘した点は、現場の開発者やアーキテクトにとって具体的な設計判断における新たな視点を提供する。
編集コメント
気候変動対策が技術戦略の必須要素となる中、コスト最適化（FinOps）と環境負荷低減（Green IT）の不一致を指摘する本記事は、実務的な設計判断において重要な示唆を与えます。
InfoQ ホームページ
プレゼンテーション
Green IT を始めた時に知っておきたかったこと
プレゼンテーションを見る
再生速度:
ダウンロード
43:13
要約
Ludi Akue は、技術セクターの排出量増加が世界の気候目標に与える影響について議論します。CTO としての経験に基づき、Green IT を実装するための7つの重要な教訓を解説します。ライフサイクルアセスメント（LCA）の評価、マイクロサービスのパラドックス、そして FinOps が常にグリーンを意味するわけではない理由についての洞察を共有します。
Bio
Ludi Akue氏はBpifrance DigitalのCTOであり、従来の銀行インフラを現代的なフィンテックプラットフォームへと変革するアーキテクチャを担当しています。彼女は20以上のデジタル製品にわたる技術戦略とイノベーションを主導し、30ものエンジニアリングチームを統括して、コアバンキングシステムと新興金融技術を橋渡ししています。
About the conference
ソフトウェアは世界を変えています。QCon Londonは、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発を力づけるイベントです。実践者主導のこのカンファレンスは、チーム内でイノベーションに影響を与える技術チームリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャーを対象に設計されています。
INFOQ EVENTS
May 12th, 2026, 1:30 PM EDT
Designing Data Layers for Agentic AI: Patterns for State, Memory, and Coordination at Scale（エージェント型AIのためのデータレイヤー設計：スケールにおける状態、メモリ、協調のパターン）
Presented by: Karthik Ranganathan - Co-CEO & Co-Founder at YugabyteDB, and Aditi Gupta - Snr. GenAI/ML Specialist Solutions Architect | GTM Data and AI at AWS
May 21st, 2026, 12 PM EDT
Portable by Design: Data Mobility & Recovery Patterns for Multi-Cloud Systems（設計によるポータビリティ：マルチクラウドシステムのためのデータ移動性と回復のパターン）
Presented by: Liore Shai - Solutions Architect at Eon
2026 年 5 月 28 日、午後 1 時 EDT
より速く配送し、より多く破壊する：AI の時代における配送システムの再考
登壇者：エリック・ミニック氏（Harness デベロッパーソリューションズ上級ディレクター）、アロン・ニューカム氏（Harness シニアプロダクトマーケティングマネージャー）
転写録
ルディ・アクエ：世界の災害の 3 分の 2 は自然災害です。地震、地すべり、暴風雨、洪水、猛暑などです。2022 年、英国では猛暑により、主要な NHS（National Health Service）病院 2 つで IT 障害が発生しました。これは患者ケアに影響を及ぼしました。自然災害は悪化し、頻度が増し、強度も増しており、デジタルシステムを含むすべてのものに影響を与えています。パリ協定によれば、地球温暖化を摂氏 1.5 度に抑えなければ、この状況はさらに悪化します。そのためには、2030 年までに排出量を 45% 削減する必要があります。そして 2050 年までに世界のネットゼロ（正味ゼロ）排出量を実現しなければなりません。私たちは問題を抱えています。なぜ問題があるのかご存知ですか？技術セクターの排出量が依然として増加しているからです。技術セクターは、世界全体の排出量の 6% を占めています。
排気ガスについて話す際、私は温室効果ガスの排出量について話しています。これは航空業界全体を上回る規模です。AI の影響により、2030 年までに排出量は 3 倍になると推計されています。何か手を打たなければ、パリ協定の目標は達成できません。自然災害は制御不能なものになります。Green IT に携わり始めた 4 年前に、これらすべてを知っていればよかったと願っています。当時私はフランスのハードウェア・スケールアップ企業である Lunii の最高技術責任者（CTO）であり、子供向けおもちゃのフランス市場リーダーでした。
フランスでは Green IT 変革を主導しました。4 年前にこれを学んでいればよかったと心から思います。現在、Bpifrance Digital の最高技術責任者（CTO）として私の任務の一環として、これらの課題に取り組んでいます。なぜなら、テクノロジーの立場として何かを行うことが私たちの中心的な役割だからです。もし何もしなければ、1.5 度の気温上昇制限には到達できません。私が苦い経験から学んだ 7 つの教訓を皆さんと共有したいと思います。まずは Green IT が持つ強みと、よくある罠を避ける方法についてお話ししましょう。さあ始めましょう。
まず確かなことにしておきたいのは、私たちが今、不安定化された世界という新たな運用コンテキストの中でテクノロジーを構築していることを全員が認識することです。これが私たちの新しい設計制約となります。排出量は設計制約です。地球の限界（Planet Boundaries）も設計制約です。規制もまた設計制约束です。
教訓 1：評価の課題
まず最初の教訓、どこから始めるかについて話しましょう。アセスメントは非常に困難です。Lunii で活動を始めた当初、どこから手をつけていいか分かりませんでした。私たちはハードウェア企業であり、子供向けの接続型おもちゃを作っています。またオーディオブックも出版しています。ヨーロッパで事業を展開しており、北米での展開も始めました。どこから始めていいか分からなかったため、サステナビリティの専門家を招きました。学ぶべき概念は多くありますが、圧倒されるほどではありません。大丈夫です。最初の概念は LCA（ライフサイクルアセスメント）です。これはグリーン IT だけでなく、サステナビリティに取り組むための標準的な手法です。原材料、製造、使用、そしてその先までを含むサプライチェーン全体を見直し、排出量を評価します。これがスタート地点です。また、スコープについても学ぶ必要があります。ここでスコープに慣れている方はいますか？スコープは排出量を分類するための枠組みです。スコープ 1 は、自社の活動から発生する排出量です。
例えば、会社の配送用バンはスコープ1に該当します。スコープ1はあなたが管理する範囲です。スコープ2は、活動のために使用するエネルギーからの排出量です。例えば、オフィスの電気使用量がこれに当たります。スコープ3は残りのすべてで、物流パートナーからクラウドプロバイダーに至るまで、あなたが運営するサプライチェーン全体を指します。また、目標を設定する必要があります。なぜなら、目標がなければ何も改善できないからです。実際、私たちはカーボンフットプリント（炭素排出量）の測定を行うことを選びました。ここで陥りやすい罠は、カーボンフットプリントを測定する際に生じうるあらゆる不一致に圧倒されてしまうことです。なぜなら、得られるすべての数値は不正確だからです。それでも構いません。それは問題ありません。なぜなら、カーボンフットプリントの測定は相対的な活動だからです。宣言的に測定できるものもあれば、測定できないものもあります。それも問題ありません。その点については気にせず進んでください。明確な数値を求めず、進むべき方向感を持つだけで十分です。
避けるべき罠の一つは、炭素排出量だけに着目することです。なぜならテクノロジーは材料にストレスを与え、水使用量のような資源にも負荷をかけ、電力グリッドにも負担をかけるからです。どこから始めるかを決める必要があります。まずは炭素から始めましょう。炭素は扱いやすく、シンプルで、動き出しの勢いを作るのに役立ちます。私もチームと一緒に炭素排出量の削減から始めました。会社全体のライフサイクルアセスメント（LCA）を実施した結果、テクノロジーが当社のグローバルな排出量に寄与する要因として第三位であることがわかりました。私たちは管理可能なスコープ 1 とスコープ 2 に焦点を当てて見ることにしました。テクノロジーに関連する貢献度には、デバイス、画面、ノートパソコン、サーバー、そしてインフラストラクチャが含まれます。まず取り組むべきことは、インフラストラクチャに深く入り込むことです。
教訓 2：インフラストラクチャの現実
クラウドを利用している方はどれくらいいますか？オンプレミスですか？それとも両方のミックスですか？私は主要なプラットフォーム・アズ・ア・サービス（PaaS）を利用していました。当初は PaaS を利用しているのですべてが問題ないと考えていました。しかし、私が発見したのは、PaaS は抽象化レイヤーが追加されるため、最も柔軟性がなく、最も透明性の低いクラウドインフラストラクチャだということです。すべてのことが不透明です。スケーリングも不透明です。独自のデータベースを微調整することもできません。裏側で何が動作しているかを確認することもできません。すべてを測定することが困難だったため、制御を得るために一部クラウドに移行することを決断しました。ここで得られる教訓はシンプルです。制御を獲得し、より高い透明性を求める必要があります。私たちはクラウドに移行し、多くのことを学びました。
理解しておくべきことのひとつに、電力ミックスと呼ばれる概念があります。電力ミックスとは、オンプレミス環境であれば自国における、あるいはクラウドを利用している場合は利用するクラウドリージョンにおける、電気の構成比率を指します。例えばフランスの電力は原子力発電の影響によりグリーンです。バージニア州の電力と比較すると、炭素集約度が低くなっています。私たちは PaaS 環境にいた際、バージニア州に位置していました。私たちのリージョンもバージニア州でした。まず理解すべきことは、電力ミックスと炭素集約度です。また、炭素集約度を理解する際に重要なのは、ワークロードを調整できる点です。
クラウドを利用している場合、もちろんグリーンな地域へワークロードを移動させることができます。例えば、炭素集約度の低い時間帯に運用バッチジョブを実行することを考えてみましょう。これは、自社の需要が電力網の炭素集約度にどのような負荷をかけているかを理解し、それを基にスキルを構築する新しい能力です。これに役立つ点として、主要なクラウドプロバイダーは素晴らしい取り組みを行っており、すべてサステナビリティガイドラインを提供しています。これらのガイドラインに従ってください。非常に良く作られています。オンプレミス環境の場合も、これらのサステナビリティガイドラインを確認し、同様に適用することができます。ハードウェアを改善する機会があれば、常に効率的なハードウェアを探してください。例えば ARM アーキテクチャは非常に効率的であり、地球にとってコストが低い選択肢です。
教訓 3: ソフトウェアアーキテクチャのパラドックス
これが私に三つ目の教訓をもたらします。三つ目の教訓はアーキテクチャに関するものです。想像してみてください。当社ではマイクロサービス構成を採用していました。もし、私たちの取り組みに関する要件をいくつか共有できるなら、それは非常にシンプルです。私たちはハードウェアを構築し、物流を追跡しています。また、13 の異なる国でオーディオブックを発行しており、多言語対応のオーディオブックです。さらに、オーディオブックやハードウェアを販売するための電子ショップ、つまり e コマースサイトを構築しています。これらが私たちのアーキテクチャにおける主要な要件です。
当時、私たちはすべてのものを社内開発していました。Green IT の観点とドメイン駆動設計（DDD）を踏まえて、私は三つの動きを行いました。一つ目は「簡素化」です。私たちは社内ですべてのものを過剰に構築してしまっていました。北米への展開やスケールアップを進めており、技術的負債が蓄積され始めています。そこで選択を行い、焦点を絞る必要があります。私たちのコアドメインは何でしょうか？そして、ビジネスの中核価値を活用すべきです。
その当時、それはオーディオ出版でした。では、私たちの支援ドメインとは何でしょうか？e コマースのような支援ドメインです。この部分は Shopify などの e コマースプラットフォームに委譲しても問題ありません。私は摩擦を追及しています。なぜなら、技術的負債（technical debt）を眺めているとき、そこには機会、すなわち Green IT の機会が示されているからです。
第一に、コアドメインを単純化することです。チームの成功を支援するために、私はマイクロサービスからモジュラーモノリスへと回帰するという選択をしました。技術的負債のためにマイクロサービスは分散モノリシック（distributed monolith）になりつつあるため、これをシンプルにするためです。これが最初のポイントです。
第二に、すべての e コマースサイトを Shopify へ移行しました。
第三に、社会技術的な観点からチーム全体を再焦点化し、コアドメインと単純さに注力させました。これは Green IT と相関しています。
教訓 4: フロントエンドの移行
それでは、4 つ目のレッスンへ行きましょう。4 つ目のレッスンは非常に面白いものです。なぜなら、フロントエンドはグリーン IT において最も見過ごされがちな分野だからです。興味深い事実として、ウェブページ自体がエネルギー消費と排出源となっています。HTTP Archive のこの調査結果はそのことを如実に示しています。過去 10 年間で、私たちのウェブページの重量は 4 倍に増加しました。これは非常に大きな変化です。私たちが目に見えていないのは、重くなったウェブページがユーザーのデバイスに負荷をかけるということです。これにより、ユーザーはより頻繁に充電し、再充電せざるを得なくなります。また、ウェブページの複雑さに対抗するために、ユーザーは各デバイスを買い替えなければならなくなることもあります。これも心に留めておくべき点です。
もちろん、フロントエンドに取り組み始めた当初は、「ページ速度を最適化する必要がある」と考えていました。なぜなら、ページ速度はコンバージョン率と相関関係があるからです。私たちはページ速度に注力し、アクセシビリティにも取り組んでいました。そして、コア・バイタル（Core Vitals）の改善のために Lighthouse を活用し始めました。
その後、ページサイズや重さという新たな世界に気づきました。また、ネットワークを制限すると、低帯域環境でのウェブサイトの動作を確認できます。ウェブページの重さは単なる技術的な問題でも、単に悪い UX であるわけでもないことがわかります。これは公平性の問題なのです。パフォーマンス最適化のためのツールは数多く存在します。私がウェブページについて語る際、HTML、CSS、JS バンドル、動画、画像を指しています。画像の圧縮は必須です。遅延読み込み（lazy load）を行い、スクリプトのロードを延期する必要があります。リソースを削ぎ落とすことも重要です。これらを行うための無料のリソースがウェブ上には多数あります。ウェブページ最適化を忘れないでください。また、予算的に可能であれば、静的レンダリングとエッジキャッシングを採用し、ユーザーに近づけてデータ転送量を制限しましょう。データ転送は排出量という観点では非常にコストがかかります。効率的なプロトコルを使用してください。HTTP/2 はすでに利用可能です。今後は HTTP/3 も登場します。予算的に可能であれば、ぜひ採用を検討してください。実際のフロントエンドへの影響を継続して測定し続けることも重要です。
教訓 5: FinOps の相関関係の罠
これも面白い話ですが、運営チームや DevOps チームに話す際、CFO からも「FinOps は Green IT と相関関係がある」という意見が出ることがあります。しかし、それは完了するまでには成り立ちません。なぜでしょうか？クラウドは常に環境に優しいとは限らないと仮定してはいけません。その理由をお話ししましょう。FinOps の簡単な例を取り上げます。より安価なリージョンを選ぶことです。安価なリージョンは往々にして炭素集約型の地域であり、だからこそ安いのです。ワークロードをより安価なリージョンに移すと、Green IT への取り組みが悪化します。
例えば「Instance Spot」についてお話ししましょう。誰が Instance Spot を使っていますか？Instance Spot のことを知っている人はいますか？Instance Spot は、必要な時にリクエストできるサービスです。
Green IT や FinOps を実践している場合、必要な分だけを使うことが好ましく、そのために Instance Spot が存在します。必要な時にインスタンスを要求するだけで済みます。これは非常に環境に優しいように見えますが、中身を見てみると、Instance Spot はかつて古い仮想マシンでした。あなたは FinOps を実行していると思い込み、Green IT を実践していると思い込んでいます。しかし、実態は逆で、状況を悪化させているのです。重要なのは、意思決定を再考し、クラウドを利用している場合でも、裏側で何が起きているのかを好奇心を持って確認する必要があるということです。
FinOps を機能させるためには、FinOps に影響指標を含め、それらを測定する必要があります。電力の使用量を測定しなければなりません。クラウド計算機ツールを活用してください。これは全く新しい分野です。これが私たちが Lunii で行ったことです。調達プロセスに歩道（評価経路）を構築する必要があるのです。
教訓 6：変革の促進
この教訓は、QCon の参加者である私たち全員が、これは社会技術的な問題であると理解していることを示しています。ライフサイクルアセスメント（LCA）を実施するからといって、あるいはカーボンフットプリントを測定するという目標を設定したからといって、それが自動的に機能するわけではありません。変化を可能にする必要があります。私は「変化の管理」よりも「変化の促進」という用語を好みます。では、どのようにそれを実現できるのでしょうか？私たちが行ったこと、そして一部の企業が実践しているのは、外部からの責任体制を構築することです。例えば、体重を減らすかジムに通うと決めた場合、友人たちに「週に2回ジムに行くことにした」と伝えるようなものです。困難な局面で諦めないよう、外部の責任体制を整えるのです。これは効果的です。Bpifrance においても、同様に外部からの責任体制を構築しています。
Bpifrance の外部からの責任体制とは、私たちが気候銀行であり、これが私たちの中核的な使命の一つであるフランス経済のグリーン転換を加速することです。まず責任体制を構築することから始めます。Green IT について語る際、それは非常に新しい概念です。ある人はこれをニッチな分野だと言っていました。人々を訓練し、教育する必要があります。彼らはプラネット・バウンダリーズ（地球の限界）、システム思考を学ぶ必要があります。また、一部の行動様式を捨て去るための新たな反射的対応、パフォーマンス最適化への依存から脱却するための新しい習慣も必要です。効率性だけでなく、 Sufficiency（充足）についても学ぶべきです。このような学習と反復のための空間を作り出す際、フィードバックループを組み込む必要があります。これは「Green IT を構築する」と宣言してそこで終わるような 3 年間の目標ではありません。
マイルストーン、指標、祝賀の場、そしてチームが課題を振り返るためのスペースを設ける必要があります。サステナビリティはサイドクエスト（副任務）であってはなりません。私はその過ちを犯しました。私が学んだのは、サステナビリティをデリバリーバックログに組み込む必要があるということです。それはバックログ内の他のユーザーストーリーと同じように扱われるべきです。企業の OKR がサステナビリティを反映させる必要があります。これは技術チーム内にサステナビリティを置くよりも容易に実現できるでしょう。命令を中央集権化しないでください。分散型のリーダーシップチームを構築してください。すべてのチーム（技術チーム、プロダクトチーム、デザインチーム、マーケティングチーム）に、変化を推進するチャンピオンからなるエンパワーメントチームを任命してください。そのチャンピオンたちが共に変化を作り上げていくのです。私が Lunii にいた時に実践したのがこれです。私たちはチャンピオンを持っています。変化を築き、変化を可能にするのは非常に困難なため、リーダーシップを分散させることが重要です。
教訓 7：新興する AI パターン
最後の教訓は過去の物語ではなく、私の現在の仕事です。Bpifrance の Green IT ワーキンググループの一員として、持続可能性の観点から新興する AI パターンを検討しています。私が思うに、ガバナンスレベルでは誰も持続可能性について話していません。具体例を挙げましょう。欧州で AI 法が制定されていても、その法律は持続可能性の問題にほとんど触れていません。同時に、AI はあらゆる場所で加速しています。私たちはエージェンティック AI（自律型 AI）、つまり至る所に埋め込まれた AI について語っています。多くのモデルが誕生し、すぐに消滅する様子を目撃しており、そこには膨大なトレーニングコストが伴います。今日のことではありませんが、数ヶ月前から推論（inference）が新たなエネルギー課題となっています。すなわち、排出量という点では推論コストがトレーニングコストを上回っているのです。さらに、使用されるハードウェアについても言及する必要があります。ご存知ですか？GPU チップの寿命は約 2〜3 年しかありません。
幸運にも5年という期間があるかもしれません。しかし、誰もその点について話していません。誰もユーザーに、あるいは私たちに、今日 AI を至る所に導入することのコストがどれほどかを伝えていません。多くの国で新しいデータセンターの建設に対する禁止令が出されています。なぜなら、データセンターは地域の電力網にも負荷をかけているからです。これに対して何らかの対策を講じる必要があります。すべてが無料であるかのように思われていますが、実際にはそうではありません。価格設定がないということは抑制が効かないことを意味し、私たちの製品チームや技術チームは、ここで本当に AI を使う必要があるのか？AI の利用に環境テレメトリを組み込むにはどうすればよいのか？ユーザーに適切な選択を促すにはどうすればよいのか？といったことを一切考えずに AI ツールを開発しています。誰もそのような取り組みをしていません。私は今まさにそのための活動を行っています。
Bpifrance で私たちが行っていることのひとつは、AI リテラシーの普及です。私は PromptSage GPT というカスタム GPT の開発に関わっており、このツールを使ってプロンプトをより効果的に作成する方法や、持続可能なプロンプトと慣習を築く方法を学ぶことができます。ここで伝えたいのは、トークンの使用量（emission）は排出量に直結するため、利用の監視や制御を実現するための多くのツールが存在するということです。EcoLogits や LiteLLM、Langfuse といったツールを参照してください。これらのツールを使えば、AI の利用状況をモニタリングできます。
Key Takeaways
この旅を始めたとき、私が知っていればよかったと願うことがたくさんありました。私たちが不安定化している惑星という新しいオペレーティングシステムの中で運営していることを知っていればよかったのです。技術が中心的な役割を果たしていることも認識していればよかったのです。ソフトウェアエンジニアや技術リーダーとして、私たちは地球温暖化を摂氏 1.5 度に抑えるために中心的な役割を果たしています。この講演から一つだけ覚えておいてほしいことは、もちろん多くのことを学ぶ必要がありますが、同時に多くのことを「学び直す」必要があり、新しい質問のセットを構築しなければならないということです。「なぜ」という問いが最も重要です。なぜこれを作っているのか？何を作っているのか？どこで、どのように、そしてどこで実行しているのか？このツールを誰のために作っているのか？充足感（sufficiency）のための直観を育むことが非常に重要です。
3 つのアドバイスを残します。
一つ目は、資源はどこにでも豊富にあるということです。これはツールの問題ではなく、空間と内省の問題です。まず好奇心を持ちましょう。グリーン IT は一人の快適な領域から出ることを要求するため、その外へ踏み出すために好奇心を持つことが必要です。二つ目は、私たちの影響を正直に評価し、長年転嫁してきたネガティブな側面（パーソナリティ）を自分たちのものとして引き受けることです。三つ目は、クラウドプロバイダー、SaaS、AI に対してより透明性を求めるために、集団的にこの勇気を持つ必要があるということです。グリーン IT の旅が幸せなものになりますように。
質疑応答
参加者 1: データ転送が排出量の大きな構成要素となる理由について、もう少し詳しく説明していただけませんか？
ルディ・アクエ氏：最大ではありません、第三位です。ハードウェア企業としては典型的なことで、生産が最大の寄与要因となります。なぜなら、私たちは各国からチップを調達し、子供向けの玩具を生産しているからです。第二位は流通、つまり物流です。これは通常の状況であり、このような構成は非常に一般的です。技術部門は二番目または三番目の位置にあります。私たちがスコープ 1（電力、オフィス電力）とスコープ 2 を測定・評価した結果、IT 側が全体の寄与を押し上げる主要な要因であることがわかりました。IT 側は従業員一人あたりの指標であり、ノートパソコン、携帯電話、サーバー、ネットワークなどが含まれます。これが私たちの炭素排出におけるグリッド部分に相当します。
参加者 2 氏：スライドの一つで不完全なデータについて言及されていました。測定の実践経験、その測定のスケールアップ、不完全なデータの扱い方、そして人々にそれを信じさせる方法についてお聞きしたいです。
Ludi Akue: 偽のデータや相対的なデータを扱うことに慣れる必要があると思います。なぜなら、まずは動き出す必要があるからです。私たちは約3年前にCarboというツールを使って始めました。Carboはフランス製のツールです。Carboではすべてのことを測定することはできません。例えば、アプリケーションがクラウド上で実行されている場合、そのアプリケーションの排出量を計算するには、クラウド事業者が提供する計算機に頼らなければなりません。例えば、Google Cloudには「地域ベースの計算機」と呼ばれるものがあり、これはあなたが利用している地域の実際の排出量に基づいています。一方、AWSは市場ベースの計算を採用しており、結果が不明確な場合があります。最も正確な数値を得ることはできません。その点を受け入れる必要があります。また、ツールによって数値が異なることもあります。先ほどCarboについてお話ししましたが、それは一例に過ぎません。
より大きな企業を見てみましょう。Bpifrance では私たちが 5,000 人以上います。私は 20 のアプリケーションを持っていますが、一部の組織では 400 のアプリケーションがあるかもしれません。それを測定するのは非常に困難です。クラウドもあればオンプレミスもあります。どうすればよいのでしょうか？データセンタープロバイダーに計算結果を提供してもらう必要があります。ウェブページのようにどのように測定できるでしょうか？相対的な数値を使う必要がありますが、それは問題ありません。なぜなら、方向性を感じることが重要だからです。より重要なのは、それを行うための方法を持つことです。現在も Bpifrance では良い方法を模索しています。これは継続的な作業であり、それで構いません。Green IT は簡単ではありません。私たちは学ぶ必要があります。3 年後にはツールの動向に変化が見られるでしょう。多くのツールがあります。私の講演には利用可能なツールに関する文書を補足します。状況は改善していますが、数値そのものを探さないでください。それは真の数値ではないからです。動き出すために、数値が示す方向性を感じ取ってください。
参加者 3: ビジネス側からどれだけの説得力が必要でしょうか？世界を救うためだと言っても、彼らは金銭的な側面についてより納得したいと思うはずです。
Ludi Akue: おっしゃる通り、それは単に世界を救うことだけではありません。私はレジリエンス（回復力）のためのものだと考えています。最初のメッセージを忘れないでください。私たちが不安定な世界で働いていることを認識し、自然災害がサプライチェーンの混乱を引き起こし、人命を脅かしているという事実を認めることが非常に重要だと考えます。企業に伝える際は、それが容易ではないことを理解してもらう必要があります。それに基づいてビジネスケースを構築し、グリーンウォッシュ（環境配慮の偽装）のためではなく、コミュニケーションのために外部への説明責任を探すためのビジネスケースも構築する必要があります。重いウェブページがビジネスやスケーリングをどのように遅らせているかを探り、事業の混乱を示すシグナルを見つけることが重要です。技術的負債は効率性の指標でもありますし、グリーン IT を実現するために技術的負債を活用することもできます。どこかに摩擦があるなら、その摩擦に注目してグリーン IT のケースを構築してください。あなたと共に推進役（チャンピオン）を持ちましょう。例えば、早期採用者たちに話を聞いてみてください。
参加者 4: 開発チームがグリーン IT の課題に取り組む時間を確保するために、どのようにお手伝いしていますか？スプリントバックログに専用の Jira チケットを作成したり、週次ミーティングで指標を探ったりするなどの取り組みはありますか？
Ludi Akue: それは異なります。実際、私はグリーン IT を試みました。チャンピオンたちはチームにユーザーストーリーを作成させ、グリーン IT に関するユーザーストーリーを策定しました。私は彼らに時間があるときにそのストーリーに取り組ませようとしたのですが、これは大きな誤りでした。そこで私は、彼らの作業時間の 20% をグリーン IT に充てるように決定しました。これは一つの選択肢ですが、もしこのオプションがない場合は、少なくとも各チームがスプリント（スクラムの期間）を持つ場合、そのスプリントの中で少なくとも一つはグリーン IT のユーザーストーリーに取り組むことを確実にしてください。ここで陥りやすい罠は、それをサイドクエスト（脇道）にしてしまうことです。私たちは新しい常態的な行動様式を築きたいのです。新しい常態とは、「グリーン IT 最適化に常に注意を払い、その意識をバックログに組み込むこと」です。チームの集まりを待つのではなく、グリーン IT の目標達成を祝うことも大切です。私が目指しているのは、数年後にはグリーン IT という側面について忘れ去られることです。それは単なる通常の業務の一部となるはずです。しかし、私たちはまだそこには到達していません。
参加者 5: あなたの質問（この旅路においてリーダーシップを惹きつけること）に基づいてお尋ねします。実際、私が知りたいのは、開発者をこの旅路に引き込み、惹きつけるためのアドバイスは何かということです。また、これらの上に規制を適用する方法はあるのでしょうか？
ルディ・アクエ：私が得ているチャンスは、若手開発者たちと接点を持つことです。若手開発者は世界を変えたいと考えています。他の開発者がそうではないと言っているわけではありませんが、若手開発者はその準備ができているし、変化への対応もできています。Lunii において非常に興味深いのは、グリーン IT についてお話ししましたが、グリーン IT は持続可能性運動全体の一部に過ぎないということです。グリーン IT は技術ですが、循環経済を考えると、これもまた持続可能性運動の一環です。若年層はそれに対応する準備ができています。彼らにはそのための方法やアプローチが必要であり、それに取り組む時間を確保する必要があります。まだその準備が整っていない人々、文化的に受け入れられていない人々にとっては、教育の問題となります。Lunii にはサステナビリティのリーダーがおり、彼女の目標は、すべての従業員に対して持続可能性について、パリ協定について、測定方法について研修を行うことでした。そして、「私たちは知らない」という事実を誰もが受け入れやすくすることです。私たちは推計しますが、真実は知りません。改善し続ける必要があり、真の答えはまだわからないのです。そのことを理解し、受け入れることが重要です。私は教育もその一部だと考えており、持続可能性活動に取り組む他のチームとの交流会や、BBI などの取り組みも含まれるでしょう。
規制は興味深いものです。なぜなら、リーダーシップの取り組みを基盤にできるからです。規制は既に存在しています。私が現在 fintech に携わっている中で最も制約となるのは、気候リスクの開示義務です。多くの報告が必要となりますが、これを Green IT への旅立ちのためのレバーとして活用できます。気候リスクには ESG が含まれ、これらの報告を行う必要があります。多くの場合、これらは包括的なものです。規制を活用しましょう。炭素排出量や持続可能性、グローバルな持続可能性、平等性などの報告を義務付けるような規制は、むしろ動きの感覚や変革の意識を育むために利用すべきです。私が現在、規制が役立っていないと感じるのは AI と持続可能性の分野においてであり、ここではそのようなガバナンスを構築する必要があります。
transcript を含む他のプレゼンテーションもご覧ください
録画日時:
2026 年 3 月 4 日
原文を表示
InfoQ Homepage
Presentations
What I Wish I Knew When I Started with Green IT
View Presentation
Speed:
Download
43:13
Summary
Ludi Akue discusses how the tech sector’s rising emissions impact our global climate goals. Drawing from her experience as a CTO, she explains seven key lessons for implementing Green IT. She shares insights on LCA assessments, the paradox of microservices, and why FinOps doesn’t always equal green.
Bio
Ludi Akue is CTO at Bpifrance Digital, architecting the transformation of traditional banking infrastructure into a modern fintech platform. She leads technical strategy and innovation across 20+ digital products, orchestrating 30 engineering teams in bridging core banking systems and emerging financial technologies.
About the conference
Software is changing the world. QCon London empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
INFOQ EVENTS
May 12th, 2026, 1:30 PM EDT
Designing Data Layers for Agentic AI: Patterns for State, Memory, and Coordination at Scale
Presented by: Karthik Ranganathan - Co-CEO & Co-Founder at YugabyteDB, and Aditi Gupta - Snr. GenAI/ML Specialist Solutions Architect | GTM Data and AI at AWS
May 21st, 2026, 12 PM EDT
Portable by Design: Data Mobility & Recovery Patterns for Multi-Cloud Systems
Presented by: Liore Shai - Solutions Architect at Eon
May 28th, 2026, 1 PM EDT
Shipping Faster, Breaking More: Rethinking Delivery Systems in the Age of AI
Presented by: Eric Minick - Sr. Director of DevOps Solutions at Harness, and Aaron Newcomb - Senior Product Marketing Manager at Harness
Transcript
Ludi Akue: Two-thirds of the world's disasters are natural disasters: earthquakes, landslides, storms, floods, extreme heat. In 2022, here in the UK, because of extreme heat waves, two major NHS hospitals suffered IT failures. This impacted patient care. Natural disasters are getting worse, more frequent, more intense, and they are affecting everything, including digital systems. According to Paris Agreement, this will get worse if we don't limit the global warming to 1.5 degrees Celsius. To do that, we need to reduce by 45% by 2030. We need to reach net zero global emissions by 2050. We have a problem. Do you know why we have a problem? We have a problem because the tech sector's emissions is still increasing. The tech sector is 6% of the global emissions.
When I talk about emissions, I'm talking about greenhouse gas emissions. This surpasses the whole airline industry. Because of AI, emissions are estimated to triple by 2030. We have to do something, if not, we won't meet Paris goals. Natural disasters will become uncontrollable. I wish I knew all that when I started working with Green IT, that is four years ago. I was the Chief Technical Officer of Lunii, a hardware scale-up in France, a French market leader for kids' toys.
In France, I led Green IT transformation. I wish I learned that four years ago. Currently in my mandate as the Chief Technical Officer at Bpifrance Digital, I'm still working on those issues because it's our central role as tech to do something. If not, we won't reach the 1.5 degree Celsius limit. I want to share with you the seven lessons I learned the hard way. To get started, Green IT is strong and avoid common traps. Let's go. One thing I want to make sure, I think, is to be all aware that we are now building tech in a new operating context, an operating context of a destabilized world. This is our new design constraint. Emissions are design constraints. Planet boundaries are design constraints. Regulations are also design constraints.
Lesson 1: Assessment Challenge
Let's start with the first lesson, where to begin. Assessment is very challenging. When we started at Lunii, we had no clue where to begin. We were a hardware company. We make connected toys for kids. We published audiobooks as well. We are operating in Europe and starting to operate in North America. As we didn't have a clue, we brought in a sustainability expert. You have a lot of concepts to learn. It's not overwhelming, it's ok. The first concept is LCA, Life Cycle Assessment. It is the standard method to get started with not only Green IT, with sustainability. You just review your whole supply chain from raw materials, manufacturing, usage, and beyond to evaluate your emissions. This is the start. You have to learn also our scopes. Is anyone familiar with scopes here? Scopes are frameworks to categorize emissions. You have scope 1, which is emissions from your activities.
For instance, you have a company delivery van, it's scope 1. You control scope 1. Scope 2 is emission from energy you use for your activities. For instance, your office electricity. Scope 3 is the rest, the whole supply chain you are operating from your logistic partners to your cloud provider. You also need to have a goal. Because without a goal, you cannot improve anything. Actually, we chose to measure our carbon footprint. A trap here is to feel overwhelmed with all the discrepancies you can have in measuring the carbon footprint, because all the numbers you will get will be wrong. That's ok. That's ok because measuring carbon footprint is a relative activity. You can measure something as a declarative and some cannot be measured. That's ok. Feel free with that. Don't look for clear measures, just have a sense of direction to get going.
A trap to avoid is it's not just our carbon, because tech induces stress on materials, resources like water usage, stress on the power grid. You have to start somewhere. Start with carbon. Carbon is cool. Carbon is simple. It gets you going to create momentum. I started with carbon with my team. When we did the LCA for the whole company, what we learned is that tech was the third contributor to the global emissions of our company. We choose to look at scope 1 and scope 2. Scope that we can control. In the tech contribution, you have everything IT related: devices, screen, laptops, servers, and you also have infrastructure. The first thing to do is to get in really with infrastructure.
Lesson 2: Infrastructure Reality
How many of you are on the cloud? On-prem? A mix of both? I was on a Platform as a Service, the major one. I used to think that because I'm on a PaaS, everything is ok. What I found out is the PaaS is the least flexible and the least transparent cloud infrastructure because the abstraction layer, it adds to the cloud. Everything is opaque. The scaling is opaque. You cannot fine-tune your own database. You cannot look at what is working under the hood. Because everything was difficult to measure, I decided to move to the cloud, partly to gain control. The lesson here is simple, you have to gain control and push for more transparency. We moved to the cloud and we learned a lot of things.
One thing you need to understand is what's called electricity mix. Electricity mix is, what is the composition of electricity in your country, if you are on-prem, or in your cloud regions, if you are using cloud? For instance, electricity in France, because of nuclear, is green. It's less carbon intensive like electricity in Virginia. When we were on the PaaS, we were located in Virginia. Our region was Virginia. The first thing is to understand the electricity mix and the carbon intensity. One thing also to understand when you understand the carbon intensity, is that you can shape your workloads.
If you are on the cloud, of course, you can move your workload to the greener regions. Let's look at operational batch jobs, for instance, during low carbon intensive hours. It's the new skill to build to understand how your demands are stressing the carbon intensity, your power grid. One thing that helps, and I think the major cloud providers did a great job is that they all have sustainability guidance. Please follow them because it's well done. If you are on-prem, you can look at those sustainability guidance and apply it also to on-prem. If you have the chance to improve the hardware, always look for efficient hardware. ARM, for instance, are very efficient and less costly for the planet.
Lesson 3: Software Architecture Paradox
This makes me come to lesson three. Lesson three is about architecture. Picture this. In the company, we had a microservice setup. If I can share some requirements of how we are doing, it's very simple. We build hardware. We track logistics. We publish audiobooks in 13 different countries, so multilingual audiobooks. We build e-shops, e-commerce shops to sell audiobooks and to sell hardware. Those are the big requirements of our architecture. At that time, you build everything in-house. Looking through the Green IT lines and using DDD, I make three moves. The first one is simplify. We are overbuilding everything in-house. We are scaling and going to North America. We have a lot of tech debt piling up. We need to make a choice, have a focus. What is our core domain? Then use the core value of the business.
At that time, it was audio publishing. Then, what is our supporting domain? The supporting domain like e-commerce. It's ok to delegate this part to e-commerce like Shopify and stuff. I chase friction because when you're looking at technical debt, technical debt signals opportunities, Green IT opportunities. First, simplify, core domain. I made a choice to help the team succeed. It's to go from microservices, which because of the technical debt is becoming a distributed monolith, back to modular monoliths to make things simple. That's the first thing. We migrate all of our e-shops on Shopify. The third thing is, I refocus the whole team, sociotechnical, I refocus the whole team onto the core domain, bringing simplicity. It's correlated with Green IT.
Lesson 4: Frontend Migration
Let's go to lesson four. Lesson four is really funny because frontend is the most overlooked when it comes to Green IT. Fun fact, webpages are energy and emissions. This work from HTTP Archive says a lot. In the last 10 years, the weight of our webpages grew by four times. That's a lot. What we don't see is that the heavier webpages strain users' devices. Make users charge more and recharge more. Force the user to change each device to compete with the complexity of the webpage. This is something to keep in mind also. Of course, when we started with frontend, we were like, we need to optimize page speed. Because page speed correlates with conversion rates. We were into page speed. We were also into accessibility. We were on all that, and we started to look at Lighthouse to improve our core vitals.
Then I discovered a new world of page size, weight. Also, when you throttle the network, you can see how your website is behaving in low network regions. You see that webpage weight is not just tech, it's not just bad UX. It's an equity issue. We have a ton of tools to optimize for performance. When I talk about the webpages, I'm talking about HTML, CSS, JS bundles, video, image. We must compress images. We must lazy load, defer the scripts. We must trim them. There's a lot of resources to do that for free on the web. Don't forget webpage optimization. Also, if you can afford it, go for static rendering and edge caching, to be close to your user and to limit the data transfer. Data transfer is very expensive when it comes to emissions. Use efficient protocol. You have HTTP/2. Now we are going to have HTTP/3. If you can afford it, go for it. Keep measuring your real frontend impact.
Lesson 5: FinOps Correlation Trap
This one is also funny, because when I talk about it to our operation teams and DevOps teams, the thing that's come up even with CFO is, FinOps correlates with Green IT. Yes, until it's done, it doesn't. Why? Don't assume cloud is always greener. I'll tell you why. Let's take a simple example of FinOps. Let's go for cheaper regions. Cheaper regions are often carbon-intensive regions, that's why they are cheap. When you move your workloads to cheaper regions, you are worsening your Green IT endeavors. I want to speak about, for instance, Instance Spot. Who uses Instance Spot? Who knows about Instance Spot? Instance Spot is a service that you can ask.
If you are doing Green IT or FinOps, you prefer to use what you need, Instance Spot is here for that. You can just ask for an instance when you need it. This appears very green, but if you look under the hood, Instance Spot used to be old virtual machines. You think that you are doing FinOps. You think that you are doing Green IT. Under the hood, you are making things worse. The thing is, you need to rethink your decision and you need to be curious to see what is working under the hood, even if you are using a cloud. For your FinOps to work, you need to include in your FinOps, impact metrics, and to measure them. You need to measure the electricity. You need to use your cloud calculators. It's a whole new subject. That's what we did at Lunii. You need to build walkways in your procurement.
Lesson 6: Enabling Change
The lesson says, as QCon folks, we all know that it's sociotechnical. It's not because you do LCA, Life Cycle Assessment. It's not because you choose a goal, like to measure your carbon footprint, that it will work out of the box. You need to enable change. I prefer the term enabling change than managing change. How can you do that? What we did and what some of the companies do is to build external accountability. It's like, if you decide to lose weight or to go to the gym, you tell your friends, "I decided to go to the gym two times a week". You build external accountability to help you when things become hard, not to give up. This works. Even as Bpifrance, we build external accountability as well.
The external accountability of Bpifrance is we are the climate bank, that is one of our core missions, is to accelerate the green transition of the French economy. You start with building accountability. When we are talking about Green IT, it's very new. Someone was telling me it's niche. You have to train the people. You have to educate them. They need to learn planet boundaries, system thinking, new reflex to unlearn some reflex performance, optimization reflex, to learn about sufficiency, not just efficiency. When you create this space of learning and iteration, you want to build in feedback loops. It's not a 3-year goal, like I want to build in Green IT and full stop.
You have to put milestones, metrics, celebration, and a space for the team to reflect on the challenge. Sustainability cannot be a side quest. I made that mistake. What I learned is you need to build sustainability in your delivery backlog. It's just another user story, like your whole user story in the backlog. You need to have the company's OKR translate sustainability. This will be easier to do than to have sustainability in the tech team. Don't centralize mandates. Build a distributed leadership team. Appoint an enablement team of champions in all the teams: tech teams, product teams, design teams, marketing teams. Let the champions build the change together. That's what I did when I was at Lunii. We have the champions. It's very difficult to build the change, to enable the change, so distribute the leadership.
Lesson 7: Emerging AI Patterns
The final lesson is not a story of the past, it's my current work. As a member of the Green IT working group at Bpifrance, we are looking at emerging AI patterns when it comes to sustainability. It's not just that I think, nobody is talking about sustainability at the governance level right now. Let's take an example. Even if you have the AI Act in Europe, the AI Act barely touches the question of sustainability. At the same time, AI is accelerating everywhere. We are talking about agentic AI, so embedded AI everywhere. We are watching a lot of models coming to life and dying right away, with heavy training costs. For the first time, it's not today, it's like many months ago, inference is the new energy thing. That is, inference surpasses training costs in terms of emission. Not to mention the hardware trained with. Do you know that GPU chips, their lifespan is about two, three years?
If you are lucky, five years. Nobody is talking about that. Nobody is telling the users, is telling us, what it costs today to have AI everywhere. There are a lot of bans in different countries against the building of new data centers, because the data centers are stressing the local power grids also. We need to do something about that, because everything is free, but we know that it's not free. No pricing means no restraint, and our product and tech teams are building AI tools without ever thinking about, do I really need to use AI here? How can I build in environmental telemetry in the AI usage? How can I inform the users to make the right choices? Nobody is doing that. I'm trying to do that right now.
One thing we are doing at Bpifrance is to promote AI literacy. I work on PromptSage GPT, which is a custom GPT that you can try to learn how to prompt better with the tool. The tool will help you prompt better and build sustainable prompts and traditions as well. What I'm trying to say here, is there are many tools to achieve telemetry, to achieve the control of our usage of tokens, because token usage is emission. You can refer to tools like EcoLogits, maybe some of you know about the tools. EcoLogits, you have LiteLLM and you have Langfuse to monitor your usage of AI.
Key Takeaways
When I began this journey, I wish I knew all that. I wish I knew that we are operating in a new operating system of a destabilized planet. I wish I was aware that tech is playing a central role. As software engineers, tech leaders, we are playing a central role in bringing the global warming to 1.5 degrees Celsius. If you have one thing to keep from this talk, it is, you have to learn a lot, yes, but you have to unlearn a lot also, and build a new set of questions. Why, is the most important one. Why am I building this? What am I building? Where, how, and where am I running it? For whom am I building this tool? To build an intuition for sufficiency, that's very important. I will leave you with three pieces of advice.
The first one is, resources are abundant everywhere. It's not a matter of tooling, it's a matter of space and reflection. First, be curious. Be curious to go out of your comfort zone, because Green IT requires to go out of one's comfort zone. The second one is honesty to assess our impact, and to own our negative personalities that we offload for years. Three, we need to collectively have this courage to push our cloud providers, SaaS, AI, for more transparency. Happy Green IT journey.
Questions and Answers
Participant 1: Could you elaborate a bit on why data transfer is such a large component of emissions?
Ludi Akue: It's not the largest, it's the third largest. This is typical as a hardware company, the production was the first contributor, because we are having chips from countries and producing the toys for the kids. The second one was the distribution, that's the logistics. That's normal. It is very common to have this kind of setup. The tech, they come in second or third row. When we measure our evaluation from scope 1, electricity, office electricity, and scope 2, what we've learned is that it's more the IT side that makes the whole contribution go up. IT side is per employee, so you have the laptop, the mobile phone, you have the servers, you have the networks. This is the grid part of our carbon emission.
Participant 2: One of the slides mentioned imperfect data. I wanted to hear about your experience of measurement, also scaling that measurement and handling imperfect data and making people believe it.
Ludi Akue: I think that you have to be comfortable having false data, have relative data, because you need to get going. We started like three years ago, with a tool called Carbo. Carbo is a French tool. Carbo, you cannot measure everything. Because, for instance, you have your application running on the cloud. To calculate the emissions of your application, you have to rely on the cloud calculators. For instance, Google Cloud has what we call the local based calculator, that is your actual emission according to your region, the region you are using. AWS for instance, has market based, so it's unclear. You cannot have the finest number. You have to be ok with that. The numbers vary between tools, also. I told you about Carbo, it's an example.
Let's take a bigger company, because at Bpifrance we are more than 5,000. I have 20 applications, and some parts you have maybe 400 applications. To measure that is very difficult. You have cloud, you have on-prem. How do you do that? You need to ask the data center provider to give you the calculations. How can you measure like your webpages? You have to go with relative numbers, but it's ok. Because you are looking for a sense of direction. What is more important is to have a method to do that. We are still thinking about a good method at Bpifrance right now. It's ongoing work, and that's ok. It's Green IT, it's not simple. We need to learn. In three years, I can see shifts in the tools. There are many tools. I will complement my talk with a document about the tools that were available. Things are getting better, but don't look for the numbers, it's not the real numbers. Look for the sense of your numbers to get going.
Participant 3: How much convincing does it take from the business side? Because I'm guessing you can't just be like, this is for saving the world. They might want to be more convinced on the money side of things.
Ludi Akue: You get it right, it's not just about saving the world, I think it's for resiliency. Don't forget the initial message. I think it's very important to acknowledge that we are working in a destabilized world, and that natural disasters are causing supply chain disruptions, are threatening lives. When you come to your companies, it's to let them know, it's not easy. You have to build a business case around that, and you have to build a business case around looking for external accountabilities, even if it's for, not greenwashing, but it's for communication, it helps. Looking to find how your heavier webpages are slowing the business, are slowing your scale, and looking for business disruption signals. Tech debt signals efficiency, you can do Green IT through tech debt as well. If you have friction somewhere, just look at the friction to build Green IT cases. Have champions with you, like talk to your early adopters.
Participant 4: How do you help dev teams to spend time on Green IT subjects? Do you have dedicated Jira tickets in the sprint backlog, or weekly meetings to explore metrics, or stuff like that?
Ludi Akue: It's different. Actually, I tried, ok, do Green IT. The champions have the team come up with user stories, so Green IT user stories. I tried to let them do the stories when they have time, and this is a huge mistake. I decided that they will have 20% of their time for the Green IT. It's an option, but if you don't have this option, just make sure that every team embarks on at least one Green IT user story in their sprints, if they have sprints. I think the trap here is to make it a side quest. You want to build a new normal behavior. A new normal behavior is, please be alert, be aware of Green IT optimization, and build that into your backlog. Don't wait for team gathering. Let's celebrate reaching a Green IT goal, also. What I hope is, in a few years, we will forget about the Green IT side of the equation. It's just normal work, but we are not there yet.
Participant 5: Building on your question which is around enticing leadership on this journey. Really, what I want to know is, what advice do you have around bringing developers on this journey and enticing them? Also, is there a way to wrap in regulation on top of this?
Ludi Akue: The chance I have is to have young developers. Young developers want to change the world. I don't say that other developers don't, but young developers are ready for that, are ready for the change. Something that's very interesting at Lunii, I talked about Green IT, but Green IT is a part of the whole sustainability movement. Green IT is tech, but when you think of circular economy, it's part of the sustainability movement. The younger generation is ready for that. They need methods, approaches, and create time for them to do that. For people not ready for that, culturally not ready, it's a question of education. We have a sustainability leader at Lunii, and her goal was to train everyone on sustainability, on Paris Agreement, on how to measure, and to make everybody easier with the fact that we don't know. We estimate, but we don't know, we need to get improving, and we don't know the real answer, and to get cool with that. I think that education is a part of that, and maybe meeting with other teams doing sustainability work, BBI, things like that.
Regulation is interesting, because I can build up on the leadership thing. Regulations are here. I think the most constraining regulation — I'm in fintech right now — you have to disclose your climate risks. It's a lot of reporting, but you can use it as a lever to start a Green IT journey. The climate risk, you have ESG, you have those reporting this, and many of them are the whole one. Use the regulations, so this kind of regulation that is constraining us to report our carbon emission, is constraining us to report our sustainability, the global sustainability, equality, use that to foster a sense of movement, a sense of transformation. Where regulation is not helping right now, for me, is in terms of AI and sustainability, and we need to build that kind of governance.
See more presentations with transcripts
Recorded at:
Mar 04, 2026
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み