LET 関数の使用をやめました。Excel シートの方が適しています。

エレガントな Excel 数式の構築にはある種の誇りがあり、2020 年に LET 関数が導入されたとき、複雑なロジックを 1 つのセルに圧縮するための私のお気に入りのツールになりました。しかし、最終的には、これらの洗練された数式によって、スプレッドシートの監査、デバッグ、および後からの適応が難しくなっていることに気づきました。

このパワーユーザーの傾向を捨てて、昔ながらのシンプルさを支持したことで、ワークブックの作成方法と共有方法が完全に変わった理由は次のとおりです。

エレガントな LET 関数が隠れた罠である理由

計算のためのブラックボックス

LET 関数は技術的に優れています。数式内で変数を定義できるため、Excel は大規模なデータセットにわたって同じロジックを繰り返し計算する必要がなくなります。理論的には、これによりパフォーマンスが向上し、繰り返しが減り、数式がきれいに保たれます。

理論上は、明らかにアップグレードされているように感じます。この関数の支持者は、この関数が正当なソフトウェア エンジニアリングの原則をグリッドにもたらすと正しく指摘しています。この関数は、「DRY」(同じことを繰り返さない) 原則を遵守するのに役立ちます。つまり、重い式を一度計算し、後で名前で参照できるということです。階層またはレートが変更された場合、1 つの場所で更新するだけで済みます。さらに、これらの変数は厳密にローカルであるため、数式が評価されると消えます。その結果、ワークブックの名前マネージャーを混乱させたり、将来の名前の衝突の危険を冒したりすることなく、変数に任意の名前を付けることができます。

しかし、その「構造」には、当初は私が理解していなかった代償が伴います。

問題は、その清潔さが視認性を犠牲にする場合に発生します。単一のセルに圧縮された複数ステップの計算は一種のブラック ボックスになります。データが入力され、結果が出力されますが、中間ロジックは事実上グリッドから消えます。言い換えれば、LET は数式を構造化する方法を擬似コードのような環境に移行します。カジュアル ユーザーにとって、抽象変数でいっぱいの数式は、従来のスプレッドシートで作業するというよりも、JavaScript のスニペットを読んでいるように感じられます。単純な左から右への式に従うのではなく、コードの垂直ブロックを読み取る方法を学ばなければなりません。

標準のダッシュボードや日々のレポートに LET を使用すると、小切手帳の残高を計算するのに微積分を使用しているように感じることがよくあります。単純な算術では必要のない概念的なオーバーヘッドが追加され、後でロジックを再検討することが困難になります。

従来のヘルパー列が日常のスプレッドシートにとって優れたソリューションである理由

即時の監査証跡

計算をヘルパー列に分割すると、スプレッドシートの操作方法が完全に変わります。すべてを 1 つの数式に圧縮するのではなく、各論理ステップをグリッド全体に分散させました。 1 つの列は基本計算を処理し、別の列は条件を適用し、別の列は結果を最終出力に結合します。これまで数式の中に隠されていたものが、段階的なプロセスとして表示されるようになりました。

何かが間違っていると思われる場合でも、式をリバース エンジニアリングする必要はありません。行全体をスキャンすると、どのステップが予期しない値を生成したかをすぐに確認できます。デバッグは手順的ではなく視覚的になり、それだけで、コンパクトな式からパフォーマンスを最適化するよりも多くの時間を節約できます。

OS

Windows、macOS、iPhone、iPad、Android

無料トライアル

1ヶ月

Microsoft 365 には、最大 5 台のデバイスで Word、Excel、PowerPoint などの Office アプリ、1 TB の OneDrive ストレージなどへのアクセスが含まれています。

このアプローチは、値がシート内をどのように流れるかを正確に示す Trace Precedents などの Excel の組み込み監査ツールでもはるかに効果的に機能します。 LET では、その構造が単一の細胞内に閉じ込められます。計算手順を確認するには、数式バーを展開し、改行で折り返されたテキストを目を細める必要があります。

最も重要なことは、ヘルパー列が中間計算を使用可能なデータに変えることです。数式内でロックされた隠し変数の代わりに、ワークブック内の任意の場所でフィルター、並べ替え、再利用できる列を取得します。かつて内部ロジックだったものが、データセット自体の一部になります。これは、概要レポートを作成する場合に特に当てはまります。ピボットテーブルは LET 式の内部に到達して隠し変数を抽出することはできませんが、 できる 物理的なヘルパー列を簡単にスライスおよびダイスできます。

隠された数学から目に見える構造へのこの変化は、本当の利点です。

グリッドを乱雑にせずにモジュラーデザインを使用する方法

よりクリーンな UI

ヘルパー列に対する最も一般的な反発は、純粋に見た目の問題です。スプレッドシート文化には、列が増えると自動的にデザインが悪化するという通説が根強く残っています。実際には、ロジックをモジュール構成に分割することが最も保守しやすい方法であることが多く、そのためにクリーンなレイアウトを犠牲にする必要はありません。

私は、ヘルパー列によってシートが乱雑になったり、プロフェッショナルらしくなくなったりするのではないかと心配していました。実際には、その逆が当てはまります。乱雑な状態は、すべてが常に一度に表示される場合にのみ存在します。Excel には、視覚的なノイズを管理するために必要なツールがすでに用意されています。

プレゼンテーションが主な関心事である場合は、ヘルパー計算を完全にバックグラウンド ロジック専用の別のタブに移動できます。これにより、舞台裏での完全な透明性を維持しながら、メイン シートは入力、出力、クリーンなレポートに厳密に焦点を当てたままになります。

一方、すべてを 1 か所に保持し、Excel のネイティブ グループ化機能を使用してヘルパー列を折りたたむこともできます。素早い切り替えにより、基礎となるメカニズムを日常のビューから完全に非表示にし、システムを調整または検査する必要があるときにいつでも再度展開することができます。

これにより、LET 関数ではできないもの、つまりオプションの複雑さが得られます。ロジックはオンデマンドで表示または非表示になりますが、アクセスできないことはありません。また、下位互換性の問題も回避できます。古いバージョンの Excel を使用している人とファイルを共有すると、複雑な LET チェーンによって #NAME? の壁が崩れてしまいます。エラー。ヘルパー列は、実行しているバージョンに関係なく、普遍的に機能します。

さらに良いことに、LET の名前付き変数の読みやすさが気に入っている場合は、ヘルパー列に切り替えるときに名前付き変数を諦める必要はありません。 Excel の名前付き範囲ツールを使用すると、パラメーター セルにわかりやすい名前を直接割り当てることができます。 $B$7 のような抽象セル参照を指す数式を記述する代わりに、ヘルパー列で Deal_Threshold のような名前付きセルを参照できます。 LET 変数とほぼ同じ可読性が得られますが、計算は引き続き表示され、監査が容易になります。

透明なスプレッドシート レイアウトによる共同作業の利点

時間の経過とともに明らかな修正が加えられる

Excel スプレッドシートの本当の強みは、最初に作成したときのパフォーマンスだけではなく、時間が経ってもそれがどのように維持されるかです。

ロジックを明確なステップに分割すると、問題の特定と解決が容易になります。複雑な式を解明したり、隠れた変数を再構築したりする必要はありません。計算パスはすでに目の前にレイアウトされています。これにより、特に数式の構造を忘れて久しい古いファイルで問題の診断に費やす時間が短縮されます。ロジックを一から学び直す代わりに、地図のようにシートをたどることができます。

また、変更をより安全に行うことができます。ロジックが変化した場合でも、単一のセルに埋め込まれたネストされた式全体が壊れることを心配することなく、個々のステップを更新できます。

これにより、時間の経過とともに、私だけが安全に編集できる脆弱なシステムではなく、更新、改訂、忘れられたコンテキストにも耐えられる耐久性の高いスプレッドシートが作成されます。

シンプルさがスプレッドシート ゲームに勝つ

私が学んだ本当の教訓は、LET が悪いということではなく、最適化と可読性が実際には必ずしも一致しないということです。 LET のような複雑な数式への傾向に抵抗することで、日々の仕事生活が大幅に改善されます。単一セルのブラック ボックスをオープン ヘルパー列と交換すると、同僚 (そして将来のあなた) はトラブルシューティングがはるかに簡単になるでしょう。これは、Excel スプレッドシートの操作と長期的な保守を容易にする 1 つの方法にすぎません。