パスワードを忘れた? アカウント作成
9683297 story
ネットワーク

やめていくシステム管理者から仕事を引き継ぐには? 98

ストーリー by headless
後継 部門より
本家/.「Ask Slashdot: IT Staff Handovers — How To Take Over From an Outgoing Sys Admin? 」より

私はITサービス企業での仕事を始めたばかりだが、3年間担当していた前任者から仕事を引き継ぐ必要がある。仕事をほかのITスタッフから引き継ぐ際に、知識を譲ってもらうベストプラクティスはどんなものだろう。特に、ある程度のドキュメントは存在するものの、多くは前任者の頭の中にある場合、どうすれば1週間で数千のホストやネットワーク、関連するソフトウェアシステムを理解できるだろうか。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2013年08月04日 19時48分 (#2434462)

    ハード故障時などに、手順を間違えてバックアップ・リストアに失敗したとか、
    泣きついてくるSEがサポートデスクに定期的に来る。

    色んな理由はあるにせよ。
    何だかなー。それでも本当にプロなのか?と時々思うことがある。

    引継ぎができるかどうかは、個人能力もあるけど組織力もある。
    システム管理とは、現在のシステムの監視するだけではなく、
    そのシステムを永続的に安定稼動させるための施策を行っていくこともある。ある筈なんだ……。

  • 設定ファイル読め (スコア:5, おもしろおかしい)

    by Technical Type (3408) on 2013年08月04日 20時52分 (#2434485)
    設定ファイルのありかはOSが決まればだいたい決まるから、システムの設定を見ればわかるだろ。説明が要るぐらいなら引継ぎなんて無理。つまり、前任者の考えている事は、設定ファイルの記述に反映されている。あとは、1週間あるなら優先順位をつけて前任者に教えてもらえ。このあたり、スキルの低い後任者だと、あれも教えてくれ、これも教えてくれと、重要じゃない事を伝授させて肝心な事を教わり損ねるのがオチ。で、「教えてくれなかった」とか言うし。「あんな無意味な事を貴重な一週間のうち4日もかけて説明を強いたのはお前だろ。結局管理はできないし利用者も僅かだったからサービスやめたんだってな、オレが居なくなった直後に!」と言い返したくなるような間抜けをやる。
    一方、バックアップ・リストア系はヤバい。前任者も本当にディザスタ・リカバリをした事はないとか、のちに変更した設定がミスっていても分からなかったとか、危険性が著しく高い。これは良く聞いておけ。
    後は、予備機とかで「テスト」や「練習」できるようにしておけ。予備機ならミスってデータ飛ばしても笑ってやりなおせばいい。本番機で「ぶっつけ本番」だけは、やめとけ。
    資料もなぁ。作れって言うから上司でも理解できるように図などを用いた「分り易い」内容だけを書いた資料を残すとバカな上司が資料だけ見て理解したつもりになって「この手順書さえれさえあればこいつを首にして安い奴と置き換えられる」って思うからなぁ。いや、こんなバカ向けの手順書に書ける内容じゃないんだよ、システム管理ってのは。だったら、バイトでもお前の代わりができる手順書書けるなら書いてみろよって言いたい。まぁ、答えは「ふざけるな!」だろう。システム管理だって一緒。知識と経験、そして人間の判断ってものが必要なんでね。
    • by Anonymous Coward on 2013年08月04日 22時04分 (#2434524)

      DVD1枚分のオリジナル版仕様書とオリジナル版運用マニュアルに、BD-R2枚分の修正履歴と修正版マニュアル束を渡されて途方に暮れたことがある。
      おまけに、バックアップと権限管理とシステム独自の処理のため、設定ファイルが標準の位置にない。セキュリティの都合とか言って、SELinux+chrootでパスが複雑になっていて、面倒この上ない。

      確かに物はそろっていたし内容も間違っていなかったが、学習期間ぐらいは欲しかった。

      #まったく、前任者を過労死なんかさせるから、後が大変になる。

      親コメント
    • by yuki_next (39550) on 2013年08月04日 22時07分 (#2434527) ホームページ
      私は引き継ぎ作業は相手に依る気がしていて、最初の一文で仰るようなやり方もアリだと思っています。

      が、「なぜこの設定・コードになったのか」はコメントなり口伝なりに残しておいて欲しいなあ、と。

      設定とかソースを読んでわからないものは、たいてい何らかの理由があったので。
      変更して良いかの判断を慣れる前にすることもあり、アンドキュメンテッドな情報はバカにできません。
      親コメント
    • Re:設定ファイル読め (スコア:3, すばらしい洞察)

      by Anonymous Coward on 2013年08月04日 21時14分 (#2434499)

      この人から引き継ぎする人は大変だなあ、と思いました。

      親コメント
      • by Anonymous Coward on 2013年08月05日 8時49分 (#2434642)

        こうやって説明を受けるくらいならおとなしく設定ファイルを読もう、と思わせてくれる興味深いコメントではないか!
        引き継ぎを受けているはずがなぜか愚痴が始まって時間を無駄にしてしまうのは引き継ぎでのよくあるパターン。

        実際、説明を受けるより中身を読んだほうが効率良く理解できる部分というのは多くあるので、
        「設定ファイル読め」というのは一理あると思う。
        ただ「バグ回避のためにイレギュラーな設定をしている」などは、
        後から追うと意図がわかりにくいので、前任者がそういう部分を判断して教えるようにしたらいいね。

        親コメント
    • by Anonymous Coward on 2013年08月04日 23時33分 (#2434562)

       私はとあるシステムのメンテナンス業務をを上司から引き継いだのですが、定型化できる業務であるにもかかわらずルール化・文書化されていませんでした。
       トラブルが発生したため、上司(何処かに出向しているわけではない、同じ職場にいる)に聞くと
      「あれー、どうやってやるんだっけ? 忘れちゃった(笑)」
       と一言。
       ログや設定を片っ端から調べ、原因を特定して対応したりして、少しずつ勉強していますが、調べてみるとDBのバックアップが定期的に行われていませんでした。
       また、システムの運用上の取り決めがないため、前担当者の上司が勝手にサーバーを落としたりしていました。

       引き継ぎの対象者がすぐ近くにいても、いなくても、私の意見としては、
      ・運用上、定期的にやっていること(バックアップとか特に重要)
      ・起こったトラブルの対応方法
      ・社内でのシステム運用上のルール(なければ方針を決める)
       を相手がいる間に、知ることですね。
       そして、それを簡単なメモでもいいからまとめおき、時間があれば少しずつマニュアル化していくことです。

       でないとあとで、忘れちゃった(笑)自分、もしくはその後任が大変な思いをします。

      親コメント
      • by Ryo.F (3896) on 2013年08月05日 10時24分 (#2434696) 日記

        そして、それを簡単なメモでもいいからまとめおき、時間があれば少しずつマニュアル化していくことです。

        できればそれを、スクリプト化(プログラム化)しておくと、さらに良いですね。
        基本的に、マニュアル化できることは、プログラム化することができるはずですから。

        # しかし、運用に「回される」人は、プログラムが苦手だったり…

        親コメント
    • by JULY (38066) on 2013年08月05日 9時40分 (#2434663)

      設定ファイルのありかはOSが決まればだいたい決まるから、システムの設定を見ればわかるだろ。説明が要るぐらいなら引継ぎなんて無理。つまり、前任者の考えている事は、設定ファイルの記述に反映されている。

      ま、概ね同意なんだけど、「意図」まで設定ファイルで伝わるかは分からない。ある設定が「意図」を持った設定なのか、どこからかコピペしただけで、本来は不必要なないようなのか、かつての設定を引き継いだだけだったり、一時的に入れた設定のように、既に不要となっている設定なのか、といった辺りは、設定を見ただけでは分からない。故に「触らぬ神に祟りなし」で、未来永劫、無駄設定が引き継がれてゆく...。

      で、「意図」を正しく理解するためには、バックボーンとなる知識が必要、という事が理解されないから、「パソコン得意そうだから、今度からお前な」になってしまう...

      親コメント
    • 私は極力手順書やドキュメントを書くようにしています。
      プログラムソースのコメントと同じ感覚で。

      で、俺が死んでも手順書はあります。俺が不慮の事故で死んだらよろしくお願いします。
      と、統括管理者なお客さんに度々いってますわ。
      日々情報共有はしていますので、手順書に起こしがたいものは暗黙の了解として、手順書にしていません。
      作業履歴として、自分が使ったデータを全部残しているだけです。

      統括管理者なら私の代わりに作業ができますが
      後任はシステムを理解するまで手順書の使いどころがわからないでしょうね。

      私が引き継ぐときには、半年ぐらいほしいです。
      年一のイベントとかは、実地で教えたいですから。

      ああ、まだ未体験な年末イベントが怖いです…。

      親コメント
  • 諦める (スコア:5, すばらしい洞察)

    by iwakuralain (33086) on 2013年08月04日 20時54分 (#2434486)

    人生において「ときどき」必要なことです

  • RAIDと一緒 (スコア:5, 興味深い)

    by Anonymous Coward on 2013年08月04日 20時56分 (#2434488)

    辞めることが決まってから対応するのは間違い。
    引継ぎ期間があるのは、まだマシな方で、事故とか急に居なくなることだってある。
    スタッフが入院したんで、サービスが継続できませんなんて会社、誰が利用するの?

    サーバとかは一生懸命冗長化するのに、何でもっと大事な所を冗長化しないかなぁ

    RAID0: 複数のスタッフで仕事を分担。効率はいいが一人が抜けると手順も失われる。
    RAID1: 複数のスタッフが全ての仕事を覚える。一人でも残っている限り、手順が失われることは無い。
    RAID5: 各仕事に二人のスタッフを割り当てる。一人が抜けても手順が失われることは無い。

    • Re:RAIDと一緒 (スコア:5, おもしろおかしい)

      by yug (32253) on 2013年08月04日 22時38分 (#2434543)

      | RAID5: 各仕事に二人のスタッフを割り当てる。一人が抜けても手順が失われることは無い。

      交換した新しいスタッフへの引き継ぎが通常業務に追加されるのが引き金となって他のスタッフもバタバタと辞めていくんですね。

      親コメント
    • Re:RAIDと一緒 (スコア:2, 興味深い)

      by Anonymous Coward on 2013年08月04日 21時27分 (#2434506)

      この発想にどうい。

      まあそれをどう実現するかという話なのだろうけど、どの1人が倒れても
      システムの運営に問題が起きないことを理想として構成を練るのが原則だと思う。

      親コメント
    • Re:RAIDと一緒 (スコア:2, 興味深い)

      by Anonymous Coward on 2013年08月04日 21時58分 (#2434521)

      RAID1: 各仕事に二人のスタッフを割り当てる。一人が抜けても手順が失われることは無い。
      RAID5 : スタッフが複数の仕事を受け持つ。複数の仕事は別のスタッフと一部は同じだが全く同じということはない。

      そんな印象

      親コメント
    • by ReadOnly (9749) on 2013年08月05日 0時18分 (#2434571)

      冗長化も重要だけど、一番重要なのはRAIDの「I」だよね。
      自分で言ってて悲しくなるけど。

      親コメント
    • by wolf03 (39616) on 2013年08月05日 1時59分 (#2434591) 日記
      足の怪我で入院だった為、病院まで聞き取りに行きました。
      親コメント
    • by Anonymous Coward on 2013年08月04日 21時48分 (#2434518)

      極限まで一人に任せっきりにするからなぁ・・・。
      その例で行くと、うちはRAIDすら組んでいない状況かもしれないです。

      親コメント
      • by miishika (12648) on 2013年08月04日 22時33分 (#2434537) 日記
        一人しかいないシステム管理者にも、無能(かそれ以下)の上司は「お前の代わりはいくらでもいる」と
        言い放つのかな。それはそれで、辞める時に後腐れがなくていいかもしれない。
        親コメント
  • by Anonymous Coward on 2013年08月04日 19時51分 (#2434465)

    辞めていく人じゃないけど、社内での仕事の引き継ぎをいろいろ
    経験していくと、引継ぎする側、される側に関係なく、相手の
    引継ぎが悪くて仕事ができない、と騒いで自分に有利な状況を
    作り出そうとする人がいるので閉口します。
    上手に上を巻き込まれて、いつの間にかこっちが悪者に。

  • そもそも (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2013年08月05日 0時29分 (#2434575)

    数千のホストを一人で管理とかおかしくない?
    そのクラスの仕事というか、ビジネスとして真面目に営業しているなら、3年間も一人の人間に頼ったりしちゃダメだろ。
    会社として、3年分支払った給料のほとんどを、一週間分だけ残して捨てちまおう!って人事計画な訳でしょ?

    システムの管理者権限と、各エスカレーション先等、資料の過不足の確認が、まず最優先事項だろう。
    理解しようとか、知識を教えてもらうとか、そんな事をやってたら、一人になってから速攻で事故って終わりだわ。

    あと意外と重要なのが、各システムのユーザとか、現場の人とのコミュニケーションだろうね。
    最悪事故っても、まだ代わったばっかだからとフォローしてくれる人が現場に居ると、すごく楽。
    事故の最中に末端からの電話攻撃とか、無理解者による直接訪問とか、一人じゃ事故対応が出来なくなっちゃう。

  • by fukapon (4131) on 2013年08月04日 18時06分 (#2434430) ホームページ

    前任者→整理を外注→そのまま運用を外注 or 改めて引き継ぎ

    お仕事、お待ちしております。

  • ひきつぐ仕事を減らす (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2013年08月04日 19時25分 (#2434451)

    よくわからないシステムがあったらこんなの引き継いでないといって無視する
    または適当に壊れたとか理由つけて廃棄
    適当な管理してる会社ならシステムが少し減っても気づかれない

    • by Anonymous Coward on 2013年08月04日 23時19分 (#2434556)

      適当な管理している会社だったら、システム止めて経費を浮かしたほうが
      手柄になったりして
      以前、引き継いだシステムの半分以上がまともに使われていなくて
      「しらぬふり」して止めたことがありました
      まともに使っていなかったので、だれからも文句ひとつきませんでした
      ・・・前任者の金の使い方を疑ってしまいました

      親コメント
  • まともな会社は (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2013年08月04日 23時17分 (#2434553)

    利益を生み出している装置をたった1人の社員に任せ切ったりはしない。

  • 知識は無料じゃない (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2013年08月05日 8時04分 (#2434626)

    業務の引き継ぎというより、知識の継承を期待する人って多いですね。
    受託SIでも発注元がよく要求するんですが、構築方法を完全に手順化しろとか、Linuxサーバの管理ノウハウを手順化しろとかActive Directoryの運用方法をマニュアル化しろとか。

    そういうのは本屋で参考書を買ってきて勉強したり、どっかの技術者向け養成講座を受けてくださいと。

    同僚から知識を得たいなら、普段からのコミュニケーションで得ておくべし。
    辞める時になってから習おうなんて図々しい。
    普段から学んでおけば、その人も辞めずに済んだかもしれない。
    負荷を分散できただろうし。

    出来るIT技術者が欲しがるものって(日本の場合は)コピーロボットです。
    もちろんそんなのは現実には無いので、それに近い存在を同僚に求めるのですよ。
    それが無ければ疲れて辞めていく。

    • by Garry (9310) on 2013年08月05日 14時35分 (#2434840)
      >知識を譲ってもらうベストプラクティスはどんなものだろう。
      訳中にも、知識ってありますね。
      引き継がねばならないのは、知識ではなく、
      社内の要求と現状の設定なんじゃないかなと思います。
      そのためのシステムですし。同じことができれば
      別段そのシステムじゃなくてもと思ってしまいます。

      知識を得るのは人材育成で、引継ぎですることではありませんね。
      親コメント
  • by sindobook (35700) on 2013年08月06日 11時53分 (#2435543)
    昼は重要事項から順番に引き継ぎを受けましょう。
    夜はあなたのおごりで飲み屋にでも出かけまくって 愚痴を聞きまくってあげて懇意になりましょう。
    そうしたら個人のメアドを教えてもらえます。
  • by Anonymous Coward on 2013年08月04日 17時56分 (#2434424)

    > 多くは前職者の頭の中にある場合、どうすれば1週間で数千のホストやネットワーク、関連するソフトウェアシステムを理解できるだろうか。

    前任者に来い
    前任者にもないから心配すんな

    これがAzuru、クラウド時代です

  • by Anonymous Coward on 2013年08月05日 6時45分 (#2434613)

    人なんてものはいつ死ぬかもしれないので、引き継ぎができるだけでもありがたいと思ておけ。
    # いつ自分が死んでも後の人に迷惑をなるべくかけないようにしたいものです。

  • by Anonymous Coward on 2013年08月04日 18時21分 (#2434435)

    引き継ぎは、これは必須という事項を中心に可能な範囲で行うものであって、それ以外は実務に携わりながら覚えていくしかない。
    前任者との引き継ぎは一切無かったなんて話も珍しくないし、一週間も時間があるなら恵まれている方だよ。

    • by Anonymous Coward

      単に不可能とは限らないから完璧にやってみたいってことなんじゃないかなと
      もし3億円当たったらどうすると同じような話のネタ提供でしょ

typodupeerror

日本発のオープンソースソフトウェアは42件 -- ある官僚

読み込み中...