Comments
Description
Transcript
「できない」を「できる」に！人の行動原理に着目したプロセス改善
「できない」を「できる」に！人の行動原理に着目したプロセス改善 ～現場が自らの問題に気づきプロセス改善に取り組むための極意～ Change your Mind from “Impossible” to “Possible”! Process Improvement Focused on Behavioral Principle of Human -A Wisdom to Make Projects Recognize their Problems and Try Process Improvement 主査 副主査 副主査 リーダー 研究員 研究員 研究員 研究員 ：阪本 太志（東芝デジタルメディアエンジニアリング株式会社） ：中森 博晃（パナソニック ファクトリーソリューションズ株式会社） ：三浦 邦彦（矢崎総業株式会社） ：岩井 慎一（株式会社デンソー） ：江口 徹（株式会社神戸製鋼所） ：小笠原健二（株式会社日立製作所） ：小川 忠久（株式会社ニコンシステム） ：関野 浩之（アズビル株式会社） 研究概要 開発組織が品質・コスト・納期を達成し続けるために、現場支援者 (プロセス改善推進 担当や品質保証担当)はプロセス改善として、標準プロセスの作成・適用・定着を目指して いる。一方、現場は納期に追われているため、現行プロセスの変化を望んでおらず、結果 としてプロセス改善が進んでいない場合が多い。現場の現状調査･分析の結果、そのような 現場は、「現状に満足しているか、現状の問題をプロセス改善では解決できない」、もしく は「現場と現場支援者の間で要望が異なることで生じる対立は解決できない」と思ってい ることが明らかになった。 そこで我々は客観的事実に立脚した未来予測によるリスク認識と、双方の主張の背景に ある要望を満たす Win-Win 施策の探索から、現場にプロセス改善を動機づけるごちゃもや スッキリ(GMS)法を考案し、検証を行った。本手法を活用することで全員が共通の目標を共 有でき、現場の思い込みを排除して、現場主体のプロセス改善を進めることが可能となる。 Abstract The support members of software development projects such as Software Engineering Process Group and Software Quality Assurance aim to make and apply the standard software development process so that the software development organization to which they belong continues accomplishing their goals of quality, cost and delivery. On the other hand, there are many cases where the process improvement does not make progress because many of projects do not require change of their current processes due to the pressure of delivery. As a result of our survey and analysis of the projects’ reality, it was clarified that such projects believe their satisfaction to current situation, and impossibility to solve their problems not related to the process and conflicts among them including their support members. We proposed and verified the “Gocha-Moya-Sukkiri(GMS)” method which makes the projects motivated the process improvement by recognition of possible risk in the future based on objective facts and explore the win-win strategies between the projects and their supporters satisfying both demands. Applying this method makes possible to share commo n goals and eliminate assumptions of projects, and then it results in improving their software development processes by themselves. 1 1. 研究動機 ソフトウェアが社会に与える影響が大きくなる中、高品質・低コスト・短納期を前提条 件としたソフトウェア開発は多い。開発組織が事業目標に貢献し続けるには、プロジェク ト(PJ)が品質・コスト・納期(QCD)を達成し続けることが必要であり、これらの予測精度、 見積もり精度を上げ、さらに品質や効率性を高めることが重要な課題になっている。 そのため、開発組織長や現場支援者はモデルベースのプロセス改善に取り組み、ソフト ウェア開発の標準プロセスを作り、それを組織内で標準的に運用 ・定着させたいと考えて いる。しかしながら、研究員らの所属する企業では標準プロセスの運用に 前向きでないソ フトウェア開発現場が存在し、それがプロセス改善ひいては上記の前提条件の遵守を阻害 するケースが報告されている。 例えば、開発現場の声として、「現状の開発プロセスでうまくいっている」、「プロセス 改善をする余裕がない」「プロセス改善をする理解を得られない」などの意見が聞かれた。 これらを総合した結果、 「プロセス改善に前向きでない開発現場では、そこに内在する「納 期やコスト」 「現状への満足感」 「周囲との対立」等の前提条件が阻害要因となり、現場支 援者との間で問題を共有できなくなっている」という仮説が見えてきた。 本論文ではこの仮説を出発点として、開発現場にプロセス改善を定着させるために必要 な現場支援者の開発現場への関わり方、およびプロセス改善の阻害要因を排除し、開発現 場と現場支援者が問題を共有する手法を考案することを研究の目標とした。 本研究では、PJ が過去に経験したトラブル事例(過去トラ)を活用したリスク評価の仕組 みと、ゴールドラット博士が開発した、教育現場におけるファシリテーション手段である 教育のための TOC(TOCfE)の思考ツールを組み合せた「ごちゃもやスッキリ (GMS)法」を提 案する。本手法によって開発現場のプロセス改善に対する思い込みや対立関係を解消し、 最終的に開発現場と現場支援者が目標を共有し、現場主体でプロセス改善を進めることで、 PJ を継続的に成功させる体制の確立を狙っている。 2. 現状分析 2.1 ソフトウェア開発現場の意識 本研究を進めるにあたり、我々の研究動機に関連するソフトウェア開発現場の現状把握 を目的として、研究員らの所属組織でアンケート調査を実施した。（詳細内容は付録１ (1) 参照） その結果、標準プロセスは調査対象の全ての組織に存在し、ほぼ適用されている結果を 得た。また、開発現場における問題・課題を解決するためのプロセス改善は、 「取り組んで いる」と「取り組んでいない」は同数で、取り組んでない理由として表 1 の結果を得た。 表 1：プロセス改善に対する意識調査の結果 2 2.2 プロセス改善に取り組んでいない問題の分析結果 2.1 の結果から、現場がプロセス改善に取り組めない実態を把握できたが、その背景に ある問題については明らかになっていない。我々は、前節で述べた仮説をなぜなぜ分析に よって掘り下げて 12 種類の仮説を導出し、更になぜなぜ分析の結果とアンケートの結果を 紐づけることで、最終的に 7 種類の問題(真因)を抽出した(付図 1)。 PJ を取り巻くステークホルダー(管理層／現場(PJ)／現場支援者(プロセス改善担当者、 品質管理担当者))は「PJ を成功させる」共通目標の下で PJ に関わるが、置かれている立 場によって QCD 確保に対する目標が異なる。表 2 は、抽出した真因に対して、この目標の 違いが具体的にどのような行動として表出しているかを対比・分類した結果である。 表 2：プロセス改善に取り組めないプロジェクトの問題の分析結果 プロジェクトを成功させる 共通の目標 ステークホルダー別の目標 No. 真因 （１）管理層 （２）開発現場(ﾌﾟﾛｼﾞｪｸﾄ) （３）ﾌﾟﾛｾｽ改善担当 （４）品質保証担当 組織的にQCDを確保し、 プロジェクトのQCDを確保 組織的にQCDを確保し、 プロジェクトのQを確保す 高める する 高める る ↓ ↓ ↓ ↓ ステークホルダー別の行動 （１）管理層 （２）開発現場(ﾌﾟﾛｼﾞｪｸﾄ) （３）ﾌﾟﾛｾｽ改善担当 （４）品質保証担当 1 現状の業務に余裕がない 現状の開発プロセスで何とかする 2 現場がPJの現状に満足している 現状の開発プロセスを維持・継続させる 3 (A)現場は、現状が手一 杯（もしくは満足）で思考 停止しているか、 現状の問題をプロセス改 善では解決できないと考 えているため、 プロセス改善に興味がな く、プロセス改善に取り組 めない PJの問題がプロセスに関係したものではない 技術や方法論を獲得・向上させる （技術やスキルの問題など） やるべきことをやってもら プロセス改善に取り組む い、プロジェクトの品質を 確保する 管理層・現場共にはプロセス改善の必要性を 認識しているが、目の前のプロジェクトを成功 4 させること（プロジェクトの問題を解決すること） 現状の開発プロセスで何 を優先する とかする プロセスの顧客依存が阻害要因となり、有効 なプロセス改善施策が打てない プロセス改善に取り組む 現場はプロセス改善の必要性を認識している 現状の開発プロセスを維 6 が、管理層がPJの現状に満足している 持・継続させる 5 7 上司や部下の間で認識の違いがある 問題の分類結果 現状プロセス／プロセス 改善のどちらでも構わな い (B)現場と現場支援者の 間でプロセス改善に取り 組むことは共有できてい るが、現場と他のステー クホルダの行動が異なる ことで対立が起こり、プロ セス改善に取り組めない 分析の結果、プロセス改善に取り組めない組織は、以下の状況にあることが見えてきた。 (1)現場支援者は現場をあるべきプロセスへの改善に導きたいが、現場自体は内在する様々 な要因により、現状プロセスの維持・継続に留まっている。 (真因 1～3：問題(A)) (2)現場支援者/現場のいずれもプロセス改善へ取り組む目標は一致するが、ステークホル ダー間の要望(優先順位や進め方)の違いから対立が生じている。(真因 4～7：問題(B)) (3)管理層は手段としてのプロセス改善には興味がなく、結果としての QCD 確保のみを注視 している。(真因 1～7) 上記のうち(3)は管理層のみに限定された状況であり、プロセス改善の定着とは直接的 に無関係である。したがって、アンケート結果から読み取れる真の問題は、 (1)(2)に関連 した、現場と現場支援者との関係性に由来する問題 (A)(B)に分類できる。 2.3 課題と既存手法の限界 2.2 で明確になった問題はいずれも、 「人の認識の違い」に起因するもので、以下に例示 するとおり、問題相互の関係に人間心理が大きく影響し、複雑に絡み合っている。 ・前提となる事実認識が異なっている ・結論を導くための考え方、あるべき基準に関する認識が異なっている ・そもそも根底にある価値観が異なる そこで、我々は「人の認識の違い」を解消する手法を考案することを目標に、表 2 に示し た(A)(B)の問題を解決することを課題とした。 課題(A)のような場合、PJ は「問題」が分かっていない状態で、危機感もない。また、 3 課題(B)のような場合、PJ は「問題」は分かっているが、「人の認識の違い」により、「解 決策」が決まらない状態で、手を打てないことにもやもやしている。これらの問題を解決 する手法として、SaPID/SPINA 3 CH、TOC、TOCfE があるが、それぞれ表 3 に示すメリット／ デメリットがある。このうち TOC は「検討過程が複雑である」 「時間がかかる」といった特 徴から導入段階で現場が敬遠することが懸念される。SaPID/SPINA 3 CH や TOCfE は「着手し やすい」という面で適切ではあるが、「全体最適になりにくい」「 真因は後回しになりやす く真因解決に至らない場合がある」という面もあり、これらを解決する必要がある。 表 3：課題に対する既存手法のメリット／デメリット 3. 解決策 3.1 解決策のポイント 本論文の目標は、現場に問題を気づかせること、問題の対立があっても、対立を解消で きる目標があることを伝えることである。前節で示した既存手法のデメリットを克服し、 目標とする状態へ到達するためのアプローチとして、我々は以下の 3 点に着目した。 (1) 過去に起きたトラブル事例(過去トラ)による問題認識：真因の解決 過去に PJ が経験した問題を再発防止等に活用できる組織や現場であれば、それらを自 分たちの問題として認識することができる。過去トラはまさに現場の抱える「真の問 題」にほかならず、真因の認識とその解決への意識を客観的視点から与えられる。 (2) 事実の因果関係による未来志向での問題認識：真因の解決 過去に PJ が経験した問題を事実として認識できない組織や現場の場合、 (1)のアプロ ーチは通用しない可能性がある。この場合、現場が認識できるものは現在経験してい る「事実」のみであり、これらの事実関係の因果を繋ぐことで、現場が陥る可能性の ある好ましくない状況を抽出できる。そして、更にそれに過去トラ等を絡めることで、 問題として認識させることが可能である。 (3) 共通目標の導出・共有による対立解消：全体最適の達成 プロセス改善活動における全体最適を阻害する要因として、現場支援者と現場の対立 などが存在する。これらの対立は行動レベルで発生しており、お互いの目標が同じ (例 えば現場支援者と現場の対立では PJ の成功が共通目標)であることを認識させること ができれば、両者が妥協しない Win-Win の解決が可能となる。 以上の観点に立って現場に問題を気づかせるためには、現場支援者が PJ の中に入り込 み、共同作業によってその状態に導いていく必要がある。我々は「チームワークを引き出 し、そのチームの成果が最大となるように支援する」手段であるファシリテーションに着 目し、各観点に応じた思考ツールの適用や現場―支援者間の質疑応答の手順を体系化した 『ごちゃもやスッキリ(GMS)法』を考案した。 3.2 解決策の詳細 GMS 法は前節(1)～(3)の観点に対応する 3 種類のファシリテーション法からなる。以下 に各手法の概要を説明する。 4 3.2.1 PTB ファシリテーション手法 多くの開発現場では、PJ が過去トラを基に再発防止策を規定し、以降の開発へ活用して いる。3.1(1)の観点から、過去トラは「過去に経験した事実」であり、これに立脚したフ ァシリテーションによって課題(A)が扱う問題の気づきに説得力を与える効果を期待でき る。一方、単純な事実の提示のみでは、元々問題の存在に否定的な現場に対して依然とし て気づきを与えられない懸念があり、自発的な問題認識に導けるような工夫が必要である。 以上から、課題(A)の解決策として過去トラの真因情報を質問構築に活用する「 PTB(Past Trouble-based)ファシリテーション手法」を考案した。本手法は以下の手順で実施する。 (1) 真因情報抽出：現場支援者は予め過去トラを集約した DB から、適用対象の PJ に類似 した事例を抽出する。過去トラ DB の概要は付表 4 の通り「PJ 情報」 「真因情報」 「不具 合情報」が紐づいた形式で管理されており、事例抽出は PJ 情報の各項目の類似度合い に鑑みて決定される。真因情報は、フェーズ情報(開発のどの時点で)、主語(トラブル の原因となる対象物)、述語(主語がどうなったか)の 3 項目について整理しておく。 (2) ファシリテーション：現場支援者は(1)で抽出した真因情報 3 項目を基に以下の質問群 を組み立て、開発現場へのヒアリングを実施する。（詳細フローは付図 2 を参照） a) 真因情報を切り口とした問題認識 1： 「フェーズ情報」と「主語」について気になる こと、問題は起こると考えているか？(Q1～3) b) 真因情報を切り口とした問題認識 2： 「述語」について気になること、問題は起こる と考えているか？(Q4,5) c) 現状に問題がない理由の引き出しと、それに基づく問題認識：4M5E を用いて網羅的 に引き出された「問題がない理由」に将来的な状況変化が生じないか？ (Q6/7～9) 以上の手順で進めることで、PJ が潜在的に有する、過去トラに立脚した問題のリスクを 段階的かつ自律的に認識させることができる。 3.2.2 GS ファシリテーション手法 課題(A)を解決するために、3.1(2)の観点を基に TOC 思考ツールのブランチ(付録 4 参照) と過去トラ等の客観的データを用いた「ごちゃごちゃスッキリ(GS)ファシリテーション手 法」を考案した。この手法は以下の手順で実施する。 (1) 現場に気づかせたい問題に対し、 「今の状態」を起点に「起きる可能性がある状態（結 果）」として考えられることを、ポストイット 1 枚に 1 件書いてもらう。 (2) ポストイットに書かれた内容で分からないところがあれば、付表 6 の質問を活用して 明らかにする。質問の後、1 分間待つと考える時間ができて良い結果に繋がる。 (3) 因果関係があるかどうかは、参加者の表情が「そうだ」となっているかで判断する。 ここで意見が分かれた場合は、理由をつけて「もし・・・ならば、結果として～。な ぜならば・・・」と補うことで解消することが多い。 (4) 解消しない場合はまだ何か抜けがあると判断し、その部分に対して、 付表 6 に記載の 質問を行って明確にして行き、結果にたどり着くまで予測する。結果はひとつとは限 らず、複数に分散する場合や、ループし続けることもある。 (5) 「好ましい状態」が「好ましくない」に変わったポイントを PJ に認識させた時点で「今 のままだとやばい」に気づかせることができる。ここで、過去トラなどのデータを提 供することで、PJ に何が問題で何を変えるのかを認識させることができる 。 3.2.3 MS ファシリテーション手法 課題(B)を解決するために、3.1(3)の観点を基にペイオフマトリクス法と TOC 思考ツー ルのクラウド(付録 5 参照)を組み合せた「もやもやスッキリ(MS)ファシリテーション手法」 を考案した。本手法は以下の手順で実施する。 (1) 問題の明確化：縦軸に影響度、横軸に緊急度をとった平面上に問題を配置することで、 5 双方が納得できる問題を合理的に選択する。 (2) 対立構造の明確化：クラウドにより問題の対立構造を見える化し、問題が生じている 背景を単純な構造を図示する。 (3) 解決策の検討・決定：双方の背後にある要望・ニーズ・期待を満足させるように考え ることで、双方が満足できる Win-Win の解決策を決める。解決策が多い場合は、縦軸 に効果、横軸に難易度をとった平面上に解決策を配置することで、双方が納得できる 解決策を合理的に選択する。 ファシリテーション時に作成した図表は付録 5 にまとめる。 4. 解決策の検証方法 提案した解決策の効果を確認・考察するため、具体的事例やシミュレーションによる検 証を実施する。以下に検証方法を述べる。 4.1 PTB ファシリテーション手法 『PTB ファシリテーション手法』では、適用対象となる現場責任者(PM)のタイプと、フ ァシリテーションのベースとなる不具合事例をそれぞれ複数 組み合せたケースにおいて、 提案手法の各質問群(a～c)に対して対象者の問題への気づきや納得感を基準とした効果を 各研究員が定量的に検証する。詳細な検証方法については、表 4 および付録 6 に補足する。 表 4：『PTB ファシリテーション手法』の検証方法 項目 1 PMタイプ 2 不具合事例 条件 具体情報 10種類 付表9を参照 4事例 3 評価対象 3質問群 4 評価基準 2項目 5 評価者 3名 付表10を参照 ・Q1～3 ・Q4,5 ・Q6/7～9 (A)問題への気付き (B)結果への納得感 本テーマ研究員 備考 ITスキル標準(PM)で規定されている11種類のスキル項目の優劣 の組合せによって典型的なパターンを定義 前年度の第1分科会テーマ“KWS振り返り[1]”にて収集・分析され た不具合DBから選定 ファシリテーションの段階に応じて分類される3種類 それぞれどの程度効果が得られるかを0～5の6段階で評価（大き いほど効果大） できるだけ先入観を排除した評価とするため、研究員相互の結果 を知り得ない状況下で独立に実施 4.2 GS ファシリテーション手法 『GS ファシリテーション手法』では、「自分に問題はない」と思っている開発者に対し て、 「今のままだとどうなるか？」を出発点として、表 5 の指標を定義し、効果を検証する。 表 5：『GS ファシリテーション手法』の効果の検証方法 No 期待される効果 指標 1 まずいと気づいたか ヒアリング結果（Yesと回答） 2 アクションが起こせたか ヒアリング結果（Yesと回答） 3 次に何をやったか（定着） ヒアリング結果（他PJでアクションが起こせた） 4.3 MS ファシリテーション手法 『MS ファシリテーション手法』では、表 6 の指標を定義し、効果を定量的に検証する。 表 6：『MS ファシリテーション手法』の効果の検証方法 6 5. 検証結果 5.1 PTB ファシリテーション手法 表 4 の条件で実施した、 『PTB ファシリテーション手法』の検証結果を下表 7 に示す。な お、事例や PM タイプ等の項目別に見た詳細結果を、付表 11 および付図 7、8 に併せて示す。 表 7：過去トラを活用したファシリテーションの検証結果 事例1 事例2 仮想適用者数（PMペルソナ） 評価者数（研究員） フェーズ 現場に気づいてほしい こと（過去トラ事例） 主語 述語 No 期待される効果 1 問題に 気付けたか 2 納得感を 得られたか 事例3 事例4 10 10 10 3 3 3 テストスクリプトフォーム に設けられていない 明確になっていない 存在しない 事例1 事例2 事例3 事例4 質問群 Q1～3 Q4,5 シミュレーション評価 Q6/7～9 (0～5の6段階、全評価 Q1～3 者の平均) Q4,5 Q6/7～9 要件定義 チームのPJにおける 役割 3 基本設計 システム仕様書の 変更箇所以外の部分 充分レビューされて いない 指標 機能テスト 10 開発コメント欄 2.27 2.80 3.37 2.70 3.20 3.70 2.00 2.57 3.33 2.30 2.93 3.67 実装 コーディングルール 2.13 2.63 3.27 2.57 2.93 3.50 2.03 2.47 3.27 2.57 2.83 3.60 5.2 GS ファシリテーション手法 『GS ファシリテーション手法』の効果の検証は、研究員の所属組織にて実施した。その 結果を表 8 に示す。また、作成したブランチ図を付図 9 に示す。 表 8：『GS ファシリテーション手法』の検証結果 事例1 参加プロジェクト数 現場に気づいてほしいこと 今の状態が続くとどんな状態が 発生するのか 今の状態が続くと将来何が起き るのか 事例2 5 レビューしっかりやる 不具合流出 開発がいつまでも終わらない 担当を外される どれくらいの確率で起きそうか No 期待される効果 1 まずいと気づいたか 指標 ヒアリング結果（Yesと回答） 5 計画をたててほしい メンバーが勝手に開発を進め る メンバーや周りの人にリーダー として認められず、居場所がな くなる。 70% 80% 50% 事例1 事例3 5 仕様をあいまいにしない 開発の最後に作業が集中す る 計画が作れない 担当を外される 事例2 事例3 Yes Yes 無駄な工数を使って全員の メンバーが今のリーダーは やる気がなくなる 不要だと考える 2 アクションが起こせたか ヒアリング結果（Yesと回答） Yes Yes Yes レビュー実施し再設計に至っ 要求元と仕様作成の 計画の立て方の教育実施 た 責任範囲を協議して合意した 3 次に何をやったか ヒアリング結果 次モデルにて、未レビューの 合意した責任範囲をルール化 次モデルで現場支援者に協力 （定着） （他PJでアクションが起こせた） 機能について、最初からレ して次モデルから運用開始し して貰って計画を作成した ビューを計画した た Yes 後戻りで周りの信用を無くす 5.3 MS ファシリテーション手法 『MS ファシリテーション手法』の効果の検証は、研究員の所属組織から集めた事例（5 件） について検証を実施した。その結果を表 9 に示す。また作成したクラウド図を付図 10～14 に示す。 表 9：『MS ファシリテーション手法』の効果の検証結果 7 6. 考察 本研究では、「ごちゃもやスッキリ(GMS)法」を考案し、以下の効果を確認した。 6.1 PTB ファシリテーション手法の効果 表 7 の評価点は評価者 3 名の平均から求めたが、評価者自身のバックグラウンド等に依 存するため、その絶対値の信頼性は高くない。しかし以下のように、質問群、事例、PM タ イプの各評価軸に対する評価点の相対的な傾向の違いから、その効果を把握できた。 (1)質問群：Q1～Q3⇒Q4,Q5⇒Q6/7～9 と段階を追う毎に質問の内容が詳細化していくこと で、気づきと納得感の両方で効果が高まった。（付図 7 参照） (2)事例：事例間で有意な差は確認できなったが、事例 1,3 の評価が高いことから、要件定 義や設計等の上流工程での効果が期待できる。 (3)PM タイプ：万能タイプはあらゆる問題に敏感に対応できるため高評価となったが、利 益追求タイプ、新人タイプ、現状満足型の 3 タイプでは「問題解決手法の活用」等のス キルが十分備わっていないことが影響したとみられ、低評価となった。（付図 8 参照） 6.2 GS ファシリテーション手法の効果 表 8 に示すように、参加者が現実的なチームの未来を予測して、将来発生しそうな課題 を共有することで現場の問題に気づけた。また、抽出した問題に対するアクションを自ら 考案し、現場主体のプロセス改善を実行することができた。 6.3 MS ファシリテーション手法の効果 ・表 9 のとおり現場支援者と現場が共通目標に着目して議論することは We vs.Problem に 目を向け、本音で発言する場の確保、参加者全員の納得度向上に貢献すると考えられる。 ・影響度と緊急度を基準とした判断は客観的事実に基づく解決に目を向け、双方が納得で きる問題の選択に貢献すると考えられる。また、表 9 の評価項目 No.4 から、対立の理 由は多い場合で半分が思い込みであることが確認された。これらの払拭がお互いの真意 を明らかにし、双方が納得できる解決策の選択に大いに役立つと考えられる。 7. まとめ 本研究では、開発現場のプロセス改善に対する思い込みや対立関係を解消し、現場と現 場支援者が問題意識を共有する手段として、現場が自らの問題に気づき活動するためのフ ァシリテーション手法「ごちゃもやスッキリ(GMS)法」を考案した。具体的事例やシミュレ ーションによる検証の結果、ケーススタディレベルではあるが、そ の効果を確認できた。 本結果から、人の行動原理に注目したプロセス改善の新たな方向性を示せたと言える。 8. 今後の課題 小規模 PJ の対立はメンバーvs.メンバーのことが多く、開発リーダが仲裁できるので、 付録を活用することで対立を解消するアイデアを PJ メンバーで考えることができる。しか し、大規模 PJ や組織の対立は集団 vs.集団なので、話の流れを整理したり、参加者の認識 の一致を確認したりする行為で介入し、合意形成や相互理解をサポートするファシリテー ターが必要となる。 PTB ファシリテーション手法では、低評価となった PM タイプに対しても、気づきや納得 感を引き出す質問の組み立てや過去トラ情報の整理充実が必要である。 また、上記課題への対応に加え、実際の開発現場への適用検証を進め、更なる課題整理 と改善を図っていくことも必要である。 9. 参考文献 付録参照 8 付録 1 現状分析 (1) アンケート様式 本研究において、実施したアンケートの様式を以下に記す。 付表 1：アンケート様式 9 (2) なぜプロセス改善に取り組めないのか 本論文の冒頭で示した仮説では、 「現状への満足感」や「納期やコスト、周囲の組織等の 弊害」による問題への関心の欠如がプロセス改善の阻害要因であるという方向性を示した。 そこで本仮説を起点として、なぜなぜ分析によって問題点を各論について捉えることを試 みた。分析の結果、付図 1 に色付きで示す 12 種類の具体的な問題点に対する仮説を得た。 次に、付図 1 のなぜなぜ分析結果に対し、アンケートで得られた意見がどのように紐づ いているかを分析したところ、両者の間に付図 1 に青字で示したような関連性があること がわかった。アンケート結果は実際の開発現場の声を表した「事実」であり、これから導 かれた仮説は実在する「問題点(真因)」と見なせる。この考え方を基に真因を抽出 した結 果、最終的に付図 1 に黄色で示した 7 種類の真因が得られた。 付図 1：アンケート結果に対するプロセス改善に取組めない要因のなぜな ぜ分析結果 参考資料 小倉 仁志、なぜなぜ分析 実践編、日経 BP 社、2010 10 付録 2 TOC を教育現場に応用した TOCfE ・ 自分達には問題ないという「周りの人に見えている姿」を認識できない。 ・ 問題なのは周りという「人の所為にする姿」を認識できない。 上記のふたつを解消するポイントは、自らが気づくことである。我々は、そのような手段 として、TOC を教育現場に適用した TOCfE に注目した。TOCfE は TOC 生みの親であるゴール ドラット博士の 4 つの信念「人はもともと善良である（人の所為にしない）」「対立は常に 解決できる（Win-Win は存在する）」 「すべての物事は非常にシンプルである」 「分かってい るとは思わない」を元にした、 「子供でも扱える」ツールで、教育現場だけでなく家庭、ビ ジネスへと利用され、至る所で効果を出している。TOC と TOCfE の違いを付表 2、TOCfE で 利用する思考ツールの特徴を付表 3 に示す。 付表 2：TOC と TOCfE の違い No ツール 特徴 1 TOC 会社や組織の全体最適を求め、会社や組織に内在する中核問題の根本原因に対する解決策に焦点を 当てる。→全体最適 2 TOCfE 個人が行動できるようになることを求め、目の前の「ごちゃごちゃ」している事実間の関係を整理し、そこ から問題を見つけ、その問題の要因となっている「もやもや」を解消する解決策に焦点を当てる。→部分 最適 付表 3：TOCfE 思考ツールの特徴 No ツール 1 ブランチ 2 クラウド 3 アンビシャス ターゲットツリー 特徴 用途 ごちゃごちゃした事実を因果関係のロジックで繋ぎ、事実間 現状の問題を整理する。 の関係を整理する。 過去の出来事を整理する。 未来の出来事を整理する。 ある問題に対して、双方の要望が異なることが要因となっ 対立する双方の要望と行動を整理する。 て、双方の行動が対立する状態を整理する。 ある問題に対して、2つの選択肢が存在し、そのどちらかを あるべき自分とありたい自分を整理する。 選んでも、何らかの不利益があり、行動を決めかねる状態 を整理する。 目標の達成を阻む障害を挙げ、障害を克服する中間目標 目標を達成するための道筋を定める。 をロジックで繋ぎ、実行可能な道筋を定める。 これらのツールは全て以下の特徴を持っている。 ・シンプルである。 ・具体的である。 ・論理的に順序立てられている。 ・誰もが使うことができる。 本研究で扱う TOCfE 思考ツールを使ったファシリテーション手法は、以下に記載の資料 に、TOCfE 公認ファシリテーターの研究員オリジナルの手法をミックスして活用している。 参考資料 ｷｬｼｰ･ｽｴﾙｹﾝ 著、飛田 基 訳、TOC による学習のつながり、TOC for Education Inc.、2012 G.M.ﾜｲﾝﾊﾞｰｸﾞ 著、木村 泉 訳、ｺﾝｻﾙﾀﾝﾄの秘密、共立出版、1990 11 付録 3 PTB ファシリテーション手法の補足資料 付表 4：過去トラ DB の例 PJ情報 真因情報 不具合情報 前提条件 人員 期間 工数 新規 業務 (人) (月) (人月) ／派生 種別 PJ/作業 詳細 原因となる事象 不具合事例 フェーズ情報 主語（～が） 述語（～されていない） システム仕様書の変更箇 充分レビューされていな 1 5 3 15 新規 PJ 車両制御 基本設計 納期遅れ 所以外の部分 い テストスクリプトフォーム 2 10 0 派生 作業 SST担当テスト 機能テスト テスト目的 不具合流出 に明示されていない ●真因・不具合情報の抽出 テストスクリプトフォーム 3●事例抽出 10 0 派生 作業 SST担当テスト 機能テスト 開発コメント欄 不具合流出 ：抽出したPJ情報に紐づく真因情報、 に設けられていない 不具合情報を抽出 ：対象PJとPJ情報を参照し、類似度の高い 仕様書とテストスクリプト 4 10 0 派生 作業 SST担当テスト 機能テスト 取られていない 不具合流出 のトレーサビリティ ⇒ファシリテーションへ活用 PJ情報を抽出 5 10 0 派生 作業 SST担当テスト 機能テスト テストノウハウ 管理されていない 不具合流出 6 10 0 派生 作業 SST担当テスト 機能テスト テスト環境、結果 バックアップされていない 納期遅れ 7 2 0.5 1 作業 ソフト検証 システムテスト ユーザビリティの確認 実施されていない 不具合流出 8 3 0.5 1.5 作業 Excel作成 要件定義 要件 要件元に確認していない 不具合流出 9 7 20 140 派生 PJ S開発PJ-PA 要件定義 チームのPJにおける役割 明確になっていない 目標性能未達 膨大な設計パラメータ 複数のドキュメント（仕様 10 6 24 144 派生 PJ S開発PJ-PC 基本設計 （定量的基準値がほし 書）に分割して記述して 納期遅れ い） いない 設計パラメータ定義書の パラメータ規模に応じて 11 6 24 144 派生 PJ S開発PJ-PC 基本設計 納期遅れ フォーマット 決定していない 抜け漏れなく仕様書に記 12 6 28 168 派生 PJ S開発PJ-PV 詳細設計 仕様情報 不具合流出 載していない 過去トラDBから 引っ張ってきた情報 開始 a) 真因情報を切り口とした問題認識1 Ｑ１：フェーズ情報 と 主語 に気になることはあります か？ Ｑ２：それはどんなことですか？ 問題が起き、プロセス改善が必要 Ｑ３：気になることの結果、ど んな問題が起こりますか？ b) 真因情報を切り口とした問題認識2 問題が起こるが、プロセス改善は不要 ／問題は起こらず、メリットを享受 不十分 B Ｑ４：例えば 述語 について、 現在の状況はどの程度です か？ Ｑ５：述語 が不十分であるこ との結果、どんな問題が起こ りますか？ 十分やれている 問題が起き、プロセス改善が必要 問題は起こるが、プロセス改善は不要 Ａ Ｑ６：Ａ５の結果となる理由を教えてください。（４Ｍ５Ｅの観 点で条件を引き出し） Ｑ７：フェーズ情報 主語 述語 の関係が充分な理由を教 えてください。（４Ｍ５Ｅの観点で条件を引き出し） Ｑ８：組織が変化し、Ａ６／Ａ７ の理由が満足できなくなる可 能性はありますか？ 可能性はない 可能性はある c) 現状に問題がない理由の引き出しと、 それに基づく問題認識 Ｑ９：例えばＡ６／Ａ７の理由 のいずれかが満足されなくな るとどうなりますか？ 問題は起こらない 問題が起きる Ａ 過去トラと同じ場所に問題が存在し、それに気づいたと判断 B B Ｃ 過去トラと類似の問題が存在し、それに気づいたと判断 Ｃ 過去トラと類似の問題は存在しない 付図 2：PTB ファシリテーション手法のフローチャート 参考資料 原子力安全技術ｾﾝﾀｰ、4M5E 分析手法ﾏﾆｭｱﾙ、 http://www.n-iinet.ne.jp/Manual4M5E.pdf 12 付録 4 TOCfE で使用する思考ツール (1) ブランチ TOCfE 思考ツールのブランチは、出来事、概念、主張間の原因とそ の結果を調べるための、1 つの分析法であり、付図 3(ブランチの基本 図)のように四角と矢印で表される。 ブランチの基本的な考えは、 「結果には全て原因がある」であり、そ れぞれの断片的な情報の因果関係を理由と共に明確にすることで、一 連の出来事を順序立てて説明できるようになる。ブランチを作成する ことによって、最初の行動の結果、そこに連なる一連の出来事が起こ ることが分かるようになる。 ブランチの基本図 以下、例を挙げてブランチ作成手順を記す。作成には付録 4(2)で説 明するファシリテーション手法を使用する。 ①原因と結果を結ぶ 原因となる事象に対し、結果としてどうなるかをポストイットに書 いて貰う。 「勉強をしなかった」から「テストで悪い点を取る」の場合、右の 図(原因と結果)になる。 ②曖昧さの排除(明確化) 曖昧な表現を具体的にする(この例では「勉強しなかった」に具体性 が無い)。 これにより、例えば「勉強」とは「宿題」であると特定され 、右図(具 体的表現)となる。 ③因果関係の確認 以下のように読み上げ、因果関係を確認する。 「もし宿題をやらなかったら、結果としてテストで悪い点を取る」 ④理由付け なぜ、宿題をやらなかったらテストで悪い点を取るのかを理由付け する。 例えば、 「 宿題になった問題がテストに出ることが多い から」を付加して、 「もし宿題をやらなかったら、結果と してテストで悪い点を取る。なぜならば、宿題になった 問題がテストに出ることが多いから」と繋げることで、 右図(理由付けされた原因と結果)のように、意味のある 一連の流れができあがる。 勉強をしない 原因と結果 テストで悪い点を 取る 宿題をしない 具体的表現 テストで悪い点を 取る 宿題をしない ⑤ブランチの完成 ④で作成したブランチのあとには、 「 もしテストで悪い 点を取ると、結果として・・・」と、1 つずつ原因と結 果を繋げていくことで、ブランチが完成する。 テストで悪い点を 取る 宿題になった問 題がテストに出 ることが多いから 理由付けされた原因と結果 付図 3：ブランチの基本図 ブランチは、完成させる過程で問題であることに気づくことができるツールである。 13 (2) TOCfE におけるファシリテーション手法 自分の姿に自ら気づくためのポイントは、分かって欲しい側が教えないでオープンな質 問 で 問 い か け 続 け る こ と に あ る 。 こ の 場 合 の 問 い か け は CLR（ Category of Legitimate Reservations ） と 呼 ば れ 、 7 つ の 視 点 ( 付 表 5) が 提 唱 さ れ て い る （http://listfreak.com/list/1813）。今回は、CLR を基にして考えられた「ちゃんと考え ていない思考の 4 大ケースとそのための質問(付表 6)」を活用する。 付表 5：7 つの視点と観点 No 7つの視点 1 明瞭性 (Clarity) 2 項目の存在 (Entity Existence) 3 因果関係 (Causality Existence) 4 原因不十分 (Cause Insufficiency) 5 別の原因 (Additional Cause) 6 因果が逆さま (Cause-effect Reversal) 7 予想される結果の存在 (Predicted Effect Existence) 観点 結果・原因それぞれが短く、明瞭で、わかりやすい文章で書かれている か？ 結果・原因それぞれが本当に存在するか？ 本当に因果関係があるか？ 何かが抜けていて論理の飛躍に見えないか？ それらの原因さえあれば結果が起きるといえるか？ 同じ結果を生じさせる、まったく別の原因はないか？ 結果と原因が逆ではないか？ 原因から引き起こされると予想される結果は他にないか？ 付表 6：ちゃんと考えていない思考パターンとそのための質問 No ちゃんと考えていない思考パターン 1 用語や文章の意味があいまいな場合 （あいまいで分かりにくくないか？） 2 文が意味することが厳密には妥当でない場合 （本当かどうか？） 3 4 因果関係がちゃんと成立していない場合 （因果関係があっているか？） 結果の原因となることが不足している場合 （それで十分か？） そのための質問 ・・・（用語や文章）とはどういう意味ですか？ 本当ですか？ 一般的すぎる表現はありませんか？ 常にそうであると言えるのですか？ 「もし・・・ならば、結果として～」を補って読んだ時、しっくりきますか？ 他に必要なことはありませんか？ 出展：教育のための TOC(TOCfE) 事務局 また、ファシリテーションを行うに当たっては、ファシリテーターや参加者がやっては ならないことがあり、付表 7 にまとめる。 付表 7：ファシリテートにおいてやってはならないこと No やってはいけないこと その理由 1 他の人のアイデアを否定、批難する 否定、批難された人は思考停止してしまうため 2 他の人のアイデアに対して「それって○○ってこと？」と聞く 「○○ってこと？」は質問のようだが、実は質問になっておらず、 誘導しているため Yes / No だけで応えられる質問はNG 考える際、グループ全員がまず付箋に書き出す 他の人のアイデアから次に繋がらなくなってしまい、 同じ考えを膨らませることができなくなるため 3 14 付録 5 MS ファシリテーション手法 事前準備 a) 目的／目標の確認 目的：現場支援者と現場で QCD 確保の主張が異なり、プロセス改善に取り組めない といった対立を解消する 目標：双方が納得できる共通のゴール(上位のゴール)を見つけ、お互いの主張ではなく、 その背後にある要望、ニーズ、期待を満足させるように考えることで、 双方が満足できる Win-Win の解決策を見つけ出す b) 参加者の決定 キーパーソンを確保しつつ、自由な発想が促される数(5～8 人程度)に絞る。 c) 場所と時間の決定 可能であれば、通常の会議と違う場所、違う時間を選び、「特別な場」を演出する。 d) ファシリテーターの決定 参加者と利害関係のない第 3 者をファシリテーターにする。 当日 a) 会場のレイアウト 向かい合う座り方ではなく、物理的に同じ側に座るように会場をレイアウトする。 →You vs. Me ではなく、We vs. Problem に目を向ける。 b) グランドルール 相手のアイデアを否定・避難しないためのグランドルールを周知する。 →本音で発言できる場を確保する。 すべし すべからず ・本音で話す ・会議が終わったら他言しない ・お互いの意見を積極的に「聴く」 ・「こうしようよ！」など、建設的に話す ・ひとりが長々としゃべる ・個人攻撃 ・上げ足をとる ・他人の話をさえぎる 付図 4：グランドルール 1) 問題の明確化 1-1) ファシリテーターから問いかける。(以降、⇒で表す) ⇒「日頃の痛みは何ですか？」 ⇒「過去の後悔・現在の愚痴や不満・未来の不安など、あなたはどう思っていますか？」 参加者はポストイットに問題を無記名で 1 件に１枚書き出す。 1-2) ファシリテーターがポストイットを集め、ホワイトボードに貼る。 1-3) 先ずポストイットの内容を現在形(現在進行形)に書き換える。 次に痛みを問題として具体化するために、 付表 8 の観点でチェックする。 付表 8：問題のチェックリスト 15 1-4) ファシリテーターがポストイットの問題を読み上げる。 「縦軸に影響度／横軸に緊急度をとったマトリクス」のどこにポストイットを置くか ブレストする。 マトリクスの中に貼っていく。(ペイオフマトリクス手法) 1-5) 全体を見渡し、どこに重点があるのかを確認し、いちばん問題であると思うものを 選択する。 2) 対立の明確化 付図 5：対立の明確化 2-1) A:共通目標の明確化 ・⇒「双方にとって共通となる目標やゴールは何ですか？」 ・参加者から得た情報を A のボックスに現在形で記入する。 ※自分側と相手側を具体的に決める。 2-2) C:自分側の要望の明確化 ・⇒「ゴールを達成するために、(自分は)どうすべきだと考えていますか？」 ・参加者から得た情報を C のボックスに現在形で記入する。 2-3) D’:自分側の行動の明確化 ・⇒「C:自分の要望を満たすために、(自分は)どのように行動することが必要ですか？」 ・参加者から得た情報を D’のボックスに現在形で記入する。 ・⇒「そうなる理由は何ですか？」 ・参加者から出来るだけ多くの情報を集め、D’の理由ボックスに現在形で記入する。 2-4) B:相手側の要望の明確化 ・⇒「ゴールを達成するために、(相手は)どうすべきだと考えていますか？」 ・参加者から得た情報結果を B のボックスに現在形で記入する。 2-5) D:相手側の行動の明確化 ・⇒「B:相手の要望を満たすために、(相手は)どのように行動することが必要ですか？」 ・参加者から得た情報を D ボックスに現在形で記入する。 ・⇒「そうなる理由は何ですか？」 ・参加者から出来るだけ多くの情報を集め、D の理由ボックスに現在形で記入する。 16 2-6) D’:自分側の行動 と D:相手側の行動 の明確化 ・⇒「どういうときに対立しますか？」 ・対立する条件を明確にする。 2-7) 読み合わせ 「A を達成するためには B という状態を達成しなければならない。」 「B という状態を実現するためには D という行動をとらなくてはならない。」 「そして A を達成するためには C という状態を実現しなければならない。」 「C という状態を実現するためには D’という行動をとらなくてはならない。」 「D と D’は同時に実行できない。」 このとき、ファシリテーターが先導する形で、参加者全員が声を出して読んでいき、 クラウド図がその通りであると納得できるか、自分の直感に当てはめて確認する。 2-8) 思い込みの払拭 ・⇒「D と D’の理由ボックスに記述した考えが違っていたとするとどうでしょうか？」 ・D と D’との理由ボックスに記述されている 「・・・だから」を「・・・でないかもしれない」と読み替える。 ・参加者の反応(縦に首を振っている人数の割合)を確認する。 過半数を超えていれば、それは思い込みと判定する。 3) 解決策の検討 付図 6：解決策の検討 3-1) クラウド図から抽出した理由に注目し、各自、以下の問いかけで状況を整理する。 ①この理由は本当に存在するのか？ ②どのような変化を起こせは、この理由を無効にすることができるか？ ③正しいか、正しくないか？ ④もし正しいならば変化させることもできるか、それでもできないか？ 3-2) 解決策はクラウドを成り立たせている仮定の中にある。 そこで、付図 6 に示すクラウド図の 3 つの対立構造について、それぞれの仮定を明確 にする。 ファシリテーターの以下の問いかけで、ポストイットに仮定を書き出し、クラウド図 に貼る。 ①D’をすると、なぜ B ができないと思っているのですか？ ②D をすると、なぜ C ができないと思っているのですか？ ③D と D’はどういう時に対立しますか？ ④B と C の両立ができないと思っているのはなぜですか？ 3-3) それぞれの対立を作り出している仮定を頼りに、共通目標を達成するために、 17 双方の行動の理由を満足させるように考えることで、双方が納得できる解決策を 導き出す。 ファシリテーターの以下の問いかけでアイデアを発散させ、参加者はポストイットに 解決策を無記名で 1 件に１枚書き出す。 ①D’をすることで、B ができる方法は本当にないのでしょうか？ ②D をすることで、C ができる方法は本当にないのでしょうか？ ③ある条件では D、ある条件では D’というルールで両立させることはできませんか？ ④B と C の両立ができる方法が本当にないのでしょうか？ まずクラウド図の理由を崩す解決策を列挙する。 この段階では実現可能性や具体性を気にせず、できるだけ多くのアイデアを列挙する。 解決策は、行動ではなく、状態として表現する。 抽出した理由と対立の構造に着目し「変化」を実現することで対立を打破していく。 3-4) ファシリテーターがポストイットを集め、ホワイトボードに貼る。 3-5) 「縦軸に効果／横軸に難易度をとったマトリクス」のどこにポストイットを置くか ブレストする。 マトリクスの中に貼っていく。(ペイオフマトリクス手法) 3-6) 全体を見渡し、どこに重点があるのかを確認し、いちばん効果があると思うものを 選択する。 ペイオフマトリクス手法 ブレストなどで出てきたたくさんのアイデアから、どれを選んで実行するかを、できるだ け合理的に判断したい時に役に立つ手法である。 判断基準を 2 つ選んでアイデアを評価し、2 軸で可視化して意思決定を促す。 使い方： 1) 提案を評価する重要な軸を 2 軸選び、模造紙にそれらを軸にしたマトリクスをつくる。 (右上に優先順位の最も高いものがくるように軸を選ぶ) 2) ポストイットにアイデアを 1 件に１枚書き出す。 3) そのポストイットをマトリクスの中に貼りつけながら、位置づけを議論する。 4) 一番右上のものから順次目標を達成するところまで選定する。 参考資料 岸良 裕司、全体最適の問題解決入門、ﾀﾞｲﾔﾓﾝﾄﾞ社、2008 村上 悟、問題解決を｢見える化｣する本、中経出版、2008 ﾛｼﾞｬｰ･ﾌｲｯｼｬｰ/ｳｲﾘｱﾑ･ﾕｰﾘｰ 著、岩瀬 大輔 訳、ﾊｰﾊﾞｰﾄﾞ流交渉術、三笠書房、1998 森 時彦、ﾌｧｼﾘﾃｰﾀｰの道具箱―組織の問題解決に使えるﾊﾟﾜｰﾂｰﾙ 49、ﾀﾞｲﾔﾓﾝﾄﾞ社、2008 18 付録 6 ファシリテーションで作成した結果 (1) PTB ファシリテーション手法 ⅰ）PM タイプの定義 検証では、スキルや性格が異なる多様な PM のタイプを評価の対象とした。PM タイプの 定義付けには、IPA が発行する IT スキル標準(ITSS)にて規定されている 11 項目のスキル 領域を参考に、それぞれの優劣の組合せによって付表 9 に示す、典型的な 10 種類の PM タ イプ(ペルソナ)を定義した。 付表 9:検証に適用した PM タイプ PMのスキル領域の水準（IPA ITSSより抜粋) ファシリテーション対象者(PM)のタイプ 1 要求分析 ICT技術の 適用業務知 ｾｷｭﾘﾃｨ･ﾏﾈ 問題解決手 契約・法規・ ﾅﾚｯｼﾞ･ﾏﾈ ﾌｧｲﾅﾝｼﾝｸﾞ 活用 識の活用 ｼﾞﾒﾝﾄ 法の活用 ガイド ｼﾞﾒﾝﾄ ﾘｰﾀﾞｰｼｯﾌﾟ ｺﾐｭﾆｹｰｼｮﾝ ﾈｺﾞｼｴｰｼｮﾝ 標準タイプ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 2 ワンマンタイプ ○ ◎ ◎ ○ ◎ ○ ○ ○ ◎ × ○ 3 交渉が得意だが、技術が弱い ◎ × ○ ○ × ○ ○ ○ ○ ◎ ◎ 4 技術はあるがコミュニケーションが苦手 ○ ◎ ◎ ○ ○ ○ ○ ○ ○ × × 5 利益追求タイプ ○ ○ ○ ○ × ◎ ○ × ○ ○ ○ 6 納期遵守・品質確保・投資度外視 ○ ○ ○ ○ ◎ × ○ ◎ ○ ○ ○ 7 リスク回避型 ○ × ○ ◎ ○ ◎ ○ ◎ ○ ○ ○ 8 新人タイプ ○ ○ ○ × × × × × × ○ ○ 9 万能タイプ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ 10 現状満足型 ○ ○ ○ ○ × ○ ○ × ○ × ○ 【凡例】◎…高い水準で備わっている ○…標準的に備わっている ×…備わっていない（積極的に活用しない） ⅱ）不具合事例のサンプル 検証では、各 PM が担当する（と想定する）PJ が抱える過去トラ事例として、付表 10 に 示す 4 事例を用いた。これらは、2012 年度の SQiP 研究会第１分科会テーマ“KWS 振り返り” にて収集・分析された不具合 DB から採用した。 付表 10:検証に適用した不具合事例 前提条件 事例 人員 期間 工数 新規 業務 (人) (月) (人月) ／派生 種別 ① 5 ② 10 ③ ④ 7 6 3 15 新規 0 派生 20 28 140 168 派生 派生 - PJ/作業 詳細 原因となる事象 主語（～が） 述語（～されていない） システム仕様書の変更 充分レビューされていな PJ 車両制御 基本設計 箇所以外の部分 い テストスクリプトフォーム 作業 SST担当テスト 機能テスト 開発コメント欄 に設けられていない PJ S開発PJ-PA 要件定義 チームのPJにおける役割 明確になっていない PJ S開発PJ-PV 実装 コーディングルール 存在しない 不具合事例 フェーズ 納期遅れ 不具合流出 目標性能未達 不具合流出 ⅲ）検証結果の詳細 検証結果の詳細結果として、PM タイプ／不具合事例／質問群／評価基準別の結果および その集計結果を整理したものを付表 11 に示す。なお、付表 11 の結果は評価者である研究 員 3 名の評価結果の平均である。 付表 11:検証結果（全評価者の平均） ファシリテーション対 評価 象者(PM)のタイプ 基準 Q1～Q3 1 標準タイプ 2 ワンマンタイプ 交渉が得意だが、 3 技術が弱い 技術はあるがコミュ 4 ニケーションが苦手 5 利益追求タイプ 6 納期遵守・品質確 保・投資度外視 7 リスク回避型 8 新人タイプ 9 万能タイプ 10 現状満足型 集計（平均） A B A B A B A B A B A B A B A B A B A B A B 2.00 2.33 2.67 3.33 1.67 2.00 3.00 3.33 1.00 1.33 2.67 3.33 3.33 3.67 1.33 1.67 3.67 4.67 1.33 1.33 2.27 2.70 過去トラ① Q4,Q5 2.67 3.00 3.67 4.33 2.33 2.67 3.33 4.00 2.33 2.00 3.00 3.33 3.33 3.67 2.00 2.33 3.67 4.67 1.67 2.00 2.80 3.20 過去トラ② Q6/7 ～Q9 3.67 4.33 3.67 4.33 3.33 3.33 4.00 3.67 2.67 2.33 4.00 4.67 4.00 4.33 2.00 3.33 3.67 4.67 2.67 2.00 3.37 3.70 Q1～Q3 2.00 2.33 2.00 2.33 1.67 2.00 2.67 2.67 1.33 1.33 2.67 3.00 2.33 2.67 1.00 1.33 3.67 4.67 0.67 0.67 2.00 2.30 Q4,Q5 2.67 3.00 2.33 3.33 3.00 3.00 3.00 3.33 1.67 1.00 3.67 4.00 3.67 4.00 1.33 2.00 3.67 4.67 0.67 1.00 2.57 2.93 過去トラ③ Q6/7 ～Q9 3.67 4.33 3.33 4.33 3.33 3.00 3.67 3.67 2.33 2.00 4.67 4.67 4.00 4.33 2.00 3.67 3.67 4.67 2.67 2.00 3.33 3.67 19 Q1～Q3 2.00 2.33 2.00 1.67 3.00 4.00 1.67 2.00 1.33 2.00 2.67 3.33 3.00 3.33 1.33 1.33 3.67 4.67 0.67 1.00 2.13 2.57 Q4,Q5 2.67 3.00 2.67 2.33 3.33 4.00 2.00 2.33 2.33 2.33 3.33 3.67 3.33 3.67 1.67 1.67 3.67 4.67 1.33 1.67 2.63 2.93 過去トラ④ Q6/7 ～Q9 3.67 4.33 3.33 3.00 3.33 3.67 2.67 3.00 2.67 2.33 4.67 4.67 4.00 4.33 2.00 3.00 3.67 4.67 2.67 2.00 3.27 3.50 Q1～Q3 2.00 2.33 2.33 3.33 1.00 1.00 2.67 3.33 1.00 1.67 2.67 3.00 3.00 3.67 1.00 1.33 3.67 4.67 1.00 1.33 2.03 2.57 Q4,Q5 2.67 3.00 3.00 4.00 2.00 2.00 2.67 3.00 1.67 1.67 3.00 3.33 3.67 3.67 1.00 1.33 3.67 4.67 1.33 1.67 2.47 2.83 集計（平均） Q6/7 ～Q9 3.67 4.33 3.33 4.33 3.33 3.00 3.67 3.33 2.67 2.33 4.33 4.67 3.67 4.00 2.00 3.33 3.67 4.67 2.33 2.00 3.27 3.60 Q1～Q3 2.00 2.33 2.25 2.67 1.83 2.25 2.50 2.83 1.17 1.58 2.67 3.17 2.92 3.33 1.17 1.42 3.67 4.67 0.92 1.08 2.11 2.53 Q4,Q5 2.67 3.00 2.92 3.50 2.67 2.92 2.75 3.17 2.00 1.75 3.25 3.58 3.50 3.75 1.50 1.83 3.67 4.67 1.25 1.58 2.62 2.98 Q6/7 ～Q9 3.67 4.33 3.42 4.00 3.33 3.25 3.50 3.42 2.58 2.25 4.42 4.67 3.92 4.25 2.00 3.33 3.67 4.67 2.58 2.00 3.31 3.62 また、付表 11 の結果を不具合事例別、PM タイプ別の視点でそれぞれグラフ化したもの を付図 7、8 に示す。 A：問題への気付き 5 Q1～Q3 Q4,Q5 Q6/7～Q9 4 B：結果への納得感 5 Q1～Q3 Q4,Q5 Q6/7～Q9 4 3 評点 評点 3 2 2 1 1 0 0 過去トラ① 過去トラ② 過去トラ③ 過去トラ① 過去トラ④ 過去トラ② 過去トラ③ 過去トラ④ (a)基準 A に対する評価結果 (b)基準 B に対する評価結果 付図 7:不具合事例別に整理した評価結果 5 A：問題への気付き 4 3 2 1 0 Q1～Q3 Q4,Q5 Q6/7～Q9 (a)基準 A に対する評価結果 5 B：結果への納得感 4 3 2 1 0 Q1～Q3 Q4,Q5 Q6/7～Q9 (b)基準 B に対する評価結果 付図 8:PM タイプ別に整理した評価結果 参考資料 IPA、IT スキル標準(PM)、http://www.ipa.go.jp/files/000010335.pdf 花原、伴野 他 著、 “KWS 振り返りで得られた知識と知恵を、組織的に活用する仕組みの 研究”、第 28 年度ソフトウェア品質管理研究会分科会報告書、第 1 分科会、日科技連、 2013 <http://www.juse.or.jp/software/444/attachs/SQiP1-B.pdf> 20 (2) GS ファシリテーション手法 GS ファシリテーション手法を実施した際に作成したブランチ図を以下に紹介する。 事例1 事例2 担当を外される 客の信用をなくす （以降、レビューの結末と同じ） 客の信用がなくなる 開発が終わらない 客の要望に応えられなくなる 後戻りするから 納期が遅れるかも知れない 日程調整が必要になる 開発の最後に作業が集中する 計画が計画でなくなる レビューと同じ結末 メンバーのやる気かがなくなる 客の要望に応えられなくなる 無駄な工数が発生する 可能性がある 不具合を発生させるかも知れない 不要なものを作るかも知れない 違うものを作るかも知れない 開発がいつまでたっても終わらない 不具合が発生するかも知れない 設計などのやり直しが発生する 今のレビュー（毎回３回程度実施） だとどうなるの 不具合が残ったままに なるかも知れない 今の要求分析を続ける 導入のために最初に使用した事例 事例3 将来、生活できなくなる リーダーはこの場にいられなくなる （居場所が無くなる） 仕事が無くなる メンバーはリーダーを 無視するようになる プロジェクトを 任せてもらえなくなる プロジェクトが失敗する 開発が完了した場合、 メンバーは今のリーダーは 不要だと思う 失敗した場合、 メンバーはリーダーに 責任を押しつける 仕事に対する モチベーションが下がる 益々メンバーの判断で開発が進む 遅れた場合に 気付かないかも知れない あとからやることが 出てくるかも知れない 細かなことは メンバーの判断になる 仕事をするのがつらくなる 早く帰りたくなる 次のプロジェクトでも 余裕が無くなる 自分の時間が減る 残業が増える スケジュールを メンバーに作成して貰う このままでいる 付図 9:ファシリテーション結果(ブランチ図) 21 (3) MS ファシリテーション手法 事例 1～5 のクラウド図を付図 10～14 に示す。 付図 10：事例 1 のクラウド図 付図 11：事例 2 のクラウド図 22 付図 12：事例 3 のクラウド図 付図 13：事例 4 のクラウド図 付図 14：事例 5 のクラウド図 23