Skip to main content Skip to Footer

業績変化に適したシステム開発アプローチ~フェーズドアプローチにおける導入のポイント

開発途中で業績が変化しても状況判断により次フェーズの対応を再検討できる、証券業界に適したリリースモデルを紹介します。FSアーキテクト Vol.33。



金融サービス本部
マネジング・ディレクター
坂本 幸一
 坂本 幸一 

アベノミクスの影響もあり、リーマンショック以前の好景気を取り戻した証券業界。2014年もNISA口座がスタートして業界としても堅調維持を予測する傾向が強い。

ただ、この15年間を振り返るとITバブル~崩壊、いざなみ景気~リーマンショックなど、市況は乱高下を繰り返しており、その度に証券業界の業績は大きな影響を受けてきた。

そのような状況の中で、多くの証券会社では業績変化に強いシステム投資計画を提唱・検討していると思われるが、今回は、業績変化が激しい証券業界におけるシステム開発モデルのあり方について紹介したい。

■証券業界の業績
大手証券会社における2013年4月から12月までの決算情報によると、株価の上昇に伴う取引の拡大、NISA口座開始に伴う証券への関心の高まりの中で、揃って業績を伸ばしている。

野村證券は純利益ベースで、前年同期期間比で約6倍、SMBC日興証券は2.9倍となったほか、大和証券グループ本社も、純利益が5.6倍と、四半期決算開示開始(1999年)以降過去最高を更新した。

一方で、証券業界における業績の歴史を振り返ると、株価同様の激しい乱高下を繰り返している。

2000年以降、ITバブルが崩壊すると株価は瞬時に暴落し、証券会社の業績も1年待たずして、不動産バブル以降の最高益から赤字へと転落している。

また、直近においてもリーマンショック後には投資家がリスク資産への投資を回避する傾向が高まったため、株式市場が低迷し、証券会社各社の業績も低迷が続いた。その後も東日本大震災や戦後最大の円高など株式市場および証券会社にとって厳しい局面が続いた。

しかし、2012年12月の第2次安倍政権発足以降の株価上昇に伴い、投資家の投資意欲も回復したため、証券会社の業績も大幅に改善している。

■証券会社の収益構造
証券会社の主な収益源は「受入手数料」、「トレーディング損益」、「金融収益」に大別される。特にフロー型商品に関連する「受入手数料」は収益への寄与度が高く、各証券会社の収益の50-70%を占める。

「フロー型商品」は取引量に大きく依存するため、証券会社にとって業績が市況の影響を受けるのを回避することは難しく、株価の激しい変動がそのまま業績変動に直結してしまっている。

■業績変動がシステム構築に与える影響
このような証券会社の業績変動は経営計画に大きな影響を与えるのは当然だが、システム構築にも大きな影響を与える。業績が良い時の証券会社はシステム投資計画を策定し、システム構築を強力に推進する。

一方で、業績が悪くなれば瞬時にシステム投資を抑制し、新規システム構築の停止やスコープの縮小を実施する。場合によってはシステム構築プロジェクト自体を中断してしまうケースも見られる。

また、コスト削減だけを重んじるような一過性の取り組みを実施した結果、システム品質の極端な悪化を招いてしまったケースも少なくない。

開発モデルごとにおける特徴と業績変動時の問題点
通常のシステム開発モデルは大きく3つに分類される。(図表1)

図表1 各開発モデルのリリースモデルイメージ(画像をクリックすると拡大画像が開きます)

【図表1 各開発モデルのリリースモデルイメージ(画像をクリックすると拡大画像が開きます)】

  1. カスタム開発
    ユーザ要件に基づき、原則ゼロからシステムを構築する開発モデル。ユーザ要件を全て取り込み、満足度の高いシステム構築を実施する事が可能。ただし、完成までには膨大な時間やコストを要する事が多い。そのため、業績変動が大きく、将来的な見通しがつけづらい証券業界においては投資判断が非常に難しくなる。

  2. パッケージ開発
    パッケージソフトウェアをベースにし、ユーザ要件を取り込む開発モデル。カスタム開発に比してリリースは早いものの、リリース後の追加開発に対する自由度が限定的。また、一般的にはメンテナンスコストは高く、ライセンス料として固定されているため、業績悪化時でもコスト抑制が効かない事が多い。

  3. ツール・EUC開発
    エクセル・Access等のアプリケーションを用い、ユーザ要件を充足する簡易なツールを構築する開発モデル。開発が容易で、簡単なユーザ要件であれば短期間・低コストで実現できる。しかしながら、業績が好転し続け、要求が高度化された場合においてはユーザが求める機能レベルを実現する事は極めて限定的である。

■証券業界に適したリリースモデル
業績変動の影響が大きい中で求められるのは、比較的短期間でリリースすることと、その後の業績変動を見定めながら、必要に応じた機能拡張を可能とする段階的なリリースモデルである。リリース期間は、開発モデルだけではなく開発アプローチにも大きく依存する。したがって、このようなリリースモデルを実現するためには、開発アプローチにも着目する必要がある。

■システム開発アプローチ
システム開発においては、カスタム開発、パッケージシステム導入を問わず、以下2つの開発モデルが一般的とされている。

  1. ウォーターフォール型
    最もよく知られたシステム開発アプローチであり、Vモデル(開発工程の対応関係を示したモデル。仕様を策定する工程に対し、対応するテスト工程を規定。)に添って、要件定義からテストまでの全ての工程を順々に実施し、一度に全機能をリリースするモデル。

    上流フェーズから下流フェーズまで、フェーズごとに異なる要員が担当し、明確な役割分担が設定されている。

    そのため、リリースまでには期間を要すことが多く、開発途中での投資金額変更に弱い特徴がある。

  2. アジャイル型
    システムリリース、評価、改善を繰り返す事でシステムを構築していく手法である。もともとは、商用ソフトウェア開発向けに考えられたシステム開発アプローチであり、要件が不明瞭なまま開発に着手し、完成したシステムを確認しながら要件を完成させるモデル。

    全体的な要件定義を省きながらリリースすることで、一般的には比較的早期にシステムリリースできると思われているが、未完成なままシステムリリースを繰り返すため、システムの完成までには中・長期的な期間と投資の継続が必要になる。業績変化に合わせて都度変更をかけられるものの、全体としての計画が立てづらい。

■フェーズドアプローチ型
では、証券業界に適したリリースモデルを実現するにはどうしたら良いのだろうか。方法としてはいくつか存在すると思われるが、今回は「フェーズドアプローチ型」を紹介したい。(図表2)

図表2 開発アプローチ比較(画像をクリックすると拡大画像が開きます)

【図表2 開発アプローチ比較(画像をクリックすると拡大画像が開きます)】

全体をいくつかのフェーズに分けて、小~中規模なVモデルを繰り返してリリースしていくのが特徴。

プランニングフェーズ内で全体要件定義を実施し、全体像を把握した後にフェージング計画を策定。

フェーズ単位でのリリースは小さくなるため、途中で業績が変化した場合においてもその時点の状況を判断して、次フェーズにおける対応を再検討できる型である。

■導入におけるポイント
前述したモデルについては本モデルを実現するためのポイントとして、下記4点が挙げられる。(図表3)

図表3 フェーズドアプローチの主な課題と対応のポイント(画像をクリックすると拡大画像が開きます)

【図表3 フェーズドアプローチの主な課題と対応のポイント(画像をクリックすると拡大画像が開きます)】

  1. 期間ベースでフェーズ1のスコープを確定
    フェーズドアプローチ型でシステム開発をする場合、ユーザ要件ベースでフェーズ1のスコープを決めるとリリースが遅くなり、早期効果創出ができなくなってしまう。そのため、ユーザ要件ベースではなく、フェーズ1リリースまでの期間から逆算で要件を決めるアプローチを取ることが肝要である。(例:ファーストリリースは半年後と定め、その期間で開発できる機能を選定する。)通常、半年以内にフェーズ1をリリースするのが早期効果創出の観点から望ましいと考えられる。

  2. ユーザの継続的な参画
    フェーズドアプローチ型では、プランニングフェーズで比較的短期間のうちに要件定義を行うため、開発者まで細かい要件が伝わらず、後続工程で手戻りが発生するケースが多い。これを防ぐためには、要件定義期間および設計以降の開発工程にユーザが継続的に参画し、開発サイドと密なコミュニケーションを持続することが不可欠となる。

  3. ユーザと会話ができるSEの調達
    ユーザとのコミュニケーションが重要なのは、既に述べた通りだが、それを可能とする「ユーザと会話できるSE」の重要性を忘れてはならない。例えば、要件定義書では表現しきれない操作感、デザイン、こだわり機能等のユーザ要望をSEがユーザとのコミュニケーションの中で直接把握し、コーディングに活かすことが可能となる。これにより、迅速かつ精度の高いシステム開発が実現できる。

  4. 戦略的プロジェクト管理チームの設置
    開発期間が短いフェーズドアプローチ型では、1つの課題・障害が全体スケジュールに大きく影響してしまう。そのため、課題・障害が発生してから対応するのではなく、潜在的なリスクの段階から対応を推進する戦略的プロジェクト管理チームを設置する必要がある。このチームが起点となりプロジェクト全体でリスクを共有し、先手対応を進めることがシステム開発成功の鍵といえる。

■終わりに
既に各証券会社においては業績変動による「負」の歴史を繰り返さないための策を実施されている事と思う。このようなアプローチに関しても、その1つの策として、検討いただきたい。

FSアーキテクト Vol.33 / 2014年春号

(関連リンク)