今日のコメント欄は、
論文の感想でも、
あなたがつける論文評価でも、
自由にコメントください。 (￣▽￣)
平成２７年春 ＰＭ 問１
システム開発プロジェクトにおける
サプライヤ管理について
【問題文】
平成２７年プロジェクトマネージャ
【完成論文】
（設問ア） ＰＪの特徴
私 は愛媛県にあるみかん専用の冷蔵庫の開発、製造、販売を手掛けるＡ社に勤務している。Ａ社は従業員が１００名程であり、受注管理システム等をはじめとする 基幹システムは、すべて社内でグループウェアを利用して、内作している。Ａ社では以前から、営業担当者が社外から社内システムにアクセスしたいという強い 要望があり、今年度、その為の開発予算が承認され、社外からのアクセスに対する機能の増築プロジェクトが開始された。開発予算は１５００万（外注費を含 む）、開発期間は４か月である。システムの設計は、私をプロジェクトマネージャとする３名から成るシステムグループが行い、開発要員や開発知識が不足する 場合には、サプライヤと呼んでいる外部のシステム開発を専門に行っているＢ社に、開発の依頼や要員の派遣を依頼するようにしている。
外部のサプライヤから請負で調達した範囲とその理由
今回のプロジェクトは開発期間が短いにもかかわらず、様々な利用環境・条件を組み合わせた複数の通信テスト、動作確認が必要であった。営業担当者がミカン畑など、どこにいても、社内のシステムにスムーズにアクセスできることが本システムには求められているからである。
し かし、社内のシステムグループのメンバだけでは、人的リソースに、万が一の場合に不安があると、私は考えた。特に通信テストでは、原因不明な問題点が発生 することも想定され、その原因究明に要する時間は計画に組み込むことが難しい。そこで、外部のサプライヤのＢ社に請負契約で、作成したモジュールのテスト 作業を依頼することを計画した。こうすることで進捗の遅延を極力防ごうと考えていた。
（設問イ） 進捗管理の仕組み
サ プライヤであるＢ社に請負契約で発注するテスト作業は、Ａ社で作成したモジュールの単体テストから結合テストであり、その工程は７週間を計画している。請 負契約の場合、成果物の完成を以って契約が完了するが、検収時（つまり、テスト工程最終日）に、モジュールの不具合を「まとめて」報告されるのでは、意味 がない。今回、私がＢ社に期待することは、Ａ社のメンバのコーディングと並行して、モジュール単位で仕上がったものからテスト工程を進め、不具合抽出を行 う並走作業である。そこで、Ｂ社に発注する際に、その日に検出された不具合に関する報告を当日中にＡ社に実施することを義務付ける契約条項を、進捗管理の 代わりに、盛り込むことにした。請負契約では、サプライヤに対する進捗管理は法的にできないが、この契約条項を盛り込み、報告がなかった場合には、本来の 目的であるテスト工程全体の進捗遅延は免れるはずである。
品質管理の仕組み
今回のプロジェクトは、単体テスト工程、結合テスト工程を合わせて７週間であり、テスト期間が短い。そのため単体テスト工程、結合テスト工程、それぞれの工程できちんと品質の管理を行い、手戻りが発生しないようにすることが重要である。
そこで私が工夫した点は以下のとおりである。
（１）役割分担の明確化
今回モジュールを製造したのはＡ社である。
そのため、テスト仕様書の作成はＡ社にて行い、Ｂ社ではテスト仕様書に基づいてテストを実施し、テスト結果（エビデンス）は当日のうちにＡ社に納品してもらうようににした。
そしてテスト結果をＡ社にて最終確認することにした。
（２）品質評価指標値の設定
単体テスト工程、結合テスト工程で、テスト密度と障害密度により品質を評価することにした。
具体的には以下のとおりである。
・単体テストのテスト密度は、１キロステップあたり、80～120項目の範囲内であること
・単体テストの障害密度は、１キロステップあたり、8～12件の範囲内であること
・結合テストのテスト密度は、１キロステップあたり、20～40項目の範囲内であること
・結合テストの障害密度は、１キロステップあたり、2～4件の範囲内であること
単体テスト完了時点で単体テスト工程の品質評価を行い、結合テスト工程完了時点で単体テスト工程の品質評価を行うことにした。
また、品質評価指標値に入らなかった場合は、Ａ社責任にて原因分析と対策を実施することにした。
これらを実施することにより品質確認の迅速化と、Ａ社責任による品質の管理を実現することにした。
（設問ウ） 進捗・品質管理の実施状況と評価
Ｂ社との契約が合意され、Ｂ社でのテスト作業が発注された。初めて品質評価指標値を外れる程度の大きな不具合群がＢ社より報告されたのは、テスト開始５日 後であった。Ａ社では、予定通り、最終確認等の他作業から、不具合対応に切り替え、原因分析と対応にあたった。品質評価指標値を外れた不具合は他に６件 あったものの、いずれも予定通りの対応ができ、他の微細な不具合（ソースの部分修正等で即時対応可能なもの）は、随時、対応することができたため、テスト 工程に影響はなかった。また、品質管理の仕組みに関しても、エビデンスの確認を日々、両社で行ったため、当初意図していた形で各テストの完了時の報告がな され、大きな手戻りもなく、品質確認の迅速化と管理の実現が達成できた。
以上の点、及び主目的としていたテスト工程完了時の進捗遅延が発生しなかった点を鑑みて、私は今回の仕組みの作成、及び実施について非常に評価している。
今後の改善点
本機能が無事リリースされ、その結果、営業担当者は社外から受注管理システムにアクセスすることができるようになった。これにより商談活動が効率化され、みかん専用の冷蔵庫の受注数は伸長するはずであった。
ところが本機能のリリース後、致命的な問題が発生した。この問題は、経験豊富な私のＰＭスキルを以ってしても、予測不可能な問題であった。本機能をリリース後、西日本を中心に観測史上最高の猛暑が襲い、多くのみかんの樹が枯れてしまった。これにより当年のみかん出荷量は過去最低を記録し、その結果、みかん専用の冷蔵庫の商談は殆ど発生しなかった。
今後システムを開発する際には、天変地異の発生をリスクとして捉え、リクスマネジメントを実施する必要があると考えている。
以上