概況
前会計年度(2006年4月～2007年3月)の売上高は過去最高の756,102,838円(前期比7.1%増)となりました。
ニューメリカルテクノロジーズ株式会社の業績推移 (単位：百万円)
例年この決算概況欄で申し上げておりますように、当社財務の特徴は単純さ、非常にわかりやすい(＝会計上の操作性がない)経営です。 当社は創業以来黒字基調で累積損失がなく、取り崩しあるいは評価替えが必要な在庫がなく、評価損を出すような固定資産も、のれん代償却を要する買収会社も、売上や利益付け替えを出来るような連結対象会社も非連結関連会社もなく、100%自社開発で外注先も存在しません。 これほど単純な会社では、近年話題の架空売上計上どころか、合法的節税策すら選択肢がほとんど存在しません。 したがって売上増はストレートに利益増につながります。 もしも当社が上場会社であれば利益増は配当増(＝利益は社外流出する)で良いことですが、当社は非上場会社かつ無配当(＝利益は社外流出しない)であり、創業から9期連続黒字決算でしたから自己資本も厚い(＝つまり内部留保の積み上げは必要ない)企業です。 人目さえ気にしないならば損益ゼロが理想、したがって過大な利益増は納税額増＝資本回転率低下を意味する反省材料になります。
当社の業務内容を分析しますと、システムプロジェクトの平均的な資金回収期間が約1年であるために、1年先の出来上がり業績を概ね予想できます。 当然ながら本決算内容を予測した1年前から将来を見据えた投資と償却・除却促進(＝設備投資だけでは現預金が固定資産に振り替わるだけで財務的には意味をなさないため)を行い、利益つまり予定納税額圧縮を試みました。 その効果はあったものの、前期決算時の予測よりも売上額が若干上ブレした分が反映されたために、出来上がりの利益水準はグラフに示す通りになりました。 当社の租税負担率は実に47.6%に達します。 他方、健全性諸比率に目を転じますと、連続黒字決算を映してさらに数値が向上しています。 流動比率(流動資産／流動負債)は904.5%、有利子負債比率は0%(無借金)、自己資本比率(株主資本比率)は89.7%、固定資産比率(有形固定資産／自己資本)1.5%、となっており、しかも負債勘定は100%が未払法人税等の流動負債で実質的な負債もゼロという、超健全な状態にあります(「コラム：財務の健全性諸比率について」参照)。 創業から10年目となる今期については、前期受注分が反映されるため、自然体ならば前会計年度とほぼ同水準の売上高で着地するものと予想しております。 経費面については抑制的に運営しつつも、外部環境が安定的であることから、研究開発投資とともに将来を見据えた投資を積極的に行いたいと考えております。 また、引き続き自然体での決算着地を心掛けたいと思います。
なお、民間企業信用情報会社に対する当社からの財務情報開示は2006年3月期決算を最後にして行っておりません。また民間企業信用情報会社から今後接触を受けたとしても財務情報の開示は致しません。 この方針は、2006年4月1日の法改正「所得税法等の一部を改正する等の法律」施行により法人税を含む公示制度が廃止されたことに合わせる形で実施しました。 したがって、株式会社帝国データバンクと株式会社東京商工リサーチなどの民間調査会社から得られる当社の財務情報は各社による推定値か、または本欄に記載された数値およびグラフから転記されたものです(「コラム: 格付け冬の時代到来？ – 企業信用情報データベースの現実」参照)。 当社と直接取引のあるお客様、取引をご検討のお客様に対しては、当社財務諸表を個別に開示致しますので直接ご請求くだされば幸いです。
当期売上高
756,102,838円
昨年度の売上高には、信用リスク管理製品 CreditBrowser®と、ALM(資産負債管理：アセット・ライアビリティ・マネジメント)製品 Numerical Technologies Altitude®が貢献しました。 CreditBrowser®は当社が創業以来手がけている製品であり、我が国の大手金融機関、メガバンクの大半で導入して頂いているもので、最近もBasel II対応やCDO対応などのバージョンアップを重ねて、言わばライフワーク化しています。 また統合リスク管理システム製品 PortfolioBrowser®も引き続き売上増に寄与しています。当社は大手の金融機関から直接受注して製品開発を行うパッケージソフトウェア業であり、販売商品は自社開発ソフトウェア製品です。 外部のシステムインテグレーターを介した契約はなく、仕事の外注も行っておりません。 従って仕入れも在庫も基本的に存在しないため、販管費の大半は人件費が占めております。
資産の状況
金融資産については安全性と流動性を重視し、普通預金と円建ておよびドル建てのMMFに分散して保有しております。 定期預金、運用目的の長期資産、節税目的の保険資産は一切保有しておりません。 固定資産は大半がコンピュータのハードウェアです。 すなわち、当社資産は超短期かつ流動性のきわめて高い資金ポジションになっております。
資本の状況
資本金 50,000,000円 + 準備金 118,822,563円
資本勘定の118,822,563円は法令に定めるプログラム等準備金です。 租税特別措置法第20条の2第1項及び第57条第1項の表の第1号の中欄のロに規定する汎用プログラム(制御プログラム以外のもの)として、情報処理振興事業協会にソフトウェア登録。 登録番号25295。 登録年月日 平成11年2月28日。 このプログラミング等準備金については法令改正(廃止)が決まっており、当社では2004年3月期決算から逐次取り崩しております。 株式保有状況については、当社の取締役3名が当社株式を100%保有しており、外部との資本関係は一切ございません。 当社は資本面で中立な企業です。
設備投資の状況
今日のリスク管理は装置産業でもあります。 高い開発生産性を維持し、顧客金融機関のニーズに応えていくためには自社保有システムを強化していかねばなりません。 近年は金融機関の大型化が進んだ結果、顧客保有データと同等規模のテスト環境を整備するだけでも一苦労です。 特に負債サイドALMや日次シミュレーションを実現するためには、多大なハードウェア投資を必要とします。 このため、引き続き高水準の設備投資を行っております。
前期においては、ALM(資産負債管理：アセット・ライアビリティ・マネジメント)製品Altitudeのグリッド環境対応版開発を目的として、64bitマルチプロセッサ構成のブレードサーバーを新規に導入しました。 このグリッド対応版は最近第1号ユーザー向けに出荷したばかりです。 とはいえハードウェアの市場価格は漸次低下しておりますから、経費面における最大の費目は人件費であって、財務上の設備投資が占める割合は僅少です。 これは実質的に人への投資＝設備投資という、研究開発型企業に特有の体質です。
業務環境
当社の特徴
当社は自社内に研究開発リソースを持つ独立系システムベンダーであり、ALM・収益管理、信用リスク管理、市場リスク管理、オペレーショナルリスク管理をはじめとする金融ミドルオフィス系システム(＝金融リスク管理システム)を開発販売しています。 この種の難易度の高い金融系システムを提供する専門会社は、国内的にも世界的にも、金融機関からのスピンアウト組が中心となって設立した会社(例：米バーラ、加アルゴリズミックス、米RMG、日シンプレックス)か、同じ話題にひたすら長く取り組んでいるうちに気がつけば大きくなった会社(例：米QRM、日エックスネット)の、何れかに分類できるでしょう。 単に技術面が得意なだけで金融のノウハウを持たない企業、ノウハウを顧客金融機関から入手しては下請けソフトウェアメーカーに流す委託開発方式を繰り返すだけでノウハウが蓄積されない企業は、長い目で見ますと廃業していきます。
この分野では専門的なノウハウとともに持続的な研究を必要とします。 我が国に限った特殊性として、ゼネコン的な大手システムインテグレータ(例：IBM、富士通、NEC、NTTデータ、日立など)が存在します。 これらのシステムインテグレータは、外部の専門企業の製品を再販したり、特定の金融機関の内部開発に人員提供したり、あるいはサブスタンダードなマーケット(＝下位金融機関)向けの似て非なるディスカウントされた製品を提供する存在です。 つまりシステムインテグレータにノウハウがあるわけではありません。 専門家が集まる内外のカンファレンスに行きましても、プレゼンをしたり勉強をしているのは専門会社か金融機関の方であり、システムインテグレータの人は一時的なブームに乗って覗きにくる営業絡みのコンサルタントです。 しかも近年はまずお見かけしません。
また、10年以上も遡る昔にはコンサルティングファーム(例：当時のアンダーセンコンサルティングなど)が上流工程を引き受けるという開発形態もあったのですが、これはコンサルティング会社に関する誤解(＝当時はなぜか金融機関内にない高度なノウハウをコンサルタントが持ってきてくれると勘違いしている人が多かった)がなくなり、欧米におけるコンサルティング会社の実態がむしろ日本の大手システムインテグレータに近い人材派遣業であることが知られるにつれて、今や見ることもなくなりました。 金融ミドルオフィス系システムは基本的に、専門企業と一部の金融機関自身が支配しており、システムインテグレータとコンサルティングファームが人員提供の形で参画していると理解すれば正しいでしょう。
需要動向
近年は金融機関決算も好転しており、金融リスク管理も守りの話題から攻めの話題へと転じております。 例えば、旧来のVaR(バリューアットリスク)管理に収益性概念を加えてみてCPM(Credit Portfolio Management,クレジット・ポートフォリオ・マネージメント)に転じてみたり、仕組み債などの新商品を取り込んだりといった具合です(「コラム：新BIS規制(Basel II)が始まる」参照)。 その一方でリスク管理手法の導入については規制当局の目も厳しくなっていることから裾野が広がっており、需要は総じて堅調です。 当社が近年取り組んできた生命保険、損害保険業態のALM(Asset Liability Management,アセット・ライアビリティ・マネージメント)に関しては、個別保険契約を全数再評価する規模のシステム実現が現実に可能であると理解されるにつれて、こちらも採用実績を伸ばしております。
今期の方針
前期である「平成18年3月期決算概況」の本欄には、「現在の受注水準はレッドアラートとは言わないまでも黄信号であり、売上高7億円の業績は相当な重荷」、と書きました。 実際ホームページの更新もおろそかになるくらい忙しかったのです。 今期もまた仕事は多くあり、おそらく来期(＝2年後)も同程度の売上水準はありそうで多忙には変わりがないのですが、徐々に我々も「慣れ」が出てきており若干の余裕が感じられます。 こんな時こそ先を見据えた研究開発を行うべきだと考えます。 今期計画しているのは金融工学ではなくシステムアーキテクチャに関係するものであり、2つあります。
- 第1の計画はグリッドコンピューティング対応です。
- 第2の計画は当社製品のオンラインサービス対応です。
以下ではこれら2つの計画について記します。
グリッドコンピューティング対応
現時点で当社はALMシステムAltitudeのグリッド対応製品を出荷済みであり、お客様環境ですでに稼働しております。 すなわち、この第1の計画とは当社にとっては開発済みの製品をより大規模な形態で大手金融機関向けに提供していく、営業面の計画です。 顧客金融機関においては、デュレーションの長い保険資産の大規模ポートフォリオの評価や、銀行業における数百万件規模の資産負債ポートフォリオの日次長期間モンテカルロシミュレーションといった、これまでの常識からすれば信じがたい規模の計算が可能になります。
長年当社のことをご存じの方から見れば、「長年大量の計算を必要とするアプリケーションを提供しており、元々並列処理が得意とする当社が、なぜ今までグリッド対応に消極的であったのか」、との疑問を抱かれるかもしれません。 その理由は、当社が2004年11月30日に行った講演の中でも部分的に解説しました(“VaR、EaRシステムの現状と将来 (前編)”, 東京工業大学理財工学研究センター主催シンポジウム「信用リスク管理の実務と理論」の講演資料、15ページから17ページ)。 より具体的に申し上げるならば、金融系のグリッドと、学術系あるいは工学系のグリッドとは、次に示す諸点においてまったく別物であるからです。
金融系グリッドで使用するアプリケーションは確立されていない
学術系のグリッドはそれこそ何十年も歴史がありますから、有限要素法はLS-DYNA、量子化学計算ならばGaussian、といった具合に定番のアプリケーションがあります。 それ以外の場合も多くは線形代数用途ですから、歴史の長い線形代数ライブラリBLAS、そして並列処理のインターフェイスとしてMPI、を動かします。 そうは言っても、そこまで大学の先生方が自分でプログラミングするケースは例外であり、MPIの先まで低レベルなプログラミングを行うなどさらに例外になります。 学術系グリッドを使用する大学教授らも計算機科学系の一部を除けばコンピュータのエンドユーザーに過ぎずプログラミングに長けているわけではありません。 それでもアプリケーションは先に出来上がっているので、あくまで比喩ながらMicrosoft Officeを導入するような気軽さでグリッド環境に手を出せるのです。したがってグリッドを導入後に「こんなはずではなかった」となっても、それはアプリケーションの性能が期待ほど出ないという意味であり、致命的な問題に到るような開発リスクは通常存在しません。
他方、金融系グリッドではMATLABを単純に使用するケース、オラクルデータベースを動かすクラスタ環境(＝データグリッドという営業用語がある)、そして当社提供製品のような汎用製品を使うケースを除けば、都度開発となります。 いくら優秀なエンジニアを投入したところで、学術系ならば10年を越える時間をかけているところを1～2年の委託開発プロジェクトで専用アプリケーション開発する計画は無謀です。 したがってアプリケーション開発に失敗するリスクが伴い、またうまくいっているケースでも単にデータを分割して複数のコンピュータで回し最後にかき集めているだけ、つまり本当にグリッドが必要であったのか、安くて簡単なSMP(対称型マルチプロセシング)で頑張っておいた方が良かったのではないかと疑問に思うケースが少なくないのです。
金融系グリッドにかかわるエンジニアのスキルは低い
もちろん、学術系グリッドの場合は導入する側は大学や研究所ですから、大学院生を安価な労働力として活用できるでしょう。 地球シミュレータセンター級ともなれば、メーカーの面子もあって若くて優秀なメーカー出向エンジニア(＝研究生)をつけられるかもしれません。 ですが、それ以外にも金融系グリッド構築が低スキルで行われてしまう理由があるのです。 前項で指摘したように学術系や工学系ならば、ある使用目的に関する第1号ユーザーになるケースは通常ありません。 だから目標性能は明確であり、手抜きがあっても見抜きやすいと言えます。
ところが日本の金融機関の場合、システム部門は予算策定、プロジェクト管理、保守運用の部門であって開発要員はいないのです(なお欧米の金融機関は単一の人事部制度になっていないので必要な部署には開発要員が本当にいる)。 システム部門の出先にはシステム子会社(総合研究所という業務実態から縁遠い名前がついていたりします)に実働人員がいるものの、HPC(High Performance Computing、ハイ・パフォーマンス・コンピューティング)の経験などありません。 そしてユーザー部門、ここには優秀な理系人材が配置されはするものの、開発経験が多少あったとしても大学院時代に少し触ってみたという程度であって所詮は学生レベル、いわゆる「修羅場」を潜り抜けた経験は当然ありません。 大体、そもそもBLASの実装や数値計算法、最適化コンパイルそのものまで追いかけられる人材は、関連大学ならびに付属研究所クラスを探したところで、喜連川研ならばいざしらず、多くはいない。 そして何年かすれば転勤したり出向するのが金融マンです。 人生のキャリアをかけてグリッドをやる根性は当然ありません。
それで、比較可能な事例が少なく、導入側のスキルも乏しく、キャリアをかける意気込みもなく、開発予算だけ潤沢にあるとなれば、いきおい話はハードウェアメーカーの営業マンやシステムインテグレーターの自称コンサルタントのペースで進みます(「コラム：グリッドコンピューティングの経済学」参照)。 学術系の方が聞いたら笑ってしまうかもしれませんが、難しい問題があると「それはX社のYミドルウェアを導入して解決しましょう」と誰かが言って関係者一同思考停止になる。 自分で検証せず、ガートナーや日経ナントカのような調査会社のレポートを鵜呑みにする。 実は問題解決になっていないし、メーカー側エンジニアも、(おそらくわかっていないので)RAID構成やらネットワークポートのチーミングやらスパニングツリーといった、本質とは関係のない自分が得意な話題にばかり凝ろうとします。 もしかすると営業から「黙っているように」釘を刺されているだけかもしれません。 いずれにしてもメガバンク相手であろうと付き従ってくるメーカー側エンジニアは一般に二流であり、開発が始まってから遅まきながら問題に気づき、プロジェクトがどんどん遅延するパターンをよく見かけます。
金融系グリッドを失敗すれば責任問題になる
学術系でグリッドに失敗しても「研究に失敗はつきもの」で許されるかもしれません。 大規模グリッドの構築そのものを目的とする研究であれば稼動さえすれば成功である、と私は思います。 ぜひリスクをとってどんどんやって頂きたい、それこそアカデミックの醍醐味ではないでしょうか。 しかし、これがビジネスの場であれば「責任問題」に発展します。
以上、歯に衣着せない言い方になりましたが、メーカーやコンサルタントの皆様、反論できるでしょうか。 民間ビジネスでの使用に耐えうるようなグリッドコンピューティングシステムとは、少なくとも次の図に示す要件を満たさねばなりません。
グリッドコンピューティング方式の実現課題(拠点内対応)
一見してわかると思いますが、同じくグリッドと言っても性能よりも運用に力点を置くのが学術系との違いです。 同じ東大情報科学科を出たとはいえ、地球シミュレータを抜き去って現在国内最速の学術系グリッドTSUBAMEを構築された東京工業大学の松岡教授と、民間それも金融業というテクノロジ面では未成熟な世界に出た私とでは、直面する課題が異なるのです。 私たちが最も気にしているのは、グリッド環境が要求する複雑な運用を隠ぺいする、特にアプリケーションレベルの耐障害性と保守容易性にあります(「コラム：グリッドコンピューティングの経済学」参照)。 数百ノード以上のグリッド環境を仮定しますから、低レイテンシのMyrinetやInfiniBandを当然使いたい(注：一般的なネットワーク機器は大量データ転送は得意でも多点間小パケット転送は不得意なので、数十ノードになっただけで細粒度の並列処理は性能が頭打ちになるため)。
しかし金融機関に出入りするインテグレータやハードウェアメーカーのエンジニアの質で大規模Myrinet環境をサポートできるか、そして故障率上昇にユーザーが耐えられるかを考えますと、これはちょっとした冒険です。 確かにメーカーは一見信頼おけそうなハードを出しているのですが、多くの現場のエンジニアは自社製品さえ「それなんですか？」というレベルにある。 そこでフィールドサポートエンジニアが場慣れしている汎用1000Base-Tスイッチを使い、しかも並列処理にとってカスケード接続は弱点になるとわかっていながら、大量出荷で信頼が置けるスイッチ(＝つまり現在ならば48ポート程度まで)のカスケードで構成せざるを得ない。 金融機関のマシンルームにいる普通の保守担当者を想像すれば、非GUIベースのLinuxばかりでなく、プログラマーにとっては厄介者でもエンドユーザーには優しいWindows OSを考慮せざるを得ない。 加えて金融機関のアカウントを持つ営業マンの質が最悪で、こちらはHPCの話題をしているのに、ブレードサーバN台ひと山いくらの感覚で見積もってきたりします。 メーカーの営業には段取りを含めて細かく指示を与えて機器構成する必要がある。 ここまでやれば不良率は下がり、メーカーのエンジニアのスキルが多少低かろうとシステムは稼働します。
しかし逆にアプリケーションの開発難易度は当然ながら上昇します。 特に学術系でよく使われる連立一次方程式ソルバーLINPACKのような、グリッドノード間で通信を頻繁に発生させるタイプの並列処理には向きません。 高いレンテンシを期待できないとなればアプリケーション側の並列処理の粒度を大きくし、ネットワークに流れるパケットを減らすしかありません。 ネットワークトポロジを意識したパケットフローを作る必要もあります。 結果、粒度の大きな計算をグリッドで行い、粒度の小さな計算はマルチコア、SMPで行うというアプローチ(fatコア方式という奴です)になります。 しかもこれを線形代数ではなく、金融つまり会計系のアプリケーションで達成しなければなりません。
アプリケーション利用者にとってのシステムダウン時間を非グリッド環境と同レベルに保つ必要もあります。 「こんなに故障が多くては業務に支障が出る」と言われないためです。 つまり、計算実行中のグリッドノード故障時における動的切り離し・再計算機能を付与する必要があります。 私たちは、この問題では早くにMPIを叩くアプローチに見切りをつけた上で、グリッドコンピューティングのミドルウェアを提供する各社、特に米データシナプス社と加プラットフォーム・コンピューティング社の製品を当社製品に組み込む方向について検討しました。 さんざん悩み、両社とは何度も接触しました。 結局、ミドルウェアに頼るだけではアプリケーション側のフォールトトレラント性は何も解決しないことがわかり、また外部依存によるベンダーリスクを増すとの判断で採用を見送りました。 こうしたアーキテクチャ上の決定においては、早くからグリッド対応を行っているMATLABの開発元米MathWorks社の実装方針など先行事例も参考にしました。 こうして当社製品のグリッド対応そのものは完成したのですが、ここまでしても金融機関内の複雑な人間関係力学を嫌というほど味わってきた我々としては、最初の冒険者になりたくありませんでした。 そこで、近縁異分野、特にフロントシステムにおける最近のグリッドの採用実績が伸びるまで待つことにしました。 今やグリッドコンピューティングに対してあれほど熱心であった独立行政法人 産業技術総合研究所のようなところの活動が下火になるのに反比例して、我が国の金融機関でも徐々にグリッドコンピューティングの採用実績が伸びています。
以上がグリッドコンピューティングのマーケティングに関して当社が”Go”とした理由です。 慎重すぎるでしょうか。私はそうは思いません。
グリッドコンピューティング方式の実現課題(拠点間対応)
オンラインサービス対応
もともとこの種の事業は、ASP(Application Service Provider, エーエスピー,アプリケーション・サービス・プロバイダ)という名前で10年ほど前に一時的なブームになりましたが、参入した各社の見通しの甘さ、未成熟な技術、深刻化するセキュリティ問題、があって大半がうまくいっておりません。 しかし近年環境が整うとともにASPは再び名前を変えて、SaaS(Software as a Service, サーズ, ソフトウェア・アズ・ア・サービス)の名前で復活しつつあります。 我々のような専門企業にとっては製品＝サービスですから、SaaSによって製品デリバリーが改善されるならば大変な魅力です。 すなわち、直接契約とデリバリーコスト減により圧倒的な低コストでサービスを提供できますし、また我々自身のメンテナンスにより遠隔地の金融機関に対するサービスも均質に提供可能になります(下図)。
オンラインサービスによる金融リスク管理の課題
このようにソフトウェアのサービス化が認められ、低コスト高品質が当たり前になってしまえば、システムインテグレータなど大手であろうと駆逐可能でしょう。 SaaSといえば現在は米セールスフォース・ドットコム社が有名ですが、当社の取り組みは、1)閉鎖的なネットワークである、2)Webインターフェースを仮定しない、の2点が異なります。 当社の顧客は金融機関ですから、上図に示す通り公衆につながるインターネット接続は存在しない方が望ましいと考えられ、したがって追加的な開発を行って閉鎖しているのです。 上図のスキームではハードウェアは当社が所有し当社がメンテナンスすることになります。 それでなぜ当社にとってのコスト減になるのか不思議に思われるかもしれません。 その理由は、最近のフィールドサポートエンジニアの質が大幅に劣化しているという業界事情にあります(「コラム： エンジニアの2007年問題」参照)。
このところ、自前でハードウェアを調達している大手金融機関の環境において、非常に馬鹿馬鹿しいメーカー対応のおかげでその場ですぐ直るはずのトラブルが半年間も長引く現象に頻繁に遭遇します。 障害対応に出てくるエンジニアの肩書きを持つ方々はとても一生懸命であり、人間的には好感が持てるし、配置転換で来られた方には同情もします。 が、残念なことにその質が問題なのです。 一頃に比べてとんでもなく技術力が低下、まるでファーストフード店の店員のようにマニュアル通りにしか動けない。 日本橋近辺のセミナーで学習した内容か、Googleで検索した怪しい知識に頼るばかりで、自社製品の最新機能さえ追えていなかったりします。
我々が見ていて問題なのは、熱心すぎる(しかしスキルの低い)エンジニアが、手に余る仕事を抱えていながら(自分ではそれがわからなくて)仕事を手離さないケースです。 これがひと昔前ならば同じ会社の同僚か上司が代わりに白旗をあげるなりタオルを投げてあげたもの。ところが、最近は皆自分のことに一生懸命で他人には冷たい。 そうなるとレベルの違う選手が混じってサッカーをしているようなもので、上手い選手にパスも出さずに下手くそがドリブルしているおかげでゲームに負けるパターンに嵌るわけです。 責任分界点の外側にいるアプリケーション屋としては「あのハードウェア野郎のOJTをソフト屋に引き受けさせるのか」「マラソンと違って個人プレーじゃないんだぞ」となって、周囲は大迷惑なわけです。 まるで冗談みたいですが、何度もそのような事態に遭遇しますと、ハードウェア上で稼働するアプリケーションを販売する会社としては深刻な問題です。 ここ1年の間にも単なるサービスパックのあてもれ程度のトラブルを何度も経験しました。 お客様も我々もさっさと解決してほしいのですが、どこかの阿呆が「研究」を初めてしまったばかりに貴重な時間を、それも何か月にわたって浪費する。 これではメーカーサポートそのものをコスト認識せざるを得ません。
そこで我々としてはメーカーサポートは最小限度とし(＝多少お金を払おうがテレホンセンターにつながる早さが変わるだけなので結局同じです)、ある程度までは自社でリスクをとって保守する(＝ハードウェアメーカーのサポートは基本的にOSをはじめとするソフトウェアまわりをやってくれません)。 そしてヘッジ策として冗長系システムを、それも異なるメーカーのハードウェアにして確保する(＝ハードウェア価格は人件費に比べて安く償却も効きます)。 こうした方がかえって安くつくことに気づいたわけです。 繰り返しになりますが当社は何事につけて保守的性格ですので、オンラインサービス対応についても段階的に進めていく方針です。 今期は主に地方金融機関向けを想定して、既存製品 PortfolioBrowser® で長年導入実績があり機能的にも安定しているヒストリカルシミュレーション対応部分など、市場リスクの分野からサービス提供を始める考えです。
事業リスクの回避
当社にとっての主な事業リスクは、知的所有権関係と開発プロジェクトのリスクです。 知的所有権については、商標登録、著作権登録、および特許申請によって防御しております。 開発プロジェクトのリスクについては次のように考えます。 当社には、金融機関におけるシステム開発に関しては発注側・受注側の双方から長年の経験があります。 資本面の充実によって大型プロジェクト案件に耐えうるだけの財務体力もついて参りました。 それでもなお、仮に開発プロジェクトのリスクが現実のものとなった場合、売掛金回収期間の長期化と経営資源固定化により経営悪化が不可避です。 また何よりも風評の悪化を懸念しますから、中途でプロジェクトをやめるわけにはいきません。 受注前段階において開発リスクを案件別に評価し、成功確率が低く危険と判断したならば、商談見送りも辞さない方針をこれまで通り堅持したいと思います。
そのほか、当社の顧客に対しては、顧客、当社、(財)ソフトウェア情報センターの三者間でのソフトウェア・エスクロウ契約締結を促しており、当社に万が一の事態が起きた場合にはソースコードを含む全預託物が譲渡されるようにしております。 2005年4月1日から全面施行となった個人情報保護法および内部統制との関連においては、当社内部の情報管理を徹底するとともに、情報流出を防止するべく従来通り社外への開発の外注は行わずに100%内製化を貫く方針で今期も臨みたいと考えます。
どうか今後とも一層のご支援、ご鞭撻を賜りますようお願い申し上げます。
ニューメリカルテクノロジーズ株式会社
代表取締役社長 鳥居 秀行
