2022-02-14

ドキュメントについて改めて考える

1つのプロダクトに機能の追加、改善等をおこなって行くプロダクト開発であればドキュメントは必要なんだろうと思うが、クライアントワークのプロジェクトだとどうだろう？

普段行っているクライアントワークであったとしてもドキュメントは重要だろうと個人的には強く思っている。
それは bit part がリモートワークメインだからというのにも関係しているかもしれない。

色々と素晴らしい記事を読むことができた。

自分がドキュメントを残すことに注力しているというのも関係しているかもしれない。
が、まだまだ道半ばというかできてない感は満載。

プロジェクトを進めるうえではチームビルディングであったり、タスク管理などのプロジェクト管理といったことももちろん重要だけど、ドキュメントを共有したりテキスト化することが何よりも重要なんじゃないかと思っている。

ドキュメントはリモートワークじゃなくても有意義だし、リモートワークの場合はないと成り立たない。
見える化という感じか。それはそれでまた別の時にでも。

クライアント側としては要求、要件をテキストにしておく必要があると思う。
提案前とかにRFP用意するような感じのことは常にやる感じで。。。
後々もめたときにどういう要件だったから、とか要件定義書が、、、という話はあるが。

要件定義書は確かに重要なんだけど、後々のアップデートがし辛い印象があるからもう少し分割したドキュメントにして共有・更新できる作りの方がいいのではないかという気がするが、それはまた別の話。

開発して作られた物が正しいのか正しくないのか。
元々の要件は？と振り返る時に記憶頼りではよろしくないし。
そもそもテキストにまとめられない、まとめられていないというのは整理ができていない、という裏返しなのではないかと思う。

制作側としてはクライアント側から受け取った要件・仕様を整理したうえで、どのように実装する・したのかを簡潔にわかりやすくまとめておく必要があると思う。
設計だけではなく要件・仕様が整理されているか？を確認もできるし、整理できていないところについてはヒアリングをしながら双方でアップデートしていけば良い。

細かい実装については最後はコードを読めということにはなるが。。。
コードで表せないような所はマニュアル的なものを作成して補完する事にはなるかもしれないし、マニュアルほど作り込まないにしても、機能がどのように実装されているのか、どのような運用想定などを書いておくだけでも実装の把握には繫がる。

ヒアリング、仕様整理、設計、実装を全て1人で行い、属人性など気にしないチームであればドキュメントはなくてもいいのかもしれないが、職域に限らず2人以上で動いているチームであれば誰かが考え、決めたと言うことが確実に発生する訳なので、それをドキュメントとして残しておくことで、理解の共有も深まるし、人が増えたときに毎回説明する必要も無くなる。

クライアント側と制作側みたいな関係がある時点で、全体としてステークホルダーは2人以上になるわけだから、なかなかドキュメント無しというのも考えづらい。
伝えました、聞きました、というのが聞かれるプロジェクトはなぁなぁになってるのに、何かあった時にはドキュメントが要求される謎な文化がある気がする。

打ち合わせの議事録なんかも決定事項じゃないにしても言った言わない問題になりがちなのでとりあえず残す文化は必要では無いかと思う。

議事録も参加者が1つのドキュメントに書いてアップデートして共有して、確認して完了くらいの物でいいだろうし。
まぁ、やってみるとそれはそれでどう書いたらいいかが難しい所はあるんだけど。。。
形式とかよりも内容がちゃんと書かれていることが重要であって、、
定例かどうかに限らず打ち合わせが多いプロジェクトなら優先的に議事録担当を置くための予算を確保したいと思うくらいではある。
打ち合わせで話した事がベースであり、ドキュメントのスタートでもあるだろうし

もちろん、ドキュメントがあると説明は全く不要か？というとそういうことでは無い。
ドキュメントを書いた人のその時の案件理解力と、新たに入った人では案件に対する前提理解が全然違うレベルではあるし。
スキルも全く同じということはないだろうし、書かれたドキュメントをどう理解するかは難しいところがある。

都度テキストチャットやビデオ会話、音声で補足をしたりするわけだが、それで行われたことを元にドキュメントをアップデートすることで理解されやすいドキュメントになっていくと思う。

共有されているドキュメントであれば後々検索して解決につなげることはできるが、オンラインでの会話・ビデオチャットみたいなものはそこに参加した人のみしか利益を享受できない閉じた物になりがち。
聞いた人がまた別な人に伝えることはできるが、それ以上の効果は見込めない。

ドキュメントは誰が書くべきか？という話であれば、自分が関係する所ではやはりクライアントとコミュニケーションをとるようなディレクターが先陣を切って書いていく必要があると思う。

基本的な案件情報やら環境情報。
書いてあるのに質問が来るというのは情報の置き場所が正しくないか、質問者が調べてもいないのどちらかであることが多いだろうし。
基本的すぎるから書いていないというのは、ドキュメントも含めた環境整備ができていないと言うことになるかと思う。

ディレクターが書くとはいえ、プロジェクトはディレクターだけでは回らないので、実装についての設計はエンジニアが書くだろうし。
プロジェクトに関することは、質問した人がドキュメントを更新したり、知ったことをアップデートしていくことでドキュメントが古くなることもなくなるし、多くの人が理解しやすいものになっていく。

それができるかどうかはルールとして定めることもできるだろうけど、結局は文化だったり、プロジェクト・進め方に対する個々人の意識なんだろうな、という気もする。

ドキュメント書くことが仕事ではないが仕事の一部と理解できるかどうか。
コードを読めば解決するとはいえ全員のスキルが同等でコードを読んで理解できるのか、というところもあるかもしれない。

ドキュメントは書いて更新してアップデートしていくことが必要になるわけだけど、それを進めるために、自分自身もアップデートしていかないといけないな。