TOP業界裏話注目ニュース徒然コメントリンク紹介
『外資系企業に住む住人の視点からIT業界の出来事を伝えます。』

資料作成本の最後の秘境『ワード』を対象とした外資系コンサルの資料作成テクニックが1冊の本になりました。2017年3月29日に発売されています。
※購入頂きました皆様、ありがとうございます。
https://www.amazon.co.jp/dp/4492557776

gaishi_word_201703_new.jpg
累計数十万部を数える「外資系〜シリーズ」には「スライド作成術」と「Excel作成術」がありますが、ワード向けの本はありませんでした。パワーポイントとエクセルは一生懸命練習するのに、ワードの作成法を学ぶ人はほとんどいません。見よう見まねの作成が繰り返され、ワード文書はどんどん読みづらい存在になっています。その結果、「ワード文書は扱いにくい」と考えられるようになりました。この本は、最後の秘境、ワード向けの「文書作成術」です。優れたWord文書を効率よく作成する方法を知り、適材適所でビジネス文書を作り分ける術を自分のものにしましょう。


【吉澤準特の本:累計10万部以上】
外資系コンサルが実践する資料作成の基本』はロングセラーで重版多数
外資系コンサルの仕事を片づける技術』はロングセラーで重版多数
フレームワーク使いこなしブック』はロングセラーで重版多数
兄弟本の『ビジネス思考法使いこなしブック』はロングセラーで重版多数

【吉澤準特の過去配布レポート】
「外資系コンサルの仕事を片づける技術」特別抜粋版のダウンロード
「最新会議運営の基本と実践がよ〜くわかる小冊子」のダウンロード
できる人の9つの法則
コンサルタント直伝!コミュニケーションのプロになれる!


IT業界の裏話(まぐまぐ殿堂入りメルマガ)へ
メルマガ登録ならコチラ メルマガ解除ならコチラ
メールアドレス:
メールアドレス:



2013年05月31日

ベンダーの言うことを信じた結果、システムの欠陥を直してもらえなかったユーザー
このエントリーを含むはてなブックマーク

IT業界では、システム開発にまつわる訴訟トラブルが最も多く発生します。

ベンダー側の立場で話を聞くと、「ユーザーが自分たちの責任を全うしてくれないから、ベンダー側の作業遂行が滞る」というケースを数多く耳にします。ですが、ユーザー側の立場で話を聞くと、契約書を持ち出して不誠実な対応をするベンダーへの不満もあることに気づきます。今回はそれを見ていきましょう。

以下の事例は経産省のモデルケースに掲載されていたものです。

【トラブル内容】
一般廃棄物処理業者であるユーザーは、ベンダーに対して、基幹業務ソフトの開発を委託した。ソフトはベンダーが開発した後、ベンダーの関連会社であるリース会社Aに売却され、Aからユーザーに対してリース物件として引渡される予定であったところ、ソフト製作請負契約の契約書は作成されず、ベンダー・A間でリース契約書が作成されたのみであった。納品されたソフトに欠陥があったため、ユーザーはベンダーに対し、請負契約の債務不履行を理由に損害賠償を請求。

【ユーザーの主張】
リースは単なる支払の手段にすぎず、実質的には、ユーザとベンダとの間でソフト開発の請負契約が成立していた。

【ベンダーの主張】
ユーザはリース会社とだけ契約しており、ユーザとベンダの間では、報酬や代金の支払約束がないから、請負契約は成立していない。

このケースでは、ユーザーの支払手段としてリースが利用されたため、リース会社に対してはリース契約がありましたが、ベンダーに対しては契約書が作成されていません。ユーザーがベンダーに対して、契約上の責任を追及するためには、双方間で、何らかの契約関係がなければなりませんが、それがなかったため、契約関係の有無自体が争われることとなったのです。

さて、このケースで裁判所はどのような判断を下したでしょうか?

答えは、ユーザー側の一部請求容認です。仕様書、提案書、基本設計書のやりとり及びその打ち合わせ議事録の内容から、ユーザーとベンダーは、本件ソフトの製作について、数回の交渉を経て、その内容を確定し、それに従って請負契約を締結したと判断しました。リース契約は、金融を得る手段に過ぎず、ベンダーが作成したソフトに不具合がある状況では、ベンダーに債務不履行があったと認めたのです。

このような紛争を避けるため、リース契約を使う場合であっても、ユーザーとベンダーとの間で、ソフト開発委託契約書などを作成しておくべきだった、というのが、このケースから直接的に得られる示唆です。

ざっと読むと、「ひどいベンダーに引っかかった、ユーザーは災難だった」と感想を抱くぐらいの話でしょう。しかし、これはベンダー側だけに非があったかと言えば、そうではありません。

前回のエントリーで紹介した『なぜユーザーはITも業務も詳しくないベンダーへ発注するのか』で、ITのことをベンダーへ任せっきりにするユーザーの姿勢が問題であることを取り上げましたが、上記のケースも結局は同じ話です。

要は、ユーザーには稼働後に発生するソフト不具合への対処アプローチについて想像力が欠けていたため、そうした事態を踏まえた契約条項を取り入れることができなかったのです。

このことを、「それくらいはベンダーが進言することだろう」と憤慨するのではなく、「細部を詰めないユーザー側の非も大きかった」と捉えることができる人は、性悪説に基づいたリスク管理の感覚を持っていると言えます。個人的な感想ですが、こうした人材がユーザー側の実務担当者にいれば、IT業界のトラブルは半減するんじゃないでしょうか。

あなたの周りにこうした人はいますか?いないなら、あなた自身がそうした役割を担えるようになれているといいですね。

posted by 吉澤準特 at 15:03 | Comment(0) | TrackBack(0) | 業界裏話

2013年05月29日

官公庁の本気:政府統計全データの自動分析機能をインターネットで公開
このエントリーを含むはてなブックマーク

日本の官公庁のIT活用と聞いて、みなさんはどんなイメージを思い浮かべるでしょう。

システム開発の案件に関わったことがある人なら、あまり先進的な印象を持っていないのではないかと思います。私も以前、「官公庁が情報システム半減に取り組む前にやるべきこと」というエントリーで、こんな話を書きました。

特に、これからますますデータ活用が重要になってくるのですから、データガバナンスと言いますか、データのサプライチェーン(データSCM)を本格的に構築することを考えてもらいたいです。最終的にどんなことがしたいのか、という視点で必要となるデータを整理し、それを受け取るための最適なサプライチェーンを構築する、という利用者中心の考え方でデータフローを描くためには、統計情報を管理する部門も併設した方がよいですね。

実は、総務省には”統計局”という、政府統計を横断的に体系整備する部門があります。この組織の管理下のもと、独立行政法人統計センターというところが、”e-Stat”という政府統計のポータルサイトを運営していました。

これまで、このe-Statでは、各省庁が公開した統計情報(詳細データ含む)をアーカイブしてきました。リンク体系を整備し、検索機能も付けてあるので、けっこうカンタンに政府統計情報を一元的に検索することができ、統計情報を仕事に使っている人たちからは好評を博していたように思えます。

しかし、前述のエントリーで書いたように、データの提供元となる各種官公庁からユーザーの元までシームレスに提供できる仕組みが備わっていたかと言えば、そうではありません。

たとえば、提供されるデータの多くはExcelですが、一部PDFだけの資料もありました。また、Excelシートについても、資料のフォーマットは省庁ごとにばらつきがあり、ユーザーは各自でダウンロード後、目的に合うよう、毎回各自が手元でフォーマットを加工するという手間が発生していました。

こうした状況を踏まえて問題提起をしたのが前述のエントリーでしたが、去る5/28、総務省から以下のプレスリリースが発表され、ついに政府のデータガバナンスへの本気度がじわじわと明らかになってきました。

現在、政府全体でオープンデータへの取組を推進しているところですが、これらの取組をリードする総務省として、政府統計の情報提供のかたちを更に高度化すべく検討を行い、独立行政法人統計センターと協力し、トップランナーとして次のような取組を進めています。具体的には次の3つです。

(1)API機能による統計データの高度利用環境の構築
(2)統計GIS機能の強化
(3)オンデマンドによる統計作成機能・方策の研究

今般、統計局所管の統計データについて、(1)のAPI機能の導入を6月上旬から試行運用開始します。更に、(2)の統計GIS機能強化についても、本年秋を目途に試行運用を開始する予定です。統計データの利活用を促進することで、ビジネス活性化や新規事業開発などを支援してまいります。
http://www.soumu.go.jp/menu_news/s-news/01toukei01_02000024.html

このプレスリリースで最も注目すべきなのは、「(1)API機能による統計データの高度利用環境の構築」です。

政府統計データを取得するためのAPI(アプリケーション・プログラミング・インターフェース)を公開するから、使いたい人は機能を呼び出せば、自動的にデータを受信でき、そのままシステム上でデータ加工をすることができるのです。

これはデータのサプライチェーンを自動化するための仕組みが備わったということであり、国家が集めた膨大な素データを民間企業が簡単に分析できる土壌が整ったと言えます。

今まではリサーチ機関から購入していた政府統計の分析情報も、今後は有志がインターネット上で解析済データを無料公開するようになり、リサーチマーケットにいくらかの影響を与えるでしょう。また、民間企業が直接統計データをシステムに取り込むようになり、これを利用したウェブサービスも多数発表されるようになるはずです。

このサービスはユーザー登録制で6月上旬から試行されます。興味のある方は継続的にe-Statをチェックしておきましょう。

イースタット 政府統計の総合窓口

今後、第二次安倍内閣の下、”世界最先端IT国家創造宣言”(2013年5月25日)にしたがって、オープンデータガバナンスの取り組みはさらに加速していきます。IT業界人の一人として、本政策が完遂されるよう、一貫した政府の姿勢を期待します。

posted by 吉澤準特 at 15:03 | Comment(0) | TrackBack(0) | 業界裏話

外資系コンサルの仕事術が本になります
このエントリーを含むはてなブックマーク

このたび、6月14日に「外資系コンサルの仕事を片づける技術」をダイヤモンド社より刊行することとなりました。今回の本は、外資系コンサルの仕事のやり方をベースに、”仕事ができる人”がやっている仕事のテクニックを体系的に整理した内容となっています。

新入社員/中堅社員/ベテラン社員の視点で、具体的にどんなアクションを起こすべきか、多数の手書きイラストを交えて解説しています。ページ見開きで最低2イラストを含んでおり、「文字ばかりの本は頭に入りにくい」と思っている人にもオススメできると思います。

つい先日、カバーイラストも決まり、あとは印刷されて配本を待つばかりです。詳しい内容は改めてお知らせします。

http://it-ura.up.n.seesaa.net/it-ura/image/book_gaishi_shigoto1.jpg?d=a0

posted by 吉澤準特 at 13:39 | Comment(0) | TrackBack(0) | 徒然コメント

2013年05月27日

なぜユーザーはITも業務も詳しくないベンダーへ発注するのか
このエントリーを含むはてなブックマーク

世の中にITシステムの開発案件は星の数ほどありますが、これほど数が多いと、「なぜこのようなことになってしまったのか」と唖然としてしまう案件も中にはあります。なかでも、発注した自分たち自身がシステムの要件を理解していなかったというケースは、比較的悲惨な結果に陥りやすいですね。

以下は経産省のモデルケースで取り上げられていた事例です。

【トラブル内容】
本件の自治体(ユーザー)では、水道料金収納システムを地元のITベンダに全面的に任せていた。同システムのリニューアルにあたって、同自治体が主導権を握って進めて、費用も低減することとした。まず、同自治体の関連団体であるサービス会社(委託者)に発注し、委託者が受託者に開発を委託することになった。

ところが、委託者には、IT技術の専門家も水道課の業務に詳しい者もいなかった上、受託者は他県の企業で同自治体関係の開発は初めてであったため、仕様策定が難航した。自治体は、水道課担当職員を会議に出席させるなどしたが、意思疎通が十分にできなかった。結局、開発されたシステムには不具合が多く、納期を6カ月延期しても完成に至らなかった。

【ユーザー委託を受けた業者(委託者)の主張】
委託者はシステム開発に必要な仕様を明確にしなかったし、窓口端末の閲覧、借用もできなかった。情報提供も不十分だった。

【受託した業者(ベンダー)の主張】
開発期限を6カ月延長したのに、システムが完成しなかった。

このケースは現在係争中であり、まだ判決は出ていません。しかし、状況内容から得られる示唆はあります。

本件はオープンソースの地理情報システム用ソフトウェアをベースに、水道料金収受システムを開発する計画であったそうです。そのため、ユーザーは、このソフトウェアに詳しいという点を評価してベンダーを選定しました。

選定されたベンダーは他県自治体での実績はあるものの、この自治体のシステムは初めてであり、ユーザー側からの積極的な情報提供が必要であることは当初から分かっていたことでしたが、そのための体制をユーザー側が構築できませんでした。加えて、ユーザが長年にわたって使っていた水道料金収受の従来システムに仕様書は存在せず、ユーザの担当者は利用方法のみを知っているにすぎなかったとのこと。

このような情報不足がある上に、自治体自体がシステム開発に不慣れであれば、「プロジェクト全体を統括するコンサルタントを導入する方法もあり得た」というのが有識者の見解ですが、そのような施策は採られていませんでした。

全体の雰囲気からすると、特許庁のシステム開発頓挫の話に似ていますね。実際、ITシステムを単なるツールと割り切っている組織は官公庁・自治体には多く、職員もシステムの仕組みに興味はありませんから、構築ベンダーの好き勝手になっているという状況が割と見受けられます。

こうした組織では、システム更改に伴うシステム要件の洗い出しが難航する傾向にあります。それだけで済めばまだマシ。今回のケースや前述の特許庁のような、業務要件さえ明確ではなかったということもしばしばあり、これではベンダーはリスクへの備え(コンティンジェンシー)を積み増すばかりです。

その結果が不透明で割高なサービス契約に行き着くことは想像に難くありません。事実、そうした組織との折衝に慣れているNTTデータ社は、データ・通信・サービス契約というどんぶり勘定契約で官公庁・自治体のITシステムを支えています。

ベンダーに対する正当な見積りを要求するには、まずユーザー自身が正当な自己責任を果たすことが肝要です。「ITのことはITベンダーに任せておいて、ユーザーは業務に集中すればよい」との意見を主張するユーザーもいますが、自システムの仕様が不明瞭であること自体、業務が明確になっていないも同然ではないでしょうか。

posted by 吉澤準特 at 18:44 | Comment(0) | TrackBack(0) | 業界裏話

ユーザ「メインシステムが更改したからサブシステムは無償改修しろ、イヤなら改修費用を代わりに払え」 ベンダ「!?」
このエントリーを含むはてなブックマーク

以前のエントリーで、モンスターペアレントならぬ、モンスターユーザーの話を取り上げましたが、他にもユーザーとベンダーのいさかいに関するエピソードはたくさんあります。興味深い事例は経産省がモデルケースとして取り上げられているので、そこから一例を紹介しましょう。

【トラブル内容】
問題となったのは会計処理システムで、システムはメインパッケージと、ユーザ向けにカスタマイズされたサブシステムに分かれていた。メインパッケージは、被告ベンダとは別のZ社が使用許諾権を有し、サブシステムは被告ベンダが有していた。ユーザは、Z社と被告ベンダとそれぞれ使用許諾契約を結んだ。Z社がメインパッケージの2000年問題対応の無償バージョンアップを行ったため、バージョンアップに伴うサブシステムの補修が必要となった。被告ベンダは補修対応費用として1400万円の見積もりを提出したが、ユーザが支払いをしないと主張したため、見積もりを撤回し補修に応じなかった。ユーザが被告ベンダに補修作業費用相当額として1400万円を請求した。

【ユーザーの主張】
ユーザと被告ベンダ間の使用許諾契約は、全体として統合された会計処理システムを構築する義務を負っており、メインパッケージのバージョンアップにあわせてサブシステムを補修する義務を負っている。さらに、保守契約が成立しており、被告ベンダは補修する義務を負っていた。

さて問題です。このユーザーの主張は裁判所に認められたでしょうか?

答えはNOです。裁判所は、ユーザはメインパッケージについてZ社と別途契約を締結していることなどから、被告ベンダは会計処理システム全体について責任を負うということはないと判示し、変更後のメインパッケージにサブシステムを適用させる義務はないとしました。

そもそも、保守契約については、ユーザと被告ベンダ間に結ばれていなかったそうです。いくらなんでも無茶苦茶だな、と思ってしまいますよね。ユーザー企業は、この状態でよくも裁判を起こそうと考えたものだと思ってしまいます。

しかし、もしこのトラブルの内容が、「ユーザーの無知に付け込んで不当な工数費用を請求していた」という事情に基づいていたなら、ユーザーの主張は部分的に認められていた可能性がありますし、非難されるべきはベンダー側ということになります。

つまり、このケースから得られる示唆は、開発契約の際に、被告ベンダの業務範囲(パッケージ側のバージョンアップ作業に対応するサブシステム側の補修作業を行う責任(=システム全体についての責任)を負うか)や費用負担(補修作業を行う場合の費用(有償/無償)の扱い)などを明確にしておくべきであった、ということです。

あなたがシステム開発契約に携わるときには、くれぐれもシステム稼働後の保守フェーズにおける責任分界だけは最初にハッキリさせておくことをお勧めします。

posted by 吉澤準特 at 07:20 | Comment(0) | TrackBack(0) | 業界裏話

2013年05月24日

GIFはギフとは読みません:IT用語の読み方ルール
このエントリーを含むはてなブックマーク

IT業界といえば、外来語が多くてカタカナ表記の専門用語や溢れかえっていますが、カタカナにさえなっていない、英語表記そのまんまのキーワードも少なくありません。そうした用語は、どんな日本語発音をするのか、人によって意見はマチマチでした。

たとえば、安価なPCメーカーとして知られているASUS。2010年秋に日本法人の活動を本格化するに際して、日本語読みはアスース(英語ではエイスース)とすることを正式決定しましたが、それまではエイサスやエイスースなど、人によって呼び方が異なっていました。

今やWeb開発で欠かすことのできないAjaxという技術も、エイジャックスという読み方とアジャックスと呼び方が混在しています。値が入っていないことを意味するNullという言葉も、ヌルとナルの呼び方に分かれますね。

そんな中、これまで永遠の謎とされてきたGIF(ジフ・ギフ)の呼び方を「ジフ」へ統一しようという発表がGIFの生みの親であるSteve Wilhiteからなされました。

『“GIF”の発音に終止符!開発者曰く「ジフ」と言うのが正しかった』
http://getnews.jp/archives/345507

リンク先の日本語ニュースには結果のみが述べられていますが、海外のサイトでは、どうして「ギフ」ではなくて「ジフ」と読むべきなのかを解説しているところがあります。

どうやら、英語の専門家によれば、「i」「e」「y」の前にGがくっつくと「弱い発音”ジ”」になり、「a」「o」「u」の前だと「強い発音”ギ”」にするのが一般的なのだそうです。Giraffeはジラフ、Germanはジャーマンと読みますし、gapはギャップ、guideはガイドと読みますよね。
※Giftでギフトとか、Gigaでギガとかありますが、英語のネーミング・発音ルールからすると、これらは例外扱いなのだそうです。

ちなみに、GIFという言葉は、オックスフォード辞書の2012年ワードオブイヤーに輝いています。名詞としてのGIFだけでなく、「GIFファイルを作る」という動詞としても登録されるとのことです。当時、オックスフォード辞書上ではギフでもジフでもどちらでも呼び方はOKと定義されていたのですが、今回の発表を受けて、「ジフ」という呼び方で統一されることになりそうです。
posted by 吉澤準特 at 10:52 | Comment(0) | TrackBack(0) | 業界裏話

2013年05月22日

瑕疵担保期間を長引かせるためにITシステムの”検収”を終わらせないユーザー
このエントリーを含むはてなブックマーク

システム開発に関わっている人にとって、”検収”という言葉は大きな意味を持ちます。なぜなら、ユーザー側の検収が終わった時点から”瑕疵担保期間”がスタートするからです。

そもそも瑕疵担保期間とは何でしょうか。

法務上の用語なので難しく感じられますが、一言でいえば、「システムにバグが見つかった際に無償で改修することを保証する期間」です。あなたがPCを購入する際に、1年間のメーカー保証は大抵ついてきますよね。購入日から1年以内であれば、故意・天災による破損を除いて、メーカーが無償で修理してくれます。その保証期間をITシステムでは”瑕疵担保期間”という言葉で表現するのです。

民法では1年で設定することが標準的な考え方ですが、システム開発では6ヶ月としているケースが多いですね。これは1989年に発刊された大著『ソフトウェア取引の契約ハンドブック』で次のような記載がされているからです。

『商法第526条は、商人間の売買について、買主は遅滞なく検査をなし、瑕疵を発見した時は直ちに(ただし、隠れたる瑕疵は6か月以内に)売主に通知しなければ、売主の担保責任を追及しえない旨定めている。これは、売主が引き渡し後いつまでも不安定な立場におかれることを回避するための規定である。』

もうすこしカンタンに言うと、「明らかなバグはすぐにベンダーへ伝えて直してもらいましょう。後から発覚したバグは6か月以内ならベンダーで無償対応しましょう。それ以降の対応は、ベンダーの経営に悪影響を及ぼすから、認めないことにしましょう。」ということです。ですから、システム開発ベンダーの方々は、開発後の6ヶ月までが呼び出し対応を受ける期間になるのですね、形式的には。

しかし、ユーザーが大企業である場合、事情が異なります。6ヶ月を過ぎたから、そのあとに出てきたバグには一切責任を負いません、なんて姿勢を取ろうものなら、「あのベンダーは柔軟性に欠けるから次のシステム開発は任せない」というカウンターをもらうことは容易に想像できます。

ただし、曲がりなりにも大企業というのは契約書面を重んじます。そのため、システムの検収時期をできるだけ後ろ倒しにしようと働きかけてきます。もしくは、ソフトウェア取引の慣例となっている6ヶ月検収ではなく、民法一般上の慣例となっている1年の瑕疵担保期間の設定を求めてくることが多々あります。

実際のところ、システムが本番稼働してからでないとバグが発覚しないというたぐいもあるため、ユーザー側は瑕疵担保期間の開始を本番稼働時点とするよう求めてくることには一定の合理性があり、ベンダー側としては、そのケースになったとしても受け入れられるように関係者との段取りを進めておくことが望まれますね。

なお、ユーザー検収にあたっては、見つけた全てのバグの解消を確認できるまでは検収を終わらせるべきではないと考えるユーザーはかなり多いです。これについて、ベンダー側は本番稼働をもって検収完了にするという交渉で臨むのが定石ではありますが、稀に、「バグの発見・解消が終わるまでは本番稼働はしない」という断固とした姿勢をとるユーザーもいます。こうしたケースでは、ベンダー側が「今稼働させないことによる業務的な損失」を説明して納得させるしかありません。

他にも、瑕疵担保期間中にバグが発見された場合、そのバグが解消されてから新たに瑕疵担保期間がスタートするというベンダーにとっては悪夢のような条件を持ち出してくるケースもあります。さらには、瑕疵担保期間の後ろ倒しに伴う、保守サービス期間の延長(通常は設置後5年のところを、瑕疵担保期間が半年ずれたら保守期間も料金据え置き)を求めてきたという話もありました。

ユーザー側、ベンダー側の双方が不当な契約を結ぶことがないよう、一般的な契約文書の内容を知っておいて損はありません。経産省から出されている『情報システム・モデル取引・契約書』が昨今の契約条件の判断基準になっています。契約締結に関わる方々は、このドキュメントは一読しておくことをお勧めします。

posted by 吉澤準特 at 10:28 | Comment(0) | TrackBack(0) | 業界裏話

2013年05月21日

官公庁が情報システム半減に取り組む前にやるべきこと
このエントリーを含むはてなブックマーク

2013年5月20日、政府は省庁情報システム半減をIT戦略の工程表へ盛り込むことを決めました。主に、省庁ごとに存在している人事給与システムを共通化するなど、情報システムの統廃合を行うことで経費を3割削減する見込みとのことです。

『政府は20日、人事や給与など、省庁が個別に管理・整備している1500の情報システムを統廃合し、半減させる方針を固めた。』
http://www.yomiuri.co.jp/net/news0/politics/20130520-OYT1T00703.htm

官公庁の情報システム関連経費(IT予算のうち、維持管理に必要な費用)は、2013年度で5319億円ですから、この3割にあたる約1600億円を恒常的に削減可能という考え方になります。

一般企業であれば、年間総売り上げの1.5%程度がIT予算になるとの統計結果がJUAS(日本情報システムユーザ協会)から示されており、さらにその予算の7割が既存システムの維持管理費になると言われています。

システム統合によるITコストの圧縮効果は、維持管理費の比率を7割→5割へ押し下げる効果(30%の削減効果)があるといったエピソードをガートナーやアクセンチュアが述べていることを踏まえると、前述の試算はそれなりに妥当なラインであるように思えますね。


そもそも、官公庁の情報システム半減に向けた取り組みは、2010年9月にまで遡ります。当時、民主党政権では総務大臣を原口氏が務めており、そのイニシアチブのもとで「国の情報システム運用費3900億円を2020年までに半減させる」という総務省目標が発表されました。

当時のニュースを調べると、日経新聞電子版から以下の情報を拾うことができました。

『現在は中央省庁が持つシステムの数は2059あり、年間の運用費は約3900億円にのぼるという。ネットワーク経由でソフトウエアなどを共用する「クラウドコンピューティング」技術を導入するなど、コスト削減に向けた方策を議論する。総務省の調査によると、大型汎用機(メーンフレーム)の運用費が約1800億円と、全体の47%を占めた。(中略)省庁別では厚生労働省が最も運用費がかかっており、985システムで1500億円を超えた。』
http://www.nikkei.com/news/print-article/?R_FLG=0&bf=0&ng=DGXNASFS03039_T00C10A9EE2000

当時の発表と今回の発表で、システム数と年間運用費の数字がかなりずれている点が気になりますが、それはさておき、この取り組みのキーとなっているのは、霞が関クラウドと呼ばれていた「政府共通プラットフォーム」です。

2009年6月〜10年3月まで事前分析、その後、2011年年9月〜13年3月まで開発・試験を行っており、現在はeラーニング等5つのシステムが稼働しています。今回の政府発表は、この政府共通プラットフォームへ、人事給与システムや高い可用性が求められないシステムを移行しようという話になります。


前置きが長くなりましたが、こうした省庁間を横断するシステム開発の取り組みというのは、大変な困難を伴うものであることは、官公庁の案件に携わったことのある人々の共通認識であると思います。

横断活動によってシステムが共通化された場合、その発注予算と執行権限は1か所に寄せられることになるため、共通化の対象となるシステムを抱える省庁のほとんどが、予算の削減(=権限の縮小)を強いられることに反発を示すことが、その最大の理由です。ですから、省庁間の調整事が多かった総務省の関係者は、過去の政権下で大変もどかしい思いを重ねてきたものです。

ですが、民主党政権下で、良くも悪くも政治家主導のシナリオが練られ、後を継いだ自民党安倍政権も、今のところは省庁間の論理に振り回されずにコトを運んでいるように見えます。この調子で、カタチだけではない、本質的な政府共通プラットフォームの推進を期待したいですが、そのためには、情報システムに関する調達ルールの改善にも着手しなければなりません。

以前のエントリーで、分離調達を取り上げました。

『(前略)要件定義と設計フェーズを分断するのは、システム開発上のポジティブな意味はほとんどありません。むしろ、設計に責任を持たない人たちが好き勝手に要件定義を行って、絵に描いた餅が出来上がってしまうリスクを高めます。そうさせないためには、要件定義をしたベンダーが責任を持ってい設計・開発を行うように調達計画を定めなければなりませんが、今の仕組みはそうなっていません。』
http://it-ura.seesaa.net/article/351543994.html

これに加えて、共通化業務については、その決定権を既存の一省庁に集中させるのではなく、政府内でエンタープライズ・アーキテクチャの立案・構築を主導する特命組織を立ち上げ、そこにグランドデザインのとりまとめをさせる。状況次第で、永続的に独立省庁とするか、既存の省庁に統合するかを検討する。これくらいのことを実現させることが必要ではないかと考える次第です。

特に、これからますますデータ活用が重要になってくるのですから、データガバナンスと言いますか、データのサプライチェーン(データSCM)を本格的に構築することを考えてもらいたいです。

最終的にどんなことがしたいのか、という視点で必要となるデータを整理し、それを受け取るための最適なサプライチェーンを構築する、という利用者中心の考え方でデータフローを描くためには、統計情報を管理する部門も併設した方がよいですね。

米国ではオープンガバメントとして知られている取り組みを、是非日本国内でも同時に取り組んでほしいと願っています。

Project Open Data
http://project-open-data.github.io/

posted by 吉澤準特 at 10:50 | Comment(0) | TrackBack(0) | 業界裏話

2013年05月16日

デビルズアドボケイトが上手い田原総一郎、下手な蓮舫
このエントリーを含むはてなブックマーク

以前、「デビルズ・アドボケイト」という言葉をブログで取り上げました。

http://it-ura.seesaa.net/article/14400485.html

デビルズ・アドボケイトとは、わざと相手の意見に反論し、議論を盛り上げ活発にする目的で用いられる手法であり、討論では一般的に用いられるスタイルです。よく「朝まで生テレビ」で、田原総一郎がコメンテーターの真意を引き出すために、わざと喧嘩口調で反論をぶつけていますが、あれこそ、まさにデビルズ・アドボケイトです。

たとえば、システム開発のテストコンディションを考える際に、次のような視点で自問自答する、もしくは設計チームが作成したものをレビューするのもデビルズ・アドボケイトの視点が活かされます。

「この機能が無かった本当に業務は回らないのか?」
「こんな不正データを流したら、データが流出するのではないか?」
「不正操作でシステムを停止させることができるのではないか?」

相手から意見を引き出すことが上手な人は、デビルズ・アドボケイトに長けています。「敢えて言わせてもらうなら〜」などの切り口で根本的なテーマを話題にすることは、クリティカルシンキングができているからこそです。

クリティカルシンキングは、状況を掘り下げて、「なぜそうなのか?」「本当に正しいのか」を問い続けることから、批判的思考・探求思考と呼ばれることもあります。次の例を考えてみましょう。

『何年も業績が低迷していた同業のA社は、インド進出を機に売上が右肩上がりで増収増益となっている。一方で、わが社は長期にわたって売上が低下しており、収益も減少している。この状況を打開するには、わが社もインドに進出するべきだ。』

この意見は、「似たような境遇にあったA社が増収増益なのはインド進出をしたから」であり、「増収増益となっている」状況に至ったと述べています。だから、わが社もインドに進出すれば同じ結果を得られる、という論理です。

しかし、よく考えてみると、インド進出の時期から業績が上向き始めたと言っているだけで、インド進出自体にその理由があるとは捉えるのは論理の飛躍です。単に、インド進出と時期を同じくして商品開発やマーケティング上の大成功があっただけかもしれません。

売上増に伴ってA社がやってきたことをすべて検証できれば、より確実な原因を探り当てることができます。一方で、すべてを検証すると時間がいくらあっても足りません。分析作業に膨大な時間を費やして実行着手のタイミングが遅すぎないことを意識することが、クリティカルシンキングでは重要です。

話を戻しましょう。

民主党政権の頃、事業仕分けでスパコン事業に対して蓮舫議員が、「2位ではダメなんでしょうか?」と発言して物議をかもしだしたことがありましたが、これもデビルズ・アドボケイトです。蓮舫議員の真意は、2位ではダメだという強い意見を相手から引き出して、だからスパコン事業の予算はできるだけ削らない方向に持っていこうというところになりました。その意図は国民には伝わらず、マスコミからバッシングを受けまくっていましたけどね。

つまり、デビルズ・アドボケイトは使いどころを間違えると、自分が火だるまになるというリスクを抱えているのです。ですから、自分の発言を評価するステークホルダーのうち、何割かにはあらかじめその意図を共有し、自分の味方になってもらわなければなりません。

さもなければ、「この人は皮肉ばかり口にするイヤな人だ」とのレッテルを貼られて、周りからネガティブな目線で見られるようになってしまいます。これでは議論を活発にするどころか、そもそもまともな議論をしてもらえなくなるでしょう。

デビルズ・アドボケイトを使う際には、発言の前に意図をはっきりと説明することをお勧めします。

posted by 吉澤準特 at 11:25 | Comment(0) | TrackBack(0) | 業界裏話

2013年05月14日

オフィスワーカーの生産性の低さはインターネットのせい?
このエントリーを含むはてなブックマーク

IT業界というジャンルに限らず、PCに向かって仕事をしているオフィスワーカーの人たちは、その生産性が人によってほんとうにマチマチなんだと思うことが多いです。

たとえば、資料から情報を探して一覧表を作成するという仕事があったとしましょう。集中すれば1時間も掛からずに終わらせることができるボリュームです。この仕事を終わらせるのに、だいたいどれくらいの時間を実際に要するのか、見当がつきますか?

2時間です。

どうして倍の時間が掛かってしまうのか。それはPCを使って仕事をしているからに他なりません。特殊な環境でない限り、PCにはブラウザとインターネット接続が標準装備されているため、作業が一区切りすると、そのタイミングでメールをチェックしたり、Webで気になるキーワードを検索したり、ニュースサイトをなんとなく眺めたり、そんな息抜きがたびたび発生します。

これは私の周囲の人たちから聞いた平均的な所感ですが、およそ10分に1回はメールをチェックして、短いメールならば、その場で返信してしまうとのこと。資料上で気になるキーワードがあれば、Googleで検索し、そこから別の公開資料を読み込み始めることも1日1回以上あるそうです。

並行して別作業をこなしたり、情報収集を兼ねたりしているので、一概に生産性が低くなっているとは思いません。ですが、世の中の多くの人はマルチタスクで仕事をすることに長けていません。スタンフォード大学が発表した下記の成果がそれを証明しています。

『(前略)eメールからウェブテキスト、ビデオ、チャット、電話を行ったり来たりして、継続的に多くの情報の流れをさばいている大学生は、マルチタスク作業をあまりしない学生と比べて明らかに結果が悪かった。研究者が特に驚いたのは、いわゆる「重度のメディアマルチタスク作業者」と呼ばれる人たちが、タスクを切り替える能力に関するテストの結果が悪かったことだ。これについては「おそらく、関係のないタスクからの妨害を取り除く能力が低下しているせいだろう」と言われている。(後略)』
http://www.infoq.com/jp/news/2009/09/study-multitasking-performance

これは2009年の話ですが、いまだに巷ではマルチタスクで仕事をすることに問題を感じない人が多くいます。作業と作業の切り替わりによって、自分の中のエンジンを何度もかけなおしていることに気づいていないので、そのたびに生産性が落ちているという事実を認識できていないのだと思います。

あなたの周りには、マルチタスクが恒常化して生産性を落としている人はいませんか? もし、あなたが助言できる立場にあるなら、一度このことを話し合ってもよいかもしれませんね。

posted by 吉澤準特 at 09:54 | Comment(1) | TrackBack(0) | 業界裏話





【IT業界の裏話】過去コラム(No.1-337)
[ TOP ]IT業界の裏話

▼ IT業界の人々
「内製率を高めたい」のに「世界...
人の話を聞かないIT技術者の...
コンサルを目指す学生との対話...
IT業界、悪魔の辞典『ヒト編』
改善は「自分が楽をすること...
近くて遠きもの、プログラ...
IT企業が求めるプログラマ...
ITプロの3割が機密情報に...
10年働くソルジャーが欲しい...
PGとSEの仕事の面白みは何...
メールをすぐ返信する人、しな...
├ ITコンサルタントになる方法
我がコードは我流。我流は無...
欧米人がグリーンITに積極的...
実は変化など望んでいないエ...
├ 実はコミュニケーション能力に...
IT業界人は自分のドッグフード...
IT業界を不人気にした重鎮...
IT業界の変わった人々
電子メール禁止!ゼロメール...
名言集−運用フェーズ−
システム開発における名言集
失敗から学ぶ人、学ばない人...
SEに多いコーチングタイプは...
あなたのコーチングタイプは...
ITエンジニアの年収公開サ...
CTCは何の略?
会議は踊る、されど進まず...
繰り返し使われるメールアド...
遅刻しそうなので面接受け...
社内SEが人気を集めている...
サポートセンターの悪夢
IT業界に向いていない人
日本の夏、熱暴走の夏
客前で後ろから刺される
システム障害でクビが飛ぶ人
病欠って何ですか?
昼休みって何ですか?
Windowsに弱いIT技術者2
Windowsに弱いIT技術者
エンジニアは音を伸ばさない
話しにくい人
転職する人しない人
サイコロ一振りで給料を決め...
コンサルがお絵描き好きなの...
コンサルの報酬額って?
ITコンサルとSEの違い
SEのITリテラシ
公私のケジメ

▼ 仕事のやり方
客先で自分のPCが差し押さえられ...
「闇リリース」は善意でやっても...
新人のための7つのワークハック...
仕事の質を落とさないメソドロ...
組織が150人を超えると仕事の質...
世界最大のコンサル会社が最低...
IT業界、悪魔の辞典『SI編』
パワーポイントを紙芝居に貶め...
日本と米国の違い:ベンダーサ...
定時退社日に罪悪感を感じるIT...
ストレス厳しい職場を生き抜く...
おまえが呼ぶな、俺が呼ぶ「ハ...
ITプロレタリアートは多機能工...
図表をリッチにする5つのシン...
セクシーパワーポイント道
エンジニア御用達のIT誌
メールコミュニケーションを200.
├ ニッポン・エンジニア・レボリュ...
ITのプロって何ですか?
クールビズにも限界、冷房28...
真夏に長袖!なのに裸より涼...
測定しにくいものを測定する方...
山田さんの使いやすいシス...
SEの品格
コンサルの品格
ダメシステムはひとまず葬れ
眠気対策アイテムを考える
長篠メソッド
ITサポートがユーザーに教え...
資格の価値
出張先のホテルでインターネ...
お口の恋人
絶対に潰れない会社の悩み
エアエッジが必要になる理由
ハイプ曲線+キャズム理論
ユンケル黄帝液とスーパー黄...
一貫性が信用を生む
デビルズ・アドボケイト
落とし所を見定める
クライアントの良き友人たれ
キャンペーンでたたみかける
比較で暴利をごまかす
権威を活用する
ヒヤリハットの考え方
密談のタバコ部屋
「えいや」で決まる、魔法の言葉
海外テレカンの心得
IT業界でうまく生きていくコツ
ポンチ絵
仕事と作業の違い
上司に背を向けると怒られる?
ロケットスタートのススメ
人の考えを利用すべし
「見える」化
仕事の範囲
ワークシートのススメ
フローチャートの基本
仕事のやり方、片付け方
もんたメソッド
高橋メソッド
作業時間の見積り方
仁義を切る
アクションプラン
ミーティングと議事録
ベンダー選定の基準
ITと数学
レスポンシビリティとアカウンタ..
仕事の密度
リクルーティング
ドキュメントプロパティ
クライアントが納得する答え

▼ 仕事の環境
こんなのITのプロらしい仕事...
デスマーチに陥るお決まりパ...
外資が休暇を大切にする”真”...
HTMLメールとテキストメール...
ペーパーレス化が紙の無駄...
携帯電話のSDカードも禁止す...
人々は安定性と安全性の両方...
カタカナ会社はあやしい会社?
サービスリリースの落とし穴
IT業界の職場環境
IT業界の労働環境悪化は...
英語の必要性
正月出勤
年末年始の過ごし方
止められないコンピュータ
動かないコンピュータ
リリース直前の危機

▼ IT業界の動向
クラウドプレイヤーの名言集...
ネット史上最大の惨事、マイクロ...
ベンダー努力を台無しにするIFRS...
電子政府構想は無駄遣いの温床...
NASAのレポートがIT業界に与える...
中国当局によるプログラム盗用は...
コンサルもSIerもいらない内製...
中国のソースコード強制開示制度...
IBMは当て馬、Oracleが演出する...
PWCCが復活、ベリングポイントを...
IBMに喰われたSun、IT業界に訪れ...
ヤフー、自社データセンター所有...
自分が決めたルールに違反するGo...
SOAは死んだ
データセンターを巡るIT業界三...
├ リーマン破綻にみる米国証券業界...
IT史に輝く「すべったテクノロジ...
冷却を必要としない常温データ...
過去のIT業界10大予測を振り...
├ エンジニアよ、大志を抱け!
├ 黒箱襲来!コンテナがDC...
IT業界進化論: SIer 2.0を目...
IT業界がダメな理由を学生の...
IT業界温室効果の1/4はDC...
新生ニコニコ動画、ニコンド...
システム前線異常アリ!ゆう...
ニコニコ動画は文化の架け橋
Web2.0の向こう側〜サードリ...
セカンドライフだけで宣伝の...
国家戦争にも利用されるDDo...
DoCoMo2.0に見る情報格差...
DoCoMo2.0とWeb2.0
ITIL準拠という幻想
システム障害訓練の日を制...
WAONとnanacoが提携したい...
NTT東西の野望〜光回線編...
mixi招待制の綻び
Vistaが売れない理由
独自仕様に走り過ぎて泣き...
米国事情から見る日本のIT...
MVCからAjaxへ
外字ってなんですか?
Sunがx86サーバにIntel採用...
やりたい放題バッドウェア!
アウトソーシングという名の幻...
ソフトバンクモバイル、MNP停...
やっぱり止まったソフトバンク...
あらゆる意味でやり過ぎの...
経営者不在の日本版SOX法...
働いてみたいIT企業ランキン...
サーバの進化がデータセン...
_システム運用にRSSを活用
電力線通信が認可される日...
携帯メールはSSL通信よりも...
経営者不在の日本版SOX法...
Microsoftがサイトリニューア...
停電に脆弱なシステム
システムは誰のためにある...
ITILで運用が楽になる?
進化するコールセンター
Vacademy
IT業界にロングテールはある...
時間をお金で買う
あなたの猫はコンピュータウ...
個人情報保護法の範囲
あなたvsプロジェクト構成管理
ドラマ24にみるシステム最前...
次世代トレンドと枯れた...
日本版SOX法の施行に向け...
新しいWindowsはWeb決済...
地震に強いシステムをお持...
IT Doesn't Matter
SOAと分散コンピューティン...
各社で定義が異なるESB
おサイフケータイに見...(2/2)
おサイフケータイに見...(1/2)
子会社のシマを荒らす親会社
アインシュタインに学ぶソフ...
公職選挙法とインターネット
マイレージ負債
インターネットの舞台裏:海底...
ゼロ・クライアント
サーバのトレンド
外資系パッケージベンダー

▼ 業界の構造
対極にあるIT業界とコンビニ業...
IT業界は成果報酬型のサービス...
特定ベンダー以外をふるい落と...
欧米人なら爆笑するレベルと...
IT業界が詐欺師集団と言われる...
IT業界の格差社会、年収200...
├ 新基準導入でデスマーチがな...
公式では言えないニコニコ動...
├ コンサルとアプリ開発者、格差...
システム運用はIT業界の最下...
テストフェーズの呼び方は千...
2000年問題再来!?サマー..
減り続ける正社員の割合
労働局が偽装請負の抜け道...
会社貸与のPCは何年償却?
ITIL Foundationを2万円で買..
IT製品もイメージ重視?
お試しできない製品は売れない
IT業界は無免許制
どんぶり勘定
標準価格と提供価格
ソフトウェアライセンス
社外秘の秘密度合
偽装請負 
システム開発の流れ7 テス...
システム開発の流れ6 開発...
├ システム開発の流れ5 開発...
システム開発の流れ4
システム開発の流れ3
システム開発の流れ2
システム開発の流れ1
IT業界の構造

▼ 業界ランキング
SIerランキング2005
コンサルランキング2005

▼ その他
「幣社」という表現は相手を見下...
コミュニケーション力の不足は...
聞く耳を持たないYahooニュース...
黒デスクトップ事件に見る中国...
ITコンサルから見たブラッディ...
違法ダウンロードでネット追放...
就職難民=不出来な学生とい...
モンスターペアレント、会社襲来
あえて言おう、Yahooの掲示...
プログラマ向きなカフェをオー..
├ Japan Brog Award 2008を..
日立さん、IT大喜利をもう一度
インターネット上の信頼できる...
IT業界でありそうな迷惑勧誘...
倒産してもカネを要求する悪2...
倒産してもカネを要求する悪1...
├ 枯れた技術の水平思考で
├ ずさん極まりない環境保護ラ...
世界の奇妙な法律を集めた...
50万円のキーボード
洋楽を1曲10円で購入できる...
CNETとZDNetは同じ会社
情報の価値(情報商材)
コンパイル1回12時間の世界
楽天ポイント事件
楽天ポイント事件〜利用者...
楽天300ポイント付与で謝罪
ライブドア強制捜査
└ ネットワークベンダー