SQiP シンポジウム 2009 プロジェクトを成功させるためのチーム作りの考察と実践 Consideration and practice of team making to make project succeed 株式会社日立システムアンドサービス 品質保証部 Hitachi Systems & Services, Ltd. Quality Assurance Department 鵜飼 智徳 1) 丹羽 敬子 1) 成田 弘幸 2) ○高橋 敏浩 1) ○Toshihiro Takahashi Tomonori Ukai Keiko Niwa Hiroyuki Narita Abstract Troubled Projects has not disappeared though the management theory has developed. The troubled project is generated, and the project manager makes an effort to solve it everyday. One of the most significant obstacles is "Issues Concerning people" to proceed with the project smoothly. It is difficult for only the project manager to overcome it. Therefore the person or organization that supports the project is necessary. In this paper, we call the person or organization, which keeps better relationship between the project manager and team members, project facilitator, and show the effect of the project facilitator. １．はじめに マネジメント理論が普及した現在でも、トラブルプロジェクトは減少する傾向にない。この事実は、 プロジェクトマネージャ（以下ＰＭ）が体系的なマネジメント理論を手には入れたが、それだけでは 何かが足りないことを意味する。 プロジェクトマネジメントは不確実で曖昧なものを、徐々に確実で明確なものにしていく。この過 程でＰＭは決断を繰り返していくが、時として決断に誤りがあるかもしれない。またはメンバが前向 きに受け入れてくれないかもしれない。決断の間違いやメンバの不満の多くは「人に関する問題」を 解決しようとするときに起きやすい。プロジェクトで発生する問題の多くは、この「人に関する問題」 にある。 このようにプロジェクトを成功させるためには「人」が肝心となるが、ＰＭの「人」に対しての思 慮が足りないとき、コンフリクト（対立、衝突）が起こる。その時にＰＭを手助けしたり、ＰＭとメ ンバの関係を調整したりする人（または組織）が必要となる。ＰＭとメンバの良好な関係、チームワ ークの向上を中心に考える人（または組織）をプロジェクトファシリテータ（以下ＰＦ）[1]と呼ぶこ とにする。ＰＦは、ＰＭの考慮不足や伝達ミスを補正する。更にメンバ間のコンフリクトの調整や解 決を促し、メンバのやる気を維持、向上させることを目的とする。 本稿では、開発総人月約３８０人月（ピーク時約４０人）、開発期間約１年のプロジェクトを対象に、 ＰＭとメンバの思考のずれを分析する。その上で社会学や心理学などの知見を参考にプロジェクトを 成功させるための効果的なチーム作りを考察し、その運用方法について述べる。 ２．現状分析 ２．１．ＰＭとメンバのずれ プロジェクト開始時から疲れている、やる気をなくしているチームは少ない。しかし、それは目標 （品質／コスト／納期）に現実感がないからである。プロジェクトが進むにつれ、スケジュールが遅 れたり、仕様変更が起きたり、テストで不良が予測以上に出たりして、目標未達に現実感が出てくる。 これらの原因は様々であるが、プロジェクトに状況変化が起こるのは自然の摂理である。この状況変 化とともに、チームにはコンフリクトが起きる。このコンフリクト解決の方向がチームワークに影響 を与える。予め、ＰＭが現実感のある目標をチームに与え、変化を予測し、コンフリクトの解決に強 いチーム作りを考えれば、チームの結束は揺るがない。 チームの結束は「目標」から生まれ、 「協力」や「信頼」から育まれる。逆に「目標」と「協力」と 「信頼」にメンバ間で誤解や認識のずれがあるとチームは結束しない。 1) 株式会社日立システムアンドサービス 品質保証部 Quality Assurance Department , Hitachi Systems & Services, Ltd. 東京都品川区南大井 6-23-1 Tel: 03-3763-1131 6-23-1, Minamiooi, Shinagawa, Tokyo Japan Tel: 03-3763-1131 2) 株式会社日立システムアンドサービス 交通第１システム部 Transportation Information Systems Department 1 , Hitachi Systems & Services, Ltd. SQiP シンポジウム 2009 プロジェクト開始時に、「目標」と「協力」と「信頼」にＰＭとメンバで差異がないか考えてみた。 表１にＰＭとメンバの「目標」 、「協力」 、 「信頼」のずれを示す。 表１ ＰＭとメンバの「目標」 、「協力」 、 「信頼」のずれ 項 分類 プロダクト又は ＰＭ メンバ ずれ 番 プロセス １ 目標 スケジュール プロジェクト開始時に決定 プロジェクト開始時に決定 なし ２ 品質 量的基準に従う 量的基準に従う なし ３ 予算 プロジェクト開始時に決定 考慮なし 有 ４ 協力 仕様書レビュー 不参加 参加して欲しい 有 ５ 顧客仕様調整 やらない やってほしい 有 ６ スケジュールの調整 やらない やってほしい 有 ７ 信頼 各種会議 権力行使の場 相談の場 有 ８ 関係 上司と部下 パートナー 有 （１）目標 目標は当初ＰＭとメンバで大きなずれはない。プロジェクト発足時のスケジュールについては、メ ンバに現実感がない場合が多いが納得はしている。また品質についても、開発ステップ数あたりのバ グ数が工程ごとに示されており、その値はそれなりにベンチマークした値を使用しているため、メン バは反論の余地がない。但し、ずれはないが目標について現実感がないことは問題である。 メンバがプロジェクト開始から目標に現実感を持つためには、ＰＭが「ビジョン」を明確にするこ とが必要である。その上でＰＭはスケジュールを説明し、チームで共有することが重要となる。 尚、本プロジェクトではプロジェクトを開始した時点で、ＰＭは既に「ビジョン」を決め、メンバ に伝えていた。その「ビジョン」は「品質至上主義、絶対社外事故を出さない」である。これはチー ム作りの点から見てもプロジェクト序盤におけるＰＭの最も大きな功績である。トム・デマルコも「品 質至上主義はチームを結束されるための中心的関心事となる。」と述べている[2]。 また、唯一相違している予算は意図的にＰＭが公表していない場合が多い。チームの結束を考えた 場合、予算はそれほど重要な要素ではないと考えるため、ここでは特に問題視しない。 （２）協力 チームの協力は様々な場面で必要になる。本稿ではＰＭとメンバが知恵を出し合うレビューと、状 況変化に対応する時の調整について考えた。その場合、全ての項目にずれがあった。 本プロジェクトでの仕様書のレビューは、 「詳細設計書」 、 「結合テストチェックリスト」、 「総合テス トチェックリスト」が主なものである。これらのレビューは顧客から細かい業務仕様や、顧客が抱く 品質について直接聞ける重要な機会である。当然メンバはＰＭに参加して欲しいと考えているが、現 実はそうなっていない。 また顧客との仕様調整においても同様である。メンバは全ての解決をＰＭに望むが、現実はそうで はない。ＰＭもすべての解決を自分ですべきではない。難しいのは「さじ加減」であり、このさじ加 減をＰＭが誤ると、 「マル投げＰＭ」や「ワンマンＰＭ」と呼ばれ、メンバの協力や信頼は得られない。 （３）信頼 協力で差異があるもの同士が信頼しようとするのは無理がある。その結果各種の会議（特に進捗会 議）は、メンバから「儀式的な会議」であるとか、ＰＭの「権力行使の場」に受け止められる。 本来チームはみんなで考え、意見を出し合い、チームとして進むべき方向を決めた時に、信頼（チ ームワーク）が生まれる。その際ＰＭもメンバも、お互いをパートナーとして捉えることができれば 最良である。しかし、ＰＭが意識的であろうとなかろうと、メンバと協調せずにトップダウンで進む べき道を決定したとき、メンバは「やらされ感」を抱きやすくなる。 ２．２．ずれを埋める人（または組織）の必要性 ２．１項のずれを見るとチームが結束するうえでの阻害要因がわかってきた。その阻害要因からＰ Ｍの「やるべきこと」を見た場合、プロジェクトのサイズによってはＰＭひとりの力では達成が難し い場合がある。実現に向け、助けたり、調整したりする人（または組織）が必要となる。本稿ではそ の役割を持つ人（または組織）をＰＦと呼び、ＰＦが考えるべき要素を以下とする。 （ａ）チーム構成を理想的な形にする（チーム構成の検証と変更） （ｂ）会議を理想的な形にする（会議体での意見調整役と運営改善） （ｃ）プロジェクト状況の「見せる化」 （メンバへの内発的動機付け） 表２にチーム結束の阻害要因とＰＭ、およびＰＦのやるべきことを纏める。 SQiP シンポジウム 2009 表２ チーム結束の阻害要因とＰＭ、およびＰＦのやるべきこと チーム結束の阻害要因 ＰＭがやるべきこと ＰＦがやるべきこと プロジェクト序盤で目標に現実感 「ビジョン」を明確にする － がない ２ 刻々と迫る目標達成へのプレッシ メンバ同士で協力し合いやす チーム構成の検証と変 ャーに受入れ準備が整っていない いチーム構成を形成する 更 ３ ＰＭとメンバで協力と信頼にずれ メンバの心配事、不満事を聞 会議体の運営改善と意 がある き、メンバ同士で助けあう 見調整 ４ トップダウンで物事を決定したと メンバのやる気を維持、向上 メンバへの内発的動機 き、メンバは｢やらされ感｣を抱く させる 付け 表２の項番１「ビジョン」を明確にする点については、本プロジェクトにおいてＰＭは既に実施済 みであり、最大の功績である（２．１項（１）で記述）。そのため「ビジョン」作りについてＰＦは、 特に何もする必要がないと判断した。しかし、 「ビジョン」がないとチーム作りや、チームの結束は難 しいことをＰＭおよびＰＦは認識するべきである。 項番 １ ３．各要素の検証と変更 ３．１．チーム構成の検証と変更 ３．１．１．チーム構成の検証 ＰＭは開発規模と機能を中心にチーム構成を検討する。ここではＰＭが作ったチーム構成を人の面 から検証してみた。検証後にチーム構成を変更することになったが、その際はプログラム群が持つ機 能の特性、独立性も考慮した。しかしながら本稿では「人に関する問題」がテーマであるため、その 部分の説明は必要最低限にとどめておく。 （１）チーム構成の検証 この検証では人の持つ心理的距離を使った。板倉稔氏の著書[3]でＥ．ホール教授と国際パフォーマ ンス研究所の研究結果が述べられている。表３に引用する。 表３ 心理的距離 心理的距離 距離（国際パフォーマンス研究所） （Ｅ．ホール） アメリカ 日本 名称 意味 （ｃｍ） （ｃｍ） （ｃｍ） 密接距離 愛情・親子 １５～４５ ４６ ５９ 固体距離 縄張りを維持しつつ親しい会話 ４５～１２０ １２２ ７０．５ 社会距離 格式張った社交、ビジネス １２０～３６０ ３６０ ９８ 公衆距離 演説調 ３６０～ ３６８ １１３ 更にその著書では、会議の人数ごとに人と人の距離を計算し、次のように言っている。 ・密接距離で会議ができるのは２人まで ・固体距離で親しい会話ができるのは３人から５人まで ・六人以上になると、社会距離のパスができてしまう ・七人以上になると、社会距離のパス数が急に増える 本プロジェクトのチーム階層は「ＰＭとサブリーダ」、 「サブリーダと担当」の２階層となっている。 それぞれの階層の主なコミュニケーションを考えていく。 ＰＭとサブリーダとの重要なコミュニケーションは二つある。一つ目は各サブリーダからの進捗状 況や品質状況の報告を受け、情報を正確にかつ主体的に共有すること。二つ目は各サブリーダと問題 解決のための最適な方法を見つけ、効率的な作業を考えることである。これらの多くは会議（打合せ） で解決するものである。そのため会議での活発な意見交換、正確な状況把握が必要になってくる。そ のため社会距離が保てる人数（６人以下）が最も良いと考える。 これに対して、サブリーダと担当者の間は、実際にモノ作りする単位となる。ここは生産性向上が 要求される。そのため固体距離（５人以下）が望ましいと考える。 ３．１．２．チーム構成の変更 （１）実際に組替えたチーム 表４に当初ＰＭが考えていたピーク時の予想チーム構成、表５に実際に組替えたチーム構成を示す。 表４の問題は、サブリーダ対担当者が固体距離（５人以下）を保てないところにあった。そこで今 後サブリーダ経験を積ませたい担当者を積極的にサブリーダにすることで対応した。この対応でサブ リーダの数が増えたため、ＰＭとサブリーダ間の社会距離（６人以下）が保てない問題が発生した。 ここではサブリーダのうち経験豊富な人を統括サブリーダとすることで対応した。 SQiP シンポジウム 2009 ＰＭ 数 １ 表４ 当初ＰＭが考えていたピーク時の予想チーム構成 チーム サブ 担当者 リーダ数 数 チームの主な担当機能 Ａ １ １０ トランザクションコントロール Ｂ １ ４ 入力編集／入力検定 Ｃ １ １ 出力制御 Ｄ １ ９ 出力１ Ｅ １ ７ 出力２ 表５ 実際に組替えたチーム構成 統括サブ サブリー 担当者 リーダ数 ダ数 数 チームの主な担当機能 Ａ－１ （１） ４ トランザクションコントロール１ １ Ａ－２ １ ３ トランザクションコントロール２ Ａ－３ １ １ 集計更新／ジャーナル編集 Ｂ １ （１） ４ 入力編集／入力検定 Ｃ １ （１） １ 出力制御 Ｄ－１ （１） ３ 出力１－１ １ Ｄ－２ １ ２ 出力１－２ Ｄ－３ １ ２ 出力１－３ １ Ｅ－１ （１） ３ 出力２－１ Ｅ－２ １ ３ 出力２－２ （ ）は統括サブリーダとの兼任 表５では、ＰＭ対統括サブリーダは１対５になり、統括サブリーダ対サブリーダは最大でも１対 ２となり、各層とも社会距離（６人以下）以下を保てる。一方で階層が２から３に増えたが、統括サ ブリーダ対サブリーダ間、サブリーダ対担当者間のそれぞれを固体距離（５人以下）にしたことで伝 達ミスを防ぐことが可能である。 このような体制にすることで、理想的なチーム構成になったと考える。 （２）チーム構成のエッセンス チーム構成を無機質に理想的な形にする ＰＭ サブリーダ 担当者 だけでは、メンバの不満が発生する。例え ば今までの担当の仕事から、サブリーダの ＰＦ 仕事が降りかかり不満を持つ人が出るかも しれない。あるいは、チームの細分化によ ・ ＰＭのサポート ・ サブリーダとのコミュニケーション り技術的なインタフェースの隙間が出るか ・ 顧客とのコミュニケーション もしれない。そのため、ＰＦの他に技術的 にそれらを埋める人を設けた。 ＴＭ それをテクニカルマネージャ（以下ＴＭ） と称し、各サブリーダの技術面をサポート、 ・ 技術面のサポート ・ 各種レビューの実行責任者 調整する役割を担った。図１に体制と役割 分担を示す。 図１ 体制と役割分担 ＰＭ 数 １ チーム ３．２．会議体の運営改善と意見調整 ３．２．１．有効な会議 ここではチームの結束に必要な会議とはなにかを考えた。有効な会議を以下に示す。 ・会議に出席している全員が問題解決意識を持つ会議 ・個人攻撃ではなく、問題に対して攻撃する会議 ・問題解決に必要な場合のみ開催する（非定期に開催される）会議 逆にチームの結束を阻害する会議も以下に列挙しておく。 ・大人数（１０人以上）の会議 ・ＰＭに報告するだけの会議（儀式的会議） ・定期的に実施する２時間以上の会議 当然この考え方にも定理がある。大人数の会議になると自分はやらなくても支障がないと考える「社 会的手抜き」が発生したり、役職などの目に見えない圧力に「集団圧力・同調行動」したりするのが チームの結束を阻害する会議とされている。 SQiP シンポジウム 2009 ３．２．２．会議体の運営改善と意見調整 本プロジェクト内で行われる主な会議体と出席者、および運用改善点を表６に示す。ここでは上位 マネージャや会社幹部（以下プロジェクトスポンサー）への報告会議は含まない。 表６ 主な会議体と出席者、および運用改善点 項番 主催 会議名 会議内容 主な出席者 頻度 参加人数 運用改善点 １ 顧客 各種 詳細設計書、 顧客 非定期 ７人以下 ＰＦが出席する レビュー チェックリスト リーダ以下 ことにした のレビュー メーカ サブリーダ ２ チーム 各種 詳細設計書、 サブリーダ 非定期 ５人以下 ＴＭが承認する レビュー チェックリスト ことにした のレビュー ３ 顧客 プロジェ 進捗、品質につ 顧客 週１回 ７人以下 原則ＰＦのみが クト内 いて リーダ以下 出席することに 工程会議 メーカ した サブリーダ ４ チーム プロジェ 進捗、品質につ ＰＭ 週１回 １０人 中止した クト内 いて サブリーダ 以上 工程会議 （１）各種レビュー 顧客との各種レビューは、サブリーダのみが対応していた。このレビューは、設計書は数千ページ、 チェックリストは数万件となり、時間がかかる。但し、このレビューでは設計書の妥当性確認や、チ ェックリストの網羅性確認が行われる。そのため、この会議は顧客の要求している事柄や品質を聞け る機会でもある。顧客が持つ業務仕様の暗黙知やメーカ側への品質要求を聞き出すためにＰＦが出席 することにした。 またチーム内の各種レビューは、レビュー承認者をＴＭとした。これは二つの目的がある。一つ目 はＴＭのやる気を維持、向上させるために責任と権限を持たせたことである。二つ目はメンバが技術 的に困っていることを早期に吸い上げるためである。 （２）プロジェクト内工程会議 顧客とのプロジェクト内工程会議は基本的にＰＦのみが出席することにした。これはサブリーダに 余計な負担をかけないためである。但し、実際はリーダの育成のため、今後のＰＭ候補ひとりを同行 させた。またチームのプロジェクト内工程会議は、中止することにした。それはチームの結束を阻害 する会議条件の全ての項目に、合致するからである。 （３）朝ミーティングの実施 チームのプロジェクト内工程会議を中止した代わりに、朝ミーティングを開いた。目的はメンバの 生活リズムの一定化による生産性向上と、即時状況把握によるコンフリクト解決の速度向上である。 このミーティングの留意点は「決まった時間に」、 「短い時間で」行うところにある。 そのため、毎日９：３０からＰＦとサブリーダ、毎日１０：００からサブリーダと担当者がスタン ドアップミーティングをすることとした。 更に顧客リーダとも毎日１０：００からミーティングをすることにした。このミーティングはタイ ムリーな状況報告はもとより、顧客リーダとＰＦが一層親密な関係になることを狙った。顧客リーダ に呉越同舟する意識を持って貰い、コンフリクト発生時にプロジェクトとして最も良い解を選択しや すいようにするためである。当然、人数は顧客１人と我々２人とし、限りなく密接距離（２人以下） に近い固体距離（５人以下）でミーティングした。 ３．３．メンバへの内発的動機付け プロジェクトの「見える化」について昨今叫ばれている。ただし「見える化」の対象はプロジェク トスポンサーであったり、上位マネージャであったり、管理チームに対してであったりする。 ここでは、チームが活気付くための「見える化」を考える。また「見える化」の行為は、チームか ら「見える」情報を意図的に発信するため、能動態の「見せる化」と呼ぶ事にする。 「見せる化」はチームが活気付くことを目標としている。そのためには情報を見たメンバがやる気 や助け合いの気持ちが芽生えないと意味が無い。「見せる化」については、行動分析学を使ってみた。 ３．３．１．行動分析学 行動分析学[4]では、 「行動の真の原因は行動の直後にある」と言われ、行動の直後とは「６０秒ルー ル」と定義されている。言い換えれば行動してから６０秒以内になにも変化がなければ、それは真の SQiP シンポジウム 2009 原因とはならないということである。人の行動の原因は行動の直前から直後への状況変化にあると考 える。少しわかりにくいので図２に行動分 ■好子（こうし）出現の強化 析学の具体例を示す。 直後の行動 直前の行動 行動（原因） 行動分析学では、直前から直後への状況 Ａさんが私に笑 私の笑顔がない 私も笑顔になる 変化をもたらす行動を原因と考えている。 顔で挨拶する 好子とは「直後の行動を増やす刺激や出来 ■嫌子（けんし）出現の弱化 事」で、嫌子とは「直後の行動を減らす刺 直後の行動 直前の行動 行動（原因） 激や出来事」である。 部下が帰り支度 部下が帰り支度 課長が嫌味を 図２の好子出現の強化は、私の「笑顔が をする をやめる 言う ない状態」から、Ａさんの行動「挨拶」で、 図２ 行動分析学の具体例 私の「笑顔が増えた」訳である。その反対 に嫌子出現の弱化は、帰り支度を課長の行動で止めた訳である。チームが活気付くためには、好子を 使えば良いと考えた。 ３．３．２． 「見せる化」の具体例 （１）信頼度成長曲線 テスト工程でプロジェクトの状況が一目でわかるグラフは、チェックリストの消化とバグの発生を 時系列で表したものであろう。今はバグ管理ツールが普及し、個人のＰＣ上で簡単に見ることができ るようになった。しかしこれではチーム全員で一緒に見ることはできない。そこで紙で張り出し、チ ーム全員が一緒に、同時に見ることができる形を作った。毎日、朝ミーティングすることは前章で述 べたが、このミーティング時に全員で一緒に見て、このグラフを好子として使用した。そしてメンバ の毎日の行動にやる気を増やした。 （２）レビュー管理表 ■一般的な管理表 進捗を管理するときに使う表は、人を 項 仕様書 担当者 ページ 作成 レビュー 不良 番 名称 数 予定 実績 予定 実績 指摘 修正 中心に考えていない場合がある。最たる 1 ａ Ａ ５０ 10/11 10/12 5 2 ｂ Ａ ２０ 10/11 10/13 2 ものがレビュー日程の管理である。 3 ｃ Ｂ ３０ 10/11 10/14 3 レビューは人が行うのに対して、日程 n ｄｄｄ Ｚ ５５ 10/11 10/15 6 管理表は仕様書ありきで作成されている。 つまり、日程管理表は第１キーを仕様書 ■カレンダ形式の管理表 名称にして、表の１行が出来上がる。開 発規模が４００Ｋｓ程度のプロジェクト 日 月 火 水 木 金 土 1 2 3 4 5 6 の詳細設計書やテーブル仕様書などは、 13:30-17:30◎ 10:30-12:00◎ 内部 15:30-17:30 13:30-15:00◎ 10:30-12:00◎ トランザクションコン 出力制御（CL) トランザクションコン 入力検定（CL) 入力検定（CL) 表の行が約１００行出来上がる。 トロール１（CL) 榎本/水谷 トロール２（CL)→再 長田 長田 遠藤/町田/鈴木 石橋/町田 確かにＰＭやＰＦなど管理する側から 15:30-17:30◎ 13:15-14:45 ジ ャ ー ナ ル 編 集 出力２－１（CL) 沢井/神田 （CL) 見れば、一覧で見ることができ、結果を 上田/脇田/竹田 外部 13:30-15:20 14:00-16:00 集計するためには使いやすい。 出力１－３（CL) 集計更新（FS) 沢井/野口 上田/脇田/長谷部 /内藤 反面、レビューの日程設定をするメン バのためや、工程を守るメンバの意識向 上のためには、効果が薄い。これらの効 7 8 9 10 11 12 13 13:30-17:30 内部 15:30-17:30 13:30-15:00◎ 10:30-12:00◎ 10:30-12:00◎ 果を高めるためには、人が普段から見慣 出力制御（CL)再 中間品質評価報告 出力制御（CL) 入力検定（CL) 出力制御（CL) 榎本/水谷/長谷部 長田 清水/長田/等々力 水谷/三輪 水谷/三輪 れているカレンダ形式が望ましい。 15:30-17:30◎ 17:00-18:00 13:15-14:45 出力２－２（CL) トランザクションコン 出力１－１（CL) カレンダ形式にすることで、メンバは 桑原/原田 滝沢/桜井/木場 トロール１（CL) 笹原/遠藤/町田 いつまでにドキュメントを作成しないと 外部 10:00-12:00 10:00-12:00 13:30-15:30 出力制御（CL) 出力２－１（CL) 出力２－１（CL) レビューができなくなるなど工程を守る 榎本/藤田/束竹 沢井/水野/野土 沢井/水野/野土 18:30-20:00 16:00-18:00 ことに対しても前向きになる。図３に、 トランザクションコン 異 常 系 試 験 レ ビ ュ ト ロ ー ル 全 体 打 ちー 一般的な管理表と本プロジェクトで使用 合わせ リーダ全員 したカレンダ形式の管理表を示す。 図３ 一般的な管理表とカレンダ形式の管理表 ４．評価 ４．１．チームワークの評価 ２．２項の表２で定義したＰＦがやるべきことに対しての実施事項と主な効果について表７に纏め る。 SQiP シンポジウム 2009 ＰＦがやるべきこと チーム構成の検証と変更 表７ ＰＦの実施事項と主な効果 使用した法則など 人の持つ心理的距離の適用 ２ 会議体の運営改善と意見調整 有効／無効な会議の選定 ３ メンバへの内発的動機付け 行動分析の「好子」の使用 項番 １ 実施事項と主な効果 チーム組替えによるコミュニ ケーションの活性化 儀式的な会議の廃止による協 力関係の助長 メンバのための「見せる化」 による「やる気」向上 （１） 「チーム構成の検証と変更」についての評価 （ａ）チーム構成変更の評価 人の持つ心理的距離に基づいてチーム構成を考え、ＰＦ対サブリーダを社会距離（６人以下）、サブ リーダ対担当者を固体距離（５人以下）とした。 この構成はサブリーダ対担当者で大きな効果を発揮した。固体距離（５人以下）は、昔の師弟関係 の距離と同じで、モノ作りする際の最適距離であると考える。これは、当然コーディング工程以降に 生産性向上効果が表れるが、本プロジェクトでは特に結合テスト以降のバグ解決速度に効果があり、 バグは原則即日対応となった。またバグ対応の際には、適切な修正の仕方や類似見直しの仕方が、サ ブリーダから若手担当者へ師弟関係のごとく引き継がれた。 （ｂ）ＴＭ登用の評価 各種レビューの実行責任者を１人置いたことで、チーム間の技術的な隙間を埋めることが可能とな った。品質面ではドキュメント記述内容の均一化が図れ、処理もれやモジュール間インタフェース不 正も設計工程で取り除くことができた。また、ＴＭは本システムに深い知識を持っていたため、冗長 なコーディングや、今後バグを誘発しやすいコーディングの排除にも一役買った。 （２） 「会議体の運営改善と意見調整」についての評価 （ａ）会議体の運営改善の評価 チームメンバにとって最も有効だった会議体の運用改善は、チーム内の工程会議を止め、朝ミーテ ィングを実施した点である。これによりサブリーダは、以下の２つのストレスから解放された。 一つ目は、週１回の報告用資料作成ストレスからの解放である。技術者にとって資料作成に割かれ るこの時間は、報告資料の記述方を学ぶと言う側面では意味があるが、多くの場合は知的作業（設計 作業やテスト設計作業）の妨げとなる。 二つ目は、課題解決ストレスからの早期解放である。サブリーダは週１回の紙媒体での報告では、 見栄やプライドがあり、課題の解決結果を報告したがる。優秀と呼ばれる技術者ほどこの傾向は強く、 自分で解決までの全ての責任を背負いたがる。しかし毎日の朝ミーティングの口頭報告では、解決で きるかもしれない誰かが目の前に並んでいるため、とにかく自分の抱える課題を他者に連絡するよう になる。早い段階で課題を共有することで、当事者のみが課題を抱えるストレスから解放され、更に 他者から解決のアドバイスをもらえる可能性も広がった。 （ｂ）意見調整の評価 ＰＦは様々な会議で意見調整をすることになるが、ＰＦにとっては顧客リーダとの朝ミーティング が特に有効であった。顧客リーダと毎日顔を合わせていると、互いのコミュニケーションの思考回路 が形成され、良い理解者になってくれる。月１回の顧客幹部へのプロジェクト状況報告時に顧客リー ダは、必ずと言って良いほど、我々を支えてくれた。 （３） 「メンバへの内発的動機付け」についての評価 メンバの「やる気」を定量的に評価するのは難しい。確かに信頼度成長曲線を前に議論するメンバ が増えたし、レビュー管理表を適用してからは、レビューはほぼ予通り進んだ実績がある。しかしこ れらから「やる気」を評価するのは当たり前すぎる。チームやメンバの「やる気」は、ＰＭやＰＦが 望む期待値を良い方向で裏切られることで測れる。それを表す象徴的な出来事を２つ紹介する。 （ａ）罰金制度 結合テスト開始直後に、ある日突然、罰金制度がメンバの中から生まれていた。罰金制度とは「遅 刻」などのモラル面で失敗した時や、 「初期化もれ」のような単純なバグが見つかったなど技術面で失 敗した時に、当事者が罰金を払う制度ということだった。 この制度は、３．３．１項で述べた行動分析学の嫌子を使用している。ＰＦが使用した好子とは反 対の行動を強化するものであった。しかし、メンバからボトムアップで生まれたこの制度を聞いたと き、我々はプロジェクトの成功を感じた。なお、貯まったお金は、チームのオフサイトミーティング 時に使用した。 SQiP シンポジウム 2009 （ｂ）担当者の前向きな進言 チームの結束とメンバのやる気の好循環が予期せぬ副産物を生んだ。それは自らサブリーダ的業務 を申し出てくる担当者が出てきたことだ。ＰＦは朝ミーティングにサブリーダが出席できないときな どに担当者と直接会話する機会がある。その際、チームを超えた問題提起や解決策提案を申し出して くれる担当者が数人出てきた。 ４．２．納期、品質、コスト面の評価 プロジェクトの結果は「納期」と「品質」と「コスト」で評価される。しかしこれらはチームワー クの他、見積もりや、アーキテクチャや、スポンサーなど多くの要素の結晶である。今回の施策は「納 期」と「品質」と「コスト」の銀弾ではないことを前提にプロジェクトの結果を述べていく。 （１）納期（スケジュール） 本プロジェクトは納期遅延することなく終了した。以下にＰＦとして参画してからの各工程の最大 遅延日数を示す。 ・詳細設計工程：２週間遅れ ・コーディング、机上デバック（以下ＤＤ）工程：２週間遅れ ・結合テスト工程：２週間遅れ 各工程とも工程途中では遅れが発生しているが、当該工程内で回復することができ、マイルストー ンを守ることができた。 （２）品質 表８に一般的なプロジェクトの不良率（不良数／開発対象規模（Ｋｓ） ）を１００とした場合の相対 評価によるテスト工程の品質データを示す。一般的なプロジェクトと比べ、各工程とも不良率は低い 数値で推移した。各チェックリスト品質は顧客レビュー済みで定量、定性両面で十分性を確認してい る。このことから上流工程で品質の作り込みが図れたと判断している。 表８ テスト工程の品質データ 工程 項番 分類 ＤＤ＋単体テスト 結合テスト 総合テスト １ 本プロジェクト ７４ ５６ ３５ ２ 一般的なプロジェクト １００ １００ １００ （３）コスト コストは組織の売上データであり、詳細を明かすことはできない。しかし、同一顧客で、類似の開 発内容（開発規模も同程度）のプロジェクトと比較した場合、本施策が最も効果を発揮する結合テス ト工程において１１人月相当のコスト低減をできた。 ５．結言 本稿では、 「人に関する問題」について社会学や心理学の定理を参考に、実際のプロジェクトで適用 してみた。適用した施策のひとつひとつはベテランＰＭにとっては古臭く、以前から実施済みかもし れない。しかし、プロジェクト開始から終了まで「人に関する問題」を一貫して考え、実行したこと は初めてである。 「人に関する問題」を考え、実行することはプロジェクト成功への重要な要素の一つ であり、またチームメンバの喜びにも繋がることを証明した。更に「チームワーク」と「人のやる気」 が好循環すると、ＰＭやＰＦの考えてもいない良い結果が生み出される場合があることもわかった。 「人に関する問題」の解決策は、その特性から決まった形はなく、方法は無限にある。そのため、 マニュアル化は難しい。今後は、本稿での結果を他のプロジェクトでも適用し、更なる法則化を考え ていく必要がある。 ６．参考文献 [１]平鍋健児:2008 年度(第 24 年度)ソフトウェア品質管理研究会 第 3 回例会 特別講義 「現場力を高める見える化手法プロジェクトファシリテーション ～モチベーションアップのツールと場づくり～」,2008 [２]トム・デマルコ、ティモシー・リスター: 「ピープルウエア第２版 ヤル気こそプロジェクト成功の鍵」,日経ＢＰ社,pp196,2001 [３]板倉稔、橋本惠ニ:「スーパーＳＥがすすめる 知のモデリング」, 日科技連出版社,pp133-134,1996 [４]舞田竜宣、杉山尚子:「行動分析学マネジメント 人と組織を変える方法論」, 日本経済新聞出版社,pp17,2008
© Copyright 2026 Paperzz
