“ユーザー主体”の姿勢が開発のスピードと質を高める：システム開発、成功のポイントを聞く（1）（2/2 ページ）

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

会社組織の壁を越えて、危機感・使命感を共有した仲間たち

　その後、レスポンスタイムは2ミリ秒となり、東証もニューヨークやロンドンなど世界の証券取引所と肩を並べるレベルになった。これを受けて世界中の投資家の利用も増大した。宇治氏は、今回のプロジェクトを振り返って、成功の最大の要因は危機感、使命感にあったと総括する。

　「前述のように、東証のシステムは日本経済に直接的な影響を及ぼし得るもの。投資家の信頼を獲得するために1000分の1秒という目標値をどうしても達成しなければならない。そうした危機感、使命感をプロジェクトメンバー全員で共有できたことがプロジェクト推進の大きな原動力となった」（宇治氏）

「危機感・使命感の共有がプロジェクト成功を大きく後押しした」と語る宇治氏

　その一つのポイントとなったのが、江東区有明にプロジェクトメンバー全員が集うプロジェクトオフィスを設置したことだ。ここに関係者が一同に集い、同じ空気を共有していたことが危機感・使命感の共有にひと役買うことになった。

　ただ、宇治氏はチームの一体感をより強固にするために、「Challenge“10”msec！　高速性と信頼性を両立する、世界一の取引所システムを創る」というスローガンを作成し、これをチームの“コアバリュー”に設定。併せて、「One Team,One Dream　世界一のシステムを目指して頑張ろう！」という“会社間をつなぐスローガン”も策定した。

　その上で、フィードバックV字モデルを指す「上流工程完璧主義」や、メンバー全員でお互いに人となりを知り、活発に意見交換する「ワイガヤ民主主義」といった「プロジェクト管理方針」、リニアなスケールアウト、ミリセカンド・レスポンスなど設計上の要件をまとめた「システム設計方針」を明確化した。それを受けて富士通側のプロジェクトマネージャがオフィスの一番目立つ場所に貼った。

図2　プロジェクトチーム全体のコアバリューを設定し、会社間の壁を解消。一丸となって開発に臨んだ（クリックで拡大）

　「結局、開発プロジェクトとはチームビルディング――組織をどう作るか、どうリードするかが鍵になる。その点、会社間の壁をなくし、一つの会社組織と同じように、プロジェクトチーム全体の行動指針、文化を明確化する必要があると考えた」（宇治氏）

「プレジデントレビュー」も実施。経営層も含め、全員で目標を共有

　こうしたプロジェクトの基盤作りが効いた。例えば「要件定義書を自社で作る」というのも、実際にやるとなると非常に大変な作業だ。しかもコアメンバーは全て元業務部門のスタッフ。当然、ITの知識などなかった。だが、その使命感から自ら必要な知識を勉強したほか、周りには使命感を共有する富士通や協力会社の“仲間たち”もいる。

　そこで、不明点があれば教えてもらいながら、試行錯誤して取り組みを進めたのだという。その結果、「レビューも最初は単なる文言の修正などが多かったが、こなしていくうちにレビューすべき観点やポイントが分かるようになり、作業効率が向上していった」（宇治氏）。

富士通 保険証券ソリューション事業本部 東証事業部 プロジェクト統括部長 三澤猛氏

　富士通の三澤氏も、「同じ一つのオフィス内という利点は大きく、東証スタッフの要望について不明点があればすぐに確認できたし、業務現場の詳細な知識も入手できた。また、東証のスタッフが要件定義書のレビューなどで、夜遅くまで働いているのを間近で見ているだけに、開発を担う弊社スタッフの使命感も一層高まった。設計・開発上の疑問点はその場で解決することを目指し、危機感を共有しながら一丸となって開発に取り組めたと思う」と振り返る。

　東証のスタッフが一同に集い、全員が業務部門出身の人間だったからこその利点もあった。要件定義を行う上では、各要件の間に矛盾や齟齬があってはならない。従って要件を固める上では、要件に優先順位を付け、採用するもの／しないものを切り分ける必要があるが、これに納得してもらうためには部門間調整が不可欠となる。

　その点、コアメンバーは全員が業務部門から来た人間。調整は効率的に進み、掛ける時間も比較的短時間で済んだ。調整の経緯・履歴については紙ベースできちんと記録を残し、あとで覆される事のないよう配慮したこともポイントとなった。

　さらに、プロジェクト成功を大きく後押ししたのが、東証のCIO、鈴木義伯氏からの働き掛けだ。本プロジェクトが社運を賭けた問題であることから、「経営層にも報告して問題を共有すべき」として「プレジデントレビュー」も行うよう、宇治氏に指示したのである。これを受けて、宇治氏は3カ月に一回、東証の社長と富士通の社長にプロジェクトの進ちょくを報告、内容を確認してもらった。まさしく関係者全員が一丸となって、それぞれの立場から“日本経済にかかわる一大課題”に取り組んだ格好だ。

“スピード＝アジャイルという記号”に惑わされず、最適な手法を

　ただ、このプロジェクトは、プロジェクトマネジメント以外の面でも見るべきポイントが存在する。1つはシステム開発にスピードが求められ、アジャイル開発の必要性が叫ばれている中で、ウォーターフォールモデルで開発を行った点だ。

　特に前のフェイズの誤りを確実にチェックしながら進む「フィードバック型V字モデル」は一見、トレンドに逆行しているようにも思える。だが今回のように、基本的な要件が明確で大きく変わらない場合、上流工程で確実に問題を発見・解決しておけば、たとえ前半で時間はかかっても後半は手戻りなくスピーディに進められる。つまり「スピード＝アジャイル」といった短絡的思考に陥らず、「要件の特徴を見極め、それに応じて、先入観を持たずに最適な手法を選ぶ」ことが開発のスピードと品質を担保する真のポイントとなることを、あらためて示唆していると言えるのではないだろうか。

ユーザー企業と開発企業のスタッフ同士で一丸となり、業務とシステムに対する相互理解を深めたことがプロジェクトの成功に結び付いた。新たなプロジェクトによるシステムの継続的改善も、目標を共有し、実現した両社、両氏の信頼関係あってのものだ

　また、本プロジェクトの場合、遅延を防ぎ、品質を担保するための、もう一つのポイントとなったのが、富士通とともに行った要件の絞り込みや、レビューで見つかった問題解決の優先順位付けだ。

　宇治氏はこれについて、「東証のスタッフと富士通のスタッフで、ともに業務とシステムのマッピングを行い、慎重に必要な要件を絞り込んだほか、優先してつぶすべきバグについても、システムの利用者、すなわち投資家に影響のあるものを優先し、東証社内で閉じるものについては優先順位を下げて解決を図った。これが開発スケジュールの厳守と無駄な開発コストの抑制に効いた」と解説する。

　富士通の三澤氏も「要件をシステムに実装する際も、例えば要件Aと要件Bの整合性をチェックする必要があるが、要件がしっかり固めてあるだけに優先順位の調整がやりやすかった」と振り返る。すなわち、「ITシステム＝ビジネス」と捉え、“発注者責任”をまっとうしようと考えたことが、プロジェクト成功の全ての礎となったのである。

　そして、こうしたスタンスは、「来年5月までに1ミリ秒を実現することを目指し、この7月にスタートした新プロジェクトでも変わらない」という。

　「ITシステムがビジネスを支えている以上、ITすなわちビジネスと考え、サービス提供者がITシステムに対してきちんと責任を持ち、自主的に取り組むべきだと思う。ベンダやSIerに丸投げするのではなく、システムを利用する側の人間が、自分たちできちんと開発をコントロールすることが、プロジェクトの成功、システムの成功に不可欠だと考えている」（宇治氏）

　宇治氏は最後にこのように述べ、ビジネスの遂行、サービスの提供に責任を持つ“ユーザー主体の姿勢”こそが、開発を成功させる前提条件になることを強く訴えた。

---

　なお、2011年9月8、9日に東京・早稲田大学で行われる「ソフトウェア品質シンポジウム 2011」（日本科学技術連盟主催）で、宇治氏と三澤氏が登壇し、静岡大学の森崎修司氏、広島修道大学の脇谷直子氏の進行により、本プロジェクトの成功要因や、開発品質がもたらすビジネス的価値について議論するという。開発の品質とスピードを担保するためのポイント、ユーザー主体開発の具体的な中身について、ぜひ両氏の知見を学んでみてはいかがだろうか。

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

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