このサイトについて

  • このエントリーをはてなブックマークに追加
  • 人気ブログランキング

昔は大変だった。。。

今までいろいろなアプリケーションを開発してきましたが、特に画面表示、画面インターフェースは、PCの機種やディスプレイの依存などで、すごく面倒でした。

 

現在では、PCやスマホには、Webブラウザは必須です。もう、ブラウザなしでは、情報は引き出しにくいです。

 

「アプリがある」

 

と言われても、それはiPhoneやアンドロイド依存で、昔ながらのアプリケーション開発と、苦労は同じです。

 

もう標準となったWebブラウザですが、簡単に、汎用的に作るなら、昔よりは、はるかに楽になりました。
(※微妙にブラウザ依存もあったりしますが。。。)

Webブラウザは必須

PCやスマホ、もうWebブラウザは必須です。

 

そうなると、ブラウザに表示する仕組みを知っていると利用価値があります。

    • HTML(HyperText Markup Language)
      ページの文書を記述するための言語
    • CSS(Cascading Style Sheets)
      画面デザイン
    • JavaScript
      画面上の動的な制御を行う言語

 

上記は、ブラウザ上(フロントエンド)の話です。

バックエンドとの連携

「フロントエンド」に対して「バックエンド」があるわけですが、「バックエンド」では、いろいろな処理を行うことになります。

 

システムでは、データベースを使いますし、メールの送受信、FTPで情報のやりとりなど、アプリケーションとしての処理を行います。

 

そこで、「バックエンド」では、いろんな処理をしつつ、最終的に、ブラウザ表示部分まで行うこととなります。

 

「バックエンド」=「いろいろな処理」+「フロントエンド表示部分の生成」

 

と、なると思います。

 

「フロントエンド」の表示部分はHTMLですので、「いろいろな処理」もHTMLに似たものであれば、「バックエンド」全体の処理としては作りやすくなります。

 

それを実現するのが「ColdFusion」というものです。

 

そのHTMLに似た書き方をする言語として、CFML(ColdFusion Markup Language)というものがあります。

 

正直なところ、スクリプト形式の言語をやってきたものとしては、違和感がすごくありました。

 

ただ、HTMLと混在させると、CFMLがなじみやすいでした。

Webデザイナーやホームページを作成する人であれば、すごくなじみやすいのが、「ColdFusion」です。

ColdFusionが日本で普及しない理由

1999年にColdFusionの存在を知ってから、

「Webアプリの開発効率はすごくいい」

と、思っています。

 

でも、

「どうして普及しないのか」

いろいろ考えましたが、

 

ソフトを他人に作らせる日本、自分で作る米国

 

という本を読んで、納得しました。

日米のIT技術者数の比較

2009年と古い資料ですが、日米のIT技術者数の比較です。

 

日本が102万6千人、このうち25万5千人が一般企業に属し、77万千人がIT企業に属している。

米国は330万3千人、このうち236万2千人が一般企業に属し、94万千人がIT企業に属している。

 

比率でいうと、

 

日本の一般企業:日本のIT企業=25:75
米国の一般企業:米国のIT企業=72:28

 

上記のように、アメリカは一般企業のIT技術者数が多いです。

日本の会社

日本の会社は、正社員が解雇しづらい状態です。

 

例えば、社内でシステム開発しようと思っても、正社員として雇った場合は、そのシステム開発が終了した場合は、暇になってしまうでしょう。

 

となると、派遣社員を雇った方が都合がいいと思います。

 

契約期間を短くしておいて、契約継続しておけば、契約終了としても、ほぼロスタイムなく契約終了できそうです。

 

派遣社員でなくても、請負業者が多数を占めています。

 

かといって、建設業界と同様に、一次、二次下請け業者が多かったりします。昔は、三次、四次とあったりしました。最近は改善されているようですが。。。

 

請負業者としては、見積もり金額が高く、長期の仕事が理想です。

 

ColdFusionは簡単なので、理想にほど遠いです。
(知られていないというのもありますが。。。)

アメリカの会社

アメリカは社員であっても、ボス次第で、スカウトしたり解雇したりできます。

人・モノでも、会社に貢献できないものは、捨てることができます。

 

会社で作ったものは、会社の資産として、マニュアルをしっかり作るようです。
(日本の場合は、正社員として守られるので、マニュアル化をなかなかしない。なぜなら、わからなかったら会社のどこかにいるはずなので、聞けばいい!?)

 

社員はボス次第で増減できるので、優秀な人を雇って、システムを内製化できると会社の資産として残りますし、トータルコスト(言語習得時間、開発時間、メンテナンス時間など)を考えるとColdFusionを使う方が安くできます。
(HTMLに似た言語なので、わかりやすい)

 

社内で内製化するということは、メンテナンスにしても社内で行います。

 

日本では数年たってメンテナンスしようと思っても、外注化したものであれば、見積もりとって、下請けに発注など。長期的にはコストが増えると思います。

 

そう考えると、内製化してトータルコストを安くするには、ColdFusionがいいようです。

一般企業のIT社員が多いアメリカでは、ColdFusionは、よく利用されていると思います。

まとめ

アメリカでColdFusionが使われているのは、社内でシステムを作ることが多いからであろう。社内で効率よく作れば作るほど、コストが低くおさえられ、社内なので、メンテナンスもすばやくできる。

 

かたや日本は、外注が多く、安く発注したとしても、プログラミングの技術が高いかどうかわかるわけでもなく、

長年使ったシステムの修正や改修する場合は、同じ業者に発注できるかどうかも、わからず、

外注すれば、会社の資産としてのノウハウができるわけでもなく、

短期運用のシステムなら安ければよいが、長期的になりそうな場合は、メンテナンスこみでコストを考えないと、結局トータルコストは高くなる、と思う。

 

社内で内製化してメンテナンスも行うなら、トータルコストが安くなるColdFusionがおすすめ。

某企業に約10年常駐した感想

ColdFusionのプログラマーとして約10年、某企業に常駐した感想です。

以下の3段階に分けてみました。

 

初期:常駐を始めてから3年
中期:3年目から8年
後期:8年目以降

初期

初めて常駐した時は、某企業にはColdFusionはありませんでした。海外にいた人がColdFusionを知り、日本に帰国してColdFusionを採用しました。

 

また日本ではWebアプリという考え方は理解されておらず、担当の上司は、

「エクセルファイルをネットのどこかにおいて、それをうまく共有するしくみを考えたい」

という話が先にありましたが、担当によって、

「ColdFusionとデータベースの連携で情報共有しやすい」

と、上司が理解し、それで運よく?常駐作業することになりました。

 

簡単な登録・訂正・削除・照会処理を見せたところ、思ったより早くできたので、満足されました。

 

ある程度実績を積んでくると、ちょっとした規模のシステムを依頼されました。納期が特にありませんが、仮に「Aシステム」としましょう。仕様はColdFusionを紹介した担当者が作成し、プログラマーは私一人。半年ぐらいかかりました。

 

営業の力もあって、徐々にいろんなお客(取引企業)が使い始めました。

中期

「Aシステム」については、部分的に顧客専用プログラムも追加されていきました。
さらに、「Aシステム」を土台に、取引量が多い顧客専用システムを作りました。
この「Aシステム」によって、ColdFusionのプログラミングのしやすさが理解されたかもしれません。

 

その他、いろいろなシステムも作られていきました。もちろんColdFusionで外注します。

企業間取引も行うので、EDI(Electronic Data Interchange)もColdFusionで行います。

 

例えば、ある会社のシステムで、データをCSV形式などて、FTPで配信し、そのデータを定期的にシステムに取り込む、などです。

 

他社のシステムと通信することで、自動化が進んでいきました。

後期

大小合わせて100システム以上作られました。これほどシステムが増えることは予想できませんでした。

 

問題はCTOというか、技術的に取りまとめる人がいなかったこと。

ColdFusionで外注しても、作り方がばらばらで、メンテナンスするにしても、数年たったものは外注先ではしづらいようです。

 

結局、常駐している私のようなものが、メンテナンスすることとなりました。

 

中にはひどいソースがあって、変数名は意味のないaとかbとか多用していたり、まずは全体を理解してから修正とか、とんでもない状況でした。

 

個人的には、開発効率は初期の頃より10倍以上(?)よくなっている感じで、

早くできるのはいいけど、暇になるのもイヤだし、
早くできると、「そんなに簡単なの?」と思われるかもしれないし、
かといって、時給があがっているわけでもないし、

などと、無駄に余計なことを考えたりしました。

 

最終的には某企業から契約終了ということでやめることになりましたが、あとに残った人は大変だろうと思いました。

まとめ

    • ColdFusionは効率的である(ひいき目)
    • 社内で広まる前に、コーディング規約やプログラムの作り方は統一していたほうがよい
    • とりまとめる人は必要(規模が大きくなる場合)
    • メンテナンス要員も必要である

個人的総括

ColdFusionは開発効率がいいですが、大規模になれば、それなりに管理コストが発生します。

また、大規模になったがゆえに、ColdFusionから他の言語に変えた事例もあります。

Webサービスが当たると、いずれ返済できない技術的負債に突入する由々しき構造について

 

おすすめは、個人や中小企業が、ちょっとしたシステムを作るレベルがよいと思いました。

 

Webアプリというと、画面でいろいろ処理するものと思われるかもしれませんが、画面処理はなくても、例えば定期的にメールチェックして、まだメールがこない人宛に催促メールを出すなど、メール関連の処理は、なにかと便利かもしれません。

 

実は作る方としては、画面インターフェースやデザインを気にしなくていいのですごく楽です。

 

あとは、このサイトを通じて、ITリテラシーを高めて、ColdFusionを使って自動化の方法など、いっしょに考えていければいいなぁ、と思います。

 

中小企業でも、多少はITに関することを知っている人材がいないと、発注するにしても、ある程度の見積もりを想定できるかどうかで違ってきます。

 

一番いいのは、自社内で作ることで、社内ノウハウも蓄積され、修正・改善もすばやくできるので、これが理想的です。
それをColdFusionを通じて、身につけるとよいと思います。

 

ColdFusionもあくまでも道具なので、よりよい言語がでてくれば、それを利用すればよいです。

ColdFusion以上に簡単で便利なものがでてくれば、私も浮気するかもしれません。

 

または、適材適所で、開発言語を使い分けてもいいと思います。

 

ちなみにColdFusionで、iPhoneアプリやアンドロイドアプリも作ることができます。その場合は、ColdFusion Builderという統合開発環境が必要ですが、たぶんこれから先も便利なものが盛り込まれると思います。

 

というわけで、個人・中小企業が、簡単・楽に自動化できるColdFusionで、いろいろ作ったりしたいと思います。

 

  • このエントリーをはてなブックマークに追加
  • 人気ブログランキング
最近の投稿
カテゴリー
タグ
アーカイブ
プロフィール