[経験談シリーズ]システム開発がうまくいかなかった訳(1)～”論理”から”物理”の際の抜け落ち

他人の失敗は蜜の味？、という訳でも無いでしょうが、人の「こんな風にやってうまく行ったんですわ、ワッハッハ」という、へこんでる時に見てしまうとちょっと自慢話にしか見えない話をするより、「へぇ～、そんなこともあるんや」とか「あるある～、そんなこと」とか「アホやな、うちなら絶対そんなことせぇへんわ」と言った失敗話の方が、皆さんに気軽に見てもらえるかな、ということでちょっと書いてみます。

まぁ、超ライトな「動かないコンピュータ」(by日経BP社)みたいなものだと思っていただければ幸いです。

もうかれこれ10年近く前の話です。

とある新規プロジェクトでSFAツールをスクラッチ開発することになりました。

それまでITの開発、においては使用しているメインフレームのSIerさんにお願いする、というのがほぼ常識化していたのですが、何名かの「ちょっとなめられてない？」という話からあまり発注実績の無いSIerさんにお願いすることになりました。

その当時がはやり始め、ということではなかったのでしょうけど、「DOA(Data Oriented Approach)」を得意とするその会社は、「まず何かをやりたい時にはそのデータを抑えないと始まらない」ということで、ER図により上流工程を固めていきます。

それは、それまで「まぁ、おたくはうちのことよく知ってまっしゃろ？」的なアプローチで、何となくSIerさんとシステム開発を行ってきたその会社にとっては画期的なことであり、当時は営業部門に居た自分にとっても、「ああ、これが世の中的な開発手法なんだ。やっぱり慣れだけでは世の中通用しないな」と非常に新鮮に感じました。

とは言え、営業部門と情報システム部門の混成からなるそのプロジェクトのメンバーにおいて、自分が一番若く、かつ一番その「DOA」に対して関心が深かった（というか、正直に言えば、他のメンバーはあまりに関心が無さ過ぎた・・・ああ、このエントリーに気づかないことを祈る（苦笑））ことから、自分達が望むべきシステムを実現するためにER図を徹底的に読み込んだのは自分だけだった。もちろんそれまでER図なんてものを知りもしなかったので、読み方はそのSIerさんに教えてもらいながら・・・。

ようやく、そのER図は完成した。”論理”ERDとして。

「この”論理”っていうのはどういうことですか？」
「まず実現する業務のためには、そのデータの役割等を明確化するため、細分化して記述していく必要がありますが、実際実装する際には、検索におけるレスポンスだとか、データベースの資源の有効化を図るために、エンティティの統合や分離などを行っていく必要があります。だから、次には”物理”ERDを書き直していきます」
「なるほどね～」

※記憶を再現したつもりだが、もう相当前の話なので、ちょっと会話の内容はうろ覚えです。

”論理”をきちん確認することにより、要求定義をする側としては少なくとも自分達が行いたい業務が実現できるデータ構造になっていることが確認できたので、その後は、営業部門である自分は”元々の”タスクである、どう展開していくか”という計画の方に移ることにし、実装における詰め、すなわち”物理”化は情報システム部門の方にお任せすることにしました。

ところが結果から言うと・・・ある部分において、検収時の「利用者想定による検証」で行えるべきことができていない、いや、正確にはデータ構造上できないようになっていたことがわかったのです。

”論理”の段階で、業務上Null値になることを想定してキー項目にしないとしていた項目を持つエンティティが、”物理”の段階で他のエンティティと結合された結果、その項目がキー項目に設定され、Null値が取れないようになっていたのです。

また厄介なことに、マスター管理をするためのサーバー側、そのマスターを配信し、実際にSFAツールとして利用するクライアントPC側、それぞれ同一の構造をとっていたため、いざ改修する、となっても大幅な期間が必要である、ということになりました。

したがって、(絶対にmustな要件、という程のものでは無かったので)一旦、その状態でリリースを行い、初期導入に伴う発生課題等を解決しながら、たぶん半年以上は経ってから、でしょうか、やっと改修をしました。その間、ユーザーには結構な手間を強いてしまいました。

問題の温床はいくつかありました。

まず極めて単純な話。格好悪いのですが、当初、そのプロジェクトで実現したい、と思っていたことを全て実装するために必要なそのSIerさんでの開発費用と、予算化できていた費用に大幅なずれがあり、「ダンピングできる程、大きい仕事では無い」とふんでいたSIerさんと、「そもそもうちの会社でそんな金額出せますかいな」と甘く見ていたその会社で次の実装フェーズに行くまでに膠着状態になり、半年間、休止期間があり、結果として、ほとんどのメンバーが入れ替わってしまったため、”論理”設計結果の意図が”物理”設計時に100%きちんとはトレースされなかった、ということがあげられます。

※今、世の中で聞く金額で考えれば、画期的に「安かった」ような気がしているのだが、それはまたそれ。

属人的ではいけない、とは思うのですが、ここはいたし方無いでしょう。

でも、それより、”論理”できちんと描けていたものは”物理”になる時には自然に反映されているものだ、という思い込みをしてしまったところがあるか、と思います。情報システム部門の担当は何をやっていたんだ！という話もちらっとは思わなくは無かったですが、自分としては、あれだけ根性入れて”論理”ERDを確認したのに、”物理”ERDがあがってきた時に、人の言葉を鵜呑みにしてしまった、というのが、自分自身、当時を振り返ってみても悔やまれるところでした。