マニュアル命のSE

質問

長文になります。

OS・ミドル系インフラエンジニア3年目です。

常駐型の運用プロジェクトで、昨年9・10・11月に増員し、うち2名は契約元の会社（40代ライブラリアンと30代手前の元開発者）、1名は自社のメンバーです。

はっきり言って、契約元の2名が曲者で困っております。
「マニュアル命」で、「仕事」ではなく「作業」に集中している傾向があります。

今まで既存のメンバーで回していたため俗人化していたことや、マニュアル等整備できていなかった点は認めます。
しかし、既にできているものを自分たち流に作り直すまではともかく、
それを元に作業しているにも関わらずミスしたり、
既存のものやこちらが作り直したものを見ずに間違えたりするので、困ります。

また、マニュアルの見た目は綺麗でも肝心な部分が抜けていたり、
管理簿の書き方やログ1行までわざわざスクリーンショットを貼るので「そんなことに時間をとるなよ」と思います。

そもそも、既存と被るドキュメントを作り直して良いかどうかを既存メンバーに聞きもせずに勝手に作るのが良い度胸をしていると思いますし、
エビデンスか備忘録かよくわからないものを含めて色々とマニュアルらしきものを勝手に作り過ぎた挙句「整理します」と自滅したのには呆れました。

他には、作業を短縮するためにバッチがあるのにGUIで操作していたり（既存の手順書を良く読んでいない）、
調査を依頼されてネットで散々調べた挙句「わかりません」とのたまわったり（人に聞いたり、検証しないのが謎です）
新しく出すメールがあり、近い雛型を使って間違えて「雛型が悪い」というようなことを言ったり、
雛型や手順書をアテにしすぎる彼らは本当に技術者なのか？と疑問を抱きます。

話を聞く態度が腹立たしいので、最近は進んで色々と教えなくなりましたし、仕事も自社メンバーに振ることが多くなりました。

彼らをどのように扱っていけば良いか、頭が痛い日々です。

現在、自社の上司がご家庭の事情で相談しづらい状況につき、ここに参りました。
アドバイス宜しくお願い致します。

回答No.2

imachan_net · ベストアンサー

４０代のシステムエンジニアです。

私の経験からいうと、
確かに入社３年目って一番大事な時期で、
それまではいろいろな細かいことだったり１つ１つの作業が、
つながりがなくてよくわらない状態だったりして、いままでは困惑していたかと思います。
それが、やっとこさ、社内だったり、業務全体だったり、関係性が見えてきて、
仕事が楽しくなり、改善したいこと、やりたいこと、いろいろ見えてきて、
『あー、こーなんだ、そっか・・・』って思うこと、感じることがたくさん出てくる時期だったように、
自分は感じます。
それだけに、やりがいも有ったし、向上心も有ったかと・・・

だから、質問者の方も頑張って欲しいと思って、書いています。

質問内容をずらずら・・・いろいろ書いているけど、
・組織、命令系統はどうなっているの？
・本来はこれまでの背景・経緯がどうで、何が目的で何を今はするの？これからは何をするの？
・現在の問題点は何で、何が課題なの？だから、今は何をして、今後何をしていくの？
・誰には何を聞いて、何をどのように判断するの？誰が判断出来るの？判断していいの？
等、を考えたら、おのずと、ただの愚痴なのか、
本当に困っていることが有って、その困っていることに対し本当に何をすべきか見えてくると思います。

気になったのは、
運用プロジェクト・・・って何？
運用って、ずっとあるもので、組織で有って、プロジェクトではないです。
プロジェクトは一過性のものであって、定例の運用で問題が有って、
何かを改善する為のプロジェクトではないの？

もし、これまでの運用で問題有るから、
運用を見直して、改善して、ドキュメントを整備して、
またスパイラルアップするのではないの？
と感じました。

まずは、関係者を集めて、
それぞれの今のやり方の確認なり、
困りごとの持ち寄りで、
話す場を設けることです。

少しでも役に立てれば、
１つでも気に留めてもらえたことが有ったら幸いです。

では、肩の力を抜いて・・・
明日から３連休です。
ゆっくりと考えて下さい。
仕事場で考えてるよりは、
オフのときに思ったこと、感じたこと、したいと思ったことって、
結構、仕事の改善だったり、本当に良かったことって出てきますよ。

お礼

かなり感情的になってしまっていたので、落ち着いて考え直す機会になりました。
ただの愚痴や悪口にはしたくないと思っており、
問題点が見えてきました。
手厚いご回答、ありがとうございました。

回答No.4

Oaktreefield（@Oaktree-field）

もとＳＥです。プロフィールを参照願います。

＞バッチがあるのにGUIで操作していたり
コマンドライン入力（シェル）が、究極のオブジェクト指向なのにね。

明らかに、その両名は素人レベルですので、
＞彼らをどのように扱っていけば良いか、頭が痛い日々です。
私なら、コストカットします。

＞「雛型が悪い」というようなことを言ったり、
そういう人に限り、問題を他人のせいにします。

個人的な経験では、そういう人は、むしろいないほうが作業効率は、上がると思います。

回答No.3

noname#208883

1.上司に相談すべきです。
たとえ家庭の事情があろうともです。

2.同じ質問をしない。
これはルールです。

回答No.1

SePapa

こんにちは。

私も過去にプロジェクトのリーダーをしたことがありまして
その経験から回答します。

まずは機会的な対策例を回答します。

・ＩＳＯという標準化の考え方がありますが、
そのような規格にて品質向上を図る場合に必要な例ですが、
ドキュメントを作成する場合は必ず管理Ｎｏをふってください。
そして改定履歴も表紙の次とかに絶対につけて必ずいっしょにファイルします。
文書を変更する場合は改定者が改定履歴を書いた上で
必要なレベルの上長の承認を得てから初めて運用開始します。
もっと厳密にやるのであれば、そのマニュアルのテスト期間を設けて
その期間中に実際使用してみた担当者間で回覧に改善点などのコメントを書かせます。
ドキュメントというのは運用品質の命です。
必要な承認なしに勝手に本番で使用することはあってはなりません。

・次にトラブルですが、トラブル発生時は起因者に必ずトラブル報告書を書かせ
恒久対応を絶対にかかせます。
どんなトラブルでも絶対に恒久対応は存在します。
それがマニュアルの変更なのか、教育の問題なのか。。。
本人に考えさせることが重要です。
そして、できれば月次でそのトラブル傾向を分類別にわけて資料作成し、お客様に報告します。
トラブルをいかに対策して減らしていくか、ということをプロジェクト全体で
意識して取り組むことが必要です。

・次に精神的、教育的な方法ですが、
プロジェクトを組むと必ず、一癖、二癖ある人が存在するものです。
一番大事なのは、何でもかんでも上から押し付けるのではなく、
普段は喫煙所とかでも近づいていってバカ話などしながら信頼関係作っておくことです。
そして、ここぞというときにはトップダウンで支持してまとめることが必要です。
ときに反対されそうな事案の場合は、事前にネゴしておくことも重要です。
運用管理者で一番大変なのは、メンバーのモチベーション管理だと思います。