ドキュメントの負債化とどう戦うか

結論は多分なく、「いかがでしたかブログ」チックになってるので結論が知りたい方は、そっ閉じ推奨。

ソフトウェアは完成した瞬間にはすでに負債となっている。
開発初期と開発後期では業務知識に差があるから。(後一応プログラミング能力も)
その理解の差がソースコードに反映されているため、常に負債になっている。なので、最新の知識を持ってリファクタリングしていこうというのが、ソフトウェアの負債化に対する一つの回答だと思っている。(まぁ、利益に繋がらないものはなかなかできないが)

では、ドキュメントはどうだろうか。
答えはいまだに見つからないが、途中経過をセーブするつもりでこの後を書いていく。

まず、ドキュメントはいつの時点から負債化するのか。
ごくごく普通に開発が終わった場合は、追加開発時に起こりやすい。炎上した場合は、納品の時にはすでに……だったり。
「追加開発時に微妙に修正が漏れている」が観測範囲では多い。最近では、初期開発終了時にすでに手遅れパターンもあったが。

それがたとえ小さな仕様漏れでも後続の開発者からの信用度は底辺まで落ちる。どれが正しくてどれが古いのかが判断がつかない、つきにくくなるから。そうなると、さらに負債化する。修正する意味がなくなっていく。でも、追加開発時の仕様は書かないといけない。不毛。ふもう。

なので、一時は「設計書なんて不要。ソースコードがあれば問題ない派」に属していた。結局のところ、現状動いているソースが一番正しいのだから、無駄に修正されない設計書を作成する意味も修正する意味もないじゃないかと、見えない誰かに怒っていた。

でも、かなり細かい業務知識が必要なプロジェクトに入って考えが変わった。

そのシステムは大炎上の末にリリースされたもので、ソースコードもまさに「動けばいい」状態、そんな状態だからドキュメントも内容が古かったり、どこにあるか分からなかったりで仕様理解にとにかく時間がかかった。

この時になって初めて「今まで恵まれていたこと」に気付いた。変わった業務でもなければ、まだ理解できるソースコードで書かれ、一応ドキュメントは1箇所に固まっている。そのありがたさに気付いた時に、目の前のシステムに対して今の自分にできることはなんだろうかと思った。

何はともあれまずは、ドキュメントの整理。
必要なもの、不要なもの、追加でいるものを洗い出して～って普通のことをやらないといけないんじゃないかと思う。
近道はないんだろう。
そもそも一番の近道はその都度変更をきちんとすることなんだけど！

ちなみに、これをやろうと思い立って半年ほど。
これを書いてる時点では炎上中でさらなるクソを生み出し中。
ああもう、いやだ。

他にできることはあるだろうか。

ドキュメント作成のルールの作成？
フォルダ構成の見直し？(これはやった)

やってみて効果があったなぁと思ったのは、「はじめに」っていうフォルダに用語集やシステムの流れ、プロジェクトのルール、やることリストを入れておいて新しく入った人にはそれに一通り目を通してもらうってやつ。

これなら口頭で1から説明しなくていいし、概要はふんわり伝わるのでちょっとは入りやすいみたい。
とはいえ、伝えきれていないところはあって要改善なんだけど。
そもそも、1から作った人間が作った資料じゃないからね。
作った人間が理解していないことは資料にも反映されないし、理解しても反映する時間が取れないので、そのあたりがまだまだ口頭伝達になってる。

前担当者がそのあたり考慮してないから立ち上がりは本当に苦労した。
だから、次に関わる人にはその苦労せんでいいようにと思って、作ってみたがなかなか好評のようでよかった。

会社には感謝してほしいもんだ。
ある程度目途がついたら、今度は社内で啓蒙活動か。
面倒だから誰かやって……(´・ω・`)