SQiP2011の東証さん＋富士通さんのセッションに参加しました。
モデレータの森崎先生(静岡大学)にお誘いいただきました。ありがとうございました。
http://www.juse.or.jp/software/327/#k_003
品質がもたらすソフトウェアのビジネス的価値
―東京証券取引所 arrowhead 開発のユーザ側、ベンダ側双方のプロジェクトマネージャに聞く―講演者・パネリスト： 宇治 浩明 氏（(株)東京証券取引所）
三澤 猛 氏（富士通(株)）
進行・ファシリテーション： 脇谷 直子 氏（広島修道大学）
森崎 修司 氏（静岡大学）
ソフトウェア品質が提供するビジネス的価値を参加者それぞれの視点から考えるセッションです。
対象となるソフトウェアやプロジェクトによって、ビジネス的価値の提供方法は異なります。
本セッションでは、ビジネス的価値をどう判断し、ソフトウェア品質とどう関連づけるかを参加者全員で考えます。
まず、東京証券取引所の株式売買システム arrowhead の開発での事例を、東証側のプロジェクトマネージャ宇治様、ベンダである富士通側のプロジェクトマネージャ三澤様からご紹介いただきます。
その後、パネルディスカッション形式で参加者全員で議論しましょう。
- メモはTogetter をご参照ください。
イノベーションスプリント2011 の続編です (キッパリ)
イノベーションスプリント2011というイベントで、宇治さんと富士通側のPMであった金子さんにお話しいただきました。今回は、そのときのファシリテータをお願いした森崎先生が自ら企画して実現した、いわば森崎さん版イノベーションスプリント第２章というべきセッションでした。 ... あああ、僭越ですみません。
自分が運営側ではないので、ついにブログに書くことができ、非常にうれしいです。ありがとうございました。
東証 arrowhead 開発のきっかけは「危機感」
宇治: プロジェクトの背景。システム障害: ときの大臣からもしかられた。信頼が得られないと私設取引所に市場参加者が流れてしまう。
質問: システム障害がなければこの取り組みはできたか？
宇治: 一言でいえば、できなかったと思う。2005年のトラブルがあったのでこの取り組みができた。結果としてトラブルが起きるとがんばっていても、言い訳できない。それが起きないようにやろうと。
宇治: 全社プロジェクトになったので、業務に一番詳しい人、東証の中でも詳しい人を集めることができた。
危機感といっても、会社が本当に潰れそうになっているわけではないので、この期に及んで「海外とは違う。日本のベンダーが悪い」と言い切ることもできたのではないかと思います。「常日頃から品質に気をつけろと、社員に言い聞かせているが、このような事態になり大変残念だ。」というメッセージを社員や取引業者に対して発し続けるだけにとどまることもできたんじゃないかとおもいます。なんといっても国内ダントツの一位企業ですし。
しかし、2006年の証券取引所の状況は国際的な取引所間競争が顕在化してきた時期です。米国のNASDAQに対抗して、米NYSE と 欧Euronext が大陸を超えて合併したり、大量の取引を株価に影響を及ぼさずにあつかう私設取引所(ダークプール)が勃興したり、またアジアでは金融センターの地位を争うシンガポールの他、香港や上海の取引所がどんどんと力をつけてきたり。キーポイントはアルゴリズム取引で、大量の注文を即座にさばけるミリ秒単位の性能が、取引所に求められる時代になっていました。
そういった危機的な状況を経営レベルできちんと認識し、外部からCIOを招聘して、組織の文化そのものを変えたわけで、結果として、ものすごいことだと思います。
日本のソフトウェア受託開発における「ユーザ企業」という定義
「ユーザ企業」というのは、「ソフトウェア開発企業」「システムインテグレータ(SIer)」というソフトウェア開発産業の人から見た、「お客さん (Customer)」のことです。要件を定義し、発注してくれます。ユーザ企業自身がサービス提供業者として、他の企業や個人にそのソフトウェアを利用したサービスを提供していることもありますので、ユーザ企業の中に利用者(エンドユーザ)がいるとは限りません。
ユーザ企業には、通常、プログラムの組む人はいないようです。まあ自分で組めたら外注しないでしょうから、人手が足りないとか、技術者がいないとか、社員は単価が高いとか、様々な理由があって、外部の開発企業やSIerに発注するわけです。プロトタイプ構築や技術検証はしているかもしれませんが、プロダクションコードは発注先が組む、というケースがほとんどではないでしょうか。
ということで、基本的な取引形態としては、
- ユーザ企業が基本的な要件を作成する
- システム企業が要件に従って、工数を見積もり、コストを算出
- ユーザ企業はコストが安く、信頼できる企業に発注
- システム企業はソフトウェアを構築(設計、構築、テスト)して納入
- ユーザ企業はソフトウェアを確認(受入テスト、UAT)して、エンドユーザ向けにリリース
- その後、運用
という感じです。
で、一般的なソフトウェア開発では、後半のテスト工程に入ってからも、いろいろな問題が起こってきます。
- 仕様不都合、仕様の不備、考慮漏れ
- 実装のミス(バグ)
- テストの漏れ
- ユーザ要件の見直しによる仕様そのもの変更
ユーザ企業と開発企業のあいだで、どちらがこのリスクを負担するか、うまく取り決めができないと、延々と押し付け合う結果になります。もともとバグや考慮漏れが或ることを完全に予想することはできませんから、計画外のバグが発生し、想定外の仕様変更が発生するのが、ソフトウェア開発の通常の姿だといえるのではないでしょうか。
先に述べた通り、ユーザ企業は「お客さん」なので、松下幸之助の「お客様は神様」を額面通りに適用すると、お客さんの言ったことは絶対、という関係が成り立ちやすい点は日本社会の特徴だと思います。
「おたくさんもプロなんだから、きちんとバグのないように作ってくれないと、この業界で商売できないでしょ」
お客さん側が間違った要件定義を行って、あとから修正しても、開発企業は無理してあわせる、という構図が成り立ちやすいのです。また、ユーザ企業は、エンドユーザを持っています。仕様がまずければ、エンドユーザから矢のようなクレームが来たり、そもそもエンドユーザにサービスが売れなかったり、非常にまずい事態に陥るわけです。その場合に開発会社に泣いてもらって、緊急の修正を入れる、ということも、業界的にはよくある光景です。
しかも、最近の日本企業はとてもコストにうるさいので、ユーザ企業の発注担当者は大きな決裁権限をもっておらず、追加の料金支払いには社内稟議を行うことが必要で、(不正防止の意味もあり)すごく審査に時間がかかるようになっており、結局は緊急修正の対価が十分に支払われない、というリスクが潜んでいたりするようです。
不確実性バッファ - 信頼の欠如にともなう「保険料」
開発会社からすれば、一回そのようなリスクに直面すると、人間は痛い目をみたことは忘れないので、次の案件や他の企業でも同じことをされるのではないか、ということで、だんだんと防衛線を貼るようになります。
- 予め大きめに見積もって、変更時のバッファを持つ
- 契約書やドキュメントを整備・レビューして、そこに載っていないことは免責とする
問題は、ここにはコストがかかるということです。前者は人件費が掛かりますし、後者はドキュメントや契約書(これはビジネス場の価値を生みません)の作成コストがふくれあがります。私はこのコストのことを、信頼の欠如にともなう「保険料」と呼んでいます。信頼が欠如すればあがっていきますし、何らかの問題が起これば、その先の問題を想定して、保険料が上がります。
ユーザ企業と開発ベンダーの関係を見直すきっかけに
東証の宇治さんの事例が画期的なのは、この部分です。（これは森崎先生も言っていたので、私の妄想というわけではなさそうです。）
宇治: システムの目標。まずコンセプトを決め、できるだけ定量的に目標値を決めていった。次に、プロジェクトの運営方針決め。スローガンが必要。３年もプロジェクトやっているとみんなの考えが変わっていく。システム障害から何年も立つと忘れてしまう。なぜこのシステムを作るのか
宇治: 上流工程をしっかりやるとか、民主的にやっていくとか。富士通さんと一緒にやったが、会社間の壁があるとうまくいくものもいかなくなるので、ワンチームだというスローガンも決めた。
宇治: 発注者責任の明確化。ベンダの提案の精度が低い？=>RFPの記述粒度が粗い。要件と実装の齟齬？=>要件定義に漏れがある。と考えて改善してきた。
「開発企業に責任を押し付けることはしない」という宣言をした上で、フェアな制度化をめざしつつ、統一した目標/コンセプトを設定しました。
この宣言が、おそらく数十億とか数百億の予算を持つ案件で、いったいいくらの保険料を削減することになったか、計り知れません。
スクラムの核心も、信頼による保険料削減
欧米で主流になってきたプロジェクトマネジメントの方法論「スクラム」というものがあります。スクラムという名前はラグビーのスクラムのように職能横断的なチームを組んで、新製品開発という難局を乗り切る、というメタファーから来ています。このスクラムの核心部分も、前項で述べたような保険料を削減する、まさにそのことなのです。
以下に、スクラムガイドの冒頭部分を引用します。
スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。
(中略)
経験的プロセス制御の実現は、透明性・検査・適応の 3 本柱に支えられている。
透明性
経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明 性とは、この点が標準化され、関係者全員が共通理解を持つことである。
(中略)
検査
スクラムでは、好ましくない変化を検知できるように、成果物や進捗がゴールに向かっているかを 頻繁に検査しなければならない。ただし、検査を頻繁にやりすぎて作業の妨げになってはいけ ない。熟練の検査人が念入りに行うことで、検査は最大の効果をもたらすものである。
適応
プロセスに不備があり、成果物であるプロダクトを受け入れられないと検査人が判断した場合、 プロセスやその構成要素を調整しなければならない。調整はできるだけ早く行い、これ以上の 逸脱を防がなければならない。
これって、アジャイルとかウォーターフォールとか、あんまし関係ないとおもうんですよね。
というわけで、来月「Scrum Gathering Tokyo 2011」で、ヘンリック・クニベルグさんも、そんな話をしてくれると思います。日本のソフトウェア業界が陥っている問題は、すでに欧米のソフトウェア業界では過去のもの。変化の秘訣を探ります。
