私が最初に勤めていた家電店から地図関連の会社に転職した際の採用名目は「地図関連商品を販売、流通させる」というものでした。たしかに私がいた会社は最も有名なZ社をしのぐ詳細地図を有しており、自社開発のオブジェクト指向DBをベースとした表示検索エンジンも保有していましたので、業務用GISやそれより小規模なコンシューマー用地図パッケージを販売したい、という考えは20世紀も終わろうとする時期でも決しておかしな考えではなかったのですが、当の私が、「それは無理です。」と入社して1か月ぐらいで言い出してしまいました。

【自社でやれる売り方の範囲で】
製品の販売には商品デザイン、パッケージのデザインや説明、ヘルプの分かりやすさ、問い合わせ窓口でのマニュアル化された対応、それにバージョンアップ時の返品など流通との情報のやり取りなど開発技術以外の多くの要素が必要になるわけですが、その会社は中国人技術者を中心とした技術はあっても、これらに関しては非常に低いレベルだったのです。
当然、私は、「お前、何のために来たんじゃ」という風当たりをもろに受けたわけですが、その代わりに提案したのが、当時黎明期で、当時はASPサービスと呼ばれていたインターネット上で地図を検索、表示したり、その他のコンテンツを地図上にプロットしたり検索したりするAPIを公開するクラウドサービスでした。これならば、とりあえず、メンテナンスやバージョンアップする箇所はサーバー1か所でよく、APIの仕様書は開発企業向けにわかるものであればよいので、ぐっと負担が減る、というわけでこの会社にあった選択だったと思っています。
今のようにJSONでのデータ交換などができる前でしたが、当時新しくはやり始めていたXMLを活用した仕組みは汎用性が高いもので、営業の方の奮闘もありそこそこの成功を収めました。

【自社でやれる開発のやり方で】
最近、知り合いの会社が顧客管理のシステムを結構なお金を使って外注して、AWS上でRuby On　Railsでスクラッチ開発されていました。ただ、その会社は業務の営業に関しては非常に高いスキルを有するものの10人未満で、システムに詳しい方はおられないため、運用条件ですとか、あるいは納品物にマニュアルを含むか、とかそうしたことを事前に考えておき、開発業者と相談しておく、ということの重要性がよくわかっておられませんでした。そのため、継続的に運用する、あるいは改変し発展させていく、ということが難しいものが出来上がってきてしまいました。その仕組み自体のニーズはとてもよくわかるし、口述伝承で伝えられた要求はほしいものがきちんと網羅されていましたし、出来上がりをみても、DBアプリを開発するのにスマートな方法である特徴を生かして作られているようです。ただ、デザイン性などは事前の相談をしていなかったため、極めて簡素でそれも不満の種のようでした。
もう少し早く社長にアドバイスを差し上げられていれば（といっても着手したのは半年前のようなのですが）よかったなあ、と思うのですが、、契約管理、顧客管理、営業管理といった多くの会社で使われているベースがあるようなものを果たして０から作り、サーバーも自社で構築して（SSLが導入される流れになっていませんでした）、というのがこうした小さな会社が運用し続ける仕組みで適当だったのだろうか？というのを急ぎもう一回検証してから次の策を練りたいと思っているところです。SalesForce（R)に代表されるような仕組みを活用することは、社長は「費用が高い」と初期段階で選択肢から排除していたようですが、サーバー運用にかかるコストやリスク、ひな型的な既開発分をプロトタイプとしていくことでの開発速度の改善などを加味して評価すること、そして、「アンダーコントロール」である範囲に対処すべき範囲を限定することなどを考えると、悪い選択枝ではなかったように思います。
また、必要な機能をすべて盛り込んだため、入力しなければいけない項目が非常におおくなっていて本当に運用できるのか？というようなサイズ感の問題も実は検証されていないようでした。

私自身、システム開発部にいるときも、ソースコードを書くことはもっぱら天才たちにまかせっきり（勉強はしたが、なかなか動かない…）だったのですが、それとは別に「何を考えるべきかをまず考える」「見えにくいトータルコストを見えるようにすることや掌握可能な仕組みとすること」ができることで自社やお客様への提案にあたり、いつまでも完成しない、運用しきれないという状況を回避できたことが多かったように思います。そういう助言ができる人が普段システム化なんて頼まない会社には必要なんじゃないか、と最近よく思っています。