インフラの環境構築を行ったときに、はい、環境です、と接続情報だけ顧客に提供したところで、そのまま受け取ってくれることはない。
ドキュメントはないんですか？。
何を作ったかを示すドキュメントとセットで初めて、プロにお金を払って仕事をしてもらった気持ちになる。今でも、ドキュメントを残せ、ドキュメントがないと今どうなっているかがわからなくなる、常に更新して最新にしよう、そんな掛け声は健在である。
このドキュメント、年々複雑さが増していると思う。というのも、IT関連のソフトウェアにしろクラウドにしろ、機能は増えるばかりだからだ。かつ、設定自体は年々洗練されており、デフォルト値で動くことも多い。たくさんの設定項目があるが、設定するのはほんの一部分である。
ドキュメントに何を残すべきか。設定値全てをドキュメントに書き込もうものなら莫大な量になる。一方で変更したものは少ししかない。このギャップが激しくなっている。
設定変更したものだけドキュメント化する。これも一案だが、その場合「ノウハウそのもの」になることもある。膨大な中でここを設定するといいよ、ということ自体は流出したくないので、なんとなく仕事をした感を出すため、設定を全部洗い顧客に提供する、ということになると思う。
そもそも、「これだけしか変更していないのに、こんなに作業費かかるんですかあ？」みたいな質問も防止できる。作業プロセスは明かさず結果を提供する。それがこの仕事の秘訣ではある。
ただ・・、このドキュメントづくり、結構不毛な作業でもある。デフォルト値の正当性を毎回の構築作業で洗って、一つ一つ検証していたら、まるで自分たちの構築検証ではなく、ソフトウェアやクラウドサービスそのものの検証をしているみたいになる。標準機能自体はベンダーが保守期間、保証しているというのが建前なのだから、全てを疑ってかかる意味はない。それこそ、不具合は保守で対応してもらえ、である。正常に動くことを前提として、テストを行うのが定石だ。
たまに、勘違いした顧客やプロジェクトマネージャーが、全部の機能を網羅的に洗いなさい、と、標準機能すらテスト項目に加えてしまい、テスト項目が膨大になりつつ「そんな機能使わないでしょ」みたいな感想を持ちながらテスターがテストを行うものの時間が足りず、土日祝、いや夜間も人が無尽蔵に駆り出されて、壮大なテストが行われる現場を見たことがある。それこそ「総点検」のように。
ドキュメントをどんな形にしたら最も、顧客も自分たちもWIN-WINになれるのか。一番いいのは、製品側でドキュメントが自動生成されるようになること。それができたら夢のようだよね。リリース前に、ドキュメントを自動生成してくれて、それで終わり。
うーん、それこそAIが手伝ってくれないかな。ドキュメントをめぐる無駄な、そしてかなりの工数が、人に割かれている。９割はおそらく誰も読まないドキュメントに。
もっと正直にいえば、ドキュメントを作るために作業しているみたいな状態になっていると言っても過言ではない。製品ベンダーも、構築時のドキュメント生成なんて知らんよ、というかもしれないけど、欲しいな。困ってるんだもん。
