ThomasLogic

アプローチ

10年以上のプロダクトを構築 新しい発想で10年以上のプロダクトを構築できないだろうか？

日々刻々と変化する業務に対応できるシステムを10年以上カスタマイズし続ける事はできないのでしょうか。
OSやデータベースなどのバージョンとビジネスプロダクトを切り離して構築すれば可能性はあります。

OSが変わろうと周辺のアプリケーションが変わろうとツールの会社がM&Aされて保守が見込めなくなる事が起きても ビジネスのロジックは変わりませんし、コストに見合うプロフィットは期待できません。
（この点については長年お客様と解決案はないものか検討しました。）

しかしながら企業のプロダクトは止める事ができないので保障のある維持管理のためにコストをさきます。
積み重ねてプロダクトを構成したものを捨てて保障をとるのです。

「保障のある」を高められるようにするためにはISOやW3Cなどの国際標準や技術の流れが重要になります。
なぜなら、理解してメンテナンスできる技術者の確保が保守にかかわってくるからです。 では、今後も標準的であり続ける事は何でしょうか。


A)今後も標準的であり続ける技術
・Ms-InternetExploerなどのブラウザーで業務をする
・HTML
・ブラウザーに組み込まれたJavaScript
・データアクセスのためのSQL
・ファイルの管理のためのI/Oアクセス
・文字列による文字解釈
　　　（バイナリではなくASCIIやUTF8などによる文章:HTMLや
　　　PostScriptのような記述）


B)バージョンの問題もあるが標準的であり続ける可能性の高い技術
・Miscosoft社 Windows
・Oracle
・Miscosoft社 Sql-Server
・Oracle社 Java
・Adobe社 pdf

C)5年後はなくなっているかもしれない技術
・各種

と考えるならB),C)は、切り離せるように設計を考えるべきです。
業務プロダクトをオラクルで開発した後DBだけMsSql-Server、DB2、HiRDBに変更するということは実際は皆無です。
弊社での実績はあるのですが優先事項としてはかなり下位に属します。
各種ツールについては「5年後もこのプロダクトは製品でありますか」と聞いて不明確な答えなら
オープンソースの方がいいのかもしれません。

我々は、
基本はAランクで作成。
Bランクについては、最低限の変更で済むように設計。
Cランクはできるだけ使用しないが、他にない場合は数ヶ月で変更できるように設計。

悪戦苦闘しながらこのアプローチした結果、
プログラミングを教える学校で習ったことばかりとなってしまいました。
なんと技術者確保についても容易になってしまいました。
業務を理解すれば10年以上の保守管理が可能となり、新しい技術の追加組み込みが容易となりました。

※新しい技術：GoogleMap連動、セキュリティタグ機能の追加、インターフェイスデザインのajax化など