「開発工数の削減」

さて、すこしづつ開発工数を削減するための知識、という観点でのABAP基礎知識を書いているのだが、
実は技術論云々の前に、全然違う観点から実現が難しい場合がある。
「SE・コンサルは金の話をしてはならない」なぜなら「責任が取れないから」という話が
プライマリベンダーから出てきて、コストに対する効果の話自体を封じ込めてしまう場合。
それと、そもそもエンドユーザ側に「コスト意識」が働いていない場合である。


結局のところ、私がつらつら書いている「知識」は、
「ここで我慢してもらえれば、全然少ない工数ですみますよ」
という知識なのである。
ということは、そもそもエンドユーザ側に、「安いのなら、この辺で我慢しておこうか」という
「コスト感覚」に訴える手法なのである。
だから、当然、「これ以上のことをすると、高くつきますよ」ということをコメントせざるを得ないのである。


ところが、このこと自体をタブー視するプライマリベンダーが、実際にいるのである。
「お金のことは営業が調整するのだから、作業を行う人間がそんな話をするな」
という姿勢である。
しかも悪いことに、時々、
「せっかく作るのだから、細部までいいものにするべきだ」
返す刀で、
「一括で請け負っているのだから、工数がかかるかどうかは、ベンダーのリスクなんだ」
という、さらにわけのわからない理屈をこね出すエンドユーザもいたりするのである。


んなもん、意味のないアドオン工数を「ユーザ要件だから」バンバン増やしていくほうが、
ユーザにコストを意識させるよりも、よっぽど「無責任」だと思うのだが・・・
少なくとも、費用対効果をユーザに判断させるための大雑把なコスト情報は、コンサルの責任として開示すべきだろう。
さらに、「一括」という言葉尻を捕らえて、プロジェクトが遅延するという最大のリスクを、
自ら招くようなことを言ってしまうエンドユーザは、論外中の論外である。
そんなことして、開発工数が膨らんで、カットオーバーできなかったらどうする気なのだ?


結果は大体決まっている。
この膨らんだ工数の後始末を、より安いところに分割して請け負わすことで、全体の費用を安くしようと、
エンドユーザは考え、それを行う。
ところが、そんなことをすれば、その他のところをやっているベンダーと「会社間の壁」が発生し、
簡単にできることも、どんどんオーバーヘッドがかかっていく。
例えば、2年に1回しかメンテナンスしないマスタの更新画面作るのに、仕様書をきっちりつくって、
それを別の会社に渡す。別の会社は、前提となる業務は知らないわけだから、仕様書のとおりに作る。
業務の前提を知らない状態で作ったプログラムほど、危険なものはない。当然仕様変更が発生する。
そのたびに「仕様書作成」「プログラム変更」「綿密なテスト」が行われるのである。
しかも、仕様書を書いている会社と開発した会社が別な場合、「責任分担の明確化」を大義名分に、
同じテストを両者がする場合が非常に多い。結果、加速度的に開発工数および費用が発生する。
このパターンに陥ったプロジェクトは、「ブラックホールプロジェクト」と呼ばれ、人を吸い込み続けるのである。
(去年から今年にかけてだけでも、私の知っているだけで、このパターンにはまったプロジェクトは5つある)


まあ、プライマリベンダーにしてみれば、「作る」といってくれればしめたもの、自分ところの売上が
「開発」という名目であがっていくわけだし、体制図上は、たいていプロジェクトマネージャは、
ユーザ側の人間になっていて、そこが止めないのだから、こちら側からコストの話をして、
追加開発を我慢してもらうようなことを話すのは、越権である、なんて話にもなることがある。
理屈としてはある意味通っているので、この理屈を出されると、私もあきらめざるを得ない。


最終的には、やはりエンドユーザの姿勢が大事、ということになる。
ただ、彼らの立場もわかる。
不用意に「この程度でいいでしょ」と言ってしまって、今後何年か不自由なオペレーションが発生し、
「こんなものにしたのは誰だ!」という社内の声を聞く羽目になり、居心地の悪い思いをするなんて、
たしかに真っ平ゴメンである。
勢い、「せっかく作るのだから、細部までいいものにするべきだ」の、勘違い人間が生まれるわけである。


それに対する解法は、システム化予算の組み方である。
「小さく作る」「どうしてもダメなところをカットオーバー後に修正する」という方針で予算を組むのだ。
そうすれば、とりあえず「安い」手法で作っておいて、どうしてもダメなら、後から修正しましょう、
という意思決定をしやすくなるのである。
カットオーバー後の修正に、ある程度の予算を組んでおいて、「この程度でいいでしょ」という
意思決定がしやすい環境を作る、それが、「開発工数を削減する」という命題への、
もっとも重要な施策になるのである。


だが、現実は作りっぱなし予算が大半を占めていて、自分でベンダーの食い物になりに行っている。
エンドユーザの皆さんには、ぜひにそこは理解していただきたいところである。