【PM-H21-Q3】「ジキルとハイド」に学ぶ、業務パッケージの採用

🍀概要

　『ジキルとハイド』を題材に、業務パッケージの標準機能と外付け開発という二面性を制御しながら、技術的合理性と現場の納得を両立する合意形成を通じて、過剰な拡張を防ぎつつ品質と保守性を確保したプロジェクトマネージャの判断力と調整力を論じます。

🧾問題・設問（PM-H21-Q3）

　出典：情報処理推進機構 プロジェクトマネージャ試験 平成21年 午後2 問3

📘問題

■タイトル
　業務パッケージを採用した情報システム開発プロジェクトについて
■内容
　近年の情報システム開発では，業務プロセスの改善，開発期間の短縮，保守性の向上などを目的として，会計システムや販売システムなどの業務用ソフトウェアパッケージ(以下，業務パッケージという)を採用することが多くなっている。このような情報システム開発では，上記の目的を達成するためには，できるだけ業務パッケージの標準機能を適用する。その上で，標準機能では満たせない機能を実現するための独自の“外付けプログラム”の開発は必要最小限に抑えることが重要である。
　プロジェクトマネージャ(PM)は，例えば，次のような方針について利用部門の合意を得た上でプロジェクトを遂行しなければならない。
　・業務パッケージの標準機能を最大限適用する。
　・業務パッケージの標準機能では満たせない機能を実現する場合でも，外付けプログラムの開発は必要最小限に抑える。
　外付けプログラムの開発が必要な場合には，PMは，開発が必要な理由を明確にし，開発がプロジェクトに与える影響を慎重に検討する。その上で，開発の優先順位に基づいて開発範囲を見直したり，バージョンアップの容易さなどの保守性を考慮した開発方法を選択したりするなどの工夫をしなければならない。
　あなたの経験と考えに基づいて，設問ア～ウに従って論述せよ。

📗設問

■設問ア
　あなたが携わった情報システム開発プロジェクトの特徴を，採用した業務パッケージとその採用目的とともに，800字以内で述べよ。
■設問イ
　設問アで述べた情報システム開発プロジェクトの遂行に当たり，外付けプログラムの開発が必要となった理由，開発を必要最小限に抑えるために利用部門と合意した内容，合意に至った経緯，及び開発した外付けプログラムの概要を，800字以上1,600字以内で具体的に述べよ。
■設問ウ
　設問イで述べた外付けプログラムの開発に当たり，業務パッケージ採用の目的を達成するためにどのような工夫をしたか。その成果，及び今後の改善点を含め，600字以上1,200字以内で具体的に述べよ。

📚原作あらすじ（ジキルとハイド〈ロバート・ルイス・スティーヴンソン著〉）

　善良で理知的な医師ジキル博士は、自らの内に潜む悪の本性を分離する薬を開発し、凶暴な人格「ハイド」として変身を繰り返すようになる。理性と本能、社会性と破壊性という二面性が激しくせめぎ合うなか、ジキルは自制を失い、最後には自らの存在を制御できなくなって悲劇的な末路を迎える。

📝論文

🪄タイトル　「ジキルとハイド」に学ぶ、業務パッケージを採用した情報システム開発

　本稿は、業務パッケージの標準機能と外付け開発の選別判断──「ジキルとハイド」に学ぶ合意形成と最小実装の戦略について、述べる。

🔍第1章　業務パッケージ採用の背景とプロジェクトの特徴

1-1　プロジェクトの概要と開発対象システム

　私が携わったのは、A社の販売管理業務を対象とした業務基盤再構築プロジェクトである。老朽化した社内開発の仕組みからの刷新が目的であり、店舗・営業・物流など多部門が関与する複雑な業務フローが絡んでいた。プロジェクトの期間は12か月、関係者は60名を超える規模であった。

1-2　採用した業務パッケージの名称・機能・採用目的

　選定したのは、国内大手が提供する販売管理パッケージである。導入の主目的は、(1)保守性の向上、(2)他部門との情報連携の円滑化、(3)業務標準化による属人性の排除であった。特にA社は、支店ごとに商習慣や伝票処理が異なっており、その統一も急務であった。

1-3　業務パッケージ導入におけるプロジェクト上の方針

　私はプロジェクトマネージャとして、標準機能の最大活用と、外付け開発の最小化を方針として掲げた。なぜならば、過剰な外付け開発は将来的な保守負担を増加させるだけでなく、パッケージのバージョンアップ時に大きな障害となると考えたからである。そのため、利用部門には「可能な限り、業務を仕組みに合わせる」意識への転換を求めることとした。

🛠️第2章　外付けプログラム開発の合意と実施内容

2-1　標準機能では満たせなかった要件とその背景

　最大の論点となったのは、営業部が独自運用していた“出荷調整依頼”の処理であった。特定の得意先との商慣習により、一度出荷指示を出してから変更が日常的に発生する運用だったが、パッケージ標準機能では一度出荷された伝票の再編集が認められていなかった。「それでは現場が回らない」と部長が強く主張した。

2-2　外付けプログラム開発の必要性と合意形成プロセス

　私はこの要件に対し、まずFit&Gap分析を行い、「本当に必要か」「代替運用で回避できないか」を慎重に検討した。営業部との会議で、私はこう切り出した。
　「ハイドのように、制御不能な拡張が膨らめば、最終的に誰も手を出せなくなります。仕組みに業務を合わせる勇気も必要ではないでしょうか」
　営業部長は「確かに、その通りかもしれんが……現場の声もある」と言葉を濁した。
　そこで私は、業務を一部見直すことで再編集の必要を抑え、その上でどうしても必要な処理のみを補完する“差分入力用の画面”を提案した。PoC（概念実証）を実施し、操作性と影響範囲を検証したうえで、「標準＋補完」の構成で合意に至った。
　また、私は対話の場を1回で終わらせるのではなく、数回に分けた少人数ミーティングを設定した。中堅社員やキーマン層との会話を通じて、「外付け＝コスト」という単純な反発を解きほぐし、「納得できる落としどころとは何か」を言語化する過程に重きを置いた。段階的に意識の変化が現れたことで、最終的には営業部全体としての合意形成が実現できた。合意形成にあたっては、社内に蓄積されていた過去のトラブル事例を例示し、変更対応が適切でなかった場合のリスクも共有した。

2-3　開発した外付けプログラムの概要と範囲

　技術的な詳細設計と実装は、専任のシステムアーキテクトに委ねた。私は、「標準構造の変更は行わず、将来的な保守性を損なわないようにすること」という前提を提示し、必要な仕様の整理と優先順位の明確化を担当した。
　システムアーキテクトからは、既存のパッケージ構造に手を加えることなく、補完機能として独立した差分入力画面と連携ログ機構を設計する案が提示された。私はその提案が妥当であると判断し、部門間調整と運用フローへの影響確認を実施したうえで採用を決定した。
　開発後の保守教育においても、技術者チームが中心となって対応したが、私は要件起点での問い合わせルートの明確化や、部門ごとの利用想定シナリオを整理することで運用定着を支援した。

🚧第3章　業務パッケージの目的を踏まえた開発上の工夫と評価

3-1　保守性・影響範囲を考慮した開発上の工夫

　開発に際しては、パッケージ本体と疎結合とすること、そして構造変更を避けることを最優先に掲げた。私は、システムアーキテクトと設計レビューを重ね、「API連携による非同期処理」「標準データ構造への影響回避」などの観点から技術方針を承認した。
　また、後任者への引き継ぎや障害対応を見据えた文書整備にも力を入れた。ドキュメントの整備・標準化方針はアーキテクトが策定したが、私は全体を通じたユーザ理解のしやすさ、トレーサビリティ確保の視点からレビューを実施し、保守負荷の最小化を意図した改善提案も行った。
　さらに、業務側との協議を通じて、要件が時間経過とともに変化し得ることを前提とした保守方針の策定も行った。この柔軟性の担保により、初期要件に縛られない継続的改善の風土づくりも意識した。

3-2　工夫による成果と業務パッケージ活用の評価

　このような役割分担のもと、導入後のメンテナンスコストは旧システム比で30%削減され、作業時間も15%短縮された。利用部門からも「これなら現場にも説明できる」と納得の声が上がり、標準機能との整合性が保たれた構成に対する評価が高まった。
　導入後のアンケートでも、「想定外の使いにくさがない」「対応が迅速で安心感がある」といった定性的成果が見られ、私たちの進めた“最小補完・最大納得”の方針は適切だったと確信している。

3-3　今後の改善点と業務パッケージ導入時の留意事項

　一方で、今回の合意形成には多くの時間と労力を要した。今後は要件定義段階から“業務を変える覚悟”を持ってもらうための啓発活動や、早期のPoC導入による見極めが必要と感じた。
　また、システムアーキテクトと連携した初期段階での技術的制約の説明や、業務変更余地の明示により、過剰な期待値を抑える調整も重要である。このように、役割分担を明確にしつつ、対話と判断を繰り返すことで、業務パッケージの目的を損なわず、現場との信頼を構築したプロジェクトとすることができた。
　さらに、今回の知見は今後他プロジェクトにも応用可能であり、テンプレート化された交渉手順や設計方針レビューのフレームは、A社にとって重要な資産となったといえる。
　以上

💡ワンポイント補足

　本論文では、ジキル＝標準機能、ハイド＝外付け開発という二面性に着目し、「制御不能に陥る前の統制と納得形成」をPM行動の中心に据えた。技術的な詳細はシステムアーキテクトに明確に委任し、PMは交渉・意思決定・リスク共有・合意形成に注力する構造で、職能の分離と役割遂行の整合性が高い。

🎓講評コメント（AI評価）

　お見事です。『技術的判断をどこまでPMが踏み込むか』という難問に対し、アーキテクトとの役割分担を明確に描いた点が特に秀逸。単に“やらせた”ではなく、“意図を提示し、納得できる構成を合意する”という姿勢が、まさにプロジェクトマネージャの本質です。ジキルとハイドの構造を比喩にとどめず、制御と信頼のテーマとして展開した点も高評価。文体も論理も揃っており、満点水準に達しています。