あなたはドキュメント作成は得意ですか？私は若い頃、資料作りが下手で、上司に何度も修正されていました。数多の失敗を繰り返し、ようやくノウハウらしきものが身についた気がするので、ちょっとまとめてみます。
この記事で解説する「ドキュメント」は、システム開発作業で作る以下の資料を指します。
１．相手の意思決定を促す「ドキュメント」
例：・ユーザー企業に提案書を出して契約を締結したい
・基本設計や利用技術で候補案が複数あり、最良案を上司に承認してもらいたい
２．記録化のための「ドキュメント」
例：・議事録など
３．相手の理解を促進・向上する「ドキュメント」
例：・社内の勉強会などで作成する資料
・保守フェーズで使用する設計書類・引継ぎ資料
相手の意思決定を促す「ドキュメント」の作り方
この種類のドキュメントは、予算や開発方針に直接影響を与える書類であり、最も重要な類になります。そして「重要である」ということは、相手は「偉い方、役職の高い方」になります。
更に「偉い方、役職の高い方」ということは、皆さん、とてもお忙しく、また、こういった資料を読むことに慣れています。
資料作成やプレゼンテーションは、相手（読み手・聞き手）のバックグラウンド、知りたいこと、関心があることを意識して用意するのが基本です。
従って、このパターンは、
1.「説明したいこと」の要旨が３秒で直感的に理解できる資料を用意する
2.相手が食いつくテーマが何かを予習した上で臨む
の2点を心掛けましょう。この２つは外せません。
1点目は、横書きなら、人は資料に対して左から右、上から下に目が移るので、左上あたりに要旨を大きな文字で枠で囲って書くとか、Powerpointなら1枚目にまず結論を書くとか、そういうことです。
図や表を使うのもよいと思います。直感的に理解しやすいので。特に議論の要素が多いときは、プロコン表の形式にして、重視するポイントを赤太字で書くとか視覚的に強調することでわかりやすさが増します。
２は経営課題や社内の問題などマネジメント目線で、どのような課題を抱えており、今回の資料の意思決定によりその課題をどのように解消できるのかを意識しましょう、ということです。
記録化のための「ドキュメント」の作り方
システム開発の要件定義・基本設計工程において議事録の作成はとても重要です。
というのは、システム開発で起きるトラブルのうち「要件定義の時と言ってることがちゃうやん！」という要件理解不足や仕様変更に伴う、追加開発や開発のやり直しは、かなりの割合を占めるからです。
仕様変更であれば「追加でお金もらわないとできません！」となり予算・納期に対して攻めの交渉ができる一方、ユーザーが仕様変更と認めない、つまり「開発側のコミュ力不足でしょ」という扱いになると、設計不具合の類と見做され、金はもらえんがやらねばならぬタダ働きになります。まさに天地の差ですね。
そして仕様変更かどうか、言ったか言わないかを証明する手段は、この議事録しかないわけです。
従って議事録は、要件・仕様の内容を誰が読んでも「ハッキリ」認識できるよう、言い訳できないレベルでわかりやすく書くことが大事です。設計書のドラフト版を添付して代替しても構いません。
打ち合わせでの会話を一字一句そのまま書く必要はありません。上記の仕様変更トラブルが起きるのは半年後とかですので、その時には半年前の会話なんて覚えていないので。ユーザーには、「会話をそのままではなく、ポイントとなる要件・仕様を整理して記載させて頂きました」と説明すれば納得頂けるはずです。
それよりも、上記の仕様変更トラブルが起こることを想定して、その時にユーザーと揉めることを覚悟して、議事録には要件・仕様をしっかり書きましょう。
あと、書き方のコツとして、対応することだけを書くのではなく、やらない（開発範囲外）を明記するのもテクニックの一つです。論理的には「やる／やらない」のどちらかしかないので。
相手の理解を促進・向上する「ドキュメント」の作り方
システム開発で作る保守資料は10年使われると思って作りましょう。つまり10年後の新人SEが読んでも理解できるドキュメント、それが目指すべき資料の記載レベルになります。
また、この業界では「SEだったら普通はこれくらい知っているだろ」という共通知識がたくさんあります。基本設計だとUMLとかですね。こういった社外でも通用する技法をできるだけ使って資料を作成しましょう。
更に、複数の開発工程で似たドキュメントをできるだけ重複して作らない工夫もしていきましょう。
例えば、UMLのうち、それぞれのユーザーがどんな業務を行なっているかを視覚的に整理できるユースケース図と、事務フローを時系列で表現できるシーケンス図に関しては、要件定義工程のユーザー向け説明資料としても使えます。また、設計書を表形式のデータ・フローバリエーションの形で作っておけば、テストケースはそれを流用することで作成が楽になります。
まとめ
如何だったでしょうか？「もう知っていた。当たり前！！」と思った方は、かなりコミュ力が高いですね。ドキュメントは、会話での説明能力が高いと効果が倍増するので、よければ会話に関する記事も読んでみて下さい。
