ドキュメント風林火山
今回は上記を読んで、なんとなくパクっ……もといインスパイアした内容となります。
今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるようなマネジメントができるエンジニアとか最先端の技術に精通しているエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもありませんでした。
ではどういうエンジニアが、ということの答えの一つとして、技術力云々ではなく、ドキュメンテーション能力が大事だと考えています。
そこで、開発におけるドキュメントの要素についてまとめたものが次の表です。
| 分類 | 能力 |
| 風のドキュメント化 | 迅速な文章化によってチームを加速させる。 風のドキュメント化が発生しない開発チームでは、議事録やメモが残りづらく、そもそも「ドキュメントを書く」という文化が発生しない。 |
| 林のドキュメント化 | 突発的なトラブルが発生しても冷静に対処し、原因と対処の文書化、及びそれをもとに作業を標準化することができる。 その結果、チームに乱れぬペースを提供する。 林のドキュメント化が発生しない開発チームは同じようなトラブルを永遠と繰り返し、人の入れ替わりにも弱い。 トラブル時や引き継ぎ時に何をすべきかの正確な判断を行えず、混乱に陥りやすい。 |
| 火のドキュメント化 | 焚書。 運用を進めていく中で不要になった情報を削除したり、仕様変更に合わせてドキュメントを更新していくことによりチームやその成果物の競争力を高める。 火のドキュメント化が発生しない開発チームは古くなった情報や不要な情報に惑わされてチームの進捗スピードが鈍くなる。 |
| 山のドキュメント化 | 厳密なチェックと堅牢なドキュメント管理によって成果物の安定性を高める。 必要なときに必要な情報にすぐアクセスできる環境を整備する。 山のドキュメント化が発生しない開発チームは曖昧な仕様による認識のズレが常に発生し、チームメンバーのナレッジも弱くなる。 |
「風」からドキュメント化という文化が発生し、「林」で育て、「火」で質を上げていき、「山」で定着させる、といった流れになるでしょうか。
これらすべての要素が揃わないと質の高いドキュメントは生まれません。
プログラマー風林火山と違ってドキュメント風林火山のほうはあまり属人的な要素はないので、「各個人がどの要素が得意か？」というよりかは「ドキュメント化にはこういった要素があります」という内容になってしまいました。
あと、書いてて思いましたが「ドキュメンター」のような文章化を行う人を呼称する言葉ってないんですね。
最初に書いたとおり、ドキュメントはある意味技術力より重要だと思うので、それ相応の呼び名があっても良いと思います。
もう一つ、ドキュメントと同じくとても重要なのにあまり日の目を見ない能力として「バグ取り」があります。
バグの事前発見とその修正はシステムの安定化にとってとても大切なことだと考えています。
バグを潰すのが得意な人にもそれ相応の呼び名があって良いと思います。
ちなみに私はバグを見つけて修正する人を「バグシューター」という呼称で呼ぶことを提案しています。