工場は, 生産管理システムの開発を自社の情報システム部門に依頼し, 情報システム部門は開発プロジェクトを編成した。依頼主である工場と情報システム部門との関わり方のうち, 最も適切なものはどれか。
平成24年度 春期 ITパスポート試験 問40
This question's explanation and your answers so far.
問 40
Incorrectア
Conveying the request when the project starts and then never communicating again is what is called throwing the work over the wall, and it is not appropriate. Requirements are not fixed completely by the initial explanation alone; as development proceeds, points that need confirmation and differences in interpretation inevitably appear. If the requester cuts off contact, the development side has no choice but to decide the specification by guesswork, misunderstandings of the requirements are built into the system without being noticed, and large-scale rework occurs at the testing and acceptance stages. Far from reducing the burden of development work, this instead increases the burden and the cost through waiting for confirmation and redoing work.
- イ
正解 The correct answer is イ. Even when system development is entrusted to the company's own information systems department, the factory as the requester is not a bystander who is finished once the order has been placed; it is a key stakeholder with a direct interest in whether the project succeeds. The factory, which owns the shop floor, knows the business requirements of the production management system best, and the factory is also the party that can judge business priorities, operational constraints, and trade-offs among requirements. Therefore, when a problem arises in the development project (differing interpretations of the specification, exceptions to business rules, interface conditions with other systems, constraints on staff or deadlines, and so on), it is the most appropriate way to interact for the factory to make decisions and supply information from the standpoint of the requester and to take an active part in solving the problem, because this leads to early resolution and prevents rework. In project management as well, identifying stakeholders and continuously managing their involvement and expectations (stakeholder management), together with sharing necessary information in a timely manner (communications management), are regarded as conditions for success. When the requester joins in solving problems, business decisions that the development department cannot make on its own are reached quickly, and the risk of the fatal mismatch of “this is not what we wanted” after completion is also reduced. Therefore イ is correct.
Incorrectウ
Telling the developer about a specification change directly and having it handled on the spot is not appropriate. A specification change ripples out to other functions, effort, cost, schedule, and quality, so it must go through change management (the change request procedure): it is formally accepted as a change request, its impact is analyzed, and it is carried out only after the project manager or the person responsible for change management has approved it. If requests made directly to individual developers are allowed, unapproved work slips in, the plan and the actual situation diverge, and because no change history remains, management of progress and quality breaks down. This is also a typical cause of what is called scope creep.
Incorrectエ
Even though it is the information systems department that carries out the development, progress reports and quality reports never become unnecessary. The factory, as the requester, is responsible for the return on the investment in the system and is in the position of advancing on-site acceptance testing, operational preparation, and training in step with the go-live, so it needs to know how far the work has progressed and whether quality is being assured. Regular reporting is the basic mechanism for sharing delays and quality problems early so that countermeasures can be taken; if reporting stops, problems surface only just before the delivery deadline. Reporting is an obligation toward the requester and at the same time an opportunity for the project side to ask for decisions.
- The requester (the user department) is a key stakeholder — even for in-house development, the requester is a party to the project and is responsible for presenting requirements, making business judgements, taking part in solving problems, and accepting the result. Both throwing the work over the wall and omitting reports cause misunderstood requirements and rework, so neither is appropriate.
- A specification change must go through the change management procedure — the change request is formally accepted, its impact, effort, cost, and schedule are evaluated, and it is carried out only after the responsible person has approved it. Asking a developer directly or handling it verbally on the spot leads to divergence from the plan and to lower quality.