ビジネス価値の見極めが、開発効率を決める：システム開発、成功のポイントを聞く（2）（2/2 ページ）

[内野宏信，＠IT情報マネジメント編集部]

「自社にとってのビジネス価値は何か」が第一の判断基準

　このほか、東証のCIO、鈴木義伯氏からの指示を受けて、「経営層にも報告して問題を共有すべき」として3カ月に1回、東証の社長と富士通の社長にプロジェクトの進ちょくを報告、内容を確認してもらう「プレジデントレビュー」も成功要因として挙げられる。

　だが実は、これらの他に本プロジェクトを貫く最大のポイントが存在する。それは「自社にとって何が重要か」というビジネス価値を全ての判断基準としたことだ。これがシステムの設計から、開発のスピードと品質の両立まで、全てに効いている。

　例えばシステムの設計では、株式の売買注文処理を行うフロントサーバ群と、売買処理に伴う社内手続きを支えるバックサーバ群に大別した。さらに売買注文は全てフロントサーバ側のインメモリデータベースで処理し、3台のサーバで同期を取ることで高速性と信頼性を担保している。

図3　arrowheadは株式の売買注文処理を行うフロントサーバ群と、売買処理に伴う社内手続きを支えるバックサーバ群に大別されている

　このポイントは「東証の顧客は誰か」――すなわち「arrowheadのエンドユーザーは投資家であり、彼らの満足、信頼を獲得することが目的」だと明確に認識していたことだ。これにより、投資家へのサービス提供を担うフロントサーバ群を「絶対に止まってはいけないシステム」、東証の社内業務を支えるバックサーバ群を「仮に止まっても対処可能なシステム」と位置付け、バックサーバ群に問題があっても売買処理は継続できる設計としたのである。

　具体的には以下の図のように、フロントサーバ、バックサーバが支えるサブシステムを整理し、1つ1つについて品質、性能、納期などの要求レベルを評価。これを基準に開発リソースとマネジメントリソースの配置の優先順位付けを行った。これが合理的な設計、開発のスピードと品質の両立に大きく貢献したのだ。

図4　フロントサーバ、バックサーバが支えるサブシステムを整理し、1つ1つについて品質、性能、納期などの要求レベルを評価。これを基準に開発リソースとマネジメントリソースの配置の優先順位を付けた

　バグの対処も同様だ。全てを修正しようとすれば膨大な手間と時間がかかる。ともすれば、手を入れることで他の部分に悪影響が生じるリスクもある。そこで以下の図のように、本番稼働前2カ月間に発生した障害については、業務への影響度と修正リスクのバランスを考慮し、稼働前に修正するか、当面は運用で対処しつつ稼働後に修正するかを判断した。

図5　バグの修正も、ただがしむゃらに全てを解消を狙うのではなく、ビジネス価値を基準に優先順位を付けて効率的に行った

　これについて富士通の三澤氏は「あくまでバグゼロを理想としつつ、現実的には障害仕訳けをした上でリスクとのバランスを考えた。さらにこれを東証スタッフと共有できた点が大きい」と解説した。

「価値を最大限、担保するためには？」という観点が大切

　こうした点を受けて、静岡大学の森崎氏はポイントを整理するために、「東証がarrowheadに求めたビジネス価値とは何か」について宇治氏に質問。宇治氏は「arrowheadは世界中の投資家が利用するシステム。“高品質で絶対に停止しないシステム”を構築することで、顧客の信頼獲得を目指した」と回答した。

　また、注目されたのは、「もし2005年のシステム障害がなかったら、このように主体的に開発にかかわるプロジェクトを実践できたのだろうか？」という受講者からの質問だ。

　これに対して宇治氏はしばし考えた後、「こういうやり方はできなかったかもしれない」と回答。やはり世界の投資家の信頼獲得、日本経済にも影響を与え得る存在という、当時から抱いてきた強い危機感と使命感が今回のプロジェクトを支えていたのだという。

「採用した手法・手段の全てが“東証にとってのビジネス価値の実現”にひも付いている」と解説する静岡大学の森崎氏

　「従って、信頼獲得のために東証側でできること――すなわちコーディング以外は全て取り組むと決め、“高品質で絶対に停止しないシステム”実現に向けて、設計・開発の全てにおいて投資家に影響のあるものを優先し、東証社内で閉じるものについては優先順位を下げて取り組んだ」

　宇治氏はこのように述べ、システムに求めた“東証にとってのビジネス価値”がプロジェクトを一貫していたことをあらためて強調した。

　これを受けて森崎氏は、「今回の事例は、開発にお金を掛けられる企業だから実現できたものであり、予算に余裕がない会社にとっては参考になりにくいのでは？」という見方もあることを紹介。

　だが、「開発コストは絶対額だけで考えるのではなく、“そのシステムによって得られるビジネス価値とのバランス”で考えるべき。狙った価値を実現できるシステムならペイすると判断できるはず」と解説。

　また、今回の事例にはフィードバック型V字モデルをはじめ、数々のポイントが存在するが、「採用した手法・手段の全てが“東証にとってのビジネス価値の実現”にひも付いている、逆に言えば『その価値を最大限、担保するためにはどうすれば良いか』という観点から全ての取り組みが導き出されている」と指摘。採用する要件の選定から、システムの設計、バグの修正まで、「顧客の信頼獲得」というビジネス価値を判断基準に、優先順位を付けて取り組んだことが大きな成功要因なっていることを訴えた。

---

　実現したい目標から要件を導き出し、システム落とし込む――こうまとめてしまえばシステム開発の基本そのものだが、プロジェクトが進み始めると、採用するテクノロジや開発手法などに、つい目を奪われやすいものだ。だが、それらはあくまでビジネス価値を獲得するための手段に過ぎない。自社にとってのビジネス価値とは何なのか？ それを実現するシステムにはどのような要件が必要で、何を優先し、どのように開発コストとのバランスを取れば、一定の制約条件の中で得られる価値を最大化できるのか？――

　今回の事例は “基本”であるがゆえに形骸化しているシステム開発のあるべき姿を具現化してくれた、またある意味では事業継続の1つの在り方も示唆する、懐の深い好事例と言えるのではないだろうか。

「システム開発、成功のポイントを聞く」バックナンバー

• ビジネス価値の見極めが、開発効率を決める
• “ユーザー主体”の姿勢が開発のスピードと質を高める