何を大事にしないといけないのか、チームで価値の共有がなければ思うようなドキュメントは出てこない

一人であっても、何かを作るときにこれから作るものの出来上がりのイメージは持つものです。

料理で言えば、見た目なのか、味付けなのか。勿論、それが初めてのトライならそれすらイメージを持つことはできないでしょうから、料理本などのお手本に写真があったらそれをイメージして作るでしょう。

たとえばスコーンを作るときに、狼の歯のようなギザギザに割れるように、なんて書いてあるものです。でも、狼なんて見たことないです。絵本の中か狼と香辛料で、くらいなのものです。

何かモノを作ろうとするとき、「(こんな感じに作りたい。)」と思って作らないと、作ったそれが希望したものなのかどうかなんてわかりません。その作ったもの、その形や味のスコーンでいいのかどうか。なんだかわからないけれど、作ってみてそれでいいなんてそんないい加減なもの材料や掛けた手間暇のコストが見合うか、って。

システムエンジニアが、たとえばドキュメントを作るときも何等かアウトプットのイメージを持って作らないとそれで十分なのかどうか判別つきません。それが顧客に納めるものなら、それこそ別の問題を孕むことになってしまいます。

一人でドキュメントを作るにしたって、そのドキュメントの目的が単なる作業の順序を間違えないことを目的としたものと、検討した仕様を書く目的ならそのドキュメントに記載する様式も内容も変わってくるし、そのドキュメントのインプットとの関係や抜け漏れの関係をどこまで押さえるかを決めておかなければ各ページごとに少しずつずれてしまうでしょう。

そのドキュメント作りが複数のチームで、なら尚更です。そのドキュメントを作る目的や出来上がったドキュメントが持つ価値を作る前にチームのメンバに伝えないと「(こう作ってほしい！)」と依頼する側の気持ちなんてさっぱり伝えていないのですから、受け止められるはずがないのです。

それを伝えない限り、欲しいドキュメントは得られません。

テストの手順なら慣れた人がやる前提とそれとも忙しくて誰が対応できるかわからないという前提では手順の記載レベルが変わってきます。後者なら、手間であっても、それを実施する場所で実施者がその手順を読んで悩むような記載では困ります。

それをしないで、つまり、何を目的にして、どのような価値観で、どのような前提で、というドキュメントに求める価値観を共有しないで作った手順ややり取りされているのを目の前にしてしまったらどうすればいいか。それは一つしかないのです。

「忙しいところ申し訳ないけれど、ちょっと集まってほしい。」
「このテストの手順を実施するのは誰を想定して作ったのか教えてください。」
「設計した人を前提にしています。」
「その設計した人は誰だっけ。」
「Aさんです。」
「Aさんが必ずそのテストをやれるように調整しているの。」
「いえ、していません。」
「では、行けない場合、誰が出来るの。」
「わかりません。」
「それではあなたが行くかもしれないですね。この手順で迷わずやりきれますか。」
「ちょっと躓くかもしれません。」
「この手順を作って欲しいとBさんからお願いされていたと思いますが、そのときにお互いに実施者の前提を共有しておいた方がよかったですね。それでは、今からそれを共有しましょう。」
「ワタシはその手順をメンバ誰がやっても実施できるように作ってほしいと思っています。」
「幸い、メンバはその領域のスキルを持っているので画面キャプチャまではいらないでしょう。やって欲しいことを具体的に表記することに変更するだけで十分だと思いますがどうですか。」
「それで十分やれるでしょう。みなさんどうですか。」
：

こうした意識合わせは、何事も始めるときにやっておきたいものです。ただ、それを初めて作るようなドキュメントであれば、ちょっとだけ作ってイメージアップするやり方を取るしかないかもしれません。

それでも全部出来上がってしまってからダメ出しをするより何倍もましです。