HOME > ソフテックだより > 第90号(2009年5月27日発行) 現場の声編「案件の引継ぎについて」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより(技術分野別)のページへ
ソフテックだより(シーン別)のページへ


ソフテックだより 第90号(2009年5月27日発行)

現場の声編

「案件の引継ぎについて」

1. はじめに

ソフトウェアの請負開発を行っている会社では担当者が複数の案件を抱えていることが多いです。そのため、担当者の長期出張などにより、ある案件を他の担当者に引継ぐという状況は珍しくありません。今回は案件の引継ぎについて書かせていただきます。

2. 引継ぎについて
2-1. 前提

本稿では引継ぎの状況を以下のように想定します。

  • 引継ぎ時は引継元担当者及び引継先担当者に引継ぎの時間が十分あること
  • 引継ぎ実施後、引継先担当者だけで案件の対応が可能になるとこと

一言に引継ぎといっても、引継ぎ内容は案件ごとに千差万別です。 しかし、大まかに分類すると以下の(A)〜(E)のようになると思います。

2-2. 引継ぎ内容について
(A) システムの概要について
  • システムの目的
  • システムの構成
  • システムの運用状況(運用開始されているか、問題が発生していないか)
(B) 管理方法について
  • プログラムやドキュメントの保管場所
  • ソフトウェアのビルド環境
  • ソフトウェアの実行環境
  • ソフトウェアのバージョン管理
  • ソフトウェアの不適合管理
  • プロジェクトの進捗管理
(C) 顧客について
  • 顧客担当者及び関係者の情報(役職、Eメールアドレスなど)
  • 顧客担当者への引継先担当者の紹介
  • 案件のルール( メールの添付ファイルを暗号化するなど)
(D) ドキュメントについて
  • 要求仕様書
  • 設計書
  • 試験項目書
  • 取扱説明書
  • 議事録
(E) 開発方法について
  • コーディング規約
  • ソフトウェア製品の使用方法
  • 関連機器の使用方法
開発方法の引継ぎ内容は多岐にわたります。また、どこまで引継ぐかの判断がむずかしいため、引継ぎにおいてもっとも漏れが発生しやすいと考えられます。
2-3. 引継ぎの注意点

引継ぎの実施については、引継元担当者が引継ぎ内容や段取りを考える必要があると思います。しかし、引継ぎがうまくいかなかった場合、直接的に困るのは引継先担当者です。ひいては顧客や会社に迷惑をかけることになります。ここでは、引継元担当者及び引継先担当者のそれぞれの立場からみた注意点について書きます。

2-3-1. 引継元担当者から見た注意点
(A) 引継元担当者だけが持っている情報がない状態にする

引継先担当者はどの情報が必要なのかを判断する以前にどの情報があるかがわかりません。それを意識して引継元担当者が必要な情報を引継ぐ必要があります。
当然ながら、引継元担当者のPCの中にしか必要なファイルがないのは問題です。PCの故障などによるデータの紛失をさけるためにも、開発を進めるに当たって必要な情報は特定の場所に保存しておく必要があります。
また、システム開発の経緯などについても引継元担当者は引継先担当者に伝えておくことで、これから機能を追加するときや不適合が見つかったときなど調査に役に立つと思います。

(B) 引継ぎ後、引継先担当者が引継元担当者と同じ苦労をしないようにする

機器の使用方法など引継元担当者が時間かけて調査したことなどは引継先担当者に引継ぐ必要があります。引継対象者へ教育的な配慮を行う場合でない限り、引継先担当者が引継元担当者と同じ苦労をしないような引継ぎを行う必要があります。

(C) 引継ぎ内容をできるだけ文書化する

コーディング規約や開発機器の使用方法など文書化できるものはいくらでもあると思います。予め文書化しておくことで引継先担当者への説明時間を短くすることができます。また、顧客との電話内容やEメールなども質問票などでその内容を文書化しておくことで効率的に引継先担当者へ伝えることができると思います。
また、引継ぎそのものも引継ぎ手順書として予め文書化したほうが良いと思います。

(D) バッチ処理にできるところはバッチ処理化する

ファイルやフォルダを特定の場所へコピーするなど、決まった順番で実行する作業はあると思います。そういった場合、その作業をバッチ処理化することでその分の説明を簡単にすることができます。詳細が知りたければ、バッチ処理の内容を確認すればよいので結果的に文書化することと同じ効果になります。また、その作業自体の効率も上がるのであればそれだけでもバッチ処理化の意味はあると思います。

(E) 引継ぎ時間が短くなるように配慮する

引継ぎ時は引継元担当者だけでなく、引継先担当者も忙しい場合が多いと思います。
引継ぎ時間が短くなるように配慮する必要があります。例えば、引継ぎ手順書のようなものを作成して事前に引継先担当者に目をとしてもらうなど工夫することはできると思います。

(F) 引継ぎ後の猶予期間を予め考えておく

引継ぎ時に引継ぎ内容の不備が見つかった場合、その修正が必要になります。引継先担当者が修正を行う場合であっても修正中に疑問点がでることもあるのでその期間は引継元担当者に質問できたほうが良いと思います。

[A]〜[D]は、引継ぎ時に実施することではありません。引継ぎのためというよりは情報管理という意味から普段の仕事で実施するべき内容になります。つまり、普段から引継ぎを行うこと(=第3者に説明すること)を意識して情報の管理を行うことが大切です。
2-3-2. 引継元担当者から見た注意点
(A) 不明点を残さない

引継元担当者に聞けばすぐわかることでも、引継先担当者が調査すると時間がかかってしまうということは良くあります。そのため、引継ぎの時点で質問を行って不明点を残さないようにすることが大切です。また、引継元担当者へ理解度を伝えるためにも質問を行うことは効果的だと思います。

(B) 顧客対応を行うことを意識する

案件の引継ぎは社内的な問題ですので、そのことで顧客に迷惑をおかけしないようにする必要があります。引継先担当者は顧客からの質問に回答することを意識して引継ぎを受ける必要があると思います。仕様の話であれば、引継ぎで自分が感じた疑問点は顧客も疑問に感じる可能性は高いと思います。

(C) 自分が引継元担当者になることを意識する

引継いだ内容はいずれ自分が引継元担当者となって引継ぎを行う可能性があります。引継先担当者も、[引継元担当者から見た注意点]の[A]〜[D]を意識して引継ぎを受ける必要があると思います。不足している内容があれば、引継元担当者に指摘して修正してもらうか、内容を聞いて引継先担当者が修正する必要があります。

2-4. 引継ぎ文書について

案件を引継ぐことはコストのかかる作業ですが、[引継ぎの注意点]で述べたとおり、普段の仕事でしっかりと情報を管理することで引継ぎのコストを軽減することができます。とはいえ、社内でしか使用しない文書に時間をかけ過ぎてしまうのも問題があります。引継ぎ文書に求められるのは正確であることで丁寧に説明することはコストと相談することになります。例えば、ソフトウェアの使用方法を説明するとき、社外文書であれば画面キャプチャ等を用いて丁寧に説明する必要があっても、社内文書なら箇条書きで十分という場合が多いと思います。

2-5. 引継先担当者になったときの感想
(A) 引継ぎの時間を確保することが難しい

引継ぎ実施時に別件で緊急の割り込み作業が入ってしまい、引継ぎがいったん中断することがありました。これはかなり特殊なケースだと思いますが、引継ぎ手順書があれば途中で中断しても引継ぎの再開を行うのも容易ですし、引継ぎにどれくらい時間がかかるのかも予測しやすいので引継ぎ手順書を事前に作成しておくことが必要だと感じました。

(B) 引継ぎ時になって手順書を作成するのは時間がかかる

引継元担当者も引継ぎに十分な時間をかけられる状況とはかぎりません。 普段の仕事からしっかりと情報を管理しておくことが引継ぎ時にも生きてくると思いました。

(C) ISO9001の取り組みについて

弊社ではISO9001を取得し、その品質マネジメントシステムそったソフトウェア開発を行っています。 品質マネジメントシステムに沿ったソフトウェア開発を行うことが結果的に引継ぎのコストを軽減することにつながっています。実際、最近行った引継ぎでも品質マネジメントシステムに沿って作成された文書は引継ぎで詳しい説明は必要ありませんでした。特にビルド環境や実行環境をまとめた文書は引継ぎ文書として役に立つと思いました。

3. 最後に

今回は案件の引継ぎについてご紹介させていただきました。
計画的に引継ぎができればよいのですが、病気や事故などで緊急に引継ぎを実施しなければならない場合もあります。また、案件を引継ぐことはコストのかかる作業ですが、普段からしっかりと情報を管理していればそのコストを軽減できます。つまり、普段から引継ぎを意識して作業を行い、いつ引継ぎを行っても大丈夫なようにしておくこと大切になります。

(K.T.)


関連ページへのリンク

関連するソフテックだより

ページTOPへ