この開発者の習慣を Excel に取り入れたので、今後の作業時間を節約できました

Excel での作業を楽にしたいと誰もが思っていますが、それはアプリ自体の先を見据えることを意味する場合もあります。スプレッドシートの作成はプログラミングと多くの共通点があるため、私はそこから最も有益な習慣の 1 つを盗みました。

リファクタリングとは、すでに動作しているものの動作を変更せずに内部構造を改善する実践です。開発者は、コードの理解、保守、デバッグ、変更を容易にするためにこれをよく使用します。ここ数年、私は同じ原則を Excel ワークブックに適用するようになり、その後の多くの作業を省略できるようになりました。

ロジックを単純化する

実用的な公式にはまだ変更する価値がある

Excel を使用しているときに私がいつも陥っていた罠の 1 つは、正しい答えが得られたため数式が完了したと思い込むことです。私は数式を違った視点で見るようになりました。数式が読みにくく、理解しにくく、修正するのが難しくなった場合は、それが完全に機能する場合でもリファクタリングします。

それは、IF ステートメントの長いチェーンをより単純な IFS 式に置き換えること、反復計算を管理しやすくするために LET を使用すること、または同じ複雑なロジックを複数回作成していることに気づいたときに LAMBDA を作成することを意味するかもしれません。

変数を追加するにつれて数式が増大し続ける場合は、代わりにそのロジックの一部をヘルパー列に移動します。これにより、各ステージの検査とデバッグが容易になるだけでなく、ピボットテーブル、グラフ、その他の計算で使用できるフィールドも提供されます。

データにより良い構造を与える

場合によってはワークブック自体を変更する必要がある

開発者は、ロジックを簡素化するだけでなく、プロジェクト自体の構造をリファクタリングして、作業しやすいように移動することができます。私は同じ考えを Excel に適用して、データ、計算、レポートをどこに置くべきかを検討します。

ブックのこれら 3 つの部分を別々にしておくことは、ファイルが大きくなるにつれて効果的です。これらを混在させると、どのセルに基礎となる情報が含まれているのか、どのセルが情報を変換しているのか、どのセルが単に結果を表示するために存在しているのかを区別することが難しくなるためです。

私は 3 タブ ルールと呼ばれるものを使い始めました。生データをに移動します ソース タブ、計算と変換 論理 タブに移動し、完成したレポートまたはダッシュボードを インタフェース タブ。他のタブも使わないというわけではありません。たとえば、私はよく次のように追加します。 お読みください タブ – 私が共有する予定のワークブックで、開発者から無作為にスワイプしたもう 1 つの方法。 参考データ 計算で調べる必要がある情報を表示するタブ。ただし、データをこれら 3 つのメイン タブに分割することは、古いファイルをリファクタリングするときの優れた出発点になります。

そして、拡大する可能性のあるデータセットを操作する場合は、それを Excel テーブルに移動します。これにより、データに定義された構造が与えられ、数式や参照の管理が容易になり、レコードを追加するたびに範囲を調整し続ける必要がなくなりました。

Excel で退屈な作業を自動化する

繰り返しは何かを微調整する必要があるというサインです

私は習慣の生き物なので、タスクを繰り返すことはすぐに私の日課の一部になりました。ワークブックを更新するたびに、同じインポートされたデータをクリーンアップし、同じ概要を再構築し、同じ範囲を拡張し、同じ書式設定を適用します。リファクタリングについて考え始めてから、これらのタスクを Excel に処理させる方法を探しました。

インポートされたデータを繰り返しクリーニングする場合、それは Power Query の仕事になります。新しいレコードが到着するたびに同じ概要を再構築する場合、通常はピボットテーブルが引き継ぐことができます。別の行を追加するたびに範囲を手動で拡張している場合、Excel テーブルではその手順を省略できます。

プレゼンテーションについても同様です。特定の値または条件に基づいて同じ書式設定を適用し続ける場合、条件付き書式設定により、それが Excel が自動的に処理するルールに変わる可能性があります。

ワークブックを理解し、変更しやすくする

次の編集はわかりやすくしたい

私が作るワークブックは目で見るだけのものが多いので、「後で覚えよう」と思いがちです。実際には、そのようなことはほとんどありません。だからこそ、私は今、すべてのスプレッドシートを、あたかも誰かに渡すかのように扱うようにしています。既存のワークブックをリファクタリングするとき、私は次の変更を必要以上に困難にする要因を探します。

それは私が下す決定の一部に影響を与えます。ハードコーディングされた仮定は明らかなターゲットです。仮定を専用のセルに移動するということは、数式を調べなくても一度変更できることを意味します。固定範囲は別です。データが増加することがわかっている場合は、それに対応するために範囲をテーブルに置き換えます。一般的なテーブル名やワークシート名などの単純なものであっても、後でその意味を思い出す必要がある場合には、変更する価値があります。

また、ワークブックのさまざまな部分間の依存関係についても見ていきます。 1 つの計算を変更することがレポート、ヘルパー範囲、およびいくつかの無関係な数式をチェックすることを意味する場合、それはファイルで既に作業している間にそれをリファクタリングする良い機会です。

最後に、私はできる限り式そのものを説明するようにしています。特に複雑な計算の場合は、N() 関数を使用して数式内に短い説明を残します。結果は変わりませんが、後でワークブックに戻ったときに、なぜそのロジックがそこにあるのかを思い出す必要がなくなるということです。

不要なものを削除する

リファクタリングは、物事を取り除くことを意味する場合があります

これは簡単そうに思えますが、ワークブックから何かを削除するのは、見た目よりも難しい場合があります。数式、ヘルパー列、ワークシート、または回避策を追加すると、それが必要なくなった後でも、それがワークブックの DNA の一部のように感じられることがあります。

そのため、古いファイルに再度アクセスするときは、不要な要素を削除することが最初に行うことの 1 つです。重複データ、未使用の名前付き範囲、冗長な数式、時代遅れの非表示ワークシート、何もフィードされなくなった計算をチェックします。使い始めると、時間の経過とともにワークブック内にどれだけ多くのジャンクが蓄積されるかに驚かれることがよくあります。個々の追加は、その時点では意味があったかもしれませんが、数回の変更の後、削除できる衝撃的な量が存在することがよくあります。

これは、ワークブックのリファクタリングで最も満足のいくフェーズの 1 つです。完成すると見栄えが良くなるだけでなく、見た目も軽くなり、作業が楽になります。

---

Excel は見た目よりもプログラミングに似ています

私は何年も Excel を使用してきましたが、その背後にある開発者の原則についてあまり考えませんでした。しかし、スプレッドシートをソフトウェアのように扱うようになってからは、リファクタリングがワークフローの自然な部分になりました。結局のところ、多くの Excel ユーザーは気づかないうちにすでにプログラマーになっており、Excel はそれ自体が実質的にプログラミング環境なのです。そのため、私にとっては、リファクタリングのような借用の習慣が非常に自然に感じられます。