「ITマネジメントの新機軸」（向正道著）を読んで

河田です。
気がつけば、今日で11月も終わり。月日が過ぎるのは本当に早いですね。

研究会でお世話になっている先輩コンサルタントの方から、先日発売されたばかりの
素敵な本を頂きましたので、今回はその本をご紹介します。

経営・事業・ITの三者で進めるITマネジメントの新機軸 向 正道 新日鉄住金ソリューションズ 日経BP社 2013-10-17 売り上げランキング : 13064 Amazonで詳しく見る by G-Tools

この本は、ITコンサルタントという実務家の一面だけではなく、
資源ベース論の研究者としての一面も併せ持つ著者が、
「システム化計画（IT計画）」を中心にITマネジメントのあり方を書かれた本であり、
実務的なテーマを学術的な視点も組み込んでまとめ上げているという点で
非常に貴重な本ではないかと思います。

一般論として、実務家が経験に基づく話を語る場合は、ケースバイケースの偏った
内容になってしまうことも少なくなく、
一方で、研究者の方は時として実務を無視した机上論になっている場合もあるの
ではないかと思いますが、この本はその両面を上手くバランスを取って、セオリーに
基づきながらも地に足のついた話が展開されている本だと感じます。

本の帯に「CIO、情報システム部員必見！」と書かれているのも頷けますね。

発売されたばかりの本なので、具体的な内容は本書を見て欲しいと思いますが、
目次だけご紹介しておくと・・・

第1章　企業における情報システムとその役割
第2章　システム化計画の概要
第3章　経営者視点からのITマネジメント（経営戦略とITの融合）
第4章　事業部門視点からのITマネジメント（ビジネスプロセスと情報）
第5章　情報システム部門視点からのITマネジメント（サービスレベルとコストの最適化）
第6章　IT施策の統合（優先施策と中期ロードマップの作成）
第7章　情報システム部門の組織運営（施策の推進に臨み）

という構成になっています。
各章の終わりには要約があり、頭を整理しながら読み進めることもできます。

IT投資マネジメント、IT投資管理に関して考察するアプローチではないのですが、
システム化計画を通して「IT投資はどのように企業業績を向上させるのか？」
というIT投資のあり方の本質に迫っています。

著者自身が冒頭に書いている通り、所謂ノウハウ本では無いので、目新しさを求める
方にはFITしないかもしれませんが、この分野の仕事に関わる多くの方にとって、
ITマネジメントの全体像が網羅的・体系的にまとめられている点で、非常に示唆に富む
本だと思います。（何度も読み返す価値があります）

私自身、戦略論の経験はまだまだですが・・・あとがきに書かれているシステム化計画が
次の活動につながらないケース（3つの考慮点）は、同じコンサルタントとしてとても共感
できました。

1.報告書の全体感
2.施策の具体性
3.推進責任者が不明確

このキーワードに心当たりのある方は、是非この本を手にとって見て下さい。
日々の多忙な業務の中で、この本を纏めあげた向さん、ホント凄いです。

最後に・・・著者の向さん他、複数企業のコンサルタントの方々、研究者の方々と一緒に、
今年の5月から「IT資産価値研究会」にて研究を深めています。

具体論はこれからですが、
先月の経営情報学会（2013年秋季全国研究発表大会）で
「IT資産の価値評価に関するフレームワークの構築」
というテーマで共同研究発表もしています。

該当テーマの研究に興味のある方はご一報ください。

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

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


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

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

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

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

１．スコープが定義出来ていない
これは、見積が甘かったという声を取り上げたものです。要件（機能・非機能）、要員、コスト・・・色々あるとは思いますが、いずれもスコープが正しく定義出来なかったから起こる事象です。
では、スコープは要件定義段階で明確に定義出来るものなのでしょうか？答えはNoだと思います。ITプロジェクトの成果物が目に見えないという性質上、最終的なイメージを付けづらいからです。そのため、後から後から要望が増え収集がつかなくなったり、そもそも思っていたものと違うものが出来上がって使われないといった事態に陥ってしまいます。

個人的には「大枠のスコープを定義」して、後はお客様との認識ギャップを減らす取り組みを続けたり、発生する可能性のある変更を予め洗い出して共有しておくことが効果的だと思います。

前者は、プロト開発やイテレーション開発、簡単なところではお客様とのコミュニケーションを増やすといったことが考えられます。少しずつ成果物が見えてくれば、お客様のイメージもより具体的になりますし、コミュニケーションを増やすだけでも認識ギャップは大幅に減らせます。特に開発フェーズ等、請負期間中は移行やユーザーテスト、ユーザー教育の話が中心となってしまい、機能イメージの共有等を行わないことが多いように感じますので、やってみる価値は大いにあると思います。

後者は、リスクマネジメントの実践です。マネジメントは実践しているといっても、リスクマネジメントを正しく実践しているプロジェクトは少ないのではないでしょうか？実際リスク一覧を作っているといっても、書いている内容が具体化されていなかったり、洗い出して満足してしまって運用されていないプロジェクトが多いように感じます。まだ実践されていないのであれば、フェーズの開始終了時点だけでも有識者を集めて、リスク検討してみてはいかがでしょうか？


２．プロジェクトの振り返りをしっかり行っていない
プロジェクトの振り返りを行うことは、ナレッジの共有という意味でも非常に有効であると考えています。冒頭で挙げた記事を引用すると、
プロジェクトとは、
　「やったことがないことを何が起こるか分からないのに、計画して、
　　予定通りのモノ（コト）を、期限までつくる（終らせる）こと」
とあるように、分からないことに挑戦することでもあります。プロジェクト推進期間中に、何事も起きないプロジェクトは皆無です。であれば、過去に苦労した情報は貴重で価値のある情報なのですが、あまり共有・活用されない傾向にあります。
それもそのはずで、振り返りはプロジェクト期間外（終了後）に行われることが多く、実践したとしても主要メンバーが別プロジェクトに参画してしまい、なかなか本質を突いた振り返りが出来ていないからです。
これを防ぐためにも、フェーズの切れ目で振り返りを行うことをオススメします。私の参画していたプロジェクトではありませんが、フェーズの切れ目で振り返りを行い、プロジェクトの終了後に総合的な振り返りを行うことで、本質を突いた意見や改善提案が多く挙がっていたように感じます。言いづらいことを言いやすくしてもらうために、匿名性で問題点・改善点を挙げてもらうといったプロジェクトもありました。とにかく後に続く貴重な情報を吸い上げられる仕組みを作ることが大切です。

振り返りの後は、整理した内容をノウハウとして一元管理する仕組みを作り、簡単に検索・閲覧出来る仕組みがあると良いですね。集めたナレッジを分析した結果、同じような問題にぶつかったプロジェクトが多ければ、プロジェクト参画者で集まって分科会を開き、改善策を深掘りするのも良いでしょう。



長々と書いてしまいましたが、今回はこの辺で。少しでも多くのプロジェクトが成功するよう、またメンバーが楽しくプロジェクトを進めることが出来るよう、自分自身も精進していけたらと思います。

アジャイル開発とIT投資について

藤原です。
今回は、「アジャイル開発」をテーマに、関連するトピックとIT投資の観点から見た価値について述べたいと思います。


アジャイル開発とは
ソフトウェア開発において従来より広く採用されていたウォーターフォール型開発は、求められる全て機能の実装を最終的なゴールとして、「要件定義」「設計」「実装」「テスト」の流れを順序通りに進めるアプローチ（計画重視）であるのに対し、
アジャイル開発は、小さな機能レベルで動作するソフトウェアをリリースし、各種要件や環境変化に応じて、イテレーション（反復）による開発を繰り返すことで機能を成熟させていくアプローチ（変化対応重視）の開発手法です。

アジャイル開発は、ソフトウェア開発自体を円滑に実施することに着目するのではなく、可能な限り早い期間で動作可能な機能を提供し、環境変化にも対応すべく、機能を変化・拡充していくことで、開発されたソフトウェアがもたらす価値を最大化する点に着目する点が特徴と言えます。


アジャイル開発の現状
先日、MPFU（Microsoft Project Users Forum）主催のセミナー『アジャイル開発の現状と「プラクティス・リファレンスガイド」』に参加した際、アジャイル開発を取り巻く現状を伺いました。
紹介されていた内容をかいつまんで要約すると

• 海外で多く普及されており、日本国内でも年々増加傾向にある
• アジャイル開発の適用に関して親和性の高い領域
• ビジネス要求が変化する領域
• リスクが高い領域（市場/技術リスク）
• 市場競争領域
• 逆にチャレンジや創意工夫が必要（困難）な領域
• 大規模開発
• 分散拠点開発
• 組織間をまたぐ開発チームによる開発
• 組み込みシステム開発
• アジャイル開発はW/F型開発に比べ、技術者の満足度（モチベーション）が高い
• ジャイル開発の様々な事例と具体的な実践方法のリファレンスをまとめた「リファレンスガイド」がIPA/SECから発行されている

アジャイル開発は、多くの企業で採用・実践され、確実に普及していると言えます。
近年、ビジネス環境の変化に伴いスピードが求められる中、その有効性についても、開発者と利用者の双方から認識されていると考えられます。
ただ、依然として、基幹システム等の大規模なソフトウェア開発においては、実践する上での工夫が必要である点や、ベンダーとの業務委託等の契約スキーム等、検討すべき課題はあるのが現状のようです。


アジャイル開発と要求分析（ビジネスアナリシス）
「要件が曖昧だと開発が進められない」
従来のウォーターフォール型開発では、こうした要求定義の重要性が問われるケースが多く聞かれますが、アジャイル開発の場合はどうでしょうか？

アジャイル開発においても、同様に要求分析は重要と言えます。
イテレーションを繰り返す中で、実装されていく機能が、ビジネス上の目標を達成するための要求と整合が取れているか、常に要求分析を行う必要があります。

以前、本ブログでも紹介した要求分析に関する知識体系であるBABOK（Business Analysis Body of Knowledge）においても、アジャイル開発におけるビジネスアナリシス活動のプラクティスをまとめた拡張版「Agile Extension to the BABOK」が2013年7月に公開されました。

BABOKのアジャイル拡張版には、各種アジャイル手法（XP、Scrum、Kanban）におけるビジネスアナリシスの役割や責任、実務上のテクニック等がまとめられています。
＃アジャイル拡張版の詳細は、また別の機会にご紹介したいと思います。

こうした動向からも、開発手法としてのアジャイル開発の普及、有効性に関する認識の高まりを感じることができます。


IT投資の観点から見たアジャイル開発の価値
IT投資の観点から、アジャイルによるソフトウェア開発は大きなメリットがあると言えます。私は、アジャイル開発の価値として、以下が挙げられると思っています。

• 短期間で動作するソフトウェア（機能）をリリースすることで、投資対効果を早期に実現できる
• イテレーションによって機能を変化・拡充することで、投資価値を最大化できる
• ビジネス環境の変化に対応すべく、機能実装を通じて投資をコントロールできる

SaaS、PaaS等のクラウドサービスが成熟していく中、ソフトウェア開発自体の在り方も変化している現状からすれば、ビジネスをとりまく環境変化に柔軟に対応でき、投資効果を早期に実現可能な手法が普及するのは当然と言えるかもしれません。
ただ、開発するソフトウェア（機能）の安定稼働の実現、戦略目標達成に向けた価値を十分に発揮するまでに、どれだけイテレーションを繰り返すか、投資をかけるべきなのかについては判断が必要な部分と言えます。

アジャイル開発においても、ソフトウェアのライフサイクルを意識したIT投資管理が重要だと思います。

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/

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

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

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

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