グリーンコーディング
飛び恥
飛び恥、英語ではFlight Shameという言葉があることを知った。環境に配慮して、飛行機での移動を控えようというものだ。ヨーロッパで盛んになった運動で、ドイツでは国が積極的に国民に呼びかけを行っており、フランスでは鉄道で2時間半以内で移動できる距離の飛行機の運行が禁止された。
抜け道があるとか、どこまで二酸化炭素排出量の削減に効果的であるのかという疑問もある。グリーンロンダリングという言葉もあるように、環境に配慮しているというポーズだけではないのかなどの声もあるようだが、このような動きは今後も確実に増えていくだろう。
グリーンコーディング
IT業界でも、グリーンITという言葉がある。IT自体をグリーンにしよう、すなわちIT利用時にできるだけ環境に優しくするという考えと、ITを活用することで環境負荷を減らそうという考えの双方を含んだ言葉だ。
前者はIT機器や環境、利用方法をグリーン化するという考えであり、省エネ型のIT機器の利用などのようなオフィス環境での取組の他、データセンターにおけるエネルギー公立の高い冷却システムの導入や再生可能エネルギーの利用などが挙げられる。
このグリーンITで、ソフトウェアエンジニアにも貢献が求められているのではないかと思い、環境に優しいコーディングの存在について調査してみたところ、「グリーンコーディング」というベタな呼称の考え方があった。
グリーンコーディングは従来までの処理効率を高めるコーディングと共通するところが多い。メモリやプロセッサの使用効率を高めることは無駄なエネルギーを使わないことであり、両者の目的は一致する。
しかし、反面、昨今のコーディングは開発効率も追求する。また、ユーザーへの応答速度の最大化が最優先されることも多い。前者は汎用的な技術の利用を促し、後者は最終的にはシステム的には無駄な処理をすることがあっても、ユーザーへの応答を優先することが良しとされる。
例えば、オープンソースの活用により、開発効率は高くなる。普及しているフレームワークやライブラリーを使うことで、エンジニアの学習コストは下がり、（広く使われているコードを再利用することで）品質も高くなる。他方、オープンソースは多くの場合、自分が必要とする機能以外も含まれている。それはフットプリントの増大にも繋がり、環境負荷を高くする。自分が必要とする機能だけを抽出すれば良いのだが、それは更新の手間を増やし、開発効率を悪くする。更新頻度が下がれば品質へも影響する。
ユーザーへの応答速度改善のためのテクニックとして良く知られたものに投機的実行がある。パイプライン処理などで、使われるかわからない処理であっても、その処理を行い、最終的にその処理結果を廃棄することも厭わないが、使われることになった場合はすでに処理が行われているため、待ち時間が無く、パイプライン処理はブロックされないことになる。これも予測が外れていた場合には無駄な処理を行うことであり、環境には優しくない。
この投機的実行と同じようなことは、プリフェッチやプリロードと呼ばれる処理においても行われている。すなわち、フェッチすることになるであろう・ロードすることになるであろうという予測を元に先んじてフェッチやロードをすることで、全体的な処理速度を高めるというものである。予測はヒューリスティックに基づき行われており、その精度が一定以上のときに「プリ」動作は行われるようになっているが、予測が外れることも少なくない。この処理が行われるのがWebアプリケーションなどの場合には、ローカルデバイスの処理に無駄が発生するだけでなく、無駄な通信を行うことにもなり、環境負荷は高まる。
考えてみると、我々はある課題を解決するために技術を進歩させるが、その進歩は課題解決以上のものとなることが多く、そのあまり余った技術向上を「無駄遣い」する形で消費してきていたのではないか。そして、その消費 - 浪費と呼んでも良いかもしれない - は当初贅沢だったかもしれないが、程なく普通となり、絶えることなく増大した欲望を満たそうとする中で生まれる課題を解決する形で技術は進化する。
しかし、時代は変わった。持続的な成長のために、コーディングも変わらなければならない。
次のIBMの記事の冒頭では、20年前の帯域幅や処理能力の制約の中でコーディングをしていたことを回顧しているが、また我々はその時代に戻るのかもしれない。富豪的プログラミングは過去のものか。
グリーンコーディングの普及により、プログラミング言語の選択にも影響を与えるかもしれない。2017年に発表された"Energy Efficiency across Programming Languages"という論文では、エネルギー効率の良いプログラミング言語を調査した。この論文では27の言語のエネルギー消費、実行時間、使用メモリを様々なベンチマークに対して行って比較している。想像できるように、1つの言語がすべてにおいて有利ということは無く、何を重視するかによってどの言語を選択すべきかというのも異なっている。
なお、この論文での比較については、Elixirでの開発を行っているソフトハウスにCuriosumという会社がブログで「Elixirが含まれていないのは、ElixirやErlangがそもそも対象としていなかった数学的な計算を用いたベンチマークであるからだ」とこの論文の不備を言っているのを見つけたが、確かにこのランキングだけが独り歩きするのは危険だと思う。ちなみにこのブログ記事はグリーンコーディングについて網羅的に説明されていて、参考になる。
グリーンコーディングにどう取り組むべきなのか
我々人類にとって、もはや飛行機という手段での移動を完全に廃止することは不可能である。しかも、冒頭にも書いたように、飛行機での移動を制限したとしても、どれだけ効果があるのかもわからない。
根本的な解決には、SAF (Sustainable Aviation Fuel) を普及させるしか無いかもしれないが、廃食油の争奪戦も激化する中、利便性の飽くなき追求という価値観を諦めなければいけない時代になってきているのかもしれない。
ソフトウェアやITについても、ソフトウェアエンジニアがコーディングという作業の中でできる二酸化炭素の排出量抑制には限界があろう。持続的な成長のためには、利用者含めての価値観を変えることが求められているのだろうか。技術でできるからという理由だけで、ひたすら要求を満たし続けて良いのか。ある技術を使って良いのかどうか、どのような技術を使うべきなのか、その判断に「環境」という条件が加わっていることを我々は忘れてはならない。
