プロセス
さて。遅くなりましたが整理して書いて見ます。...と丁寧に書いたらすっげえ長くなってしまった(苦笑)ので思い切ってもう一回、いつものやさぐれ口語で短く書いてみました。わかりにくければ補足しますので、コメントいただければ。
私が厳格さという言葉で言いたかったのは、ウォーターフォールプロセスの現実の実装で長年行われている、
- 次工程(軽量プロセスにはなじみませんが、仮にこう呼びます)に進む際の判断として徹底して行うフォーマル・レビューなり承認作業
- これを厳格と言うのは違うかもしれないが、工程とそのつながりはすべて規定されていて、それから外れる事がないこと。基本的に前に進むか戻るかだけ
ってことでした。そんなんわかるわけねえだろってくらいの殴り書きの文だったのは、まったくごめんなさい(_._)。
まあ、この話は従来ウォーターフォールでやっていたのを、なんとかしようと動いている、オイラみたいな人に限定した話なのかもしれないが、これを推した動機はどちらもその決断力と推進力にあります。この力が厳格に与えられる。変な日本語だな。まあいいか。なんとなーっくプログラマの子はペアプロしたりビルドすげー毎日できてると喜んだり、プロジェクトリーダもポストイットいっぱい貼ってなんだかたのしー、というのは、もちろんいい。俺も好きだ。けど、で、どうなってるの結局、という話に持って行き難いのが多いなと。それを打破するにはいいなあと。
軽量プロセスに変えて従来からよくなっているかってのは、周りも気になります。特に費用を負ったり、それに合わせてスタイルを変えた人たちはね。特に費用や責任を背負ってる方は不安でしょうがない。そういう人にわかるよう、成果や問題をまとめてあげるのに、しっかりしたレビューを追加して行い結果を見せるのが、まず一点。まだまだ成果が出て無くても、それはそれで今後の金の工面や関係部門への根回しもできるでしょ。
段々生臭くなりますが、次にあるのが、「イテレーションだかしらねえが、同じことやって遊んでるだけじゃねえの」という関係者にわかるように成果を見せられること。ソフトウェア開発以外ではウォーターフォールが参考にした分業スタイルは良く機能してますから、やっぱり「ちゃんと全部準備して、準備したか確認して、OKなら次にちゃんと全部設計して」ってのがまあ、ちゃんとしてる(笑)訳です。製造だけじゃなく、営業や企画もそれを前提とした業務形態が多い。
そういう人に「ちゃんと進んでますよ」と話すにはスタイルを合わすのが一番早い。最終的にはこちらにあわせてもらうだろうけれど、向こうだってこっちが良いと思ってくれなきゃ話にならないし、良いと思うには2つや3つのプロジェクトが最終的に成功したくらいじゃ足りない。今までの実績や経験があるからね。早めにこっちの良さを教えていくには、まず合わせてあげるのが一番。そうすればXPのエクストリームある意味最大なオンサイト・カスタマーも、営業さんの説得で可能になるかもしれない。ちなみにウォーターフォールモデルのもともとにも「顧客を巻き込め」というのは書いてあります。
次。はっきり書くけど、本当に「同じ事やって遊んでる」という場合が、よくある(笑)。遊んでるってのは違うな。ドツボ。信者や技術野郎に多いんですけどね。なんだかんだと理由をつけ、自分が完璧だと思うまでやろうとする。自分が完璧じゃないから成果も完璧じゃないんだという人生の真実を認めないから止まらない。こういうのは、もっとこうすればいい、ああこの本のこう書いてたのはこれかー、なんつって、いつまでも出荷まで持ってかない。多少はいいですよ、もちろんね。でもさ、そうやってやらせるために、費用や責任を背負って、「すいませんね、これがソフトの開発スタイルなんで」って頭下げとるおっちゃんが後ろに居るからできてる訳でしょう。同じくらい興味があってやってみたいけど、今回のプロジェクトで最終的に成果が出たら、って止められてる子もいて、今のプロジェクトとの優劣は無いはず。だったらとっとと成果出して終われ。プログラムいじる話ならいいですよ。でも開発プロセスは会社組織の人間をいじるものですから、俺だけ楽しければいいってのはね。こういうののケツを叩いて終わらせるにはちょうどいい。終わってから次でまたやりゃ済む話なんだが、こういうタイプはまずそういう発想をしないのが面白い。いや面白くない。
こんなとこかな。他にも、軽量級は往々にしてプラクティスに技術的な話と組織的な話を混ぜるから、どっちかしかわからないヤツはフォーマル・レビューの場で双方の側面や噛み合わせ方を勉強できるだろうとか細かいのがありますけど、まあこのへんで。もう頭回りません(笑)。
