外資系企業に住む住人の視点からIT業界の出来事を伝えます。ご興味のある方は、メルマガの登録をお願い致します。Twitterやっています。→http://twitter.com/juntoku_yマイナビニュースで「IT業界裏講座」を掲載中です。そちらもヨロシクお願い致します。→コンサル直伝−IT業界”裏”講座EnterpriseZine(翔泳社)で記事掲載中です。そちらもヨロシクお願い致します。マネジメントセンター(JMAM)より「フレームワーク使いこなしブック」を上梓しました。仕事の質と効率を高める思考の枠組み・フレームワーク。本書は、架空のパンメーカー・ナイスハーベスト社を舞台に、新人のむぎ夫がフレームワークを使って課題を解決していくストーリーを追いながら、フレームワークを学べる仕掛けになっています。最終章では、オリジナルのフレームワークを作る方法も紹介。「わかる」レベルから「使える」レベルに無理なくステップアップできます。2012年7月末、同じくJMAMより「ビジネス思考法使いこなしブック」を上梓しました。こちらもむぎ夫が登場し、ロジカルシンキング・ラテラルシンキング・クリティカルシンキングの3つをどうやって使いこなすか、問題解決の発想技法を学べる仕掛けになっています。このジャンルでは、おそらく初めて3つのシンキングを体系的に1冊の本でまとめている本です。以下の書籍も執筆しています。こちらも合わせてどうぞ。『外資系企業に住む住人の視点からIT業界の出来事を伝えます。以前好評いただいた『資料作成の基本』から図解作成だけにテーマを絞って抽出した本が2018年6月23日に発売となります。https://www.amazon.co.jp/dp/4799106511本書は「資料」ではなく「図解」の作成に特化しています。図解は、論理的にわかりやすい内容、感覚的に心地よい見た目が好まれます。図形のカタチ(フォーム)と配置(ポジション)で生み出される「要素のバランス」、色の使い分け(カラー)によって醸し出される「コンテンツの強弱」です。それらを「図解キューブ」というモデルで表し、その実践例をチャートとグラフの「図解パターン」として体系的・網羅的に整理しました。これらを「エグゼクティブ図解術」と私は呼んでいます。本書を図解作成のハンドブックとして、ぜひ使ってみてください。|2013年06月>>2013年05月31日ベンダーの言うことを信じた結果、システムの欠陥を直してもらえなかったユーザーIT業界では、システム開発にまつわる訴訟トラブルが最も多く発生します。ベンダー側の立場で話を聞くと、「ユーザーが自分たちの責任を全うしてくれないから、ベンダー側の作業遂行が滞る」というケースを数多く耳にします。ユーザー側の立場で話を聞くと、契約書を持ち出して不誠実な対応をするベンダーへの不満もあることに気づきます。今回はそれを見ていきましょう。以下の事例は経産省のモデルケースに掲載されていたものです。あるユーザーは、ベンダーに対して、基幹業務ソフトの開発を委託した。ソフトはベンダーが開発した後、ベンダーの関連会社であるリース会社Aに売却され、Aからユーザーに対してリース物件として引渡される予定であったところ、ソフト製作請負契約の契約書は作成されず、ベンダー・A間でリース契約書が作成されたのみであった。納品されたソフトに欠陥があったため、ユーザーはベンダーに対し、請負契約の債務不履行を理由に損害賠償を請求。【ユーザーの主張】リースは単なる支払の手段にすぎず、実質的には、ユーザとベンダとの間でソフト開発の請負契約が成立していた。【ベンダーの主張】ユーザはリース会社とだけ契約しており、ユーザとベンダの間では、報酬や代金の支払約束がないから、請負契約は成立していない。このケースでは、ユーザーの支払手段としてリースが利用されたため、リース会社に対してはリース契約がありましたが、ベンダーに対しては契約書が作成されていません。ユーザーがベンダーに対して、契約上の責任を追及するためには、双方間で、何らかの契約関係がなければなりませんが、それがなかったため、契約関係の有無自体が争われることとなったのです。やりとり及びその打ち合わせ議事録の内容から、ユーザーとベンダーは、本件ソフトの製作について、数回の交渉を経て、その内容を確定し、それに従って請負契約を締結したと判断しました。リース契約は、金融を得る手段に過ぎず、ベンダーが作成したソフトに不具合がある状況では、ベンダーに債務不履行があったと認めたのです。このような紛争を避けるため、リース契約を使う場合であっても、ユーザーとベンダーとの間で、ソフト開発委託契約書などを作成しておくべきだった、というのが、このケースから直接的に得られる示唆です。読むと、「ひどいベンダーに引っかかった、ユーザーは災難だった」と感想を抱くぐらいの話でしょう。これはベンダー側だけに非があったかと言えば、そうではありません。前回のエントリーで紹介した『なぜユーザーはITも業務も詳しくないベンダーへ発注するのか』で、ITのことをベンダーへ任せっきりにするユーザーの姿勢が問題であることを取り上げましたが、上記のケースも結局は同じ話です。要は、ユーザーには稼働後に発生するソフト不具合への対処アプローチについて想像力が欠けていたため、そうした事態を踏まえた契約条項を取り入れることができなかったのです。このことを、「それくらいはベンダーが進言することだろう」と憤慨するのではなく、「細部を詰めないユーザー側の非も大きかった」と捉えることができる人は、性悪説に基づいたリスク管理の感覚を持っていると言えます。個人的な感想ですが、こうした人材がユーザー側の実務担当者にいれば、IT業界のトラブルは半減するんじゃないでしょうか。あなたの周りにこうした人はいますか?いないなら、あなた自身がそうした役割を担えるようになれているといいですね。日本の官公庁のIT活用と聞いて、みなさんはどんなイメージを思い浮かべるでしょう。システム開発の案件に関わったことがある人なら、あまり先進的な印象を持っていないのではないかと思います。私も以前、「官公庁が情報システム半減に取り組む前にやるべきこと」というエントリーで、こんな話を書きました。これからますますデータ活用が重要になってくるのですから、データガバナンスと言いますか、データのサプライチェーン(データSCM)を本格的に構築することを考えてもらいたいです。最終的にどんなことがしたいのか、という視点で必要となるデータを整理し、それを受け取るための最適なサプライチェーンを構築する、という利用者中心の考え方でデータフローを描くためには、統計情報を管理する部門も併設した方がよいですね。実は、総務省には”統計局”という、政府統計を横断的に体系整備する部門があります。センターというところが、”e-Stat”という政府統計のポータルサイトを運営していました。これまで、このe-Statでは、各省庁が公開した統計情報(詳細データ含む)をアーカイブしてきました。リンク体系を整備し、検索機能も付けてあるので、けっこうカンタンに政府統計情報を一元的に検索することができ、統計情報を仕事に使っている人たちからは好評を博していたように思えます。前述のエントリーで書いたように、データの提供元となる各種官公庁からユーザーの元までシームレスに提供できる仕組みが備わっていたかと言えば、そうではありません。提供されるデータの多くはExcelですが、一部PDFだけの資料もありました。Excelシートについても、資料のフォーマットは省庁ごとにばらつきがあり、ユーザーは各自でダウンロード後、目的に合うよう、毎回各自が手元でフォーマットを加工するという手間が発生していました。した状況を踏まえて問題提起をしたのが前述のエントリーでしたが、去る5/28、総務省から以下のプレスリリースが発表され、ついに政府のデータガバナンスへの本気度がじわじわと明らかになってきました。センターと協力し、トップランナーとして次のような取組を進めています。具体的には次の3つです。統計データについて、(1)のAPI機能の導入を6月上旬から試行運用開始します。(2)の統計GIS機能強化についても、本年秋を目途に試行運用を開始する予定です。統計データの利活用を促進することで、ビジネス活性化や新規事業開発などを支援してまいります。http://www.soumu.go.jp/menu_news/s-news/01toukei01_02000024.htmlこのプレスリリースで最も注目すべきなのは、「(1)API機能による統計データの高度利用環境の構築」です。政府統計データを取得するためのAPI(アプリケーション・プログラミング・インターフェース)を公開するから、使いたい人は機能を呼び出せば、自動的にデータを受信でき、そのままシステム上でデータ加工をすることができるのです。これはデータのサプライチェーンを自動化するための仕組みが備わったということであり、国家が集めた膨大な素データを民間企業が簡単に分析できる土壌が整ったと言えます。今まではリサーチ機関から購入していた政府統計の分析情報も、今後は有志がインターネット上で解析済データを無料公開するようになり、リサーチマーケットにいくらかの影響を与えるでしょう。民間企業が直接統計データをシステムに取り込むようになり、これを利用したウェブサービスも多数発表されるようになるはずです。このサービスはユーザー登録制で6月上旬から試行されます。下、”世界最先端IT国家創造宣言”(2013年5月25日)にしたがって、オープンデータガバナンスの取り組みはさらに加速していきます。IT業界人の一人として、本政策が完遂されるよう、一貫した政府の姿勢を期待します。外資系コンサルの仕事術が本になりますこのたび、6月14日に「外資系コンサルの仕事を片づける技術」をダイヤモンド社より刊行することとなりました。今回の本は、外資系コンサルの仕事のやり方をベースに、”仕事ができる人”がやっている仕事のテクニックを体系的に整理した内容となっています。新入社員/中堅社員/ベテラン社員の視点で、具体的にどんなアクションを起こすべきか、多数の手書きイラストを交えて解説しています。ページ見開きで最低2イラストを含んでおり、「文字ばかりの本は頭に入りにくい」と思っている人にもオススメできると思います。先日、カバーイラストも決まり、あとは印刷されて配本を待つばかりです。詳しい内容は改めてお知らせします。徒然コメント2013年05月27日なぜユーザーはITも業務も詳しくないベンダーへ発注するのか世の中にITシステムの開発案件は星の数ほどありますが、これほど数が多いと、「なぜこのようなことになってしまったのか」と唖然としてしまう案件も中にはあります。なかでも、発注した自分たち自身がシステムの要件を理解していなかったというケースは、比較的悲惨な結果に陥りやすいですね。以下は経産省のモデルケースで取り上げられていた事例です。本件の自治体(ユーザー)では、水道料金収納システムを地元のITベンダに全面的に任せていた。同システムのリニューアルにあたって、同自治体が主導権を握って進めて、費用も低減することとした。同自治体の関連団体であるサービス会社(委託者)に発注し、委託者が受託者に開発を委託することになった。ところが、委託者には、IT技術の専門家も水道課の業務に詳しい者もいなかった上、受託者は他県の企業で同自治体関係の開発は初めてであったため、仕様策定が難航した。自治体は、水道課担当職員を会議に出席させるなどしたが、意思疎通が十分にできなかった。結局、開発されたシステムには不具合が多く、納期を6カ月延期しても完成に至らなかった。委託者はシステム開発に必要な仕様を明確にしなかったし、窓口端末の閲覧、借用もできなかった。情報提供も不十分だった。開発期限を6カ月延長したのに、システムが完成しなかった。このケースは現在係争中であり、まだ判決は出ていません。状況内容から得られる示唆はあります。本件はオープンソースの地理情報システム用ソフトウェアをベースに、水道料金収受システムを開発する計画であったそうです。そのため、ユーザーは、このソフトウェアに詳しいという点を評価してベンダーを選定しました。選定されたベンダーは他県自治体での実績はあるものの、この自治体のシステムは初めてであり、ユーザー側からの積極的な情報提供が必要であることは当初から分かっていたことでしたが、そのための体制をユーザー側が構築できませんでした。加えて、ユーザが長年にわたって使っていた水道料金収受の従来システムに仕様書は存在せず、ユーザの担当者は利用方法のみを知っているにすぎなかったとのこと。このような情報不足がある上に、自治体自体がシステム開発に不慣れであれば、「プロジェクト全体を統括するコンサルタントを導入する方法もあり得た」というのが有識者の見解ですが、そのような施策は採られていませんでした。全体の雰囲気からすると、特許庁のシステム開発頓挫の話に似ていますね。実際、ITシステムを単なるツールと割り切っている組織は官公庁・自治体には多く、職員もシステムの仕組みに興味はありませんから、構築ベンダーの好き勝手になっているという状況が割と見受けられます。した組織では、システム更改に伴うシステム要件の洗い出しが難航する傾向にあります。それだけで済めばまだマシ。今回のケースや前述の特許庁のような、業務要件さえ明確ではなかったということもしばしばあり、これではベンダーはリスクへの備え(コンティンジェンシー)を積み増すばかりです。その結果が不透明で割高なサービス契約に行き着くことは想像に難くありません。事実、そうした組織との折衝に慣れているNTTデータ社は、データ・通信・サービス契約というどんぶり勘定契約で官公庁・自治体のITシステムを支えています。ベンダーに対する正当な見積りを要求するには、まずユーザー自身が正当な自己責任を果たすことが肝要です。「ITのことはITベンダーに任せておいて、ユーザーは業務に集中すればよい」との意見を主張するユーザーもいますが、自システムの仕様が不明瞭であること自体、業務が明確になっていないも同然ではないでしょうか。以前のエントリーで、モンスターペアレントならぬ、モンスターユーザーの話を取り上げましたが、他にもユーザーとベンダーのいさかいに関するエピソードはたくさんあります。興味深い事例は経産省がモデルケースとして取り上げられているので、そこから一例を紹介しましょう。問題となったのは会計処理システムで、システムはメインパッケージと、ユーザ向けにカスタマイズされたサブシステムに分かれていた。メインパッケージは、被告ベンダとは別のZ社が使用許諾権を有し、サブシステムは被告ベンダが有していた。ユーザは、Z社と被告ベンダとそれぞれ使用許諾契約を結んだ。Z社がメインパッケージの2000年問題対応の無償バージョンアップを行ったため、バージョンアップに伴うサブシステムの補修が必要となった。被告ベンダは補修対応費用として1400万円の見積もりを提出したが、ユーザが支払いをしないと主張したため、見積もりを撤回し補修に応じなかった。して1400万円を請求した。【ユーザーの主張】ユーザと被告ベンダ間の使用許諾契約は、全体として統合された会計処理システムを構築する義務を負っており、メインパッケージのバージョンアップにあわせてサブシステムを補修する義務を負っている。保守契約が成立しており、被告ベンダは補修する義務を負っていた。このユーザーの主張は裁判所に認められたでしょうか?答えはNOです。裁判所は、ユーザはメインパッケージについてZ社と別途契約を締結していることなどから、被告ベンダは会計処理システム全体について責任を負うということはないと判示し、変更後のメインパッケージにサブシステムを適用させる義務はないとしました。そもそも、保守契約については、ユーザと被告ベンダ間に結ばれていなかったそうです。いくらなんでも無茶苦茶だな、と思ってしまいますよね。ユーザー企業は、この状態でよくも裁判を起こそうと考えたものだと思ってしまいます。このトラブルの内容が、「ユーザーの無知に付け込んで不当な工数費用を請求していた」という事情に基づいていたなら、ユーザーの主張は部分的に認められていた可能性がありますし、非難されるべきはベンダー側ということになります。このケースから得られる示唆は、開発契約の際に、被告ベンダの業務範囲(パッケージ側のバージョンアップ作業に対応するサブシステム側の補修作業を行う責任(=システム全体についての責任)を負うか)や費用負担(補修作業を行う場合の費用(有償/無償)の扱い)などを明確にしておくべきであった、ということです。あなたがシステム開発契約に携わるときには、くれぐれもシステム稼働後の保守フェーズにおける責任分界だけは最初にハッキリさせておくことをお勧めします。業界裏話2013年05月24日GIFはギフとは読みません:IT用語の読み方ルールIT業界といえば、外来語が多くてカタカナ表記の専門用語や溢れかえっていますが、カタカナにさえなっていない、英語表記そのまんまのキーワードも少なくありません。した用語は、どんな日本語発音をするのか、人によって意見はマチマチでした。安価なPCメーカーとして知られているASUS。2010年秋に日本法人の活動を本格化するに際して、日本語読みはアスース(英語ではエイスース)とすることを正式決定しましたが、それまではエイサスやエイスースなど、人によって呼び方が異なっていました。今やWeb開発で欠かすことのできないAjaxという技術も、エイジャックスという読み方とアジャックスと呼び方が混在しています。値が入っていないことを意味するNullという言葉も、ヌルとナルの呼び方に分かれますね。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と定義されていたのですが、今回の発表を受けて、「ジフ」という呼び方で統一されることになりそうです。瑕疵担保期間を長引かせるためにITシステムの”検収”を終わらせないユーザーシステム開発に関わっている人にとって、”検収”という言葉は大きな意味を持ちます。ユーザー側の検収が終わった時点から”瑕疵担保期間”がスタートするからです。そもそも瑕疵担保期間とは何でしょうか。法務上の用語なので難しく感じられますが、一言でいえば、「システムにバグが見つかった際に無償で改修することを保証する期間」です。あなたがPCを購入する際に、1年間のメーカー保証は大抵ついてきますよね。購入日から1年以内であれば、故意・天災による破損を除いて、メーカーが無償で修理してくれます。その保証期間をITシステムでは”瑕疵担保期間”という言葉で表現するのです。民法では1年で設定することが標準的な考え方ですが、システム開発では6ヶ月としているケースが多いですね。これは1989年に発刊された大著『ソフトウェア取引の契約ハンドブック』で次のような記載がされているからです。『商法第526条は、商人間の売買について、買主は遅滞なく検査をなし、瑕疵を発見した時は直ちに(ただし、隠れたる瑕疵は6か月以内に)売主に通知しなければ、売主の担保責任を追及しえない旨定めている。これは、売主が引き渡し後いつまでも不安定な立場におかれることを回避するための規定である。』もうすこしカンタンに言うと、「明らかなバグはすぐにベンダーへ伝えて直してもらいましょう。後から発覚したバグは6か月以内ならベンダーで無償対応しましょう。それ以降の対応は、ベンダーの経営に悪影響を及ぼすから、認めないことにしましょう。システム開発ベンダーの方々は、開発後の6ヶ月までが呼び出し対応を受ける期間になるのですね、形式的には。ユーザーが大企業である場合、事情が異なります。6ヶ月を過ぎたから、そのあとに出てきたバグには一切責任を負いません、なんて姿勢を取ろうものなら、「あのベンダーは柔軟性に欠けるから次のシステム開発は任せない」というカウンターをもらうことは容易に想像できます。曲がりなりにも大企業というのは契約書面を重んじます。そのため、システムの検収時期をできるだけ後ろ倒しにしようと働きかけてきます。ソフトウェア取引の慣例となっている6ヶ月検収ではなく、民法一般上の慣例となっている1年の瑕疵担保期間の設定を求めてくることが多々あります。実際のところ、システムが本番稼働してからでないとバグが発覚しないというたぐいもあるため、ユーザー側は瑕疵担保期間の開始を本番稼働時点とするよう求めてくることには一定の合理性があり、ベンダー側としては、そのケースになったとしても受け入れられるように関係者との段取りを進めておくことが望まれますね。ユーザー検収にあたっては、見つけた全てのバグの解消を確認できるまでは検収を終わらせるべきではないと考えるユーザーはかなり多いです。これについて、ベンダー側は本番稼働をもって検収完了にするという交渉で臨むのが定石ではありますが、稀に、「バグの発見・解消が終わるまでは本番稼働はしない」という断固とした姿勢をとるユーザーもいます。したケースでは、ベンダー側が「今稼働させないことによる業務的な損失」を説明して納得させるしかありません。他にも、瑕疵担保期間中にバグが発見された場合、そのバグが解消されてから新たに瑕疵担保期間がスタートするというベンダーにとっては悪夢のような条件を持ち出してくるケースもあります。瑕疵担保期間の後ろ倒しに伴う、保守サービス期間の延長(通常は設置後5年のところを、瑕疵担保期間が半年ずれたら保守期間も料金据え置き)を求めてきたという話もありました。ユーザー側、ベンダー側の双方が不当な契約を結ぶことがないよう、一般的な契約文書の内容を知っておいて損はありません。経産省から出されている『情報システム・モデル取引・契約書』が昨今の契約条件の判断基準になっています。契約締結に関わる方々は、このドキュメントは一読しておくことをお勧めします。官公庁が情報システム半減に取り組む前にやるべきこと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%の削減効果)があるといったエピソードをガートナーやアクセンチュアが述べていることを踏まえると、前述の試算はそれなりに妥当なラインであるように思えますね。総務大臣を原口氏が務めており、そのイニシアチブのもとで「国の情報システム運用費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)を本格的に構築することを考えてもらいたいです。最終的にどんなことがしたいのか、という視点で必要となるデータを整理し、それを受け取るための最適なサプライチェーンを構築する、という利用者中心の考え方でデータフローを描くためには、統計情報を管理する部門も併設した方がよいですね。米国ではオープンガバメントとして知られている取り組みを、是非日本国内でも同時に取り組んでほしいと願っています。以前、「デビルズ・アドボケイト」という言葉をブログで取り上げました。http://it-ura.seesaa.net/article/14400485.htmlデビルズ・アドボケイトとは、わざと相手の意見に反論し、議論を盛り上げ活発にする目的で用いられる手法であり、討論では一般的に用いられるスタイルです。「朝まで生テレビ」で、田原総一郎がコメンテーターの真意を引き出すために、わざと喧嘩口調で反論をぶつけていますが、あれこそ、まさにデビルズ・アドボケイトです。システム開発のテストコンディションを考える際に、次のような視点で自問自答する、もしくは設計チームが作成したものをレビューするのもデビルズ・アドボケイトの視点が活かされます。相手から意見を引き出すことが上手な人は、デビルズ・アドボケイトに長けています。「敢えて言わせてもらうなら〜」などの切り口で根本的なテーマを話題にすることは、クリティカルシンキングができているからこそです。呼ばれることもあります。次の例を考えてみましょう。『何年も業績が低迷していた同業のA社は、インド進出を機に売上が右肩上がりで増収増益となっている。一方で、わが社は長期にわたって売上が低下しており、収益も減少している。この状況を打開するには、わが社もインドに進出するべきだ。』この意見は、「似たような境遇にあったA社が増収増益なのはインド進出をしたから」であり、「増収増益となっている」状況に至ったと述べています。わが社もインドに進出すれば同じ結果を得られる、という論理です。考えてみると、インド進出の時期から業績が上向き始めたと言っているだけで、インド進出自体にその理由があるとは捉えるのは論理の飛躍です。インド進出と時期を同じくして商品開発やマーケティング上の大成功があっただけかもしれません。売上増に伴ってA社がやってきたことをすべて検証できれば、より確実な原因を探り当てることができます。一方で、すべてを検証すると時間がいくらあっても足りません。分析作業に膨大な時間を費やして実行着手のタイミングが遅すぎないことを意識することが、クリティカルシンキングでは重要です。民主党政権の頃、事業仕分けでスパコン事業に対して蓮舫議員が、「2位ではダメなんでしょうか?」と発言して物議をかもしだしたことがありましたが、これもデビルズ・アドボケイトです。蓮舫議員の真意は、2位ではダメだという強い意見を相手から引き出して、だからスパコン事業の予算はできるだけ削らない方向に持っていこうというところになりました。その意図は国民には伝わらず、マスコミからバッシングを受けまくっていましたけどね。デビルズ・アドボケイトは使いどころを間違えると、自分が火だるまになるというリスクを抱えているのです。自分の発言を評価するステークホルダーのうち、何割かにはあらかじめその意図を共有し、自分の味方になってもらわなければなりません。なければ、「この人は皮肉ばかり口にするイヤな人だ」とのレッテルを貼られて、周りからネガティブな目線で見られるようになってしまいます。これでは議論を活発にするどころか、そもそもまともな議論をしてもらえなくなるでしょう。デビルズ・アドボケイトを使う際には、発言の前に意図をはっきりと説明することをお勧めします。業界裏話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年の話ですが、いまだに巷ではマルチタスクで仕事をすることに問題を感じない人が多くいます。作業と作業の切り替わりによって、自分の中のエンジンを何度もかけなおしていることに気づいていないので、そのたびに生産性が落ちているという事実を認識できていないのだと思います。あなたが助言できる立場にあるなら、一度このことを話し合ってもよいかもしれませんね。マスターヨーダもクリエイター:クリエイティブになる31の方法(05/31)主要ツール120個を網羅するDevOpsツール周期表、作り方(05/26)ロジカル・ラテラル・クリティカルシンキングで発想力を鍛える(05/26)ユンケル黄帝液とユンケルスーパー黄帝液の違い(08/24)文章をわかりやすくする【18個】のルール(05/31)誠意を見せつつ相手に納得してもらう「謝罪報告書」の書き方(04/11)10年前に予測したITの将来が2017年どれだけ実現できているか?(03/30)【IT業界名言集】我がコードは我流。