問2 チーム内コミュニケーション課題の解決と円滑なプロジェクト推進

テーマ：チーム内コミュニケーション課題の解決と円滑なプロジェクト推進

左右2分割表示：左側の問題文をスクロールしながら右側の設問に解答できます

長文事例本文

図表クリックで拡大

問2　プロジェクトにおけるコミュニケーションに関する次の記述を読んで，設問1〜3に答えよ。

　システム開発会社のP社は，10年前に開発した放送事業者A社の放送番組編成支援システムの追加開発を担当している。追加開発は，A社との間で請負契約を結んで，半年サイクルで継続的に実施している。このシステムの特徴は，他の複数のシステムと連携していることから，A社の現場部門や他システムの担当者など，ステークホルダが多いことである。
　長期にわたってこのシステムを担当してきたP社のプロジェクトマネージャ（PM）が退職することになり，後任のQ課長がPMとして追加開発を担当することになった。開発チームはこれまでどおり，リーダであるR主任を含むメンバ8人から成る体制を継続する。
　Q課長は，着任に当たって過去のプロジェクトの実績を確認するとともに，開発チームやステークホルダにヒアリングを行ってこれまでの状況を把握し，次のように整理した。
・前回の追加開発（以下，前回開発という）をはじめ過去の追加開発でも，何回か大きな手戻りが発生しており，A社，P社とも，何らかの対策の必要性を認識している。
・A社のステークホルダは，P社に対して不満をもっている。
・P社の開発チームは，十分なチームワークを発揮できていない。
　Q課長は，これらの状況を生んだ根底にはコミュニケーションに関する問題があると考え，改善を検討することにした。

〔前回開発の問題を踏まえた改善〕
　Q課長は，前回開発の問題を次のように整理した。
・A社システム部は，現場部門から提示された要求事項を，そのまま一覧にしてP社に提示していた。そこに記載された要求事項は，“何をどのように追加・変更するか”は書かれているものの，断片的な情報であることが多く，業務上の目的や，背景，意図などはほとんど書かれていなかった。また，要求事項の漏れや考慮不足が後工程で見つかることもあった。
・P社は，A社システム部から一覧にして提示された要求事項を，そのまま追加開発のインプットとしており，要求事項のレビューをほとんど実施していなかった。
・要求事項一覧で使用されていた業務用語は，用語の定義が不明確で，複数の解釈が可能なものもあった。そのような場合に，A社とP社の解釈が違っていると，その違いは現場部門による受入テストまで検出できず，大きな手戻りとなった。
・現場部門が，複数の要求事項から自明なので当然対応されるはず，と考えて，要求事項一覧に明示されていない要求事項もあった。しかし，その認識はA社システム部にもP社にもなかったので，現場部門による受入テストで，“このままでは業務には適さない”と評価され，大きな手戻りとなった。
・要求事項からP社としては他システムへの影響が容易に想定できるはずだと思われた事項が，連携先の他システム担当者の想定から漏れていて，他システムとの連携確認テストで問題が判明し，大きな手戻りとなった。
　ヒアリングによると，過去の追加開発でも上記の前回開発の問題と同様な事象が発生しているとのことだった。
　Q課長は，図1に示す前回開発における要求事項の解釈に関わる過程で，(i)と(ii)の過程に問題がある，と考えた。

 拡大
図1 前回開発における要求事項の解釈に関わる過程


　Q課長はまず，①A社システム部が提示する要求事項一覧に関する基本的な責任の所在について，A社システム部と話し合い，合意を得た。その上で，次の(1)〜(5)のプロセスで要求事項のレビューを行うことを提案した。
(1) P社は，要求事項一覧に記載された内容について，A社システム部に別の観点や表現で問い返したり，疑問点を質問したりして，要求事項の解釈にA社と違いがないことを確認する。
(2) P社は，解釈した要求事項について，“なぜ追加・変更するのか”，“何のために追加・変更するのか”という質問を励行する。A社システム部はその質問を契機として，提示した要求事項が実現したい内容と合っているかどうかを現場部門に確認し，必要であれば実現したい内容に合わせて要求事項の見直しを行う。
(3) P社は，解釈した要求事項を図表に整理して，要求事項としての漏れや考慮不足がないかどうかを整理する。また，要求事項から導かれる，利用者や他システムへの影響について整理する。A社システム部はその情報を基に，必要であれば実現したい内容に合わせて要求事項の見直しを行う。
(4) 上記のプロセスを経て完成度を高めた要求事項一覧に対し，P社はその要求事項をブレークダウンした要件定義書を作成する。A社システム部は，要件定義書をレビューし，要求事項一覧の内容が正しくP社に解釈されていることを確認する。
(5) A社システム部は，要求事項一覧と要件定義書の必要な範囲について，現場部門や他システム担当者とレビューし，要求事項が実現したい内容と合っていること，他システムへの影響が想定されていることを確認する。
　A社システム部はこの提案を受け入れた。

〔顧客報告の改善〕
　Q課長は，P社の顧客報告に対するA社システム部の要望をヒアリングした結果に基づいて，R主任に顧客報告についての改善案を検討するように指示した。R主任が検討した改善案は，表1のとおりである。

 拡大
表1 顧客報告についてのR主任の改善案


　Q課長は，要望3に対する改善案について，この内容ではA社システム部及びステークホルダの時間を有効に使う観点からは不十分なので，②見直しを行うように指示した。R主任は改善案の見直しを行い，Q課長はこれを承認した。

〔開発チーム内部の改善〕
　Q課長は，開発チームへのヒアリングで，次のような意見を収集していた。
(1) R主任の意見
・前任のPMは，進捗会議で進捗や品質の問題が報告されると，報告者に対して“原因は何か”，“対策は考えたか”と問い詰め，全員の前で叱責することが多かった。そのためにメンバは，原因分析や対策立案ができていない段階では，問題の発生を報告しにくいと感じていると思う。
・連絡や相談を頻繁にしてくるメンバがいる一方で，ほとんどしてこないメンバもいる。ミーティングでも発言をするメンバとしないメンバに分かれている。意見を言わないメンバともコミュニケーションを取る必要があるが，そのための時間を確保できていない。
(2) メンバの意見
・進捗や品質の問題を発生させたくないので，自分の担当作業を問題なく進めることを最優先にしている。過去に他のメンバの作業が遅れていた時，早めに助言，レビューをしてあげていれば，影響を小さくできていたかもしれない。
・前任のPMもR主任も，いつも忙しい様子だったので，明らかに問題であると判断したときは相談したが，予兆や“いやな感じ”といった程度では，相談しづらかった。結果として問題になったケースが多く，早めに相談しておくべきだった。
　Q課長は，これらの意見をまとめてメンバに配布した。その際に，“チームとして活動する強みを生かすことが最も大切であり，今後は，問題を起こした個人に着目するのではなく，問題に対して c で向き合う姿勢で臨みたい。そのためには，チーム内部の状況を的確に共有することが重要である。その第一歩として，1週間後にミーティングを開き，全員で改善方針を検討したいので，それぞれの見解や対策を事前に考えてきてほしい”と伝えた。また，Q課長は，これまでの開発チームのコミュニケーションの状況を踏まえて，各自の事前の検討結果をミーティングの前日までに提出するように指示した。
　ミーティングでQ課長は，前日までに集めた意見を整理した資料を配布した上で，まず③全員に自分の意見を述べさせ，議論を経て，朝夕の短時間ミーティングの開催や，困っているメンバに対する相互支援などの改善方針をまとめた。次にQ課長は，“これからは，過去の事例に学んで，悪い話ほど早めに，ミーティングなどの場を通じて共有してほしい。問題として明らかになる前でも構わない。そのことが④開発チームの活動を改善することにつながると思う。”と述べて，ミーティングを終えた。

設問一覧＆解答・演習

まずは解答を作成してみましょう。「解答例を見る」をクリックするとIPA公式解答例と採点基準が開きます。

設問1(1)記述問題

制限字数：15 字以内

〔前回開発の問題を踏まえた改善〕について，(1)〜(3)に答えよ。
(1) 図1中の a に入れる適切な字句を15字以内で答えよ。

0 / 15 文字

【IPA公式解答例】

a P 社が解釈した要求事項

設問1(2)記述問題

制限字数：35 字以内

〔前回開発の問題を踏まえた改善〕について，(1)〜(3)に答えよ。
(2) 本文中の下線①で，Q課長が得た合意の内容は何か。35字以内で述べよ。

0 / 35 文字

【IPA公式解答例】

要求事項一覧を定義するのは,A 社システム部の責任であること

設問1(3)記号・選択式

〔前回開発の問題を踏まえた改善〕について，(1)〜(3)に答えよ。
(3) 本文中の(1)〜(5)のプロセスを，図1に示す(i)の過程の問題を解決するためのものと，(ii)の過程の問題を解決するためのものとに分類したとき，前者に該当するものを全て答えよ。なお，両方に該当するものは，解答に含めるものとする。

※直接入力してください