大企業でも通用するシステム設計手法を用いて、御社の業務システムを最適化
システム運用時においてよく挙げられる課題としては
過去に作ったWEBシステム、業務システムなど、今まで問題なく運用できていたが、ビジネス拡大に従い、次々と新規機能を追加する必要が出てきている。しかし、システムが多すぎて、必要な開発人員も増えているので、開発チームの管理が難しい。
大規模なシステムなので、何か一部の手直しを行ったときに、全体的に他の部分に影響があるのか確認（いわゆる結合テスト）をするのに膨大な時間がかかるため、効率よく開発を進められない。
心当たりはありませんか？
少なくとも、我々の経験している限りだと、大企業でのシステムは昔から作っていたもので、全部の機能を一つのコードベースに入れてあり、しかも、レガシーテクノロジーの部分が多いので、特定の部分を改良するのは極めて手間とコストがかかります。
ある程度予算に余裕がなければ、今のシステムのまま妥協してしまい、日々の業務の生産性は低いままになります。そのため結局は運用コストが膨らんで、企業の利益率が下がる要因になります。
昔のシステムアーキテクトはすたれている！と言っても過言ではありません。
どの様に業務システム全体の設計をするのか考えると、そこで「マイクロサービスの設計」という今流行っているシステムの設計手法が出てきました。
我々は、大手の外資投資銀行とマイクロソフトでのソフトウェアエンジニアの経験をもっている為、社内業務系のアプリから、ネットメディア業界のアプリまで幅広く知識を持っています。
ソフトウェア開発会社の役員である現職では、常にITでクライアントのビジネス課題を解決する為のコンサルティングを行っています。
約30本の案件に携わっており、プロダクトの要件定義・企画・デザインから開発・運用まで豊富な経験を持っています。
技術方面からのお話をいたします。
①企業の基盤システム
企業の様々な部門において、業務が異なります。そして、同じ業務であっても企業によって、課題が異なる為、一つのソリューションで全ての企業に適応できることはありません。
今現在の業務内容と課題を教えていただけると、御社に最適なソリューションを提案するのみならず、各種カスタマイズ・運用までお手伝いできます。
②マイクロサービス
システムをスケールさせる時はどうしても従来のやり方だと、制限がついてしまいます。一つのシステムの規模が大きすぎるために、管理しにくかったり、開発チームの人数が大量に必要になったりすることは珍しくありません。
そのため最近マイクロサービスの設計方式が流行しています。それはシステムを小さい部分に分けて、各小さい開発チームで構築するような手法です。
マイクロサービスの設計方式には下記の利点があります。
・効率よく開発を進められる。マイクロサービスはそれぞれ小さいチームに任せられる為、管理コストが下がるとともに、チームでのやり取り・コードレビューなどは効率よくできます。
・汎用性がある。各マイクロサービスは一つのブラックボックスのようにインプットとアウトプットが決まっているだけで、中身までは決まられていない。だから、一つのマイクロサービスは様々な実装方法があります。入れ替えることもできます。
・システムの検証はやりやすい。検証は各マイクロサービスを検証すればいいので、仕様に決まったインプットとアウトプットをしっかりとテストするだけです。
いわゆる、マイクロサービスは部品のような考え方で、一つの車を作るために、様々な部品メーカーに任せられます。そして、一つの部品に関しても様々なメーカーがあるので、一つのメーカーがダメであっても違うメーカーを使えばよいことになります。
納品の規格だけ、各メーカーさんが守れば問題ありません。
③運用モデル
本番環境で動いているシステムの運用保守モデル・サポートモデルについて話すことが出来ます。プロセスのモニタリング、L1、L2、L3のサポートモデル、ログシステムについて精通しております。一番低コストで効率よくシステムの運用保守モデルをお話します。
④金融システム
フロントオフィス用の金融システム、バックオフィスの金融システムのアーキテクトに関して話します。
⑤Javaの大規模システム
Javaでのシステム構築の方にさまざまなアドバイスをすることができます。
大きい業務システムをマイクロサービスのアーキテクトに変換すること
これから新規システム開発で、最初はMVPでいいが、将来は業務多様化にも対応したいので、最初からマイクロサービスの設計で行きたい
というお客様は是非AMELAにお問い合わせください。
AMELAに在籍している優秀なシステムアーキテクトの者が御社の業務に最適なシステム設計を行います。
