† 北陸先端科学技術大学院大学
P2M 視点によるソフトウェア開発プロジェクトの引継ぎに関する研究
Study on Knowledge Transfer in Software Development Project Utilizing
P2M
三宅 由美子
Yumiko Miyake
†内平 直志
Naoshi Uchihira
† 受注型プロジェクトで開発したソフトウェアは、顧客を通して運用側に引継がれる。ソフトウ ェアは、運用段階で顧客が利用して、初めて価値が創出する。開発プロジェクトは、ソフトウェ ア開発の各段階で創造した価値を運用に引継ぐことを意識することが必要である。しかし、引継 ぎのプロセスは、顧客との契約によって異なるため、具体的な手順として示すことが難しい。 そのため、P2M 視点によるソフトウェア開発プロジェクトにおける「運用を意識した引継ぎ モデル」を作成した。本モデルは、プロジェクトライフサイクルを通して、開発プロジェクトが 運用に引継ぐ形式知と暗黙知を意識するべきプロセスを明らかにし、価値あるソフトウェア開発 のために貢献する。 キーワード：引継ぎ、暗黙知、形式知、ソフトウェア開発、価値創造Software developed in the external project is transferred the operation side through the customer. Value of the software is found to use customers in the operational phase. To be aware that transfer the value is created at each stage of software development is important in the project. However, the transfer process is different depending on the contract with a customer and, is difficult to standardize.
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. はじめに
日本のソフトウェア開発の特徴として、受注型プロジェクトとして、開発の受託企業が顧客 のソフトウェア開発を担うことが挙げられる。このような開発プロジェクトで開発したソフト ウェアは、顧客を通して運用担当に引継がれる。開発したソフトウェアの価値は、運用段階で ユーザーが使用して、初めて創出するため、開発プロジェクトは、プロジェクトライフサイク ル（PLC）の各段階で創造した価値を運用段階で創出させることを意識して、引継ぎを行うこ とが必要である。しかし、引継ぎ方法は、顧客と開発プロジェクト間の契約によって異なるた め、具体的な手順として示すことが難しい。P2M は、「ソフトウェア開発のプロジェクト引き渡しへの流れ」[1] を示している。この中で、 システム全体の引き渡しは、システムテストが完了した時点で行われることが示されている。 この時点で、開発プロジェクトは、形式知として成果物を運用担当に引き渡す。しかし、開発 プロジェクトでは、形式知だけではなく、開発者の中に暗黙知を蓄積する。この暗黙知を含め て、PLC を通して、開発プロジェクトが蓄積した知識を運用担当に引継ぐことが、運用段階で 価値を創出するために有効である。 本研究では、引継ぎに関するアンケート調査とインタビュー調査の結果を分析し、「運用を 意識した引継ぎモデル」を新しく提案する。アンケート調査では、IT サービスマネジメント （ITMS）の有資格者に対して、開発プロジェクトから運用担当に形式知として引継ぐ成果物 の実態について、調査・分析を行っている。さらに、インタビュー調査では、itSMF Japan1に おいて、積極的に活動をしている運用マネジャーの 8 名に対して、引継ぎの実態に関する調査・ 分析を行った。 本モデルにより、PLC を通して、開発プロジェクトから運用担当に引継ぐ形式知と暗黙知を 意識するべきプロセスを明らかにし、価値あるソフトウェア開発のために貢献する。
2. 受注型プロジェクトの引継ぎ
ビジネスと情報システムが整合する中で、顧客のビジネスに対する期待を情報システムで実 現することが求められる。開発プロジェクトは、顧客と開発者が情報システムにおける価値を 創造する。その中で、ソフトウェアの価値は、IT 戦略段階で策定され、設計・開発段階でソフ トウェアに組み込まれる。 大規模の開発プロジェクトは、事前に成果物の効果や内容を十分に明確にすることができな いため、顧客満足は成果物から得られる効果あるいは価値に基づくことになる [2]。 そのため、 開発プロジェクトは、運用段階で価値が創出することを意識して活動し、開発時に蓄積した成 果物を含む知識を、ソフトウェアを使用する顧客に移転することが求められる。顧客は、さら にその知識を運用担当と共有し、運用段階で顧客が求める価値を創出させる。2.1. 受注型プロジェクトの引き渡し
P2M は、システム開発 PLC の運用への引き渡しのフェーズ[3]と「ソフトウェア開発のプロジ ェクト引き渡しへの流れ」[1] を示している。この中で、システム全体の引き渡しは、基本的に システムテストが完了した時点で行われることになっている（図２－１）。 この時点で、開発プロジェクトが獲得した知識は，形式知の形で成果物として、顧客を介し、 運用担当に引き渡している。ランス[4]は、運用段階で上流の段階から得るべきインプットを例 示している。図２－１ ソフトウェア開発のプロジェクト引き渡しへの流れ
2.2. 引継ぎの課題
開発プロジェクトの People・Product・Process に関する引継ぎの課題を示す。2.2.1. People に関する課題
プロジェクトマネジメントは、従来、QCD（品質・コスト・時間）が重要だと言われていた が、近年では、顧客のビジネスへの貢献や期待に応えることも、プロジェクトの成功には、必 要だと言われている[6]。開発プロジェクトは、顧客のビジネスへの貢献や期待に応えるために、 顧客の要件を定義し、ソフトウェア開発を実践する。そして、顧客と開発プロジェクトは、ビ ジネスに貢献する新しい価値を創造する。 設計・開発段階で顧客と開発者が価値を創造する中で、蓄積した知識は、運用担当者に知識 移転され、運用段階では、顧客と運用担当者がその知識を活かして価値を創出する。このよう な段階をまたがる知識移転は、引継ぐべき知識が引継がれず、運用段階の価値創出に影響する という欠点がある一方、バウンダリーから生じる新たな知識を統合していくことは、持続的競 争力を生み出す組織としての能力獲得につながる[7]と言われている。 さらに、瀬川[8]は、組織間の知識移転に対して、業務を分析し、優れた視点で助言をすると いう形で知識移転を繰り繰り返し、相手の組織に気付きを与え、新たな知識を導くことで競争 優位を形成する暗黙知創造のモデルを提案している。ソフトウェア開発の引継ぎに関しても、 開発プロジェクトから運用担当に知識移転するだけではなく、それぞれの組織が新たな知識を 得ることで持続的な競争力を生み出すことが必要である。2.2.2. Product に関する課題
開発プロジェクトの成果物は、QCD のバランスを取りながら作成し、顧客に引き渡す。 廣瀬[5]は、プロジェクトに外部委託先に対して、「教育」と「品質記録に関連する検査」に よって正確な品質記録を残し、品質分析・評価の精度を高めることで成果物を改善し、運用段 階の品質に顕著な効果があることを述べている。そのため、開発プロジェクトは、運用段階で 価値を創出するためにあ、運用担当に引継ぐ成果物として必要とされる品質を確保し、運用す るために必要な知識を移転することが必要である。2.2.3. Process に関する課題
開発プロジェクトは、開発時の成果物を顧客に引き渡す。さらにその成果物は、顧客を介し て運用担当に引継がれる。引継ぎは、成果物の引き渡しだけではなく、開発時に蓄積した知識 を含んで、顧客に移転することが有効である。顧客は、成果物と開発時に蓄積した知識を運用 担当と共有する。 しかし、開発プロジェクトの実態として、開発プロジェクトから運用担当に、直接、引継ぎ を行うことがある。特に、開発者は運用担当と会話をすることにより、開発時に蓄積した暗黙 知を引継ぐことができる。 このような引継ぎは、プロジェクトの環境や状況、運用パターンによって有無や頻度が異な る。運用担当は、「顧客内の運用担当」、「受注企業の運用担当」の場合がある。さらに、「受託 企業の運用担当」は開発と同じ企業の場合と異なる企業の場合がある。（図２－２）。 図２－２ 運用パターン別の引継ぎの流れの例 開発プロジェクトの知識を運用担当に引継ぐ場合、プロジェクトの環境や状況、運用パター ンなどによって、引継ぐプロセスが異なり、「引継ぎ」を具体的な手順として示すことは困難であるため、抽象度の高いモデルとして示すことが有効である。 本研究では、顧客と開発プロジェクトが、成果物の「引き渡し」だけではなく、ソフトウェ ア開発のPLC 全体の中で、成果物による形式知と、人による暗黙知の引継ぎを意識するべき プロセスを明らかにし、全ての運用パターンに対応した「運用を意識した引継ぎモデル」を提 示する。
3. 引継ぐ成果物に関するアンケート調査
引継ぎの現状調査を行うために、ソフトウェア開発の成果物の引継ぎに関するアンケート調 査を行った。アンケート項目は、参考文献[4]に運用へのインプットとして例示されている文書 を参考にして作成（図３－１）した。アンケートは、2015 年 3 月 6 日 ～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[9]と SCAT[10]の 2 種類のツールを使用して分析した。 KH Coder とは、テキスト型データを統計的に分析するためのツールである。社会調査デー タを分析するための「計量テキスト分析」または「テキストマイニング」に対応している。本 研究では、KH Coder を使用して、共起ネットワーク（サブクラス検出）（図４－１）を作成し、 インタビューの要素の関係を分析する。 図４－１ 共起ネットワーク（サブクラス検出） <1> <3> <4> <5> <6> <2> <7> <8> <9> <10>さらに、SCAT[10]を使用して、今回のインタビュー結果の質的データ分析を行い、テキスト 化したインタビュー・データの 530 センテンスに対して、305 の理論記述を作成した。
4.2.1. 共起ネットワーク（サブクラス検出）
図４－１は、インタビューで出現数 15 以上の語の結びつきを示している。比較的強い結び つきの語は、10 サブクラスに分かれる。 共起ネットワークは、インタビューでどのような語を中心に会話が進んだか概要を示すこと ができる。この共起ネットワークの結果を基に、SCAT[10]を利用して、インタビュー結果の質 的データ分析を行う。4.2.2. 質的データ分析
SCAT[10]で質的データ分析をした 305 の理論記述をソフトウェア開発の段階ごとに暗黙知が 関わる People、形式知が関わる Product とソフトウェア開発の各段階の活動を Process として分 類した。さらに分類した理論記述の中で同意の項目を選定して、「運用を意識した引継ぎ」を 行うために「意識すべきこと」として項目の内容を要約した。 表４－３ SCAT 分析結果（10／305 センテンス抜粋） 段階 分類 意識すべきこと 理論記述 企画 Product 企画書や RFP に は顧客の思い （価値）を記載 する 成果物の元になる企画書は開発の受託企業は入手していないので、最 終的な成果物にもあまり入ってこない 情報システムは顧客の思いがあって開発されている 価値を創出するには RFP、企画書などを引継ぐことが必要である ソフトウェアは、RFP が要件の元であり、必要なドキュメントである People 求める価値を仕 様にまとめる 価値共創する役 割（顧客・開発 者・運用担当者） を決める 仕様に関しては、要件定義の前の段階で仕様を確認している 求める価値は欠落している（課題） アウトソーサーの役割は、プロジェクトの立上げ時、顧客と価値共創 するための役割分担を決める 運用時の役割は開発が決めるが情報システムの価値を創出する活動 をするのは運用である役割がぶれないように情報システム全体のラ イフサイクルの役割は開発が決める 役割分担を行い、開発者、構築担当者、運用担当者が分かれている場 合もある 開発と運用の役割を明確に分けている5. 運用を意識した引継ぎモデル
共起ネットワーク（サブクラス検出）（図４－１）と SCAT 分析結果（表４－３）を考慮し た運用を意識した引継ぎプロセスモデル（図５－１）と運用を意識した引継ぎ概念モデル（図 ５－２）を作成した。図５－１ 運用を意識した引継ぎプロセスモデル
5.1. 運用を意識した引継ぎプロセスモデル
運用を意識した引継ぎプロセスモデル（図５－１）は、ソフトウェア開発に関わる顧客、開 発者、運用担当者などの全てのステークホルダーが PLC の各段階で「意識すべきこと」を、 People、Process、Product で分類して示している。この意識すべきことは、SCAT 分析結果（図 ４－３）の 305 の理論記述を要約した 58 個の「意識すべきこと」をプロットしている。 本モデルは、顧客のソフトウェア開発に対する「思い」を把握し、PLC を進めていく中で、 顧客と創造した価値を運用段階で創出するまでを範囲としている。モデルの構成は、共起ネッ トワーク（サブクラス検出）（図４－１）を考慮して作成した（表５－１）。表５－１ 共起ネットワークの語とモデルの構成の関係 No. 語 モデルの構成 1 設計、開発、運用、段階、 システム、作る、人、言 う 「人」－「言う」という暗黙知の引継ぎを People に分類して、モデ ルの左側に示している。顧客、開発者および運用担当者は、実線が主 な活動期間、点線は契約等により活動する期間を示している。意識す る対象は■で示している 2 思う、見る、実際 ソフトウェア開発に対して「思う」点があれば、成果物を「実際」-「見る」。成果物は Product に分類して、モデルの右側に示す 3 ユーザー、部分 「ユーザー」がソフトウェアを使う「部分」である運用段階をモデル に含めた 4 作業、手順、比較 「作業」「手順」を実施する際に成果物と「比較」しながら進める運 用段階をモデルに含めた 5 構築、試験 システムテスト（「構築」「試験」）の段階をモデルに含めた 6 要件、定義 「要件」「定義」の段階をモデルに含めた
7 SLA、契約 「SLA」と「契約」を Product に含めた
8 テスト、確認 「テスト」で運用を「確認」する運用テストをモデルに含めた 9 お客、価値 Process で「意識すべきこと」は、企画段階から運用段階までの全段 階で、顧客と開発者と運用担当者が価値共創することを前提とする 10 メンバー、残る 開発の「メンバー」が運用段階に「残る」ことを含める
5.2. 運用を意識した引継ぎ概念モデル
開発プロジェクトから運用担当へ引継ぐ知識には、形式知である成果物だけではなく、開発 者の暗黙知がある。SCAT データ分析（表４－３）の理論記述を分析し、運用パターンごとの形 式知と暗黙知活用について表５－２に示した。 この結果、形式知である成果物は、運用パターンＡが、最も活用しており、顧客企業の運用 担当は、活用する成果物を開発段階で整備していると考えられる。運用パターンＢは、成果物 を活用しているが、運用開始時に開発プロジェクトが作成した成果物を改訂したり、作成した りしている。運用パターンＣは、成果物をあまり活用せず、運用段階で作成したり、改訂した りしている。暗黙知に関わる人に関しては、どのパターンも運用担当者が開発プロジェクトに 参加したり、開発者が運用段階で運用担当を支援したり、暗黙知の引継ぎが可能な状況であっ た。 表５－２ インタビュー回答者別引継ぎ状況 No. 運用パターン 運用 パターンＡ 運用 パターンＢ 運用 パターンＣ インタビュー回答者 Ａ氏 Ｅ氏 Ｇ氏 Ｂ氏 Ｄ氏 Ｆ氏 Ｃ氏 Ｈ氏 1. 運用段階で成果物を活用している ○ ◎ ◎ ○ ○ △ △ △ 2. 運用開始時に成果物を作成（改訂）する △ △ △ ◎ ○ ◎ △ ○ 3. 運用担当が開発プロジェクトに参加している ○ ◎ ◎ ◎ ◎ ◎ ◎ ◎ 4. 開発担当者が運用を支援する ◎ ◎ △ ◎ ◎ △ ◎ ◎ [No1 ◎：すべて活用、○：一部を除いて活用、△：あまり活用していない、×：活用していない] [No2～No4 ◎：ある、○：時々ある、△：ほとんどない、×：ない]表５－３には、質的データ分析の理論記述の中から、暗黙知に関する記述を例示した。ソフ トウェア開発をする上で、開発者が得たすべての知識を成果物に記載できるわけではない。運 用担当者は、成果物を理解するときに「成果物に書かれていないこと」、「成果物の理解ができ ないこと」について、開発者に確認し、開発者の暗黙知から、新たな知識を得ることが必要で ある。 表５－３ 暗黙知に関する理論記述例 主な段階 回答者 理論記述 要件定義 Ｅ氏 プロジェクト・マネジャーとステークホルダーのやり取りなど、例えば、メー ルなどで情報を入手し、顧客とプロジェクト・マネジャーの会話を把握する。 要件定義 Ｅ氏 要求の出た経緯について、開発や顧客、ユーザーなどに会話で確認する。 設計 Ａ氏 イレギュラーケースなどすべて、成果物に書ききれていないため、開発時の知 識は人に残り、属人化することがある。 引き渡し Ｆ氏 引き渡し時の会話は議事録にまとめるが必ずしも運用のナレッジとして活用さ れていない。 引き渡し Ｇ氏 運用担当者は、対面レビューで開発と会話をすることにより、システムを理解 し、知識を向上させ、運用テストは、実践力を向上させる。 運用テスト Ｈ氏 運用テストを通して、開発と運用がともに作業することによって、技術、特性 などの知識を移転する。 運用テスト Ｈ氏 プロジェクトの日常のコミュニケーションで様々な気づきがあり、開発から運 用への知識を移転している。 運用段階 Ｂ氏 運用担当者は、開発者の証跡から手順書を作成するが、開発者は、記述してい る内容の証跡を丁寧に残していないことがある。 運用段階 Ｃ氏 運用担当者はプロジェクトの途中から参加するため、開発のナレッジが十分理 解できずに運用で活用できていない。 運用を意識した引継ぎ概念モデルは、開発から運用に引継ぎを行う中で、顧客や開発者が意 識すべき知識移転の流れについて示している（図４－３）。本モデルは、顧客や開発者向けて、 運用段階で、顧客がソフトウェアを利用して価値を創出する支援をする運用担当者に対して、 企画段階から運用段階の適切な段階で暗黙知を含めた引継ぎを行う必要性を示している。 図５－２ 運用を意識した引継ぎ概念モデル
6. まとめ
「運用を意識した引継ぎプロセスモデル」は、開発プロジェクトから運用担当への引継ぎを 意識すべきことだけではなく、開発プロジェクトの「引継ぎ」の課題の解決策を示している。 People に関する課題に対しては、ソフトウェア開発の引継ぎにおいて、顧客、開発プロジェ クト、運用担当が他の組織と共創し、組織として新たな知識を得ることができる。この知識は、 それぞれの組織の中の知識と統合されて、ソフトウェア開発における持続的な競争力を生み出 すことに貢献することを提示している。 Product に関する課題に対しては、運用を意識し、成果物の「品質」だけではなく、「整合性・ 量・レベル」に配慮し、運用するために必要な成果物を引継ぐことを示している。顧客の思い を記載している要件定義書や顧客の求めるサービスレベルに関わる SLA、サービスレベル目標 （SLO）などを含む、運用で必要とされる形式知である成果物を品質、成果物間の整合性、量、 記述レベルを考慮して引継ぐことが、運用段階で、顧客と運用担当が価値を創出するために有 効であることを提示している。 Process に関する課題に対しては、運用パターンに関わらず、ソフトウェア開発の PLC にお ける成果物による形式知と、ヒトによる暗黙知を意識するべきプロセスを提示した。顧客、開 発者、運用担当者が、モデルのProcess に示した段階で意識すべき点を考慮して積極的にコミ ュニケーションを図ることで、運用段階で価値を創出するソフトウェア開発に貢献するために 有効であることを提示している。 「運用を意識した引継ぎ概念モデル」は、顧客、開発者に対して、運用を意識して引継ぎを 行うために、運用担当に「形式知」である成果物を引き渡すだけではなく、開発者の「暗黙知」 を含めて運用担当に引継ぐことが、運用段階で価値を創出する為に必要であることをモデルと して強調している。 本研究は、受注型プロジェクトにおいて、複数の運用パターンがあるために、開発から運用 への引継ぎの手順を具体的に示せない中で、運用段階で価値を創出するため、形式知としての 成果物の引き渡しだけではなく、暗黙知としての人による引継ぎが必要な段階を具体的に抽出 した点に新規性がある。 今後は、開発プロジェクトが本モデルを意識して、ソフトウェア開発を実践する場合の課題 を抽出し、それを改善するための「引継ぎの教育」を開発する。運用段階で「価値創出」でき る競争力があるソフトウェア開発に対して貢献することができる研究を進めていく。参考文献
[1]日本プログラムマネジメント協会「改訂 3 版 P2M プログラム＆プロジェクトマネジメント」、 日本能率協会マネジメントセンター、pp.385、2014 [2]日本プログラムマネジメント協会「改訂 3 版 P2M プログラム＆プロジェクトマネジメント」、 日本能率協会マネジメントセンター、pp.44-45、2014 [3]日本プログラムマネジメント協会「改訂 3 版 P2M プログラム＆プロジェクトマネジメント」、日本能率協会マネジメントセンター、pp.214、2014
[4]スチュアート・ランス「ITIL サービストランジション」、TSO 出版、pp.292、2013
[5]廣瀬 守克「品質記録の記述レベルと成果物品質に関する実証的考察－SI プロジェクトにお ける成果物品質向上に関する実践事例」、日本 MOT 学会、No.3、pp.1-10、2015
[6] 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
[7]児玉充「バウンダリーチーム・イノベーション」、翔泳社、2010
[8]瀬川 良久「思考スキルの組織的間移転を通じた暗黙知創造のモデル－電子機器受託生産企 業の事例研究」、日本 MOT 学会、No.2、pp.9-18、2014
[9]樋口耕一「テキスト型データの計量的分析 ―2 つのアプローチの峻別と統合―」、数理社会 学会、 19(1):、pp101-115、2004
[10]大谷尚「SCAT: Steps for Coding and Theorization －明示的手続きで着手しやすく小規 模データに適用可能な質的データ分析手法－」、感性工学、10-3、 pp155-160、 2011
