銀行決済24時間化が2018年となる理由をちょっとだけ推測
銀行振り込み｢1時間だけ｣延長…ご冗談を！ | 夏野剛のググっても絶対出ないハナシ | 東洋経済オンライン | 新世代リーダーのためのビジネスサイト
銀行は専門じゃあないので、内容は不確かなところもありますがご了承を。
2018年まで改修が必要となる理由は政治じゃないかな
この夏野氏。2018年まで銀行24時間決済が実現しないのを憤っているご様子ですが、正直銀行のせいじゃあないと思うんだけどなあ。
今、銀行系のシステムでは「金融一体課税(2016年1月完了)」「みずほ銀行のシステム更改(2016年後半頃完了)」「マイナンバー制度(2016年～2017年順次完了)」って形で、かなりの規模のシステム改修が動いている形となります。
上記を見ての通り、既に2017年までシステム改修スケジュールが埋まっている状態なんですよね。
しかも、政府主導の制度案件がかなり多く占めてます。
このような状況で、例えば「マイナンバー制度」のリリースが破綻してしまい、そもそも制度がスタートできなくなってしまうなんて自体は政治的にも避けたいところ。
そういった形から、制度案件だけでなく、平行して稼働している中～大型案件については、かなり厳しいチェックを受けている状況じゃないかなと思われます。
※金融系のシステム開発ではよくある話。
このような条件下で「決済24時間化」を2017年までに銀行協会が推し進めようとしても、政治の面からストップがかかるんじゃないかなって思います。どんなにユーザ視点を強調しても。
ただ、これは政治の都合としては仕方ないんじゃないかなって思うんですよね。
金融一体課税にせよ、マイナンバー制度にせよ、銀行以外にも多数の業界でシステム改修対応を行っている案件ですし、その影響の大きさから、制度破綻を招くようなシステム開発の失敗は許されないでしょう。
最悪の最悪の事態として、ミッションクリティカルの取引網の中心に存在する銀行系システムが、制度対応できなければ政治的な超法規的判断で制度開始延期にならざるを得ないなんて状況も考えられます。
安全第一にならざるを得ない状況ってのもまあわかります。
※これも、現在のミッションクリティカル系システムが高度化しすぎて、業界横断で結合しすぎだったりするせいもあるんですけど。
まとめ
夏野氏は、2018年まで変更が遅れることについて、「銀行業界がユーザ目線がないせいだ」と憤っておりますけど、そんなことは無いんじゃないかな。
制度改正といった政治の都合に翻弄されながらも、精一杯ユーザの要望に答えようとした結果、2018年というスケジュールが出てきたんじゃないのという気がしますよ。
以上
- 作者: 野村総合研究所決済制度プロジェクトチーム
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2009/05
- メディア: 単行本
- 購入: 2人 クリック: 47回
- この商品を含むブログ (3件) を見る
paizaには認識されてないSIerで身につけられる技術
SI⇒Web転向に失敗するエンジニアに共通した【たった１つの特徴】 - paiza開発日誌
SIerがぬるま湯なのか。。。SIerって平均的にはわりかし給料が高いけど、高給ぬるま湯ならホワイト企業ってことで、SIerへ転向進めたほうがいいんじゃないのかな。
2014/11/12 00:41
個別の転職話は正直興味ない話なのでここではおいておくとして。。。
毎度のごとく、SIer disへの誤りを指摘しておきますか。
転向者の割合を求められる水準の高さと勘違いしてはダメでしょ
ふむふむ。主張としては、WEB業界へ転向する人のうち、22.8％しかいないため、WEB系企業で求められる人材の水準が高い、と言いたいようですが。。。
でも、その直前にはこんなこと記載しているんですよね。。。
逆のSIerの中途採用の7.3%がユーザ企業から、2.2%がWeb企業からとなっており、SIerからユーザー企業、Web企業への流出は増加しています。
・・・これ、数字だけ見れば、WEB系からSIerへの転向者の割合は、SIerからWEB系企業への転向に比べて著しく少なく、更に高い技術水準を求められているってことになるんじゃないのかな。。。
WEB系企業からわずか2.2％しか転向しないIT企業は、さらなる狭き門である！と。
まあ、自分で書いていて何書いてんだろうという気分になるわけですが。。。
お分かりの通り転向者のパーセンテージを見て、広き門だ、狭き門だ、なんて主張すること自体があまり意味が無いわけですよね。
ぶっちゃけていってしまえば、他業種、他業界からの転向者の多寡なんてのは、その業界に対する求人需要の差異の現れなだけで、それをもって「SIer⇒自社Webサービスは非常にハードルが高いのです。」ってのは些か話が飛び過ぎってもんでしょう。
paizaには認識されてないSIerで身につけられる技術
paiza社の記事で一貫しているのは、「働く個人としては低スキルでも働けるようになっており、スキル向上の場がない」、つまり、SEはスキルが低いという主張しているわけですね。
いや、もしくはプロジェクトマネジメントぐらいしか身につけられるスキルが無いと。。。ホントかい。
SIerは個人個人のスキルが無くても、プロジェクトを細かくタスク分解し、誰にでもできる作業に落とし込んでいく事で、属人性を排し、多重下請け構造で巨大なシステムを作れるように仕組化されています。
それができるなら、ウチのチームのメンバーはとっくの昔に全員オフショアにしているっての。
タスクを分解することは、「誰にでもできる作業に落としこむ」のではなく「求められるスキルセットに合わせた仕事に分解する」ってのが正解です。
例えば、ヨーロッパなどではSEの仕事として
- システムアーキテクト
- エンタープライズアーキテクト
- システムアナリスト
- ビジネスアナリスト
- アナリストデペロッパ
- ソフトウェアデベロップメント (Java/C#/.Netなど言語ごと)
に分けられたりします。
あっちではジョブ型雇用が中心なので、実際に行うスキルセットに応じた雇用が存在するのでわかりやすいのですが、日本はどちらかと言うとメンバーシップ型雇用なので、上記のような欧州では複数のスキルセットとして見られる仕事を横断的に実施することが多い。
上記を見てもわかるように、SEに求められるスキルはかなり多岐にわたっているんですよね。
オッサンみたいなプロマネは、WBSで作業をメンバーのスキルセットに合わせた作業単位に分解することで、各人の得意とするスキルに合わせた円滑な仕事をできるようにするというわけですよ。
属人性を無くすとかってのは、どちらかと言うとサービスを維持するための話。「誰でも出来る」の冠詞には「必要なスキルが有る人なら」が隠れているわけ。
エンジニアとしてのスキルがいらない、って話とは違います。当たり前なんだけど。
で、上記の様にWBSごとに作業を分けたとして、アサインする仕事を変えたり、そもそもタイプの違う仕事をスキルの身につき方は変わってくるわけで、成長しないなんてことはないわけで。
そもそも業界理解が甘い
ここまでがメインなのであとは細かい指摘を。。。
銀行なら「 地銀共同センター」や「NEXTBASE」、保険なら「e-JIBAI」とか知らないのかな？
金融系って昔からASP(要はSaaS)の利用が活発だったりするのですけど。。。
ここで銀行保険を例示するのは適切じゃあないですね。
システム内製化でSIerへのシステム外注より競争力を高められるのか - プロマネブログでも記載したんですけど、オントレ証券なんかではITが事業のコアとなっているわけですが、外注率が高い。
「人材教育・評価体制の構築」「外注価格と外注先のスキル」「事業の撤退可能性と容易性の確保(逃げ道戦略)」「IT以外の営業戦略の存在と比重」「予算の固定化/流動化」「法・政治リスク」「セキュリティ」などのファクトが存在し、内製化が良いのか、外注が良いのか判断したりするわけで、単純にコアコンピタンスだから内製化する、ってほど簡単な問題じゃあないです。
他にもありますが、このぐらいで。
まとめ
paiza社の記事見ると、ソフトウェアデベロップメント以外のスキルは存在しないと主張しているように見えますが。。。
まあ、ソフトウェアデベロップメントのスキルを商売にしている会社だし、「我々の認定しているスキル以外は存在しないので、paizaのサービス利用してね」ってポジショントークとしては仕方が無いのでしょう。
ただ、他の業界をdisるのは感心できる行為ではないです。しかも、企業広報ブログで。
企業広報が自社のCSRやコーポレート・ガバナンスをあまり考えてないのか。。。
自社の価値を高めるどころか、ヘタしたら自社の価値を下げる可能性は意識してないのかなあ。
繰り返しとなりますが、WEB系で求められるスキルが有るようにSIerで求められるスキルも存在します。
自分の業界ではそのスキルが必要ないって話と、スキルを成長できないって話はまた別物。
それを、「SIerではスキルを成長できない」なんてとらえるのは、ちょっと視野が狭いんじゃあないかなあ。
以上
プロジェクトマネジメントで大切な一つのこと
ほうほうと思って内容見ていたのですが。。。ちょっとだけ。
プロジェクトマネジメントで大切な一つのこと
まあ、プロジェクトマネジメント語る上で、スケジュール管理や課題管理など、色々管理しなければならないことがあります。
PMBOKでは、以下の様なことを管理しろとあります。
- 総合管理
- スコープ管理
- タイム管理
- コスト管理
- 品質管理
- 人的資源管理
- コミュニケーション管理
- リスク管理
- 調達管理
- ステークホルダ管理
教科書的には上記のような管理が大切なのできちんと行いましょう、というのが答えになるんでしょうけど、それだけだとつまらないので。。。
オッサンが考える、プロジェクトマネジメントで一番大切なことは何か、と聞かれればぶっちゃけ「計画」かな、と答えます。
要は、不確定要素がなくやるべきこと明確で、ステークホルダーの誰もが文句を言わないような状態に持ってきて。で、スケジュールも余裕。予算もきちんと抑えた状態。こんなだれでも勝てるプロジェクト計画立てられるようにすることが重要と。
・・・まあ、プロジェクトの進め方の答えが事前にわかってれば、淡々と仕事進められるわけで当然なんですけど。。。
実は、PMBOKなんかでも「計画」を重点的に記載してたりしてるんですよ。
プロジェクトは変化していくもの。なので、この前提に立って変化に耐えられるような実行→監視→再計画のフィードバック管理も重要なのですけど、それらの変化すらも予想できるような計画立てられれば更にスムーズなプロジェクト運営ができるだろうと思います。
計画段階で落としこみができていれば楽
プロジェクト計画ってわりかしおろそかにされたり、場合によっては読めないからとりあえず開発しようなんて進められたりもします。これもまあ一つの答えであるわけですが。。。
※この場合は、リスクが積み上がった状態でプロジェクトが進められていることとなりますね。
ただ、気をつけなければならないのは、「スケジュール管理」や「課題管理」として実行の場に出てきた問題ってのは、事前の計画段階で潰しこみができていれば半分以下、場合によっては1/10よりも小さな労力で対応できることもしばしばです。
後手後手の対応では、どんどんコスト・労力が積み重なってきてしまい、対応にかけるリソースが不足してきます。エスカレートしていけば、ついにはデスマーチに突入となってしまいます。
コスト管理やリソース管理は重要です。それが成立してなければ、スケジュール管理や情報共有の仕組みも機能しません。
デスマーチ状態に陥った場合、ちょっとやそっとのスケジュール管理や課題管理では焼け石に水状態だったり。デスマーチ状態での課題・問題分析は精度が下がったりすることもあり、更に傷口を広げることもあります。
なので、デスマーチに陥らないよう事前にどうすれば最小の労力、最小のリスクでプロジェクトを達成できるか、計画をたてることが重要ってわけですね。
てなわけで、早め早めに対応するよう、実行段階の管理も重要なのですが、それ以上に計画をマネジメントすることが重要だと思うわけですよ。ついでに言うと、実行段階で出てきた課題や問題の振り返りをきちんと行い、次回のプロジェクトの計画の精度を高めるようにすることが大切だったりも。
まとめ
実は、オッサンも昔は「スケジュール管理」や「課題管理」などの実行プロセスを血眼になって追っかけていたのですが、それでは見えないコストばかり積み重なってきてしまい、残業だなんだと疲労の毎日になってしまったのですね。
それからというもの、計画段階で如何に楽で勝てる計画をたてるか、ということに注力するようにしました。
慣れてくれば、中小規模の案件なら、前述した理想状態のプロジェクト計画を立てられるもので、スケジュール管理や課題管理などであまり苦労することなくプロジェクト進められますよ。
大規模案件ではなおさら。計画段階できちんと先読みができるかどうかで、その後の労力は段違いです。
なので、元増田氏の語るように実行段階のマネジメントも重要なのですけど、もう一步進んで計画をマネジメントすることも気をつけたほうがいいんじゃないかなと。
プロマネに求められる重要な素養として、幅広い情報収集能力と、現状分析や経験から、未来を予測し、早期に問題発見できる能力になるんじゃないのかな、なんて思うわけです。
※情報共有についてなど他にも語りたいことがあったのですが、だるくなったのでこのぐらいで。。。
以上
プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第５版 (A Guide to the Project Management Body of Knowledge)
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2014/02/15
- メディア: ペーパーバック
- この商品を含むブログを見る
指摘密度だけでレビュー品質をチェックするPMOは仕事をサボっているも同然
ひと通り笑ったので。。。
用語統一厨は結構重要な指摘
用語統一厨 「"お問い合わせ"は"お問合せ"と表記することに決まってるので」
元増田ではクソレビューアに「用語統一厨 」が挙げられているわけですが、結構この指摘って重要なんですよね。
というのも、オフショアとの開発やっていると、用語一つ一つが認識相違の致命傷となることがよくあるから。
オフショア側の人間ってやっぱり日本語に慣れてないこともあるので、用語がバラバラの設計書を渡したりすると、日本人からすれば同じ意味と把握できるような単語でも、別の読みや言葉として認識したりする場合もあったり。
オフショア開発で痛い目にあった、という人の話を聞くと、用語の統一や表記の統一みたいな、日本人からすると些細な部分できちんとコミュニケーションをとれてない場合があります。
でも、これってドキュメントを上手く解釈してくれるよう読み手に甘えている部分でもあるので、書き手の責任としては、きちんと用語を統一するように書くのが正解じゃないかな、と思います。
指摘密度と品質の関係
PMO 「指摘密度が基準値に満たないので、その他なんでもいいので指摘ありませんか?」
合同プロジェクトなどにチームで支援にいったりすると、PMO部隊が支援チームのPMの活動を分析したりすることがあります。
なので、オッサンがレビューした結果に対して合同プロジェクトのPMO部隊から「レビュー指摘が足りてないんじゃないですか？」なんて言われることまれにあります。
現場見てないので、数値で判断するわけですね。
その度に「いや、ウチのチームとしては十分レビューできているって」なんてバトルになったりすることもしばしば。
そもそも指摘密度って何か。
指摘密度自体位は、過去の類似プロジェクトにおけるレビューの実施状況から、「おおよそ１Pあたり○○件～XX件の指摘が発生する傾向がある」という結果より、レビューが適切に行われたかどうかを判断する指標となります。
上記の下限値より指摘密度が小さい場合、レビューできちんと問題点を指摘できてないんじゃないだろうか、上限値より指摘密度が大きい場合、そもそも成果物品質が悪いんじゃないだろうか、みたいな感じで使うわけです。
さて。上記の評価ですが何が問題か。
決定的な問題としては「質的な面で品質評価してない」ってことです。
例えば、レビューイが前回初めてドキュメントを作成した人で、今回修正内容について設計内容を熟知している場合、当然2回めの修正は慣れがありますので、指摘件数が少なくなる傾向があります。指摘は少なく、品質は向上するってパターンです。
逆に、レビューアが前回とは異なる人物で、体裁や表記があまり理解できない場合、自分の理解しやすいドキュメントでないと成果物とならないなんて考えた結果、表記や体裁等の指摘が増える傾向があります。この場合は、指摘は多いものの、あまり品質に変化なしってパターンです。
又、そもそも前述したPMO部隊がチェック基準としている指摘密度が、過去品質の悪いプロジェクトのものを採用していたりもして、ノウハウやドキュメントをきちんと整備したオッサンのチームのレビューで使うには、あまりにも状況が乖離していたりも。
とまあ、色々なパターンが考えられるわけですが。。。
要は指摘密度から外れても品質面は変わらない、あるいは向上しているパターンがあるってことをきちんと把握しなければならないわけですね。
まとめ
結局のところ、指摘密度は「品質を保証するための指標」ではなく、「レビューの場面で前回と異なる何かが起きたアラート」だと思うのが適切だと思うのですよ。
PMOはレビューの品質を指摘密度といった数字で判断するのではなく、指摘密度でチェックに引っかかったレビューの定性評価をきちんと行うことで判断しなければ、きPMOとしての品質評価にならんと思うわけです。
言い換えれば、指摘密度だけでしか品質を判断しないPMOは仕事サボっているのと同然になってしまう、と思うわけです。
以上
WEBサービス会社のはてながSIerからシステムを買ったこと
getlife - 『ミロク情報サービス×はてな、CFO対談 「上場の意義」…』 へのコメント
2014/10/22 08:59 にブックマーク
へー、はてなってミロクさんの会計パッケージ使ってたんだ。
知らなかった。
「WEBサービス会社」のはてながSIerからサービスを買った理由
SIerで働いている人ならあまり違和感ないんですけど、業務システムに詳しくない人だと「はてなって内製でサービス作っているのに、なぜSIerからサービス買うの？」と思った人もいるんじゃないかと思ったので、ちょっとだけ。
企業の業務システムは、色々な分析方法がありますが、一般的なのは顧客との距離ごとに「フロントオフィス」「ミドルオフィス」「バックオフィス」に分けて機能分析を行うことが多いです。
フロントオフィス
顧客との直接的な営業活動を行う機能に対して働きかけるシステム。CRMやコールセンタシステム等。WEBサービスもここに含まれる
ミドルオフィス
企業収益活動の中心となり、営業の実行と企業戦略を統括するシステム。ミドルオフィスと合わせてバックオフィスと呼ばれることも。
バックオフィス
円滑な企業活動を支援するための間接機能を管理するシステム
イメージ的には以下の図のような形となります。
さて。
はてながミロク情報サービスから購入したのは、「MJSLINK NX-I」。財務会計を中心とした業務システムで、バックオフィスからミドルオフィスの入り口までの機能を管理するシステムとなります。
一般にバックオフィス機能のシステムですが、
- 仕様変更が少ない
- 変更時のスコープ管理がしづらい(制度変更など、お上の都合で仕様変更が要求される)
- システムリリース期限の自由が持ちづらい(お上の都合で決まることがある)
- コストセンターである
と言った特徴をもつシステムと言われてます。
上記の特徴は、アジャイル開発等のWEBサービスでよく使われる開発スタイルと相性が非常に悪く、内製化だとどうしても高コスト化しやすい部分であり、維持するモチベーションを持ちづらい。
なので、ERP導入したりパッケージ構築、SaaSやASPなどSIerのサービス買うのが合理的と考えてます。
※そういえば、以前はスクラッチで作ってる事例もありましたけど、最近はトンと聞かないですね。。。観測領域だけなのかな。
なので、今回のはてなの判断は、IT投資管理上合理的な判断だと思います。
エンプラシステムとして見た場合のはてなのシステム構成
比較的モダンなエンプラシステムでは、フロントもミドルもバックも全て共通のEBSに載せたSOA形式でアーキテクチャ組むこともありますが、記事を見ただけでははてなの事例ではそこまで全体最適化されたエンプラアーキテクチャになってなさそう。
上場ぐらいまでなら現状でも大丈夫かな、と思いますが、さらなる事業拡大を考えた場合、いずれかのタイミングでアーキテクチャの改善が必要となる場面があるんじゃないかな、なんて思います。
まとめ
そういや以前、
相互の能力需給関係のマッチングがあるからこそ、ユーザは高いカネを支払ってでもSIerに仕事を依頼したい。
別に、ユーザはシステムの規模が大規模だからSIerへ仕事を依頼するわけではありません。規模はただの一要因。大小関わらず、比較優位の原則に従いSIerに仕事を依頼することが合理的であれば、ユーザ企業は仕事を依頼するだけです。
と書いてpaiza社のSIerへのDisに文句たれてたわけですが、まさにその反証を同WEBサービス企業であるはてなが実施しているかたちになったことにちょっとオドロキ。
はてなは、きちんとIT投資管理を理解しているんだなあ。
まあ、WEBサービス業も企業である以上は収益性等の考慮が必要なわけで。。。
はてな含むWEBサービス業では、収益を最大化するためには、どこまで内製化するのか、どこまで外注するのか、と言った見極めが必要な分、CIO等経営層に求められるIT投資管理は重要性を増すのじゃあないだろうかなんて思うわけです。
以上
プロマネの価値を発揮できる場所
最近、PMBOKの再勉強していたらすっかりブログの更新を怠ってました。
ちょっと前に読んだ記事ですけど、自分なりの考えを書きたいなって思ってたんですよね。
元記事はプラントの話でソフトウェア開発とは若干違うのですが、感じるところがあったのでちょっとだけ。
プロジェクトは順調で在り続けられるのか
最初から最後まで順調な仕事では、プロジェクト・マネジメントなんて、ほとんど何もすることがないはずなのだ
コレは全く疑うことがないことで、順調な局面はプロマネのすることなど何もないです。言い方を変えれば、順調な局面に抑えることができなければプロマネの忙しさはうなぎのぼりであり、ときとして過労死寸前の生活が当たり前という過酷な状況となることもしばしばです。
システム開発の現場では、何もしなくても最初から最後まで順調で在り続けられるというのはかなり難しいと感じてます。
小規模で要件も明確、誰もが同じコンセンサスで活動可能な案件であれば、最初から最後まで順調というのは難しくない反面、ちょっとでも規模が大きくなると、開発が進むにつれてアヤシイ状況が発生することもしばしばです。
こういう問題が生じるのは、案件規模が大きくなればなるほど、ステークホルダーが増えてきて、それぞれ目する「プロジェクトの目標・あり方」、つまりプロジェクトの姿が異なることにほかならないかと思います。
知的活動としてのシステム開発とプロマネ技術
では、なぜステークホルダーが増えるとプロジェクトの姿の見え方が変わるのか。
これは、システム開発が知識集約的な仕事*1だからにほかならないかと思ってます。
要は、システム開発の現場が顧客の考えた要望、アーキテクトの考えた理解、SEの考えた判断、プログラマの考えた発想といった知的活動に支えられているから。
作業手順書を作れば仕事ができるわけでもなく、また、ITやツールや機械によって自動化される仕事でもなく、人間の考えが必要な仕事だから。
で、それらの知的活動を行う人間を作り上げた経験、学習履歴といった土台が異なるがゆえに、向いている方向がバラバラになってしまうと。
そういったコンセンサスは、関わる人間が少ない小規模開発案件であれば発散しづらい反面、関わる人間が膨大となる大規模開発案件であれば、四方八方に発散してしまうと。
で、それらの人間がきちんと同じ目標に向けて活動できるようにするためには、個々人の考え、思いをきちんと整理し、動機づけを行い、組織としての活動に転換できる技術としてプロジェクトマネジメント技術が必要になるんだろうと思うわけです。
※これだけだと、プロマネ技術中のステークホルダーマネジメントだけですけど。。。
補足：SIが「労働集約」と呼ばれること
ときおり「SI産業は人月商売だから労働集約産業である」なんて言説を時折見かけるのですが。。。
他にも知識産業と呼ばれるコンサルや研究産業だって、準委任契約結べば立派な人月商売になってしまうオチなんですよね。
※「産業」ではなく「収益構造」ということなのかな。であれば理解できるんですけど。。。
元々、知識集約産業が通産省構造審議会で規定された時「知識集約型産業は労働集約型産業である」という言葉で語られてました。
要は、「知識を発揮するのが人間である以上は、労働集約に必ずなる。労働集約と知識集約産業を分けるのは単純労働か知的労働かの差である」と規定されてました。
「知識集約型産業」の言葉の定義に照らし合わせれば、受託開発は「知識労働集約型産業」となり、サービス開発は「知識資本集約型産業」と呼ぶのが正解かな。
まあ、本当にSIの現場が単純労働的な労働集約的ならば、さっさと仕事のやり方マニュアル化して、それこそ誰にでもできるような仕事にして儲かるようにできるんですけどね。
まとめ
誰しもがマニュアルに従って動く労働集約の仕事や、機械が動き続ける資本集約の仕事の中でプロマネ技術が活きることは無いでしょう。
そういった現場で必要となるのは、また別の管理技術。
繰り返しとなってしまいますが、プロジェクトマネジメント技術が価値を発揮できる局面は、「（本来の定義の）知識集約」の仕事の中でこそだと思います。
以上
プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第５版 (A Guide to the Project Management Body of Knowledge)
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2014/02/15
- メディア: ペーパーバック
- この商品を含むブログを見る
*1:参照 ： 知識労働集約型産業としての視点から
ICTイノベーションを競う「global ICT awards」で日本企業がわりと活躍している話
「TRUE TELLER」が「世界情報サービス産業機構 IT賞」を受賞 | 野村総合研究所(NRI)
世界情報サービス産業機構（World Information Technology and Services Alliance、WITSA((Witsa | World Information Technology And Services Alliance、世界70カ国以上のITサービス業界団体により構成される国際組織」）主催の世界情報技術産業会議（WCIT）にて「global ICT awards」という賞があるのですが、6年ぶりに日本企業が受賞したとのこと。
「global ICT awards」って何？
global ICT awardsというのは、公共分野ITユーザ、民間ITユーザ、デジタル格差解消を促すITユーザ、審査員グランプリの4分野で評価されるコンテストです。
世界最大級のITサービスカンファレンスである世界情報技術産業会議（WCIT）にて、隔年で審議、投票された受賞企業が発表されてます。
ICT技術を用いて、企業の競争力、顧客満足度を高めるといったイノベーションを発揮した企業に贈られる賞となります。ITイノベーションを用いて業務革新を行っている企業を称える賞というわけです。
日本では過去4社1団体が受賞してます。
| 受賞年 | ユーザ企業・サービス | 開発ベンダー |
| 2000 | セブン-イレブン ジャパン「第5次総合情報システム」 | NRI，NECなど |
| 2004 | JR東日本「Suica」 | JR東日本情報システムなど |
| 2004 | 横須賀市 「電子入札システム」 | NTTコミュニケーションズなど |
| 2006 | KDDI 「固定系事業システムの構造改革」 | DIRなど |
| 2008 | JFEスチール 「新統合システム（J-Smile）」 | ＪＦＥシステムズ、エクサ |
NRIはベンダの立場としては、2度めの受賞となるわけですね。
日本だと業務システムを中心に受賞している感じですが、海外だと教育系ウェブサービス（ギリシャ）、クレジットカード決済サービス（カナダ）や、クラウド構築のためのアプライアンスサーバ（台湾）等で受賞していたりもします。
ユーザ企業で有名なのは、フィンランド航空やアジアエアラインなど、受賞しております。
公共機関では、電子政府や保険などを達成できた団体が受賞してます。電子政府を構築したことで有名な韓国も受賞してます。
オバマ大統領の「Open Government Initiative」が受賞してたりも。
日本は受賞数２位
毎年６～７企業、団体が受賞する「global ICT awards」ですが、2000年を初めにおおよそ５０企業、団体が受賞しております。
2014年版の受賞企業の一覧がまだ見つからなかったので、2000年から2012年までのTOP10まで集計してみると、以下のようになります。
| 順位 | 国 | 受賞数 |
| 1 | アメリカ | 9 |
| 2 | スペイン | 5 |
| 2 | 日本 | 5 |
| 4 | マレーシア | 4 |
| 4 | 香港 | 4 |
| 4 | 台湾 | 4 |
| 7 | ギリシア | 3 |
| 7 | 韓国 | 3 |
| 9 | カナダ | 2 |
| 9 | シンガポール | 2 |
| 9 | フィンランド | 2 |
ICT技術なので、ダントツのトップはいつもどおりアメリカなのですね。
ドイツやフランスといった欧州各国が少ないですね。オランダが次点としてノミネートしていた年があったので全くエントリしてないわけではなさそうですが、あまり評価されるようなシステムはないのかな。
日本はアメリカに続いての2位です（スペインと同順）。
世界的に見ても日本はICTイノベーションをトップクラスで達成できている国ってわけなんですよね。
まとめ
ITProあたりで「日本のSI構造ではイノベーションが生まれない」なんて散々言われているわけですが、実際蓋を開けて見れば、世界的に日本発のシステムがイノベーティブとして評価されているわけで。
GoogleやAmazonみたいなBtoCのわかりやすいイノベーションじゃ無いから、日本のユーザ企業とベンダのイノベーションに気づいてないだけじゃないかな。
まあ、ユーザ企業の挑戦と、SIerの技術が合わされば世界的に評価されるイノベーション生み出せるっていう証左かな、なんて思います。
余談
ただ、この話ってSIerの海外営業売上高比率が低いっていう事実と照らしあわせてみれば、「世界で評価されるイノベーションを作れる技術力はあるが、それを海外に売ることができる営業力、販路、売り方に難がある」っなるわけですよね。。。
これはこれで問題だよなあ。
以上
ITロードマップ2014年版: 情報通信技術は5年後こう変わる!
- 作者: 野村総合研究所先端ITイノベーション部
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2013/12/20
- メディア: 単行本
- この商品を含むブログ (3件) を見る
