最近とある人とかわした会話についての考察。ソフトウェア開発のベストプラクティスを組織の内側に求めても効果的ではない、というのが個人的な見解。むしろ害になることもあるのではないかと思っている。
以前に書いたこの記事も関連。
「ソフトウェア開発」とベストプラクティス
Wikipediaで「ベストプラクティス」を引くと、こうある。
ある結果を得るのに最も効率のよい技法、手法、プロセス、活動などのこと。最善慣行、最良慣行と訳されることもある。また、仕事を行うために最も効率のよい技法、手法などがあるという考え方をいう。すなわち、適切なプロセスを確立し、チェックと検証を行えば、問題の発生や予期しない複雑さを低減させて、望ましい結果が得られると考える。ベストプラクティスは、多くの人々によって反復され、最も効率的で最も効果的であることが時間をかけて証明されてきた。
ベストプラクティス - Wikipedia
プロジェクトマネジメントの視点や工学的観点でのベストプラクティスは「業界としては」確かにあると思う。まさにPMBOKやSWEBOKなどがそれにあたるのだけれども、読んだ人にはおわかりの通り、非常に抽象化された知識体系である。便利だけれども抽象度が高いので、活用するには難易度も高い(しっかりと勉強する必要がある)。
というわけでもっと中級者～初心者向けに「ガイドライン」であるとか「マニュアル」を作ろうとしがちなのだけれども、実際にこれらが効果を上げるかは疑問である。
そもそもソフトウェア開発プロジェクトは個別性が高い。
のだから、一般化するのはそもそも難しいはずだ。
「ある限られた顧客だけに提供」する「特定の枯れた(イノベーションのかからない)技術」だけを「プラクティスを提供できるほど多数」提供する組織であったら、組織内のベストプラクティスを収集することに意義があるかもしれない。しかし、多様な顧客に多様な形態でソフトウェア開発サービスを提供している組織であれば、内部のベストプラクティスの収集とマニュアル化は大きな効果を出せないだろうと思っている。
(ただし、情報を共有すること自体は意味がある。それをルール化するのが大きなムダなのだ)
むしろ、害のほうが大きいかもしれない。
ルールは達人の能力を阻害して組織のパフォーマンスを下げる
苦労して(不適切な)ルール等を作ってしまうと、組織のパフォーマンスは下がっていく。
しかしそれよりひどいのは、ドレイファスモデルを誤解して達人から専門知識を奪い取ってしまうことです。達人を脱線させ、達人の能力を削ぎ落としてしまうのは簡単です。達人にルール遵守を強制すればよいのです。ドレイファスの研究においても、これが実証されています。まず、航空会社のベテランパイロットに自らの知識に基づく「ベストプラクティス」を初心者向けのルールにするよう依頼しました。ベテランたちはルールにまとめ上げることに成功し、初心者はそのルールに基づいて自分たちのパフォーマンスを改善することができました。
ところがこの研究では、達人パイロットをも自らが作ったルールに従わせてみたのです。その結果どうなったかというと達人たちのパフォーマンスは著しく低下してしまったのです。
リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法 1章 初心者から達人への道
ルールは無駄を生み出す
ルール作成者の意図は「このルールをプロジェクトにあわせて取捨選択して利用する」だったとしても、自信や知識の無い管理者が取捨選択せずに全て提供して、壮大な無駄タスクだらけのプロジェクトにしてしまう、ということもある。
残念ながら、それほど自信も専門知識もない開発者や顧客やマネージャは、計画や仕様や標準を一式すべて作成しておいた方が安全だと考えがちである。ここに至ってある種のグレシャムの法則（「悪貨は良貨を駆逐する」）が働き、最も専門知識に乏しい参加者が先頭に立って、必要な部分だけに絞り込むこともなく、文書一式すべてを作成する方向にプロジェクトを押しやることになる。
アジャイルと規律
というわけで、私としては
- ソフトウェア開発のベストプラクティスを組織の内側に求めて
- それを標準化する
ような活動には大反対なのである。それよりきちんとした技術書などを精読したほうがよっぽど効果的だ。
