ドキュメントを読んでもらうためには
ソフトウェア開発とは，非常に難しい作業である。しかも，一人で行うことは稀であり，ほとんどの場合は複数人での作業となる。ただでさえ難しい作業なのに，チーム開発というハードルが加わることによって，その難易度は計り知れないものになる。そして，失敗したときのダメージも・・・考えただけで恐ろしい。 そこで，開発作業を滞りなく進めるために，多くの工夫が行われる。標準化であったり，規約の策定であったり，チームの細分化であったり，更にはアジャイルや統一プロセスなどの適用といった何らかの開発プロセスの採用など，あげたらキリがない。これらの工夫は，全て作業の単純化，細分化が目的である。それによって，問題の局所化やその発生自体の把握をしやすくし，各担当者への仕事の配分を均一化することによって，ミスを少なくすることが期待できる。 しかし，いくら工夫をしても，実際の作業者が理解してくれなければ，効果はゼロ。 実際の作業者に伝えて理解してもらうために，ドキュメントを作成し，それをメールで通知することがセオリーだろう。多くのプロジェクトでは，後工程で「作業手順がドキュメント化されていなかったことが問題だ」という失敗理由が語られる。確かにドキュメント化されていないということは，誰かが口にしない限り情報を得ることができないため，大きな失敗の理由として成り立つだろう。 しかし，ドキュメント化を行ったとしても，開発者のモチベーションに関係なく，それが読まれることは稀なのが現実だ。 ドキュメント化について，多くのドキュメント数があると，情報の点在を招くため，効果は低くなる。しかし，ドキュメント数を少なくしたとしても，読まれることが少なく，強制的に読ませることが求められるのは，非常に残念なことである。 Aさん「○○というエラーが出るんですけど・・・」 Bさん「それは手順書通りに行っていないからですよ。手順書読みましたか？」 Aさんの立場になったことも，Bさんの立場になったことも，これを読んでいる方はどちらも経験しているのではないだろうか。 ドキュメント化された情報は，プロジェクトを成功に導くためのメソッドとして最高の情報なはず。これを読まずに開発者自身の知識で開発作業を行ってしまうことは，チーム開発では許されることではない。しかし，強制的に読ませるということは心情的にしたくない。小学校の教師じゃないんだから，「読め」なんて何度も言いたくない。でも，読んでくれない。 じゃあ，どうすればいいか？ 真っ先に思いつくのは，読んでもらう環境を作ることかな。恐怖政治にすれば，解決するかもしれない。例えば，誰が読んで，誰が読んでないかが，他のメンバーに公開されてしまうような仕組みを導入する。これによって，他人の目という「監視機構」が働くようになるため，嫌でも読むようになるだろう。しかし，これは誰にとっても気持ちのいいことではない。 次に思いつくのは，ドキュメント化される情報を伝えることを止めてしまったらどうだろうか。ドキュメント化するということは，ある意味答えを教えるようなものである。でも，その答えを読まないのなら，伝えても意味がない。それよりも，答えを与えないことで，問題に直面したときに開発者たちで自ら解決策を考え出すことを期待する。そして解決策のドキュメント化を開発者自身でやってもらう。コーチングの考え方を適用して，解決策を導くためのサポートをしてあげれば，より効果はあがるだろう。しかし，アメリカなどに比べて，日本では自発的に仕事をこなすモチベーションを持つ開発者は極端に少ない。自発的に行ったとしても，それを報告するだけの自信を持った人間はもっと少なく，あまりこれも期待できない。 強制もダメ，自発的な解決も期待できない。ではどうするか。ドキュメント化される情報を，知らなくても自然に守っているという環境を作ることを目指すのが現在の最適解だろう。守るべきことは少ないほうが良い。そして，考えることも少ないほうが良い。せっかくコンピュータを使って開発をしているんだから，設計書に対してマクロを仕掛けたり，コードの自動生成を積極的に行うことで，自然に規約が守られる環境を作る努力が現在の現場には求められているのではないだろうか。 しかし，完全な自動化は存在しない。どうしても自動生成ツールなどを利用するための手順が現状では必要になってしまうだろう。しかし，その手順をドキュメント化するとしても，それがまた読まれないという状況が発生してしまうと，効果は出ない。あぁ，無限ループになってしまった。。。 結局，一番の解決策は「開発者のモチベーションをあげること」に尽きるのか。いや，「モチベーションを高く保つことができる開発者でチームを構成すること」なのかな。
