AIにExcelの関数やマクロを作ってもらい、無事に動いた。でも数か月後に「なぜこの関数にしたの？」「重くなったらどうする？」と聞かれたら、説明できるでしょうか。
今回のテーマは設計判断メモ。難しい設計書ではなく、選んだ理由・選ばなかった理由・見直す条件を短く残す方法です。Excelの自動化を例に、はんちゃんとチャーが考えます。
AIで作った処理。「なぜこの方法？」に答えられる？
はんちゃん（SE）チャー、AIにExcel関数を作ってもらえばすぐ動くけど、半年後に『どうしてこの方法にしたの？』って聞かれたら困るかもしれないね。
チャーそうだニャ。動いたという事実と、その方式を選んだ理由は別。小さなメモでも残しておくと役立つニャ🐈
Excelで「商品名からカテゴリーを判定する」場合、関数・VBA・Power Queryなど複数の実現方法があります。正解が一つとは限らず、現状の規模、更新頻度、性能、保守する人を踏まえて選びます。
実例：商品2,000件ならExcel関数を選ぶ？
例えば商品一覧が約2,000件、キーワードマスターが約100件あるとします。商品名に「魔王」が含まれれば「焼酎」、「八海山」が含まれれば「清酒」と判定する架空の例です。
| 候補 | よい点 | 今回はどう考える？ |
|---|---|---|
| Excel関数 | セルで結果を確認しやすく、導入が簡単 | まず候補にする。ただし処理時間を実測 |
| VBA一括処理 | 一括読み込み・出力でシートへのアクセスを抑えられる | 現状では運用・マクロ管理の負担も比較 |
| Power Query | 定型データ加工を更新で繰り返しやすい | 部分一致の実装負荷と性能を検証 |
はんちゃん（SE）今回は関数が有力そう。でも『2,000件だから必ず速い』とは言い切れないんだよね。
チャーその通り！ マスター件数や数式次第で変わるから、採用は実測してからが大事だニャ。
設計判断メモとは？ ADRとの違いは？
設計判断メモは、どの方式を選んだかだけでなく、その背景と代替案を残す記録です。ソフトウェア設計では、こうした意思決定を残す文書をADR（Architecture Decision Record：アーキテクチャ決定記録）と呼ぶことがあります。
ただし、Excelの小さな改善に正式なADRの書式をすべて使う必要はありません。まずは後で見た人が判断理由を理解できることを目指しましょう。
6ステップでわかる！ 設計判断を残す手順
商品名からカテゴリーを自動判定する。対象は商品一覧とキーワードマスター。
現状の商品件数、キーワード数、更新頻度、利用者・保守担当を記録。
Excel関数、VBA一括処理、Power Queryの導入負荷・性能・保守性を比較。
現時点では関数を第一候補にする。検証を通過した場合に採用を確定。
一括処理やPower Queryは保留。許容時間超過・データ増加などで再評価。
実測時間、試したデータ件数、確認日、判断者を記録し変更時に見直す。
保存版：設計判断メモの書き方と記入例
コピペして使える！設計判断メモ（テンプレート）
- 対象処理：［何を自動化する？］
- 現状・前提：［件数／更新頻度／利用環境］
- 求める条件：［結果の正しさ／許容処理時間／運用方法］
- 検討した方式：［案A／案B／案C］
- 採用方式・理由：［どれを、なぜ選ぶ？］
- 採用しなかった案・理由：［今回はなぜ見送る？］
- 検証結果：［測定条件・結果・確認日］
- 見直し条件・次の手：［いつ／何を再評価する？］
商品カテゴリー判定に当てはめると？
| 項目 | 記入例 |
|---|---|
| 対象処理 | 商品名に含まれるキーワードからカテゴリーを判定 |
| 現状 | 商品約2,000件、マスター約100件（仮定） |
| 第一候補 | Excel関数 |
| 選定理由 | 導入と変更が容易で、運用者が結果を確認しやすい |
| 見送る案 | VBA一括処理・Power Query（導入／保守負担も考慮） |
| 性能条件 | 例：更新後5秒以内（説明用の仮設定） |
| 検証結果 | 未計測。測定後に採用を確定 |
| 見直し条件 | 処理時間の許容値超過、件数増加、運用変更 |
重要：この表の「5秒」は実測値でも製品性能の保証でもありません。目標値を決めた後、同じPC・同じ規模のデータで実際に計測し、結果を記録してください。
はんちゃん（SE）不採用にした案も、あとで役に立つんだね。単に『今は使わない』で終わらせないのがポイントか。
チャーそうだニャ！ 状況が変わったら、残しておいた代替案を再評価できる。最初から複雑に作りすぎる必要もないニャ。
AIに設計判断メモを作ってもらう質問例
AIは選択肢や論点を整理する補助役として使えます。次のように依頼すれば、比較すべき点を見落としにくくなります。
商品名からカテゴリーを判定するExcel処理について、関数・VBA一括処理・Power Queryを比較し、設計判断メモを作ってください。
商品は現在2,000件、マスターは100件という仮定です。
機能要件と非機能要件を分け、採用理由・不採用理由・検証項目・見直し条件を整理してください。
処理速度の実測値はないため、数値を推測で断定しないでください。
AIが出した結論は確定した設計ではなく検討案。業務に使う前に、実際の要件・環境・測定結果で見直しましょう。公開用のメモでは、顧客名や業務システムの内部情報などは伏せてください。
まとめ：大切なのは「どれを作ったか」だけじゃない
AIのおかげで、Excelの自動化を始めるハードルは下がりました。だからこそ「なぜ選んだか」「どんな条件なら見直すか」という判断を残すことが重要になります。
はんちゃん（SE）AIで作れるようになった次は、選んだ理由を説明できるようになりたいね。
チャーそうだニャ🐈 迷ったときは選択肢を比べて、試して、記録する。この3つを覚えておけば、次の改善にもつながるニャ！
連載を最初から読む
※商品・件数・性能目標は説明用の架空の例です。実際の処理速度はPC環境・データ規模・実装方式に依存します。
コメント