やめていくシステム管理者から仕事を引き継ぐには？ 98
ストーリー by headless
後継 部門より
後継 部門より
本家/.「Ask Slashdot: IT Staff Handovers — How To Take Over From an Outgoing Sys Admin? 」より
私はITサービス企業での仕事を始めたばかりだが、3年間担当していた前任者から仕事を引き継ぐ必要がある。仕事をほかのITスタッフから引き継ぐ際に、知識を譲ってもらうベストプラクティスはどんなものだろう。特に、ある程度のドキュメントは存在するものの、多くは前任者の頭の中にある場合、どうすれば1週間で数千のホストやネットワーク、関連するソフトウェアシステムを理解できるだろうか。
日頃から引継ぎ資料を作っておくものです (スコア:5, すばらしい洞察)
ハード故障時などに、手順を間違えてバックアップ・リストアに失敗したとか、
泣きついてくるSEがサポートデスクに定期的に来る。
色んな理由はあるにせよ。
何だかなー。それでも本当にプロなのか？と時々思うことがある。
引継ぎができるかどうかは、個人能力もあるけど組織力もある。
システム管理とは、現在のシステムの監視するだけではなく、
そのシステムを永続的に安定稼動させるための施策を行っていくこともある。ある筈なんだ……。
Re:日頃から引継ぎ資料を作っておくものです (スコア:5, おもしろおかしい)
「去年の俺がちゃんと今年の俺に引き継ぎしなかったせいで…あの野郎…」とか思うことがときどきあります。ごめんなさい。
Re:日頃から引継ぎ資料を作っておくものです (スコア:2, 興味深い)
理想論としてはそうなんだけど、
「引き継ぎ資料なんて無駄な物を作る暇があったら仕事しろ」
と言ってくるような上司の下だと、引き継ぎ資料を作ると評価が下がって、
下手すると解雇される恐れもありますよ。
＃そして首にした後で、後任が苦労するからこういう話題が出るんだけど
そのあたりはＴＰＯに合わせましょう。
大半の日本企業だと引き継ぎ資料は作らないのが推奨。orz
Re:日頃から引継ぎ資料を作っておくものです (スコア:2)
その「経営」も、うちに頼めばなんとかしますよ。
是非ご発注ください。
あ、経営者のあなたはもう用済みなんで。
設定ファイル読め (スコア:5, おもしろおかしい)
一方、バックアップ・リストア系はヤバい。前任者も本当にディザスタ・リカバリをした事はないとか、のちに変更した設定がミスっていても分からなかったとか、危険性が著しく高い。これは良く聞いておけ。
後は、予備機とかで「テスト」や「練習」できるようにしておけ。予備機ならミスってデータ飛ばしても笑ってやりなおせばいい。本番機で「ぶっつけ本番」だけは、やめとけ。
資料もなぁ。作れって言うから上司でも理解できるように図などを用いた「分り易い」内容だけを書いた資料を残すとバカな上司が資料だけ見て理解したつもりになって「この手順書さえれさえあればこいつを首にして安い奴と置き換えられる」って思うからなぁ。いや、こんなバカ向けの手順書に書ける内容じゃないんだよ、システム管理ってのは。だったら、バイトでもお前の代わりができる手順書書けるなら書いてみろよって言いたい。まぁ、答えは「ふざけるな！」だろう。システム管理だって一緒。知識と経験、そして人間の判断ってものが必要なんでね。
Re:設定ファイル読め (スコア:5, 興味深い)
DVD1枚分のオリジナル版仕様書とオリジナル版運用マニュアルに、BD-R2枚分の修正履歴と修正版マニュアル束を渡されて途方に暮れたことがある。
おまけに、バックアップと権限管理とシステム独自の処理のため、設定ファイルが標準の位置にない。セキュリティの都合とか言って、SELinux+chrootでパスが複雑になっていて、面倒この上ない。
確かに物はそろっていたし内容も間違っていなかったが、学習期間ぐらいは欲しかった。
#まったく、前任者を過労死なんかさせるから、後が大変になる。
Re:設定ファイル読め (スコア:5, 参考になる)
が、「なぜこの設定・コードになったのか」はコメントなり口伝なりに残しておいて欲しいなあ、と。
設定とかソースを読んでわからないものは、たいてい何らかの理由があったので。
変更して良いかの判断を慣れる前にすることもあり、アンドキュメンテッドな情報はバカにできません。
Re:設定ファイル読め (スコア:1)
私は件の本を読んだことがないのですが、ちょっと興味を持ちました。七巻にたどり着く頃にはすっかり忘れているでしょうから、問題なさそうです。
ただ、そういうのの証拠としての能力ってどうなんですかね。版管理されてておいそれとは改ざんできないんですかね。うーん。
Re:設定ファイル読め (スコア:3, すばらしい洞察)
この人から引き継ぎする人は大変だなあ、と思いました。
Re:設定ファイル読め (スコア:2, 参考になる)
こうやって説明を受けるくらいならおとなしく設定ファイルを読もう、と思わせてくれる興味深いコメントではないか！
引き継ぎを受けているはずがなぜか愚痴が始まって時間を無駄にしてしまうのは引き継ぎでのよくあるパターン。
実際、説明を受けるより中身を読んだほうが効率良く理解できる部分というのは多くあるので、
「設定ファイル読め」というのは一理あると思う。
ただ「バグ回避のためにイレギュラーな設定をしている」などは、
後から追うと意図がわかりにくいので、前任者がそういう部分を判断して教えるようにしたらいいね。
Re:大丈夫だよ (スコア:2, おもしろおかしい)
自薦不可
Re:設定ファイル読め (スコア:1)
私はとあるシステムのメンテナンス業務をを上司から引き継いだのですが、定型化できる業務であるにもかかわらずルール化・文書化されていませんでした。
トラブルが発生したため、上司（何処かに出向しているわけではない、同じ職場にいる）に聞くと
「あれー、どうやってやるんだっけ？ 忘れちゃった（笑）」
と一言。
ログや設定を片っ端から調べ、原因を特定して対応したりして、少しずつ勉強していますが、調べてみるとDBのバックアップが定期的に行われていませんでした。
また、システムの運用上の取り決めがないため、前担当者の上司が勝手にサーバーを落としたりしていました。
引き継ぎの対象者がすぐ近くにいても、いなくても、私の意見としては、
・運用上、定期的にやっていること（バックアップとか特に重要）
・起こったトラブルの対応方法
・社内でのシステム運用上のルール（なければ方針を決める）
を相手がいる間に、知ることですね。
そして、それを簡単なメモでもいいからまとめおき、時間があれば少しずつマニュアル化していくことです。
でないとあとで、忘れちゃった（笑）自分、もしくはその後任が大変な思いをします。
Re:設定ファイル読め (スコア:1)
そして、それを簡単なメモでもいいからまとめおき、時間があれば少しずつマニュアル化していくことです。
できればそれを、スクリプト化(プログラム化)しておくと、さらに良いですね。
基本的に、マニュアル化できることは、プログラム化することができるはずですから。
# しかし、運用に「回される」人は、プログラムが苦手だったり…
Re:設定ファイル読め (スコア:1)
設定ファイルのありかはOSが決まればだいたい決まるから、システムの設定を見ればわかるだろ。説明が要るぐらいなら引継ぎなんて無理。つまり、前任者の考えている事は、設定ファイルの記述に反映されている。
ま、概ね同意なんだけど、「意図」まで設定ファイルで伝わるかは分からない。ある設定が「意図」を持った設定なのか、どこからかコピペしただけで、本来は不必要なないようなのか、かつての設定を引き継いだだけだったり、一時的に入れた設定のように、既に不要となっている設定なのか、といった辺りは、設定を見ただけでは分からない。故に「触らぬ神に祟りなし」で、未来永劫、無駄設定が引き継がれてゆく...。
で、「意図」を正しく理解するためには、バックボーンとなる知識が必要、という事が理解されないから、「パソコン得意そうだから、今度からお前な」になってしまう...
Re:設定ファイル読め (スコア:1)
私は極力手順書やドキュメントを書くようにしています。
プログラムソースのコメントと同じ感覚で。
で、俺が死んでも手順書はあります。俺が不慮の事故で死んだらよろしくお願いします。
と、統括管理者なお客さんに度々いってますわ。
日々情報共有はしていますので、手順書に起こしがたいものは暗黙の了解として、手順書にしていません。
作業履歴として、自分が使ったデータを全部残しているだけです。
統括管理者なら私の代わりに作業ができますが
後任はシステムを理解するまで手順書の使いどころがわからないでしょうね。
私が引き継ぐときには、半年ぐらいほしいです。
年一のイベントとかは、実地で教えたいですから。
ああ、まだ未体験な年末イベントが怖いです…。
諦める (スコア:5, すばらしい洞察)
人生において「ときどき」必要なことです
RAIDと一緒 (スコア:5, 興味深い)
辞めることが決まってから対応するのは間違い。
引継ぎ期間があるのは、まだマシな方で、事故とか急に居なくなることだってある。
スタッフが入院したんで、サービスが継続できませんなんて会社、誰が利用するの？
サーバとかは一生懸命冗長化するのに、何でもっと大事な所を冗長化しないかなぁ
RAID0： 複数のスタッフで仕事を分担。効率はいいが一人が抜けると手順も失われる。
RAID1： 複数のスタッフが全ての仕事を覚える。一人でも残っている限り、手順が失われることは無い。
RAID5： 各仕事に二人のスタッフを割り当てる。一人が抜けても手順が失われることは無い。
Re:RAIDと一緒 (スコア:5, おもしろおかしい)
| RAID5： 各仕事に二人のスタッフを割り当てる。一人が抜けても手順が失われることは無い。
交換した新しいスタッフへの引き継ぎが通常業務に追加されるのが引き金となって他のスタッフもバタバタと辞めていくんですね。
Re:RAIDと一緒 (スコア:2, 興味深い)
この発想にどうい。
まあそれをどう実現するかという話なのだろうけど、どの１人が倒れても
システムの運営に問題が起きないことを理想として構成を練るのが原則だと思う。
Re:RAIDと一緒 (スコア:5, 興味深い)
しかし、
「バックアップに使ってるHDDやテープは『無駄な物』だからコストダウンの対象だ」
と考えてる管理職に付ける薬はないのです。
バカは死なななきゃ直らない。
Re:RAIDと一緒 (スコア:2)
Re:RAIDと一緒 (スコア:2, 興味深い)
RAID1： 各仕事に二人のスタッフを割り当てる。一人が抜けても手順が失われることは無い。
RAID5 : スタッフが複数の仕事を受け持つ。複数の仕事は別のスタッフと一部は同じだが全く同じということはない。
そんな印象
Re:RAIDと一緒 (スコア:2)
冗長化も重要だけど、一番重要なのはRAIDの「I」だよね。
自分で言ってて悲しくなるけど。
Re:RAIDと一緒 (スコア:2)
Re:RAIDと一緒 (スコア:1)
極限まで一人に任せっきりにするからなぁ・・・。
その例で行くと、うちはRAIDすら組んでいない状況かもしれないです。
Re:RAIDと一緒 (スコア:2)
言い放つのかな。それはそれで、辞める時に後腐れがなくていいかもしれない。
先に騒いだ方の勝ち (スコア:3, 興味深い)
辞めていく人じゃないけど、社内での仕事の引き継ぎをいろいろ
経験していくと、引継ぎする側、される側に関係なく、相手の
引継ぎが悪くて仕事ができない、と騒いで自分に有利な状況を
作り出そうとする人がいるので閉口します。
上手に上を巻き込まれて、いつの間にかこっちが悪者に。
Re:先に騒いだ方の勝ち (スコア:1)
だって悪い人に悪いって言ってあげないと、分からない人がいるんだもの。
それ「自己評価」とやらとは無関係。、
＞引継ぎする側、される側に関係なく、相手の
＞引継ぎが悪くて仕事ができない、と騒いで自分に有利な状況を
＞作り出そうとする人がいるので閉口します。
それが「常に」であればその通りだと思うけど、
そうでなければケースバイケースかな。
本当に自分が良い資料を作って他人への引き継ぎを完璧にしてきた人ほど、
他人の資料のレベルの低さが我慢ならないでしょうから。
そもそも (スコア:3, すばらしい洞察)
数千のホストを一人で管理とかおかしくない？
そのクラスの仕事というか、ビジネスとして真面目に営業しているなら、３年間も一人の人間に頼ったりしちゃダメだろ。
会社として、３年分支払った給料のほとんどを、一週間分だけ残して捨てちまおう！って人事計画な訳でしょ？
システムの管理者権限と、各エスカレーション先等、資料の過不足の確認が、まず最優先事項だろう。
理解しようとか、知識を教えてもらうとか、そんな事をやってたら、一人になってから速攻で事故って終わりだわ。
あと意外と重要なのが、各システムのユーザとか、現場の人とのコミュニケーションだろうね。
最悪事故っても、まだ代わったばっかだからとフォローしてくれる人が現場に居ると、すごく楽。
事故の最中に末端からの電話攻撃とか、無理解者による直接訪問とか、一人じゃ事故対応が出来なくなっちゃう。
外注しよう (スコア:2)
前任者→整理を外注→そのまま運用を外注 or 改めて引き継ぎ
お仕事、お待ちしております。
Re:外注しよう (スコア:5, 参考になる)
それは(そのころいたエンジニアが辞めてしまったため)運用できる人間がいないので引き受けられない。
という返答で大混乱になるパターン…
#実際にやられた。
Re:外注しよう (スコア:1)
あとから言われたら困りますが、前提として言ってもらえれば喜んで受けますよ。
# 実際やった
Re:外注しよう (スコア:1)
でも、お高いんでしょう？
＃そういうグダグダ案件で予算がないのは良くあることだと思う。
Re:外注しよう (スコア:1)
んー、おっしゃるとおり、この手の話は払える金額が読めたりもするからねぇ。その場合は何とか合わせるかなぁ。
害虫しよう (スコア:0)
それ引き継いでいないからわかりません。
資料がないからわかりません。
ひきつぐ仕事を減らす (スコア:2, すばらしい洞察)
よくわからないシステムがあったらこんなの引き継いでないといって無視する
または適当に壊れたとか理由つけて廃棄
適当な管理してる会社ならシステムが少し減っても気づかれない
Re:ひきつぐ仕事を減らす (スコア:1)
適当な管理している会社だったら、システム止めて経費を浮かしたほうが
手柄になったりして
以前、引き継いだシステムの半分以上がまともに使われていなくて
「しらぬふり」して止めたことがありました
まともに使っていなかったので、だれからも文句ひとつきませんでした
・・・前任者の金の使い方を疑ってしまいました
Re:ひきつぐ仕事を減らす (スコア:1)
元コメの内容は知らないけど
「このシステムが動いていること」が、とある規制用件の一つとして必要だったり
突発的に起きるトラブル対策として動かしているから数年程度何も反応が無くてもおかしくないシステムだったり
変なトコで他のシステムと連動してて利用者が居ようと居まいと動いてないと他システムに変なログが残るものだったりすると、
今は問題ないように思えても、後でダメージを受ける可能性もありますね。
#という思考は「ゴミが捨てられない」「部屋が片付けられない」という人の典型的な言い訳なので、ちゃんと見極めが必要なのは言うまでもない。
まともな会社は (スコア:2, すばらしい洞察)
利益を生み出している装置をたった1人の社員に任せ切ったりはしない。
Re:まともな会社は (スコア:1)
割りとするよ？ しかも、冗長性を保つように後任を育てるのも自分の仕事らしい。アサイン権限はないのだが。
知識は無料じゃない (スコア:2, すばらしい洞察)
業務の引き継ぎというより、知識の継承を期待する人って多いですね。
受託SIでも発注元がよく要求するんですが、構築方法を完全に手順化しろとか、Linuxサーバの管理ノウハウを手順化しろとかActive Directoryの運用方法をマニュアル化しろとか。
そういうのは本屋で参考書を買ってきて勉強したり、どっかの技術者向け養成講座を受けてくださいと。
同僚から知識を得たいなら、普段からのコミュニケーションで得ておくべし。
辞める時になってから習おうなんて図々しい。
普段から学んでおけば、その人も辞めずに済んだかもしれない。
負荷を分散できただろうし。
出来るIT技術者が欲しがるものって（日本の場合は）コピーロボットです。
もちろんそんなのは現実には無いので、それに近い存在を同僚に求めるのですよ。
それが無ければ疲れて辞めていく。
Re:知識は無料じゃない (スコア:1)
訳中にも、知識ってありますね。
引き継がねばならないのは、知識ではなく、
社内の要求と現状の設定なんじゃないかなと思います。
そのためのシステムですし。同じことができれば
別段そのシステムじゃなくてもと思ってしまいます。
知識を得るのは人材育成で、引継ぎですることではありませんね。
大事なのは (スコア:2)
夜はあなたのおごりで飲み屋にでも出かけまくって 愚痴を聞きまくってあげて懇意になりましょう。
そうしたら個人のメアドを教えてもらえます。
そのうちなんとかなるだろう (スコア:1)
> 多くは前職者の頭の中にある場合、どうすれば1週間で数千のホストやネットワーク、関連するソフトウェアシステムを理解できるだろうか。
前任者に来い
前任者にもないから心配すんな
これがAzuru、クラウド時代です
Re:そのうちなんとかなるだろう (スコア:2, すばらしい洞察)
「前任者のとこへ来い 前任者にもねぇから心配すんな」でないとクレージーキャッツのパロとしては不完全ですね。
#と、あーるのパロを入れてみる
引き継ぎなんぞ (スコア:1)
人なんてものはいつ死ぬかもしれないので、引き継ぎができるだけでもありがたいと思ておけ。
# いつ自分が死んでも後の人に迷惑をなるべくかけないようにしたいものです。
勘違いしてそう (スコア:0)
引き継ぎは、これは必須という事項を中心に可能な範囲で行うものであって、それ以外は実務に携わりながら覚えていくしかない。
前任者との引き継ぎは一切無かったなんて話も珍しくないし、一週間も時間があるなら恵まれている方だよ。
Re: (スコア:0)
単に不可能とは限らないから完璧にやってみたいってことなんじゃないかなと
もし3億円当たったらどうすると同じような話のネタ提供でしょ
Re:引継ぎの (スコア:3)
普通は一ヶ月ぐらい前に辞めますと言うもんですが、有休残も一ヶ月以上あることも珍しくない…
Re:引継ぎの (スコア:2)
そういう甘やかしが良くないと思う。まぁ、状況にもよるかもしれませんが自由ですが。いずれにせよ有休は権利であるからして、自分で行使するものであって会社が「使わせてくれる」ものではありません。会社には時季変更権があるけれど、退職日が決まっていれば行使の余地はない。
「○月○日付で退職します。×月×日から有休を取得します。」と一筆書いて、FAX なりメールなりで送る。給料が払われなかったら電話してみて払わないと言われたら労基署に連絡。給料未払いなら大抵はまともに対応してくれるはずです。