公共団体のＩＴ調達を考える

なるべくコンサルタントを排除する！？

　プロジェクトマネジメントのプロフェッショナルとして、某公共団体のＣＩＯ補佐業務に関わる中で、ＩＴ調達に発注側（地方公共団体）のコンサルタントとして関与しています。

　コンサルタントの立場で関与していて初めて発言できるのですが、作る側として、過去発注側のコンサルタントをとてもジャマに感じていました（笑）。

　そんな経緯があって、正直、居心地が良いとはとても言えません。

　この業界に入りたての頃は全く思っていませんでしたが、様々な経験を経た現在では「そもそも実際にヘビーな開発そのものを現場の末端の立場で行った事がない人のそれらしい発言ほどやっかいなことはない」と思うようになってしまいました。

　これはコンサルタントという、いかにも能力が高そうな職業に対して、個人的に元々持っていた憧れと共に、期待が大きすぎていたことも悪く影響していると思います。

　いつしかコンサルタントら、実際に作るのではない人々の発言による、作る事に対して本質的にムダな事をいかに行わないようにして、開発プロジェクトのそもそもの目的や、個々のプロセスの品質に集中できるようにするか、ということがプロジェクト成功の為の重要な要素と思うようになっていました。

　公共団体、官庁等の調達は、上流工程と下流工程（上流と下流という呼び方自体に極めて強い違和感を覚えています）を別々の企業に 発注「しなければならない」ということになっているらしいのですが、それ自体がとても大きな国家レベルの損失を生み出していると思っています。

「全て」上流工程を行った者の責任とする

　というのも、業務分析などを直に行って、ユーザー側などといろいろと話しながら組み上げていったイメージや考え方を、その構築過程の多くを抜きにした結果としてのドキュメントなどで（例えばＲＦＰとか）、伝えきれるとは全く思えないのです。

　そして、説明能力の方を問わずに「聞く側が理解出来なければだめ」「理解出来ない[下の者］が悪い」という旧来の日本的な文化の中、「ＲＦＰがあるのに、それを読んで解らない方がわるい」と現実なりがちなのを極めて心外に思っています。

　「多くの場合、上位マネジメントから実作業者に説明しきれていない」とか、「ＲＦＰの品質そのものに問題がある」などのような議論を耳にすることは、なかなかありません。

　あるべき姿の実現を考えるのであれば、例えば業務システムを考えた場合には画面上の外見は全て詳細に定義して、後は機械的に作るだけという次元にするべきでしょう（ほとんどの上流工程実施者が、現実、ここまでできていませんし、やりかたをわからないと思います）。

　そして、できあがったモノが「使えない」のは、「ほぼ全て上流工程の企業の責任」となるＩＴ調達の進め方を実現出来ているべきです。

　この仕組みの上でさらに「上流工程の丸投げ」をしないで、現在、上流工程を受注している人々が経験を積んで行くようになれば、随分と日本のＩＴ業界の競争力も高まるのではないでしょうか？

　個人的に行ってきた私の進め方は、全て上流工程と設計活動（運用設計含む）を主体的に行った私、私の会社が全て責任を負うという考え方でした。

　「上流工程を行った者が（ほぼ全ての）責任を持つ」という意識だったからプロジェクト全体が成功できたのだと思っています。

　「実際に使えるモノ、運用にキチンと乗るモノ、を作るプロジェクト」なのですから...。

　建築業界のように強度計算、構造計算など、基準を明確に特定でき、第３者による監査もしやすく、できあがるものも確実に目に見えるものなのであれば、上流工程の成果物を確実に評価でき、確かに上流下流分離発注もあり得ますが、ソフトウェア開発においては、全く期待できません。

　作ろうとしているモノの特性を理解していない結果として、具現化が現実的ではない上流工程の成果物（要は使えない成果物）が大金を用いて生み出され、下流工程の少ない予算の中、「上流工程のやり直し＋本来の下流工程」が行われていると言う「関係者の中では半ば常識化した認識」が存在しているらしいのです（そしてそれを解っていながら、なかなか変えられない）。