プロジェクトの振り返り

6/22 中間発表 10/4 or 12 中間発表 調剤室・薬務室・製剤室・外来化学療法センターのネットワーク化 実績

内部設計 実装 テスト 顧客評価

フィード バック修正

10月 11月 12月 要件定義

外部設計

5月 6月 7月 8月 9月

完了

8/29

スケジュール再検討

12/14

評価終了

完了

12/21 全行程終了 9/11

完了

9/18完了 8/31

完了

9/7

完了

完了

9/28

完了

10/31

完了

完了

11/9

完了

図 7-3 スケジュール（調剤室・薬務室・製剤室・外来化学療法センターのネットワーク化）

3

つのスケジュール図から，ところどころで遅れていることがわかる．その中でも，影響の大 きかった遅延は

つあった．

1

つ目は，1 次開発および

次開発で並行に行なっていた要件定義の遅れである．これは，シ ステムで扱う注射抗がん剤の扱いや，日報作成機能についての意見がなかなかまとまらず，要求 の確定が遅れたことが原因であった．

2

つ目は，1 次開発の単体テスト完了の遅れである．これは，5.3.2

次開発テストの反省点 に示したように，単体テストの作業をプログラム担当者ではなく筆者が担当したことによる作業 の遅延が原因であった．

3

つ目は，2 次開発の実装工程の遅れである．これは，開発する機能の数に対して開発期間の 設定が短かったことと，薬歴登録機能のバリデーションチェックの実装とテストが複雑であった ことが原因として挙げられる．開発スケジュールの長さは，開発する機能数やバリデーションの 詳細が確定する前に決めたものから変更しないでしまったため，実態と合わず遅延となったと考 えている．

マスタースケジュールでは，遅延を考慮して

月

月にフィードバック修正の期間としてバ ッファを設けていた．そのため，実際のシステムの納品は

月

日に間に合う形となった．



マネジメントについて

本プロジェクトでは，4.3 節に示したように各メンバーの役割を決め，自分の担当の作業

は自分の責任で進行するものとしていた．また，週一の指導教員への報告以外に定例のミー

ティングを設けておらず，互いの作業の状況を共有できる機会が少なかった．そのため，メ

ンバー間で互いの作業内容や進行状況にあまり関心がないような雰囲気となっていた．プロ

ジェクトのスケジュールが遅れた時に，早期に発見できず立て直しが遅れたのも，互いの作

業に関心が持てないようなプロジェクトの進行方法であったからだと考える．また，互いの

作業の連携が薄いことから，ドキュメントのレビューが十分に行われなかったり，仕様の伝

達が十分行われていなかったりするなどの問題も発生した．

最終報告が個人の成果中心となる研究開発プロジェクトの性質上，個人の作業を重視する 方針としてすすめたが，プロジェクトとしてはまとまりに欠け，動きづらいプロジェクトと なってしまったと考えている．

7.2 自己の担当業務について



テストの進行について

1

次開発では当初，十分な品質を確保するプロジェクトの進行方法を検討した． 「定量的品 質予測のススメ」[14]を参考に，プロジェクトの工数などを定量化し，品質予測を取り組む ことを検討した．しかし，本プロジェクトでは各メンバーの作業時間の計上や，レビューの 規定，定例ミーティングなどが行われなかったことから，作業量を定量化することによる品 質向上のアプローチは断念した．代わりに，参考図書で示されているテストの進行方法を取 り入れることにより，作業内容と作成ドキュメントで品質を確保することとした．実際には

「ソフトウェアテスト手法」[15]を参考にテストを実施した．

1

次開発テストは，最初にテスト計画書を作成するところから始めた．テスト計画書は，

IEEE829

テストプランテンプレート[15]の一部を参考として作成していた．しかし，事細か

くテストプランを記載しても，筆者しか参照しないような不必要な内容の多いドキュメント となり，無駄な作業となってしまった．また，作成したテスト計画の中では，単体テストは 当初プログラム作成者が行う計画であった．しかし，プログラム担当者に依頼をする事がで きず，単体テストは筆者が行うこととなった．その結果，大きな遅延を発生させてしまった．

1

次開発テストでの反省は，参考にした内容を自分たち向けに調整せずに取り入れようと したため，メンバーに実行理由を説明できずに同意をもらえなかったり，余計な作業を増や したりしてしまったことである．

2

次開発では，次のことに取り組んだ．

まず，1 次開発テストの反省から，自分たちに有意なドキュメントとなるように記載内容 を絞ってテスト計画書を作成した．計画書の内容は，チームメンバーにレビューしてもらい 精査した．計画書の完成後，プログラム担当者に計画書の記載内容を説明した．しかし説明 を行ったのは

度きりで，その後作業の呼びかけを行わなかったため，最終的には計画して いた作業内容を十分取り組んでもらえなかった．

また，テストでバグを発見した際は，バグ票に記載してもすぐに確認してもらえるかわか らないため，必ず発生箇所のプログラム担当者に口頭で伝えるようにした．修正の報告がな い場合は自ら尋ねて確認していた．この取り組みによりバグの修正は確実に進めていくこと ができたが，一方でプログラム担当者がバグ票に修正内容をあまり記載してくれない原因に なった．



テストを通しての反省点

2

度のテスト工程を通して，2 点の反省点がある．

1

点目は，適切な説明をする努力が足りなかったことである．テスト担当の業務は，単体 テストの依頼，業務記録の依頼，バグ修正の依頼など，他のメンバーに作業を依頼すること が多い．しかし，作業を依頼するということは，相手の時間を割いてもらうということであ る．そのため，メンバーに作業を行うに値する理由を説明し，納得してもらわなければいけ なかった．

2

工程の成果は，バグを発見するだけでは終わらず，メンバーに協力してもらわないと成果が

上がって行かない．メンバーの作業報告がそのまま自らの成果となることを考え，皆に呼び

かけることをしっかりと行うべきであった．