開発プロジェクトには「終わり」がある
エンジニアとして新しい製品やサービスの開発プロジェクトに参画する場合、いつかはプロジェクトから離れる瞬間が発生します。
そもそも「プロジェクト」とは何らかの目標を達成する有期限の計画を意味します。大人数のエンジニアを必要とする設計〜実装〜試験〜検収までのフェイズが完了するとプロジェクト人員の整理が行われ、比較的少人数の製品チームや保守開発チームのメンバーに業務を引き継いでいくのが一般的です。所属企業の方針変更や配置転換、自身の病気や家庭の事情などによって途中離任を余儀なくされる可能性もあります。
開発プロジェクトを離任する際に必要となる最後のタスクが残ったメンバーへの業務引き継ぎです。これまでやってきた業務内容やノウハウを後任者にを引き継いで、自分自身が離任しても滞りなく業務から進められるようになってこそ、担当業務を完了させたと胸を張っていえる状態となります。
不十分な引き継ぎのまま離任の日を迎えると、ノウハウの散逸による業務効率の低下や後任者のモチベーション低下などの禍根を残してしまうのですが、引き継ぐ側も引き継がれる側も本腰が入らないまま最低限の資料説明で終わってしまうこともあるのではないでしょうか。
人生の最期を迎える準備やそこに向けた人生の総括を「終活」と呼ぶのですが、開発プロジェクトにも離任を迎える準備や業務の総括を行うための「終活」が必要なのではないかと考えています。そこで今回はスムーズな業務引き継ぎを開発プロジェクト終活のノウハウを五箇条にまとめました。
その１．自分とは同じ苦労をさせない責任感
引き継ぎ業務を行うのにあたって、もっとも重要なのは「自分とは同じ苦労をさせない」という責任感です。特に過酷な開発プロジェクトを離任する立場となると、引き継ぐためのモチベーションが湧かなかったり、後任者が同じような苦労をすることに対して罪悪感を感じにくくなったりしがちです。
しかしながら、後任者に自分と同じ苦労をさせたところで、会社や製品は成長できません。後任者には新しい課題を自分とは異なる分野や性質の苦労をして解決してもらうためにこそ、同じ苦労をさせてはならないというというマインドセットを持ちましょう。
引き継ぎに使える時間がどの程度用意できるのかは状況によって異なるでしょうが、スケジュールに応じた引き継ぎ項目の優先順位を決めて、期間内に全ての引き継ぎ事項を終わらせるようにしましょう。時間切れ終了はNGです。
後の項目でも挙げていきますが、ノウハウを共有するための資料作成や業務の棚卸しは引き継ぎ業務が決定してから慌てて行うのではなく、開発プロジェクトの一環として整備していくことがスムーズな引き継ぎには不可欠となります。
| ☓ | 引き継がれる側の責任。同じような苦労をしてもらえばよい |
| ◯ | 引き継ぐ側の責任。自分とは違う性質の苦労をして新しい問題を解決してもらう |
その２．自分のやってきた業務を明確化する
スムーズな引き継ぎを行うためには、自分のやってきた業務内容を明確化することが前提となります。開発プロジェクト内には定型業務に加えて様々な非定型業務が発生します。たとえ、定型業務に関する棚卸しや引き継ぎが行えていたとしても、過去に対応した非定型業務が引き継がれていないことによるトラブルが後になって発生しがちです。
自分が何にどのぐらいの時間をかけて業務を推進してきたのかを把握するためには、普段からなるべく具体的な日報を書き残していくのがおすすめです。日報からピックアップした過去の問い合わせやトラブル対応などの非定型業務の資料を作成することで、後で同じような状況になった場合への指針や対応方法へのノウハウが引き継がれていきます。
「過去に何が発生して、どう対応してきたか？」という事実を確認可能な状態にしておくのは後任者のモチベーションにも影響します。「過去にも起きたであろうトラブル」に事前情報なしで巻き込まれると前任者への責任転嫁をしたくなり、問題解決よりも保身に走ることを優先しがちです。「既知の問題」と「新しい問題」が判別可能という前提があることで、自分の力で解決すべき新しい問題に全力で立ち向かうマインドセットが後任者にも養われていきます。
| ☓ | 定型業務の引き継ぎさえできれば、あとのトラブルは本人がなんとかするだろう |
| ◯ | 過去に発生した出来事を具体的に残して、新しい問題に立ち向かってもらう |
その３．引き継がれる側の立場を考える
いくら詳細な引き継ぎ資料をつくったところで、後任者に伝わらなければ空回りになってしまいます。後任者の状況は様々でしょうが、自分にとっては当たり前のことであっても「何が分からないのか、分からない」ところからスタートすることを想定すべきです。
まずは業務を俯瞰してもらうことが重要です。定型業務には作業を開始するためのトリガー、作業内容、判断基準、ゴールが存在します。業務フロー図を作成することで、誰がいつ何をするかについての流れを把握することができ、各担当者の担うべき業務範囲が明確化されます。
図．業務フロー図の例
業務フローを明らかにした上で、個々の判断基準や例外的な事象が発生した場合の対応方法などについて、具体的な例示を挙げて掘り下げていきましょう。掘り下げて説明する際には「ここは苦労したんだよ」「ここはお客さんからの指摘で変わったんだ」といった実体験を交えることで、後任者にも具体的な業務内容がイメージできるようになります。
業務引き継ぎの説明をしているのに何も質問がないのは「すべてを分かっているから」ではなく「何も分かっていないから」の黄信号です。日々の業務の全体像と具体的な作業をイメージしてもらいながら、掘り下げた質問がでるように誘導していきましょう。
| ☓ | 詳細な引き継ぎ資料を残せば大丈夫 |
| ◯ | 業務の全体像の俯瞰しながら、個々の詳細を掘り下げていく |
その４．逆引き形式の資料を残す
業務を引き継ぐ際には、業務の全体像をトップダウンで理解してもらうことが重要ですが、実際の業務には細かい例外やノウハウが多数存在します。それらの知識を短い引き継ぎ期間のなかで対処療法的に覚えていってもらうのにも限界があります。
このため、何らかの課題や問題が顕在化したタイミングでボトムアップに知識を検索できる逆引き形式の資料を用意しておくと助かることが多いです。逆引き可能として欲しい索引の例としては例えば以下の内容が挙げられます。
- エラーメッセージ
- 独自用語
- 関係者の名刺
- 頻発する問い合わせ
- 定例イベント
それらについての全てを詳細に網羅した引き継ぎ資料を作成するのは現実的ではないでしょう。しかしながら「それは何時か(Know When）」「それは何か（Know What)」「それはどうしてか（Know Why）」「どこを調べれば良いか（Know Where）」「誰に聞けばよいか（Know Who）」といった内容を逆引き形式で簡潔に記載しておくことが、後の問題解決へのいちばんの近道となりえます。
また、なんらかの問題が発生する可能性があったり、完全な解決ができなかった箇所については、その旨を正直に伝えておきましょう。後任者のネクストアクションへのとっかかりや自己学習への指針になります。
| ☓ | 細かいノウハウを時間切れいっぱいまで伝え続ける |
| ◯ | 逆引き形式で「どこを調べればよいか」「誰に聞けばよいか」を簡潔に記載 |
その５．自分の手を出さない日を宣言
これまでスムーズな引き継ぎを行うための方法を述べてきましたが、どれだけ順調に引き継ぎを行えていたとしても、後任者ひとりでの業務を開始してみてはじめて色々なことが分からないと気づくことは避けられないのが実情です。
後からの後悔を避けるため、在任中にも敢えて自分の手を出さない日を宣言して、後任者ひとりで業務を回してもらいましょう。例え、後任者が分からないことがあっても、お客様への悪影響に繋がる場合を除いての手助けは禁止。さながら離任後の模擬試験です。
金融機関や外資系企業などでは業務の属人性を排除したり、不正を抱え込みにくくするために、年に1週間以上の長期休暇と、それに伴う業務引き継ぎが義務化されています。開発プロジェクトからの離任が決定する前であっても、意識的に「自分がいない日」に対応できる体制を作ることで適切な有給休暇を取りやすくなり、万が一の事故があっても開発プロジェクトが頓挫する可能性を減らすことができます。
| ☓ | 離任最終日まで手助けしてあげよう |
| ◯ | 手出しをしない日をつくって、業務の中で理解できていない部分を認識してもらう |
自分がされたら嬉しい引き継ぎをしよう
いかがでしたか。以上までで開発プロジェクト終活五カ条を挙げてきました。多忙だった開発プロジェクトが徐々に収束していき、離任が提示される状況には一抹の寂しさを覚えてしまいがちですが、業務内容を明確化して後任者に引き継ぐのは自身が働いてきた証でもあります。業務を見つめ直すことで生まれた反省点は、後任者のみならず、次の開発プロジェクトにも活かせることでしょう。
「スムーズな引き継ぎ」が掘り下げられているということは、引き継ぎをしてもらう立場においても求める内容が明確化できているということでもあります。現在の開発プロジェクトを離任して、新しい開発プロジェクトに迎えいれられると、今度は後任者の立場となって引き継ぎを受ける可能性も高いわけです。自分がされたら嬉しい引き継ぎをするのことは、自分がされたら嬉しい引き継ぎをしてもらうことにも繋がります。
本記事をきっかけにして「開発プロジェクトの終活」が行われ、スムーズな業務引き継ぎができるようになりましたら幸いです。
参照：ビジネスチャンスを掴むトップワーカーについて解説した記事はこちら
イラスト：ゆずりは さとし
この記事の著者
by 池田仮名
ITエンジニア／ブロガー
個人ブログ「太陽がまぶしかったから」を運営。
Twitter｜@bulldra
ブログ｜太陽がまぶしかったから
