ソフトウェア開発プロセスとオーケストラの関係(メモ書き)

list このエントリーをはてなブックマークに追加

ちょっとルールを決めてみる。

考察の対象は、ウォーターフォールだったりアジャイルになるんだろうけど、「比較対象」にしないようにしよう。比較対象にしてしまうとと、批判的なことになっていしまうので水掛け論にしかならない(ウォーターフォールだけにw)。なので、実現可能性を求めることにして、実現不可能性のところは、多少オミットする。実現不可能性というのは、悲観的な意見(現実がアレだから、どうにもならないことだから)という悲観的…と言いますか、「実現不可能であることの原因を外部に求めてしまうところ」のことで、所詮、ひとつひとつのプロジェクトは「プロジェクト」であるがゆえに、完全な相似は求められないのだから(だけど、若干の相似性はある。という前提がある)、外部要因も様々、ひるがえって、現実にである内部要因も様々である、ということを認識する。

なので、「なんとなくできたらいいなぁ、夢の開発プロセス」でも ok かと思う。そういう意味では、SF 的に思考実験みたいなもので、それがアジャイル界隈になるのか、逆にウォーターフォール界隈になるのか、スクラムになるのか、統一プロセスになるのかということをカテゴリに含めるのではなく、横軸として考えることにしよう。ワインバーグの本は直接ひも解くと引きずられてしまうので参照程度に。

そうそう、オーケストラとの対比の中で、ベースはのだめカンタービレを用いる第一の理由として「人物に投影すると分かり易いから」というのがある。理論的なところや手順を示しても、なんとなく可能できそうな、可能でなさそうな、スーパーマンを予想してみたりと、人物像が結べなかったりする。ふと、気づいたのが、それってプロセス開発を構築するにあたり「ペルソナ」自体がうまくいっていないでは?と思ったり。いや、発案者自身はわかっているのだが、説明するにあたり、説明を受ける側が像を結べないのではなか、と勘繰ってみたり。なので、その補完をする意味で、多少の揺れ/ぶれは目をつぶるとして焦点が合しやすい「像」を立てておくことは重要だ。それが、「のだめカンタービレ」の登場人物であったりする。

そうそう、他人と何かの認識を合わせることきには、「共通認識(バックグラウンド)」が必要だ。だから、ある程度のバックグラウンドを共有していない相手は、どうやっても認識を合わせることはできない、と最近結論付けている。そうそう、人に「期待」するところはできるだけ小さくしておくのがよく、同時に、インプットとアウトプットの組み合わせを確認することによって、その人が何を考えているのか(あるいは考えていないのか)が分かる、という具合だ。

という訳で、バックグランドで動いていたプロセスも終了したようなので、ひと区切りします。売り文句として「歌うようにプログラミングする」あるいは「歌うように開発をプロセスする」というのを思いついた。当然、「流れるようにコーディングする」へのオマージュである。

カテゴリー: 雑談, のだめ開発プロセス パーマリンク