上流工程に関わる人にこそプログラミングを経験してほしい

一般的にも、システムインテグレーション（SI）には大別して上流工程（要件定義・概要設計）と下流工程（詳細設計・プログラミング・ テスト）があり、どちらが欠けてもシステム開発は成功しません。

アクセンチュアでは、＜計画・分析・設計・構築・テスト・展開＞のフェーズに分けてSIプロジェクトを推進しており、 各フェーズで担当者が異なってもスムーズにバトンタッチできるようなアプローチを採用しています。

いずれにしても、SIプロジェクトの規模が拡大するにつれて、上流から下流まで一気通貫で直接作業を行う機会はなくなり、 むしろ分業によって効率化を図ろうという流れに必然的にたどり着くのですけど、これが無理解なセクショナリズムによって対立に結びつき、 そもそもの目的である顧客満足の達成を阻害するというケースがあります。

例えば、こんな状況を想像してみてください。

『クライアントの業務部門と直接折衝して要件定義を固めていく上流工程に関わる人たちは、 気が付くとクライアントと同じ側に立つ人間として振舞うようになり、下流工程のチームに要求を押し付けるかのごとく接するようになった。

一方で、 下流工程では確実に動くシステムに落とし込んでリリースする必要があるため、 スケジュール遅延に結びつく業務側の要求は基本的に突き返している。』

このような状況の果てに、同じプロジェクト・会社の仲間であるにも関わらず、 お互いがお互いを非難し責任を擦り付け合うという場面に遭遇したことのある方、結構いるのではないかと推察します。

私見ですが、上流工程担当者の下流工程への無理解によってこのような対立が生まれることが多いと感じます。
　※　私の経験の範囲ですから、全てがそうとは言いません。

では、上流工程担当者が下流工程を理解するためにすべきことは何か？

解決策として挙げるのは、下流工程の経験者が上流工程を担当することです。

これは私自身が経験してきたことでもありますが、設計書に従ってプログラミングを行う、テスト設計・実施を行う、システムリリース （本番稼動）を経験する。これらを一度でも経験するだけで、下流工程での作業を視野に入れた現実感のあるシステム設計に近づきます。

だからこそ、コンサルタントやシステムアナリストは早い段階でプログラミングを経験してほしい、そのように切に感じています。

多くのプロジェクトでは、すでに下流工程側の担当者は同じような歩み寄り（上流工程への理解）を十分に示してきたと思います。

次は上流工程を扱う担当者の番です。アーキテクチャの概要理解だけではなく、 是非ともソースコードをレビューできるくらいの知識を目指して、日々の研鑽を積んでいきましょう。

ちなみにこの話は、開発担当と運用担当にそっくり当てはまる内容です。「運用はシステム開発のおまけ」くらいにしか思っていない方、 是非とも運用業務を一度経験してみて下さい。

価値観がきっと変わりますよ。