たれみみの備忘録

たれみみの備忘録です。仕事と酒がメインになりそう。

【その1】ドキュメントの意味・意義

お仕事 思い出

今から 4 年以上前に MBO に書いてしまった、新人ちゃん向けのメルマガが出てきた。

正直、現在もこの風潮は変わっていない感じがする。
お客さんにもよるけどね。少なくとも官公庁案件や、「一回セキュリティでやらかしちゃった」お客さんの案件は、ドキュメントガッツリ文化な印象が未だにあるなぁ。

あ、思い出した。
とあるプロジェクトのセキュリティコンサル案件（システム開発中のプロジェクトに対しセキュリティ観点から ちゃちゃ入れ アセスメントするというお仕事） をやってた際、「（システムの）要件定義書はどこにありますか？」と聞いたら、開発ベンダーが「全部 Wiki に載っています！（ドヤァ」と言ってきた。
んで、その Wiki の中身を見ると、要件が不明瞭で方式や設計に近いことが書かれていた。 その開発ベンダーのプロジェクトがアジャイル開発手法を採用してたわ。
「あぁ、このベンダーのプロジェクト、絶対ポシャるわー（棒」と思ったなー。結局どうなったのかは知らんけど。


※以下、当時の文章。
※この時の会社はウォーターフォール開発主流だったから、なおさら以下のように書いた記憶がある。
※決してアジャイル開発手法が嫌いというわけではない。


みなさまはドキュメントを書くのが好きですか？ この業界、「好き」と答える人はそうそういないと思います。

昨今では一部のアジャイル開発に見られる「できるだけドキュメントは書かない」（※1）
というやり方もあり、ドキュメントよりかは動くモノを重視する傾向も見受けられたりします。

※1：アジャイル開発のすべてがドキュメント軽視ではありません。あくまでも、アジャイル開発の 1 つの方法です。

では、なぜドキュメントを書かないといけないのか？
そもそも、ドキュメントって何を指すのか？

上記について簡単に解説します。

あくまでも私の主観ですが・・・結論から言うと、SIer をやっている限り、ドキュメントは必要だと考えています。
特に大きな案件（公共系、金融系）は監査対策のための証跡を残す必要があるため、電子媒体、紙媒体問わずドキュメントが求められます。
また、他の案件でも「双方の合意をとったドキュメント」があれば、後のトラブルを防ぐことができます。

ドキュメントとは

ドキュメント種類 概要 例
設計書（仕様書） システムの仕様を定義するための文書群。各工程に応じて仕様を記載する。 基本設計書、結合テスト仕様書
計画書 テストや移行など、ある作業についてどのように実施するかの計画を記載する。内部的なものだと、事業計画や要員計画も対象となる。 テスト計画書、移行計画書、要員計画
提案書 顧客に対する新規開発の提案や、既存システムの問題点等を解消するための提案依頼事項を明記する。 提案書、RFP（提案依頼書）
報告書 相手（顧客、上司等）に対し事象を説明するためのドキュメント。記載方法は報告書によって様々。 テスト結果報告書、障害報告書
マニュアル 利用方法、操作方法を記載する。 ユーザーマニュアル
その他 上記以外に、何かのいきさつについて記録する。 議事録、障害管理表 、課題管理表


ドキュメントの意義

  • 監査対策用の証跡
    特に大きな案件（公共系、金融系）は監査対策のための証跡を残さなくてはならないため、電子媒体、紙媒体問わず求められます。
    納品時の成果物一覧にも、もれなく大量のドキュメント群が記載されることが多いです。

  • トラブルの抑止
    「双方の合意を取ったドキュメント」があれば、後のトラブルを防ぐことができます。
    ウチ（当時勤めてた会社）の開発手法はウォーターフォールが主流であるため、工程ごとに顧客承認を得ることで、その工程で作成した成果物が「双方の合意を取ったドキュメント」となり得ます。
    （言った、言わないの空中戦が一番しんどいです。。。）
    裁判で敗ける事例 もあったりします。

  • 内部の記録
    過去事例を残しておくことは、会社にとっても財産となります。
    （「参考となるドキュメントあるかな？」って探したことはないですか？）
    引継ぎの際にも情報を視覚的に捉えられるため、キャッチアップもスムーズになるはずです。
    保守案件とかだとドキュメントが形骸化していることが多いため、なった試しがありませんが。。。

    アジャイル開発についての補足　※私見です！

    アジャイル開発手法がダメだ！と言っているわけではありません。
    納品物の観点からして、アジャイル開発だからといって、ドキュメントを書かないことはあり得ないと思います。

    【参考：アジャイル開発者の習慣－acts_as_agile　第4回　ドキュメントを大切にする】

    ただし、アジャイル開発手法は以下理由によって 「日本では」 なかなかうまくいかないと思います。

    ＜「日本では」アジャイル開発手法がうまくいかない理由＞

  • 日本の契約習慣にそぐわない
    システム完成までの予算を年単位で一括して取る企業がほとんどである、かつ、検収は工程ごとである場合がほとんどであるため、顧客担当者にとってウォーターフォールの方が可視化＆説明がしやすい利点があります。

  • 都度顧客レビューが発生するため、顧客側にも相応の体力が求められる
    顧客側にその覚悟がない場合が多いです。また、小さなスパンで開発を回すため、顧客側も素早い決断ができないと難しいです。
    ベンダーにすべて丸投げでオッケー！って考えている顧客だと絶対無理ですね。

    結論

    ドキュメントは、会社、ひいては、自分の身を守るためにも必要です！