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

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

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

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

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

目次

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

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

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

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

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

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

Excel 仕様書のメリット

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

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

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

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

というワケで、僕は 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 ちから」を身に着けていくべきだ、と考える。