上流工程
http://www.web-career.com/suc2.html
上記を読んでいて、インタビュアーの方が上流工程っていう言葉を使っていて気になった。*1
多分、インタビューアの方が想定している開発プロセス?はパイプラインみたいになっていて、上流工程(要求分析でも外部設計でもいいけど)で作られた成果物をもとに、下流工程で実装を行ってプロダクト完成みたいなイメージだと思う。このモデルでは、情報は基本的に上から下に流れていく。
このモデルだと、上流工程のエンジニアが、要求から、実装、運用にいたるまであらゆる知識を持っていないと、下流工程で正しいものを作れなくなってしまう。イテレーティブに開発していても、上流/下流という発想があるかぎり、基本的に変わらないと思う。
例えば企業Web系プロダクトの開発なら、上流工程では、顧客独自の要求も把握してDB設計もできてサーバ系も画面系技術も押さえてて当然言語とかは詳しいし運用関連もOKみたいな、スーパーエンジニアが必要になってしまうわけで、もう弟子入りしたいです。
実際にはそういう人は多くは無いし、いたとしてもベンチャー系でバリバリやってそう。そういうわけで普通の開発現場では下流工程に皺寄せがいってしまう。AjaxのAも知らん人が画面仕様書とか泣ける。
個人的な感覚では、実装や設計みたいな下流工程(と呼ばれてたもの)と上流工程(略)は並行して走っているべきだと思う。そのモデルでは情報は双方向に流れててお互いに影響しあっている。例えば実装の要請で要求を狭めたり広げたりすることは全然アリなのではないかと。要求側で作成した画面仕様書がダメなら実装側の提案で変えればいい。
情報が双方向に流れるのなら上流、下流の区別は無いし、全部の工程に精通したスーパーエンジニアは必要無いわけで、要求のプロ,実装のプロ,マネジメントのプロ etc. がそれぞれベストの仕事をすればいい*2。ただそこには上流下流の概念は無いと思う。順序が無いと工程という言葉は当てはまらない。RUPだとディシプリン*3でこちらの方がしっくりくる。
もちろん全体で最終的な判断を下す職務は必要だし、そこらへんの「上下」が無くなるわけでは無いとは思うけど。
追記:
作業分担が工程単位ではなくタスク単位になっている開発も多いとは思います*4。それならば、上流下流の垣根を取り外し、個々のエンジニアが全体に関わりつつ、規模の増大に対応できるかもしれません。ただタスク間の同期どうすんのとか、やっぱ全体を統合する必要あるよね、といった問題がおきると思いますが。そのためのハブ的なサブチームが必要なのかもしれない。「星を継ぐもの」に出てきたみたいなやつ。
