引継ぎで「大事だなぁ」と感じたこと5つほど

引継ぎで「大事だなぁ」と感じたこと5つほど 雑記
えーとも
えーとも

どーも。えーとも(@atomoblog)です。
実を言うと先日、退職いたしました。

退職前に引継ぎを行ったのですが、その際に「大事だなぁ」とか「うまくできなかったなぁ」と感じた点についてご紹介いたします。

退職したきっかけについては↓を読んでね♪

孝行したい時分に親はなし。親孝行はお早めに
親孝行の必要性を筆者の個人的エピソードを交えて熱く語っています。「うちの親はまだまだ長生きするから〜」って思ってて足元すくわれました。マジで。親が元気な人は今のうちに親孝行するんだぞ!ホントに後悔先に立たずだからな!

引継ぎ時の状況

さて、本題に入る前に前提条件を列挙していきます。

自分の状況

  • 最終出勤日は約1ヶ月後
  • 家庭環境等の都合上、退職日は引き延ばせない

お仕事の内容

  • Webサイトの開発、改善、運用(複数)
  • 業務システムの開発、改善、保守

引継ぎ相手の状況

  • 入社したばかり(1ヶ月も経ってない。)
  • エンジニア経験有りだがWeb制作企業経験は無し

会社の事業についてはある程度理解しているけど、業務の種類やそれぞれの関係性、業務の流れについては全くわからない状態。

えーとも
えーとも

しょーじき申し訳なかった。

会社の状況

  • 超零細企業
  • 大企業みたいな分厚い業務マニュアルは存在しない
    ※あっても数年メンテされずに放置中

と、いうことで引継ぎ用のマニュアルやら資料やらは8割方新規作成。

内容別、引継ぎで大事だなぁって感じたコト

業務システム編

1.業務フローの資料を作っておく

入社から数ヶ月経っていれば業務フローがわかるとは思うものの、今回引き継ぐ後輩は入社したばかり。

今後入社する人のコトも考えると業務フローが必要だなぁと痛感しました。

特に全体の業務フローが無いと「今から引継ぐ業務はどの業務の、どの工程か」を上手く伝えられないという…。

結局、業務フローの資料を作ることはなかったのですが今後は整備が必要じゃないのかなって思います。

えーとも
えーとも

周りには言わなかったけどね。

お金にならない業務だけど、コストカットの面が大きいのでスケジュールキッチリ切ってやったほうがいいと思う。

資料を作っても随時メンテナンスをしないと現実との違いが大きくなって、価値が無くなるのでご注意

2.簿記の知識が必要な業務を引継ぐ時は、事前に入念な準備をする

えーともは商業高校卒なので簿記の知識があります。
で、話が通じる関係で経理の人のリクエストを聞いて機能追加してました。

資料を作っていざ「引き継ぐぞー!」ってなった段階で思わぬアクシデントが発生。

えーとも
えーとも

この処理は○○って器械を買った時の減価償却を行うんやで。

ヤマトさん
後輩

減価…償却…?

えーとも
えーとも

ある程度高額の備品を買うと、その備品の購入金額を一定の期間、一定の割合で費用として計上できるんやで。

その処理を減価償却って言うんや。

ヤマトさん
後輩

え、何で費用…?

一定の期間…?

割合…?

えーとも
えーとも

費用が多いと見た目上、あんまり利益が出ていないって判定されるから色々とメリットがあるんや。

帳簿上の資産とー…

2時間ほどかけて経理の人と一緒に説明したものの、イマイチ腑に落ちなかったようなので翌日に持ち越すことに。

えーとも
えーとも

説明している自分も、必死に理解しようとしている後輩も脳みそが完全に茹で上がっちゃったZE☆

最終的に「仕訳」から説明した

「貸方」「借方」の説明は不必要&混乱の元なので、省略したものの一般的な物品の売買についての仕訳をまず説明。

その後、自社のビジネスモデルを仕訳で表すとどういう形になるかを説明して「なんとなーく」で理解してもらいました。

えーとも
えーとも

零細企業で社内SEを育てたりする時は最低限、日商簿記3級を業務時間内に勉強してもらったほうが良さそうです…。

経理の人も「減価償却と前受金の2つはなかなか理解してもらえないから、新人に教えるの大変」って言ってました。

業務システムの引継ぎで「減価償却」か「前受金」が絡むときは事前に、簿記の資料を準備する。
または、簿記のテキストを渡して下準備として学んでもらう。

Webサイト編

1.機能追加、開発の際に「テーブル定義書」を作っておく

独自テーブルの追加を伴う機能追加をする際は必ず作っておきましょう。

あとあと資料を作成する時にテーブル定義書を見れば「どんな機能があるか」「どう動いているのか」が芋づる式に思い出せてホント便利。

2.日ごろから運用マニュアルを作っておく

自分が担当している業務でも「自分以外の誰かに伝えるためのマニュアル」っていうのをできるだけ準備しておくと便利です。

このマニュアルがあると「中で何が起こるのか」「関連するファイル、テーブル、フィールド」を追記するだけで十分な引継ぎ資料が出来上がります。

えーとも
えーとも

事前にマニュアル作っておいた業務の引継ぎ資料作成はホントに楽だった〜。

常日ごろから

  • メモ書き程度でも業務の流れを書いておく
  • 口頭のみでの業務説明はしない(資料が残らない)

の2点を意識しておくと将来の自分が助かりますよ。

えーとも
えーとも

メモ書き程度でも資料が残っていれば、不慮の事故などで働けなくなった時も会社からの電話攻撃をすり抜けられまっせ。

その他

自分が担当している業務の引継ぎ資料をガガーっと作ったのですが、いざ引継ぎを開始してみると「この業務、そんなに重要じゃないから切捨ててもOK」ってな業務もありました。

無駄な労力と時間をかけないためにも、引継ぎに取り組む前に各業務に関係する人と業務の断捨離をしたほうが良いです。

えーとも
えーとも

引継ぎは業務のシェイプアップチャンスっていう

えーともの引継ぎ結果

自分は引継ぎを

  1. 関連資料を一気に作成(13営業日くらい)
    資料作成の期間中、後輩には関連技術の勉強や他業務を体験してもらって社内を知ってもらう。
  2. 怒涛の引継ぎ開始

って流れでやりました。

ちなみに作った資料の半分くらいは3ヶ月以内に不要になるフラグが立ちました。

えーとも
えーとも

うれしいよーな。悲しいよーな。

担当していたWebサイトの中で一番大きいのをリニューアルした

引継ぎで一番ボリュームがあって、技術負債盛りだくさんのWebサイトをラスト一週間で後輩と一緒にリニューアルしました。

元々は自分が辞めてから「マイペースでゆっくり進めてね。ある程度はサポートするから」という話だったのですが「えーともさんが居るうちにリニューアルしないとヤバくない…?」という話になったので、ラスト一週間で急きょリニューアルすることに。

一応引継ぎをした後だったのですが、Wordpress初挑戦の後輩をメインに自分はサポートに徹しました(たぶん)。

サイトリニューアルのメリット

既存機能への理解が深まる

既存機能をリニューアルサイトに移行する際には一部ソースの書き換えをしたりするので、否が応でも機能への理解が深まります。

不要な機能を切捨てできる

また、使われていない機能の中でも「後輩の理解力が追いつかない機能」については思い切って切捨てることにしました。

切捨てた機能は使われていないので、全体として見てみると問題はありません。
上の人間が「絶対にほしい」と言い出すようなら旧サイトのソースを引っ張り出してくる話になると思います。

えーとも
えーとも

独自プラグインの形式で開発しているので、新サイトでも動作するハズ…。

動作確認はできなかったけど。

リニューアルのおかげで技術負債の8割が消えました

蛇足:「自分が居なくてもこれで大丈夫」はありえない

引継ぎを始めると「自分が居なくても大丈夫と言い切れるくらいの資料を作って」という人が出てくることがありますが、表題の通り不可能な要望なので無視しちゃってOKです。

世の中、多種多様な人が居るので「この資料があれば絶対大丈夫」は100%ありえません。

残された時間から逆算して作れる資料の質・量と、引き継ぎの質の向上を追求していく。

一番大事なのは「引継ぎが終わった時に相手が理解できているか」です。
えーとも
えーとも

「これで大丈夫かなぁ?」とか思うエネルギーと時間が無駄無駄無駄ァ!

こちとらケツカッチンなんだよぉ!

おわりに:引継ぎは「無駄な業務の切捨て」チャンスにもなる

 

先ほども書きましたが、実際に大仰な資料を作ったものの「蓋を開けてみれば要らなかった業務だった☆」ってのもありました。

引き継ぎ資料を作る前に各業務の管理者に「この業務は本当に必要か」を確認して回ることの大事さがわかりますね。

「全業務把握してる管理者居ないの?」と思われるかもしれませんが社内一人SEという都合上、明確な管理者が居らず自分が受け持っている全ての業務を知っている人は居ませんでした。

零細企業のため、かなりの属人化が進んでいましたが今回の引継ぎで緩和された…と思いたいところ。

「お仕事辞めたいけど引継ぎ面倒だなぁ」って思っている方は、今回の記事が下準備のお役に立てば幸いです。

えーとも
えーとも

それでは、えーともでした〜♪

コメント