設計書とマニュアルに向き合って初めて気づいた「伝える仕事」の正体
うわっ!? ドキュメントって、誰が読むの？
画面を前に、思わずそんな独り言が漏れた。プログラムを書いているときには感じなかった種類の、じわじわとした難しさがそこにあった。
■ プラットフォームを「作る側」に回った瞬間
プラットフォームを理解し、サーバを理解し、構築業務に携わる。
私の役割は、設計からプラットフォームを作っていく仕事だった。設計書を起点に、プログラムを自動生成する。だからこそ、設計書の出来が、そのままシステムの質になる。
フォーマットを決め、何をどう書いてもらうかを定義する。
プログラムが得意な先輩に何度もレビューしてもらいながら、少しずつ形にしていった。
■ 「全部プログラムに落ちるの？」という葛藤
設計書は、どこまで書けばいいのか。
全部が全部、プログラムに落ちるのか。結構、時間をかけて考えた。
経験が豊富とは言えない自分が、設計者の修正を想定し、設計すべきことを考える。よくある問題は「設計漏れ」だ。だからこそ、漏れがないように設計書の項目を一つひとつ決めていった。
■ 本当の難関は、その先にあった
一番てこずったのは、そこからのマニュアル作りだった。
考えたことを文章にすればいい、という話ではない。読む人が分かりやすいように、丁寧に、でも読みやすく。
そもそも、どうやってマニュアルを開くのかすら分からない人もいる。
そして正直に言えば――自分は、あまりマニュアルを読まないタイプだ。
■ 「自分でも読むか？」を問い続ける
そんな自分でも読むには、どうしたらいいのか。
意味のある情報は何か。知りたい情報は、きちんと読み取れるのか。
気づけば、「プログラムを書いている方が楽かもしれない」と思っていた。
こんなにもドキュメントを書くのが下手だったなんて。日本語の奥深さを、思い知らされた。
■ 消せるから、書ける
それでも、パソコンで良かったと思う。
すぐ消せる。何度でも書き直せる。難しさに苦しみながら、少しずつ仕上げていく。
ドキュメントは、単なる説明書ではない。
未来の誰かと仕事をつなぐ、静かなコミュニケーションなのだと、今なら分かる。
設計も、プログラムも、ドキュメントも。
全部つながって、価値になる。
私ならできる！明日から踏み出す
コメント
コメントを投稿