＼回答があります！／

• 

  Dai Fujihara

  プロジェクトマネジメント

  2年前
  こんにちは。
  
  新卒でSIで働いていたときに学んだのですが、あの業界は入れ替わりが多いので、「手離れのいい仕事をしたほうがいい」と学びました。そうしなければ次に移れないし、残された人が苦労するので、自分の評価も下がるからです。
  
  それ以来、あるポジションについたときから、再現可能な部分や必要最低限の情報は残すようにしています。開発にかたよった内容になりますがこんな感じ。
  
  1. インセプションデッキ（ちょうど今日自分のフォーマットを公開しました https://daipresents.com/2023/03/17/new-inception-deck/）
  2. システムの全体図、もしくは重要な箇所の設計図
  3. 各種手順書
  
  1は、チームのオンボーディングになるように、意義、短期的なゴール、方向性をまとめます。チームの活動とその意図（とくに意図はだんだん薄れるので明示的に書いておく）があると、バトンを受け取りやすくなります。
  
  2は、開発に最低限必要なものを考えると出てくると思います。最低限で考えると全体図や重要箇所は必須になるかと。
  
  3は運用作業、定型作業など、自動化できてない部分のメモです。これがあればだれでもできるようになります。
  
  これにくわえ、自分があるポジションに付いたときに、自分のポジションを引き継げる人の育成を開始しています。引き継ぎが決まってから教えていては遅いと感じたからです。とくにエンジニアリングマネージャになったときは、すぐにエンジニアリングマネージャ候補を考えました。
  
  参考までに！
  view数 23
  • 1
  • 1

• 

  ST

  デザイナー

  1年前
  私が以前、引き継がれ時に、前任者とのミーティングを設定してもらって確認したことは、
  ・ワークスペースのどこにどんなものがあって、どれをどのように使っているか
  ・今まで検討してきたことのあらまし
  　（どういう意図で作って、どういう意図で取り入れ/却下したか）
  です。
  
  デザイナーだと、作った画面がただただたくさん並んでいたり、コンポーネントのガイドのみ残っていて、
  どのUIがどういう理由でボツになり、結果どうなったのかという検討の流れが、あまり明確に書かれていないことが多いです。
  
  すべて確定したデザインで新しい画面を作るなら、そのまま流用すれば良いのですが、
  大体引き継ぎ時は今まで作ったものを見直してブラッシュアップしつつ、が多いので、
  一度固まった議論の無駄な掘り起こしを防ぐためにも、検討のヒストリーがパッとわかると、わざわざミーティングを設定しなくても済みます。
  
  前任者も全工程をまとめて思い出すのは大変そうだったので、普段から画面とドキュメントを合わせて整理して残しておくとスムーズでした。
  view数 29

• 

  和田健太郎

  エンジニア

  2年前
  必要な準備というのは諸々動かれていると思うので、どちらかというとそこに取りこぼしが発生する前提で、引継ぎ後のコミュニケーションの場を設定して置くというのはよくやっております。
  
  ■引継ぎ後の３ヶ月くらいは週１位の頻度で引継ぎ前後のメンバーでランチMTGでお困りごとがないか確認してみる。
  ※退職されてしまう場合は残念ながらこの限りではないですが、その場合は正式な引継ぎ日から前倒して予行演習期間として業務に入ってもらうことが多いです。
  
  ■引継ぎ用に作成してもらったドキュメントについては、第三者理解が出来るものかの観点でレビューする。
  →　ドキュメントはソースコードと同じでそれなりにスキルが必要な認識なので、書かれっぱなしになると伝達に齟齬が発生するのは必至です。なので第三者にレビューをしてもらうことがママあります。
  
  ■前任者に、情報の押し入れにタグを入れまくってもらう
  →　「この業務をするにはどこを参照すればいいんだ？」で手が止まることが現場では往々にしてよくありますので、「整理はしなくていいからキーワードだけタグ付けしておいてほしい」みたいな指示をとりあえず大量にやってもらって、検索インデックスを入れておいてもらうことはよくあります。
  
  どちらかというと体系立てたものではなく、過去の経験から飛び道具を回答させてもらったという形ですが、、、ご参考頂けますと幸いです。
  view数 25
  • 1
  • 1