ソフトウェア開発は自己目的化しやすい

ソフトウェア開発は何故失敗しやすいのか？
その一つの理由として、ソフトウェア開発は自己目的化しやすいことがあるのではないかと思ったりする。
ラフなメモ書き。

【1】ITシステムの開発方法として、Enterprise Architecture(EA)という手法がある。
以前、経産省が手法をまとめて推進したために、EAブームがあったが、今は殆ど見る目もない。

Enterprise Architectureの悲劇: プログラマの思索

EAの目的は素晴らしい。
ITシステムは、個別のプロセスの効率化ではなく、ゴールを見据えてプロセスを全体最適化すべきだ、と謳うのは上手い。
BPRのように、既存の業務プロセスを抜本的に見直して再構築する考え方とマッチする。

経産省はEAにおける必要な成果物もドキュメント作成手順も統一化し、公開した。
しかもPDCAサイクルで回すというEAのプロセスまで語っている。

しかし、EAの結果は惨憺たる結果だ。
EAと直接関係ないかもしれないが、日本の官公庁のITシステムで成功した事例はほとんど聞かないように思う。
目立つのは、ITシステム開発プロジェクトの失敗事例ばかりだ。

ASCII.jp：情報社会の新たな課題～消えた年金のシステム問題～

特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態 － Publickey

官公庁のITシステム開発は金額が途方もなく大きく、工数も莫大にかかるぐらい、複雑怪奇なシステムだ。
EAを標準にして開発プロセスを定めたとしたら、EAのサイクルであるPDCAサイクルがうまく回るわけではない。
EAには実際の具体的な改善サイクルのノウハウは書かれておらず、現場任せだ。

また、EAの成果物を作るだけでも途方もなく多くのドキュメントが必要だ。
ドキュメントを作るだけで精一杯になりがち。
だから、計画を作って実施して評価の報告を作って終わりになりがち。

更にまずいのは、ドキュメントを作れば仕様が確定するので、予算が取れることだ。
すると、EAとは単なるドキュメント生産活動になってしまい、保守されないドキュメントが山のように作られる。
時代に合わせて、現場に合わせて、システムをどんどん改善しないといけないのに、ドキュメントの整合性を取りながら保守するだけでも大変で、肝心のシステムに反映されない時が多い。

EAはそれ自身が自己目的化してしまい、肝心のITシステムの全体最適化には有効でないように思える。

【2】EAの失敗事例は、CMMIやERPのような失敗事例を想起させる。
CMMIはソフトウェア開発プロセスを標準化し、プロセスをレベル分けすることで、組織の開発能力を評価して改善させようとした。
ERPは、業界のベストプラクティスを集めて標準化したプロセスをパッケージ製品として提供し、既存の業務プロセスを抜本的に改革することを目指した。
しかし、CMMIもERPも、現場の担当者レベルでは、ドキュメント作成活動に自己目的化しがちだ。
現場で活動する人達が実際に作業している内容と、高邁な目的の間にギャップが大きすぎるのだ。

CMMIもERPもプロセスを標準化しようとする。
その最大の欠点は、フィードバックプロセスを重視していないことではないか？
現場の担当者のフィードバックをプロセス改善に活かす活動がうまくいっていないように思える。
フィードバックしても、課題と現場の作業にギャップがありすぎて、課題を解決することがとても難しいように思えてしまい、メンバーにとって、改善している感覚がないのだ。

また、フィードバックを受けても、フィードバックの量が多すぎたら、開発者も開発チームもその内容を咀嚼して制御することもできないだろう。
そんな状況は「相殺フィードバック」と言われるらしい。

相殺フィードバック: プログラマの思索

だから、CMMIもERPも現場担当者のレベルでは、それ自体の作業が自己目的化しやすい。

【3】「ソフトウェア開発は自己目的化しやすい」弱点に対し、アジャイル開発が良い所はいくつかある。
一つは、フィードバック活動に注力していることだ。
XPやScrumにしても、朝会(デイリーミーティング)やふりかえり(レトロスペクティブ)というイベントで、開発者が現状の問題点をチームに公表する機会が必ずある。
そして、その問題点をチームで解決しようとするプロセスがある。
特に、ふりかえりではKPTが有効で、KPTのやり方にはノウハウが結構ある。

フィードバックはたくさんありすぎても意味が無い。
フィードバックを受けた内容を次の開発サイクルに適用して、改善するように回さないといけない。

XPが提唱する小規模リリースでは、2～4週間のイテレーションで、定期的にリリースしていく。
たとえ機能が少なくてもリリースすることで、顧客に価値あるシステムをいち早く届けることができる。
そして、開発者も開発チームも、実際に動くシステムに触ることで、顧客から有意義な改善要望や障害報告を受けて、より良いシステムを作れるように、次のイテレーションへタスクを当てはめていく。

スクラムでは、スプリントの終わりに必ずデモを行い、利害関係者全員に見せるイベントがある。
デモを見せるからには出荷可能な製品をスプリントの最後にはリリースしなければならない。
「Demo or Die」という言葉が象徴的だ。
デモを見せることによって、顧客からのフィードバックをプロダクトバックログへ反映させて、次のスプリントに向けて改善していく。

いずれにしても、フィードバックプロセスを開発チームがコントロールできる範囲内で制御し、出荷可能な製品という現物を顧客に必ず届ける。

また、XPならオンサイト顧客、Scrumならプロダクトオーナーのように、開発チームは顧客を巻き込んで開発に取り組む。
彼らは、ゴールを開発者に思い出させる役割も持っている。
今作っている作業は、顧客にとって本当に価値あるものなのか、という評価をすぐに受ける仕組みが揃っているのだ。

【4】実際のソフトウェア開発は、ソフトウェアを作ってリリースするだけでもすごく大変だ。
ソフトウェアを無事にリリースするだけで精一杯なので、リリースしたソフトウェアがユーザにとって本当に価値があるかどうかまで正直頭が回らない時が多い。
だからこそ、タイムボックスで短い間隔でリリースしてフィードバックを受ける仕掛けが必要になってくるのだろう。

この辺りの議論はもう少しまとめてみる。