研究論文
† 北陸先端科学技術大学院大学
Japan Advanced Institute of Science and Technology
P2M 視点によるソフトウェア開発プロジェクトの引継ぎに関する研究
Study on Knowledge Transfer in Software Development Project Utilizing P2M
三宅 由美子 Yumiko MIYAKE
†内平 直志
Naoshi UCHIHIRA
† 受注型のプロジェクトで開発したソフトウェアは、顧客を通して運用担当に引継がれる。ソ フトウェアは、運用段階で顧客が利用して、初めて価値が創出する。開発プロジェクトは、ソ フトウェア開発の各段階で創造した価値を運用に引継ぐことを意識することが必要である。し かし、引継ぎのプロセスは、顧客との契約によって異なるため、具体的な手順として示すこと が難しい。 そのため、P2M 視点によるソフトウェア開発プロジェクトにおける「運用を意識した引継ぎ モデル」を作成した。本モデルは、プロジェクトライフサイクルを通して、開発プロジェクト が運用に引継ぐ形式知と暗黙知を意識するべきプロセスを明らかにし、価値あるソフトウェア 開発のために貢献する。 キーワード： 引継ぎ、暗黙知、形式知、ソフトウェア開発、価値創造Software developed in the external project is transferred to the operation team through the cus-tomer. Value of the software is found to use by customer in the operation phase. The software development project should keep in mind that the values created in the development phase are to be transferred to the operation team. One of issues associated with this is that since transfer process varies depending on a nature of the contract between the customer and contractor, it makes difficult to standardize the procedure.
This paper shows, as "a knowledge transfer model with an awareness of operations in software development projects," the solution utilizing the P2M. This model contributes to software development, by revealing the process of development projects to be aware of the explicit knowledge and tacit knowledge to transfer to the operation in the life cycle of a project
Keywords: Knowledge Transfer, Tacit Knowledge, Explicit Knowledge, Software Development, Value Creation
1. はじめに
日本のソフトウェア開発の特徴として、受託企業がプロジェクトを立ち上げ、顧客のソフ トウェア開発を担うことが挙げられる。このような受注型のプロジェクトは、成果物を含む 開発において獲得した知識を顧客と運用担当1に引継いでいる。この引継ぎ方法は、顧客と開 1 開発したソフトウェアの保守および運用するチームのこと発プロジェクト間の契約の違いなどにより複雑であるため、単純なステップ形式の手順とし て示すことが難しい。そのため、運用担当が引継ぎに対して求める知識を、人や組織 （People）、引継ぎにおける活動（Process）、ソフトウェア、ドキュメントなどの成果物 （Product）に分けて示し、顧客と開発プロジェクトが引継ぎで意識すべきことを明確にす る。 本研究では、IT サービスマネジメント（ITSM）の有資格者に対して、開発プロジェクトか ら運用担当に引継がれる成果物の実態に関するアンケート調査を実施した。さらに、itSMF Japan2において、積極的に活動をしている運用マネジャー8 名に対して、引継ぎの実態につい てインタビュー調査を実施した。これらの結果の分析に基づいた「運用を意識した引継ぎモ デル」を新しく提案する。
2. 受託企業から顧客への組織間の知識移転のための引継ぎ
ビジネスと情報システムが一体化する中で、顧客のビジネスに対する期待は、エンタープ ライズシステムなどの情報システムで実現することが求められる。ソフトウェアの価値は、 IT 戦略段階で策定され、設計・開発段階でソフトウェアに組み込まれる。 そのため、受注型のプロジェクトは、運用段階で価値が創出することを意識して活動し、 開発時に蓄積した成果物を含む知識を、顧客に移転する。顧客は、さらにその知識を運用担 当と共有し、価値を創出する。2.1. 受託企業におけるシステム全体の引き渡し
「P2M Version 2.0 コンセプト基本指針」[1]には、ソフトウェア開発のような特命業務活動 をオーナーが使命するプログラムマネジメントの概念が示されている。この中で、特命業務 活動をスキームモデル、システムモデル、サービスモデルに分割し、それぞれの相互関係を 一体化したプログラムマネジメントの概念を提供している。受注型のプロジェクトでは、超 上流工程であるスキームモデルの要件を受けて、顧客と協調して、システムモデルとしてソ フトウェア開発を実践し、サービスモデルである運用段階に引継ぎを行うことが多くある。 P2M プロジェクト&プログラムマネジメント標準ガイドブックには、「ソフトウェア開発の プロジェクト引き渡しへの流れ」[2]が示されている。この中で、システム全体の引き渡しは、 システムテストが完了した時点で行われるケースが示されている（図２－１）。 このように、受注型のプロジェクトは、獲得した知識を成果物として、顧客を介し、運用 担当に引き渡す。ランス[3]は、運用段階で上流の段階から得るべきインプットを例示してい る。2.2. 引継ぎの課題
開発段階から運用段階への引継ぎの課題について People、Product、Process に分けて示す。 図２－１ ソフトウェア開発のプロジェクト引き渡しへの流れ
2.2.1. People に関する課題
プロジェクトマネジメントは、従来、QCD（品質・コスト・時間）が重要だと言われてい たが、近年では、顧客のビジネスへの貢献や期待に応えることも、プロジェクトの成功に は、必要だと言われている[4]。開発プロジェクトは、顧客のビジネスへの貢献や期待に応える ために、顧客の要件を定義し、ソフトウェア開発を実践する。そして、顧客と開発プロジェ クトは、ビジネスに貢献する新しい価値を創造する。 設計・開発段階で顧客と開発者が価値を創造する中で、蓄積した知識は、運用担当者に知 識移転され、運用段階では、顧客と運用担当者がその知識を活かして価値を創出する。この ような段階をまたがる知識移転は、引継ぐべき知識が引継がれず、運用段階の価値創出に影 響するという欠点がある一方、バウンダリーから生じる新たな知識を統合していくことは、 持続的競争力を生み出す組織としての能力獲得につながる[5]と言われている。 瀬川・井川[6]は、組織間の知識移転に対して、業務を分析し、優れた視点で助言をするとい う形で知識移転を繰り繰り返し、相手の組織に気付きを与え、新たな知識を導くことで競争 優位を形成する暗黙知創造のモデルを提案している。ソフトウェア開発の引継ぎに関して も、顧客、開発プロジェクト、そして運用担当間の知識移転により、それぞれの組織が新た な知識を得ることで持続的な競争力を生み出すことが必要である。2.2.2. Product に関する課題
開発プロジェクトの成果物は、QCD のバランスを取りながら作成し、顧客に引き渡す。 廣瀬[7]は、プロジェクトの外部委託先に対して、「教育」と「品質記録に関連する検査」に よって正確な品質記録を残し、品質分析・評価の精度を高めることで成果物を改善すること は、運用段階の品質に顕著な効果があることを述べている。このように、顧客と開発プロジェクトは、運用段階で価値を創出するために、運用担当に引継ぐ成果物として必要とされる 品質を確保し、運用するために必要な知識を移転することが必要である。
2.2.3. Process に関する課題
開発プロジェクトは、成果物を顧客に引き渡す。さらにその成果物は、顧客を介して運用 担当に引継がれる。引継ぎは、成果物の引き渡しだけではなく、開発時に蓄積した知識を含 んで、顧客に移転することが有効である。そして、顧客は、成果物と知識を運用担当と共有 する。 しかし、現実的には、開発プロジェクトから運用担当に、直接、引継ぎを行うことがあ る。そして、開発者は運用担当と会話をすることにより、開発時に蓄積した暗黙知を引継ぐ ことができる。 このような引継ぎは、プロジェクトの環境や状況、運用パターンによって有無や頻度が異 なる。運用担当は、「顧客内の運用担当」、「受託企業の運用担当」の場合がある。さらに、 「受託企業の運用担当」は開発と同じ企業の場合と異なる企業の場合がある。（図２－２）。 図２－２ 運用パターン別の引継ぎの流れの例 開発プロジェクトの知識を運用担当に引継ぐ場合、プロジェクトの環境や状況、運用パタ ーンなどによって、引継ぐ手順が異なるため、抽象度の高いモデルとして示すことが有効で ある。 本研究では、顧客と開発プロジェクトが、成果物の「引き渡し」だけではなく、ソフトウ ェア開発のプロジェクトライフサイクル（PLC）全体の中で、成果物による形式知と、人によ る暗黙知の引継ぎを意識するべきプロセスを明らかにし、全ての運用パターンに対応した 「運用を意識した引継ぎモデル」を提案する。3. 引継ぐ成果物に関するアンケート調査
引継ぎの現状調査を行うために、ソフトウェア開発の成果物の引継ぎに関するアンケート 調査を行った。アンケート項目は、参考文献[3]に運用へのインプットとして例示されている文 書を参考にして作成（図３－１）した。アンケートは、2015 年 3 月～2015 年 7 月の間に実施 し、ITSM 関係の有資格者 96 名に対して、もっともよく対応している引き渡しの状況につい て回答を求めた。回収したアンケートの中で、「引継ぎの経験なし」と回答したものと、回答 に不備があるアンケートを集計対象から除外し、68 件に対して、集計・分析を行った。 図３－１ 引継ぎに関するアンケート用紙3.1. アンケート結果
「アンケート回答者の背景」と「開発から運用へ引継ぐ成果物」についてアンケート結果 を示す。 (1) アンケート回答者の背景 アンケート回答者は、構築や運用など下流工程の経験者が多いが、「価値ある IT サービス のために重要だと思う段階」は戦略や設計（開発）など上流工程だと 74%が回答している （図３－２）。図３－２ アンケート回答者の背景 (2) 開発から運用へ引継ぐ成果物 アンケート結果を、開発が活用した成果物、運用が活用する成果物、サービスに関わる成 果物および IT 戦略策定時に作成する成果物に分類した（図３－３）。さらに分類ごとに「成 果物を作成し、説明後に提出する」と「成果物を作成し、引継いでいる」を選択した回答の 平均値を示した。 図３－３ 開発から運用が引継いでいる成果物の順位
3.2. アンケート結果の考察
図３－３では、「開発が活用した成果物」、「運用が活用する成果物」、「サービスに関わる成 果物」、「IT 戦略策定時に作成する成果物」の順で、開発から運用に成果物が引継がれている ことを示している。アンケート調査対象の成果物を開発プロジェクトが作成をしていない件 数についても、引継がれない件数に含まれるが、開発プロジェクトから運用担当に引継いで いる成果物の順位は変わらない。本順位は、図３－２で 43%が価値ある IT サービスのために重要な段階だと回答した戦略段 階に関わる「IT 戦略策定時に作成する成果物」や運用段階における価値創出のために必要と 考えられる「サービスに関わる成果物」が下位になっているため、運用担当が求める成果物 の順位と本順位が同位であるとは考え難い。そのため、成果物のような形式知だけではな く、開発者から運用担当者へ引継ぐ暗黙知も含めて明らかにすることが必要である。 アンケートでは、「その他」に分類している「開発時に蓄積した知識と情報」が暗黙知に関 する質問であるが、79%が引継いでいないという回答であった。そのため、具体的に暗黙知に ついて調査するために、インタビュー調査を実施し、開発プロジェクトから運用担当への引 継ぎの実態を明らかにする。
4. 引継ぎに関するインタビュー調査
運用マネジャーに対して、引継ぎに関するインタビュー調査を実施した。4.1. インタビュー調査方法
(1) インタビュー項目 インタビュー項目は、People に関する質問として 3 問、Product に関する質問として 6 問、 Process に関する質問として 2 問の計 11 問を作成した（表４－１）。 表４－１ インタビュー項目 分類 インタビュー項目 People 会話によって引継ぐ知識や情報がありますか？ 開発メンバーが運用に残ることがありますか？その場合、開発側のメンバーそれとも運 用側で開発の支援に入ったメンバーのどちらが残りますか？また、運用段階でどのよう な役割を担当しますか？ 開発メンバーが運用から引き上げるのはどのようなタイミングですか？ Product 開発からどのような成果物を引継ぎますか？ どのような成果物を活用していますか？ どのような成果物が不要ですか？ 運用段階で作成した方が望ましい文書がありますか？ 顧客と価値共創をするためにどのような成果物が必要ですか？その成果物は開発から引 継いでいますか？ SLA を作成するのはどのようなシステムで、いつ・誰が・どのように作成しますか？ Process 顧客と価値共創をするために開発からの引継ぎは、重要な要件ですか？引継ぎが失敗し たことにより、運用段階で価値が創出できなかったことはありますか？ 運用段階で開発メンバーが支援できる場合とできない場合では引継ぎが異なりますか？ (2) インタビュー対象者とインタビュー時間 インタビューの対象者は、itSMF Japan で活動している運用マネジャー8 名とした（表４－ ２）。 対象者は、図２－２の全ての運用パターンを網羅するように選定し、全ての運用パターンの 要件を抽出する。インタビューは、テキスト化し、分析した。表４－２ インタビュー対象者の背景とインタビュー時間
氏名 itSMF Japan 勤務先 ITSM 資格 主な
運用パターン インタビュー 時間 A 氏 座長経験者 中小企業 上位 Ａ 25 分 59 秒 B 氏 副座長経験者 大企業 基礎 Ｂ 16 分 33 秒 C 氏 座長経験者 中小企業 上位 Ｃ 21 分 12 秒 D 氏 座長経験者 大企業 上位 Ｂ 17 分 03 秒 E 氏 メンバー経験者 大企業 基礎 Ａ 12 分 22 秒 F 氏 座長経験者 大企業 上位 Ｂ 15 分 22 秒 G 氏 副座長経験者 大企業 基礎 Ａ 29 分 29 秒 H 氏 座長経験者 大企業 上位 Ｃ 25 分 52 秒
4.2. インタビュー分析
インタビュー結果は、KH Coder[8]と SCAT[9]の 2 種類のツールを使用して分析した。 KH Coder とは、テキスト型データを統計的に分析するためのツールである。社会調査デー タを分析するための「計量テキスト分析」または「テキストマイニング」に対応している。 本研究では、KH Coder を使用して、共起ネットワーク（サブクラス検出）（図４－１）を作 成し、インタビューの要素の関係を分析する。 図４－１ 共起ネットワーク（サブクラス検出） <1> <3> <4> <5> <6> <2> <7> <8> <9> <10>さらに、SCAT[9]を使用して、今回のインタビュー結果の質的データ分析を行い、テキスト 化したインタビュー・データの 530 センテンスに対して、305 の理論記述を作成した。
4.2.1. 共起ネットワーク（サブクラス検出）
図４－１は、インタビューで出現数 15 以上の語の結びつきを示している。比較的強い結び つきの語は、10 サブクラスに分かれる。 共起ネットワークは、インタビューでどのような語を中心に会話が進んだか概要を示すこ とができる。この共起ネットワークの結果を基に、SCAT[9]を利用して、インタビュー結果の 質的データ分析を行う。4.2.2. 質的データ分析
SCAT[9]で質的データ分析をした 305 の理論記述をソフトウェア開発の段階ごとに暗黙知が関わる People、形式知が関わる Product とソフトウェア開発の各段階の活動を Process として 分類した（表４－３）。さらに分類した理論記述の中で同意の項目を選定して、「運用を意識 した引継ぎ」を行うために 59 個の「意識すべきこと」として項目の内容を要約した。 表４－３ SCAT 分析結果例（10／305 センテンス抜粋） 段階 分類 意識すべきこと 理論記述 企画 Product 企画書や RFP3 には顧客の思い （価値）を記載 する 成果物の元になる企画書は開発の受託企業は入手して いないので、最終的な成果物にもあまり入ってこない 情報システムは顧客の思いがあって開発されている 価値を創出するには RFP、企画書などを引継ぐことが必 要である ソフトウェアは、RFP が要件の元であり、必要なドキュ メントである Process 求める価値を仕 様にまとめる 価値共創する役 割（顧客・開発 者・運用担当 者）を決める 仕様に関しては、要件定義の前の段階で仕様を確認して いる 求める価値は欠落している（課題） アウトソーサーの役割は、プロジェクトの立上げ時、顧 客と価値共創するための役割分担を決める 運用時の役割は開発が決めるが情報システムの価値を 創出する活動をするのは運用である役割がぶれないよ うに情報システム全体のライフサイクルの役割は開発 が決める 役割分担を行い、開発者、構築担当者、運用担当者が分 かれている場合もある 開発と運用の役割を明確に分けている
5. 運用を意識した引継ぎモデル
共起ネットワーク（サブクラス検出）（図４－１）と SCAT 分析結果（表４－３）に基づい て、運用を意識した引継ぎプロセスモデル（図５－１）と運用を意識した引継ぎ概念モデル （図５－２）を作成した。 図５－１ 運用を意識した引継ぎプロセスモデル5.1. 運用を意識した引継ぎプロセスモデル
運用を意識した引継ぎプロセスモデル（図５－１）は、ソフトウェア開発に関わる顧客、 開発者、運用担当者などの全てのステークホルダーが PLC の各段階で「意識すべきこと」 を、People、Process、Product で分類して示している。この「意識すべきこと」は、SCAT 分析 結果（表４－３）の 305 の理論記述を要約した 59 個をプロットしている。本モデルは、顧客のソフトウェア開発に対する「思い」を把握し、PLC を進めていく中 で、顧客と開発プロジェクトが創造した価値を運用段階で創出するまでを範囲としている。 モデルの構成は、共起ネットワーク（サブクラス検出）（図４－１）を考慮して作成した（表 ５－１）。 表５－１ 共起ネットワークの語とモデルの構成の関係 No. 語 モデルの構成 1 設計、開発、 運用、段階、 システム、作 る、人、言う 「システム」を「作る」ための「設計」、「開発」および「運用」の「段階」 をモデルの対象範囲に含める。「人」－「言う」という暗黙知の引継ぎを People に分類して、モデルの左側に示した。顧客、開発者および運用担当者 は、実線が主な活動期間、点線は契約等により活動する期間を示している。 意識する対象は■で示した 2 思う、見る、 実際 ソフトウェア開発に対して「思う」点があれば、成果物を「実際」-「見 る」。成果物は Product に分類して、モデルの右側に示した 3 ユーザー、部分 「ユーザー」がソフトウェアを使う「部分」である運用段階をモデルに含め た 4 作業、手順、 比較 「作業」「手順」を実施する際に成果物と「比較」しながら進める運用段階を モデルに含めた 5 構築、試験 システムテスト（「構築」「試験」）の段階をモデルに含めた 6 要件、定義 「要件」「定義」の段階をモデルに含めた
7 SLA、契約 「SLA」と「契約」を Product に含めた
8 テスト、確認 「テスト」で運用を「確認」する運用テストをモデルに含めた 9 お客、価値 Process で「意識すべきこと」は、企画段階から運用段階までの全段階で、顧 客と開発者と運用担当者が価値共創することを前提とした 10 メンバー、残る 開発の「メンバー」が運用段階に「残る」ことを People に含めた
5.2. 運用を意識した引継ぎ概念モデル
開発プロジェクトから運用担当へ引継ぐ知識には、形式知である成果物だけではなく、開 発者の暗黙知がある。SCAT データ分析（表４－３）の理論記述を分析し、運用パターンごと の形式知と暗黙知の活用について表５－２に示した。 この結果、形式知である成果物は、運用パターンＡが、最も活用し、顧客企業の運用担当 は、活用する成果物を開発段階で整備していると考えられる。運用パターンＢは、成果物を 活用しているが、運用開始時に開発プロジェクトが作成した成果物を改訂したり、作成した りしている。運用パターンＣは、成果物をあまり活用せず、運用段階で作成したり、改訂し たりしている。暗黙知に関わる人に関しては、どのパターンも運用担当が開発プロジェクト に参加したり、開発者が運用段階で運用担当を支援したり、暗黙知の引継ぎが可能な状況で あった。表５－２ インタビュー回答者別引継ぎ状況 No. 運用パターン 運用 パターンＡ 運用 パターンＢ 運用 パターンＣ インタビュー回答者 Ａ氏 Ｅ氏 Ｇ氏 Ｂ氏 Ｄ氏 Ｆ氏 Ｃ氏 Ｈ氏 1. 運用段階で成果物を活用している ○ ◎ ◎ ○ ○ △ △ △ 2. 運用開始時に成果物を作成（改訂）する △ △ △ ◎ ○ ◎ △ ○ 3. 運用担当が開発プロジェクトに参加している ○ ◎ ◎ ◎ ◎ ◎ ◎ ◎ 4. 開発担当者が運用を支援する ◎ ◎ △ ◎ ◎ △ ◎ ◎ [No1 ◎：すべて活用、○：一部を除いて活用、△：あまり活用していない、×：活用していない] [No2～No4 ◎：ある、○：時々ある、△：ほとんどない、×：ない] 表５－３には、質的データ分析の理論記述の中から、暗黙知に関する記述を例示した。ソ フトウェア開発をする上で、開発者が得たすべての知識を成果物に記載できるわけではな い。運用担当者は、成果物を理解するときに「成果物に書かれていないこと」、「成果物の理 解ができないこと」について、開発者に確認し、開発者の暗黙知から、新たな知識を得るこ とが必要である。 表５－３ 暗黙知に関する理論記述例 主な段階 回答者 理論記述 要件定義 Ｅ氏 プロジェクト・マネジャーとステークホルダーのやり取りなど、例えば、メー ルなどで情報を入手し、顧客とプロジェクト・マネジャーの会話を把握する 要件定義 Ｅ氏 要求の出た経緯について、開発や顧客、ユーザーなどに会話で確認する 設計 Ａ氏 イレギュラーケースなどすべて、成果物に書ききれていないため、開発時の知 識は人に残り、属人化することがある 引き渡し Ｆ氏 引き渡し時の会話は議事録にまとめるが必ずしも運用のナレッジとして活用さ れていない 引き渡し Ｇ氏 運用担当者は、対面レビューで開発と会話をすることにより、システムを理解 し、知識を向上させ、運用テストは、実践力を向上させる 運用テスト Ｈ氏 運用テストを通して、開発と運用がともに作業することによって、技術、特性 などの知識を移転する 運用テスト Ｈ氏 プロジェクトの日常のコミュニケーションで様々な気づきがあり、開発から運 用への知識を移転している 運用段階 Ｂ氏 運用担当者は、開発者の証跡から手順書を作成するが、開発者は、記述してい る内容の証跡を丁寧に残していないことがある 運用段階 Ｃ氏 運用担当者はプロジェクトの途中から参加するため、開発のナレッジが十分理 解できずに運用で活用できていない 運用を意識した引継ぎ概念モデルは、開発から運用に引継ぎを行う中で、顧客や開発者が 意識すべき知識移転の流れについて示している（図５－２）。本モデルは、顧客や開発者向け て、運用段階で、顧客がソフトウェアを利用して価値を創出する支援をする運用担当者に対 して、企画段階から運用段階の適切な段階で暗黙知を含めた引継ぎを行う必要性を示してい る。
図５－２ 運用を意識した引継ぎ概念モデル
6. まとめ
本論文では「運用を意識した引継ぎモデル」として、プロセスモデル（図５－１）と概念 モデル（図５－２）を提案した。本モデルは、開発プロジェクトから運用担当への引継ぎで 意識することだけではなく、ソフトウェア開発における「引継ぎ」の課題の解決を踏まえた 留意点を示している。 People に関する課題に対しては、ソフトウェア開発の引継ぎにおいて、顧客、開発プロジ ェクト、運用担当が他の組織と共創し、組織として新たな知識を得ることが必要であること を示している。この知識は、それぞれの組織の中の知識と統合されて、ソフトウェア開発に おける持続的な競争力を生み出すことに貢献する。 Product に関する課題に対しては、運用を意識し、成果物の「品質」だけではなく、「整合 性・量・レベル」に配慮し、運用するために必要な成果物を引継ぐことが必要であることを 示している。顧客の思いを記載している要件定義書や顧客の求めるサービスレベルに関わる SLA、サービスレベル目標（SLO）などを含む、運用で必要とされる形式知である成果物を品 質、成果物間の整合性、量、記述レベルを考慮して引継ぐことが、運用段階で、顧客と運用 担当が価値を創出するために有効である。 Process に関する課題に対しては、運用パターンに関わらず、ソフトウェア開発の PLC にお ける成果物による形式知と、ヒトによる暗黙知を意識するべきプロセスがあることを示し た。顧客、開発者、運用担当者が、モデルの Process に示した段階で意識すべき点を考慮して 積極的にコミュニケーションを図ることが、運用段階で価値を創出するソフトウェア開発に 貢献するために有効である。 「運用を意識した引継ぎ概念モデル」（図５－２）は、顧客、開発者に対して、運用を意識 して引継ぎを行うために、運用担当に「形式知」である成果物を引き渡すだけではなく、開 発者の「暗黙知」を含めて運用担当に引継ぐことが、運用段階で価値を創出するために必要 であることをモデルとして強調している。 本研究は、受注型のプロジェクトにおいて、顧客との契約や複数の運用パターンがあるために、開発から運用への引継ぎの手順を具体的に示せない中で、運用段階で価値を創出する ため、形式知としての成果物の引き渡しだけではなく、暗黙知としての人による引継ぎが必 要な段階を具体的に抽出した点に新規性がある。 本研究では、与えられた QCD を確実に達成し、サービスモデルとして運用段階で価値の獲 得と評価を行う顧客を支援する運用担当が求める知識について明らかにした。今後は、サー ビスモデルの上位であるスキームモデルとしての超上流工程とシステムモデルとしての設 計・構築段階の引継ぎの実態について明らかにし、顧客のプログラムに基づいたソフトウェ ア開発における引継ぎについて、さらに研究を進めていく。
参考文献
[1]国際 P2M 学会「P2M Version 2.0 コンセプト基本指針」、国際 P2M 学会、pp.5-6、2009 [2]小原重信「P2M プロジェクト&プログラムマネジメント標準ガイドブック 下巻 個別マ ネジメント編」、PHP 研究所、pp.159、2003 [3]スチュアート・ランス「ITIL サービストランジション」、TSO 出版、pp.292、2013[4] Bygstad,B. and Lanestedt.G” ICT based service innovation - A challenge for project management,” International Journal of Project Management, Vol.27, Issue 3, pp 234–242, 2009
[5]児玉充「バウンダリーチーム・イノベーション」、翔泳社、2010
[6]瀬川良久・井川康夫「思考スキルの組織的間移転を通じた暗黙知創造のモデル－電子機器 受託生産企業の事例研究」、日本 MOT 学会誌、No.2、pp.9-18、日本 MOT 学会、2014 [7]廣瀬守克「品質記録の記述レベルと成果物品質に関する実証的考察－SI プロジェクトにお
ける成果物品質向上に関する実践事例」、日本 MOT 学会誌、No.3、pp.1-10、日本 MOT 学 会、2015
[8]樋口耕一「テキスト型データの計量的分析 －2 つのアプローチの峻別と統合－」、理論と 方法 、19(1)、pp101-115、数理社会学会、2004
[9]大谷尚「SCAT: Steps for Coding and Theorization －明示的手続きで着手しやすく小規模デー タに適用可能な質的データ分析手法－」、感性工学、10-3、pp155-160、日本感性工学会、 2011
査読 2016 年 7 月 11 日 受理 2016 年 10 月 14 日
