Excel で設計書作るのそんなに悪いことか？

僕は長らく Excel で仕様書や設計書、テストケースなどを作ってきた。現在も、何か情報を整理しようと思うと、とりあえず Excel に書き始めている。とある現場では「Excel マスター」なる称号をもらったりしたし、Excel の細かな仕様は技術ブログ Corredor でも度々紹介してきたとおり、そこら辺のニホンノエスイーよりは熟知した上で使っていると自負している。

しかし、ネットの界隈では「まだ Excel で仕様書書いてんの？」という風潮が強く、「Excel で仕様書のフォーマット作ってみました！」みたいな記事にネガティブコメントがわんさか付き、「Docker を使って PlantUML 環境を構築！」みたいな記事が高評価を得ていたりする。自分も技術オタクなので、イマドキのツールが簡単便利に色んなことができるのを見ると、いいね！と思うし、そういうモノを追っかけるのは楽しいとは思う。

そういう、どちらの面もそれなりに経験してきたつもりの、いち SE が強く感じるのは、Excel 仕様書はやっぱり便利なところが多い、ということだ。そして、Excel 仕様書をバカにしてるヤツはドキュメント作成能力が低く、どんなツールを使っていてもマトモなドキュメントを作れない、ということも感じている。

今回は、Excel 仕様書とそれ以外のツールとを比べて、Excel 仕様書の問題点と対処法、他のツールの欠点を雑多に記していこうと思う。

Excel 最強の教科書［完全版］――すぐに使えて、一生役立つ「成果を生み出す」超エクセル仕事術

目次

• Excel 仕様書の悪い点と、意見・反論
• Excel 以外のツールで仕様書を書く時のデメリット
• Excel 仕様書のメリット
• 論者たちの働く業界が違うんじゃねーの？
• それにしても Excel ちからが足りねえよどいつもこいつも
• 総合的な意味合いで「Excel ちから」を身に着けましょう

Excel 仕様書の悪い点と、意見・反論

Excel 仕様書の悪い点としてよく挙げられるのは、次のような内容だろう。

• バイナリファイルなのでバージョン管理ツールで変更箇所を管理できない
• 複数人での同時編集ができない
• 複数人でドキュメントを育てていると何の資料だか分かりにくくなってくる
  • 要件一覧のつもりだったのに、スケジュール管理用の列ができてしまったり、みたいな
• 計算式を入れていくと管理しきれなくなってくる
• 印刷時にズレたり文字が見切れたりする
• Excel 方眼紙はセル結合、折り返し制御などがダルい
• 罫線や背景色の破損など、仕上がりを気にしだすと無駄に手間がかかる
• 行追加したりすると ROW() で書いていた行番号がズレる、それを直すのにいちいち手間がかかる
• Excel とかダサい

これらについて、反論を入れてみる。

• バイナリファイルなのでバージョン管理ツールで変更箇所を管理できない
  • 素直に git diff で確認できない点は分かる。
  • しかし、WinMerge プラグインなどを使えば Excel の差分表示はできる。プラグインの存在を知っていて使いこなせている上で文句を言っているのか怪しいところ。
    • テキストベースで作成できるツールの優位性を語りたいがためにこういう論点を持ち出す人が多いようだけど、単に Git ちからがないだけ。
  • 「差分ビューアを用意しても差分がひっちゃかめっちゃかで分かりにくい」という場合は、2つの原因がある。
    • 一つは、コミットに複数の変更を混ぜ過ぎ。こういうコミッタはコード修正の時もコミットの粒度を小さく保ててないはず。単に Git ちからがないだけ。
    • もう一つは、複数箇所に変更が入りやすいフォーマットを作っていることが問題。コレは Excel ちからの不足。
• 複数人での同時編集ができない
  • 「共有ディレクトリで1ファイルを共有設定にして編集」という古い文化だと、やりづらさは分かる。
    • ただ、共有設定による機能制限は「Excel でリッチなことをしないようにする」ための抑止力に繋がるので、チーム内のルールを徹底できたら、うまく回せる。
  • Git 管理している場合も、マージがしづらいのは分かる。実は「共有設定」よりも無理が出るのはバージョン管理ツールによるオートマージができない点。
    • テキストファイルのようなオートマージはやはり困難。
    • 前述のとおり、一つの事柄に対する変更が複数箇所に入るようなフォーマットだと、プラグインを使った差分比較も苦しくなってくるので、Excel ちからが問われる。
  • Office 365 とかだともう少し編集しやすくなるし、Git とは違うが履歴管理もできる。
  • いずれの場合も、「1つのファイルを複数人が編集したくなる」状況そのものが悪くて、それをなんとかしないといけない。
    • コードでも「神クラス」に頻繁にマージコミットが入るのは、悪い作り。
    • 1ブックにつき3〜5シート程度に留めて作る。1ブック = 1クラスだと思えば、1ブックで単一責務原則を守るようになり、バカみたいに巨大な「神ブック」を作らなくなる。
    • ブックが別れれば、同時編集も起こりにくくなる。
• 複数人でドキュメントを育てていると何の資料だか分かりにくくなってくる
  • 当初と違う目的の行列を勝手に追加され、資料の用途が変わってしまう、という問題は、論理的思考力のないチームメンバの存在が悪。
    • ソイツはきっとクラスの適切な分割もできないだろうから、Excel が悪いのではなく使う人間の頭が悪い。
  • フォーマットを作る側にも問題があるかもしれない。「神ブック」に進化させやすい、すきのあるフォーマットなのかもしれない。
    • 当初の用途から外れた行列を勝手に追加されないように、フォーマットを作ることが大事。
    • DataManager クラスに何でもかんでも突っ込まれてしまうのは、DataManager なんていう目的を絞り込めていないクラスを作ったヤツが悪い。それと同じ。
    • 見出しをちゃんと作ること。
    • 「表紙」シートとかを作って、何のための資料で、何のための資料ではないか、を明記すること。勝手にやられそうだけど避けたいことは「禁止事項」として明記しておけば良い。
    • ドキュメンテーションコメントをちゃんと書くことと同じ。「ルール」を明文化できない人間が作るドキュメントは全然整理できていないからマジでクソ。
    • より強制力を強めるためには、表の範囲でセルに保護を付けてしまうのも一つ。
• 計算式を入れていくと管理しきれなくなってくる
  • 1つのセルに5つ以上の数式が含まれているのは、数式の使い方・管理の仕方が下手クソなだけ。Excel ちから不足。
  • 数式の妥当性は人間が検証できないといけない。そのためには、1つのセルに大量の数式を埋め込むのではなく、計算の途中経過を別シートや別の行に別けて残し、そのセルを参照することで最終結果を得るような作りにすることが大事。
  • 数式の中でも Alt + Enter で改行できるので、IF や AND が組み合わさる数式は、改行とインデントを付けてリーダブルな数式のコードにするべき。そんなことも知らずに数式使って分かりにくいとか文句言ってるヤツなんて、まさかいないだろうけど。
• 印刷時にズレたり文字が見切れたりする
  • Excel の仕様によるモノで、根本的な解決策はないのは確かだが、もう気にしなくて良くなるワークアラウンドを知らないだけ、とも言える。
  • 「メイリオ」を使っていれば文字切れは起こらない。過去にまとめた。
    • 【根本解決方法はなし】Excel で印刷プレビューすると文字切れが発生する件の原因と対策
  • いつまでも「MS P ゴシック」を使ってる、フォントに対する知識がないヤツが悪いんだよ。
• Excel 方眼紙はセル結合、折り返し制御などがダルい
  • Excel 方眼紙で複雑なテーブルを組み、そこにテキストを入力させようとするフォーマットは悪。大体はこのフォーマットを作った人間への憎悪が Excel というツールにも向かっているだけ。
  • 基本的に Excel 方眼紙を止めることが一番。
    • 1つのシートに情報を詰め込みすぎず、シートの分割単位も「単一責務の原則」に則って考え直す。
    • セルの幅や高さは「自動調整」に任せる。自分はシートの左上をクリックして全セルを選択したら行間・列間部分でダブルクリックして、幅や高さを全て「自動調整」に任せたブックしか作らない。
  • Excel 方眼紙が向いている場面もあるといえばあるので、使い勝手がよくなる場面でのみ適切に使用する。
    • 例えばスクリーンショットの貼り付けが主体のシートは、方眼紙状にしてあると「グリッド」での配置がしやすくなる。この時、他のセルには基本的にテキストを書かせないようルール化する。
    • ブックの説明を書くような、レイアウトを設けずテキストのみ書きたいシートは、方眼紙の列を「インデント」に見立てて使うと、「End カーソル」で箇条書きを飛ばしながら読めるようになったりする。
    • 「テキストだけならテキストファイルに書けよ」と言われそうだが、別ファイルに分けない方が良い点もある。後述する。
• 罫線や背景色の破損など、仕上がりを気にしだすと無駄に手間がかかる
  • Excel で見栄えにこだわる方が悪い。使い方の問題。
  • 「こうやって使えばいいんだよ」というノウハウ・定石集は以前作った。
    • Excel 個人的ノウハウ・定石集
• 行追加したりすると ROW() で書いていた行番号がズレる、それを直すのにいちいち手間がかかる
  • 変更に強い数式を作る能力がないだけ。Excel を使いこなせてないヤツが負け惜しみの文句言ってるだけ。
  • コレでも読んどけよ
    • Excel で空行やセル結合が混じっても連番を振る関数
• Excel とかダサい
  • こういうヤツが「イマドキのツール」で作った「イケてる (と本人は思ってる) ドキュメント」がメチャクチャ嫌われる理由をこれから解説してやるから聞いとけや

以上。全体的にまとめるとこういうことだ。

• Excel を知らない
  • Diff だって取れるっつーの
• Excel に無理をさせている
  • リッチな罫線にしたり、方眼紙でレイアウトしたり、というのは全てやりたいことが間違っている。それは製作者が悪いのであって Excel は悪くない
• 運用を考えて作成していない
  • 他の人が編集した時に壊れやすい数式を使ったり、壊しやすいフォーマットになっていたり
  • 大抵は1つのブック・シートに情報を詰め込みすぎている。情報をロジカルに分けて考えられていないことが問題で、使用するツールは関係ない

Excel 以外のツールで仕様書を書く時のデメリット

Excel 以外のツール、例えば PlantUML だったり Markdown だったり、といったところが想像されると思うが、こうしたツールを使う時に短所になる部分を挙げてみる。

• 閲覧者がそのツールをインストールしていないと表示・編集できない
  • いくらインストール作業が簡単だろうと、「インストール作業が必要」な時点でダメ。
  • 「Docker さえ入れてあればこのイメージ使って表示・編集できますよ！」と言った時点で、Docker なんか知らないであろう上司や客先に説明するための資料としては不合格。
  • Excel はその他のツールと比べても、ほとんどの PC に入っているし、MacOS でも Numbers を使うなど、代替ツールが OS 標準に近い形で用意できる。
• (SaaS の場合) インターネット環境がないと表示・編集できない
  • 社内ネットワーク環境で作業している人間は、メールでデータをもらっても見られない。
  • 手元にデータが残せないので、会議室で Wi-Fi が繋がらないとその打合せがパーになる恐れすらある。
  • 完全にオフラインで表示・編集できないと困る現場は多い。
• 1つのファイルでは、図、表、箇条書きなどを組み合わせた「文書」の体裁にならず、全体像が見えにくい
  • PlantUML で「○○業務フロー」を書いたが、そのフローの前段となる「□□業務フロー」が存在するような関係において、これらの PlantUML を「□□業務フロー」→「○○業務フロー」の順に読むべき、といった情報を紹介する資料を作りづらい。
    • 1_全体の流れ.md・2_□□フロー.png・3_○○フロー.png という3ファイルを用意したとして、これら3つの内容を意識しながらメンテしきれるか怪しい。
    • さらにいうと、「この機能に登場するフローはこの2つだけなのか？」という疑問に答えづらい。もしかしたら 4_△△フロー.png が存在していて、誰かがそのファイルだけ消してしまっているかもしれない。あるべき資料が全部揃っているかを確認するために、毎回 git log を確認するだろうか？
  • Markdown は表が書きづらい。
    • Markdown Table は CommonMark の仕様には含まれておらず、方言が多いのでレンダリングも崩れやすい。
    • だからついついリストで全てを書こうとしがちなのだが、やはりリストよりも表形式の方が視認性が優れている場面は多い。
  • それに比べて Excel は、Excel 単体で図を描けるし、Excel ファイルの中に画像ファイルを同梱できるし、表、テキストをどのようにでも配置できる。
    • フロー図なら 1_全体フロー シートからリンクを使って 2_□□フロー・3_○○フロー などに遷移させたりできる。ファイルが分割されないので、全量が間違いなく把握しやすい。
    • フロー図の隣に説明書きや種別表を書いたりしやすい。「別のファイルを見なかったがために、知り損ねた情報」がなくなる。
• ソースファイルと成果物ファイルが別れる。ビルドの手間、ビルド環境の差異による表示崩れ、成果物ファイルの更新忘れなどが起こりうる。
  • 例えば PlantUML。テキストファイルだけ共有しても、ツールがインストールできず表示できない人がいるから、ということで PNG ファイルも用意したとする。それも Git にコミットするのか・しないのか？PNG ファイルもコミットすることにしたとして、常にテキストファイルと PNG ファイルの内容が一致しているか？Git の Hook とかでチェックできなくはないが、こんな些細なことに手間が増える。
  • 「なぜか私の環境で図を書き出すと文字化けしました」とか、「VSCode のプレビューでこの Markdown を開くとリストのネスト構造が崩れてます」とかありがち。
  • Excel なら .xlsx ファイル一つで良い。ビルドも要らない。

Excel 仕様書のメリット

Excel 以外のツールを使った仕様書は、それぞれの分野で「Excel より楽になる点がある」というのが、メリット・強みになるだろう。例えば、ER 図そのものにメタ情報が埋め込めるので、そこからテーブル定義を生成できるー、だとか。コレを Excel でやろうとすると、シートのフォーマットをガチガチに守らせた上で、Excel VBA を書いてやらないと実現できない。Excel でも不可能ではないかもしれないが、物凄く手間がかかるところを、とっても楽になりましたー、というワケだ。

そうした他のツールのメリットは、それぞれで語られてるはずなので、今回は特には持ち出さない。それらの優位性自体を否定はしないし、適材適所だと思っている。そういうワケで、次は、脊髄反射的に全否定されている Excel 仕様書のメリットにだけフォーカスしてまとめる。ほとんどがコレまでの内容の裏返しだ。

• 特別なツールのインストールが要らず、オフラインでも見られる
  • Excel、Numbers、LibreOffice あたりが入っていればほぼ互換表示できる (互換表示できずに崩れる場合は、そんな凝った Excel を作る方が悪い)
• 1つのシートに、図・画像・表・文章を混在させ、一覧性・視認性の高いドキュメントが作りやすい
  • シーケンス図を見せながら、横に補足を入れたり、画面キャプチャを盛り込んでみたり、種別の表を配置したりできる

僕は、この2点が何もより重要で、他のツールの利便性がコレを勝ることがないなぁと感じている。

XMind、PlantUML、Markdown、Astah などの執筆系ツール、Redmine、Backlog、Trello などの管理系ツール、Selenium、BrowserStack などのテスト自動化ツール。僕はこれまでこういったツールを使ってきたし、それらが個別に便利なのは分かるのが、試しにそれらを組み合わせて使う代わりに、Excel は一切使わないという運用方針にしてみると、途端にうまく回らなくなるのだ。

• Redmine に課題を追記していくばかりでは全体を見渡せなくなり、バグの影響範囲調査で抜け漏れが発生しがちだ
• PlantUML や Markdown による執筆の問題点は先程述べたとおり。閲覧環境が安定しないので、客先への納品は PDF に書き出すことになるが、結局客先では「Excel でちょうだい」と言われる
• テスト自動化ツールや CI/CD ツールは、未だ「匠の技」が必要な場面が多く、「Jenkins おじさん」が生まれやすい。どんなテストがあってどこまでをカバーしているのか、自動化できず人の手でやらないといけないことは何で、それは具体的にどうやるのか (作業手順書)、といった話になると、Markdown では足りなかったり、逆に執筆の工数がかかったりする

というワケで、僕は Excel 仕様書にまだまだ分があると思うのだ。

論者たちの働く業界が違うんじゃねーの？

ココでふと思ったのだが、Excel を肯定的に見ている人たちと、否定的に見ている人たち、みんな「プログラマ」や「エンジニア」だとは思うのだが、彼らが働く業界がそれぞれ違うのではないのかと思った。

どちらかというと昔ながらな SIer、業務システムを構築するような会社の場合、IT に疎い客を相手にしながら、スキルの低い若手開発者に実装を任せたりする現場が多いだろう。コミュニケーションをとる相手が様々なので、口頭伝達に頼らず、5W1H を欠かさずドキュメント化し、書面で会話することが求められる。ネットが使えないような開発現場も多いので、柔軟にツールがインストールできなかったりする。そうなると、標準でインストールされている Excel くらいしかツールの選択肢がないが、この Excel が必要十分だから重宝されている、という感じだ。納品もあるので、「文書」の体裁が重視される面もあるし、その場その場で必要なブツを作って終わり、というワケにはいかない。

一方、Excel をあまり使わなくて良さそうなのは、自社サービスや Web サービスを開発している、いわゆる Web 系じゃないかと思う。彼らは Slack 等のコミュニケーションツールを使い、「あれってどうでしたっけ？」なんて軽く聞いた感じでコードを書いていき、自動化された CI/CD によってその正しさが証明される。要件は自分たちで決めるし、それを説明する相手が存在しないので、誰にでも分かるドキュメントを書く必要がそもそもない (SIer と比べて極めて少ない)。そういう人たちは「Slack で聞けばいいじゃん」「UML が1つあれば分かるじゃん」という感じでやってきているので、何かの拍子に Excel 仕様書を求められると、求められたとおりに作るのが大変で、否定的になっていくのではないだろうか。

自分と相手が、ふんわりと「同じエンジニア・プログラマ」だと思って会話するから、要る・要らないが水掛け論になりやすいのだ。実際は全然違う仕事をしているのだと思うと、もう少し建設的に話ができると思う。

それにしても Excel ちからが足りねえよどいつもこいつも

さて、SIer の方が Excel を重宝していると思う、と書いたワケだが、自分が見てきた限り、SIer の人間でもまともな Excel 文書を作れている人間は極めて少ない。

Excel をなんとなくしか使えていないのに、自分ではよく出来ていると思っている輩が多すぎる。神経質な人間が見ると、ひと目で「1文字だけフォント違うじゃん」「ココだけ罫線切れてるじゃん」「連番が1つ抜けてるじゃん」などと見つけてしまう。体裁面だけでなく内容についても、「一生懸命いろいろなことを書いてるのに肝心の全体像が分からない」とか、「結局いつ時点の情報なのか明記されていないから役に立たない」といったことが起こりがちだ。

体裁面は、Excel の仕様を知ったうえで、無理なく使えているかが問われる。フレームワークの学習と同じように、Excel の特徴を捉えて使うべきだが、なぜか Excel になるとそういう勉強をしたがらないヤツが増える。コイツらがフォーマットを壊していくから消えてほしいんだよな。

内容面は、例えば Redmine なんかを使うと、5W1H を必須入力フォームにすることで、情報の抜け漏れが機械的に発生しにくくできたりする。しかし Excel は、そうしたフォーマットを作るところから自分でやらないといけないので、論理的思考力、ビジネス文書の作成スキルが問われる。僕はこの2つは座学の研修を受けないと一生身に付けられないと思っている。いくら自分で考えたり、たくさんの資料を作ってみたりしてもそれだけでは足りなくて、座学で研修を受けたかどうか、で断然違いが出てくるのだ。

「ビジネス文書に何が求められるか」「コレを正しく理解してもらうためには、何をどの順に表現したらよいか」といった観点で考えられる人間がフォーマットを作れば、Excel で十分回る。問題なのは、こういう思考が当たり前にできる人間がほとんど存在しないために、そういうフォーマットが作られず、ゴミみたいな資料しか生まれないのが問題なのだ。

「フォーマットなんて自分で作らなくても Redmine なら最初から仕組み化できるぜー！」それは結構なこと。でも、「なんでこの項目を入力してるんだっけ？」ということを意識していない人は、いくら必須入力にしたところで、何も伝わらない文言しか書いていなかったり、デタラメを書いていたりして、組織にとって迷惑なだけだ。ツールを便利に使えるのはいいが、「ツールに使われていないとロクにアウトプットできない」状態になっているヤツも多いと思う。というか大抵は自分が推すツールすらまともに使えず気持ち悪いゴミ資料しか作れてねえんだけど本人はその低品質さに気が付いてなくて一人で悦に入ってるだけなんだわ。バカはどんな道具使ったって無駄なんだよ。

総合的な意味合いで「Excel ちから」を身に着けましょう

メールだって、CC と BCC を使い分けたり、HTML メールを避けて分かりやすく書いたり、といったスキルが求められる。頭語・結語だって、メールで書くのはくだらないと思うかもしれないが、それによって何を相手に表現しようとしているかを理解していれば、必ずしも「拝啓」と書かずとも、敬意を表現したメールが書けるであろう。

仕様書作成も同じ。Excel を使うのであれば、Excel をよく知ったうえで機能を使うのは、当然の前提。どんなツールを使うにせよ、何を書いて、誰にどう思ってもらうか、どんなアクションを取ってもらうか、ということを意識するには、ビジネスライティングのスキルが必要になる。

ついつい「Excel 方眼紙」のような「見た目で分かる欠点」から文句が出がちだが、Excel の機能を知っていれば問題の半分は問題でなくなるし、それ以外は Excel に限らず起こりうる、人間のスキルに起因する問題だ。

それらを総合して、Excel を使う人は「Excel ちから」を身に着けていくべきだ、と考える。

Excel 最強の教科書［完全版］ーーすぐに使えて、一生役立つ「成果を生み出す」超エクセル仕事術【電子書籍】[ 藤井 直弥 ]

楽天Kobo電子書籍ストア

価格 : 1738円