顧客の脱Excelは進んでいる
もともと発注書や請求書、伝票や報告書など、ExcelやWordで作られていたものは、どんどんシステム化され、最近ではExcelで作成というのはあまり見なくなりました。
そもそも印刷することが少なくなり、手作りするよりもシステムから入力してそのままデータとして送信したり、PDF化したりするほうが便利で誤りも少なく済むのでシステム化は一気に進んだと思います。
昔から変わらない開発資料の作成方法
私が勤めている会社は、直請けもしていますが、メインは大手SIerからの受託開発です。
そのため、開発に使用するツールや、設計書類のフォーマット、書き方はその受託者の指示するものに従う必要があります。
大手メーカーなので、さぞかし最新のリッチでクールで使いやすいツールや設計書作成を行うかと思いきや、全部Excelです。
WBS、各種仕様書、課題管理表、各種申請書など、すべてExcelで記載されます。
これは数10年前から変わらず、仕様書のレイアウトもほぼ昔のまんまです。
たまーに操作説明書などの長文文書はWordで作られることもあります。
Excelによる仕様書作成の利点と欠点
世間一般的なExcel仕様書の利点と欠点をまとめます
Excel仕様書の利点
-
導入障壁の低さ
Officeソフトは多くの開発環境に標準装備されており、専用ツールを導入する必要がない。閲覧・編集のための環境構築コストが不要。 -
操作の習熟度
誰でも使える。新たな操作方法を学習する必要がなく、すぐに作業に着手できる。 -
レイアウトの自由度
表計算ソフトであるため、パラメータ一覧やDB定義書などの「表形式」の記述に最適である。また、スクリーンショットの貼り付けや図形の描画も簡単であり、視覚的な説明を入れやすい。 -
多機能性
計算式やマクロ（VBA）を利用することで、入力値の自動計算や整合性チェック、テストデータの生成などを仕様書内で行うことが可能である。
Excel仕様書の欠点
-
バージョン管理の困難さ
ファイルがバイナリ形式（または複雑なXML）であるため、Gitなどのバージョン管理システムでテキストベースの差分（Diff）を確認できない。変更箇所の追跡が極めて困難である。 -
属人化と「神エクセル」化
あまりにも自由度が高すぎるために、作成者ごとにフォーマットがバラバラになりやすい。セル結合の多用や、印刷レイアウトのみを意識した記述（いわゆる方眼紙Excel）は、データの検索性や再利用性を低くしている。 -
同時編集の競合
最近ではSharePointでの共有も進んでおり、同時編集もできなくはないが、基本的には複数人による同時編集には不向きである。ファイルのロックや更新の競合が頻発して、その復旧にたびたび時間をかかる。
既存値の変更はまだよいが、途中に行を追加したり削除するとすぐにぶっ壊れる。 -
文書構造の欠如
WordやMarkdownとは異なり、見出しや段落といった文書構造を厳密に持たない。そのため、長文の記述には適さず、目次の自動生成やドキュメント間の相互リンクの管理も手間。 -
パフォーマンス問題
WBSなど特に列数が増えていくと、Excel全体のパフォーマンスが落ちていく。セル値を編集したり、スクロールする度に処理待ちが発生し非常にストレスがたまる。SharePointからWeb版で開くと軽いが、Web版だとマクロが使えなかったり、機能が一部制限されるため、最後は結局Excelアプリで開く必要がある。
自分が実際に困っていること
変更管理が難しい
運用としては修正した個所を色分けして分かるようにしていくんですが、修正に修正を重ねていくと、いつの修正分かもわからず、いろんな色分けになりなにがなんだかわからない資料になっていきます。
開発完了後にそのカラフルな色分けのまま終わると、数年後にシステム改修する際にこの色分けはどういう意味だという議論になり、結局色を元に戻す作業が発生します。
レイアウト調整が面倒
最近は仕様書を印刷して提出ということもほとんどなくなりましたが、Excelは印刷した時に画面で見ているレイアウトと若干違う場合があり、シェイプ内の文字も印刷したら途中で見切れたりして、昔は納品時に何度も印刷しなおしたりする作業がつらかったです。
印刷することはあまりないのですが、仕様書作成時には、改ページ位置や印刷範囲を設定する慣習がまだ残ってます。行を追加したり削除したりすると、改ページ位置がずれるため、そのたびに調整するのが面倒です。
結果として、開発者は仕様検討をし、その資料をまとめるという本来の作業以外にも、Excelの面倒を見る必要があり、無駄な時間を消費しています。
検索性が悪い
開発ではテーブル定義書、UI設計署、SS設計書など、いろんな仕様書を作成しますが、それぞれ別フォルダの別ブックで作成します。下手したらSS設計書自体もそれぞれ別ブックで作成されます。
一つの機能を開発する際に、関連する資料がすべて別ブックになっているため、別フォルダにあるいろんな資料を探して開いて、さらにそのブック内の大量のシートの中から、求める情報を検索する必要があり非常に面倒。
ブックをたくさん開いていくと、Windows上でもどこに行った？？？となり、無駄な整理時間が発生します。
後で直すのが大変
１つ作ったらそれをもとにしてほかの機能仕様書もコピーして作っていくんですが、そこにいろんな共通マクロや関数が組んであると、それを直したいと思ったら、これまで作ったすべての仕様書を同じように修正する必要があります。これがかなり面倒です。
アプリが重い、落ちる
上の欠点でも記載していますが、内容が複雑になると処理が重くなり、落ちやすくなります。
昨今だとテスト仕様書にもバリバリのマクロを組んでくるので、ファイルを開くのも時間がかかるし、ボタンを押したら落ちた！とか
それでどうしたらいいのか
不満は多数あり、誰もが思っていることと思いますが、実際数１０年改善されないままです。
受託元が改善してくれないと、下請けでは何ともできないのです。
Excel仕様書の利点で書いているような便利さがやはりあるので、なかなかこれを補えるようなシステムというものがなく、結局前と同じでいいか。。というのを繰り返していると負います。
直請けPJ、自社製品開発での改善
直請けプロジェクトについては、自身の裁量で使用するツールを選択できます。
この前のプロジェクトでは、課題・バグ管理にBackLogというサービスを使用しました。
こちらはタスク、障害をＷｅｂ上で入力していき、対応状況をメンバーで共有します。
画面イメージも貼り付けることができ、入力データも定型化されており、非常にすっきりです。
また、このシステムはソース管理(Git)機能もあるため、障害内容とGitの更新内容をリンクできます。その生涯に対してどんな修正を行ったのかが分かりやすいです。
ソースコミット、課題追加を行った際には、Teamsなどに通知もできるので、見逃すこともありません。
課題管理表は開発にかかわる人が同時に編集していくもので、時折先述のように同時編集によるブック破損やデグレが頻発しますが、BackLogであればこのような問題は皆無です。
BackLogを使った場合の弊害としては、許可している人しかその内容を参照できないので、外部提出する場合にどうしようとなります。
課題管理表の提出を求められた際には、エクスポート機能で出力し、そのまま提出しています。
課題管理表のレイアウト指示があった場合は、移し替えが必要になるので、それは面倒な部分かと思います。
各種設計書はPowerPointで書いたりもしていますが、DX化とは程遠く、図形編集がしやすいかなというレベルです。
正直設計書はなかなか脱Excel難しいと思ってますが、クールなベンチャー企業様たちは何を使って書いてるんですかね。
WBSはExcelから脱却したいのですが、なかなか良いWBSツールが見つけられておらず、いまだExcelのままです。
テスト仕様書はシステム化して、課題、バグ表とも連携できるとすごく効率化できるなと思っています。
テスト内容の書き方って人によって粒度がばらついたり、書き方も統一できていないので、システム化して作成→仕様書レビュー→実施管理→障害記入→障害対応→ソースコミット が一貫管理できるようにしたいと考えています。
まとめ
書きたい内容がまとまっておらず、文書のみでつらつらと文句を書いてしまいました。見づらくて申し訳ありませんが、その内容に同意いただく開発者の方もいらっしゃると思います。
要は脱Excelできてません。**なんとかしたいです！**という状況です。
顧客にはDX化提案しているのに内部がDX化できていないというのはおかしな話です。
プロジェクト業務の合間で検討しながら、徐々に新しい方式も試していこうと思ってます。
また思い立ったら、もっとわかりやすく再構成するかもしれません。