この数年で、情報システムの内製化に関する話題が確実に増えてきました。
日経コンピュータや日経情報ストラテジーを始めとする、主に上流工程やユーザ企業向けの情報システム専門誌に関しては、何からの形で毎号のように内製化の話題が取り上げられています。
こんにちは。
ライジングサン・システムコンサルティングの岩佐です。
昨今、システム開発の内製化が注目を浴びる背景には、何よりもビジネス環境の変化に俊敏に対応できる、よりスピーディーなITソリューションの調達といった強いニーズがあります。
私達は、このシステム開発内製化の開発プラットフォームとして、FileMaker®プラットフォームを推奨しています。
FileMakerプラットフォームは、Apple Inc.の100%子会社であるFileMaker Inc.が開発・販売しているリレーショナル・データベースアプリケーション開発プラットフォームです。
FileMakerの累計出荷ライセンス数は1,800万以上にのぼり、フォーチュン 100 企業の 70 社以上、フォーチュン・グローバル 500 企業の全社、米国の大きい順に数えた 250 学区のそれぞれ、さらに世界中のトップクラスの大学で導入されています。また、日本においても一部上場企業から、マイクロカンパニーレベルの中小企業まで幅広い層で支持されています。
これだけのライセンスが出荷されており、そして多くの企業で利用されているということは、FileMakerプラットフォームが企業ニーズに応えることができる何よりの証拠になると思います。
しかし、一方でFileMakerと聞くと、「エンドユーザ向けの小規模開発ツール」「カード型データベース」「制限が多すぎて企業レベルでは使えない」といった評価をよく耳にします。しかし、この評価はFileMakerプラットホームの黎明期であった十数年前の話です。そして、現在のFileMakerは、まったく別次元の高速アプリケーション開発(RAD)プラットフォームに変貌しています。
実は我々自身も、FileMakerプラットフォームに対してはかなり過小評価していました。そもそも我々も数年前までは、一般的な開発プラットフォームであるSQLServerに.net系の言語を使った開発を推奨していました。
それが様々な御縁から、FileMakerプラットフォームを用いた開発を手がけるようになりました。そして、現在では、ほぼ全ての開発をFileMakerプラットフォームのみで行っています。よほど特殊な要求が発生しない限り、他の開発言語が必要になることはありません。
そして私達は、大小様々な開発プロジェクトを経験させていただく中で、FileMakerプラットフォームが持つ潜在能力について、非常に高く評価するようになりました。そのきっかけが、弊社における最大規模の開発事例である株式会社アクア・グラツィエ様の基幹システム開発プロジェクトです。
このシステムは、購買管理・顧客管理・販売管理・在庫管理といった一般的な基幹系システムの機能を一気通貫で実現しています。そして、各サブシステムの情報が密接に関連し合いながら、基幹業務全体を総合的にサポートするシステムです。お客様にとっては、このシステムが無ければビジネスそのものが成り立たないというほど、重要なシステムになりました。
このシステムは、２台のFileMakerServer（RDBMSサーバ）で構成されています。さらにサーバへの同時接続数は常時150〜200クライアント、データベースの総データ量は数100GBレベル、そしてビジネス・アプリケーションとしての機能性に関しては、これまで私達が経験してきた他のプロジェクトと比較しても、同等レベルか、もしくはそれ以上の機能性を兼ね備えています。
私達自身、このレベルの要求に対してFileMakerプラットホームがどれだけ対応できるか、正直不安な部分もありました。しかし、その不安は、完全に解消されました。そして現在においては、「まだまだ余裕で、より高度で複雑な要求にもお応えできる」という自信に変わりました。
しかも株式会社アクア・グラツィエ様は、東証一部上場企業である株式会社ツカダ・グローバルホールディング様の連結会社です。つまり、上場企業レベルの基幹システムにも対応できるだけの能力をもった開発プラットフォームなのです。
目次
システム内製化にFileMakerを推奨する７つの理由
企業がシステム開発の内製化を検討する場合、その開発プラットフォームを何にするかは極めて重要な意思決定要因のひとつです。
まず内製化の開発プラットフォームを検討する場合、一般的なシステムの受託開発会社とは違った視点で開発プラットフォームを評価する必要があります。
ソフトウェアの受託開発企業は、開発活動そのものが収益に直結するため、より高度なアプリケーションを開発でき、あらゆる要求に応えることのできる技術的な視点がその評価ポイントとなります。
しかし、システムの内製化という文脈では、そういった技術的視点以上に、技術的なハードルの低さや開発環境を構築・維持していくためのトータル的なコストといった別の視点を持つ必要があります。
しかしこういった視点で開発プラットフォームを評価している情報は極めて少ないのが現状です。
そこで、私達がFileMakerプラットフォームをシステムの内製化に推奨する理由を、次の７つの観点から考察してみました。
理由1：技術獲得コストが安価である。
まず、社内に技術者を抱えようとした時に、その教育コストを無視することはできません。ITトレンドのスピードは非常に早く、最新の技術を遅滞なく習得するには、やはり相応の教育が必要です。そして、その教育には当然ですがコストが伴います。
これを最小限に押さえるには、極めてシンプルな技術体系のツールを採用すべきです。そして、そのツールとして私達は、FileMakerが最適だと考えています。
一般的な開発プラットフォームの技術獲得コストが高価になってしまう理由のひとつは、アプリケーション開発ツールの断片化です。
Microsoft Visual Studio や Oracle Developer Suite のように、通常はコード編集ツールからビルダー、データベース接続のためのミドルウェアまで数多くの ツールを組み込んだ総合開発環境を購入し、それらの使い方を習得しなければなりません。また多くの場合、標準的な開発環境・ツールのみで要求を満たすことは困難です。その為、追加のサードパーティ製プロダクトを必要とするケースが発生します。
MySQLやPHPといったオープンソースソフトウェアに関しても同様のことが言えます。オープンソースそのものは基本的に無料であり、それが理由でこれらの開発環境を導入するケースは多々あります。しかし、技術獲得コスト、そしてその技術力を維持していくための中長期的なコストに着目するとどうでしょうか。オープンソースの利用は、トラブル対応・ツール自体のバグ対応まで、全て自己責任が前提です。これに対応するためには、極めて高度な技術力が要求されます。
つまり現在普及している一般的な開発プラットフォームでは、アプリケーションの開発を開始するまでに習得しなければならない技術的な事柄が多すぎるのです。これでは、いつまでたっても実質的な価値を生み出すアプリケーションの開発に着手することができません。企業としてみれば、「学んでいる時間」は、まだ何も価値を生み出していない、いわば潜在的な負債が積み上がっている状態です。
一方、FileMakerプラットフォームの開発において、最低限習得しなければならない技術は、一般的な開発プラットホームと比較すると、数分の１程度です。これは、FileMakerプラットホームがビジネスアプリケーションの開発に特化していることが最も大きな要因です。
一般的な開発プラットフォームは、「汎用的」な開発言語なので、それを用いてビジネスアプリケーションの開発も可能ですし、ゲーム開発も可能ですし、組み込みプログラムを開発することも可能です。これは「いろんなことができる」という安心材料であると同時に、「学ぶべきことが多岐にわたる」ことの裏返しでもあります。
確かに、一般的な開発プラットフォームと比較すると、FileMakerプラットフォームで対応できることは限定的であることは事実です。例えばFileMakerでゲーム開発をすることはできません。一方、世界的に最も多くの開発者のいるJavaであれば、ビジネス・アプリケーションもゲーム開発も両方に対応できます。そういった意味でFileMakerの機能は限定的であると言えます。
しかし、限定的であるということは、それだけ習得しなければならない技術も少なくて済むということになります。
システムの内製化には、高度なアプリケーションを開発できるプラットフォームが必要なのではありません。重要なのは、ビジネス上の問題を解決するためのアプリケーションを素早く構築するための最低限の機能が備わっていることが重要なのです。
理由２：小さく始めて大きく育てる開発が容易
FileMakerプラットフォームでは拡張性を意識した設計を行えば、機能拡張を容易に行うことが可能です。実際、先に上げた我々の開発事例においては、初回リリースから数年が経過した現在においても、有益な機能が次々にリリースされています。この新機能は、多い時には１〜２ヶ月で10以上の機能がリリースされることもあります。
これは内製化を検討する企業にとって極めて重要なことです。内製化の最も大きな目的は、ビジネス環境の変化に対して、既存システムを俊敏に対応させることです。そのためには「小さく始めて大きく育てる」アプローチが極めて重要です。
アプリケーションの開発が始まって、実際に利用を開始するのが半年・１年後というのでは、内製化の意味が全く無くなってしまいます。その為にも、小さくはじめて大きく育てることに長けた開発プラットフォームを選択することは、極めて重要です。
私達は過去、様々な開発プラットフォームでアプリケーションの開発をしてきました。そして、この「小さく始めて大きく育てる」は言うほど簡単にできるものではありません。これを実現するには、技術者のウデもさる事ながら、それを可能とする開発プラットフォームが絶対に必要となります。
その点、FileMakerプラットフォームで開発したアプリケーションは、実データとデータベース構造、そして業務ロジック（プログラム）が一体化していることが、俊敏かつ継続的な拡張を容易にしている要因のひとつとなっています。
なぜ一体化していることがメリットとなるのでしょうか。それは、アプリケーション全体の構造をメカ的に解析できるからです。FileMakerは、RDBMSであると同時に、一種の設計リポジトリでもあります。FileMakerProAdvancedに付属する解析ツール（データベースデザインレポート）を利用すれば、どのテーブルのどのフィールドが、プログラムのどこで、どの様に使われているのかをメカ的に追跡することができます。
この解析機能は、俊敏かつ継続的な拡張を実現する上で極めて強力な武器となります。
既存システムに対する新機能の追加、及び修正に関する影響範囲の調査は、システムの継続的な拡張において、常に付きまとう問題です。しかし、FileMakerプラットフォームで開発されたアプリケーションであれば、その面倒な問題を難なく解決してくれるツールが標準で付属しています。
このリポジトリ機能無しに、俊敏で継続的な拡張性を実現するのは極めて困難でしょう。
理由３：iOS/Webアプリケーションを素早く開発できる。
今や日本企業の半分以上は何らかの形でタブレット端末・スマートフォンを業務利用しており、その内の４割をiOSデバイスが占めています。内製化を始める際に、これらスマートデバイスアプリの開発は、ハードルの高い問題のひとつだと思われます。
そして、この問題もFileMakerプラットフォームを選択することで、簡単に解決することができます。
FileMakerプラットフォームには、FileMakerGoという製品ラインナップがあります。このFileMakerGoは、iOS（iPhone/iPad）上で、通常のデスクトップアプリケーションをFileMakerで開発するのと全く同じ言語で対応することができます。iOSアプリケーションを開発するために、別の言語や別の開発プラットフォームを修得する必要はありません。
また、FileMakerは「１ソース・マルチデバイス」を実現しています。その結果、スマートデバイス用に最低限のコードを調整するのみで、デスクトップアプリケーションとして開発したものを、iOSアプリケーションとして移植することができます。
少し想像してみてください。
現在、あなたの会社には、スマートデバイスに対応することで、新たな価値を生みそうな既存のソフトウェアがたくさんあると思います。もしくは、iPadやiPhoneに簡易的な自社専用アプリを乗せて運用するだけで、大きな改善効果を発揮するアイデアがたくさんあるのではないでしょうか。
そんなソフトウェアを、デスクトップアプリケーションを開発するのと変わらない技術で開発できたとしたら、そしてそれが極めて短時間で実現できるとしたらどうでしょうか。私達はFileMakerGoが発売された時の感動を今でもハッキリと覚えています。
さらにこれはWebアプリケーションにも言うことができます。
最新のFileMakerプラットフォームには、WebDirect（ウェブ・ダイレクト）という素晴らしい機能が搭載されています。
これは、デスクトップアプリケーションとして開発した機能を、そのままWebアプリケーションとして公開することができる機能です。こちらについても、「１ソース・マルチデバイス」がサポートされています。なので、最低限のコードを調整するのみで、デスクトップアプリケーションとして開発したものを、Webアプリケーションとして公開することが可能なのです。
例えば、あなたの開発したシステムを、パートナー企業にも使ってもらいたい時、わざわざその会社のPCにFileMakerProをインストールする必要はありませんし、その部分だけを、別の開発プラットフォームで開発し直す必要もありません。
適切なセキュリティ設定が施されたFileMakerServerをWeb公開すれば、パートナー企業のスタッフは、Webブラウザからあなたが開発したソリューションを利用することができるのです。
理由４：他言語、他サービスとの連携が可能。
FileMakerプラットフォームを敬遠するひとつの理由として、私達がよく耳にするのが、「ユーザから要求されたことがFileMakerで実現できない可能性があるから…」という理由です。しかし、これは多くの熟練技術者が陥る罠のひとつでもあります。
心理学巨匠、アブラハム・マズローの名言に、次のような言葉があります。
「ハンマーしか持っていな人には、問題が全て釘にしか見えない」
FileMakerで全てのニーズを満たそうとすることはあまり賢い選択ではありません。つまり、全ての問題はハンマーで叩くことで解決する必要は無いということです。
FileMakerにできないことや不得意なことは、その部分だけ、他の開発言語やサービスと連携して要求を満たすことができます。例えばFileMakerからWebサービスを呼び出して結果を得たり、BIアプリケーションと連携してビッグデータの分析を行うといったことは比較的簡単に実現可能です。
また、FileMakerにはプラグインというFileMakerにない機能を拡張する機能がもともと備わっています。例えばFileMakerで開発するアプリケーションで電子メールを受信したい、もしくはSOAPで公開されたWebアプリケーションと連携したいという要求も、それを実現するプラグインを使うことで簡単に実現することが可能です。
実際我々で開発をする時も、幾つかの定番プラグインには常にお世話になっています。
また、他言語・他サービスとの連携が容易であるということは、内製化のポートフォリオを計画する上でも極めて重要です。ポートフォリオとは、自社システム全体の、どの部分を内製化し、どの部分をアウトソーシングするかという意味でのポートフォリオです。
例えばFileMakerプラットフォームで企業内システムの8割をカバーし、それ以外の２割をアウトソースベンダーと協業するという選択も十分に実現可能な選択です。
もしくは、極めてミッションクリティカルなバックエンドシステムはERPやパッケージシステムで実装し、頻繁な修正や拡張が求められるフロントエンド部分をFileMakerで実装するといったポートフォリオの組み方も可能です。
もちろん、FileMakerプラットフォームのみにフォーカスした場合でも、開発が困難な部分のみを私達のような経験豊富なプロの技術者にアウトソーシングする。そして自分たちで開発できる部分は内製化するというポートフォリオの組み方もできます。
実際、私達はそういった支援を行っています。
例えば、iPhone/iPadでオフライン時でも利用可能なアプリケーションを開発する場合、データの同期という機能を実装することが必要です。しかし、安定的に稼動する同期機能を実装することは技術的なハードルが極めて高いのです。
なので、この同期部分のみを私達にアウトソーシングいただき、それ以外の部分は自社で内製する…といったプロジェクトを支援させていただいた経験がございます。
また、医療業界においては、レセプトや電子カルテといったバックエンド機能は専用のパッケージシステムで実現し、そのフロントエンドとしてFileMakerを適用するといった使われ方も一般的に行われています。
内製化の目的はFileMakerプラットフォームですべてのアプリケーションを開発することではなく、収益性を向上するためのアプリケーションをより素早く、より経済的に開発・運用し、継続的に改善・拡張していくことで、企業経営に貢献することです。
その本質的な目的を達成するためには、最適なポートフォリオを組むことが極めて重要なのです。
その最適なポートフォリオを組むためには、内製化に使用する開発プラットフォームが、他のシステムと柔軟に連携できる必要があります。そしてFileMakerプラットフォームは、他システムとの連携の容易性を十分に満たしているのです。
理由５：クラウドコンピューティング環境での運用が可能。
現在のビジネスシーンにおいて、クラウドを外すことはできません。FileMakerプラットフォームは、このクラウドコンピューティングにも対応することが可能です。
現在はAmazon Web Serviceをはじめとして、パブリッククラウドサービスがかなり安価な金額で利用可能になりました。このパブフィッククラウドサービスの低価格化と選択肢の増加により、FileMakerServerの導入が極めて素早く、そして安価に実現できるようになりました。
Windows Server やネットワークに関しての初歩的な知識のある技術者であれば、サーバ構築作業開始から2〜3時間後にはFileMakerServerがクラウド上に構築することができます。このスピード感は、内製化の最も中心的な目的である開発スピードの向上に無くてはならない要素であり、FileMakerを内製化の中心に据える大きな理由にもなるでしょう。
また、クラウドコンピューティングに対応できるということは、海外への事業展開においても大きなアドバンテージとなります。
例えば弊社における開発事例で、世界10数か国に現地法人や営業拠点のある企業様での事例があります。
こちらの事例では、NTTコミュニケーションズが展開するパブリッククラウドサービスにFileMakerServerをインストール。FileMakerプラットフォームで開発したアプリケーションをクラウド上に展開できたことで、開発着手から数週間で、世界中のブランチオフィスから利用可能なアプリケーションをリリースすることができました。
このスピード感は、クラウドコンピューティングの有用性を示す解りやすい事例のひとつだと言えます。これがクラウドに対応出来ない場合、各国のブランチオフィスとの仮想専用線網（VPN網）の構築など、インフラの整備だけで恐らく数百万円以上のコスト、そしてインフラの整備だけで半年から１年程度の時間を要していたと思われます。
それが、月々２万円程度のクラウドサーバ費用のみ、そして開発着手から数週間という極めて短期間でアプリケーションのリリースが実現できました。
もちろん、パブリッククラウドに展開する社内アプリケーションなので、セキュリティに関しても万全の対応が必要となります。そして当然、FileMakerプラットフォームはその点についても強力な機能が備わっています。FileMakerサーバとクライアント間の通信はSSLで暗号化することが可能であり、またデータベースの内部情報そのものも極めてセキュアなアルゴリズムで暗号化することが可能なのです。
理由６：コーディングの量が極めて少ない。
FileMakerプラットフォームでアプリケーションを開発するときは、JavaやPHPといった開発言語は使いません。その代わりに「スクリプト」と呼ばれる専用言語を使用します。これは、ExcelやAccessを用いてアプリケーションを開発する場合に使用するVisualBasic for Application（VBA）と似たような考え方です。
しかし、VBAと比較するとFileMakerにおけるスクリプトのコーディング量は圧倒的に少ないです。これは私達が過去に数多くのVBAを用いたアプリケーションを開発してきたので、確信を持ってお伝えすることができるFileMakerプラットフォームのアドバンテージのひとつです。
FileMakerはビジネスアプリケーションを開発するためのツールなので、それに必要のない機能はごっそりと削ぎ落とされています。
例えば一般的な開発言語であれば、まずデータベースに接続するためのオブジェクトを生成するコードを書き、次にデータベースへの接続を試みる。この時に接続がNGとなれば、エラーハンドリングクラスにその制御を渡すコードを記述する。もしデータベースへの接続がうまく行けば、次にレコードセットオブジェクトを生成し、それに対してSQLを発行してレコードセットを取得し…っといったコードを書くことが一般的です。
しかし、FileMakerプラットフォームでは、こういったコードを一切書く必要がありません。
FileMakerで記述するスクリプトの多くは、ビジネスロジックです。そして、このようなメカ的な制御ロジックは最低限の記述で済むように設計されています。例えばFileMakerスクリプトには「関連レコードへ移動」というスクリプトステップがあります。これは、一般的な開発言語で書く場合の数十行の動きを１行で記述することのできるという、開発者にとっては極めてありがたい命令です。
コーディング量が少ないということは、コードを書く時間、そしてテストの時間そのものが削減されるということもさることながら、他にも様々な恩恵に預かることができます。
具体的に、ソフトウェアエンジニアリングの世界には「技術的負債」という言葉があります。
これは様々な文脈で使われますが、簡単に説明すると以下のとおりです。
プログラムは書いた量が多ければ多いほど複雑になり、継続的な開発をスムーズに進めることが困難になる。このスムーズな継続的開発を阻害する要因を技術的負債と呼ぶ。
この技術的負債を最小化するには、リファクタリングや、オブジェクト指向言語による洗練されたクラス設計、及び自動テスト等、様々な手法があります。
しかし、技術的負債を発生させない最も有効な手段は、コードを書かないということです。
システムの内製化においても、この技術的負債と無縁でいることはできません。重要なのは、この負債を如何に最小化するかという具体的な解決策です。
そしてFileMakerプラットホームは、必要とされるコード量が絶対的に少ないので、この技術的負債の量が極めて小さいのです。これは技術的負債に対する極めて具体的な解決策です。
理由７：開発者コミュニティが充実している
FileMakerには、FileMakerInc.自身が運営するFileMaker Communityというオンラインコミュニティサイトがあります。こちらでは、FileMakerプラットフォームの開発者として必要なるiPad、iPhone、Windows、Mac、Web向けのシステムを開発・運用する方法に関する情報やリソースが無料で提供されています。また、このコミュニティサイトにはオンラインフォーラムが設けられており、日本語ベースで活発なやりとりがなされています。
さらに、北は北海道から南は沖縄まで日本全国にオフラインのコミュニティがあり、そこでは様々な勉強会が定期的に実施されています。このコミュニティには、世界的にも著名な開発者が多数参加しており、開発者同士の人脈を構築する上でも極めて重要な役割を果たしています。
システム開発の内製化において解決しなければならない問題のひとつに、より洗練された設計手法や開発手法などといった「暗黙知」に触れることのできる機会が限定されてしまう…という問題があります。
システム開発会社であれば、様々なプロジェクトを同時並行的に手がけ、技術者も多数抱えることになるので、こういった暗黙知に触れることができる機会も多数あります。
しかし、自社内の閉じた開発実績だけでは、やはりどうしても限界があります。
その限界を超えるためにも、自分たちより高度な技術を持った技術者と直接話ができる機会は極めて重要です。
自分たちが10の時間とコストをかけて実装していることを、プロであれば1とか2の時間とコスト、もしくはそれ以下の時間とコストで、同等以上の機能を実現することは、ソフトウェア開発の世界ではよくあることです。
そして本質的な問題は、1や2の時間とコストで実現できる手法そのものに目が行かない、そしてそういった手法の存在を知らないということです。
システム内製化の目的は、より早く、より経済的にシステムを調達し、それを120%利活用することで企業の収益性を継続的に向上していくことです。であれば、システムを素早く、経済的に実装できるということは極めて重要な事です。
その為にも、開発コミュニティが充実していると言うことは、自分たちの閉じた世界以外の技術情報を知る良い機会が充実しているということであり、内製化に取り組む企業においては極めて有用な情報源のひとつになるということです。
まとめ
この記事では、私達がFileMakerプラットフォームをシステム開発の内製化ツールとして推奨する、以下７つの理由をご説明しました。
理由1：技術獲得コストが安価である。
理由２：小さく始めて大きく育てる開発が容易
理由３：iOS/Webアプリケーションを素早く開発できる。
理由４：他言語、他サービスとの連携が可能。
理由５：クラウドコンピューティング環境での運用が可能。
理由６：コーディングの量が極めて少ない。
理由７：開発者コミュニティが充実している
冒頭での述べた通り、システムの内製化という文脈においては、システム開発を専門に請け負う企業とはまた違った視点での評価指標が必要です。そして、そういった視点における評価基準が示された情報は極めて少ないのが現状です。
この記事が、あなたの検討材料として有益な情報であれば幸いです。
※このブログ記事を読まれた方は、こちらの記事もおすすめです。
