上流工程の大切さとそれに向き合う姿勢について - ipa2016. 3. 16...

2016. 3. 16

澁谷裕以（しぶやひろゆき）

上流工程の大切さとそれに向き合う姿勢について

日本取引所グループ常務執行役 CIO

【資料1-5】第1回システム構築上流工程強化部会

Copyright © 2015 Japan Exchange Group, Inc. and/or its affiliates. All rights reserved. 2

1. 東京海上の「アプリケーション・オーナー制度」について

2. 日新火災での経験

3. システム開発という仕事、大切にすべきこと

4. 上流工程の問題に向き合う姿勢について

目次


９０年代後半～、代理店オンラインの普及と金融・保険の自由化が相まって、システム開発を伴う商品開発競争の時代が到来。それまでとはレベルの違うシステム開発のボリュームに。・・・

しかしながら、システムトラブルが多く、第一線・代理店から「これでは仕事にならない！」との怒りの声が。

システムの信頼化向上・品質向上は、経営上の大問題に

１．東京海上のアプリケーションオーナー制度について


コンサルタントを入れて分析してみると、以下のような実態が判明。

問題の殆どは上流工程に

大規模トラブルの６割が上流工程に起因

開発規模が大きいものに絞ると８割が上流工程に起因


コンサルタントにより、上流工程の実態として以下のような改善課題が指摘された。

ビジネス側の要件の確定が遅い。（期日までに決めなくてはいけないというマインドが乏しい。）

要件の変更が多い。

要件を最終的に文書で確認していない。

システム開発におけるオーナー部門の関わり方を根底から

変えないといけない


外部ヴェンダー

教育・マニュアル作成

アプリケーション・オーナー制度：責任と役割分担

要件定義の最終決定･･･目的・効果に照らして

健全な緊張関係

目的を共有した協力関係、フランクな対話

アプリケーション・オーナーシステム部門お客様

・代理店

・第一線の社員

システム化要望の提示With 目的＆期待効果

工程をしっかり管理して期限までに品質の良いシステムを作る受入テストケース策定

・テスト実行

対話による要件の具体化

パフォーマンス・テスト、インフラセットアップ等

発見された問題への対処発見された問題への対処

技術的＆コストの観点からの選択肢の提示

対話による費用対効果の高いｿﾘｭｰｼｮﾝへのリード

上記を踏まえて、「アプリケーション・オーナー制度」を確立。ポイントはオーナー部門のコミットメントと、UATへの参画（手で責任を取る）。


当初は、「他人に自分の仕事を押し付けるな」と非難される。

アプリオーナー制度の創設と同時に劇的な効果が

しかし、導入直後から劇的な効果が出て、翌年からトラブルが８割削減された。


日新火災では、２０１２年４月から、２つのプロジェクトでアプリオーナー制度の試行を行った。

試行結果の効果測定は以下のとおり。

＜同じ自動車保険のシステム改定でのトラブル発生件数＞

・試行前（２０１１年４月改定）・・・１７件

・施行後（２０１２年１０月改定）・・・１件（６％）

試行の成功を踏まえて2013年度から全面展開した。2013年度のトラブル発生件数は前年度の４割減となった。

２．日新火災での経験


初めてシステム部門が作った仕様書をチェックして愕然とする。

日新火災：商品部（アプリオーナー）の反応

“こんなにも判ってもらっていなかったのか！こんなにも誤解されるものなのか！”

それまでは、「保険料算出方法書」を渡して、“この通り作っておいて“

仕様書を丁寧に添削するなかで、どんどんダイアローグが活性化する。

“これは楽しい仕事。どうしてうちのシステム部門は、これまでこれをやらせてくれなかったのか？”


日新火災：IT部門の反応

これまでは、自分たちに閉じた仕事

UATのテストケースは、システムサイドが作ったテストケースを見て作ることが判った途端、“こんないい加減なテストをやっていたのか！”と言われたくない。

システムサイドのテストケースの精緻化に必死に取り組む

健全な緊張感は品質を高める。


３．システム開発という仕事、大切にすべきこと


システム開発と建築はよく似ている。どちらも、「思いを形にする」仕事。より正確に言うと、「思いを人に形にしてもらう」仕事。システム開発も建築も自分ひとりでできる仕事ではない。

そこで大事なことは、いかに人に思いを共有してもらえるか？自分の思いをいかに人に正確に伝えることができるか？建築もシステム開発も、コミュニケーションの仕事。

しかしながら、建築においては、これから作ろうとするものが学校なのか、オフィスなのか、コンサートホールなのか、個人の家なのか、それを間違えることはない。しかも、柱が真っ直ぐか、床がフラットかは誰でも見れば直ぐに判る。

システム開発は、ITの活用によって初めてできる新しいビジネス

プロセスをつくる仕事。そこに価値がある。でも、建築のようにパターン化された先例がなく、目に見えない。当然のように思い違いが起きる。

システム開発と建築


受け取った要件伝えたつもりの要件

ＡＢＣ

ビジネス部門システム部門

人が相手が言ったことをどう理解するかは、その人の知識、過去の経験、トラウマなどに大きく左右される

“A”を”B”に、”C”を”B”にするためには、深い対話を繰り返し行うことがとても大切

当然のように起きる「思い違い」

これは、オーナーとシステムの間だけではなく、システム部門内でも同じ


ＡＢＣ

このような「良いチーム」では、双方に様々な発見や気付きがあり、最初の構想よりどんどん良いものができる・・・楽しい！

繰り返し深い対話を行える条件

「自分ごと化」・・・プロジェクトに関わる人全てがプロジェクトの目的、リスクを自分の腹に落として自分の言葉で理解し、責任をもって行動している

「互いの尊重」・・・チームメンバー間に上も下もない、内も外もない、お互いを信頼し合い、リスペクトし合い、深いレベルで共感し合っている


「態勢」という言葉は、「体制＋マインドセット」を意味する。

態勢

体制

経営者や業務部門の人たちが、システム開発を自分ごと化し、コミットして初めて「態勢」ができる。

ex. 非常時態勢、戦時態勢

こういう態勢ができて、初めて要件ギャップをなくす真の対話が成り立つ。

繰り返し深い対話が行える態勢

繰り返し深い対話が行えるためには、会社全体でシステム開発に向き合う姿勢が必要。それが「態勢」。


「態勢」をつくるもの

社長

IT 部門

株式部

審査部門

清算機関

上場部

各業務執行役員ＩＴ担当役員

経営陣の理解と姿勢“Tone at the management”

透明性・説明責任

オーナー部門

ITを自分のこととして捉えるマインド

IT部門の透明性・説明責任が全体の態勢を動かすドライバー


メソドロジーやガイドブックだけで上流工程の問題を解決することはできない。

さらに、これまでのシステム開発の方法論はシステム工学に閉じ過ぎている。システム開発は、もっと諸学を統合したものであるべき。特に重要なのは、コミュニケーション学であり、認知心理学、社会学、経営学の要素だと思う。

その背後にあるシステム開発に向き合う会社全体の「態勢」こそが重要。態勢がないところで、方法論を唱えても機能しない。

この部会が価値ある成果を生み、日本が真にITを経営の力とすることができるようになることを祈っているが、そのためにはもっとパースペクティブを広げる必要があると考える。

４．上流工程の問題に向き合う姿勢について


ありがとうございました

上流工程の大切さと それに向き合う姿勢について - ipa2016. 3. 16...

Documents

上流工程の大切さとそれに向き合う姿勢について - ipa2016. 3. 16...