IT資産価値の多面的な評価の枠組み

河田です。
最近は実務者に役立つ情報よりも活動報告的な話が多いような気もしますが、今月上旬に浜名湖フォーラム（通称：カリアック会議）に参加しましたので、今回はそこで発表したIT資産の価値についての話を少しご紹介します。

-------------------------------------------------------------------------------
カリアック会議については、昨年9月にもこのBlog上で紹介していますが

• 経営情報学会の「中小企業のIT経営研究部会」
• 武蔵大学の「松島教授オープンゼミ」
• ITコーディネータ協会の「ＩＴ経営研究所」

3者合同の研究合宿で、様々な分野の専門家、有識者、経営者の方々が集まり、肩書きや立場に関係なく議論するというオープンな形式のフォーラムでもあります。

浜名湖畔のカリアック（商工会議所研修センター）で開催されてきたこと、また「IT業界のダボス会議を目指す！」という高い志から命名されたとも言われています。

私は、今年度から新たに取り組んでいるIT資産価値研究会のメンバーの一人として、「IT資産価値の多面的な評価の枠組み」について、発表しました。

IT資産価値の多面的な評価の枠組み from Tetsu Kawata

昨年度の発表「ソフトウェア資産管理とIT投資マネジメントの関係性」の発展形の話ですが、今回は4人のコンサルタントによる連携プレゼンの一部として「評価の枠組み」というテーマで、下記の3点をキーメッセージとしてお話しています。

• IT資産価値評価の悩ましさ、難しさを考えると、企業実務で評価・活用するためには、いくつかのバリエーション検討が必要であること
• 資産価値の評価に際しては、改めて「誰のため？」、「何のため？」から評価の視点/方法を考えることが必要であること
• 具体的には、IFRS的な視点、事業価値の視点、IT全体ポートフォリオの視点の他に、「知的財産の価値評価」、「企業独自のスコアリング評価」、「システムマップ活用評価」のアプローチが考えられること

私が発表を通して伝えたかった一番のポイントは、
IT資産の価値評価は極めて難しい/悩ましいテーマではあるけれど・・・

稼働するシステムをIT資産として管理することは、「該当システムへのIT投資とその結果もたらされる価値について継続的に向き合う機会」になり得る

という点です。

まだまだ研究途上ですが、IT資産価値の測定方法は、全ての企業で一律であるべきではなく、また目的に応じた使い分けも必要であることを納得感を持って整理できたら良いな・・・と考えています。

システムの価値は、会計的には減価償却的な側面しか認められていませんが、実際には多元的な価値の側面があり、事業に占めるIT投資の割合(IT資産の比率≒業種業態)、ITコストの管理箇所(IT部門/事業部門)、企業規模等により、その意味合いも変わってくるものではないかなと。

今回の発表を通して、多くの有識者の方々から貴重な指摘をもらえたことは、とても有難く、また研究の意義も含めて共感のコメントを数多く頂けたことは、とても嬉しかったです。

-------------------------------------------------------------------------------

カリアック会議は今回で三回目の参加となりましたが、年々参加者が増え、多岐に渡る興味深いテーマの発表が多くありました。（Agendaはコチラ）

主催者の皆さま、IT資産価値研究会の皆さま、そして関係者、聴講者の皆さま、
本当にありがとうございました！！！

最後になりましたが、今年から複数企業のコンサルタントの方々と共に「IT資産価値研究会」を定期的に実施しています。
ゲスト参加も大歓迎ですので、該当テーマに関心がある方は、ご一報下さい。

プロジェクトで活躍するOSSツール

中嶋です。

あっという間に2回目の投稿となりました。月日の経つのは早いものです。
さて今回は、システム開発・運用・保守におけるツール（プロジェクト管理、バージョン管理 etc.）
について、OSSツールを中心に少しご紹介したいと思います。
古くから使われているツールが多いですが、備忘録として投稿させていただきました。

【プロジェクト管理】
　１．Trac
　　EdgeWall Softwareで開発されている、プロジェクト管理ツール。
　　
　　チケットによるタスク管理だけでなく、
　　Subversion, Gitといったバージョン管理とも連携や、テスト管理ツールであるTestLinkとの
　　連携も可能。

　２．Redmine
　　Jean-Philippe Langで開発されている、プロジェクト管理ツール。
　　
　　Trac同様、チケットでタスク管理しており、
　　バージョン管理ツールや、テスト管理ツールとの連携も可能。
　　複数プロジェクトで利用することも可能で、プロジェクト間のコミュニケーションも可能です。
　　ガントチャートやカレンダー、グラフのようなビューといったプラグインも充実しています。
　　
　　昔からあるツールですが、ここ数年（2011年以降）Redmineの導入率が高くなってきており、
　　MS Projectよりも導入率が高いとのアンケート結果も出たくらいメジャーになってきています。
　　
【バージョン管理】
　１．Subversion
　　CVSの改良版として開発されたバージョン管理ツール。
　
　　リソース編集時に「ロックしない」点が大きな特徴で、
　　編集するソースのロックによる待ちによる開発効率の低下を防止。
　　その反面、競合が発生することもありますが、それほど苦にならなかったと思います。
　
　２．Git
　　オープンソースの分散型のバージョン管理ツール。
　　
　　リモートサーバ等にあるリポジトリの完全コピーを手元（ローカル環境）に作成して、
　　そのローカルリポジトリを使って作業します。
　　最近は、SubversionよりもGitが主流になってきているようにも感じます。
　
　
【タスク管理】
　１．SubTask
　　マインドマップ形式でタスクを管理するツール。
　　
　　Web上で編集した内容が、ほぼリアルタイムに参照可能となるので、
　　タスクの洗い出し、担当割が簡単に行えます。
　　
　　メールによるプッシュ機能もあり、
　　変更内容の情報共有、期限切れのタスク共有も可能となっています。


また、Redmine, Subversionを連携させて、進捗状況を解析する仕組みも生まれています。
　http://itpro.nikkeibp.co.jp/article/Active/20120827/418343/

管理まではツールで、進捗分析はスクリプトやマクロを組むといったパターンが多かったですが、
こういったツールが充実してくると、本来のマネジメント業務に注力出来るものです。

もちろんツールを導入するだけでなく、使う視点が無いと宝の持ち腐れとなってしまうので、
各フェーズの計画段階で、進捗・対応状況の入力方法、進捗の測定方法、不具合の分析軸を
きちんと整備して定着化させる活動も必要です。

使い方を定義したあとは、実際の利用者（開発者）の負担が低くなるよう、
自動的に情報が登録出来る仕組みも考える必要があると思います。
忙しいシステム開発プロジェクトで、細かい情報を登録していこうとは思わないでしょうし、
登録する項目数（分析軸となる項目）が増えてしまうと、管理工数がかかってしまって、
非効率になりますので。

以前のプロジェクトでは、入力漏れを支援チームでカバーするといった
非常に効率の悪い管理もあったので、自動入力の仕組みが出来ていくことを願っています。
不具合の発生原因も、記載した不具合の内容をテキストマイニングで分析し、
自動的に分類されると良いですね。

プログラムマネジメントの重要性

藤原です。
今回は、プログラムマネジメントとIT投資管理の関連性について、少し触れたいと思います。「プロジェクト」ではなく「プログラム」マネジメントの話です。


プログラム、プログラムマネジメントとは？

プログラムとは、企業の戦略目標達成に向けた価値を創造するための”複数”の施策（プロジェクト）によって構成される統合的な活動を指す概念で、そのプログラムに構成される複数のプロジェクト群を管理するプロセスや手法をプログラムマネジメントといいます。
プログラムは、各プロジェクト活動の上位に位置し、横断的な管理活動を行うことで、目標達成に寄与する価値を生み出すことを目的としています。

プログラムマネジメントに関する標準やベストプラクティスは、日本や米国、英国から発行されています。

• 『P2M プロジェクト＆プログラムマネジメント標準』（日本：PMAJ）
• 『The Standard for Program Management（PGM標準）』（米国：PMI）
• 『Managing Successful Programmes(MSP)』（英国：OGC）

『P2M標準』（PMAJ）ではプログラムを
「自組織の、または顧客から所与の、組織戦略具現化のための上位レベルの特定使命（プログラム特定使命）を実施する複数のプロジェクトが有機的に結合された単位事業」
とし、プログラムマネジメントを
「外部環境の変化に柔軟に対応しつつ、組織の資源と遂行能力を効率よく活用しながら、複数の要素プロジェクト間の全体最適統合を行い、プログラム特定使命を達成するマネジメント手法」
と定義しています。

また、『PGM標準』（PMI）ではプログラムを
「プロジェクトを個々にマネジメントすることでは得られないベネフィットとコントロールを実現するために、調和のとれた方法でマネジメントされる相互に関連するプロジェクトのグループ」
とし、プログラムマネジメントは、
「プログラムの要求や、プロジェクトを個々にマネジメントすることでは得られないベネフィットとコントロールを実現するための知識、スキル、ツール、テクニックの運用」 
と定義しています。


プログラムマネジメントの価値

プログラムは、単に複数のプロジェクトを束ねた総称ではありません。
企業の戦略目標を達成するために必要な価値を産み出すための施策（活動）として「プログラム」が定義され、そのプログラムが複数のコンポーネント（プロジェクト）によって構成されている、という構図となります。
従って、プログラムはプロジェクトの上位に位置し、一連のプロジェクト成果によって、戦略目標達成に寄与する価値を創造することをゴールとしています。

私は、プログラムマネジメントの価値として、以下が挙げられると思っています。

• 戦略目標達成に求める価値とプロジェクト成果の整合性（トレーサビリティの確保）
• 統合的なリソース管理やリスク管理による個々のプロジェクト品質の向上
• 目標達成に対する責任（プログラムサイフサイクルを通して効果を測定・評価）

膨大な費用を投入したプロジェクトでも、QCDを満たして成果物を作り出せば成功！という訳ではなく、その根本には、達成すべき戦略目標があるという認識を持つことは、メンバーのプロジェクト実行に携わる意義を明確にします。
また、見落とされがちなプロジェクトの事後評価に関しても、プログラムマネジメントは、投資対効果をモニタリングする役割を担うことで、戦略目標達成に対する責任を果たします。


IT投資管理との関連性

プログラムは、企業のIT投資（またはIT資産の活用）によって戦略目標達成への価値を創造する一連の企業活動（関連する複数のプロジェクト群）と位置付けられます。そのため、プログラムマネジメントには、重要なタスクとして財務的な管理活動が含まれます。

企業におけるIT投資に対して、プログラムとして必要な全体額を要求（調達）し、各々のプロジェクトに適切に配分します。また、個々のプロジェクト状況を逐次モニタリングし、プロジェクト実行中、及び事後においても、その効果や価値を評価することで、リソースの調整を行います。
つまり、プログラムマネジメントは、プログラムのライフサイクルを通じて、投資に対する成果・価値の評価を行い、適宜そのコントロールを実施することが求められます。

プログラムマネジメントは、IT投資管理としての機能を部分的にではありますが、担っていると言えると思います。


最後に・・・
デスマーチと呼ばれる様々なプロジェクトと、それをコントロールする「プロジェクトマネジメント」の重要性、難易度は多くの実務者に認識されていますが、「プログラムマネジメント」に関しては、まだ十分に認識されていないかもしれません。

企業が求める変革（イノベーション）を達成するためには、非常に複雑で、難易度の高いプロジェクトの遂行が不可欠であり、それらのプロジェクト群が成功するためには、統合的なモニタリングとリソースやリスクのコントロールにより、環境変化に対して柔軟に対応するプログラムマネジメントが重要であると考えます。

今後、個々のプロジェクトの統合的な管理・成功に向けた活動という直接的な視点だけではなく、IT投資に対する効果（価値創造）をより高めるための活動という視点でも、「プログラムマネジメント」が、更に浸透していくことを期待します。

「IT投資マネジメントの変革」出版記念セミナーに参加して。

河田です。
今年からこのBlogの仲間がまた1人増えました。
2010年8月に1人で始めたこのBlogも、昨年4月に仲間が1人増え、今年4月からは
3人のITコンサルタントで共同運営です。ちょっと感慨深い。

内輪話ではありますが・・・仲間が増えることは、視点が広がることに繋がりますし、
良い刺激を受けられるので、他の仲間に負けないように頑張らないと！

-----

先週末に、前回の投稿でご紹介した書籍「IT投資マネジメントの変革」（松島桂樹編著）の
出版記念セミナーに参加しましたので、今回はその話を少し。

主催団体、後援団体の力添えも影響していたのかもしれませんが、主幹の松島先生を
中心とした登壇者（講演）への関心の高さから、、、
休日にも関わらず80人収容の会場（＠IBMの丸ビルオフィス）は満席でした。

当日のAgendaはコチラ。

開始から終了まで約4.5時間の長丁場のセミナーでしたが、途中退席者も殆どいなかった
ことには、、、良い意味で驚きましたが、
聴講者も学術・研究分野の専門家の方々は勿論のコト、大手企業の企画部門の方から、
大手ITベンダーの方、リサーチ会社の方まで、かなり幅広い分野の方々が参加されており、
質疑の内容も多様性に富んでいたのではないかと思います。

私は、書籍の5章「価値再発見のオペレーション・マネジメント」について、お話を
させて頂きました。

• 保守活動では、「経営の業務改革や環境変化に対応するための作業」が大きな割合を占めており、保守作業を必要悪と軽視することは、結果として「企業の競争力に重大な影響を及ぼす可能性」があること

• システム運用の目的が「ITサービスのマネジメント」へ変化している中、安易なコスト削減は企業価値を毀損するリスクがあるが、その重要性は経営層には十分には届いておらず、「運用業務の可視化」は急務であること

• 保守・運用の役割は、従来の「情報システムの維持・運行」から、「IT資産価値の維持・増大」へシフトしており、価値再発見のためにIT投資のオペレーション・マネジメントに取り組む意義は大きいこと

キーメッセージとして、上記を中心に発表しました。

緊張して、早口になり、自分の話すスピードに頭の回転が追いつかず・・・と
反省の残るプレゼンではありましたが、

1. .多くの有識者の方々に自分の考えを伝えられたこと
2. 様々なバックグラウンドを持つ参加者の皆さんから共感メッセージをもらえたこと
3. 他の講演者、及び参加者の方々から斬新な視点の考えが聞けたこと

等、とても有意義で貴重な時間を過ごすことができたと思います。
やはり、アウトプットしていくことは、重要ですね。

また、3つ目の点について、セミナーを通して私が他の講演者・参加者の話の中で、特に
強く印象に残った話を一部ご紹介すると・・・

• KPI等の評価は、時として「正しく評価をする方法を考えること」よりも、「評価の行為を通して気付くこと」の方が重要であること

• クラウド対応の検討は一律的な議論で扱うべきではなく、企業における適性を踏まえて対象範囲を明確にした上で推進する必要があること

• ITプロジェクトは、経営視点と現場視点の2軸4象限で「満足な成功」、「純粋な失敗」だけでなく、「不満足な成功」、「形式的な成功要件を満たした失敗」を定義する必要があること

私の表現力不足で、この文章だけでは上手く伝わらないかもしれませんが、、、
もし「詳しく知りたい！」という方がいらっしゃったら、ご連絡下さい。

ちなみに、当日の私のプレゼン資料は、以下でした。
 

価値再発見のためのオペレーションマネジメント from Tetsu Kawata


最後に・・・、

貴重な機会を提供して下さった主幹の松島先生、
　事務局として全てを巧みに仕切って下さった栗山さん、
　　楽しい講演で盛り上げて下さった講演者の皆さん、
　　　鋭い質問でディスカッションを有意義なものにしてくれた多くの参加者の皆さん、
　　　　また会場で参加者の入退室のガイドをしてくれたIBMの皆さん、

本当にありがとうございました！！！

ユーザー満足度の調査分析方法

中嶋です。
今月より、IT投資マネジメント情報局のブログメンバーに参画しました。といっても、IT投資マネジメント領域についてはまだまだ素人ですので、暖かい目で見守っていただければ幸いです。

今回は、先日プレスリリースとして公開された、IDCのマネジメントに関する調査レポートについて触れたいと思います。
※Project Failure is all about Business Perceptions（原文はこちら）

このレポートの中では、プロジェクトの主な失敗要因としてポイントを6つ挙げています。

1. Inadequate project prioritisation and selection processes.
2. Changing scope during the project.
3. A lack of transparency beyond the IT management level.
4. Insufficient executive involvement in IT project governance.
5. Vagueness of the businesses' expected needs or project outcomes.
6. No formalised mechanism for capturing and analysing end-user satisfaction with IT service delivery.

どれもよくある話ですね。

特に2.と5.は、私自身がメンバーとしてプロジェクトに関わっていたときから顕在化していました。相変わらず失敗要因の1つとして挙げられているところを見ると、マネジメント領域で改善・貢献出来るところは、まだまだたくさんあると感じます。

今回注目したのは、6.「ユーザー満足度の調査分析方法が確立されていない」で、確かにユーザー満足度が分かれば、ITプロジェクトの振り返りもより効果的な活動になると思います。例えば、要件がユーザーの求めるものとマッチしていたか、マッチしていなかった場合は何が足りなかったか、といった感じです。私もプロジェクトの振り返りを何度か行いましたが、あくまでプロジェクト内部での振り返りで、ユーザーに対する影響調査までは踏み込めていません。

では、ユーザー満足度はどのように調査分析すればよいのでしょうか？私は、テキストマイニングが解決策の1つとして有効に機能するのではないかと考えます。SNS等に書き込まれたささいなつぶやきから、良い評価・悪い評価を解析出来れば、ユーザー満足度の測定も可能になるはずです。ビッグデータの利活用ですね。

ただ、こんな調査結果も出ています。
日本データマネジメントコンソーシアムのアンケート調査結果ですが、ビッグデータの利活用は検証段階の企業も含めて3割程度しかなく、また米国と比較してもまだまだ後発と言えます。
※詳しくは、「IT Leaders～データマネジメント実態調査」の記事をご確認下さい。

ビッグデータ利活用が進まない主な理由は、

• データ利活用の目的があいまい
• データ分析が出来る人材確保が困難、分析のための組織が無い
• 投資対効果の説明が難しい

の3つだそうです。その一方で、ビッグデータの利活用が重要であると認識している企業は半数以上あるという結果も出ています。データを有効活用したくても、分析出来る人材がいないからやれないのかもしれません。データの解析が出来る人材、データサイエンティストと呼ばれる人材が多く輩出されることで、データの利活用が進んでいくことを願います。そして、データサイエンティストと一緒になって、自分が携わったITプロジェクトの効果を測定してみたいものです。

勿論、効果測定結果を見てプロジェクトの改善にどう活かすのか？といった仕組みは考えないといけません。いつやるか？も含めて、じっくり考えたいです。