読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ソフトウェア開発におけるグレシャムの法則

日経SYSTEMSの2012年3月号の特集は『開発ドキュメントやってはいけない』で興味深かったのだけど、いきなり「経験則でテーラリングしてはいけない」と書かれていてちょっとのけぞってしまった。経験則でテーラリングしないで、どうやってテーラリングするのだろう。

残念ながら、それほど自信も専門知識もない開発者や顧客やマネジャーは、計画や仕様や標準を一式すべて作成したほうが安全だと考えがちである。ここに至ってある種のグレシャムの法則(「悪貨は良貨を駆逐する」)が働き、最も専門知識に乏しい参加者が先頭に立って、必要な部分だけに絞り込むこともなく、文書一式すべてを作成する方向にプロジェクトを押しやることになる。さらに、この非専門家たちはどんどん溜まっていく文書の山にはほとんど目を通しもせず、それでいてプロジェクトを予測し管理するためのベストプラクティスに従っているのだと考えて安心してしまう。
アジャイルと規律 ?ソフトウエア開発を成功させる2つの鍵のバランス? P54

もしかして:老害

ちなみに冒頭で紹介した日経SYSTEMSの2012年3月号は記事タイトルは「経験則でテーラリングしてはいけない」となっているのだけれども、記事内ではだいたいこんなことを言っていて内容はそれなりに妥当である。

  • 経験則や憶測に基づいて(文書の作成を)省略してはいけない
  • 根拠なくドキュメントの数を減らすのは危険

憶測や勘でドキュメントを省略するのはダメだろうが、経験則まで否定するのはどうかと思う。また、ドキュメント省略の「根拠」というのもハードルは高めだ。(保守開発などは除く)新規開発のプロジェクトで将来起こりうるあらゆる状況を見通すのはとても困難だ。経験則で判断できるのであれば、テーラリングしても良いのではないだろうか。

古くからの習慣を打ち破るのは容易ではない。古い習慣に気づくのはそれに輪をかけて難しい。古い習慣を捨てるための最初の一歩は、自分のやり方は時代遅れだということに気づくことだ。これが最も難しい。同じくらい難しいのは、実際にそれを捨てることだ。メンタルモデルや思考パターンは、長年にわたり多大な代償を払って形成され、磨かれてきたものだ。だから軽々と捨てられない。
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 P36

ただし、現実としては「実際に開発した経験が無い」「技術的な側面については知識も無ければ経験も無い」人も業界にそれなりにいるので頭は痛い。それでいて、コストの制約など大人の事情で成果物を省略したら、あとは運を天にまかせるばかりである。

参考

アジャイルと規律 ?ソフトウエア開発を成功させる2つの鍵のバランス?

アジャイルと規律 ?ソフトウエア開発を成功させる2つの鍵のバランス?

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣