ブログ blog
設計書に Office を使わない（イントロダクション）
はじめに
こんにちは、株式会社キットアライブの関です。突然ですが、みなさんは設計書を作るときにどのようなツールを使っていますか？
それなりの年齢になってしまったので必然的に多くの現場を見てきましたが、ほとんどの現場では Office 製品、特に Excel を利用しているケースが多かった印象です。
Excel 自体は素晴らしいソフトウェアで、多くの人や企業がパソコンを使うきっかけになりました。生産性を向上させることができたという実感を得ることができるソフトウェアで、この意見には賛同してくださる方も多いでしょう。
正しく「表計算ソフト」として利用している限りは何の問題もありませんが、会社であれば大体どのパソコンにも入っていて、意外なほどの表現力（Excel 画家さんもいらっしゃいますよね）を持ち、印刷設定も柔軟であることからいつの時代からか表計算ではない利用方法、特に「Excel 方眼紙」が普及して来た印象があります。
この「Excel 方眼紙」ですが、使い方によっては生産性に深刻な影響があると感じています。
ソフトウェア開発においては、ベンダーやソフトウェアハウスによって呼び方は様々ですが、要件定義書に始まり基本設計書、テスト仕様書等々の設計書や課題一覧等の管理ドキュメントを作成することが多いです。
プログラマーとして従事しているはずなのに、プログラムではなく Excel ばかり使っている現場もありました。
どんな場面で生産性に悪影響が出ているのかを見ていきましょう。
微調整の煩わしさ
良くあるのが「1-1 方式設計」「1-1-1 認証方式について」のように章番号を付けるケースで、途中に追加したり削除したくなったケースが本当に面倒です。途中に追加したいがために以降の章番号を全部変更するなど「一体私の存在は何なのだろうか？」と心を無にするしかない時間が流れます。
章番号の件は Word を使っていればまだ機能でカバーできるのですが、なぜか Word よりも Excel を利用する現場が多いです。
単体の設計書であればまだ数時間の無駄ですが、数百人が参画している巨大プロジェクトで「ヘッダーの様式を変更しました、皆さん残業して全て変更してください」という場合には一体この変更でいくらかかったんだろう？と心配になります。
また、見た目についても HTML のスタイルシートのように全体の設定を一気に変更したり、class 指定のように部品化した指定ができず、統一感を持たせることにとても時間がかかります。
変更管理の難しさ
最近はドキュメントも Git 等で構成管理（バージョン管理、世代管理）することが増えてきました。
NAS 等の共有ドライブで管理していた時代にはファイル名に日付を入れて世代管理をしていて、複数の人が更新した際に変更が抜けてしまったり、上書きされてしまい取り返しがつかなくなるということが無くなったこと自体は良い流れです。
しかし、どうしても差分を見ると言う観点で見るとテキストデータに比べ困難であると言わざるを得ません。
差分を見つけると言う意味だけで言えば、 git diff コマンドで差分を見ることができたり、オープンソースでいくつもツールが存在します。ただ、 Git を使って差分情報を利用する場合における最大の利点は、分散型構成管理のメリットでもある差分単位でのマージができることです。
いくら差分を見つけられても手動でバイナリーファイルを変更するのであれば、手間は大きくかかることに変わりはありません。XML 形式で保存もできますが、わかりやすいとは言えません。
共有の難しさ
Office ファイルは共有ドライブに格納した上で、共有することが可能です。
しかし、共有したファイルはとても動作が遅くなったり、ファイルが壊れるというリスクがいつも隣り合わせでありました。ただし、この問題は Office 365 や Google SpreadSheet 等のクラウド上で共有利用するというスタイルになってからは共有利用がとても素晴らしいものとなってきています。
他にもいろいろな問題が出てくることもありますが、複数人数で Excel 方眼紙を使って設計書を作成していると、面倒なことや本質的ではない作業に追われることになりがちです。
そうだ、Markdownがあるじゃないか！
以上を踏まえてキットアライブでは、一部で設計書を Markdown 形式で作成することにチャレンジしています。手法は次回の記事にて説明いたしますが、 Excel 方眼紙で作成した設計書と同様の見た目を実現できています。
Markdown による記述は生産性が高く、テキストファイルベースであるため Git との親和性も高く、何より技術者にとっては Excel じゃないというだけでやる気に直結し生産性に影響が出てきます。
それでは次回実際にどのようにして Markdown で設計書を作成しているかをご紹介いたしますので、お楽しみに！
この記事を書いた人
嘉屋雄大
嘉屋雄大
株式会社キットアライブ 代表取締役社長
愛する北海道から日本のクラウドビジネスを支えるべく、キットアライブを2016年に設立。Salesforceをメインとしたクラウド上でのシステム開発による業務効率化をご提案する日々を送る。
Share
おすすめ記事
