この業務プロセスは、まだスプレッドシートに適していますか？

チームが発注内容の決定、レポートの作成、定期的な記録の管理にスプレッドシートを使っているなら、実際の業務の進め方を確認する価値があります。大切なのは、必要な情報を正しく入力し、結果を確認し、業務に必要な確信を持って結果を使えるかどうかです。

複雑なブックでもうまく機能することがあります。シンプルなブックでも見直しが必要な場合があります。使い慣れているか、古いか、会社の規模がどれくらいかだけでは、どちらとも決まりません。

まず重要な結果を一つ選び、その背後にある人と手順をたどりましょう。そのうえで、今の仕組みを保つのか、具体的な箇所を改善するのか、別のツールを調べるのかを決めます。

ブックを通じて一つの判断を追う

小さな会社が毎週の在庫発注を準備するためにブックを使っていると想像してください。これは説明のために作った架空の例です。在庫数、顧客からの注文、入荷待ちの商品をまとめ、運用担当者が提案数量を確認してから、別の人が発注します。

商品を一つ選び、提案された発注数をどう計算したのか、担当者に説明してもらいましょう。在庫数はどこから来たのでしょうか。いつ記録されましたか。未処理の注文は誰が入力しましたか。提案を確認する人と、実際に発注する人は同じバージョンを見ていますか。

計算の先も確認しましょう。誰が提案を変更できますか。誰が使用可能と判断しますか。未着の商品が抜けていたり、数量が二重に入力されたりした場合、誰が気づくでしょうか。ブックの作成者が不在のとき、誰が内容を説明し、必要な変更をできますか。

結果が間違っていたらどうなるかも考えましょう。予備のペンを数本多く買うことと、返品できない高価な部品を発注することでは、影響が異なります。ブックをどれだけ注意して扱うべきかは、それが支える業務に応じて決まります。

ICAEWの「良いスプレッドシート実務のための20原則（2024年版）」も、この考え方を示しています。スプレッドシートが業務に適しているかを考え、重要なブックには適切な管理策を設け、保守や確認をする人が理解できるようにすることです。これは専門家向けの指針であり、行数や利用者数が一定に達したら置き換えるという規則ではありません。

修正を選ぶ前に、見つけたことを説明する

確認の結果、ブックと周辺の手順がすでに要件を満たしていることもあります。それも有用な判断です。今の仕組みを保ち、引き続き管理する担当者を決めておきましょう。

問題が見つかったら、実際に起きたことを説明します。在庫の例では、修正済みの数量が最新のブックに反映されていても、発注担当者が古いコピーを使ったのかもしれません。これはバージョンの問題を示していますが、原因が分かりにくい指示、ファイルの共有方法、現在の環境の制約のどれなのかは、まだ分かりません。

修正は、最新のブックを置く場所とアクセス方法を決めるだけで済むかもしれません。GOV.UKのスプレッドシート作成・共有ガイダンスでは、目的を明確にすること、分かりやすい名前やバージョン情報を付けることに加え、保存環境でバージョンがどう管理されるかを把握することを扱っています。自社の保存・共有方法を頼りにする前に、実際の動作を確認してください。

ほかの課題には、入力情報と計算結果を明確に分ける、入力値を確認する、短い説明を加える、別の適任者に見てもらう、といった対応が考えられます。見つかった問題に合う変更を選びましょう。入力項目が分かりにくいなら、入力方法を明確にするのが解決策かもしれません。

誤操作の防止とアクセス管理を分けて考える

二つの要件を区別すると考えやすくなります。計算式を誤って変更されないようにすることと、機密情報を誰が見られるかを決めることです。

Excelについて、Microsoftはファイル、ブック、ワークシートの保護を区別しています。シート保護はロックされたセルの変更を防げますが、Microsoftはセキュリティ機能として設計されたものではないと説明しています。

そのため、特定の記録へのアクセス制限が必要なら、実際に使っている環境のアクセス権と共有設定を調べてください。セルのロックやタブの非表示では、情報の機密性は保てません。計算を保護しても、誰が発注を承認できるかは決まりません。それぞれの要件が実務でどう満たされているかを確認しましょう。

安全な例を一緒に試す

実際の発注を使って試さなくても、有用なことを確認できます。架空の記録を入れた、代表的な別コピーを用意しましょう。試す前に予想される結果を書き、別の適任者にも結果を確認してもらいます。

在庫の例では、まず単純な在庫数と発注から始めます。次に入力を一つ修正し、提案が予想どおり変わるか確認します。さらに、在庫数がマイナスになるような珍しい値を試し、ブックまたは確認担当者がそれに気づき、どう対応するか分かるかを見ます。

引き継ぎも確認してください。確認担当者は、対象のバージョンを見つけて結果を理解できますか。作成者以外の人も計算を説明できますか。ブックや手順を変更した場合は、影響を受ける手順をもう一度確認します。

ここで分かるのは、試した例についての証拠です。ブック全体を認証するものではなく、あらゆる間違いを見つけられると証明するものでもありません。説明できない結果があれば、頼りにする前に調べてください。

見つかった課題に応じて次の手順を選ぶ

ここまで確認できれば、実務を担当する人に判断の理由を具体的に説明できるはずです。

• 使い続ける：現在の仕組みが業務の要件を満たし、担当者が保守と確認をできる。
• 改善する：ブックや手順への現実的な変更で対処できる弱点が見つかった。変更箇所を確認してから利用する。
• さらに調べる：結果、アクセス設定、必要な管理策のいずれかが不明なまま。確認すべきことと担当者を明確にする。
• 別のツールと比較する：明確な要件が満たされておらず、現在の環境ではそれを確実に提供できない。

たとえば、各発注の承認記録を残し、在庫記録と関連付ける必要があるかもしれません。現在のツールでチームが確実に実行できるかを確認しましょう。できない場合は、別のアプリを評価するための具体的な要件が見つかったことになります。

比較対象には既存のアプリも含まれ、要件に合うならカスタムソフトウェアも選択肢になります。必要な機能が具体的に不足しているなら、カスタム業務ソフトウェアサービスを通じてご相談ください。チームが何をする必要があり、現在の環境では何を実現できないかが、出発点になります。

業務記録を後から別の場所に移しても、分析にはスプレッドシートが役立つ場合があります。それぞれの業務に必要なものを基準に、どこで扱うかを決めましょう。十分に検討したうえでブックを使い続けるという判断も、立派な結論です。