イノベーションプロジェクトを失敗しないために

藤原です。

PMI（Project Management Institute）から発行されている会員向け月刊誌のコラム記事が興味深かったので、今回は、その内容について簡単にご紹介させていただきたいと思います。

コラムのタイトルは 
When new ideas fall flat
新しいアイデアが失敗に終わるとき

コラムではイノベーションプロジェクト、つまり革新的なサービスを企画・開発していく際の主な失敗理由とその回避策について述べられています。

1. ガバナンスの不足

• イノベーションの責任は1人の担当者が負えるものでは無いが、利益がないと判明した場合に説明責任を負う役割を位置づける必要がある
• 適切なガバナンスが欠けていると、責任が分散し、イノベーションプロジェクト成果なしに終わる
• アイデアの創出、選別、ポートフォリオの選択・優先順位付け、実現の方法についてフレームワークで規定し、一連の主要指標を用いて、フレームワーク遵守する必要がある
• 主要指標については、運営委員会や取締役会等で定期的にレビューしなければならない

2. 不明瞭なゴール

• 目的意識は、チームのイノベーションを推進する主な要因
• したがって、イノベーション・プロジェクトの背景にあるゴールをチーム・メンバーに確実に理解させる必要がある
• チームがプロジェクトやプログラムの価値を信じていない限り、情熱を持って取り組むことはない
• 的確なゴールを明確に伝え、論じることは、イノベーションの失敗を防ぐために不可欠な対策

3. 顧客の無視

• イノベーションの失敗に共通する原因は、イノベーション・プロセスの中で顧客のフィードバックを無視すること
• 重要なステークホルダーのフィードバックを無視したために、普及や売上が伸び悩んだ例は数多くある
• ステークホルダーは、洞察とアイデアの最良の情報源となる可能性がある
• 顧客のフィードバックは、製品の長期的な実現性に関するきわめて重要な予測

4. 完璧さの追求

• まずまずの機能を備え今すぐにでも発売できる革新的な製品、多様なオプション機能が付くものの 1 年後にならないと発売できない製品、前者の方が有利
• 必要以上に機能を持たせようとすると、スコープ・クリープが絶えず発生し、プロジェクトが行き詰まる恐れがある
• 完璧を追求する場合、プロジェクト費用が膨らみ、時間が長引くと、製品を購入する意欲のある顧客を失う可能性がある

現在、サービス企画を担当している事もあり、フムフムと読んでいました。

述べられている事は、ごく当たり前の事なのかもしれませんが、イノベーションという革新的なサービスを生み出したいという一心で企画を進める場面では、自身のアイデアに執着してしまったり、何らかのバイアスがかかった状態で進めることも多く、独り善がりなものになる可能性も否めません。
かといって、あれこれ考えすぎてスピード感を失い、しかるべきタイミングを逸してしまう可能性もあります。
とりわけ、ITの業界ではスピード感は非常に重要なポイントの一つと言えます。

コラムで述べられている点を簡潔に纏めると
イノベーションプロジェクト、すなわち革新的なサービス開発は
- 組織的に
- 情熱を持って
- 顧客の声を大事に
- スピード感を持って
が重要という事でしょうか。

４つのポイントに留意して、今後も革新的でイケてるサービスの企画・開発に取り組んでいきたいと思います。

プロジェクト成功の評価基準

藤原です。
今回の投稿はプロジェクトに関する気になる数字から。

プロジェクト成功率75%
とても興味深い数字ですが、日経コンピュータ10月16日号の特集記事「情報システムのリアル 独自調査で33の疑問を徹底分析」からの抜粋となります。

有効回答＝3069件（ユーザー企業1775件、ITベンダー1294件）に基づく調査結果からまとめられたもので、記事では「開発」「運用」「ビジネス慣習」「ハード・ソフト」「サービス」等、様々な質問項目に対する結果がまとめられています。

その調査の一項目で「あなたが関わっている・知っている新規システムの導入・開発プロジェクトの成功率は何割か」という質問に対して、プロジェクト期間毎（3ヶ月以内、3-6ヶ月、6ヶ月-1年未満、1年以上）での回答を平均した結果「プロジェクト成功率は75%」というものでした。

75％。意外と高いという印象ではないでしょうか？

プロジェクト成功の定義
ここで気になるのが「プロジェクト成功の定義」です。
調査では「当初予定していた品質・予算・納期（QCD）を順守できた」を成功の定義としています。
この調査における成功の定義の設定について文句を言いたいわけではありません。
この評価基準は極めて重要だと私自身認識していますし、この定義に基づくプロジェクト成功率がどのように推移しているかは非常に興味があります。

ただ、本来の「プロジェクトの成功」は「ビジネス上の価値（ベネフィット）の獲得」であると私は考えています。
プロジェクトは投資活動ですので、その投資に対する効果が求められます。プロジェクトはその目的達成に従って活動すべきであり、本来の「成功」はそこにあるのかなと。
「QCDの順守」はプロジェクトが持つ本来の目的達成の評価指標ではなく、あくまで１つの要素であると捉えています。

実際には「ユーザ、ベンダーなど立場によって違う」「プロジェクトライフサイクルではそこまで評価できない」「マネジメントスコープが違う」という声もあるかと思いますが。。。

今回の調査結果「プロジェクト成功率＝75%」という数字を見て感じたことは、

• 「QCDの順守」という評価に基づく成功率が高まっていることから『プロジェクト遂行』に関するマネジメントの成熟度は確実に向上している。
• これは、プロジェクトマネジメントに求められる評価基準、成功定義がより上流、つまり本来の目的である「ビジネス上の価値（ベネフィット）の獲得」を意識したものへと高度化していく流れの兆しかもしれない。

ということです。

単にQCDを順守するだけでなく（それは当たり前として）、プロジェクト本来の目的、企業の戦略に合致したビジネス上の価値獲得を意識し、新たな提言、アイデアや技術力を発揮することや、逆に目的達成に寄与しない場合は、厳しい判断を促すといった方向修正（というか勇気）もマネジメントに求められる点として重要さを増してくるような気がします。

実際には難しいんですけどね。
ただ、そういう「意識を持つ」ということは重要だと思っています。

ビジネス上の価値（ベネフィット）の獲得という評価軸
では、プロジェクトが目指す「ビジネス上の価値の獲得」という成功基準はどのように評価すべきなのでしょうか。
この点について参考になりそうな記事があったので引用します。
-----
あらゆるプロジェクトは目標とするベネフィットを実現する必要があります。企業が成功を測定するための唯一の方法が、それらのベネフィットを予め定義してき、各プロジェクトの完了後にそれが組織にどのような影響を及ぼしたか追跡することです。
-----
メトリクスを設定していなければビジネス価値を測定することはできません。そして、ビジネス価値を測定していなければ顧客のニーズを満たすことはできないのです。
-----
戦略的価値を評価する５つの測定基準の例

価値：ソリューションは組織を目標に向かって前進させるものか？
満足度：代替案（他の選択肢）と比較して、ユーザーに価値を創出するものか？
パフォーマンス：契約どおりの内容を契約どおりのレベルで実施できたか？
コスト（費用対効果）：コストに見合うだけの価値を実現できたか？
リスク：適切な保護や統制によってリスクを軽減できるか？
-----
本来、同じプロジェクトは２つとありません。しかし、メトリクスの観点では、組織内の全てのプロジェクトを同じ場所に並べ、同質のものとしてポートフォリオまたはプログラムの観点から評価しなければなりません。
-----
PM Network(2013年8月号) 「Value Proposition」より抜粋

プロジェクトマネジメントに求められるものとして、プログラムやポートフォリオの視点における評価基準に応える責任も含まれていると言えます。

記事の例を参考に、今後のプロジェクト成功の評価基準として：「QCD+VSPCR」というのも一つの考え方としてアリかもしれません。

「ドラッカー・スクールで学んだ本当のマネジメント」を読んで

中嶋です。
W杯が終わり梅雨も明け、いよいよ夏到来です。
猛暑続きで屋内に籠って読書することが多くなったこともあり、
先月に引き続き読書ネタを書かせていただきます。

今回のテーマはこちらです。

ドラッカー・スクールで学んだ本当のマネジメント
藤田勝利　著

出版社：日本実業出版社
発売日：2013-07-19
価格　：¥1,944


Amazonで詳しく見る by G-Tools


ドラッカーといえばマネジメント、マネジメントといえばドラッカーということで、
ドラッカー関連の書籍の１冊として、今回手に取って読みました。

本書は実際に著者がドラッカー・スクールに留学し、
そこでマネジメントについて学んだことを実際にどう活かしたかという視点で
まとめています。

目次：
第１章：　「セルフ・マネジメント」から始まる
第２章：　マネージャーは何をめざすのか
第３章：　マーケティングの本質−顧客創造的な会社とは
第４章：　イノベーションという最強の戦略
第５章：　会計とマネジメントの「つながり」
第６章：　成果をあげる組織とチーム
第７章：　情報技術とコミュニケーションについて本当に大事なこと

若干異なるところもあるかもしれませんが、
実はこの章立て、スクールで実際に学ぶ順に章立てしているそうです。
いきなり組織論を学ぶのではなく、
しかも自分自身（セルフ・マネジメント）から始めるというところが、
個人的には驚きでした。

というのも、ドラッカー・スクールには以下の原則があるそうです。

　「自分自身をマネジメントできなければ、組織をマネジメントすることはできない」
　（第１章より引用）

どうですか？
当たり前の話ではありますが、改めて言葉にされると、実に耳が痛くなりますね。
過去を振り返ってみても、なかなか自分を理解している人は少ないように思います。

これはマネジメントに携わる人だけに限った話ではありません。
まずは自分。自分自身の強み・弱み、興味がある分野、今後やってみたいことを
しっかり理解していないと、弱みばかり出すことになってしまって
成果も出せない状態になりかねません。
※W杯でも個の力、レベルというのが問われていたように思います。

やはり強い組織、成果を出す組織とは、
　個々が自分の役割を分かっている→自分の強みを知っている
であることが絶対条件だと思います。
また、強みにフォーカスした組織であれば相乗効果として、
　お互いを尊重し合える、信頼し合える
ことにも繋がります。「信頼し合える」とは「任せる」ことが出来るということです。
信頼出来なければ"指示"は出来ても、"委任"は出来ないと思います。
"指示"ではコントロールしているだけで、マネジメントとはいえません。
信頼し合える組織になるためにも、マネージャーは組織体制を形成するときに、
個々のメンバーの個性をしっかり理解していただきたいものです。

自分自身が過去に携わったプロジェクトを振り返ってみても、
成功したプロジェクトは大変だった時期があったとしても活気があり、
全体としてモチベーションが高かったように感じます。
それも冷静に考えてみると、誰に何をやってもらうのがいいか？と
人にフォーカスを当てて組織づくりをしていたように思います。
そう思うと、計画って面倒くさいことだけど重要なことなんだと改めて思いました。

第２章では、
　マネジメントとは、人と組織を活かして社会的な成果をあげる、そして、結果として
　多くの人の人生を、よりよくすることができる仕事である（第２章より引用）
と書いてあるのも納得です。人の成長、楽しさを生み出せる仕事ではないかと思います。
一番楽しいのは、信頼出来るメンバーとお客さまへの成果を出すことです。
それを推進していけるのが、マネジメントであり、マネージャーだと私は思っています。

管理職ではなく、マネージャーになりたいという人がもっと増えればいいのに…
という想いを残して、今回のブログはおしまいにしたいと思います。

データ分析と人材

藤原です。
最近、担当業務の関係上「データの利活用」について考える機会が増えていることもあり、今回は、IT投資管理とデータ分析、それを担う人材について感じたことを少し述べたいと思います。

「ビッグデータ」「データサイエンティスト」というキーワードもバズワード感が否めませんが、企業においては、依然としてビッグデータ活用への関心は高く、先日参加した日本データマネジメントコンソーシアム主催の「データマネジメント2014」の盛況ぶりからも、その様子が伺えました。

ではデータを活用する上で、企業が感じている課題認識はどういうものでしょうか。
少し前のものなりますが、野村総合研究所から発表されたアンケート結果では、ビッグデータの活用に対する課題・問題として、以下が項目が上位に挙げられています。

• 活用目的の明確化
• 投資対効果
• スキルや人材

スキル・人材について、「データサイエンティスト」という職種に対する注目度や認知度もあり、データ分析スキルを備えた人材は着実に増えていると感じています。

数日前に経営科学系研究部会連合協議会が主催する「データ解析コンペティション成果報告会」を拝聴してきました。
このコンペは、大学生や一般から応募された各チームが、題材として提供されたデータを基に、様々なテーマにそってデータ解析を行い、その分析手法の学術的新規性や、ビジネスへの適用性等の視点から競うものです。

その成果報告会では、多くの大学生が様々な分析アルゴリズムを構築し、データ分析を実施した結果をプレゼンしており、その内容のレベルの高さや取組みへの熱意が感じられ、将来のデータ分析を担う人材の出現を大いに期待できるものでした。
今回、データサイエンティスト予備軍ともいうべき、多くの大学生の方々のデータ分析への取組みに触れ、とても良い刺激を受けました。

そんな若きデータ分析の人材が、今後実務を担っていくにあたって留意していくべきことは、 データ利活用・データ分析はあくまで”手段”であって”目的”ではないため、データ分析結果がどのようにビジネス課題の解決に寄与するかが重要であり、常に意識すべき点となります。
そのため、「データ分析や統計スキル」だけでなく、「ビジネスや業務のスキル」や『ITのスキル」といった総合的な能力が求められます。
しかしながら、これら全てを網羅的に、かつ高いレベルで備えることは難しいので、実際には各々の分野に強みを持つ人材がうまく連携することが必要だと考えます。
データ分析の実務者として有名な大阪ガスの河本さんが所長を勤めるビジネスアナリシスセンターもデータ分析の専門家だけで組織されているわけではなく、様々な分野のスペシャリストによって構成されているとのことでした。

企業としては、データ分析スキルや人材確保を単体の課題認識として捉えるのではなく、ビジネス課題を解決するために、データ活用を支える総合的な組織づくりや企業文化を醸成することが必要ですし、
データ分析を担う人材は、自身の専門性をビジネスに活かすことを常に考えてアンテナを張り、ビジネス課題に対する成果を求めていく姿勢が重要であるように感じます。

データの利活用は、IT投資管理においても非常に重要な要素であると私は考えています。

戦略的なIT投資を実施していくにあたり、データに裏付けられた事実とそこから導かれる将来予測や最適化などの分析結果が、投資判断における様々な意思決定の支援となります。
（そこには、IT投資管理に必要となるデータが、手入力によって得られるものを含むことに起因する「精度」や「信頼性」という課題はあるかもしれませんが）

今回、私が刺激を受けた若きデータ分析エンジニアの方々が、今後、IT投資管理の分野においてもその価値を発揮していくことを期待します。

PMIの2014年パルス・オブ・ザ・プロフェッションを読んで

中嶋です。
2014年2月も今日で終わり、いよいよ花粉シーズン到来ですね。
花粉症対策はバッチリですか？

--------------------------------------------------
さて、今回は「PMIの2014年パルス・オブ・ザ・プロフェッション」を読んで、
自分なりの考察をまとめたいと思います。（記事はこちら）

要約すると、
「プロジェクトやプログラムに投資している額に対して、10%近く損失が出ている」
「業績の良し悪しでプロジェクトの成功率が50%近くも変わる」
とのことで、まだまだプロジェクトに対する改善の余地ありとなります。
プロジェクト改善に向けて日々頑張っている自分としては、非常に耳の痛い話です。

これだけだと残念なお話でおしまいとなってしまうのですが、
成功率を上げるために注力するポイントについても記載してくれています。

改善ポイント１：人材
　変化に対応できる社風を作り出すこと
　プロジェクトマネージャー向け能力開発プログラムとキャリアパスを提供すること
改善ポイント２：プロセス
　改善ポイント１の取り組みを推進する支援者、プロセスを確立すること
改善ポイント３：成果
　プロジェクトの評価基準を確立し、振り返りの文化を定着させること

要するに、
　「プロジェクトマネージャーを育てる環境を作りましょう」
ということでしょうか？

確かにマネジメントが定着していないプロジェクトは失敗する傾向にあるので、
改善ポイントとしてマネージャーにフォーカスが当たるのも分かります。
しかし、現場でプロジェクトの支援を経験してきた自分からすると、
マネージャーになる前から「マネジメント」を学ばせておくことが重要と感じています。

マネジメント力は、後天的に得ることが出来る能力ではありますが、
センスの有る・無し、向き・不向きによって成長までの時間も個人差があります。
また、組織の全員がマネージャーになる必要はありませんので、
将来のマネージャー候補を見つけるという意味でも、
早くからマネジメントを学ばせる・経験させることは大切です。

そういった意味では、マネージャーではなく、
　「"新人や入社前から"マネジメントについて学ばせる、擬似的に経験させる」
といった環境作りが大切なのかもしれませんね。

プロジェクトの失敗についての考察

中嶋です。
今回はIT投資マネジメントから話がそれてしまいますが、プロジェクトの失敗についての自分なりの考察を書いてみようと思います。


先日、こんな記事がITproで掲載されていました。

　ITpro：なぜプロジェクトマネジメントは機能しないのか

「プロジェクトの成功率は3割にも満たない」と言われ続けていますが、こういった記事を見ると、如何にプロジェクトを成功させることが困難であるかを改めて感じます。昔と違って、マネジメント系の教育も充実していますし、プロジェクトマネジメントやPMPといったマネジメント系の資格取得者も増えているというのに何故改善しないんでしょう？

色々な理由があってプロジェクトは失敗してしまうわけですが、根本原因は以下２つではないかと私は考えています。
　１．スコープが定義出来ていない
　２．プロジェクトの振り返りをしっかり行っていない
以下で、それぞれについて意見を述べたいと思います。

１．スコープが定義出来ていない
これは、見積が甘かったという声を取り上げたものです。要件（機能・非機能）、要員、コスト・・・色々あるとは思いますが、いずれもスコープが正しく定義出来なかったから起こる事象です。
では、スコープは要件定義段階で明確に定義出来るものなのでしょうか？答えはNoだと思います。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プロジェクトの効果を測定してみたいものです。

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

「IT投資マネジメントの変革」（松島桂樹編著）発刊！

河田です。
今回は、昨日（3/14）発刊された「IT投資マネジメントの変革」をご紹介します。

IT投資マネジメントの変革 松島桂樹 白桃書房 2013-03-20 売り上げランキング : 30050 Amazonで詳しく見る by G-Tools

この本は、国内でIT投資マネジメント分野の第一人者である武蔵大学 経済学部の松島教授が執筆・編集された書籍で、「戦略的IT投資マネジメント」（1999年）、「IT投資マネジメントの発展」（2007年）に続くシリーズ3作目の書籍になります。

執筆者には松島先生に加えてこの分野で一流の研究者、実務家の方々9名（＋α）が参加されていますので、内容としても理論的に学べる内容だけでなく、実践的に役立つ内容も多く含まれています。

発売されたばかりの新書なので、具体的な内容の紹介は控え、皆さんにも是非本書を読んで頂きたいと思いますが、参考までに目次をご案内すると・・・

第１部 グローバリゼーションの環境変化とITの動向
　序章 グローバル時代のIT経営戦略
　２章 企業経営にとってのIFRS

第２部 IT投資の資産価値の増大
　３章 ライフサイクルポートフォリオマネジメント
　４章 情報システム構築における経営者の役割
　５章 オペレーション・マネジメントの価値増大
　６章 BCPにどこまで投資すべきか～IT-BCP投資マネジメント 

第３部 グローバル、グループ経営におけるIT投資戦略
　７章 情報システム部門の再構築～戦略的IT組織とは
　８章 中小企業にとってのIT投資マネジメント
　９章　IFRSで変わる企業会計情報システム
　終章 IT投資マネジメントの研究方法

という3部構成になっています。

国内でIT投資マネジメントを約15年間研究されてきた松島先生が編著され、多くの有識者が関わっていますので、IT投資マネジメントに関心がある方は勿論のこと、IT＋経営というテーマに興味がある方には、きっと何らかの気づきが得られるのではないかと思います。

出版社の白桃書房でも、、、

近年の経営環境の変化によりＩＴ投資マネジメントの必要性はますます高まった。本書は，経営のグローバリゼーション，IFRS，クラウドコンピューティングを取り上げ，それらのＩＴ投資マネジメントへの影響と改革を考察。企業経営者・SIer必読の書

と紹介されています。

そして、何故か？？？私も共著者の末席に加えて頂き、5章を共同執筆しています！
（という訳で、上記の＋αは私のコトです。書評等で5章を酷評しないで下さいね。）

5章の内容は、このBlogの過去のエントリ「IT投資のオペレーションマネジメントとは？」でご紹介した内容にも深く関係していますが、一般にネガティブな捉えられ方をすることが多い、運用保守フェーズのIT投資のあり方について、書いています。

実は、、、前職のITコンサルファーム時代に、二作目の「IT投資マネジメントの発展」を読み、松島先生が提唱されている「合意形成モデル」を知ったことが、IT投資マネジメント分野に本格的に向き合うことになったキッカケだったので、数年経った現在にこのような形で三作目に携わることができたことは、とても感慨深く感じています。

ちなみに・・・この本はタイトルの通り、従来のIT投資マネジメントの考え方・アプローチの「変革」に踏み込んだ内容でもあるので、これから該当分野に携わる方には、二作目の「IT投資マネジメントの発展」から読むと、より理解が深まると思います。

IT投資マネジメントの発展―IT投資効果の最大化を目指して 松島 桂樹 白桃書房 2007-05 売り上げランキング : 183072 Amazonで詳しく見る by G-Tools

最後に・・・、この本を通して、本の執筆の大変さ、編集作業の難しさを知り得たことは、とても貴重な経験になりました。関係者の皆さんには、本当に感謝の気持ちで一杯です。

この場を借りて、改めて、、、ありがとうございました！

ITポートフォリオの実践に必要な3つのポイント

河田です。
昨年の振返り結果から、「アプリケーションポートフォリオ」、「PPM」に注目して、このBlogを訪問する方が多いことが分かりましたので、今回は「ITポートフォリオ」に関する話を少し。

ITポートフォリオについては、このBlogでも何度か取り上げたこともあり、抽象的な概念はある程度確立されているものの、具体論については見かけることが非常に少ないと感じています。

実は、昨年から「ITポートフォリオ」を中心テーマと扱っている研究会に参加し、多くの企業の皆さんと情報交換/意見交換をさせて頂いていますが、他のIT投資マネジメントの取組みに比べて実際の導入例は非常に少ないと感じています。

このような背景を踏まえ、今回はITポートフォリオの理論ではなく、実践向けのアプローチとして、具体的な手法と、ITポートフォリオを考える上で重要な3つのポイントについてご紹介します。

まず、「ITポートフォリオ」と聞くと・・・イメージでは、「戦略適合性」×「実現性」、「ROI」×「投資額」といった組合せのバブルチャートの例がよく使われます（私もイメージの説明にはよく使います）。

しかし、実際にITポートフォリオを活用する際には、このモデルは一つの例に過ぎず、
　①どのような評価軸で分類するか？
　②その評価軸をどうやってスコアリングするか？
という点が、実務上は非常に重要なポイントになります。

この①評価軸、②スコアリング方法については、何らかの正解がある訳ではなく実は色々な考え方があるので、まずは汎用的に公開されている情報からいくつかの手法をご紹介します。

----------
1．経産省の「業績評価参照モデル（PRM)を用いたITポートフォリオモデル活用ガイド」

• 「戦略適合性」×「実現性」の2軸で評価

• 戦略適合性は、有効性、必然性、影響範囲の3視点で評価（計30点）

• 実現性は、外部リスク、人的・組織的リスク、技術的リスク、プロジェクトリスクの4視点で評価（計20点）

• 評価結果を4象限（2軸×平均値以上/以下）で分類し、案件を評価

2．経産省の「研修所研修教材」におけるITポートフォリオ
　＜出典：経産省「IT経営協議会（H20.6）討議用使用」＞　

• 既存システムは「満足度」×「コスト要因」の2軸で評価（新規システムは業績参照モデルと同じ評価）

• 満足度は、効果、機能充足度、操作性の3視点で評価（計40点）

• コスト要因は、外部コスト、職員稼働量の2視点で評価（計25点）

• 評価結果を4象限（2軸×平均値以上/以下）で分類し、案件を評価

3．政府調達のためのＩＴ投資評価に関する調査研究

• 戦略軸×技術軸の2軸で評価

• 戦略軸は、下記5つの視点(8項目)で評価(50点)

• 技術軸は、全般、開発 or 運用/インフラ視点(7項目)で評価(50点)
   （開発、運用/インフラ視点は選択制）

4．米国GSA(連邦政府一般調達局)の「Capital Planning and IT Investment Guide」
＜「政府調達のためのＩＴ投資評価に関する調査研究」より引用＞

• 「Technical Rating(技術要素)」×「Strategic Factor Rating(戦略要素)」の2軸で評価

• 技術要素は、一般、開発 or 運用/インフラの視点(6～7項目)で評価(50点)

• 戦略要素は、戦略的インパクト、便益への展望等の5視点(8項目)で評価(50点)

5．米国OMB(行政管理予算局)の「CAPITAL PROGRAMMING GUIDE v3.0」

• 「Suitability」×「Fitness」の2軸で評価

• Suitabilityには、Strategic Alignment、Performance Measures等の指標を利用

• Fitnessには、Serviece Reference Model、Technical Reference Model等の指標を利用

----------

如何でしょう？
リンク集のような話になってしまいましたが、実務者にとって少しは役立つ情報だったでしょうか？

文章だけでは、イメージし難い内容だと思いますので、興味のある方は各リンクからソース情報を是非ご参照下さい。

まずは、全体的なイメージだけでも掴みたいという方は、上記を含めたITポートフォリオモデルの概要を以下に公開しています。

20121108 itポートフォリオの公開モデルのご紹介と応用例 from Tetsu Kawata

今回は手法を中心にITポートフォリオを紹介しましたが、実際にITポートフォリオを活用する際の3つ目のポイント（一番重要なポイント）は、
　③採用目的：何を説明するためにITポートフォリを使うのか？
という点にあります。

上述のような手法（テクニック）に走ってしまうと、忘れ去らることが多いですが、
ITポートフォリオは、「案件の取捨選択」、及び「アカウンタビリティ」といった主に経営層への報告に際して特に有効な仕組みですから、「何のために」を強く意識することが重要です。

なお、上記資料では応用例として「サービスポートフォリオ管理」、「投資分類毎のポートフォリオ管理」も紹介していますので、興味のある方は併せてご参照下さい。

最後に…「IT投資マネジメント情報局は、最低でも週次更新しなさい」という厳しくも温かい応援メッセージ付きの年賀状を送ってくれた大先輩のKさん、ご期待に沿えなくて・・・ごめんなさい。

メッセージはとっても嬉しかったのですが、一個人としては情報力（体力とも言う？）がまだまだ足りてないので、「仲間を増やして更新頻度を上げる」という作戦を4月目処で計画中です。
ご期待ください！

ITIM分野の実務者が興味を持ったのは？（2012）

藤原です。
早いもので今年も残すところ、あと2日となりました。
ブログを読んでくださっている皆様にとって、2012年はどのような1年だったでしょうか？

今年から本ブログ「IT投資マネジメント情報局」への投稿を隔月で担当するようになりましたが、ブログ記事を書くにあたり、様々な関連分野の情報に触れる機会が増えたことで、自分自身にとって多くの「気づき」や「学び」へ繋がる良いきっかけになりました。

多くの参考情報を提供してくださった諸先輩や、このブログを見てくれた方々、フィードバックをくださった読者の皆様に深く感謝します。

今回は年内最後の投稿ということで、1年の振り返りとして毎年恒例？となりました　Google Analyticsの統計データから一部をご紹介したいと思います。



■全体傾向（訪問数、ページビュー数、他）

• 訪問者数は昨年に比べ、約500人程度（昨年は3,332）増加しています。
• 残念ながら、直帰率が昨年より2%ほど増えています。

月に一度の投稿ではありますが、前年比で訪問者数が増えていることはとても嬉しいです。ただ、昨年と同様に直帰率が高い状況にあるということは、新たに興味を持った方々にとって、コンテンツの内容として、まだまだ期待に応えられていないということですね。


■参照元（ソースメディア）

• 参照元は、昨年同様にGoogleからの検索結果が一番多い（約6割）です。
• facebook経由のアクセスが昨年に比べて僅かながら増えています。 

■検索傾向（キーワード）

• 検索キーワードとしては、昨年と同様に「IT投資」「ガイドライン」が多い傾向にあります。
• 昨年に比べ「アプリケーションポートフォリオ」というキーワードから検索されてきたケースが増えています。
• PPM製品では、「MS Project Server」が最も多く、上位10件には入っていませんが、「ca clarity」「oracle primavera」等での検索によるアクセスもありました。

ガイドライン等が検索傾向として多いのは想定できるとして、「アプリケーションポートフォリオ」や「プロジェクトポートフォリオ」に関連するキーワードが増えている傾向にあるのは、測定・評価ということを重要視する動きが高まっていることの表われなのでしょうか。


■閲覧ページ

• 閲覧ページの上位は、「経産省（JUAS）のIT投資価値評価ガイドライン」、「アプリケーション・ポートフォリオとは？」、「Microsoft Project Server 2010」です。
• 昨年に比べてPPM製品に関するページ「Oracle Primavera」「CA Clarity PPM」「Microsoft Project Server」が多く閲覧されていたようです。

閲覧ページの傾向に加え、検索キーワードでも「PPM　事例」等が数件あったことから、PPM製品に関する注目が高まっているのかもしれません。


■アクセス元（地域）

• アクセス元の地域は、昨年と同様に東京が最も多く、神奈川、大阪と続いています。
• 北海道から沖縄まで全国各地からアクセスがありました。
• 世界で見ると、オーストラリアからが最も多く、100件以上もの訪問数がありました。

2010年、2011年と同様に、同じ評価視点で簡易分析をしてみました。

年間の訪問者数が昨年に比べて増加したことは、とても嬉しいことですが、直帰率が依然高い状態であることから、まだまだコンテンツの充実を図っていかなければならないと感じています。

来年もIT投資マネジメントに関連する分野の皆様にとって、有益な情報を発信できるよう取り組んでいきたいと思います。

それでは、最後まで読んでくれた皆様・・・
良いお年を。
来年もどうぞ宜しくお願いします。

IT投資のオペレーション・マネジメントとは？

河田です。
前回の投稿でカリアック会議での発表内容（コンテンツ）を紹介したところ、予想以上に多くの方からアクセスがあったので・・・今回は少し遡って、昨年のカリアック会議での発表の話を少し。

カリアック会議の概要は、過去の投稿「カリアック会議で学んだ3つのコト」で紹介していますが、昨年の会議では「IT投資のオペレーション・マネジメントの価値」というテーマで発表しました。

-------------------------------------------------------------------------------
「オペレーション・マネジメント」とは・・・システム開発後（サービス稼働後）の、運用・保守フェーズにおけるマネジメントの概念を指しています。

一般に「オペレーション・マネジメント」と言うと、主に製造業を中心とした生産管理プロセスの運営管理にフォーカスした話が多いようですが、ここで紹介している「オペレーション・マネジメント」は、企業情報システムにおける運用・保守フェーズのマネジメントを指し、大別して「運用」・「保守」・「稼動資産管理」の3つで構成されます。

なお、企業情報システムの運用・保守フェーズのマネジメントとしては、ITIL（IT Infrastructure Library）が有名ですが、ITILが運用・保守の「プロセス」に着目しているベストプラクティスの概念であるのに対し、オペレーション・マネジメントは該当フェーズの活動を「IT投資マネジメント」の切り口で捉えているところが、一番の違いと言えます。

前置きが長くなりましたが、今回は「オペレーション・マネジメント」について、「環境変化」と「重要性」の2点に絞ってご紹介したいと思います。


【環境の変化】
ITの環境変化は数え上げればキリがない話になりますが、運用・保守フェーズで考えた場合に意識すべき考慮点として、少なくとも以下の3点はインパクトが大きいと考えられます。

1. クラウド化
2. システム開発手法の変化
3. IFRSへの対応

企業情報システムのクラウド化は、言い換えれば「システムがサービス化し、選択責任が利用者に移ること」ですが、クラウド化の進展により、従来以上にシステムの「サービス」という側面が意識されることになります。
サービス化されたシステムは環境変化に柔軟に対応するための対応（システムの機能追加、品質向上に繋がる継続的な改善）が従来以上に強く・素早く求められると言えます。

少し刺激的なタイトルですが、下記の特集も興味深いですね。

• SIと運用が消える（IT Pro）

また、システム開発手法の変化という面でも、大規模システムはまだ従来手法ながら、新規の小中う規模システムにはアジャイル開発の採用、継続を前提とした開発が増えてきていますね。

• 従来の開発では投資効果が悪すぎる（IT Pro）

また、会計制度としてのIFRS対応という面でも、（今後の議論の進展によっては）大きな影響が考えられます。
具体的には、投資判断の基準が「収益基準」から「資産負債基準」にシフトすることで、結果として下記を考慮する形で運用・保守フェーズで継続的にIT資産の管理が求められる可能性もあります。

• 従来以上に投資結果を資産/負債として正しく把握する
• IT投資においても資産、費用を正しく管理すること（耐用年数、減損）

このような環境変化に加えて、オペレーション・マネジメントの対象業務そのものも変化しています。

つまり、オペレーション・マネジメントの目的も「情報システムの維持・運行」から、「IT資産価値の維持・増大」へと変わらざるを得ない状況が生まれていると言えます。


【オペレーション・マネジメントの重要性】
運用・保守フェーズにおける調査・分析レポートは非常に少ないですが、該当分野にフォーカスを当てている調査の一つである、JUASのソフトウェアメトリックス調査によれば・・・

• 多くの企業において、新規開発より維持費用に多くのコストがかかっているのが実情
• 一定規模のシステムで、追加開発無しで継続利用するシステムはない
• 自社開発システムの約6割は、稼動時の品質が「普通以下」と評価
• 自社開発システムは、稼動後5年間で初期開発費の約5割に相当する保守費が発生

ということが報告されています。

このような状況を踏まえて、システム開発のライフサイクルに対応つけられたIT投資マネジメントのサイクルについても、変化が求められています。

• 従来は、企画・計画フェーズのIT投資判断の在り方（所謂、事前評価）の議論が中心
  ⇒今後は、運用・保守フェーズのIT投資判断の在り方の議論も必要
• 従来の事後評価は、事前評価の結果証明が中心
  ⇒今後は、機能追加を含む「保守」の評価の組み込み、システム稼働後の資産評価も必要

また、下記の点を考えれば、オペレーション・マネジメントはこれからもっと議論されるべき余地があると言えます。

• 新規開発費のどう使うか？という積極的な議論に対し、維持費用は常に消極的なコスト削減議論の対象に留まることが多い
• 維持費用と一言で言っても、投資の性質は一律ではなく、企業戦略に基づく大きな機能追加対応（拡張保守等）も増えている
• 新規に開発するシステムは稼働するまで何ら価値を生み出すことは ないが、稼働中のシステムは既に何らかの価値を生み出している

このような点を考えていくと、「維持運用を重視」とは言わないまでも、「軽視すべきでは無い」と言えますね。

ちなみに、冒頭で触れたITILについて、2000年に公開されたv2と2007年に公開されたv3を比較してみると、ITILの変化にオペレーション・マネジメントとの関連性が見えてきます。
切り口が違うITILの変化からも、オペレーション・マネジメントの必要性が言えますね。

【まとめ】

• 今後のIT投資マネジメントでは、オペレーション・マネジメントが重要なテーマの一つに
• オペレーション・マネジメントでは、 「保守の評価」、「稼動資産の評価」が重要
• オペレーション・マネジメントの取り組みとして、継続的なサービスマネジメントがKeyになる（サービス・ポートフォリオ管理、サービスレベル管理）

最後に、上記の話を含む発表資料を以下に公開しています。

20110904 IT投資のオペレーション・マネジメントの価値 from Tetsu Kawata

オペレーション・マネジメントはIT投資マネジメントの中ではこれからの分野ですが、机上論ではなく実践的なアプローチが求められる段階になってきたと感じています。

IT業界の中ではネガティブなイメージが多いこの分野において、このエントリを見て、「オペレーション・マネジメントの価値」に興味を持つ方が一人でも増えてくれるとを願っています。

カリアック会議で学んだ3つのコト

河田です。
9月8日（土）～9（日）に、「中小企業のＩＴ経営研究会」浜名湖フォーラム（通称：カリアック会議）に参加しましたので、今回はその話について少し。

-------------------------------------------------------------------------------
カリアック会議は、

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

3者合同の研究合宿で、浜名湖畔のカリアック（商工会議所研修センター）で開催されました。

実際のセッション内容、雰囲気については、参加者の一人であるシーポイントの佐野さんが写真付きのBlog記事「カリアックで鍛える」で紹介されていますが、

大学教授の先生方にはじまり、
各界で、全国で活躍の皆さんが、ここ「浜名湖畔 カリアック」に集合したのです。
まるでメジャーリーグのオールスターを観てる気分でした。
この「演題タイトル」、まじ、スゴイっすよ。

という説明には、私も同感です。


今回で二回目の参加となる研究合宿でしたが、前回以上に多岐に渡るテーマに関する発表がなされ、とても中身の濃い時間を過ごせたと思います。


様々な分野の専門家、有識者、経営者の方々が集まり、肩書きや立場に関係なく議論するというスタイルは、とても新鮮で、会場に熱気があり、そして・・・心地良い緊張感も漂いました。

個々のテーマについて学んだコトを書くと、、、キリが無いくらいに色々な話があったのですが、その中でも特に私にとって重要な「気づき」に繋がったコトを3つご紹介します。

発表を聞いていないと・・・
議論に参加していないと・・・
そして一緒に深夜までお酒を飲んでいないと・・・？？？、
文章だけでは上手く伝えられない気がしてとても残念ですが、、、備忘録も兼ねて。

1. Catalyst(触媒）としてのクラウドの重要性
   これまで個々個別に行われていた互いの業務や作業を結合させ、互いに利益をもたらす新たなビジネスのモデルを作り出すまでの設計がITベンダーに求められている（横田先生、スマイルワークス：坂本さん） 
   →クラウドの価値をコスト抑制、費用化モデル、俊敏性等のITリソースの所有/利用の世界で語るのではなく、クラウドのプラットフォームが無ければ実現できない「新たな付加価値」の視点で、実例も交えた話として聞けたのは、とても興味深いです。


2. 個別の具体論ではなく、共通項から本質を考えることの重要性
   共通項を考えないで、個別の案件、取り組みの成果を比べることに意味は無いし、議論のテーマじゃない。個々の案件、取り組みにどんな共通性があったのか？その取組みはビジネスの成功に正しく繋がったのか？という本質を考えるべき。（手島先生）
   →「耳が痛い」というのは正に。。。と感じるお話でした。分かりやすい具体論（成功例）にはついつい共感しがちですが、本当に重要なのはケース・バイ・ケースの例ではなく、共通項であり抽象化できる概念、本質ですよね。


3. ヘテロジニアスの重要性
   ヘテロジニアスな世界で勝負をしなければ、人間は成長できない。ホモジニアスな世界は居心地が良いが、大して成長しない。企業人はもっと積極的に外の社会に出て、異質な世界から多くのことを学ばなければならない。（黒岩先生）
   →技術の世界で広く深く世界と関わり、道を切り開いてきた方だからこそ・・・の重みのある話でしたが、偶然にも自分の経験と重なる部分が少しあったことも嬉しかったです。

私の中では、とても重要な気づきだったのですが、自分で書いた文章を読み返してみると、相互の関連性も無く、伝わり難いですね。ホントに。。。
この拙い表現でも、詳しく知りたいという方がもしいらっしゃったら、ご連絡下さい。

ちなみに、カリアック会議では「ソフトウェア資産管理とIT投資マネジメントの関係性」というテーマで、拙いながら…私も発表させてもらいました。

20120909 ソフトウェア資産管理とIT投資マネジメントの関係性 from Tetsu Kawata

このBlogの過去のエントリ「「ソフトウェア資産管理（SAM）とは？」、「ソフトウェア資産管理（SAM）とは？（その2）」の延長線上の話ですが、
多くの有識者の方々から貴重な指摘をもらえたことは、とても有難く、
また一部の方から共感のコメントを頂けたことは、とても嬉しかったです。

最後に、この貴重な機会を提供して頂いた関係者の皆さん（特に、松島先生、IBMの栗山さん、日本商工会議所の小松さん）には、「感謝」以外の言葉が見当たりません。

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

BABOKとIT投資マネジメントの関連性

藤原です。
3回目の投稿になりますが、隔月とはいえ、
テーマを意識したネタ探しや作文というのは、なかなか大変ですね。

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

少し前に、BABOK（Business Analysis Body Of Knowledge）の研修に参加しました。
研修や自身での勉強を通じてBABOKを読み解く中で、IT投資マネジメント活動との関連性を感じる部分があったので、今回はその話をしたいと思います。

BABOK、BAとは？

BABOKとは、ビジネスアナリシス（BA）を行う為に必要なタスクやテクニックをまとめた知識体系であり、BA活動に関する共通のフレームワークです。
カナダのIIBA（International Institute of Business Analysis）という団体が2005年に初版を発行し、現在2.0版が最新となっています。

ビジネスアナリシス（BA）は以下のように定義されています。

ビジネスアナリシスとは、組織の構造とポリシーおよび業務運用について理解を深め、組織の目的達成に役立つソリューションを推進するために、ステークホルダー間の橋渡しとなるタスクとテクニックをまとめたものである。

また、BA活動を7つの知識エリアとして定義しています。
各知識エリアには、それぞれ関連する複数のタスクが含まれています。

• 計画と監視
• 引き出し
• 要求マネジメントとコミュニケーション
• 企業分析（EA）
• 要求分析（RA）
• ソリューションの評価と妥当性確認（SAV）
• 基礎コンピテンシー

それぞれの知識エリアに関する詳細説明は、今回は省略させていただきますが、各種情報サイトの多くの記事で紹介されておりますので、そちらを参照ください。

また、BABOK自体も、IIBA日本支部のHPから購入することが可能です。
http://store.iiba-japan.org/

BABOKに記述される各知識エリア・タスク全体を通して、
BA活動のポイントを概略すると、以下となります。

• 組織、業務を理解し、組織のビジネス上のゴールや目的を明確化する
• ステークホルダーが目的の達成に必要とする機能や能力を要求として引き出し、構造化し、文書化する
• 要求を分析し、目的達成との整合性を確認する
• 実装担当（プロジェクト）に要求を正しく伝達し、提案されたソリューションの妥当性を確認する
• 導入されたソリューションのパフォーマンスを評価する

BAタスクとIT投資マネジメントとの関連性は？

BA活動について、IT投資マネジメントの活動の関連性としては、

• 組織の目的、その達成に必要な「要求」に関して、評価・判断するための指標を定義することを重要としている点
• 組織の目的を達成するための「要求」に優先順位を付け、妥当性を確認するタスクを有している点
• ソリューション導入後に、要求を満足する効果を果たしているか評価し、次の分析活動へ繋げるタスクを有している点

が挙げられると思います。

BABOKでは、ビジネス上のゴール、目的は「SMARTであるべき」としています。

　S：Specific（具体的）
　M：Measurable（測定可能）
　A：Achievable（現実的）
　R：Relevant（目的と関連している）
　T：Time-bounded（締切りがある）

また、優先順位付けられた「要求」（そして、その要求を満足するソリューションに対して投資すること）が妥当かを判断するための指標についても例示しています。

• 前提条件の識別
• 評価基準の設定（KPI）
• ビジネス価値の確認
• 要求トレーサビリティの確認
• ビジネスケースとの整合性
• 機会コスト

以下のタスクに関しては、「測定可能な評価基準の定義が必要」としています。

　「5.5　ビジネスケースの定義」
　「6.6　要求の妥当性確認」
　「7.6　ソリューションのパフォーマンス評価」

BAタスクに記述されている、投資する要求、ソリューションに対する妥当性確認や、導入したソリューションに対して、定量的・定性的な評価を行い、その効果を判断すると共に、次の取組みへと繋ぐ活動は、IT投資マネジメントにおいても共通であると思います。


私自身、BABOKについてまだまだ勉強不足で、解釈の間違い等があるかもしれません。
今後、読み解きを続ける中で、また新たな気づきがあれば、ご紹介したいと思います。

ソフトウェア資産管理（SAM）とは？（その2）

少し前に「ソフトウェア資産管理（SAM）とは？」というエントリでソフトウェア資産管理の概要、及び対象範囲に触れましたが、今回はその続きです。

ソフトウェア資産管理の対象範囲が、「基準/ガイドラインで定義された範囲」と、「一般的に実務で扱われる際の範囲」で大きな差異があることは前回書きましたが、この違いは以下の2つの問題に起因しているのではないか？と考えています。

• 技術的な仕組みの問題
• 会計上の管理の問題

つまり、概念モデル（机上論）としては広範な範囲を対象にできるけど、実務上は上記の問題が解決できないために、、、結果として範囲が限定的になるのではないかな？と。


「技術的な仕組み」については、今回のテーマではないので、簡単に触れておくと・・・
汎用性、共通性、標準性の高いクライアントPCに比べサーバーの技術仕様を標準化することが難しいことがその真因と考えています（具体的に言えば、OSレベルで異なること、エージェントアプリの導入による影響が懸念されること、それらに起因するAPIの課題・・・が挙げられます）。

前置きが長くなりましたが、今回はこの「会計上の管理」に関係するソフトウェア資産管理におけるIT投資のアプローチについて、少し考えてみたいと思います。

【国内会計基準におけるソフトウェア資産の扱い】
まず、会計制度的な扱いについて、国内ではソフトウェア資産（無形固定資産）に関する包括的な規定が無いため、下記の2つの規定からその目的に応じて会計処理が判断されることになります。

• 「研究開発費等に係る会計基準」企業会計審議会
• 「研究開発費及びソフトウェアの会計処理に関する実務指針」会計制度委員報告第12号

このため、多くの企業においてソフトウェア資産は、「自社利用ソフトウェア」という扱いの無形固定資産として計上され、5年の定額法で減価償却することが一般的になっています。


つまり、ソフトウェア資産として一時的に資産化はされるものの、あくまで会計上の費用処理の管理であり、仮に6年以上利用するアプリケーションであったとしても、減価償却後の価値は認められていません。（言い換えれば、「価値」としては管理されていないことになります）


【国際会計基準（IFRS）におけるソフトウェア資産の扱い】
少し視野を広げて国際会計基準（IFRS）におけるソフトウェア資産の扱いを見てみると・・・国内基準とは考え方が少し違います。

IAS第38号によれば、（ソフトウェア資産を含む）無形資産は
「過去の事象の結果として企業が支配し、かつ、将来の経済的便益が企業に流入することが期待される資源のうち、物質的実体のない識別可能な非貨幣性資産」
と定義され、無形資産の要件として、以下の2つが定められています。

1. 資産に起因する、期待される将来の経済的便益が流入する可能性が高いこと
2. 当該資産の取得原価が信頼性をもって測定できること

つまり、国際会計基準では上記の要件さえ満たせばソフトウェアを資産として計上し、継続的に価値を認める（管理する）考え方はあると言えます。

但し、既に国際会計基準（IFRS）導入済みの欧州企業でさえも費用処理／資産化の対応が分かれているのが実情であり、
国内基準への適用（資産化の是非）についても企業会計基準委員会（ASBJ）で「無形資産に関する論点の整理（H21.12.18）」でも問題提起され、「審議事項（５）－３ 検討論点：社内開発費の資産計上について」審議されている状態です。

開発に係る支出を資産計上するか否かについては、それが無形資産の定義に該当し、認識要件を満たす以上は資産計上すべきであるという見方がある一方で、そもそも経済的便益をもたらす蓋然性の要件を判断するのが困難ではないかという点や、その運用において資産計上すべきか否かの判断に企業間でばらつきが生じるのではないかという点から従来通り支出時の費用とすべきであるという見方もある。 

この辺りの難しい論点は会計制度の話なので、専門の会計士の議論の結果を待つしかありませんが、この資産計上の可否はあくまで（財務的な）会計上の扱いの話に過ぎません。

【知的資産としてのソフトウェア資産】
次に、ソフトウェア資産を知的財産／資産として捉えると、まずソフトウェアは知的財産としてそのプログラムの表現が著作権法で保護されています。
そこで、知的財産の会計上の扱い、及び価値評価について少し考えてみると…

• 特許権、商標権に代表される知的資産は、無形固定資産として扱われる
• （企業統合、M&A等の客観的に資産性を算出するタイミングを除けば）財務会計の視点で評価（資産計上）はできない
• 知的資産の価値を評価する目的は多岐に渡る（必ずしも会計的な視点は求められていない）

このように、知的財産は（無形資産と同様に）会計上では評価が難しいものの、内部管理の目的において適正な評価を行い、知財戦略として積極的に活用するという考え方は一般論としても妥当と言えそうです。

【会計区分と管理会計のアプローチ」
ここまでの文章では、会計＝財務的な扱いを前提に書いてきましたが、企業会計には財務会計だけでなく、管理会計のアプローチがあります。

つまり、会計制度に大きく影響を受ける財務会計の視点でソフトウェア資産管理を考えると、様々な面で限界がある（できることもあれば、できないこともある）ことになりますが、管理会計の視点としてソフトウェア資産管理を考える場合は、企業独自の考え方を適用できます。

【まとめ：IT投資マネジメントとソフトウェア資産管理】
最後に、ソフトウエア資産管理とIT投資マネジメントの関係性について、前回・今回の内容を纏めて考えてみると・・・

• ソフトウェア資産管理は「セキュリティ強化、IT投資の最適化」を目的とし、有償/無償を問わないソフトウェア全体（稼働するハードウェアも含む）が本来の対象範囲である→しかし、実際には多くの企業で、「ライセンスコンプライアンス」を目的として、有償ソフトウェアの管理のみに対象範囲が留まっていることが多い（自社開発アプリケーションは事実上管理されていない）
• 国内会計基準では、一時的に資産化はされるものの、あくまで会計上の費用処理（減価償却費）の管理のみで、価値としては管理されていない
• 国際会計基準（IFRS）では、ソフトウェアを資産として計上し、継続的に価値を認める（管理する）考え方はあるものの、その要件は厳しい
• 知的財産としてソフトウェア資産を（財務）会計視点で（資産計上することを考慮して）価値評価することは難しい
  →しかし、管理会計の視点で「自社の経営管理に役立つ情報」と位置づけ、適正な評価を行い、企業活動に積極的に活用するという考え方は一般論としても妥当

このように見てみると、「IT投資マネジメントの一つのテーマとしてソフトウェア資産管理を扱う意義は大きい」という仮説が成り立つのではないかと考えています。

今回は様々な視点での概論になりましたが、このアプローチについては、現在検討を深めているところなので、内容が纏まった時点で改めて公開したいと思います。

イギリス内閣府『Management of Portfolio（MoP）』の概要

今回は、イギリスの内閣府（Cabinet Office）から発行されているポートフォリオマネジメントのベストプラクティス「Management of Portfolio（MoP）」について、概要をご紹介したいと思います。
イギリス政府では、ベストマネジメントプラクティス（マネジメントに関する成功事例集）に関する多くの文書を発行しています。今回ご紹介するポートフォリオマネジメントに関する文書以外でも、ITサービスマネジメントのベストプラクティスとして認知されている『ITIL』を発行しているのも、このイギリス商務局です。
（発行所管については、2010年に、商務局（OGC）から内閣内閣府（Cabinet Office）に移管されています）

MoPは「適切なポートフォリオ管理のロードマップを設計するために有用なアドバイスを提供するものである」と記されています。
MoPは、5つの原則、及び2つのマネジメントサイクルとそこに含まれる12の慣行（管理項目）によって構成されています。

5つの原則

1. 上級経営者層によるコミットメント
2. ガバナンスとの整合
3. 戦略との整合
4. ポートフォリオオフィス構築
5. 変革の文化に対する意欲

2つのサイクルと12の慣行

1. ポートフォリオ定義サイクル
2. ポートフォリオ実行サイクル

 ポートフォリオ定義サイクルに含まれるプラクティス
「理解（把握）する」
「分類する」
「優先度を設ける」
「バランスを考慮する」
「計画する」

ポートフォリオ実行サイクルに含まれるプラクティス
「マネジメントコントロール」
「ベネフィットマネジメント」
「財務マネジメント」
「リスクマネジメント」
「ステークホルダーマネジメント」
「組織ガバナンス」
「リソースマネジメント」

このような項目で箇条書きすると、知識体系のような印象ですが、MoPは知識体系や標準という位置付けではなく、あくまでガイドという位置付けで、ベストプラクティスの利用事例、ベストプラクティスに関する実践方法等が説明されています。

こうした実例を通して纏められた様々な示唆は、実務における様々な局面において有益な情報になると思います。

今回はご紹介はあくまで概要レベルですので、 ご興味のある方は是非原文をご参照ください。

ソフトウェア資産管理（SAM）とは？

先日、研究会でソフトウェア資産管理（SAM）とIT投資マネジメントの関係性についての話をしたので、今回はその中からソフトウェア管理の話を少し。

【ソフトウェア資産管理（SAM：Software Asset Management）の概要】

• 「組織内のソフトウエア資産の有効な管理、制御及び保護」のために、ライフサイクル全般にわたってソフトウエアの使用・保有状況などを管理する仕組みの総称

• 近年の法規制の変化（利用者視点）と、ソフトウェア違法コピーによる損害の高まり（権利者視点）から、2000年代に入ってから急速に注目を集めている分野

• 2001年にソフトウェア資産管理コンソーシアム（SAMCon）が設立され、「ソフトウェア資産管理基準」を策定すると共に、国内企業のSAM実践に対する啓蒙活動を実施（ ※現在はSAMCon→SAMAC）

背景（法規制の変化等）について、もう少し詳しく知りたいという方は、「ITPro」、「ビジネス＋IT」に分かりやすく纏められています。

【主な管理基準、ガイドライン】

• ISO/IEC19770-1
：ソフトウエア資産管理の国際規格として2006年に策定

• JIS X 0164-1
：ISO/IEC19770-1の同一翻訳（IDT）の国内規格として2010年に策定

• SAMユーザーズガイド
： JIPDECが2010年に公開

• ソフトウェア資産管理基準
：最新版（ｖ3.1）は、SAMMACが2011年に公開

特にISO/IEC19770-1は、色々なサイトで参照扱いされていることが多いですね。

ここからが本題になりますが、、、
ソフトウェア資産管理は、基準/ガイドラインで定義された目的（対象範囲）と、一般的に実務で扱われる際の目的（対象範囲）は、結構違いがあります。

実際にソフトウェア資産管理の目的について、ISO/IEC19770-1では

• 「ITサービスマネジメント全体の有効な支援」

• 「ビジネスリスク管理の促進」

• 「ITサービス及びIT資産に関するコスト管理の促進」

• 「ITを有効に活用することによる競争上の優位を得ること」

と広義の概念が定義され、その対象範囲についても

ソフトウェアの性質に関係なく，すべてのソフトウェア及び関連資産に適用できる。例えば，実行可能ソフトウェア（アプリケーションプログラム，オペレーティングシステム，ユーティリティプログラムなど）及び非実行可能ソフトウェア（フォント，グラフィック，音声，映像，テンプレート，辞書，文書，データなど）に適用できる。（中略） あいまいでない限り，すべてのソフトウェア，すべてのプログラムソフトウェア，特定のプラットフォーム上のすべてのソフトウェア又は特定の製造業者のソフトウェアのような，組織が適切と考える何らかの方法で定義をしてもよい。

と明記されています。

特筆すべきは、OSSに代表される無償ソフトウェアは勿論のこと、内部開発のソフトウェアについても適用可能という点ですね。
実際にISO/IEC19770-1のプロセスとして、「開発」～「展開」～「廃棄」に至るソフトウェアライフサイクルも定義されています。

一方、実務上のソフトウェア資産管理の目的は

• 「著作権法、及び使用許諾条件の順守」

と非常に限定的に扱われ、対象範囲も有償ソフトウェアのみ（≒ソフトウェアライセンス管理）と位置付けている場合が非常に多いのではないかと感じます。

例えば、該当分野の主力製品が提供している機能範囲（主としてPC上のソフトウェア管理、構成管理）からも、上記の傾向は明らかと言えます。
＃どこの製品とは言いませんが・・・「ISO/IEC19770-1に準拠」と明記しながら、PC管理の機能しか提供していない製品もありますね。

基準と実務でこれほど差が大きい管理概念も珍しいのではないでしょうか？

つまり、本来のソフトウェア資産管理は、「セキュリティ強化、IT投資の最適化」を目的とし、有償/無償を問わないソフトウェア全体（稼働するハードウェアも含む）が対象範囲ですが、実際には多くの企業で、「ライセンスコンプライアンス」を目的として、有償ソフトウェアの管理のみに対象範囲が留まっていると言えます。

「あらゆるソフトウェアを管理すべき！」とまでは言いませんが、ソフトウェア「資産」の管理と言いながら、その資産の中身は「PCに関連する保有ライセンスのみ」に限定されるのは、やはりあるべき姿とは言い難いと感じます。

投資額を考えても、、、多くの企業ではPCに関連するソフトウェアコストよりも、システムに関連するソフトウェアコストの方が圧倒的に大きいですから。

勿論、システムに関連するコスト（投資）は、会計的な処理をしている云々の話もあると思いますので、その話は次回に。

プロジェクトマネジメントの視点から

前回エントリの最後に触れた通り、

「複数の視点を取り込むことにより、新たな気づきに繋がれば・・・」

という想いから、今回から隔月で同僚の敏腕プロジェクトマネージャに投稿をお願いすることにしました。

-----
今回、ブログ管理者からの依頼（強制？）を受け、

同僚の一人として記事を投稿することになりました。

拙い文章となりますが、ご容赦ください。

今回のテーマですが、私自身がこれまでの業務を通じてだったり、

或いは現在参加している研究会で諸先輩方から様々な知見を伺う中で

感じたことをメモとして残したいと思います。

私は、発注者側企業におけるPMO（プロジェクトマネジメントオフィス）支援という

立場で仕事をすることが比較的多いです。

そこで感じたのは、

プロジェクト活動において「ビジネス上の成果という戦略的な視点を持つこと」の

重要性です。

まず、企業活動における『プロジェクト』の目的とは何か。

米国のプロジェクトマネジメント協会、PMI（Project Management Institute, Inc.）では組織運営の在り方として「ポートフォリオ」「プログラム」「プロジェクト」の3層のモデルを提示しています。

それぞれの目的を簡単に纏めると（あくまで私が読み取った認識ですが）

・ポートフォリオの目的は、
戦略の実現の為に必要なプロジェクトを選定し、その実績や効果を評価すること。
（これは、IT投資マネジメント活動にも関係するものと考えられます）

・プログラムの目的は、

戦略実現の手段となるプロジェクトを企画・管理することで、戦略実現に貢献すること。 

・プロジェクトの目的は、 

品質・予算・納期等の制約の下、求められる成果物を作り出すこと。 

つまり、プロジェクト活動においては「求められる成果物を作ること」がゴールとも言えます。

プロジェクト関係者にとって、

「厳しい制約条件の下、無事に成果物をリリースし、プロジェクト成功を果たす」

その達成感は何物にも代え難い。大変なプロジェクトなら尚更嬉しい。

そして各々が思うわけです。「目的は達成した」と。

しかし、「プロジェクト」は本来、事業戦略の実現に向けた手段としての活動です。

作り出した成果物が、ビジネス上の成果を生まなければ意味がありません。

プロジェクト活動の実績は、投資効果を測る上での基礎数値となります。

プロジェクト関係者が、ビジネス上の成果という戦略的な視点を持ち、プロジェクトの実績を管理・記録、報告することによって、ポートフォリオへとしっかりと繋げる。

それによって、プロジェクトメンバーにとって、身を削って頑張ったプロジェクトが、

経営戦略の実現へ貢献する成果をもたらしたのか、しっかりと認識することができます。

その評価こそが「プロジェクト活動の意義」を見出すことに繋がるのではないかと思います。

と長々と書きましたが、私自身、PMOの支援をする中で、

まだまだこうした意識への働きかけが十分に出来ているとは言えません。

もっと頑張らないといけないなー、と感じています。

-----
やはりPMPホルダーの視点は「なるほど」と感じさせられます。
私もPMの仕事を通して、PMIの3階層モデルは漠然と理解していましたが・・・改めてその有用性を感じさせられました。
やはり、プロジェクトマネジメントの関係性を意識していくことは、IT投資マネジメントの活動上も重要ですね。