いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。

ドキュメントなんて書いてるから炎上するんだwww

»

■ドキュメントを読んでも何も分かりません

 サーバ構築案件等の成果物として、必ずと言っていいほどドキュメンントが含まれている。提出用のドキュメントを作成していていつも「これ、もう二度と読まれる事はないだろうな」と思う。実際、過去の納品物のドキュメントを読んでもサッパリ意図が伝わらない。知りたいのは設定値ではなく、意図と経緯だ。

 まず、ドキュメントの質が低いこともあるが、ドキュメントの用途が練られていないように思う。求められるドキュメントが、素人の考えた「ぼくの最強マニュアル」でしかない。作って終わり。作った方も訳が分からない。作れと言われたから作っただけ。双方、何も得るものが無い。

 タイトルにも書いたように、そんなドキュメントを作ってるから炎上するのだと思う。そもそも、ドキュメントは仕事の道具であって目的では無い。お客さんに提出を求められると、提出することが目的になってしまい、本来の意図からかけ離れてしまう。

 残念なことに、大手ほどこの傾向は強い。営業の作る資料も、エンジニアの作るドキュメントも、仕事のできないオッサンのお守りにしか活用できていない。オッサンのお守りの為に作られたドキュメンントなど、エンジニアが読んでためになるとは思えない。

■必要なのはドキュメントではなくデータだ

 散々ドキュメントに関するコラムを連投した後に「ドキュメントなんて書いてるから炎上するんだ」とタイトルを付けたのは理由がある。ドキュメントは、わざわざ手を動かして書くものではなく、集めたデータから自動生成して、書式を整えて一文加えて終わり。このくらいのレベルで作るものだと考えている。

 勘違いしている人が多いと思うが、まずはデータありきだ。データはドキュメントを作るためのネタだ。ネタもなしにドキュメンントが書けるはずがない。ドキュメント以前に、問題の洗い出しすらできないと思う。実際、ネタを揃えずに~書を書いてる現場では、後からいろいろ問題が起きていた。

 進捗表に記入したいがために、前準備をすっ飛ばしてドキュメント作成に取り掛かるから炎上する。そういう人には、「ドキュメントなんて書いてるから炎上するんだ」くらいの表現で言わないと理解できないと思う。まず、データ集めて整理しろ。だからこのタイトルだ。

 データが揃っていれば簡単にドキュメントは作れる。コピペして書式を整えて、一文付け足せばそれで終わりだ。新人に任せて数時間で終わる。そのくらい簡単な作業だと思っている。ネタを揃えずに書くから大変な作業になるのだ。

■ドキュメントじゃなくデータ見て仕事しろ

 仕事で必要なのはドキュメントではない。あくまでデータだ。ドキュメントにしても、裏付けがどれだけあるか、具体的な裏付けとしてのデータが無ければただのメモだ。

 どんなに詳しく、分かりやすく書かれていたとしても、裏付けのデータが無ければドキュメントとしての価値は低い。そもそも、手元のデータが整理できていなければ分かりやすいドキュメントは作れない。誰でも読んで分かりやすいドキュメントは、裏を返せば大した内容が盛り込まれていない。

 全てのデータがドキュメントに網羅されているというなら、前庭としてドキュメントの作り方を間違えている。十、データを集めて集計、項目を絞って、五まで圧縮する。圧縮した五から、伝えたい意図に沿ったものを抽出して二か一にまとめて書式をつける。十の内容を書くために十の情報を集めるようなやり方では、まともなドキュメントは作れないはずだ。

 ドキュメントは最終出力だ。最新出力には成り得ない。抽出したデータを取捨選択しているので、全ての情報は含まれていないはずだ。分かりやすくするために削ぎ落されている。削ぎ落されたデータは、元のデータを見なければ分からない。現状は、実物を見るか人に聞かなければ分からない。

■データを制せ!

 このコラムでドキュメントとは、客に提出する最終出力の事を言っている。一般的には、メモで残したテキストファイルや、Excelで書いたリスト形式のデータ等もドキュメントと呼ばれることもある。ただ、このコラムでは意図的にそれをドキュメントとは言わない。精査すべきデータの一つととらえている。

 まず、私の言ったやり方、多くのデータを精査して絞り込んでドキュメントを書く。それをやってる人がほとんどいない。仕事の効率化と称して、必要な手順をショートカットしているのが普通だ。そんな人たちからすれば「データ?それドキュメントのことだろ」となって、私の言ってる意味が通じないと思う。

 ドキュメントはうんこだ。食べ物を食べて、消化して、最後に残ったカスだ。データという食べ物を食べ、分析という消化作業をして、最後に出たカスがドキュメントだ。食べ物もないのにうんこは出ない。消化できなければ、そこから何も得られない。プロジェクトに必要なのは、分析して得られた結果だ。これが栄養だ。ここまで正常にできていれば、勝手にうんこは出る。

 ドキュメントで炎上する大手SIerとそのお客さんに言いたい。お前らの仕事はうんこだ。最後にブリッと垂れたカスで仕事できると思ってないか?お前らの求めてる成果物って、実はうんこなんだよ。エンジニアにうんこを渡せば仕事してくれると思ってないか?そんなやり方だから、正真正銘、クソドキュメントしか書けないのだ。

 エンジニアなら、データを集めて分析し、そこから信頼できる結論を導きだそう。それがきちんとできているなら、ドキュメントは簡単に書けるはずだ。ドキュメントを書くのがエンジニアの仕事じゃない。結果を得るのがエンジニアの仕事だ。

Comment(5)

コメント

ハリコフ

そうそう、大手ベンダーに仕事を頼むと、使う訳の無い設定値の一覧を成果物として出してるけど、アレ、要らないです。
欲しいのは、そこに辿り着くまでの打合せの内容を整理した資料ですが、こういうのは自社で作った方が良いものが出来るので、私は最初から諦めて自分で作ってます。

それより衝撃的なのは、データ(というか、書くべきもの)を分析しないでドキュメントを書くというお話。データの分析をしないと、ドキュメントの内容どころか項番すら決められないでしょ・・・

やたらと汚いドキュメントを書く人って、それが誰のための、何の為のものなのか考えない人が多い気がします。結局使えないので整理して再作成。

なんだかなぁ。ですよ。

h

ここで言うドキュメントとは具体的に何を示しているのでしょうか?

成果物としてとらえた場合、意図と経緯なんて不可能ではないでしょうか。
5年後10年後に「なんでこの機能はこの設定値の時のみ走らないようにしてるんだ?」なんて思い調べて見るも誰も知らなくて史ねと思う事はありますが、
かといって納品された成果物が段ボール箱で届いても困ります。

意図はともかく経緯をまとめようとすればそれこそ議事録やベランダ会議なんかのメモ帳が成果物に含まれることになるかと思うのですが。
(ベランダ会議の良し悪しはありますが経緯は主にここでの会話が多々あると思います)

天狗の高下駄

サーバ構築でもデータを収集するには、まずお客様とプロジェクトのゴールを合意して(要件定義書)、客先システムポリシーを正しく聞き出して、各種パラメータの策定根拠を明示し(設計書)、その後初めて個々のデータ収集を始めるものだと思ってますので、取り敢えずドキュメント?を使えるレベルで作成するには、必要な情報を確実に聞き出す事とその情報を、判りやすく簡潔に文章化する事が必須なのでは。

それさえできてしまえば、後は確かにデータを収集するだけでドキュメントは作成出来ますので。

因みに私は、納品後のトラブルやリプレースの際、自分が作成した要件定義書や設計書を読み直すことで、パラメーター等の根拠を思い出す手がかりになり、かなり手間を減らすことが出来ました。

あと、プロジェクト実行中の状況変化は、それこそフェーズが変わるタイミング等で、要件定義や設計書を経緯入りでアップデートすれば良いのでは?

天狗の高下駄

肝心な事が抜けてました。

「なぜ」そのパラメーターに成ったのか?
「なぜ」その仕様にしたのか?
「なぜ」そのラックなのか?

プロジェクトで「なぜ」を明確に文字に残すことは、お客様との不要なトラブル(認識違い)を避ける上でも、最低限必要とされることでは?

そしてそれらのデータを集めれば、自然とドキュメントは作成出来るのでは?

あ、コラム本文と似たようなところに着地してる。

Anubis

> ハリコフ さん

> 結局使えないので整理して再作成。
私もこれ多いです。
よくよく考えると、これってドキュメントのリファクタリングなんですよね。
ドキュメントのまとめ方の勉強になります。

> h さん

> ここで言うドキュメントとは具体的に何を示しているのでしょうか?
具体的に"客に提出する最終出力"と書いています。

> 納品された成果物が段ボール箱で届いても困ります。
ここら辺のくだりも、下手クソな人を前提にしてるような気がします。

納品するドキュメントや資料に、"失敗した"とか"ぶっちゃけここがダメだった"
とか書かないですよね?なので、本当の意図や経緯が伝わらない。
何を成果物にするかより、不都合な事実でも正直に伝える事が重要と思う。

>天狗の高下駄 さん
コメントありがとうございます。

読んでいて、いろいろエッセンスが詰まっていると感じました。
いただいたコメントは整形して、個人用のチェック項目として活用させて頂きます。

最近、こういう基礎的なところが総崩れなプロジェクトに多く当たりますもので。

コメントを投稿する