ドキュメント作成、面倒くさいですよね。 どうにか書かずに済む方法はないかと知恵を絞って来たワタシがたどり着いた「これだけで許される図」について説明します。

読む側（発注者）の気持ち

そもそもの話、読む方も苦痛 なんです。 多ければ多いほど。 読まされる側の人はドキュメントを読んだ上で何らかの判断を求められているのですから。

発注者は大量のドキュメントが欲しいのではなく、希望通りのシステムが役に立つことを期待してるだけなんです。 もっとカジュアルに「OK、あとよろしく～」と言って済むならそうしたいのです。

そうならないのは認識の齟齬がないことを何度も確認する必要があるためです。

• エンジニアを目指す学生さんが面接に臨む際に知っておいた方が良いこと

  システム開発におけるほとんどの作業は、勘違いしてないことを確認するためにあるといっても過言ではありません。

システム概要図＋α

言ってしまえば発注者は自分の希望通りのものが予定通りできればOK、開発者は何を作ればよいのかが明確であればOKのはずです。

この2つを満たす1枚絵はシステムの全体像です。 当たり前と思うなかれ。 1枚の中に双方が求めているゴールをシンプルに詰め込んでかつ、IT素人・玄人どちらも理解できる図を書き上げるのは結構大変です。

この図の中には以下3点が 言葉ではなく絵で 表現されているのが望ましいです。

• システム構成
• データフロー
• 運用フロー

良い例ではないけれど

仕事で作成した図は紹介できないので、過去に自分開発用に検討しかけてた図を紹介します。 アイコン等で伝わるものは極力言葉で書かない、サブシステム間の繋がり（IF）とデータの流れが示されている、というところは見て取れると思います。

ドキュメントとの対応

システム開発に必要なドキュメントとその役割をざっくりと書き出します。 ワタシの言う「システム概要図＋α」は主に3（★）を、ふんわりと2,4（☆）の役割を果たします。

1. 課題・要望（議事録）

   発注者側がシステムを必要としている動機・理由をヒアリングしたもの

2. 要件定義書☆

   課題・要望を整理して、求めているのはこれですね？を明確化したもの

3. 仕様書★

   要件が満たせる機能・データ・運用を書き起こしたもの

4. 設計書☆

   具体的に何をどう作るかを開発者に伝えるもの

5. 評価項目

   期待通りに動くことを確認するためのもの

注意点

信頼関係がないと成立しない

図1枚でドキュメントなし開発を行うためにはお互いの信頼関係が重要です。 顧客はあなたに任せておけば大丈夫、という信頼がなければ仕様書を要求するでしょう。

開発者は何かあってもあなたに相談すれば解決する、という信頼がなければ設計書を要求するでしょう。 また、IFだけ示し合わせておけばサブシステムを任せられるメンバーとチームを組む必要があります。

設計しなくていいわけではない

1枚図を描くためには何を作るかを明確にしておく必要があります。 ドキュメント化しなくても設計は必要です。 提案や見積もりでも同じだ、という話を過去に書いています。

• 提案も見積もりも設計に基づくという話

  同じことが見積もりにも言えます。 見せ方は違えど、何をどう作るかを決めておかないと値段のつけようがありません。 （フェーズごとに粒度の違いはあると思います）

追伸：自動テストは書いた方がいい

自動テストは評価項目を置き換えるだけでなく、現代の設計書の側面もあります。 つまり、自動テストを書くと先の4,5（設計書と評価項目）のドキュメントも不要になります。

効果の割に導入が進んでいない印象が強い自動テスト。 コスト増を嫌って書かせてくれない顧客も多いですが、ワタシは個人開発では必ず書きます。

自動テストを書いた方が結果的に早くて高品質になります。 個人的には自動テストを書いていない会社は、この先10年生き残れないと思います。

謝辞

画像は Pexels 様より使わせていただきました。