これを読んでなんとなく思ったことを書く。
僕は「ソフトウェアプロセスが盛り上がってこれから普及するぞ(でも下火になった)って時期」を知らないので、元記事で使われてる言葉をかいつまみながら想像を膨らませて書くことになります。なので、紹介されてる書籍を読んでから書けよという話ではある*1のですが、とりいそぎ忘れないうちにポエム程度に書いておこうかと思います。
ただ、明らかな事実誤認等があればどなたかご指摘ください。
プロセスは人に依存するようになった
「ソフトウェアプロセス技術」というものがそもそもどういうものなのか僕はイメージがわいていなくて、なのでそれが流行りかけて下火になったことに対しても何も言えないというか僕として意見はないのだけど、それらが技術として体系化されたものでなくもっと人に依存するものになった可能性はあると思っている。
ソフトウェアの開発プロセスが技術的に体系化されて管理されるのではなく、そこに集まった人たちでどうやって開発を進めるかということに比重が置かれてきた感じ。
「あらかじめ決めることを決めてからソフトウェアを開発すること」は依然大事
「ソフトウェアプロセス技術」がいわゆるプロジェクトマネジメントの話なのか、もう少しアーキテクチャに寄った話なのかわからないんだけど*2、いずれにしてもビジネス全体のあり方を整理して決めることを決めてから開発を進めることの重要性は低下していないと思う。
決めることをちゃんと決めて開発を進めることでプロジェクト資源的にもアーキテクチャ的にも無駄を極力なくして開発をすることは大事なんだけどそれが難しすぎて意思決定を遅らせたくなったという状況があって、そのときに救世主的に登場したのがアジャイルに代表されるようなインクリメンタル型開発なのではないかと思う。
ただインクリメンタルに開発をすることで意思決定を遅らせるというのは実際にやってみるとわかると思うけどすごく大変である。もしかしたらそれをノーコストでできると思っている人がいて「アジャイルは画期的だ！すごい手法だ！」と言われて広まってしまった*3のがプロセス技術が下火になった原因なのかもしれないとは思う。
僕はアジャイルとウォーターフォールをあたかも対立する概念のように扱うのは好きじゃなくて、それはこんな風に、アジャイルというか柔軟なプロセスと高度に自己組織化されたチームが決めなければいけないことから目をそらしがちになるからである*4。平たくいうとどっちが言っていることも絶対大事で、これらをどう組み合わせていくかという話でしかないということだ。
良いチームと良いプロセス
僕は良いチームと良いプロセスはかなり深い関係にあると思っているけど、これは分けて考えたほうがいいのかもしれないと最近は思っていたりもする。
僕は今回プロセス技術というのがかつて流行ったことを始めて知ってとても得るものがあったと思ってるけど、それ以前にも例えばプロジェクトマネジメント理論とかモデリングとかアーキテクチャ設計とかには興味があってわりと勉強をしていた。アカデミックな世界でこういう風に体系化可能なものは体系化されていたほうがありがたいし、それは積極的に活用するべきだと思う。
なかには開発現場までダイレクトに適用可能なほど体系化できていないものもあるはずで、それらは最近だとパターンランゲージを用いて記述されることが多いのかなという印象がある。デザインパターンとか組織パターンはもちろん、例えばリファレンスモデルなんかもひとつのパターンと言っていいと思っていて、こういうのはツールとして出来上がっているものや標準仕様として広まっているものよりは各現場での工夫が必要になるけど、フルスクラッチで設計していくよりははるかに楽であり先人の知恵を利用させてもらうことができる。
そして、それでも解決できない問題が残るのであればそれこそがそのプロジェクトが立ち向かう本質的な問題な気がするし、属人的で再現不可能であっても手探りで解決していかないといけないもので、それこそが良いチームなのかなと思う。
うーん
結局何が言いたかったんだっけ…
