システム開発における文書化の重要性について

まず、現在実践しているフローは

  1. 営業がクライアントにてヒアリングを行なう
  2. 帰社後、開発サイドへヒアリング内容をおろす
  3. 開発を行なう
  4. クライアントが営業と確認する

なお、すべてにおいて文書はなく口頭で行なっているものとする
言語化すると、すごく頭が痛くなる状態だがこんな状況である。
開発サイドで降りてきた情報はもちろんある程度の管理はしているが
後だしでもれていたものが出てきたりしている



そして、この状況の問題点としては

  1. 情報のまとまった資料がないため、話が堂々巡りする
  2. 記憶を元に情報が構築されるため、相違が出やすく仕様変更を受け入れざるをえなくなる
  3. すべての情報が営業に集中するため、捕獲できないと確認ができずスケジュールが遅延する
  4. 後だしの要求を飲まないといけないため、見積と結果の差異が非常に大きくなる


業務における口頭伝達は、確かに早い手段ではあるが
システム開発においては、決まりきった業務なんてほとんどないため
このような状況を作ると各自の理解力や想像力に頼る結果となり
ミスや繰り返し、手戻りを引き起こす原因となる
ただし、決まりきったことを行なう上でならば口頭伝達がベターかと思うが
そういう状況は運用などでルール化されたもので行なうことになるだろう

理想的なのは

  1. ヒアリング
  2. 開発
  3. 検収

各項目間での合意が文書によってなされる事であり
また、書かれている内容も理解のゆらぎがないものでなければならない



こんな事がまかり通るのは、単に信頼関係が強いからってだけだと思う
ただ、こういう相手を選ぶ仕事の仕方をしていては事業や会社の拡大なんて
夢物語であろう



今回はシステム開発を例にあげたが、企画をするときもほとんど一緒だなこりゃ・・・
企画書のない企画は、単なる夢物語
今度からそういう対応しよう・・・