AIBR プレミアム
拓海先生、最近部下から「ソフトウェアのエネルギー効率を上げろ」と言われまして。論文を読めば良いと言われたのですが、どこから手を付ければ良いのか見当がつきません。まず、この論文は何を変えるんでしょうか。
素晴らしい着眼点ですね、田中専務！この論文は「ソフトウェア開発の現場で見られる、持続可能性（sustainability）に関わる欠陥＝弱点を整理して知識ベースにする道筋」を示しているんですよ。結論を先に言うと、標準化した知識がなければ自動診断ツールは育たない、だからまず弱点を体系化する必要があるんです。
要するに、ソフトのどこが悪いと電力喰うかをリスト化するってことですか。じゃあ既にあるセキュリティの弱点リストを使えば済むんじゃないですか。
良い質問です。ここで出てくるのがCWE（Common Weakness Enumeration、共通弱点列挙）という既存の弱点カタログです。論文はCWEを出発点にすることを提案しているものの、既存のタグをそのまま再利用するだけでは不十分だと示しています。理由は、ある弱点が持続可能性に与える影響は文脈依存だからです。
文脈依存、ですか。現場では一律のルールを当てはめたがる人が多いのですが、投資対効果に直結するなら慎重にやらねばなりません。実務目線で何が問題になりますか。
ポイントは三つです。第一に、どの弱点がエネルギーや計算資源にどれだけ影響するかの定量化が必要です。第二に、ソフトの運用環境やハード構成によって影響度合いが変わるため、弱点と影響の関係を文脈付きで記述する必要があります。第三に、その知識をツールに落とし込むための形式化が必要です。大丈夫、一緒にやれば必ずできますよ。
これって要するに、既存の弱点リストをそのまま持ってきて『これは持続可能性に悪い』と印をつけるだけじゃダメで、どのくらい悪いのか数字を出して優先順位をつけられるようにしないとツールは使えない、ということですか。
その通りです、田中専務。論文の実験でも、既存の弱点を単純にリタグ付けするだけでは誤った優先順位が生まれることを示しています。ですからまずは小さな知識ベースを作り、実データで影響度を測り、そこから優先度付けルールを整備するのが現実的です。
現場に落とすときの障壁は何でしょう。人手でチェックするのは難しいが、IT投資は慎重に行いたいのです。
実務の障壁も三つに整理できます。まず既存の開発フローに組み込む簡便さ、次に測定データを集めるコスト、最後に優先度を決めるためのビジネス指標との紐付けです。優先度はエネルギー削減量だけでなくコスト削減や品質影響も考慮すべきで、これができれば投資対効果は見えます。
なるほど。小さく試して効果を見てから本格導入、というのが現実的というわけですね。最後に私の言葉で確認させてください。要するにこの論文は「持続可能性に関するソフトの弱点を標準化して知識ベース化し、文脈に応じた影響度評価を行うことがツール化と投資判断の第一歩である」と提案している、ということで宜しいですか。
全くその通りです、田中専務。素晴らしい着眼点ですね！短期的には重要度の高い弱点を絞って試験導入し、運用データを集めて知識ベースを拡張する流れが現実解ですよ。大丈夫、一緒にやれば必ずできますよ。
