目次
第１章

序論 ..................................................................................................................... 2

1.1

研究の背景と問題意識........................................................................................... 2

1.2

研究の目的 ............................................................................................................ 3

1.3

本論文の構成 ......................................................................................................... 4

第２章

先行研究レビュー................................................................................................ 5

2.1

意思決定の定義 ..................................................................................................... 5

2.2

意思決定論の概観.................................................................................................. 5

2.2.1

意思決定論の概観 ........................................................................................... 5

2.2.2

診断論的意思決定論........................................................................................ 6

2.2.3

個人の意思決定と組織の意思決定 .................................................................. 7

2.2.4

危機的状況における意思決定.......................................................................... 8

2.3

意思決定のプロセスに関する研究 ......................................................................... 8

2.3.1

すぐれた意思決定とは .................................................................................... 8

2.3.2

意思決定プロセスのフレームワーク ............................................................... 9

2.3.3

経験と直観による意思決定 ............................................................................12

2.4

ＩＴプロジェクトにおける意思決定の研究..........................................................13

2.5

先行研究レビューの結果と本研究の意義 .............................................................13

第３章

本研究の方法......................................................................................................14

3.1

仮説の構築と検証方法..........................................................................................143.2

回帰方程式と変数の定義 ......................................................................................15

3.3

アンケートの各質問と変数との対応 ....................................................................15

第４章

結果と考察 .........................................................................................................19

4.1

アンケートの配布と回収 ......................................................................................19

4.2

意思決定プロセスへの準拠度合い ........................................................................20

4.3

仮説の検証 ...........................................................................................................22

4.4

各説明変数とプロジェクトの成否との相関..........................................................23

4.5

その他の変数とプロジェクトの成否との相関 ......................................................26

第５章

結論 ....................................................................................................................32

5.1

要約 ......................................................................................................................32

5.2

含意 ......................................................................................................................32

5.3

本研究の限界と課題 .............................................................................................34【謝辞】 ...........................................................................................................................35【参考文献】 ....................................................................................................................35【付録１】アンケート用紙...............................................................................................38【付録２】アンケートの自由回答欄に記載されたコメント .............................................46
1

第１章
1.1

序論

研究の背景と問題意識

情報システムの開発は、一般にプロジェクト方式でおこなわれている1。企業にとって、プロジェクトの成功／失敗は事業そのものの成功／失敗に直結し、企業の収益や成長を大きく左右する2。
ところが近年のＩＴプロジェクトでは、品質・コスト・納期の全てにおいて当初の計画値を達成することは非常に困難になってきている3。また、2002 年 4 月に発生した大手銀行のシステム障害や、2007 年 5 月の航空会社のシステム障害に見られるとおり、ＩＴプ
ロジェクトが失敗した時の影響は単に一企業だけにとどまらず、社会的な問題に広がるケースもある。
ＩＴプロジェクトの成功率を高めるためにＩＴ業界では、プロジェクトマネジメント手法の導入や開発手法の標準化、さらにプロジェクト・マネジメント・オフィスの設置などの組織面での強化、プロジェクトマネージャや特定の専門スキルを持つ技術者の育成など、さまざまな対策がおこなわれている。
しかし、2008 年になっても証券取引所における株式売買システムの障害や、銀行のシス
テム障害が発生しており、公開されないものも多数あることを想定すると、中村・矢口(2003)の報告から５年が経過した今でも、ＩＴプロジェクトの成功率は改善していないのではないかと考えられる。
筆者が大手システム・インテグレータに入社した 1980 年代後半の頃は、１人の優秀なプロジェクトリーダーが、ＩＴプロジェクトを機関車のように牽引し、成功に導くということがあたりまえのようにおこなわれていた。
しかし、ＩＴに求められる要件が年々厳しくなり、さらにはネットワーク、データベー
ス、開発言語、ＯＳなど、使用する技術分野が多岐に渡る現在では、プロジェクトの成功／失敗の要因を、プロジェクトマネージャやプロジェクトリーダーの個人のスキルに求めることができるほど、単純ではなくなっている。とはいえ、プロジェクトマネージャやプ
ロジェクトリーダーのスキルがプロジェクトの成否に大きく影響することは否定できない。
一方で、顧客から情報システム開発の引き合いがあっても、プロジェクトマネージャや
プロジェクトリーダーが不足してアサインできず、受注を断念せざるを得ないという事態も起こっている。仕事があるのに、体制を整えることができないという理由で受注できな
いというのは大きな問題である。
ＩＴプロジェクトの成功率を高めるために、また、確実に受注して売上をのばし企業として成長するためにも、プロジェクトマネージャ・プロジェクトリーダーの育成は、ＩＴ企業にとって喫緊の課題となっている。
1

本稿では、情報システムの開発プロジェクトを「ＩＴプロジェクト」と表記する。
松尾谷(2004)を一部手直しして記述。
3 中村・矢口(2003)は、ＱＣＤ（品質・コスト・納期）の全てが当初の目標を達成したプ
ロジェクトは 26.7%であったと報告している。それまでＩＴプロジェクトの成功率を数字
ではっきり示したものはなく、26.7%という低い数値は当時衝撃的であった。
22ところで、全てのＩＴ技術者がプロジェクトマネージャやプロジェクトリーダーになる
わけではない。プロジェクトの特性と、技術者の経験・知識・適正などを考慮に入れて、多くの技術者の中から特定の人物が指名（あるいは抜擢）されるのが普通である。また、全てのプロジェクトマネージャやプロジェクトリーダーが、常にプロジェクトを成功に導いているわけでもない。同じプロジェクトマネージャやプロジェクトリーダーでも、ある
プロジェクトでは成功し、別のプロジェクトでは失敗する、ということもある。ＩＴプロ
ジェクトの成功率が３割にも満たないという報告は、ＩＴプロジェクトのマネジメントが非常に困難であることを示している。
プロジェクトマネージャやプロジェクトリーダーになるＩＴ技術者は、どのようなスキルを有しているのか。また、プロジェクトを成功に導く場合とそうでない場合とで、プロジェクトマネージャ・プロジェクトリーダーの行動や思考プロセスには違いがあるのか。
この２つの素朴な問が、本研究の背景にある。
1.2

研究の目的

本研究の目的は、ＩＴプロジェクトのクリティカルな場面において、プロジェクトマネ
ージャやプロジェクトリーダーが、どのようなプロセスで意思決定をおこなっているかを探ることにある。
本研究での「クリティカルな場面」とは、プロジェクトが以下のような状況に陥った場
面、つまり、プロジェクトの緊急事態を想定している。
・このまま放置すると納期遅れ・赤字・品質不良等、ＰＪの失敗が見えている。
・対策を検討する時間は限られており、予断を許さない。
・すばやく決断し結果を出さねばならない。
・今回の意思決定で失敗したら挽回できないかも知れない。
研究の対象をクリティカルな場面に絞ったのは、平時の場面における意思決定に比べて、クリティカルな場面における意思決定のほうがプロジェクトの成否に直結しており、意思決定の特徴がよくあらわれると考えたためである。
また、意思決定をおこなう主体であるプロジェクトマネージャ、プロジェクトリーダーの定義についても触れておく。本研究では、図１－１に示すようなプロジェクト体制を想定している。プロジェクトマネージャは、プロジェクトの引き合い・見積もり段階から関与し、プロジェクトの成功責任を負う。それに対し、プロジェクトチーム編成後にアサインされ、プロジェクトの遂行責任を負うのがプロジェクトリーダーである4。

4

堀上(2001)を一部修正
3

プロジェクトの成功責任ＰＭ

プロジェクトの
遂行責任

ＰＬ

ＳＬ

ＳＬ

ＳＬ

メンバー

メンバー

メンバー

図１－１

営業との調整、社内との調整
顧客との調整ＰＭ：プロジェクトマネージャ
ＰＬ： プロジェクトリーダー
ＳＬ：サブリーダー

プロジェクト体制（出所：堀上(2001)を一部手直しした）
1.3

本論文の構成本論文の構成は次の通りである。まず本章では、研究の背景と問題意識、そこから導かれた研究の目的について述べる。
第２章では、意思決定に関する先行研究をレビューし、本研究との関連について述べる。
最初に 2.1 で意思決定の定義をおこない、続く 2.2 で意思決定論の概観をおこなう。意思決定論の概観では、包括的な意思決定論をレビューしたあと、本研究にも関連のある、「診
断論的意思決定論」について議論する。次に、個人の意思決定と組織の意思決定の違いについて触れ、それぞれのメリットや限界について述べる。意思決定論の概観の最後として、危機的状況における意思決定の議論をレビューする。
2.3 は意思決定のプロセスに関する先行研究のレビューである。まず、すぐれた意思決
定ではプロセスを重視すべきである、ということについて議論し、次に、Elbing、ＫＴ法、
Tichy と Bennis の３つの意思決定プロセスのフレームワークをレビューする。そして、経験と直観による意思決定について議論したあと、2.4 でＩＴプロジェクトにおける意思決定の先行研究を紹介する。2.5 では、本研究の意義を明らかにし、第２章を締めくくる。
第３章では、本研究の方法について述べる。3.1 で仮説の構築をおこない、Tichy とBennis のフレームワークに基づいたアンケート調査による検証について議論する。3.2 で回帰方程式と変数の定義をおこなったあと、3.3 でアンケートの各質問項目と変数との対応付けをおこなう。
第４章は、検証結果の報告と考察である。最初にアンケートの結果について報告し、仮説の検証をおこなう。次に、被説明変数であるプロジェクトの成否と、各説明変数との相関について考察する。
第５章は、本研究のまとめである。まず要約を示す。次に実証結果から導き出された、クリティカルな場面における意思決定プロセスの提案を試みる。最後に本研究の限界と課題について述べる。

4

第２章
2.1

先行研究レビュー

意思決定の定義

宮川(2005, p. 40)によれば、意思決定とは「一般に何らかの目的を達成するための行動の選択についての決定」と定義されている。また印南(1997, p. 29)も、「複数の選択肢の中から、一つ（ないし複数）の選択肢を選ぶこと」と定義している。つまり、人や組織が、選択を迫られた場面において、複数の代替案の中から行動を決定すること、といえよう。
2.2
2.2.1

意思決定論の概観
意思決定論の概観

意思決定論の概観については、宮川(2005)によって体系的・網羅的にまとめられている。
著書「意思決定論」で、意思決定論を、基礎とアプローチの二つに分けて議論している。
前半の意思決定論の基礎では、まず、経営学の発展の歴史として、科学的管理法から現代経営学に至るまでの流れを整理し、その中で意思決定論の位置づけをおこなっている。
意思決定は「管理者の重要な職能である」とし、Simon(1997)5の議論を引用しながら、意思決定とリーダーシップが「相互依存的な職能」であり、行動科学は「意思決定論の体系の中に組み込まれなければならない」と結論づけている。組織でおこなう意思決定においては、議論を牽引するリーダーの存在は不可欠である。また意思決定した結果を確実に実行していくためには、管理者のリーダーシップは重要である。そのため、意思決定とリー
ダーシップを互いに関連づけて考えるという宮川の視点は説得力がある。
つぎに意思決定の問題と構造について説明し、いくつかの意思決定プロセスを紹介している。意思決定プロセスについては多くの論者が見解を示しているが、共通項としてSimon(1997)から「問題認識／情報活動」「設計活動」「選択活動」の３つの活動を抽出している。意思決定論の行動的フレームワークとしては、Elbing(1970)のフレームワークを参照している。なお、Elbing(1970)のフレームワークについては 2.3 で改めて紹介する。
意思決定論の基礎の最後では、意思決定の諸次元として、意思決定論におけるさまざまな側面での議論を概観している。
後半の意思決定論のアプローチでは、意思決定論の「経済学的アプローチ」「経営学的アプローチ」「決定理論的アプローチ」「デシジョン・トリーとベイジアン決定理論」「システ
ム分析的アプローチ」「行動科学的／組織科学的アプローチ」「戦略的意思決定へのアプローチ」と多岐にわたって説明し、「意思決定のための予測」に展開し、最後に企業の社会的責任における意思決定のありかたについて触れて締めくくっている。
以上のように、一言で「意思決定論」といっても、さまざまな観点から多くの研究がなされていることがわかる。

5

Herbert A. Simon, The New Science of Management Decision, revised edition,

Prentice-Hall, 1977（稲葉元吉・倉井武夫訳「意思決定の科学」産業能率出版部,1979）5

2.2.2

診断論的意思決定論

意思決定論を体系的に整理した宮川(2005)に対し、印南(1997)は、どのようにすれば「すぐれた意思決定」ができるのか、という問題意識を背景に議論を展開している。まず、意思決定論には、「規範的意思決定論」と「記述的意思決定論」の二つがあると述べる6。
規範的意思決定論とは、「合理的な人間であればどういう意思決定をすべきか」という伝統的な意思決定論で、次のようなステップを踏めば、すぐれた意思決定ができるというものである。
①問題の定義②評価基準の発見③基準間の重み付け④選択肢の生成⑤基準に基づいた選択肢の評価⑥最適な決定の計算⑦選択肢の選択
規範的意思決定論は、表２－１にあげた事項を前提としている。しかし、限定合理性の議論にもある通り、人間の認知能力は極めて限られている。規範的意思決定論のとおりに意思決定を実際におこなうことができるのか、できたとしてすぐれた意思決定になるのか
は保証がない、と述べている。
表２－１ 規範的な意思決定のステップと前提事項
ステップ
前提事項
1 問題の定義
人間は完全に問題を定義できる
2 評価基準の発見
人間は全ての判断基準を認識できる
3 基準間の重み付け
人間は正確な基準間の重み付けができる
4 選択肢の生成
人間は全ての選択肢を知っている
5 基準に基づいた選択肢の評価 人間は正確な選択肢の評価ができる
6 最適な決定の計算
人間は正確な決定の計算ができる
7 選択肢の選択
人間は最適な選択肢を選ぶことができる（印南(1997, pp. 33-36)をもとに筆者が表に整理した）
次の「記述的意思決定論」とは、「人間が実際にどういう意思決定をしているかを実証的に記述する立場」である。
印南(1997)では、記述的意思決定論そのものについての詳細な記述はなく、「直観」「同調圧力」「固定パイの幻想」の３点について触れられている程度である。なお、意思決定においてしばしば問題となる「直観」については、2.3 であらためて整理する。
以上の２つの意思決定論に対し、印南(1997)は、第３の意思決定論として、「診断論的意思決定論」を提案している。「診断論的意思決定論」とは、「規範的意思決定論の規範性を引き継ぎながら、これに実証的な根拠を明らかにし、実際的な立場から『すぐれた意思決6

長瀬(2003)にも同様の記述がある
6

定』を実現する術を追求する」意思決定論である。
図２－１は、印南(1997)が提案する診断論的意思決定論のモデルである。このモデルは「メタ判断」「結果と評価」「意思決定プロセス」の３つの部分からなる。それぞれの部分の説明は割愛するが、３つの部分の中で、「メタ判断」が「意思決定全体をコントロール」
する最も重要な部分であると述べられている。
結果と評価

メタ判断
問題の定義
予測される結果
情報収集の程度

期待
意欲レベル

質
スピード
満足度・受容度

意思決定プロセス
判断プロセス
アイデア生成プロセス
グループプロセス
コミュニケーション

図２－１

診断論的意思決定のモデル（出所：印南, 1997, p. 49）
2.2.3

個人の意思決定と組織の意思決定

意思決定は、個人による意思決定と、組織による意思決定に分類することができる。印南(1997, p. 273)は、組織の意思決定とは、「誰か個人の意思決定か、ある集団の意思決定
か、あるいは集団間の意思決定が、組織の意思決定であるとみなされる」と定義している。
また、印南(1999, p. 317)では、「すぐれた組織の意思決定は、自己の存続のために、絶えず組織の真理モデルの有効性をチェックし、政治プロセスを乗り越えながら、必要な組織変革をおこなうための合理的な意思決定である。」と述べ、組織を知悉した人間の判断力と実行力がリーダーシップである、という認識が広がりつつあることを指摘している。
さらに、集団で意思決定をおこなう利点について、印南(1997, pp. 276-279)は、「全体の知識や情報の量を比べた場合、集団の方が個人よりも一般的に多い」「実行可能性を高めることを目的として、利害関係者を意思決定に参加させたり、決定の正当性を示すため」「責任の分散」の三点をあげている。宮川(2005)も、集団の意思決定と個人の意思決定の違いについて「有効性」「能率性」「開放性」「リスクに対する態度」「合理性」の観点から議論を展開している。
個人でおこなう意思決定においては、個人の認知能力の限界や、様々な種類のバイアスなどによって、間違った意思決定をしてしまう可能性がある。集団でおこなう意思決定においても、同調圧力や集団思考によってすぐれた意思決定を妨げられることがある。つまり「集団で意思決定するよりも、非常に優秀な個人に判断を任せた方が、望ましい」という場合もあれば、逆に「運営次第で、いかなる個人でも成しえないすぐれた意思決定を、
7

集団の場合おこなえる可能性がある」ということである（印南,1997, pp. 284-285)。
「非常に優秀な個人に判断を任せ」るという点については、中西(2007)も、「もしあるレベルの人物が自分ではとても歯が立たないと感じるような問題に出くわした場合、彼らは専門知識を持った人（びと）に決定権を（上にも、下にもあるいは水平にも）移動（移譲）することができる」という Roberts and Libuser(1993)7の議論を引用し、「意思決定のシフティング」という概念を指摘している。
2.2.4

危機的状況における意思決定

危機的な場面において意思決定者は、「過去の異なる出来事における経験にもとづいて、非効率で独裁的な意思決定をおこなう」（Jehn and Weigelt, 2001）。Janis(1989)は、重大な場面でリーダーがしばしば意思決定を誤る原因として、リーダーの名誉欲などの利己的欲求である「自己中心的制約」、時間の制約などの「認識上の制約」、容認・同意などの社
会的・人的支援の欲求である「人間関係による制約」があることを指摘している。その上で、意思決定の体験的モデルとして、「警戒システム的問題解決アプローチ」を提案している。この「警戒システム的問題解決アプローチ」も万全ではないとしながらも、危機的な状況における意思決定の有効な切り札であるとの指摘である。
要約すると、危機的な状況においては、さまざまな制約により、平時とは異なるステッ
プで意思決定がおこなわれ、かつ誤った意思決定が下される可能性が高い、ということである。そうならないためには、Janis(1989)が「警戒システム的問題解決アプローチ」で述
べているように、経験と勘による手軽な意思決定のアプローチをとるのではなく、「能力の限界まで頭脳労働にうちこむ努力」が必要とされるのである。
2.3
2.3.1

意思決定のプロセスに関する研究
すぐれた意思決定とはどのような意思決定が、すぐれた意思決定といえるのかについて、印南（1997)は、二つの判断基準をあげている。第一は「合目的性」である。目的というのは、単に意思決定の質のみを指すのではない。時と場合によって、意思決定の質よりもスピードが重視される場合もあれば、関係者の受容度を優先する場合もある。すなわち、「意思決定のスピードを重視するのであれば、多少の質の低下や満足度に低下を招いても、素早い意思決定をおこなうべきであり、受容度が重要な局面ではスピードはもちろん、時には質もある程度犠
牲にしなければならない」（印南, 1997, p. 54)ということである。
第二の判断基準は「規範的プロセスへの合致性」である。意思決定の結果が、成功だったのか、失敗だったのかについて、「必ずしも意思決定直後の観察可能な結果から判断できない可能性がある」。したがって、「意思決定がすぐれたものであるか否かは、考えられる
限りの規範的なプロセスに従って意思決定がなされたか否かで判断されるべきである」（印

Roberts K. H. and Libuser C. (1993)From Bhopal to Banking: Organizational Design
Can Mitigate Risk, Organizational Dynamics, 21(4),pp.15-26

78

南, 1997, p. 55)、という考え方である。すなわち、意思決定の評価をその内容ではなく、プロセスで評価すべきである、というものである。
同様に、Roberto(2005)も多くの事例をあげて、問題の解決策、すなわち意思決定の内容ではなく、どのような方法で問題に取り組むべきかという、意思決定のプロセスを重視すべきであると述べている。とくに、多くのリーダーが意思決定とその実行に失敗するのは、「問題が生じたとき、リーダーが何よりもまず『正しい解決策』の発見に気を取られてしまい、一歩下がって意思決定のためにとるべき『正しいプロセス』を定めようとしないことが原因」であると結論づけている（Roberto, 2005, 邦訳 p. 61）。
意思決定のプロセスを重視すべきであるとはいえ、意思決定の内容を軽視してもよい、ということではない。また、「効果的な意思決定のプロセスを定めて先導しても、それだけで優れた選択と円滑な実行が保証されるわけではない。しかし、質の高い意思決定プロセスを開発し、管理すれば、優れた選択と効果を生む「確率」が飛躍的に高まる」とも Roberto
は述べている（Roberto, 2005, 邦訳 pp. 61-62）。
意思決定プロセスの質と結果の関係について、Janis (1989)は、「意思決定プロセスと結果の間に成り立つ関係が普遍的なものかどうかを調べるためには、研究をさらに進めてい
く必要がある」と前提をおいた上で、「適切な手順であれば結果が成功と出る可能性は高くなる」と結論づけている（Janis, 1989, 邦訳 pp. 148-149)。
2.3.2
2.3.2.1

意思決定プロセスのフレームワーク
意思決定プロセスのフレームワーク

2.3.1 で、意思決定には、プロセスが非常に重要であることが明らかになった。では、どのようなプロセスで意思決定すれば、「すぐれた意思決定」をおこなったといえるのか。
意思決定プロセスのフレームワークも、研究者によっていくつか提案されているが、こ
こでは、Elbing、ＫＴ法、Tichy と Bennis の３つのフレームワークをレビューする。
2.3.2.2

Elbing のフレームワーク

宮川(2005, pp. 54-61)は、意思決定のプロセスには人間の行動論的要素がかかわりを持
つとの視点から、Elbing(1970)のフレームワークを紹介している。
Elbing(1970)は、意思決定のプロセスを、不均衡の知覚、診断、問題の定義、解決策の選択、実行の５段階に分けた。それぞれの段階の詳細は表２－２に示した通りである。
ここで重要な点は２つある。第一に、意思決定プロセスにおいて通常議論の中心となるのは、解決策の選択をどのようにおこなうか、であるが、診断が正確で、問題が適切にか
つ明瞭に定義されたならば、選択すべき解決策はほぼ決まっている、ということである（宮川, 2005, p. 59）。第二は、どんなによい解決策の選択をおこなったとしても、それが実行されなければ、問題は解決しない、ということである8。このような意味から、「解決策の8

組織が戦略をなぜ実行しないのかということについては、鈴木(2006)が限定合理性と組織モデルの観点から議論を展開している。
9

選択」の前後の段階を含めて意思決定プロセスのフレームワークとして示していることは非常に意義がある。
表２－２
プロセス
Step1 不均衡の知覚
望ましくない環境変化を認識する
Step2 診断
問題の本質を正確にとらえる

Step3 問題の定義
解決されるべき問題の選択と定義

Step4 解決策の選択
解決策を選択すること診断や問題の定義ができていれば選択はさほど困難ではない
Step5 実行
解決策を実行すること

Elbing のフレームワーク
留意事項
認識の方法
事態を構造化する診断の基準①事象と言語を区別されている②事実と意見を区別されている③原因が明確にされている④多元的な因果関係を明らかにされている⑤診断結果を文書化されている問題の定式化の基準①問題が明確に叙述されている②問題の徴候ではなく基本的な原因が叙述されている③なぜ問題なのか基準が明確である④問題が明確な行動論的用語で叙述されている⑤問題の叙述の中に解決策を含まない⑥問題が誰の問題であるかを明らかである⑦長期の問題と短期の問題を区別されている⑧問題をディレンマとして叙述されていない解決策の評価
①組織目標を満たすことができる②関係者の納得を得られること③予想される反応について評価されている④過去の逸失利益にとらわれず現状の解決に集中している⑤代替案のリスクが考慮されている
実行にあたって考慮すべきこと①解決策の実行可能性を評価すること②行動の動機づけを与えること③実行のフィードバックの仕組みを備えること④リーダーシップを発揮すること宮川(2005, pp. 54-61)および、
Elbing(1970, pp. 44-163)より筆者が表に整理した
2.3.2.3

ＫＴ法

ＫＴ法とは、Kepner と Tregoe が開発した、組織の意思決定プロセスのフレームワーク
である(Kepner and Tregoe, 1981)。
まず人間には、基本的な４つの思考パターンがあると述べる。すなわち、・何が起こっているのか・どうしてそうなったのか
・どういう処置をとればよいのか
・将来どんなことが起こりそうかである。
さらに、これらを発展させて組織における意思決定プロセスとして、「状況分析」「問題分析」「決定分析」「潜在的問題分析」として体系化した。

10

目標の
分類

代替案の
作成

潜在的問題
の想定

比較・選択

実施計画
ステートメント

ＤＡ
決定分析

ＰＰＡ
潜在的問題
分析

目標の
設定
決定
ステートメント

状況分析

可能性のある
原因の特定
対策の
計画
情報網の
整備

ＰＡ
問題分析
裏づけ

差異
ステートメント

原因の
テスト

明細化
原因の
想定

図２－２

ＫＴ法の体系（出所：Kepner and Tregoe, 1981, 邦訳,p. 2 を筆者が簡略化）「状況分析」は、「何が起こっているか」つまり状況の認識、明確化、分離、複雑な状況の管理可能な要素への細分化、状況に対するコントロールの維持である。「問題分析」は、問題の起こっている原因と結果をあきらかにすることである。
「決定分析」は、選択肢の決定、すなわち意思決定そのものである。最後の「潜在的問題分析」は、問題が近い将来にどのような結果をもたらすか、あるいは対策をとることにより、どのような結果が生じる
可能性があるのかを予測することである。
Elbing のフレームワークとの関連でいえば、「状況分析」は「不均衡の知覚」、「問題分析」は「診断」と「問題の定義」に、「決定分析」は「解決策の選択」に該当すると思われる。ＫＴ法の「潜在的問題分析」は、Elbing のフレームワークに明確に対応するものがな
いが、あえていえば、「不均衡の知覚」と「問題の定義」に包含されると考えられる。逆に、
Elbing のフレームワークにおける「実行」に相当するプロセスは、ＫＴ法にはない。
ＫＴ法は、開発者の Kepner と Tregoe が事業化し、各国で展開している。日本においても高多(1987)が、国内企業での導入事例を紹介している。ＩＴ関連では、古宮(1998)がソ
フトウェアの障害対策へのＫＴ法の導入事例を、中丸他(2005)が、プロジェクトのリスク分析への導入事例を報告している。
2.3.2.4

Tichy と Bennis のフレームワーク

Tichy and Bennis(2007a, b)は、リーダーの下す判断は、
「人材」
「戦略」
「危機」のいずれかをテーマとしていること、判断は一瞬にして下されるものではなく、何らかのプロセ
スを経るものであることを発見し、意思決定プロセスは、「準備フェーズ」、「判断フェーズ」、「実行フェーズ」の３段階でおこなわれると、議論を展開している。
「準備フェーズ」は、どの問題について判断が求められるかを考え、メンバーに理解させるフェーズである。①問題を察知し、明らかにする、②問題の本質をつかむ、③関係者の協力をとりつける、という３つの STEP からなる。
11

「判断フェーズ」は、意思決定そのもので、明確な意思決定が求められる。
最後の「実行フェーズ」は判断を具体化することであり、①実行と、②結果のフィード
バックと調整の２つの STEP からなる。
また、準備フェーズの STEP3 から STEP2 へ、判断フェーズから準備フェーズの STEP3
へ、実行フェーズの STEP2 から STEP1 への３つの軌道修正の STEP を定義している。
したがって、合計で９つの STEP からなる意思決定プロセスのフレームワークとなる。
ＳＴＥＰ１・問題の兆候をつかむ
・将来を切り拓こうという熱意を抱く

兆候に気づき、明らかにする

準備フェーズ
ＳＴＥＰ２

判断フェーズ
ＳＴＥＰ３

ＳＴＥＰ１

・混沌のなかから ・だれが大切なス ・明快な判断を本質だけをテークホルダー下す
見抜く
かを見極める・判断の中身や・条件を明確に・ステークホルダ
理由をていね決める
ーを巻き込み、
いに説明する・文脈を定め、
熱意を引き出す
周囲の理解を・優れたアイデアを促す
集める
問題の大枠をつかむ

周囲の協力を
取りつける

軌道修正

図２－３

判断する

軌道修正

実行フェーズＳＴＥＰ２

・実行にみずから ・たゆみなくフィ関わる
ードバックを・実行へのサポー 求める
トを惜しまない・フィードバックに・わかりやすい
耳を傾ける
マイルストーン ・調整する
を設ける

学習し、
調整する

実行する

軌道修正

Tichy と Bennis のフレームワーク（出所：Tichy and Bennis, 2007a, 邦訳）
Elbing のフレームワークとの比較では、「準備フェーズ」は「不均衡の知覚」「診断」「問
題の定義」に、「判断フェーズ」は「解決策の選択」に、「実行フェーズ」は同じく「実行フェーズ」に該当する。
Elbing が、各 STEP においておこなうべき事項の基準や評価のポイントを厳密に定義しているのに対し、Tichy と Bennis のフレームワークには、リーダーの思い描く文脈や意思も重視されている。また、軌道修正の STEP を明確に定義しているのも特徴的である。
2.3.3

経験と直観による意思決定

印南(1997, p. 37)によれば、直観は「過程を意識できない意思決定」で、「経験によって発見され単純化された決定方法、すなわちヒューリスティックス」である。
「直観に頼った
意思決定は簡単で低コストではあるが、多くの場合は、意思決定の質が問題」になり、経験を積んでも意思決定の質がよくなるとは限らないことに問題がある（印南, 1997, p. 41)9。
直観による意思決定がよい結果をもたらすのかどうかについては他にも議論がある。
Hayashi(2001)は、1990 年代のクライスラーの窮状を救ったのは、当時の社長の直観であり、とくにスピードを重視する意思決定においては、直観による意思決定は欠かせないものであるとしている。さらに、論理的手法で解決すべき問題を、企業トップの直感10に頼9

データ収集におけるヒューリスティックとバイアスについては、印南(1997)の他、長瀬(2005)にも詳細な紹介がある。
10 意思決定論において「ちょっかん」は通常「直観」と書くが、ここは原文に従い「直感」と記述した。
12

るケースがよくあることから11、経験により直感の精度を上げるべきであると主張する。
この考えに対し、Bonabeau(2003)は、「状況が複雑化すればするほど、直観は人を誤った方向に導く」とし、コンピュータを活用した意思決定支援ツールと組み合わせて直観の弱点を補うべきであるとしている。Hoch(2001)も、人間の専門家とモデルを組み合わせる
ことにより、双方の短所を補い、意思決定の質を高めることができると主張している。
以上の議論から、直観による意思決定は、時にすばらしい結果をもたらすことがあるが、いつも質のよい意思決定ができるとは限らない。直観による意思決定をおこなう際には、モデルやツールも活用して問題に取り組む必要がある、ということになる。
2.4

ＩＴプロジェクトにおける意思決定の研究

ＩＴプロジェクトにおける意思決定の研究については、３つの研究をレビューする。
三井・石津(1998)は、「戦略的選択法」による意思決定支援システムのプロトタイプ適用の結果を報告している。「戦略的選択法」とは、「戦略的決定における不確実性を同定し、不確実性削減のための探査方法に基づいてそれらを分類し、さらに、探査方法の決定を含
む意思決定手順を導くアプローチ」（三井・石津, 1998）である。プロトタイプとはいえ、意思決定支援システムを実際にシステム化し、有効性を検証している点が興味深い。
楊他(2003)は、中国人、在日中国人、日本人のプロジェクトマネージャ経験者を対象に調査をおこない、意思決定における認知構造の比較研究をおこなっている。
まず最初にアンケート調査によって、意思決定に影響を及ぼす個人要因（パーソナリテ
ィ、プロジェクトの成功・失敗認知要因、意思決定考慮要因、プロジェクトマネジメント
能力、リーダーシップ）、社会要因（環境文化要因、人間関係要因）間の関連を比較した。
次に、ISM 法による関連づけテストならびに、個別インタビューによってプロジェクト
成功失敗要因間の関連性を表す認知構造をモデル化し、日中の比較検討をおこなった。
国内のＩＴ業界の現場では、海外からのＩＴ技術者が日本人と一緒に働く姿が普通に見られるようになっている。国内向けの開発を海外に発注するオフショアも盛んになっている。このような状況を考えると、日本人と外国人とでは、認知構造にどのような違いがあるのかを理解しておくことは、非常に重要である。
渡邉(2007)は、意思決定におけるアンカリングを一般モデル化し、実際の失敗ＩＴプロ
ジェクトに適用して有用性を検証している。ＩＴプロジェクトが失敗する要因には様々なものがあるが、プロジェクトの意思決定における各段階でアンカリングの悪影響を排除するべきという指摘は、質のよい意思決定をおこなうために非常に重要なことである。
2.5

先行研究レビューの結果と本研究の意義

先行研究のレビューにより、以下の３点があきらかになった。
①意思決定をおこなう際には、決定内容そのものよりも、決定に至るまでのプロセスが重要である。
11

Mintzsberg(1975)にも同様の議論がある。
13

②意思決定プロセスのフレームワークがいくつか提案されているが、実際の意思決定がフレームワークに沿っておこなわれているのかについて、実証研究がなされていない。
③ＩＴプロジェクトにおける意思決定の研究は数が少なく、意思決定プロセス全体を俯瞰した研究は見あたらない。
本研究の目的は、ＩＴプロジェクトのクリティカルな場面において、プロジェクトマネ
ージャやプロジェクトリーダーが、どのようなプロセスで意思決定をおこなっているかを明らかにすることである。その手段として、ＩＴプロジェクトのプロジェクトマネージャ、
プロジェクトリーダー経験者を対象にアンケート調査をおこない、フレームワークに沿った意思決定がおこなわれているかについて、実証研究をおこなう。
したがって本研究の意義は、実際のＩＴプロジェクトの開発現場でおこなわれている意思決定が、先行研究で提案されているフレームワークに沿ったものであるのかどうかを、定量的に検証することにある。

第３章
3.1

本研究の方法

仮説の構築と検証方法

先行研究レビューの結果と、筆者の問題意識より導かれた仮説は以下のとおりである。
仮説：
ＩＴプロジェクトの成否は、クリティカルな場面でおこなわれた意思決定の、合理的な意思決定プロセスへの準拠度合いと関連がある。
この仮説を検証するために、第２章でレビューした Tichy と Bennis の意思決定プロセ
スのフレームワークをベースとしたアンケート調査をおこない、結果を定量的に分析する。
そして、①クリティカルな場面でおこなわれる意思決定がどの程度フレームワークに準拠しておこなわれているかを確認し、②その準拠度合いと、プロジェクトの成否との相関を重回帰分析によって検証する。
なお、Tichy と Bennis のフレームワークを検証対象に選んだのは２つの理由による。
第一は、Tichy と Bennis のフレームワークが発表されたのが 2007 年 10 月であり、本論文執筆時点で最新の研究であることである。アンケートをおこなう上で、できるだけ最新の研究に基づいて調査したほうが、より時代に即したものになると判断した。
第二に、Tichy と Bennis のフレームワークにおける、「準備フェーズ」「判断フェーズ」「実行フェーズ」という３段階のフェーズが明快でわかりやすく、また筆者の 20 年以上にわたるＩＴプロジェクトの実務経験に照らしてみても、現場の実態に即した無理のない
フレームワークであると認識することができたためである。

14

3.2

回帰方程式と変数の定義

調査のベースとなる回帰方程式を以下のように定義した。
回帰方程式１：
Ｙ＝ｃ＋α1･PRE1＋α2･PRE2＋α3･PRE3＋α4･RED1＋α5･CALL＋α6･RED2＋α7･EXE1＋α8･EXE2＋α9･RED3
回帰方程式２：
Ｙ＝ｃs＋αs･SUM
回帰方程式１は、プロジェクトの成否と Tichy と Bennis のフレームワークの各 STEPとの相関を表す。Ｙは被説明変数、すなわち、プロジェクトの成否である。ｃは定数項、
α1～α9 は回帰係数、その後ろに続くのが Tichy と Bennis のフレームワークの各 STEPに対応する説明変数である。
回帰方程式２は、プロジェクトの成否と Tichy と Bennis のフレームワークとの相関を表す。Ｙは回帰方程式１と同じく、プロジェクトの成否である。ｃs は定数項、αs は回帰係数で、SUM は回帰方程式１の説明変数をひとつの説明変数としてまとめたものである。
それぞれの説明変数の詳細については、3.3 で説明する。
3.3

アンケートの各質問と変数との対応

仮説を検証するために作成したアンケートは、「付録１」に掲載した。
全体を大きく５つのパートで構成している。最初のパートは、回答者の属性に関する質問である。パートの最後に、プロジェクトマネージャ・プロジェクトリーダーの立場での、
クリティカルな場面での意思決定経験の有無を質問している。ここで「①あり」と回答した場合のみ、第二番目以降のパートの質問の回答してもらうこととなっている。
第二番目のパートは、クリティカルな場面での意思決定をおこなったＩＴプロジェクトの属性に関する質問である。核となる質問は、「問２－４」「問２－５」である。このアン
ケート自体が、プロジェクトマネージャ・プロジェクトリーダーの立場でおこなった、ク
リティカルな場面での意思決定のプロセスを問うものなので、「問２－４」で、「①プロジェクトマネージャ」「②プロジェクトリーダー」と回答のあったものが有効回答となる。
ただし、プロジェクトにおける回答者の立場がプロジェクトマネージャ・プロジェクトリーダーでなかったとしても、職責として相応の立場にあれば、プロジェクトに対して責任ある立場で意思決定をおこなったと見なすことができると考えられる。そのため、「問２－５」の質問を設定した。つまり、「問２－４」で「③その他」と回答した場合でも、「問２－５」で「①会長・社長」「②役員」「③本部長クラス」「④部長クラス」「⑤課長クラス」「⑥係長・主任クラス」と回答してあった場合は、有効回答であると判断した。
第三番目のパートは、説明変数に関連する質問のパートであり、アンケートの中核にあたる部分である。Tichy と Bennis のフレームワークの各 STEP の特徴をベースに、ＩＴ15

プロジェクトの開発プロセス12に沿うように考慮して質問を設定した。
このパートはさらに、Ａ，Ｂ，Ｃの３つのパートに細分化されている。最初のＡのパートは、ＩＴプロジェクトで問題が発生した時の状況を問うもので、Tichy と Bennis のフレームワークの「準備フェーズ」に相当する。
最初の説明変数である、準備フェーズの STEP1(変数名：PRE1）に相当する質問が「問３Ａ－４」である。準備フェーズの STEP1 の特徴は「問題の兆候をつかみ、切り拓こうとする熱意を抱く」というものである。問題の前兆に事前に気づいたか、気づいたとしたら何らかの対応をとったのかを問う質問を設定した。問題の前兆に気づき、何らかの対応をとった場合を「２」、問題の前兆に気づいたが、対応はとらなかった場合を「１」、問題の前兆に気づかなかった場合を「０」と数値化した。
準備フェーズの STEP2(変数名：PRE2）に相当する質問が「問３Ａ－３」である。「問題の本質をつかみ、周囲の理解を促す」という特徴に基づき、３つの質問を用意した。すなわち「(1)問題の原因の特定をおこなったか」「(2)問題が発展すると、どのような事態に陥る危険性があるかを予測したかどうか」「(3)問題を明文化し、関係者の理解を得る努力をしたかどうか」である。質問に対する選択肢のうち、肯定的な選択肢を選んだ場合を「１」、そうでない場合を「０」とし、３つの質問での合計値を PRE2 の値とした。
準備フェーズの STEP3(変数名：PRE3）に相当する質問は「問３Ａ－５」である。「ステークホルダーを見極め、周囲の協力をとりつける」というのがこの STEP の特徴である。
したがってここでは、ＩＴプロジェクトでクリティカルな問題が発生した場合に、関係者になると思われるステークホルダーを５つ想定し、それぞれに対して相談をおこなった場
合を「１」、そうでない場合を「０」とし、合計を PRE3 の値とした。
Ａのパートの最後の質問「問３Ａ－６」は、準備フェーズの STEP3 から STEP2 への軌
道修正をおこなったかどうかを問う質問である(変数名：RED1）。軌道修正をおこなった場合を「１」軌道修正しなかった場合を「０」とした。
Ｂのパートは、Tichy と Bennis のフレームワークの「判断フェーズ」とその軌道修正に関する質問である。判断フェーズ(変数名：CALL）の特徴は「明快な判断を下し、その内容や理由を説明する」というものである。前半の「明快な判断を下す」という点については、「問３Ｂ－２」で、何を重視して意思決定をおこなったかという観点から５つの質問を設定した。すなわち「(1)意思決定のわかりやすさ」「(2)実行可能性」「(3)成功確率」「(4)
合理性・納得性」「(5)スピード」である。５つの質問とも、重視した場合を「１」、そうでない場合を「０」とした。後半の「意思決定の内容や理由を説明する」については、「問３
Ａ－５」であげた、各ステークホルダーに対し、説明をおこなったかどうかという質問を

12

情報システムの開発プロセスには、ウォータフォール・モデルやスパイラル・モデルなど、いくつかの種類がある。当アンケートでは、暗にウォータフォール・モデルで開発されるＩＴプロジェクトを想定しているが、どのモデルを使ったＩＴプロジェクトでも差し支えないように配慮した。なお、「問３Ａ－１」で用意した選択肢はウォータフォール・モ
デルの各開発プロセスを指すものである。ウォータフォール・モデルは、もっともポピュラーである反面、前フェーズへの手戻りがないことを前提としており、問題も多いことが指摘されている。しかし、「問３Ａ－１」で回答された内容から推測する限り、ウォータフォール・モデルで開発するＩＴプロジェクトは、まだまだ多いと考えられる。
16

「問３Ｂ－４」として設定した。説明をおこなった場合を「１」、そうでない場合を「０」とした。「問３Ｂ－２」「問３Ｂ－４」の値の合計を CALL の値とした。
判断フェーズから準備フェーズ STEP3 への軌道修正(変数名：RED2）に関する質問は、「問３Ｂ－５」である。軌道修正をおこなった場合を「１」、そうでない場合「０」とした。
Ｃのパートが、Tichy と Bennis のフレームワークの「実行フェーズ」と、その軌道修
正に関する質問である。
「問３Ｃ－１」「問３Ｃ－２」「問３Ｃ－３」が実行フェーズ STEP1(変数名：EXE1)に該当する質問で、それぞれが、この STEP の特徴である、「実行への関与」「中間目標の設定」「達成目標の設定」に対応している。「問３Ｃ－１」では、実行に自ら関与した場合を「１」、自らは関与しなかった場合を「０」とした。「問３Ｃ－２」では、中間目標設定の要否を検討した場合を「１」、検討しなかった場合を「０」とした。「問３Ｃ－３」では、達成目標の要否を検討した場合を「１」、検討しなかった場合を「０」とした。そして、「問
３Ｃ－１」「問３Ｃ－２」「問３Ｃ－３」の値の合計を EXE1 の値とした。
実行フェーズ STEP2（変数名：EXE2）に該当する質問が「問３Ｃ－４」である。このSTEP の特徴は「実行のフィードバックを求める」である。したがって、実行の達成状況を確認したかどうか、という質問を設定した。確認した場合を「１」、確認しなかった場合を「０」とし、これを EXE2 の値とした。
「問３Ｃ－５」は、実行フェーズ STEP2 から実行フェーズ STEP1 への軌道修正の有無（変数名：RED3）を問う質問である。軌道修正をおこなった場合を「１」、そうでない場
合を「０」とした。
第四番目のパートは、被説明変数「プロジェクトの成否（変数名：Y）」に関する質問である。本研究では、「プロジェクトの成否」を中村・矢口(2003)にしたがい、品質・納期・コスト全てが計画通りか、それ以上の成果が出た場合をプロジェクトの成功と定義する。
留意点は「計画」を、意思決定時点の計画値としていることである。プロジェクト開始
時点の計画値としていないのは、ＩＴプロジェクトの場合、様々な理由で、プロジェクト
開始当初の計画値を途中で変更することは十分考えられることであり、意思決定をおこなった時点ですでに開始当初の計画値が変更されている可能性があると判断したからである。
「問４－１」が品質、「問４－２」が納期、「問４－３」がコストに関する質問である。
意思決定時点の計画値以上の成果が出た場合を「４」、計画通りであれば「３」、計画値を下回ったが容認できる場合を「２」、計画値を下回り、結果も容認できなかった場合を「１」とした。そして、「問４－１」「問４－２」「問４－３」の値の合計を Y の値とした。
最後の第五番目のパートは自由回答欄である。アンケートに対する感想・意見および、意思決定に関する回答者の考えを自由に書いてもらい、アンケートの分析結果の解釈への活用ならびに、本研究の課題の抽出に役立てることを意図したものである。
第二章で掲載した Tichy と Bennis のフレームワークの図２－３に、変数名の対応付けを追記して図３－１として再掲する。
回帰方程式１の各変数の対応と、アンケートの各質問との対応をまとめたものが、表３－１である。

回帰方程式２については、表３－２にまとめた。

17

準備フェーズ
ＳＴＥＰ２(PRE2)

ＳＴＥＰ１(PRE1)
・問題の兆候をつかむ
・将来を切り拓こうという熱意を抱く

兆候に気づき、明らかにする

判断フェーズ
ＳＴＥＰ３(PRE3)(CALL)

・混沌のなかから ・だれが大切なス ・明快な判断を本質だけをテークホルダー下す
見抜く
かを見極める・判断の中身や・条件を明確に・ステークホルダ
理由をていね決める
ーを巻き込み、
いに説明する・文脈を定め、
熱意を引き出す
周囲の理解を・優れたアイデアを促す
集める
問題の大枠をつかむ

周囲の協力を取りつける

軌道修正(RED1)

図３－１

判断する

軌道修正
(RED2)ＳＴＥＰ１(EXE1)

実行フェーズ
ＳＴＥＰ２(EXE2)

・実行にみずから ・たゆみなくフィ関わる
ードバックを・実行へのサポー 求める
トを惜しまない・フィードバックに・わかりやすい
耳を傾ける
マイルストーン ・調整する
を設ける

実行する

学習し、
調整する

軌道修正
(RED3)

Tichy と Bennis のフレームワーク（図２－３に掲載した図に、変数との対応を加筆した）
表３－１

アンケートと回帰方程式１の各変数との対応

変数
Ｙ

変数の意味
プロジェクトの成否
問４－１～問４－３の回答を下記の値で数値化して合計
４点： ①意思決定時点の計画値以上の成果を得た
３点： ②意思決定時点の計画通りの成果を得た
２点： ③意思決定時点の計画を下回ったが、容認できる成果は得た
１点： ④意思決定時点の計画を下回り、結果も容認できるものではなかった

PRE1

準備フェーズＳＴＥＰ１への準拠の度合い
２：準拠大問３Ａ－４の回答が①かつ、問３Ａ－４（２）の回答が③か④
１：準拠小問３Ａ－４の回答が①かつ、問３Ａ－４（２）の回答が③④以外
０：準拠なし問３Ａ－４の回答が②
準備フェーズＳＴＥＰ２への準拠の度合い
問３Ａ－３の３つの設問のうち、①を選択した数
準備フェーズＳＴＥＰ３への準拠の度合い
問３Ａ－５の５つの設問のうち、①を選択した数
ＳＴＥＰ３からＳＴＥＰ２への軌道修正の有無
１：あり
問３Ａ－６の回答が①まはた②
０：なし
問３Ａ－６の回答が③
判断フェーズへの準拠の度合い
問３Ｂ－２の（１）～（５）の設問のうち、①または②または③を選択した数と、
問３Ｂ－４の５つの設問のうち、①を選択した数の合計
判断フェーズへから準備フェーズＳＴＥＰ３への軌道修正の有無
１：あり
問３Ｂ－５の回答が①まはた②
０：なし
問３Ｂ－５の回答が③
実行フェーズＳＴＥＰ１への準拠の度合い
下記のポイントの合計
・問３Ｃ－１の回答が①②③のとき１，以外のとき０・問３Ｃ－２の回答が①②のとき１，以外のとき０・問３Ｃ－３の回答が①②のとき１，以外のとき０
実行フェーズＳＴＥＰ２への準拠の度合い
１：あり
問３Ｃ－４の回答が①②③④
０：なし
問３Ｃ－４の回答が⑤⑥⑦
実行フェーズＳＴＥＰ２からＳＴＥＰ１への軌道修正の有無
１：あり
問３Ｃ－５の回答が①②
０：なし
問３Ｃ－５の回答が③④

PRE2
PRE3
RED1
CALL
RED2
EXE1

EXE2
RED3

18

表３－２

回帰方程式２の説明

変数
Ｙ

変数の意味
プロジェクトの成否
回帰方程式１と同じ

SUM

フレームワークへの準拠度合い
回帰方程式１の各説明変数の合計

なお、アンケートには、他にもいくつか質問を設定している。これは、Tichy と Bennisのフレームワークに沿った項目以外にも、意思決定に影響を与える可能性があるのではな
いかと思われるものを、経験則をもとに筆者が独自に追加したものである。

第４章
4.1

結果と考察

アンケートの配布と回収

第三章で説明したアンケートを、２つの方法で配布し回収した。
第一の方法は、独立系大手のシステム・インテグレータであるＡ社に協力を要請したことである。社員数約 3,000 人のうち、プロジェクトマネージャ・プロジェクトリーダー経験者と思われる開発部門の役職者の中から、162 名を抽出して電子メールでアンケートを送付し、回答を依頼した。
第二の方法は、筆者が所属する以下のＩＴ系の任意団体に対し、それぞれのメーリング
リストを通じてアンケートの協力依頼をおこなった。
・関西情報技術士会13
会員数約７０名、うちほとんどがＩＴ系技術者
・日本システムアナリスト協会14
会員数約５００名、うちほとんどがＩＴ系技術者
・筆者がＩＴコーディネータ資格を取得した際の、研修クラスの同期生
約２０名、半数がＩＴ系Ａ社の場合、アンケートの回答を依頼した 162 名のうち、83 名より回答があり、うち有効回答は 70 名であった。
無効とみなした回答の内訳は、プロジェクトマネージャ・プロジェクトリーダーの立場
で、意思決定をおこなった経験がないという回答が 12 件15、意思決定当時の回答者のプロ
1985 年創立。英文名称は PEAK/IT(Professional Engineers Association in KANSAI/
Information Technology)。
関西圏の情報工学部門の技術士を中心とした団体。本論文執筆時、筆者はこの団体の副会長。(http://www.peak.gr.jp/)
14 2000 年創立。英文名称は JSAG(Japan Systems Analysts Group)
情報処理技術者試験の「システムアナリスト試験」合格者を中心とした任意団体。
(http://www.jsag.org/)13

19

ジェクトにおける立場が、プロジェクトマネージャ・プロジェクトリーダー以外であり16、かつ職位が担当者であったものが 1 件であった17。
筆者の所属する任意団体の場合は、アンケートに協力すると反応のあった会員 23 名にアンケートを電子メールで送付し、全員から回答があった。23 件とも有効回答であった。
有効回答である 93 件を、全件・Ａ社のみの 70 件・Ａ社以外の 23 件の３つに分けて仮説の検証をおこなった。
4.2

意思決定プロセスへの準拠度合い

アンケートの結果から、「表４－１」に示すとおり、説明変数のそれぞれについて回答の割合を分析し、プロジェクトマネージャ・プロジェクトリーダーが Tichy と Bennis のフレームワークにどれだけ準拠した意思決定をおこなっているかを確認した。
表４－１

各説明変数の回答分布割合

準備フェーズSTEP1の準拠度合い(PRE1)
全数
割合
数
２準拠大
57.0%
53
１準拠小
19.4%
18 76.3%
０準拠なし
23.7%
22 平均
合計
93 1.3

準備フェーズSTEP1の準拠度合い(PRE1)
Ａ社のみ
割合
数
２準拠大
55.7%
39
１準拠小
20.0%
14 75.7%
０準拠なし
24.3%
17
平均
合計
70
1.3

準備フェーズSTEP1の準拠度合い(PRE1)
Ａ社以外
割合
数
２準拠大
60.9%
14
１準拠小
17.4%
4 78.3%
０準拠なし
21.7%
5 平均
合計
23 1.4

準備フェーズSTEP2の準拠度合い(PRE2)
全数
割合
数
３点
66.7%
62
２点
31.2%
29 97.8%
１点
2.2%
2
０点
0.0%
0 平均
合計
93 2.6

準備フェーズSTEP2の準拠度合い(PRE2)
Ａ社のみ
割合
数
３点
64.3%
45
２点
35.7%
25 100.0%
１点
0.0%
0
０点
0.0%
0
平均
合計
70
2.6

準備フェーズSTEP2の準拠度合い(PRE2)
Ａ社以外
割合
数
３点
73.9%
17
２点
17.4%
4 91.3%
１点
8.7%
2
０点
0.0%
0 平均
合計
23 2.7

準備フェーズSTEP3の準拠度合い(PRE3)
全数
割合
数
５点
14.0%
13
４点
19.4%
18
３点
41.9%
39 75.3%
２点
18.3%
17
１点
5.4%
5
０点
1.1%
1 平均
合計
93 2.9

準備フェーズSTEP3の準拠度合い(PRE3)
Ａ社のみ
割合
数
５点
10.0%
7
４点
20.0%
14
３点
42.9%
30 72.9%
２点
18.6%
13
１点
7.1%
5
０点
1.4%
1
平均
合計
70
2.8

準備フェーズSTEP3の準拠度合い(PRE3)
Ａ社以外
割合
数
５点
26.1%
6
４点
17.4%
4
３点
39.1%
9 82.6%
２点
17.4%
4
１点
0.0%
0
０点
0.0%
0 平均
合計
23 3.1

準備フェーズSTEP3からSTEP2への軌道修正の有無(RED1)
全数
成功率
数
あり
90.3%
84
なし
9.7%
9
合計
93

準備フェーズSTEP3からSTEP2への軌道修正の有無(RED1)
Ａ社のみ
成功率
数
あり
91.4%
64
なし
8.6%
6
合計
70

準備フェーズSTEP3からSTEP2への軌道修正の有無(RED1)
Ａ社以外
成功率
数
あり
87.0%
20
なし
13.0%
3
合計
23

15

「問１－６」の回答が「②なし」であったもの「問２－４」の回答が「③その他」であったもの
17 「問２－５」の回答が「⑦担当者」であったもの
16

20

判断フェーズの準拠度合い(CALL)
全数
割合
数
１０点
15.1%
14
９点
28.0%
26
８点
33.3%
31
７点
12.9%
12
６点
6.5%
6 95.7%
５点
2.2%
2
４点
1.1%
1
３点
1.1%
1
２点
0.0%
0
１点
0.0%
0
０点
0.0%
0 平均
合計
93 8.2

判断フェーズの準拠度合い(CALL)
Ａ社のみ
割合
数
１０点
11.4%
8
９点
30.0%
21
８点
34.3%
24
７点
17.1%
12
６点
4.3%
3 97.1%
５点
2.9%
2
４点
0.0%
0
３点
0.0%
0
２点
0.0%
0
１点
0.0%
0
０点
0.0%
0
平均
合計
70
8.2

判断フェーズの準拠度合い(CALL)
Ａ社以外
割合
数
１０点
26.1%
6
９点
21.7%
5
８点
30.4%
7
７点
0.0%
0
６点
13.0%
3 91.3%
５点
0.0%
0
４点
4.3%
1
３点
4.3%
1
２点
0.0%
0
１点
0.0%
0
０点
0.0%
0 平均
合計
23 8.1

判断フェーズから準備フェーズSTEP3への軌道修正の有無(RED2)
全数
成功率
数
あり
64.5%
60
なし
35.5%
33
合計
93

判断フェーズから準備フェーズSTEP3への軌道修正の有無(RED2)
Ａ社のみ
成功率
数
あり
57.1%
40
なし
42.9%
30
合計
70

判断フェーズから準備フェーズSTEP3への軌道修正の有無(RED2)
Ａ社以外
成功率
数
あり
87.0%
20
なし
13.0%
3
合計
23

実行フェーズSTEP1の準拠度合い(EXE1)
全数
割合
数
３点
73.1%
68
２点
16.1%
15 89.2%
１点
10.8%
10
０点
0.0%
0 平均
合計
93 2.6

実行フェーズSTEP1の準拠度合い(EXE1)
Ａ社のみ
割合
数
３点
72.9%
51
２点
17.1%
12 90.0%
１点
10.0%
7
０点
0.0%
0
平均
合計
70
2.6

実行フェーズSTEP1の準拠度合い(EXE1)
Ａ社以外
割合
数
３点
73.9%
17
２点
13.0%
3 87.0%
１点
13.0%
3
０点
0.0%
0 平均
合計
23 2.6

実行フェーズSTEP2の準拠度合い(EXE2)
全数
成功率
数
あり
91.4%
85
なし
8.6%
8
合計
93

実行フェーズSTEP2の準拠度合い(EXE2)
Ａ社のみ
成功率
数
あり
90.0%
63
なし
10.0%
7
合計
70

実行フェーズSTEP2の準拠度合い(EXE2)
Ａ社以外
成功率
数
あり
95.7%
22
なし
4.3%
1
合計
23

実行フェーズSTEP2からSTEP1への軌道修正の有無(RED3)
全数
成功率
数
あり
87.1%
81
なし
12.9%
12
合計
93

実行フェーズSTEP2からSTEP1への軌道修正の有無(RED3)
Ａ社のみ
成功率
数
あり
87.1%
61
なし
12.9%
9
合計
70

実行フェーズSTEP2からSTEP1への軌道修正の有無(RED3)
Ａ社以外
成功率
数
あり
87.0%
20
なし
13.0%
3
合計
23

まず、準備フェーズの STEP1(変数名：PRE1）であるが、「準拠大」「準拠小」の割合が一番少ないＡ社のみの場合でも、75%を超えている。したがって、プロジェクトマネージャ・プロジェクトリーダーは、問題の兆候を事前につかみ、何らかの対応をとっているということになり、Tichy と Bennis のフレームワークに準拠している、と判断できる。
つぎに、準備フェーズの STEP2(変数名：PRE2）については、「問３Ａ－３」の３つの質問のうち、２つ以上について、肯定的な回答をおこなった場合を「準拠している」ものと判断した。結果は、ほぼ 100%に近い値となっており、この STEP も Tichy と Bennisのフレームワークに準拠している、と判断できる。
以下同様に、回答を点数化した質問については 5 割以上の得点であったもの、回答が二値になっているものについては、肯定的な回答であったものの割合を求めた。
結果として、全ての質問について割合が過半数を超えた。
したがって、プロジェクトマネージャ・プロジェクトリーダーは、クリティカルな場面においてフレームワークに沿った意思決定をおこなっている、と結論づけることができる。
なお、参考までに被説明変数の「プロジェクトの成否(Y)」についても、結果を見ておく。
21

表４－２
品質の結果
全数
割合
数
計画以上
5.4%
計画通り
61.3%
容認可
31.2%
容認不可
2.2%
合計
納期の結果
全数
割合
数
計画以上
2.2%
計画通り
72.0%
容認可
22.6%
容認不可
3.2%
合計
コストの結果
全数
割合
数
計画以上
5.4%
計画通り
39.8%
容認可
41.9%
容認不可
12.9%
合計

プロジェクトの成否

557 66.7%
29
2 平均
93 2.7

品質の結果
Ａ社のみ
割合
数
計画以上
2.9%
計画通り
62.9%
容認可
32.9%
容認不可
1.4%
合計

2
67 74.2%
21
3 平均
93 2.7

納期の結果
Ａ社のみ
割合
数
計画以上
2.9%
計画通り
74.3%
容認可
20.0%
容認不可
2.9%
合計

5
37 45.2%
39
12 平均
93 2.4

コストの結果
Ａ社のみ
割合
数
計画以上
4.3%
計画通り
44.3%
容認可
38.6%
容認不可
12.9%
合計

品質・納期・コスト全てと計画との比較
全数
成功率
数
計画以上
31.2%
29
計画以下
68.8%
64
合計
93

2
44
23
1
70

2
52
14
2
70

3
31
27
9
70

65.7%
平均
2.7

77.1%
平均
2.8

48.6%
平均
2.4

品質・納期・コスト全てと計画との比較
Ａ社のみ
成功率
数
計画以上
34.3%
24
計画以下
65.7%
46
合計
70

品質の結果
Ａ社以外
割合
数
計画以上
13.0%
計画通り
56.5%
容認可
26.1%
容認不可
4.3%
合計

3
13 69.6%
6
1 平均
23 2.8

納期の結果
Ａ社以外
割合
数
計画以上
0.0%
計画通り
65.2%
容認可
30.4%
容認不可
4.3%
合計

0
15 65.2%
7
1 平均
23 2.6

コストの結果
Ａ社以外
割合
数
計画以上
8.7%
計画通り
26.1%
容認可
52.2%
容認不可
13.0%
合計

2
6 34.8%12
3 平均
23 2.3

品質・納期・コスト全てと計画との比較
Ａ社以外
成功率
数
計画以上
21.7%
5
計画以下
78.3%
18
合計
23

表４－２から、全数では品質については 66%以上、納期では 74%以上が意思決定当時の計画通りか、それ以上であるのに対し、コストでは 45%であり半数以上が計画を下回った。
品質・納期・コストの全てが計画通りかそれ以上になった割合は 31.2%で、中村・矢口(2003)が報告したＩＴプロジェクトの成功率 26.7%に近い値となっている。
4.3

仮説の検証

仮説を検証するために、計量経済分析用ソフトウェア TSP を用いて回帰分析をおこなう。
TSP による回帰分析は、標準の回帰分析(OLS)、トービットモデルによる回帰分析(TOBIT)、順序プロビットモデルによる回帰分析(ORDPROB)がある。
被説明変数であるプロジェクトの成否(Y)のとる値が、０を含む正の整数であることから、
順序プロビットモデルによる回帰分析の結果を用いて解釈をおこなう。標準の回帰分析、
トービットモデルによる回帰分析の結果は参考値として扱う。
また、全体のサンプル数は 93 であるが、Ａ社が 70 と回答数の大半を占めるため、Ａ社の結果を中心に解釈をおこない、全数、Ａ社以外の結果は参考値とする。
回帰分析の結果をまとめたものが「表４－３」「表４－４」である。
まず、表４－３であるが、９ある説明変数のうち、被説明変数の「プロジェクトの成否(Y)」との相関が認められたのは、「準備フェーズ STEP2(PRE2）」「準備フェーズのSTEP3(PRE3）」「実行フェーズ STEP2（EXE2）」「実行フェーズ STEP2 から実行フェー
ズ STEP1 への軌道修正の有無（RED3）」の４つである。しかし、「準備フェーズの22

STEP3(PRE3）」「実行フェーズ STEP2（EXE2）」については、回帰係数の推定値がマイナスとなっている。さらに、9 の説明変数をひとつの説明変数にまとめた回帰分析では、「表４－４」のとおり、被説明変数と説明変数との間に全く相関が認められなかった。
よって、仮説「ＩＴプロジェクトの成否は、クリティカルな場面でおこなわれた意思決定の、合理的な意思決定プロセスへの準拠度合いと関連がある。」は棄却された。
表４－３
サンプル数
決定係数
調整済決定係数
Ｆ値
被説明変数
プロジェクトの成否
説明変数
定数項
準備フェーズ
STEP1
準備フェーズ
STEP2
準備フェーズ
STEP3
準備フェーズＳＴＥＰ３から
ＳＴＥＰ２への軌道修正
判断フェーズ
判断フェーズへから準備
フェーズＳＴＥＰ３への軌道修正
実行フェーズ
STEP1
実行フェーズ
STEP2
実行フェーズＳＴＥＰ２から
ＳＴＥＰ１への軌道修正

OLS
93
2
.167617Ｒ
2.077358
修正ＲＦ
1.85708Ｙ
問4-1～4-3
の合計値
C
PRE1
PRE2
PRE3
RED1
CALL
RED2
EXE1
EXE2
RED3

回帰方程式１の分析結果

全数
TOBIT
←

ORDPROB
←

←

←

OLS
70
.201544.081776
1.68278
←

Ａ社のみ
TOBIT
←

ORDPROB
←

←

←

OLS
23
.487557.132789
1.37430←

ORDPROB
←←←6.40280
6.40280
1.41789
7.41929
7.419292.25894
5.817125.817121.00475(1.23241)(1.16427)(.939562)(1.54816)(1.43332)(1.25855)(2.46852)(1.85586)(1.85097)-.034904-.034904-.042452-.092824-.092824-.087648.354450.354450.262498(.183014)(.172895)(.134169)(.204162)(.189017)(.154426)(.483001)(.363125)(.344010).761828** .761828*** .600034***.572312.572312*.530377*
2.05888* 2.05888*** 1.62427 **(.311210)(.294003)(.233794)(.369174)(.341789)(.283941)(.983308)(.739260)(.766416)-.168585-.168585-.146969-.318164* -.318164* -.280817** -.318927-.318927-.216087(.161323)(.152403)(.119424)(.182986)(.169412)(.141498)(.638747)(.480216)(.450323).170442.170442-.075364-.252033-.252033-.368674.415849.415849.277522(.515486)(.486984)(.386961)(.613037)(.567562)(.475173)(1.12023)(.842202)(.804363).065881.058966-.070170-.070170-.035577-.039035-.039035 -.349625E-02 .065881(.128377)(.121279)(.094855)(.171160)(.158463)(.130032)(.372291)(.279892)(.261567).154755.154755.088068.210973.210973.14272.028041.028041-.114697(.338168)(.319470)(.249811)(.362501)(.335611)(.276358)(1.63131)(1.22644)(1.20837).183153.183153.160331-.059907-.059907-.019668.467137.467137.408995(.248112)(.234394)(.182044)(.321849)(.297975)(.243737)(.483524)(.363518)(.344363)-1.55622** -1.55622** -1.31203** -1.20422-1.20422* -1.08676* -6.40368* -6.40368*** -5.18082**(.691646)(.653403)(.522307)(.735957)(.681364)(.574681)(3.10435)(2.33388)(2.41085)
1.40863** 1.40863*** .977923** 1.91327*** 1.91327*** 1.34999**
1.19132
1.19132
1.10309(.556627)(.525850)(.417057)(.671616)(.621796)(.530104)(1.22005)(.917242)(.879614)
カッコ内の値は標準偏差、Ｐ値<0.1：* Ｐ値<0.05：** Ｐ値<0.01：***表４－４回帰方程式２の分析結果

全数
TOBIT
←

Ａ社のみ
OLS
ORDPROBOLS
TOBITORDPROB
OLS
サンプル数
93
←
70
←
←
23
2
.348796E-03.451339E-02.045118
決定係数
Ｒ2-.352933E-03-.010636-.010126
調整済決定係数
修正Ｒ
Ｆ値
Ｆ.031752.308302.992238
被説明変数
Ｙ
問4-1～4-3
←
←
←
←
←
←
プロジェクトの成否
の合計値
説明変数
定数項
C
7.630627.63062
2.126818.51126
8.511262.87066
5.87638(.998670)(.987873)(.738049)(1.21618)(1.19868)(.951028)(1.85690).827525E-02 .827525E-02 -.493590E-02 -.031742-.031742-.032089.083353
フレームワークへ SUMの準拠度合い(.046441)(.045939)(.032423)(.057168)(.056345)(.040813)(.083678)
カッコ内の値は標準偏差、Ｐ値<0.1：* Ｐ値<0.05：** Ｐ値<0.01：***

4.4

Ａ社以外
TOBIT
←

Ａ社以外
TOBIT
←

ORDPROB
←←←5.87638(1.77432).083353(.079957).821388(1.23522).043220(.055461)

各説明変数とプロジェクトの成否との相関

4.3 によって仮説は棄却されたが、被説明変数と各説明変数との間には、どのような解釈が成り立つのであろうか。ここでは、表４－３の回帰分析の結果をもとに、プロジェク
トの成否と、それぞれの説明変数との関係について解釈をおこなう。
・準備フェーズの STEP1(PRE1）
問題の兆候を事前につかんだからといって、必ずしもプロジェクトの成否に影響を与えないとの結果である。しかし、問題の兆候を事前につかんで適切な対応をおこなった結果、クリティカルな問題が発生しなかったプロジェクトについては、本アンケートの回答の対象にはならないということを考慮しておく必要がある。
23

逆に、事前に問題の兆候をつかんで処置をおこなっても、クリティカルな問題に発展することがあるということであるが、本研究とは別の課題として、研究する価値がある。
・準備フェーズの STEP2(PRE2）
この変数の意味するところは、「問題の本質をつかみ、周囲の理解を促す」である。
問題が発生した場合、単に表面上に見えている事象だけでなく、本質をつかんでおかな
いと適切な対応をとることはできない。また、クリティカルな問題の解決にあたっては、
プロジェクト内外の関係者と問題意識を共有することは非常に重要である。このような観点から、有意な結果を示したことは理解できるものである。
・準備フェーズの STEP3(PRE3）
回帰係数がマイナスで有意となっている。この変数の意味するところは、問題を解決するために「ステークホルダーを見極め、周囲の協力をとりつける」ということである。これに対応するアンケートの質問項目は、問題解決のための情報収集や解決策の検討をおこなうにあたって関係者との相談の有無を問うものであった。つまり、関係者に相談すればするほどプロジェクトは失敗する、という予想外の結果となっている。
ただし、全体の 93 件あるいは、Ａ社以外の 23 件では、いずれも有意ではなく、Ａ社だけの特徴となっている。なぜそのような結果となるのかについては、本アンケートの結果
だけでは説明できない。あくまで推測に過ぎないが、たとえば、クリティカルな問題について関係者に相談をしても、周囲の協力をうまく得るようなことができない何らかの、組織的な要因がＡ社にはあるのかも知れない。
・準備フェーズの STEP3 から STEP2 への軌道修正の有無(RED1)
軌道修正をおこなって問題の本質の見直しをおこなったとしても、プロジェクトの成否とは何ら関連がないという結果である。ということは、最初に問題の本質を見誤り、以降のフェーズになってから誤りに気がついて見直しをおこなったとしても効果がなく、取り返しがつかない、という解釈がなりたつ。
・判断フェーズ(CALL)
意思決定をおこなう際に「明快な判断を下し、その内容や理由を説明」しても、プロジ
ェクトの成否には関係がない、という結果である。意思決定時の明確さ・実行可能性・成
功確率・合理性・スピード・関係者への説明は、非常に重要であると考えていたため、意外な結果であった。
・判断フェーズから準備フェーズ STEP3 への軌道修正(RED2）
この変数は準拠率においても最低の割合であった。一度意思決定をおこなったあとは、後から内容を見直してもプロジェクトの成否には影響がない、という結果であり、速やかに実行に移したほうが得策ということになる。
・実行フェーズ STEP1(EXE1)
24

意思決定の結果を、プロジェクトマネージャ・プロジェクトリーダー自ら実行するのか、メンバーに任せるのか、あるいは実行するにあたって中間目標などを適切に設定しても、プロジェクトの成否には影響がない、ことを意味している。
・実行フェーズ STEP2(EXE2)
回帰係数がマイナスで有意となっている。これは実行過程で目標の達成状況のフィードバックを求めれば求めるほど、プロジェクトが失敗する、ということを示している。これも予想外の結果となった。
クリティカルな問題が発生している場合、実行の進捗状況を関係者に報告する際、平時に比べて細かい報告が求められ、報告の頻度も多くなるのは想像ができる。また、報告の内容自体も、かなり厳しいチェックを受けることになり、報告書類のまとめかたや、報告
会議の場での言動なども、かなり気をつかうこととなる。しかしそれが却って足かせになって、本来おこなうべき業務に注意を集中できず、プロジェクトの成功率を落とすという解釈ができる。
しかし、クリティカルな問題が発生しているＩＴプロジェクトの現場で、関係者に対する進捗報告の精度や頻度を落とすことは、現実問題として難しい。実行するメンバーと進捗報告をおこなうメンバーを分けるなど、体制上の工夫が必要になる。
・実行フェーズ STEP2 から STEP1 への軌道修正(RED3)回帰係数がプラスで有意となっている。実行する過程で、必要に応じて軌道修正をおこ
なえば、プロジェクトは成功に近づく、という結果になっている。逆に、意思決定後は速やかに実行フェーズに移り、軌道修正しながらでも、プロジェクトを前に進めていく必要がある、という解釈ができる。
以上の結果を表４－５に整理した。この結果を総合的にどのように解釈するのかについては、第５章で述べる。
表４－５

回帰方程式１の分析結果まとめ

説明変数
変数
記号 変数の意味
準備フェーズ
STEP1
PRE1 兆候に気づき明らかにする

有意性

係数の
符号 結果の意味するところ

なし

STEP2

PRE2 問題の大枠をつかむ

あり

＋

STEP3

PRE3 周囲の協力をとりつけるあり－

RED1 準備フェーズＳＴＥＰ３からＳＴＥＰ２への軌道修正の有無
判断フェーズ CALL 判断する
（意思決定のわかりやすさ）
軌道修正２
RED2 判断フェーズから準備フェーズ
ＳＴＥＰ３への軌道修正の有無
実行フェーズ
STEP1
EXE1 実行する（実行への参画度）
STEP2
EXE2 学習し、調整する（実行の成果進捗の把握）
軌道修正３
RED3 実行フェーズＳＴＥＰ２からＳＴＥＰ１への軌道修正の有無

なし

軌道修正１

なし
なし
なし
あり

－

あり

＋

25

問題の兆候に事前に気づいても
プロジェクトの成否とは関係がない
問題の本質をつかむことは、プロジェクトを成功させる上で重要である
周囲に相談すればするほどプロジェクトは失敗する
問題の本質を後から見直してもプロジェクトの成否と関係がない
意思決定内容のわかりやすさとプロジェクトの成否とは関係がない
一度決定した意思決定を見直してもプロジェクトの成否とは関係がない
実行に対するＰＭ・ＰＬの参画度合いはプロジェクトの成否とは関係がない
実行時の達成度合いの進捗を求めすぎるとプロジェクトは失敗する
実行しながら必要に応じて軌道修正することはプロジェクトを成功させる上で重要である

4.5

その他の変数とプロジェクトの成否との相関

Tichy と Bennis のフレームワークの９つの STEP のうち、２つの STEP のみがプロジ
ェクトの成功に寄与するということがわかった。ということは、意思決定をおこなう際には、Tichy と Bennis のフレームワークで提示されている要素以外にも、考慮すべき事項があるのではないかと考えられる。では、他にどのような要素が意思決定時に影響し、その結果としてのプロジェクトの成否に影響を与えるのであろうか。
本研究でおこなったアンケートには、Tichy と Bennis のフレームワークに沿った質問
項目以外に、意思決定に影響を与えると思われる 15 の質問項目を設定した。この 15 項目を説明変数、プロジェクトの成否(Y)を被説明変数として、TSP による回帰分析をおこな
い相関を調べた。
15 項目の、回答結果は表４－６、回帰分析の結果は表４－７にまとめた。各項目の説明と分析結果について順次説明するが、これまでと同様に、Ａ社の順序プロビットモデルによる回帰分析(ORDPROB)での分析結果を中心に議論する。
表４－６
プロジェクトの種類
全数
手作り
パッケージ適用
組込みシステムの開発
ソフトウェア製品の開発
インフラ構築コンサルティング
その他

割合 数67.7% 63
16.1% 15
5.4% 5
3.2% 3
4.3% 4
1.1% 1
2.2% 2
合計 93

プロジェクトのピーク時の規模
全数
10人未満
10人以上50人未満
50人以上500人未満
500人以上その他の変数の回答結果

プロジェクトの種類
Ａ社のみ

プロジェクトの種類
Ａ社以外
割合 数
71.4% 50
15.7% 11
5.7% 4
2.9% 2
4.3% 3
0.0% 00.0% 0
合計 70

手作りパッケージ適用
組込みシステムの開発
ソフトウェア製品の開発
インフラ構築コンサルティング
その他

プロジェクトのピーク時の規模
Ａ社のみ
割合 数
16.1% 15
62.4% 58
21.5% 20
0.0% 0
合計 93

割合 数56.5% 13
17.4% 4
4.3% 1
4.3% 1
4.3% 1
4.3% 1
8.7% 2
合計 23

プロジェクトのピーク時の規模
Ａ社以外
割合 数
21.4% 15
62.9% 44
15.7% 11
0.0% 0
合計 70

10人未満
10人以上50人未満
50人以上500人未満
500人以上

手作りパッケージ適用
組込みシステムの開発
ソフトウェア製品の開発
インフラ構築コンサルティング
その他

10人未満
10人以上50人未満
50人以上500人未満
500人以上割合 数
0.0% 060.9% 14
39.1% 90.0% 0
合計 23

プロジェクトにおける回答者の立場
全数
割合 数
プロジェクトマネージャ
37.6% 35
プロジェクトリーダー
50.5% 47
その他
11.8% 11
合計 93

プロジェクトにおける回答者の立場
Ａ社のみ
割合 数
プロジェクトマネージャ
32.9% 23
プロジェクトリーダー
58.6% 41
その他
8.6% 6
合計 70

プロジェクトにおける回答者の立場
Ａ社以外
割合 数
プロジェクトマネージャ
52.2% 12
プロジェクトリーダー
26.1% 6
その他
21.7% 5
合計 23

当時の職位
全数

当時の職位
Ａ社のみ

当時の職位
Ａ社以外

会長・社長
役員
本部長クラス
部長クラス
課長クラス
主任・係長クラス
担当者
その他

割合 数
1.1% 1
0.0% 01.1% 1
8.6% 822.6% 21
46.2% 43
19.4% 18
1.1% 1
合計 93

当時の年齢
全数
20歳未満
20歳～24歳
25歳～29歳
30歳～34歳
35歳～39歳
40歳～44歳
45歳～49歳
50歳～54歳
55歳～59歳
60歳以上

割合 数0.0% 00.0% 00.0% 04.3% 3
18.6% 13
52.9% 37
24.3% 17
0.0% 0
合計 70

会長・社長
役員
本部長クラス
部長クラス
課長クラス
主任・係長クラス
担当者
その他

当時の年齢
Ａ社のみ
割合 数
0.0% 00.0% 04.3% 4
20.4% 19
36.6% 34
21.5% 20
9.7% 9
5.4% 5
1.1% 1
1.1% 1
合計 93

会長・社長
役員
本部長クラス
部長クラス
課長クラス
主任・係長クラス
担当者
その他

割合 数
4.3% 1
0.0% 04.3% 1
21.7% 534.8% 8
26.1% 6
4.3% 1
4.3% 1
合計 23

当時の年齢
Ａ社以外
割合 数
0.0% 00.0% 05.7% 4
21.4% 15
40.0% 28
25.7% 18
5.7% 4
1.4% 1
0.0% 00.0% 0
合計 70

20歳未満
20歳～24歳
25歳～29歳
30歳～34歳
35歳～39歳
40歳～44歳
45歳～49歳
50歳～54歳
55歳～59歳
60歳以上

26

20歳未満
20歳～24歳
25歳～29歳
30歳～34歳
35歳～39歳
40歳～44歳
45歳～49歳
50歳～54歳
55歳～59歳
60歳以上

割合 数0.0% 00.0% 00.0% 017.4% 4
26.1% 6
8.7% 2
21.7% 5
17.4% 4
4.3% 1
4.3% 1
合計 23

当時のIT業務経験年数
全数
3年未満
5年未満
10年未満
20年未満
25年未満
25年以上

当時のIT業務経験年数
Ａ社のみ
割合 数
0.0% 02.2% 2
10.8% 10
60.2% 56
22.6% 21
4.3% 4
合計 93

問題発生フェーズ
全数
システム提案
要件定義
基本設計
詳細設計
プログラム設計
単体開発
結合テスト
システムテストシステム移行システム保守その他

システム提案
要件定義
基本設計
詳細設計
プログラム設計
単体開発
結合テスト
システムテストシステム移行システム保守その他

割合 数0.0% 04.3% 1
4.3% 1
43.5% 10
34.8% 813.0% 3
合計 23

10人未満
50人未満
500人未満500人以上システム提案
要件定義
基本設計
詳細設計
プログラム設計
単体開発
結合テスト
システムテストシステム移行システム保守その他

割合 数4.3% 1
26.1% 6
8.7% 2
0.0% 00.0% 00.0% 013.0% 3
26.1% 6
13.0% 3
0.0% 08.7% 2
合計 23

問題発生時プロジェクトの規模
Ａ社以外
割合 数
25.7% 18
62.9% 44
11.4% 80.0% 0
合計 70

意思決定の方法
Ａ社のみ
割合 数
29.0% 27
23.7% 22
11.8% 1117.2% 16
7.5% 7
10.8% 10
合計 93

3年未満
5年未満
10年未満
20年未満
25年未満
25年以上

問題発生フェーズ
Ａ社以外
割合 数
2.9% 2
0.0% 08.6% 6
14.3% 10
5.7% 4
22.9% 16
14.3% 10
14.3% 10
5.7% 4
7.1% 5
4.3% 3
合計 70

問題発生時プロジェクトの規模
Ａ社のみ
割合 数
22.6% 21
62.4% 58
14.0% 13
1.1% 1
合計 93

意思決定の方法
全数
全員一致
多数決
独断
上位指示
顧客
その他

割合 数
0.0% 01.4% 1
12.9% 965.7% 46
18.6% 13
1.4% 1
合計 70

3年未満
5年未満
10年未満
20年未満
25年未満
25年以上

問題発生フェーズ
Ａ社のみ
割合 数
3.2% 3
6.5% 6
8.6% 8
10.8% 10
4.3% 4
17.2% 16
14.0% 13
17.2% 16
7.5% 7
5.4% 5
5.4% 5
合計 93

問題発生時プロジェクトの規模
全数
10人未満
50人未満
500人未満500人以上当時のIT業務経験年数
Ａ社以外

10人未満
50人未満
500人未満500人以上割合 数
13.0% 3
60.9% 14
21.7% 5
4.3% 1
合計 23

意思決定の方法
Ａ社以外
割合 数
32.9% 23
21.4% 15
12.9% 918.6% 13
8.6% 6
5.7% 4
合計 70

全員一致
多数決
独断
上位指示
顧客
その他

全員一致
多数決
独断
上位指示
顧客
その他

割合 数
17.4% 4
30.4% 7
8.7% 2
13.0% 3
4.3% 1
26.1% 6
合計 23

信念・価値観の重視
全数

信念・価値観の重視
Ａ社のみ

信念・価値観の重視
Ａ社以外

割合 数
非常に重視
9.7% 9重視
35.5% 33
どちらかといえば重視
23.7% 22 68.8%
どちらかといえば重視しなかった 18.3% 17
重視しなかった
8.6% 8
意識しなかった
4.3% 4
合計 93

割合 数
非常に重視
8.6% 6重視
34.3% 24
どちらかといえば重視
24.3% 17 67.1%
どちらかといえば重視しなかった 18.6% 13
重視しなかった
8.6% 6
意識しなかった
5.7% 4
合計 70

割合 数
非常に重視
13.0% 3重視
39.1% 9
どちらかといえば重視
21.7% 5 73.9%
どちらかといえば重視しなかった 17.4% 4
重視しなかった
8.7% 2
意識しなかった
0.0% 0
合計 23

過去の成功体験の重視
全数

過去の成功体験の重視
Ａ社のみ

過去の成功体験の重視
Ａ社以外

割合 数
非常に重視
4.3% 4重視
19.4% 18
どちらかといえば重視
26.9% 25 50.5%
どちらかといえば重視しなかった 17.2% 16
重視しなかった
5.4% 5
意識しなかった
14.0% 13
成功体験なし12.9% 12
合計 93

割合 数
非常に重視
4.3% 3重視
21.4% 15
どちらかといえば重視
27.1% 19 52.9%
どちらかといえば重視しなかった 18.6% 13
重視しなかった
5.7% 4
意識しなかった
11.4% 8
成功体験なし11.4% 8
合計 70

割合 数
非常に重視
4.3% 1重視
13.0% 3
どちらかといえば重視
26.1% 6 43.5%
どちらかといえば重視しなかった 13.0% 3
重視しなかった
4.3% 1
意識しなかった
21.7% 5
成功体験なし17.4% 4
合計 23

過去の失敗体験の重視
全数

過去の失敗体験の重視
Ａ社のみ

過去の失敗体験の重視
Ａ社以外

割合 数
非常に重視
9.7% 9重視
20.4% 19
どちらかといえば重視
30.1% 28 60.2%
どちらかといえば重視しなかった 9.7% 9
重視しなかった
5.4% 5
意識しなかった
9.7% 9
成功体験なし15.1% 14
合計 93

非常に重視
重視
どちらかといえば重視どちらかといえば重視しなかった
重視しなかった
意識しなかった
成功体験なし

直観の重視
全数

直観の重視
Ａ社のみ

直観の重視
Ａ社以外

割合 数
非常に重視
2.2% 2重視
26.9% 25
どちらかといえば重視
35.5% 33 64.5%
どちらかといえば重視しなかった 18.3% 17
重視しなかった
9.7% 9
意識しなかった
7.5% 7
合計 93

割合 数
非常に重視
1.4% 1重視
22.9% 16
どちらかといえば重視
34.3% 24 58.6%
どちらかといえば重視しなかった 22.9% 16
重視しなかった
11.4% 8
意識しなかった
7.1% 5
合計 70

割合 数
非常に重視
4.3% 1重視
39.1% 9
どちらかといえば重視
39.1% 9 82.6%
どちらかといえば重視しなかった 4.3% 1
重視しなかった
4.3% 1
意識しなかった
8.7% 2
合計 23

27

割合 数
10.0% 7
21.4% 15
25.7% 18 57.1%
11.4% 8
4.3% 3
8.6% 6
18.6% 13
合計 70

割合 数
非常に重視
8.7% 2重視
17.4% 4
どちらかといえば重視
43.5% 10 69.6%
どちらかといえば重視しなかった 4.3% 1
重視しなかった
8.7% 2
意識しなかった
13.0% 3
成功体験なし4.3% 1
合計 23

プロジェクトメンバーの意見の重視
全数
割合 数
非常に重視
9.7% 9重視
39.8% 37
どちらかといえば重視
30.1% 28 79.6%
どちらかといえば重視しなかった 10.8% 10
重視しなかった
7.5% 7
意識しなかった
2.2% 2
合計 93

プロジェクトメンバーの意見の重視
Ａ社のみ
割合 数
非常に重視
8.6% 6重視
44.3% 31
どちらかといえば重視
27.1% 19 80.0%
どちらかといえば重視しなかった 12.9% 9
重視しなかった
5.7% 4
意識しなかった
1.4% 1
合計 70

プロジェクトメンバーの意見の重視
Ａ社以外
割合 数
非常に重視
13.0% 3重視
26.1% 6
どちらかといえば重視
39.1% 9 78.3%
どちらかといえば重視しなかった 4.3% 1
重視しなかった
13.0% 3
意識しなかった
4.3% 1
合計 23

プロジェクトメンバー以外の意見の重視
全数
割合 数
非常に重視
4.3% 4重視
24.7% 23
どちらかといえば重視
25.8% 24 54.8%
どちらかといえば重視しなかった 20.4% 19
重視しなかった
12.9% 12
意識しなかった
11.8% 11
合計 93

プロジェクトメンバー以外の意見の重視
Ａ社のみ
割合 数
非常に重視
5.7% 4重視
21.4% 15
どちらかといえば重視
25.7% 18 52.9%
どちらかといえば重視しなかった 21.4% 15
重視しなかった
12.9% 9
意識しなかった
12.9% 9
合計 70

プロジェクトメンバー以外の意見の重視
Ａ社以外
割合 数
非常に重視
0.0% 0重視
34.8% 8
どちらかといえば重視
26.1% 6 60.9%
どちらかといえば重視しなかった 17.4% 4
重視しなかった
13.0% 3
意識しなかった
8.7% 2
合計 23

表４－７
サンプル数
決定係数
調整済決定係数
Ｆ値
被説明変数
プロジェクトの成否
説明変数
定数項

2

Ｒ
2
修正Ｒ
Ｆ
Ｙ

OLS
93
.378072.2569173.12057
問4-1～4-3の合計値

その他の変数の回帰分析結果
全数
TOBIT
←

ORDPROB
←

←

←

OLS
70
.368487.193066
2.10059
←

Ａ社のみ
TOBIT
←

ORDPROB
←

←

←

OLS
23
.849042.525560
2.62470
←

Ａ社以外
TOBIT
←

ORDPROB←←←C
6.498716.49871
1.249996.606896.60689.998826-1.85732-1.85732(1.24020)(1.12849)(1.09748)(1.54969)(1.36111)(1.36572)(3.48614)(1.92322)
プロジェクトの種類
PJ.204669*.204669** .202325**.080988.080988.067111.378530.378530***
問2-1(.108706)(.098914)(.091599)(.185262)(.162718)(.151101)(.240801)(.132844)
プロジェクトのピーク時の規模
PJPEAK.228714.228714.346115.244142.244142.5067111.851171.85117**
問2-2(.378811)(.344688)(.318361)(.477748)(.419611)(.404253)(1.30995)(.722670)
プロジェクトにおける回答者の立場 CLASS-.219404-.219404-.114510-.132545-.132545.023426-.950552 -.950552***
問2-4(.231879)(.210992)(.194660)(.313674)(.275503)(.259675)(.544346)(.300304)
回答者の当時の職位
TITLE.120978.120978.075585-.286019-.286019-.423671
1.02293** 1.02293***
問2-5(.178052)(.162013)(.148910)(.315880)(.277441)(.263461)(.396359)(.218662)
回答者の当時の年齢
AGE.136593.136593.132763-.010880-.010880.022666.430026.430026**
問2-6(.177125)(.161169)(.147014)(.293391)(.257688)(.240821)(.307698)(.169750)
回答者の当時のIT業務経験年数 EXPE
.062744.062744.047724.668546.668546.743955*-.893392 -.893392***
問2-7(.307981)(.280238)(.253599)(.501199)(.440208)(.415643)(.567594)(.313129)
問題発生フェーズ
PHASE-.063418-.063418-.036705-.101603-.101603-.066434-.108646-.108646
問3A-1(.062815)(.057156)(.052393)(.081928)(.071958)(.068064)(.126110)(.069572)
問題発生時のプロジェクト規模
KIBO.252798.252798.113834.280734.280734-.039040-.606431-.606431
問3A-2(.347318)(.316032)(.292769)(.479855)(.421461)(.405528)(.871735)(.480916)
意思決定の方法
METHOD -.244241*** -.244241*** -.215550*** -.306080*** -.306080*** -.298662*** .104588.104588
問3B-1(.089004)(.080986)(.076037)(.109854)(.096486)(.094537)(.240463)(.132658)
信念・価値観の重視
SHIN.033426.033426.019562.058467.058467.080115.473186.473186***
問3B-2(6)(.117110)(.106561)(.098632)(.146506)(.128678)(.122381)(.275478)(.151975)
過去の成功体験の重視
SUC.313677*** .313677*** .301944*** .286815** .286815** .296856**-.218409-.218409
問3B-2(7)(.096150)(.087489)(.083428)(.138564)(.121702)(.117630)(.295886)(.163233)
過去の失敗体験の重視
FAIL-.026993-.026993-.039733-.046538-.046538-.062917.540829** .540829***
問3B-2(8)(.090315)(.082179)(.075227)(.121856)(.107028)(.100717)(.213395)(.117725)
直観の重視
INTU
-.201232* -.201232* -.175090*-.189755-.189755-.211789*.264691.264691
問3B-2(9)(.120446)(.109596)(.101104)(.151324)(.132909)(.127591)(.356558)(.196705)
プロジェクトメンバー意見の重視 INOPI.123220.123220.108656.035597.035597.039523-.212960-.212960
問3B-2(10)(.123330)(.112221)(.103408)(.156326)(.137303)(.130397)(.368971)(.203553)
プロジェクト外メンバー意見の重視 OUTOPI-.170308-.170308* -.170425*-.113154-.113154-.133300.459837.459837***
問3B-2(11)(.102457)(.093228)(.087000)(.132457)(.116338)(.111367)(.284221)(.156798)
カッコ内の値は標準偏差、Ｐ値<0.1：* Ｐ値<0.05：** Ｐ値<0.01：***

・プロジェクトの種類（問２－１-98.5569(110.209)
9.25123(9.34046)
38.1157(39.9564)-6.13252(5.44910)
13.9668(14.2065)
9.03088(8.66905)-21.7002(21.8474)-3.29681(3.64823)-12.1909(12.5740)
3.51000(4.04717)
1.42458(1.34819)-5.37416(6.23393)
6.53425(6.39132)
8.68965(9.55284)-7.81707(7.87159)
8.17429(8.58357)

変数名：PJ）

ＩＴプロジェクトには、手作り・パッケージによる業務処理システム開発、ソフトウェ
ア製品の開発、ネットワークなどのインフラ構築など様々な種類がある。プロジェクトの種類がプロジェクトの成否に影響を与えるのかどうかをみるのがこの質問である。
全数では有意となっている。これは、手作りによる業務処理システム開発よりも、ソフ
トウェア製品の開発や、ネットワークなどのインフラ構築、コンサルティングのほうが、プロジェクトの成功率が高まるという意味になる。しかし、手作りによる業務処理システ
ム開発・パッケージ適用による業務処理システム開発・組み込みシステムの開発の回答数
は約 90%を占めており、その他の回答の割合は小さい。件数の少ないインフラ構築やコン
サルティングがプロジェクトとして、たまたま成功した事例であったことも考えられる。
28

一方、Ａ社単独の場合は有意性が認められない。Ａ社単独では、インフラ構築は 3 件あるが、コンサルティングのプロジェクトやその他は０件である。全体でみても、インフラ構築・コンサルティング・その他のプロジェクトは数が少ない。そのため、プロジェクトの種類とプロジェクトの成否との間には関連がないと考えても問題ないと思われる。
・プロジェクトのピーク時の規模（問２－２

PJPEAK）

・プロジェクトにおける回答者の立場（問２－４
・回答者の当時の職位（問２－５

TITLE）

・回答者の当時の年齢（問２－６

AGE）

CLASS）

プロジェクトの規模、プロジェクトにおける回答者の立場、回答者の当時の職位・年齢が、プロジェクトの成否に影響を与えるのかどうかをみるのがこれらの質問である。
いずれも有意性を認められない。プロジェクトの成否は、規模や回答者の立場・役職・
年齢の影響を受けないということであるが、これは予想通りの結果となっている。
・回答者の当時のＩＴ業務経験年数（問２－７

EXPE）

プロジェクトマネージャ・プロジェクトリーダーのＩＴ業務経験年数が上がれば、プロ
ジェクトは成功するのかどうかをみるのがこの質問である。
Ａ社単独の場合のみ有意となっている。Ａ社の場合、入社後の経験年数が上がるにつれて多くの社員が、プロジェクトリーダー・プロジェクトマネージャを任されるようになる。
ＩＴ業務経験を積むにしたがって、プロジェクトリーダー、プロジェクトマネージャとしての経験とスキルが高まり、結果としてプロジェクトの成功確率が高まることにつながるものと思われる。全数で有意となっていないのは、Ａ社以外では、ＩＴ業務経験が長いからといって、必ずしもプロジェクトマネージャ・プロジェクトリーダーとしての経験を積んでいるわけではない、と解釈できるが、サンプル数が 23 件と少ないため断定できない。
・問題の発生したフェーズ（問３Ａ－１

PHASE）

問題の発生したフェーズが、プロジェクトの成否に影響を与えるのかどうかをみるのがこの質問である。問題の発生が、後のフェーズになればなるほど挽回する機会が少なくな
り、プロジェクトの失敗に結びつきやすいのではないかと想定していたが、回帰係数がマイナスの傾向を示してはいるものの、有意とはならなかった。
・問題発生時のプロジェクト規模（問３Ａ－２

KIBO）

問題発生時のプロジェクトの規模がプロジェクトの成否に影響を与えるのかどうかをみるのが、この質問である。
問題発生時のプロジェクトの規模が大きいほど、影響度も大きく、それだけ難しい意思決定を迫られることとなるので、プロジェクトの成功確率が下がるのではないかと想定していた。しかし、予想に反し、有意性はみられなかった。
・意思決定の方法（問３Ｂ－１

METHOD）

意思決定をおこなう際に、合議で決定するのか、プロジェクトマネージャ・プロジェク
29

トリーダーが独自で判断するのか、あるいは、上司や顧客に判断を委ねるのかによってプ
ロジェクトの成否に影響があるのかどうかについて調べる質問である。
これについては興味深い結果が得られた。回帰係数はマイナスであり、かつＡ社単独の場合の P 値は 0.002 と、非常に強い相関があることが示された。つまり、上司など、より大きな権限を持っている人・組織、顧客など異なる立場の人・組織に意思決定を委ねると、プロジェクトは失敗する可能性が高い、ということである。クリティカルな場面では意思決定の方法が合議であれ、独断であれ、発生している問題に直接関与している者が意思決定をすべきである、ということである。
・信念・価値観の重視（問３Ｂ－２(6)SHIN）

信念・価値観を重視して意思決定した場合、プロジェクトの成否に影響があるのかどうかをみるのがこの質問である。全体でもＡ社単独の場合でも、約 70%の回答者が自己の価値観を重視して意思決定をおこなった、との結果が出ているが、回帰分析の結果では、有意性は認められなかった。しかし Irwin& Baron(2001)が、「価値観が重要なのは、それが結果の良好さについてわれわれがおこなう最善の判断だからである。
（中略）結果についての最終的な判断が価値観である。」と述べるように、信念や価値観が意思決定に影響を与えているのに、プロジェクトの成否との関連がない、という結果は興味深い。
・過去の成功体験の重視（問３Ｂ－２(7)SUC）

有意であり、過去の成功体験を重視すればするほど、プロジェクトは成功するとの結果となった。アンケートの結果によれば、過去の成功体験を重視した割合は、約 50%と意外と少ない。ということは、プロジェクトマネージャやプロジェクトリーダーは、過去の成功体験をもっと意思決定に生かすべき、ということが言える。
・過去の失敗体験の重視（問３Ｂ－２(8)FAIL）

過去の成功体験を重視すればするほどプロジェクトは成功するのに対し、過去の失敗体
験の重視については有意性が認められず、意外な結果となった。常識的に考えれば、過去の失敗の教訓を生かし、プロジェクトを失敗に導くと思われる要因を取り除くことによって、プロジェクトの成功する確率は高まると考えられる。アンケートの結果でも、過去の失敗体験を重視した割合は、成功体験を重視する割合よりも高い。ところが、過去の失敗体験を重視しても必ずしもプロジェクトの成功に結びつくわけではない、ということは、
単にネガティブな要因を取り除くだけでは十分ではないか、もしくは、過去の失敗経験の応用が難しい新たな問題に直面することが多いのではないか、という解釈ができる。そのあたりにＩＴプロジェクトの難しさがあるのではないかと考えられる。
・直観の重視（問３Ｂ－２(9)INTU）

回帰係数はマイナスで有意であり、直観を重視すればするほどプロジェクトは失敗するという結果となった。これは、第２章の先行研究レビューにおいて紹介した、印南(1997, p.
41)や、Bonabeau(2003)が主張する通り、意思決定をおこなう際、直観に頼っては危険であるということを裏づけることとなった。
30

なお、同じく第２章で、直観の正体は、「経験によって発見され単純化された決定方法、
すなわちヒューリスティックス」であるという印南(1997, p. 37)の議論を紹介した。先の２つの「過去の成功体験の重視」「過去の失敗体験の重視」と、この「直観の重視」との違いは、前者は意思決定する際に、意識的に過去の成功・失敗体験を参照・吟味するのに対し、後者は決定過程を意識しない、という点である。
・プロジェクトメンバー意見の重視（問３Ｂ－２(10)INOPI）

有意性は認められず、予想外の結果であった。この結果に対する解釈であるが、個々のプロジェクトメンバーが発する意見は、自己の立場における問題解決に寄与するものであり、必ずしもプロジェクト全体を見渡した最適な意見を述べているとは限らない、ということになる。
・プロジェクト外メンバー意見の重視（問３Ｂ－２(11)OUTOPI）

Ａ社単独では、有意とならなかったが全数でみた場合は、回帰係数がマイナスで有意となっている。前述の意思決定の方法(METHOD)と同様に、発生している問題に直接関与していない人の意見を重視すると却って混乱を招く、ということになる。
以上の結果を表４－８に整理した。この結果を総合的にどのように解釈するのかについては、第５章で述べる。
表４－８
説明変数
変数
プロジェクトの種類
問2-1
プロジェクトのピーク時の規模
問2-2
プロジェクトにおける回答者の立場
問2-4
回答者の当時の職位
問2-5
回答者の当時の年齢
問2-6
回答者の当時のIT業務経験年数
問2-7
問題発生フェーズ
問3A-1
問題発生時のプロジェクト規模問3A-2
意思決定の方法
問3B-1
信念・価値観の重視
問3B-2(6)
過去の成功体験の重視
問3B-2(7)
過去の失敗体験の重視
問3B-2(8)直観の重視
問3B-2(9)プロジェクトメンバー意見の重視
問3B-2(10)
プロジェクト外メンバー意見の重視
問3B-2(11)その他の変数の分析結果まとめ
記号
PJ

有意性
なし

PJPEAK

なし

CLASS

なし

TITLE

なし

AGE

なし

EXPE

あり

PHASE

なし

KIBO

なし

METHOD

あり

SHIN

なし

SUC

あり

FAIL

なし

INTU

あり

INOPI

なし

OUTOPIなし

31

係数の符号 結果の意味するところ
プロジェクトの種類とプロジェクトの成否とは関係がない
プロジェクトのピーク時の規模とプロジェクトの成否とは関係がない
意思決定者がＰＭかＰＬかは
プロジェクトの成否とは関係がない
意思決定者の職位とプロジェクトの成否とは関係がない
意思決定者の年齢とプロジェクトの成否とは関係がない＋ 意思決定者のIT業務経験年数が長いほどプロジェクトは成功する
問題の発生したフェーズとプロジェクトの成否とは関係がない
問題発生時のプロジェクトの規模とプロジェクトの成否とは関係がない－ 発生している問題に直接関与している者が意思決定をすべきである
意思決定時に信念や価値観を重視してもプロジェクトの成否とは関係がない＋ 成功体験に基づいて意思決定することはプロジェクトを成功させる上で重要である
失敗体験を生かして意思決定してもプロジェクトの成否とは関係がない－ 直観に頼った意思決定を行うとプロジェクトは失敗する
プロジェクトメンバーの意見を重視してもプロジェクトの成否とは関係がない
プロジェクト外メンバーの意見の重視度はプロジェクトの成否とは関係がない

第５章
5.1

結論

要約

本研究の目的は、ＩＴプロジェクトのクリティカルな場面において、プロジェクトマネ
ージャやプロジェクトリーダーが、どのようなプロセスで意思決定をおこなっているかを明らかにすることであった。
アンケート調査による検証の結果、クリティカルな場面における、プロジェクトマネー
ジャ・プロジェクトリーダーの意思決定プロセスは、Tichy と Bennis のフレームワーク
における９つの STEP に準拠していることが判明した。
また、アンケートの結果から重回帰分析をおこない、プロジェクトの成否と、Tichy とBennis のフレームワークの各 STEP との関連を調べたところ、９つの STEP のうち、プロジェクトの成否と相関があったのは、「準備フェーズの STEP2」「準備フェーズのSTEP3」「実行フェーズの STEP2」「実行フェーズ STEP2 から実行フェーズ STEP1 への軌道修正の有無」の４つの STEP であった。
しかし、「準備フェーズの STEP3」「実行フェーズの STEP2」の２つの STEP については、マイナスの相関となった。さらに９つの STEP をひとつにまとめた説明変数と、プロジェクトの成否との間には、全く相関がみられなかった。
したがって、仮説「ＩＴプロジェクトの成否は、クリティカルな場面でおこなわれた意
思決定の、合理的な意思決定プロセスへの準拠度合いと関連がある。」は棄却された。
さらに、Tichy と Bennis のフレームワークの９つの STEP 以外にも、プロジェクトの成否と相関があるかどうかを調べた。結果、IT 業務の経験年数が長く、意思決定時において過去の成功体験を活用すればプロジェクトの成功に寄与し、逆に、意思決定を当事者がおこなうのではなく、上司や顧客などの他者に委ねたり、直観に頼った意思決定をおこな
うと、プロジェクトの成功の阻害要因になることが明確になった。
5.2

含意

本研究の結果、ＩＴプロジェクトのクリティカルな場面におけるプロジェクトマネージャ・プロジェクトリーダーの意思決定について、以下の２点があきらかになった。
①合理的と言われる意思決定プロセス18のうち、プロジェクトの成功に寄与するのは、プロセスの中の一部の STEP であること。
②意思決定をおこなう上で重要なことは、問題の本質を正確につかんで、当事者が意思決定をおこない、対応策の実行にあたっては、必要に応じて軌道修正しながら進めていくことである。
このことから、プロジェクトを成功に導く意思決定のプロセスは、①問題の本質を見極18

本研究では、Tichy と Bennis のフレームワークを指す。
32

める、②実行する、という２段階のシンプルなプロセスである、といえる（図５－１）。

意思決定プロセス
問題分析
フェーズ

実行フェーズ実行

問題の本質を
見極める

問題の発生

問題解決

結果の評価

図５－１

プロジェクトを成功に導く意思決定プロセス

ただし、判断フェーズについては、独立したフェーズとしての「判断フェーズ」が不要ということであって、意思決定そのものが不要ということではない。
「診断が正確で、問題が適切にかつ明瞭に定義されたならば、選択すべき解決策はほぼ決まっている」と、宮川( 2005, p. 59)が指摘するように、問題の本質をつかむ過程や、実行フェーズで軌道修正する場合など、それぞれのプロセスの中で同時並行的に意思決定がおこなわれる、と考えたほうが自然である。その他の STEP についても不要ということではなく、この２段階のプロセスを進めていくための選択肢を示していると考える。
たとえば、実行フェーズの STEP1 では、プロジェクトマネージャ・プロジェクトリー
ダーが自ら実行する、ということが重要であると指摘されている。しかし、実際のプロジ
ェクトでは、問題の性格と対応策の内容に応じて、もっとも最適と思われるメンバーが実行者として選ばれる。プロジェクトマネージャ・プロジェクトリーダーが最適の実行者であることもあれば、実行は別のメンバーに委ね、プロジェクトマネージャ・プロジェクト
リーダーは、サポート役という機能を果たすほうがよい場合もある。状況によっては、実行にまったく関与しないという選択もあるかも知れない。
なお、最も重要なことは、図５－１に示したプロセスにしたがって、意思決定をおこなったとしてもプロジェクトの成功を 100%保証するとは限らない、ということである。
クリティカルな場面では、順調なプロジェクトではありえないような体力的・精神的に厳しい状況が発生している可能性が高い。そのような状況でプロジェクトを冷静に運営し、成功に導くために、さらに重要な要素があると考えられる。付録２の、アンケートの自由
回答欄に記載されたコメントからわかることは、プロジェクトマネージャ・プロジェクト
リーダーは、「なんとしてもプロジェクトを成功させる」という強烈な意思のようなものを持ってクリティカルな場面に対峙しているということである。
このことは、Janis(1989)の「能力の限界まで頭脳労働にうちこむ努力」や、竹野内他(2002)の「プロジェクトリーダは、自分の進め方について「哲学」を持っておく必要がある。正解というものはないであろうが、「哲学」というほど強いものでなければ、メンバを引っ張り、難解なプロジェクトを成功させることはできない。」にも述べられている。
本研究では、この点について深く掘り下げることはできなかったが、今後研究を進めていく上で、考慮しなければならない重要な要素であると考えられる。
33

5.3

本研究の限界と課題

本研究における限界と課題は、次の３点である。
第一に、研究対象の限定性である。検証の対象は、「ＩＴプロジェクトのクリティカルな場面」に絞られている。ベースとしたフレームワークは、Tichy と Bennis のフレームワークのみである。回収したアンケートについても、有効回答 93 件のうちＡ社の回答が 70件であったため、分析もＡ社の回答が中心である。したがって、他の企業や他業種のプロ
ジェクトを分析対象にしたり、異なったフレームワークをベースに検証をおこなった場合
は、結果が異なる可能性がある。
第二に、最新のプロジェクトマネジメントの議論との整合性を必ずしもとっているわけではない、ということである。本研究で対象にした、ＩＴプロジェクトのクリティカルな場面での意思決定は、プロジェクトマネジメントの議論でいえば、「リスク管理」の領域に該当すると思われる。しかし、たとえば PMBOK19に述べられているリスク管理のプロセスとの整合性はとっていない。また、本研究では、プロジェクトの成功を、品質・納期・コストが意思決定時点の計画値を満たしているかどうかで定義しているが、P2M20のバリューマネジメントという概念は参照していない。これらの概念をとりいれた場合は、検証の方法が異なってくる可能性がある。
第三に、「1.1

研究の背景と問題意識」で述べたような、プロジェクトマネージャやプ

ロジェクトリーダーになるＩＴ技術者が、どのようなスキルを有しており、また、プロジ
ェクトを成功に導いた場合とそうでない場合とで、行動や思考プロセスには違いがあるのかという問には、回答できていないことである。その結果、ＩＴ企業にとって喫緊の課題である、プロジェクトマネージャやプロジェクトリーダーの育成にまで言及できていない。
今後、さらに研究を深めていくためには、上記の内容を考慮して適用範囲の拡大や、検証結果の信頼性の向上を高めていく必要がある。
以上

Project Management Body of Knowledge の略。アメリカの非営利団体 PMI(ProjectManagement Institute)が策定した、プロジェクトマネジメントの知識体系。(出典：IT 用
語辞典 e-words http://e-words.jp/)
20 Project & Program Management for Enterprise Innovation の略
経済産業省の委託を受けて、財団法人エンジニアリング振興協会が PMBOK などを基に日本の経営環境を考慮して開発した、プロジェクトマネジメントの標準ガイド。現在では特定非営利活動法人 日本プロジェクトマネジメント協会に引き継がれている。
19

34

【謝辞】
本研究を進めるにあたっては、多くの方々のご協力をいただいた。
まず、筆者の指導教官である、神戸大学大学院経営学研究科教授の原田勉先生からは、一年間にわたり多大なご指導をいただいた。特に、ゼミ配属初期の頃にいただいた助言は、筆者の研究の方向性を決定づけるものとなった。また、研究の成果を論文にまとめる段階
においては、定量分析の結果に対する筆者の解釈を、より深く掘り下げるための方法を示していただいた。未熟な筆者に対する、原田勉先生の忍耐強いご指導がなければ、本研究をまとめることは到底望めなかった。深く感謝の意を表したい。
次に、同じ社会人院生である原田ゼミ同期生の皆様の、研究に対する真摯な姿勢からは、
多くのことを学ばせていただき、研究を進める上で、様々な立場からの貴重な情報やご意見を何度も参考にさせていただいた。改めて感謝申し上げたい。
また、プレテストをはじめ、アンケートの配布・回収にあたっては、多忙にもかかわらず、多くの組織・ＩＴ技術者の皆様にご協力いただいた。深くお礼申し上げたい。
最後に、筆者の研究をサポートしてくれた家族に、この場を借りて、深く感謝したい。
2008 年 8 月
堀上 明【参考文献】
Eric Bonabeau(2003) Don't Trust Your Gut, Harvard Business Review, May, 2003（丘雄二訳「複雑系の意思決定モデル」『DIAMOND ハーバード・ビジネス・レビュー』 2003年９月号, 149-159 頁）
Alvar O. Elbing(1970), Behavioral Decisions in Organizations, Scott, Foresman & Co.
Alden M. Hayashi(2001) When Trust Your Gut, Harvard Business Review, February,
2001（森尚子訳 「直感の意思決定モデル」『DIAMOND ハーバード・ビジネス・レビュー』 2001 年６月号, 167-176 頁）
S.J.Hoch (2001) Combining Models with Instuition to Improve Decisions, in S.J.Hochand H.C.Kunreuther, eds., Wharton on Making Dcisions, The Whrton School（小林陽太郎監訳 黒田康史/大塔達也訳「直観とモデルを組み合わせて意思決定を向上させる」『ウォートンスクールの意思決定論』東洋経済新報社,2006 年,

99-119 頁）

堀上明(2001)「成功するチーム編成～ソフトウェア開発におけるチーム編成の考え方」（第２回 IT 論文発表セミナー『第２回 IT 懸賞論文集』竹野内情報工学研究所）
印南一路(1997)「すぐれた意思決定

判断と選択の心理学」中央公論社

印南一路(1999)「すぐれた組織の意思決定組織をいかす戦略と政策」中央公論新社
35

J.Irwin and J.Baron(2001) Values and Decisions,in S.J.Hoch and H.C.Kunreuther, eds.,

Wharton on Making Dcisions, The Whrton School（小林陽太郎監訳 黒田康史/大塔達也
訳「価値観と意思決定」『ウォートンスクールの意思決定論』東洋経済新報社,2006 年,
270-286 頁）
Irving L. Janis (1989) Crucial Decisions, New York: Free Press（首藤信彦訳「リーダーが決断する時危機管理と意思決定について」日本実業出版社，1991 年）

Karen A. Jehn and Keith Weigelt (2001) Reflective versus Expedient Decision Making:Views from East and West, in S.J.Hoch and H.C.Kunreuther, eds., Wharton on Making

Dcisions, The Whrton School（小林陽太郎監訳 黒田康史/大塔達也訳「よく考えられた意
思決定 vs ご都合主義の意思決定：東洋と西洋の視点」『ウォートンスクールの意思決定論』
東洋経済新報社,2006 年,

120-133 頁）

情報処理振興事業協会(2002)「EVM 活用型プロジェクト・マネジメント導入ガイドライン」情報処理振興事業協会
Charles H. Kepner and Benjamin B. Tregoe, The New Rational Manager, Princeton
Research Press, 1981. (上野一郎監訳｢新・管理者の判断力｣産業能率大学出版部, 1985 年)
古宮誠一(1998)「WWW 上で行われるソフトウェア障害対策作業への KT 法の導入とその改良」『電子情報通信学会論文誌』Vol. J81-D-2,

No.5

松尾谷徹(2004)「IT-プロジェクトにおけるヒューマンファクタと組織行動の課題」プロジェクトマネジメント学会誌 Vol. 6

No. 2, 3-8 頁

H.Mintzsberg,The Nature of managerial Work,New York:Harper & Row,1975.（奥村哲史・須貝栄訳「マネジャーの仕事」白桃書房, 1993 年）
三井・石津(1998)「ソフトウェア開発におけるプロジェクト戦略決定のための意思決定支援システム」電子情報通信学会技術研究報告 Vol.98, No.6(19980418)
宮川公男(2005)「意思決定論

pp. 9-16

基礎とアプローチ」中央経済社

長瀬勝彦(2003)「組織的意思決定に関する実験的研究方略の再構築」『組織科学』Vol.37
No.1, 44-55 頁
長瀬勝彦(2004)「意思決定のマネジメント

意思決定と合理性」『一橋ビジネスレビュー』

2004Winter, 104-115 頁

36

長瀬勝彦(2005)「意思決定のマネジメント

データの収集と解釈のバイアス」『一橋ビジネスレビュー』2005Spring, 88-98 頁
中丸学・八重樫理人・中村恵一・井戸孝昭・古宮誠一(2005)「KT 法を用いたソフトウェ
ア開発プロジェクトのリスク分析支援」『情報処理学会研究報告』Vol.2005, No.3, pp. 7-12
中村建助・矢口竜太郎(2003)「プロジェクト成功率は 26.7％

2003 年情報化実態調査」『日

経コンピュータ』2003 年 11 月 17 日号 50-71 頁
中西晶(2007)「高信頼性組織の条件」生産性出版
日本プロジェクトマネジメント協会(2007)「新版 Ｐ２Ｍプロジェクト＆プログラムマネジ
メント標準ガイドブック」日本プロジェクトマネジメント協会
Michael A. Roberto(2005) Why Great Leaders Don't Take Yes for an Answer, New
Jersey: Wharton School Publishing（スカイライトコンサルティング訳「決断の本質」英治出版, 2006 年）
鈴木秀一(2006)「なぜ組織は戦略を実行しないのか－限定合理性と組織モデル－」『立教経済研究』第 60 巻第 1 号, 117-146 頁
高多清在(1987)「鋭い管理職・意思決定のＫＴ法」実業之日本社
竹野内勝次・久井信也・渡部英男(2002)「SE のためのプロジェクト管理心得ノート」日刊
工業新聞社
Noel M. Tichy and Warren G. Bennis(2007a) Making Judgment Calls, Harvard

Business Review, Octber, 2007（有賀裕子訳 「決断と実行のリーダーシップ」『DIAMOND
ハーバード・ビジネス・レビュー』 2008 年 3 月号, 122-134 頁）
Noel M. Tichy and Warren G. Bennis (2007b) Judgment: How Winning Leaders Make

Great Calls, New York: Portfolio
渡邉晶子(2007)「意思決定のアンカリング分析モデルの構築－情報システム構築の失敗プ
ロジェクトへの適用」早稲田大学大学院商学研究科 2006 年度修士論文（概要）
楊子明・上市秀雄・深町珠由・中川正宣(2003)「意思決定における認知構造の日中比較研
究 : ＩＴプロジェクトマネジメントの現場調査」プロジェクトマネジメント学会研究発表
大会予稿集, Vol.2003（春季）37【付録１】アンケート用紙
２００８年５月２１日

ＩＴプロジェクトにおけるリーダーの意思決定行動に関する調査ご協力のお願い
神戸大学大学院 経営学研究科
原田研究室
堀上 明
私は神戸大学大学院・社会人ＭＢＡプログラム（注１）において、ＩＴプロジェクトにおけるリーダーの意思決定行動の研究をおこなっています。
研究を進めるにあたり、ＩＴプロジェクトのプロジェクトマネージャ、プロジェクトリーダー経験者である
みなさまを対象にアンケートを行い、プロジェクトのクリティカルな場面（注２）における、リーダーの意思決定行動について分析しようと考えています。
アンケートは、質問が約５０問ありますが、そのほとんどは多肢選択式で、プルダウンリストから回答を選んでいただく形式になっており、２０分程度の回答時間を想定しています。
いただいた回答は研究目的以外に使用することはありません。また、アンケートは無記名で、回答は統計的に処理され企業や個人が特定されることもありません。
なお、回答していただいた方には、お礼として研究結果の要旨を後日お送りさせていただきたいと考えております。
お忙しい中、誠に恐縮ですが、以下に続くアンケートに回答していただき、返送していただけましたら幸いです。
■ アンケート対象者：ＩＴプロジェクトのプロジェクトマネージャ、プロジェクトリーダー経験者
委託側、受託側などの立場は問いません。
ＩＴプロジェクトの種類（組込系、業務系、インフラ系など）も問いません。
■ アンケート回答の要領：
・ すでに終了しているプロジェクトについて、あなたがプロジェクトマネージャまたは、
プロジェクトリーダーの立場で行った意思決定の場面を思い出して回答してください。
・ このアンケートにおける「プロジェクト」の範囲は、プロジェクト体制図に示されている、プロジェクトマネージャまたは、プロジェクトリーダーが受け持つ責任の範囲、という想定をしています。
たとえば、あなたがＩＴベンダー側のプロジェクトリーダーであった場合は、お客さま側のプロジェクト体制があなたの責任範囲として、プロジェクト体制図に記載されることは通常はないと想定できます。
逆に、あなたがユーザー側（つまり委託側）のプロジェクトリーダーであった場合は、
ＩＴベンダー側のプロジェクト体制もあなたの責任範囲として、プロジェクト体制図に記述されているならば、ＩＴベンダー側のプロジェクトも範囲に含むことになります。
判断が難しければ、あなたが自己の責任範囲と認識できる範囲という理解で結構です。
・ 選択肢の中に、該当する回答がなかった場合は、もっとも近いと思われる選択肢を選んで回答してください。
■ 回答希望期限：２００８年６月９日（月）■ 返送先：神戸大学大学院経営学研究科 堀上 明宛に、電子メールで返送してください。
返送先電子メールアドレス： horikami@stu.kobe-u.ac.jp
注１） 神戸大学大学院・社会人ＭＢＡプログラム：

http://mba.kobe-u.ac.jp/

注２） クリティカルな場面の例：
このまま放置すると納期遅れ・赤字・品質不良等、ＰＪの失敗が見えている。
しかし、対策を検討する時間は限られており、予断を許さない状況。
すばやく決断し結果を出さねばならない。
もし、今回の意思決定で失敗したら挽回できないかも知れない。
必ずしも、厳密な定義ではありません。「プロジェクトの緊急事態」という解釈で結構です。

38

ＩＴプロジェクトにおけるリーダーの意思決定行動に関するアンケート
１．あなたの職務経歴等について、下記の質問にお答えください。
問１-1

勤務先の業種を下記の中から選び、回答欄に番号でご記入ください。

1-1回答欄⑳その他の場合①農林／水産／鉱業 ②建設 ③不動産 ④製造 ⑤商社 ⑥流通／小売⑦金融／証券／保険 ⑧運輸 ⑨エネルギー ⑩通信 ⑪情報処理／ソフトウエア⑫ＳＩ・コンサルティング ⑬専門サービス（弁護士／会計士など） ⑭その他サービス⑮教育／研究機関 ⑯医療機関／介護施設 ⑰政府／官公庁 ⑱地方公共団体⑲各種団体・組合 ⑳その他
問１-2

勤務先の従業員数を下記の中から選び、回答欄に番号でご記入ください。

1-2回答欄

問１-3①100人未満 ②100人～999人 ③1000人～4999人④5000人～9999人 ⑤10000人以上

現在の勤務先への入社年月を回答欄に西暦でご記入ください。

1-3回答欄年
問１-4①会長・社長⑤課長クラス②役員 ③本部長クラス ④部長クラス⑥係長・主任クラス ⑦担当者 ⑧その他

２００８年４月１日時点の職位を下記の中から選び、回答欄に番号をご記入ください。

1-5回答欄

問１-6（半角数字でお答えください）

現在の勤務先への入社当時の職位を下記の中から選び、回答欄に番号をご記入ください。

1-4回答欄

問１-5

月①会長・社長⑤課長クラス②役員 ③本部長クラス ④部長クラス⑥係長・主任クラス ⑦担当者 ⑧その他

あなたがプロジェクトマネージャまたはプロジェクトリーダーの立場でクリティカルな場面での意思決定をおこなった経験の有無を下記の中から選び、回答欄に番号をご記入ください。

1-6回答欄①あり（引き続き、以下の質問にお答えください）②なし（アンケートは終了です。ありがとうございました。）

２．ここから先の質問は、問１－６で、「①あり」とお答えいただいた方について、
クリティカルな場面での意思決定についてお答えください。
なお、あなたがクリティカルな意思決定をおこなった経験が複数ある場合は、その中で特に印象に残っている意思決定についてお答えください。
もし複数の意思決定について回答していただける場合は、お手数ですが、
当アンケート用紙をコピーしていただき、それぞれについて、分けて回答してください。
問２-1

該当プロジェクトの種類を下記の中から選び、回答欄に番号をご記入ください。

2-1回答欄⑦その他の場合①手作りによる業務処理システム開発 ②パッケージ適用による業務処理システム開発③組み込みシステムの開発 ④ソフトウェア製品の開発⑤ネットワークなどのインフラ構築 ⑥コンサルティング ⑦その他

39

問２-2

該当プロジェクトのピーク時の人数を下記の中から選び、回答欄に番号をご記入ください。

2-2回答欄

問２-3③５０人以上５００人未満

該当プロジェクトでの、クリティカルな意思決定をおこなった時期を回答欄に
西暦年月でご記入ください。

2-3回答欄
西暦
問２-4①１０人未満 ②１０人以上５０人未満④５００人以上

年月ごろ（半角数字でお答えください）

該当プロジェクトで、クリティカルな意思決定をおこなった場面におけるあなたの立場を、
下記の中から選び、回答欄に番号をご記入ください。

2-4回答欄③その他の場合①プロジェクトマネージャ
問２-5①会長・社長⑤課長クラス②役員 ③本部長クラス ④部長クラス⑥係長・主任クラス ⑦担当者 ⑧その他

該当プロジェクトでの、クリティカルな意思決定をおこなった当時のあなたの年齢を、下記の中から選び回答欄に番号をご記入ください。

2-6回答欄

問２-7③その他

該当プロジェクトで、クリティカルな意思決定をおこなった場面におけるあなたの職位を、下記の中から選び、回答欄に番号をご記入ください。

2-5回答欄

問２-6②プロジェクトリーダー①２０歳未満 ②２０歳～２４歳 ③２５際～２９歳 ④３０歳～３４歳 ⑤３５歳～３９歳⑥４０歳～４４歳 ⑦４５際～４９歳 ⑧５０歳～５４歳 ⑨５５歳～５９歳 ⑩６０歳以上

該当プロジェクトでの、クリティカルな意思決定をおこなった当時におけるあなたのＩＴ関連業務の経験年数を下記の中から選び、回答欄に番号をご記入ください。

2-7回答欄①３年未満 ②３年以上・５年未満 ③５年以上・１０年未満④１０年以上・２０年未満 ⑤２０年以上・２５年未満 ⑥２５年以上

３．あなたがクリティカルな意思決定をおこなった当時の状況についてお伺いします。
３－Ａ 問題の発見時の状況について
問３A-1 クリティカルな問題はどの開発フェーズで発生しましたか。該当するフェーズを
下記の中から選び、回答欄に番号をご記入ください。
3A-1回答欄⑪その他の場合①システム提案 ②要件定義 ③基本設計 ④詳細設計 ⑤プログラム設計⑥単体開発 ⑦結合テスト ⑧システムテスト ⑨システム移行 ⑩システム保守⑪その他
問３A-2 その問題が発生した時点のプロジェクトの規模を下記の中から選び、回答欄に番号をご記入ください。
3A-2回答欄①１０人未満 ②１０人以上５０人未満④５００人以上

40③５０人以上５００人未満

問３A-3 その問題が発生した時に、以下のことを行ったかどうかについて
下記の中から選び、回答欄に番号をご記入ください。
（１）問題の原因の特定
3A3（１）回答欄①特定した②特定しなかった（２）その問題をもし解決できなかった場合、どのような事態が生じるかの予測（たとえば、納期遅延、コストオーバー、品質不良など）
3A3（２）回答欄①予測した②予測しなかった（３）問題の内容を文書化し、関係者に配布したか
3A3（３）回答欄①文書化し、配布した②文書化しなかったまたは、文書化したが配布しなかった

問３A-4 その問題が顕在化する前に、事前に兆候があったかどうか
下記の中から選び、回答欄に番号をご記入ください。
3A-4回答欄①事前に兆候があった②事前に兆候はなかった

問３A-4(2) 事前に兆候があった（問３A-4で①を選択した）場合にお答えください。
問題の兆候を発見した時、どのような措置をとりましたか？
下記の中から選び、回答欄に番号をご記入ください。
3A4(2)回答欄⑤その他の場合①無視した ②とりあえず様子を見た ③情報収集のみおこなった④情報収集し、対策をとった ⑤その他
問３A-5 問題解決のための情報収集や解決策の検討を、誰に相談して行ったかについて、下記の中から選び、回答欄に番号をご記入ください。
（１）プロジェクトのコアメンバー
3A5(1)回答欄①相談した②相談しなかった（２）コアメンバー以外のプロジェクトメンバー
3A5(2)回答欄①相談した②相談しなかった①相談した②相談しなかった（３）顧客
3A5(3)回答欄

41

（４）役員、上司、営業担当者などのプロジェクト外の関係者
3A5(4)回答欄①相談した②相談しなかった（５）ＰＭＯ、技術部などの他部門
3A5(5)回答欄①相談した②相談しなかった

問３A-6 問３A-5（１）～（５）の各メンバー・部門に相談した結果、問題の本質への認識を見直すようなことがあったかどうかについて、下記の中から選び、回答欄に番号をご記入ください。
3A-6回答欄①見直した結果、認識を訂正した②見直したが、認識は訂正しなかった（または訂正する必要はなかった）③見直しをしなかった

３－Ｂ 問題に対する意思決定を下した時の様子について
問３B-1 意思決定をどのようにおこなったかについて下記の中から選び、回答欄に番号をご記入ください。
3B-1回答欄⑥その他の場合①関係者による合議（全員一致） ②関係者による合議（多数決） ③あなたの独断④上司など、社内の自分より権限の大きい人・組織からの指示 ⑤顧客からの依頼⑥その他
問３B-2 意思決定をおこなったとき、以下の項目を重視したかどうかについて
下記の中から選び、回答欄に番号をご記入ください。
（１）意思決定の内容のわかりやすさ
3B2（１）回答欄①非常に重視した ②重視した ③どちらかといえば重視した④どちらかといえば重視しなかった ⑤重視しなかった ⑥意識しなかった（２）意思決定の内容の実行可能性
3B2（２）回答欄①非常に重視した ②重視した ③どちらかといえば重視した④どちらかといえば重視しなかった ⑤重視しなかった ⑥意識しなかった（３）意思決定による結果の成功確率
3B2（３）回答欄①非常に重視した ②重視した ③どちらかといえば重視した④どちらかといえば重視しなかった ⑤重視しなかった ⑥意識しなかった（４）意思決定の内容の合理性・納得性
3B2（４）回答欄①非常に重視した ②重視した ③どちらかといえば重視した④どちらかといえば重視しなかった ⑤重視しなかった ⑥意識しなかった42

（５）意思決定のスピード①非常に重視した ②重視した ③どちらかといえば重視した④どちらかといえば重視しなかった ⑤重視しなかった ⑥意識しなかった

3B2（５）回答欄（６）自己の信念・価値観①非常に重視した ②重視した ③どちらかといえば重視した④どちらかといえば重視しなかった ⑤重視しなかった ⑥意識しなかった

3B2（６）回答欄（７）過去の成功体験①非常に重視した ②重視した ③どちらかといえば重視した④どちらかといえば重視しなかった ⑤重視しなかった ⑥意識しなかった⑦類似の過去の成功体験なし

3B2（７）回答欄（８）過去の失敗体験①非常に重視した ②重視した ③どちらかといえば重視した④どちらかといえば重視しなかった ⑤重視しなかった ⑥意識しなかった⑦類似の過去の失敗体験なし

3B2（８）回答欄（９）自己の直感
3B2（９）回答欄①非常に重視した ②重視した ③どちらかといえば重視した④どちらかといえば重視しなかった ⑤重視しなかった ⑥意識しなかった（１０）プロジェクトメンバーの意見
3B2（10）回答欄①非常に重視した ②重視した ③どちらかといえば重視した④どちらかといえば重視しなかった ⑤重視しなかった ⑥意識しなかった（１１）プロジェクトメンバー以外の意見
3B2（11）回答欄①非常に重視した ②重視した ③どちらかといえば重視した④どちらかといえば重視しなかった ⑤重視しなかった ⑥意識しなかった

問３B-3 問３B-2であげた（１）から（11）の選択肢について、最も重視したもの上位３つを下記の中から選び、回答欄に番号をご記入ください。
3B3回答欄

１つ目⑫その他の場合

3B3回答欄

２つ目⑫その他の場合

3B3回答欄

３つ目⑫その他の場合①わかりやすさ ②実行可能性 ③成功確率 ④合理性・納得性 ⑤スピード⑥信念・価値観 ⑦成功体験 ⑧失敗体験 ⑨直感 ⑩プロジェクトメンバーの意見⑪プロジェクトメンバー以外の意見 ⑫その他

43

問３B-4 意思決定の内容や理由の説明を、どの範囲に行ったかについて下記の中から選び、回答欄に番号をご記入ください。
（１）プロジェクトのコアメンバー
3B4（１）回答欄①説明した②説明しなかった（２）コアメンバー以外のプロジェクトメンバー
3B4（２）回答欄①説明した②説明しなかった①説明した②説明しなかった（３）顧客
3B4（３）回答欄（４）役員、上司、営業担当者などのプロジェクト外の関係者
3B4（４）回答欄①説明した②説明しなかった（５）ＰＭＯ、技術部などの他部門
3B4（５）回答欄①説明した②説明しなかった

問３B-5 意思決定してから実行するまでの間に、決定事項の妥当性を再度見直すことがあったかどうかについて下記の中から選び、回答欄に番号をご記入ください。
3B-5回答欄①見直した結果、決定内容を変更した②見直したが、決定内容は変更しなかった（または変更する必要がなかった）③見直しをしなかった

３－Ｃ 意思決定の内容の実行について
問３C-1 意思決定の内容を実行する際に、あなたがどのように関与したかについて
下記の中から選び、回答欄に番号をご記入ください。
3C-1回答欄⑤その他の場合①自ら先頭に立って実行した ②自ら実行はしなかったが陣頭指揮をとった③自らは実行せず、指揮も他のメンバーに任せたが、実行のサポートをおこなった④実行には関与しなかった ⑤その他
問３C-2 意思決定の内容を実行する際に、中間目標を設定したかについて
下記の中から選び、回答欄に番号をご記入ください。
3C-2回答欄①設定した ②設定する必要がなかった③設定する必要があったが、設定しなかった

44④設定するという認識がなかった

問３C-3 意思決定の内容を実行する際に、達成すべき成果の最低ラインを設定したかについて
下記の中から選び、回答欄に番号をご記入ください。
3C-3回答欄①設定した ②設定する必要がなかった③設定する必要があったが、設定しなかった④設定するという認識がなかった

問３C-4 実行のための中間目標や成果の最低ライン達成の状況を、どのような方法で確認したかについて下記の中から最も重視したものをひとつ選び、回答欄に番号をご記入ください。
3C-4回答欄①自分の目で確認した ②実行部隊からの報告を定期的に求めた③実行部隊とは別の立場のメンバーの意見を聞いた④上記①②③とは別の方法で確認した ⑤必要なかったので確認しなかった⑥確認する必要があったが確認しなかった ⑦確認するという認識がなかった

問３C-5 実行のための中間目標や成果の最低ライン達成の状況が、設定した期待値を下回っていることがわかったときに、どのようにしたかを下記の中から選び、回答欄に番号をご記入ください。
（達成状況が期待値通りまたはそれ以上であった場合は②を選択してください）
3C-5回答欄①実行する内容や方法を見直して軌道修正した②軌道修正する必要はなかった③軌道修正する必要があったが、そのまま遂行した④軌道修正という認識がなかった

４．意思決定によってプロジェクトにどのような結果をもたらしたかをお答えください。
問４-1 品質面について得られた結果について下記の中から選び、回答欄に番号でご記入ください。
4-1回答欄問４-2

納期面について得られた結果について下記の中から選び、回答欄に番号でご記入ください。

4-2回答欄

問４-3①意思決定時点の計画値以上の成果を得た②意思決定時点の計画通りの成果を得た③意思決定時点の計画を下回ったが、容認できる成果は得た④意思決定時点の計画を下回り、結果も容認できるものではなかった①意思決定時点の計画値以上の成果を得た②意思決定時点の計画通りの成果を得た③意思決定時点の計画を下回ったが、容認できる成果は得た④意思決定時点の計画を下回り、結果も容認できるものではなかった

コスト面について得られた結果について下記の中から選び、回答欄に番号でご記入ください。

4-3回答欄①意思決定時点の計画値以上の成果を得た②意思決定時点の計画通りの成果を得た③意思決定時点の計画を下回ったが、容認できる成果は得た④意思決定時点の計画を下回り、結果も容認できるものではなかった

５．もしよろしければ、今回のアンケートの内容に関する感想・ご意見、あるいは意思決定に関して何かお考えをお持ちであれば、お書きください。

アンケートは以上です。回答に抜けや誤りがないか、念のため、ご確認ください。
ご協力ありがとうございました。

45

【付録２】アンケートの自由回答欄に記載されたコメント(1)意志決定において一番大切な事は、リーダーの報告を鵜呑みにしない正しい情報である。
(2)プロジェクトの収束局面における要員削減計画変更に関わる意思決定について回答させて頂きました。
(3)振り返ると、意思決定の内容の実行に際しては、ただひたすらに実行するのみだった記
憶がありますが、中間目標をたてるという考え方もあるのかと考えさせられました。
(4)意思決定にあたり、リーダーが強い態度・意志を示さないとメンバーはついてきてくれません。私の場合、はったりでも何でも、断固たる姿勢を示したことで成功することが出来たと考えています。
(5)プロジェクトを成功させる最も大切なことは、お客さまの業界や業務に関する知識があり、お客さま側のＩＴ化に対する問題点・課題・解決策をキチンと理解していることである。失敗事例ではこの視点が欠けており、お客さまの要求仕様をうのみにして問題点・課
題の背景まで深掘りせず、サブシステムごとの重要性をＰＭやＰＬ21が理解していない。
ただ、同一業界・業種のシステム構築は、１回目や２回目では失敗することも多い。失敗の経験を生かして３回目以降に成功できるように導いてやることも配慮してほしい。
(6)プロジェクト運営上の有事の意思決定では以下を考慮するようにしています。
・有事（クリティカルな局面、沼地）を的確に捉えること・既存組織形態に対してふさわしいリーダーシップを決定すること・有効な対策をスピーディに実行すること（合理性・納得性＞スピード＞自己の信念・価値観）(7)自己の信念・価値観については賛否両論と思いますが、カラーのあるリーダーでありた
いと思っています。
(8)コアメンバーの意見を尊重し、合意を得た上でプロジェクトの遂行をおこないます。
(9)「リーダーの性格・意思決定の傾向・結果の良否」を把握することができれば、リーダ
ー任命時の判断に役立つのではないかと考えています。
(10)意思決定においては、会社（上司）の方針が最優先されると思います。その方針が揺らいだりすることが無いように、上司の承認を何度も取りつける必要があると思います。
また、顧客に対しては分かり易い説明、相手の立場への配慮が必要と考えています。
21

ＰＭ：プロジェクトマネージャ

ＰＬ：プロジェクトリーダー
46

(11)緊急時におけるＰＭ，ＰＬとしての意思決定は、多くの人が自己流である場合が多い。
これは、教育対象として取り上げられることが少なく、取り上げるのも難しいからだと考える。リーダー研修等で取り上げられることもあるが、ケース例が現実的でないことが多く参考にならない。他のＰＭ，ＰＬの体験談を聞いてみたいと思う。
(12)クリティカルな場面で自分の意思決定をおこなう際、やはり重要なのは正しく現状認
識をおこなうことだと思います。また意思決定と言っても頼りになるのは他のＰＭや上司、他部署有識者の参考意見です。日頃から人脈を大切にすることも肝要と思います。
(13)「意思決定におけるＰＭの振る舞いは抽象化できる」を仮説として検証をしてみたい。
(14)クリティカルなケースでは危機管理セオリーに収斂していくような気がしてならない。
(15)今回のアンケートは過去の大型プロジェクトにリーダとして参画していたときにおこなった「受注範囲の削減」の意思決定を念頭に記入しました。お客様から 150 人の要員投入を要望されましたが、体制の脆弱さから 100 人まで投入し、それを超える分は同業他社の参入ということにしたものです。
(16)営業の反対を押し切って、人数を制限したことが良い結果に結びついた。
(17)緊急事態など発覚した段階で、直ちにその情報を開示し、なるべく多くの関係者とともに解決に当たっていくことが事態の収束に繋がるのではと思っています。
(18)意思決定は SPI,CPI22の傾向・リスク分析を基に判断するのですが、最終的にはＰＭの『胆力』が必要となる。IPA23の笑力研究会が報告書を WEB に掲載しております。
(19)今回例に挙げた、品質改善の意思決定においては、現状の分析のためにメンバーへのヒアリングはおこないましたが、対策に関しては相談等はおこなっていません。別プロジ
ェクトの意思決定の局面では、コアメンバーに対策の相談をすることもあります。
(20)当時は PMO24の体制も無く、プロジェクト管理技法も今のように参考書のようなものが無かったと記憶しています。

プロジェクトの進捗度合いを管理する手法である、EVM(Earned Value Management)の中で用いられる指標。
SPI(Schedule Performance Index：スケジュール効率指数)は、スケジュールの進捗度合いを表す指標で、CPI(Cost Performance Index：コスト効率指数)は、計画に対するコストの消化度合いを表す指標。
23 独立行政法人「情報処理推進機構」
24 プロジェクトマネジメントオフィス：プロジェクトが円滑に進行するように支援する組織。プロジェクトチームとは別の組織として編成される。
22

47

(21)意思決定できる立場にある人は、周囲の意見を聞くことも必要だが、簡単に同調せず、自身の確たる意志を持ち合わせていることが大切である。
(22)現場におけるリーダとしては、多くに断面においてボリュームは違うにしろ、意思決定を求められます。その際に、問３Ｂ－３が重要になると考えます。何を優先するかです。
もちろん、全てが満足させられればいいのですが。各局面において、優先順位が変わってきます。また、意思決定の判断材料として、ビジネス面での要因が絡むことがあるのではないでしょうか。(収益性、事業としての拡大展望、など)(23)意思決定は突然おこなうものではなく、ステークホルダーとの連携を常にとり、最良ではなくても現時点での判断を常に持っている必要があると感じる。その局面になった時から考えていては後手の施策しかおこなえない。スピードは重要であると思う。
(24)兆候が見えた段階で早めの対処をおこなうのが客先の通例であるため、今まで経験した開発では大事に至る前に問題解決をしてきたことが大半です。
(25)各アンケート項目に、クリティカルな局面でとるべき行動のチェック項目として認識すべきものが多くありましたので、今後の業務に活用させていただきます。
(26)プロジェクトの関わり方として、当事者であればあるほど意思決定内容がメンバーに十分説明できているかどうかが客観的に見えないと思う。その点に難しさを感じている。
(27)意思決定に人の意見を重要視するパターンと、リーダーもしくはマネージャの信念で押し進めた場合の、スピードや成功率との関係には興味があります。個人的には、周囲の意見を真摯に受け止め取り入れ、意思決定に役立てることはとても重要だと思いますが、事態が逼迫している状況でメンバー全員の意見が一致することなど稀なので、その場合はスピードとわかりやすさを重視し、独断でも押し進め、途中経過が間違っていないかをメンバー等からチェックしてもらう方法がベターだと思っています。
(28)開発フェーズの意思決定についてはリーダーの判断で進めていくことが望ましいと思われるが、今回はトラブルシューティングにおける意思決定だったため、ステークホルダ
ーの意見を十分に考慮しながら、失敗の許されない意思決定を行なった。意思決定ひとつ
とっても、場面場面で使い分けるべきと思われる。
(29)該当案件の当初見積もりに対する妥当性の評価不足、また、当初見積もった工数から、さらに他社との競り合いで受注する際の戦略の甘さが発端であると感じる。見積もりの精度の向上、及びお客様との相互理解のプロセスが重要と感じた。
(30)現在、私は Web サービスシステムの開発・運用保守に携わっています。Web サービス
は、一般のユーザ(登録したお客さま)に開放されており、高い可用性が要求されます。ま48

た障害が発生した場合も、復旧までのスピードが重要になります。よって私の携わるプロジェクトでは、一定の水準を確保できるのであれば、より速く確実に対応できる方法であることが、意思決定の重要な要素になっています。
(31)上記に書いたプロジェクトは、実際に今思えば、意思決定が必要な局面だったと思い返せますが、当時は、必要に応じて対策を打っていた、という印象です。プロジェクト内部では、リカバリーモードに入ります、という宣言をおこないましたが、社内、顧客も含
めて、同じレベルで認識できてなかった部分もあり、その辺を効率的におこなうことが出来れば、もっと適切なサイクルをまわせたのではないかと思います。
(32)今回のアンケートの対象にした場面は，「システム方式」に係る意思決定です。顧客から提示された方式では，要求されている機能の実現や納期・コストの維持が困難と判断し，コアメンバーと協議した上で，顧客と交渉を持ち，システム方式を変更しました。
(33)この回答をしたプロジェクトは、新事業の立ち上げを伴うもので、品質・コスト・納期以上に、構築する基幹システムの価値に関する議論が非常に重視されました。今後の情報システム開発はＩＴ投資マネジメントの観点から、当該システムの価値をどう把握し改善するかが、意思決定の重要な要素になると考えます。
(34)最近のもっとも大きい意思決定を頭に思い浮かべながら回答しましたが、意思決定の対象に何を選ぶかによって回答が大きく変わるような気がします。
(35)やはり、何事も経験が重要であると実感している。
(36)今回回答したケースでは、時間的に非常にタイトな状況での意思決定を迫られました。
時間的な余裕によっては、相談した相手などの状況も変わっていたと思います。
(37)顧客がＩＴに関する専門家でない場合の情報システムの導入時は、意思決定の内容を理解してもらうというのが重要だと思われます。あとは、品質だけでなくスピードというのも無視できない要件のひとつと思います。
(38)意思決定において、トップダウンとボトムアップのバランス（比重）が会社・組織ごとに異なる。そのバランス（比重）がプロジェクトリーダーの行動へ影響を及ぼす大きな要因となると思われる。
(39)ＩＴプロジェクトにとって迅速な意志決定は必要不可欠である。意志決定が遅延する
ようでは、プロジェクトはうまくいかない。なお、意志決定する場合は、プロジェクトの鍵を握るメンバー（プロジェクト、顧客、ベンダー）の参画が必要である。また、意志決定する場合は、内容の有効性、実現可能性、コスト・品質・納期に関するリスク分析を実施し、リスクの大きさに応じた対応が必要。もし、実現性のリスクが高ければプロトタイ
49

プを作る、コストが高くなれば他の機能を削減するなど、リスクに応じた対策を迅速に実施しなければならない。
(40)問４－３は、顧客から見ると①ですが、当社から見ると④という結果です。そのような結果を伴う意思決定を求められた、という局面でした。
(41)ERP25導入プロジェクトでは顧客～SI26ベンダーの関係というより、顧客と一体となってチームを形成するので、意思決定の各プロセスにおいて顧客との協業（調査、分析、対応案作成、検討）が発生します。
(42)意志決定には、関係者の巻き込みが大切だと常々考えています。
(43)今にして思えば、顧客のリーダーシップに依存していたと思う。
(44)ＰＭの意思決定のあり方は、一様でないことが多くあります。上の例では意思決定の有効性について合意形成を重視しましたが、独断で意思決定する場合も、根回しのようなことをする場合も日常的にあります。
(45) Ｂ大学のコンサル担当が稼働を遅らせるべきだと主張してきた。しかし、お客さまやコンサルを説得して無事１月より本稼動させた。
(46) 「プロジェクトと心中したくない！」という 一念で、最低限の要求レベルをターゲットにプロジェクトをドライブさせました。結果は（少々の赤字も含めて）プロジェクト
を予定どおり終了させることができました。

Eenterprise Resource Planning の略。企業全体を経営資源の有効活用の観点から統合的に管理し、経営の効率化を図るための手法・概念のこと。「企業資源計画」と訳される。
(出典：IT 用語辞典 e-words http://e-words.jp/) ここでは、ERP を支援するためのソフト
ウェアを導入するプロジェクトを指す。
26 System Integrator の略。顧客の業務内容を分析し、問題に合わせた情報システムの企
画、構築、運用などの業務を一括して請け負う業者のこと。システムの企画・立案からプログラムの開発、必要なハードウェア・ソフトウェアの選定・導入、完成したシステムの保守・管理までを総合的に行なう。(出典：IT 用語辞典 e-words)
25

50

ワーキングペーパー出版目録
番号

著者

論文名

出版年

2007・1

小杉 裕

シーズ型社内ベンチャー事業へのＶＰＣの適用

4/2007～株式会社エルネットの事例～

2007・2

岡本 存喜

マネジメントシステム審査登録機関 Y 社

4/2007のＶＣＰ（Ｖａｌｕｅ Ｃｒｅａｔｉｏｎ Ｐａｔｈ）の考察

2007・3阿部 賢一

F 損害保険会社における3/2007

ＶＣＰ（Ｖａｌｕｅ Ｃｒｅａｔｉｏｎ Ｐａｔｈ）の考察

2007・4岩井 清一

S 社における VCP（Value Creation Path）の考察

4/2007

2007・5佐藤 実

岩谷産業の VCP 分析

4/2007

2007・6

牛尾 滋昭（株）森精機製作所における VCP(Value Creation Path)の考察

4/2007

2007・7

細野 宏樹

ＶＣＰ（Ｖａｌｕｅ Ｃｒｅａｔｉｏｎ Ｐａｔｈ）によるケー4/2007

ススタディー
ケース：株式会社 電通

2007・8外村 衡平

VCP フレーム分析による T 社の知的資本経営に関する考察

4/2007

2007・9橋本 敏行

企業における現金保有の決定要因

10/2007

百貨店 A 社グループのシェアードサービス化と4/2007

2007・10 森本 浩嗣

その SS 子会社によるグループ貢献の VCP 分析

2007・11 山矢 和輝

みすず監査法人の知的資本の分析

4/2007

2007・12 山本 博紀

S 社の物流（航空輸出）に関する VCP(Value Creation Path)の4/2007

考察

2007・13 中 智玄

A 社における VCP(Value Creation Path)の考察

5/2007

2007・14 村上 宜洋

ＮＴＴ西日本の組織課題の分析

5/2007～Value Creation Path 分析を用いた経営課題の抽出と提言～

2007・15 宮尾 学

健康食品業界における製品開発

5/2007－研究開発による「ものがたりづくり」－
2007・16 田中 克実

医薬品ライフサイクルマネジメントのマップによる解析評価

9/2007－Product-Generation Patent-Portfolio Map の提案－
2007・17 米田 龍

サプライヤーからみた企業間関係のあり方

10/2007～自動車部品メーカーの顧客関係についての研究～
2007・18 山田 哲也

経営幹部と中間管理職のキャリア・パスの相違についての一考

10/2007

察 －日本エレクトロニクスメーカーの事例を基に－2007・19 藤原 佳紀

供給サイドにボトルネックが存在する場合の企業間連携の評価

10/2007－原子力ビジネスにおいて－2007・20 加曽利 一樹

通信販売ビジネスにおける顧客接点複合化の検討

11/2007～ 株式会社ゼイヴェルの事例をてがかりに ～2007・21 久保 貴裕

高付加価値家電のデザイン性のマネジメント

12/2007

2007・22 川野 達也「自分らしい消費」を促進するアパレル通販

11/2007－インターネット・メディアとの連動－
2007・23 東口 晃子

1994 年～2007 年のシャンプー・リンス市場における12/2007

マーケティング競争の構造
2007・24 茂木 稔

デバイスマーケットのデファクト・スタンダード展開

12/2007～後発参入でオープン戦略をとったＳＤメモリーカード～
2007・25 芦田 渉

地域の吸引力～企業誘致の成功要因～

12/2007

2007・26 滝沢 治

製薬企業の新興市場戦略『中国医薬品市場における「シームレ12/2007

ス・バリュー・チェーン」の導入』
2007・28 南部 亮志

e コマースにおけるパーソナライゼーション

12/2007～個々の顧客への最適提案を導く仕組みと顧客情報～
2007・29 坪井 淳

ホワイトカラー中途採用者の効果的なコア人材化の要件に関す

12/2007

る一考察
2007・30 石川 眞司

アップルとサプライヤーとの企業間関係に関する考察

1/2008

2008・1

石津 朋和

技術系ベンチャー企業の企業価値評価の実践－ダイナミック

5/2008

白松 昌之

DCF 法とリアル・オプション法の適用－

鈴木 周
原田 泰男

2008・2

荒木 陽子

医薬品業界と電機業界における M＆A の短期の株価効果と長期

井上 敬子

の利益率

5/2008

杉 一也
染谷 誓一
劉 海晴

2008・3

堀上 明

IT プロジェクトにおける意思決定プロセスの研究－クリティカルな場面におけるリーダーの意思決定行動－

9/2008