IT企業(SIer)の新人君の成長から学んだ教育方法【自分の力不足を感じた】

その他

いつの時代でも「新人類」っていますよね。

私はリアルタイムで「新人類」(1986年の新語・流行語大賞に選出)って言われていた時期を過ごしていたのでそんな表現になりましたが、社会人でいうなら新入社員は新人類って言われていたような気がします。

最近だと「ゆとり世代」とか「さとり世代」でしょうか。

 

私が勤めている会社はそこそこの大きさなので、毎年必ず新入社員はいます。だけど我が部署に来た新入社員は私の記憶に間違いがなければ、私自身の入社の後、初めてです(22年ぶり)。若手が異動してくることはありましたが。

そしてその新人君は私の直属の部下になって、仕事も組んでやることが多く、新人を育てることに直接かかわることになりました。

 

この記事では、この新人君の言動のいくつかを紹介しつつ、私の経験に基づいたSIreにおける新人教育の押さえどころをシェアします。

スポンサーリンク

システム保守の教育って難しい

私のチームとしての仕事の主軸は稼働中システムの保守です。

システムの使い方に関する問い合わせ対応や改善要望の対応、改善の提案をやります。

たまに新規システムを開発することもありますが、日常的にはシステムのお守であるため、チームメンバーは基本的にはプログラミングはしません(できません)。

上位(企画・設計)部分をやって、プログラム制作部分は他部署や外部に委託します。

そしてシステムテストを経て保守に繋げるというやり方がスタンダードになっています。

 

さて、このような仕事をどのようにして新人に教えるのか、なかなか難しいのです。

これまでは若手の異動者には開発経験者もいたので、ベースの知識に新しいシステムの知識を入れて行けばよかったのですが。

新人君は入社直後の集合研修でプログラミングを含めた、開発工程の一連の教育は受けていました。

ですが、そこで技術力を付けるわけでなく「システム会社ってどんなところ?」ってのを時間をかけて体験してもらったという程度のものでした(その後の新人君の理解度や動きを見てみると)。

自分自身の新人時代を振り返ってみる

私が入社した新人類時j代の約25年前は汎用機で構築されていた集中型システムを、クライアント/サーバ型へ分散・ダウンサイジングするという時期にありました。

入社した1年後ぐらいにWindows95が発売された時代です。

安定稼働していたシステムを組みなおすリプレイスのような作業(非機能要件は変わるけど、機能要件は現行踏襲)な訳で、当時の新人だった私は「勉強がてら」、クライアント/サーバ型へ分散・ダウンサイジングを通じてシステム開発一連の経験ができた時代です。

 

当時の私の役割としてはPG・テスト・移行が主体で、PLは先輩が担当していました。

現行システムの設計書を見ながら、VisualBasicでコードを書き、フロントはAccessかExcelです。

同時期に1週間程度のOracleの講習会に通い、戻ったら即実装。

技術を身に付けるにはネタが豊富にありました。

 

更に、当時の新技術を採用していたため、AccessやExcelでのシステム構築のノウハウは殆どを自分達若手で開拓していました(おっさん達に聞いても知らない)。

先行していたPJの成果物を参考に、自分の担当システムに当てはめて試行錯誤しながら、他のメンバーに聞いたり相談しながら進めて行っていました。

私が新人類って呼ばれていた入社当時は、座学とか定型業務とかで勉強するイメージはなく、自分で調べて作ってみる。そして、一定期間は1つのPJのみに携わっていました。

 

上位組織や部署名が変わっても組織・チームの役割としては変わっていないはずなんですけど、環境の違いは大きいようです。

システム保守チーム新人の教育計画

自分の新人時代とは取り巻く環境が違いすぎると感じながら教育の計画を考えました。

システムの保守って定常業務もありますし、そこも大事なところではありますが、ユーザから期待されるところや売上に繋がる部分はソコではないのですよね。

ユーザ側にもいろいろありますが、システム全般のアドバイザー的・よろず屋的な動きに期待されることろが多いように認識しています(現在、うちのお客様の傾向として)。

 

そんな立ち位置の人材を新入社員からどのように育成して行ったら良いのか、悩みました。

そして考えたのが、下記の2つのステップです。

 

第一ステップとして、まずは稼働中のシステムの理解度を上げ、あわせてユーザ業務知識も与えながら、バックオフィス的な立ち位置で動けるようにすることにしました。

担当している運用システムの仕組みと、そのシステムに関するユーザ業務について座学と実践で教えました。

座学としては設計書と過去のメンテナンス記録や障害記録から、仕組みと特徴を学ばせました。

ユーザ業務はシステムの説明をしながら、業界(製造業)の中での更に個別の業務(受注・仕入・製造・販売等々)の話もしました。

実践はシステム保守・運用の定常作業をすることです。

マスターのメンテナンス依頼対応だったり、定刻処理の異常対応やサーバのログファイルの退避等です。

この間、新規のシステム開発に携わることは1年間でゼロでした。

 

これを1年ぐらいやって、第二ステップでは、そこで蓄えた知識をベースに稼働中システムの第一担当者(ユーザ窓口と主担当)となることを目標にしました。第二ステップで初めてユーザとの接点を持たせるようにと考えていました。

 

私の新人時代との違いとしてもう1つ特徴的なのが、ユーザとの関わり方です。

クソ忙しい劣悪な環境でストレスまみれのSIの部署に配属されたのですから、早々に気を病んでしまわないように大事にせねばと考えました(^-^;

新しい仕事のオファーがあっても、新人君をユーザには対面させなかったんです。

ユーザ業務の知識が皆無で会話もできないとなれば、お客様にも迷惑をかけることになるし、新人君本人にとっても激しいストレスに晒されることが予想できたため、これらを回避するための判断でした。

 

懇意にしていただいているユーザから、「新人が入ったんでしょ?あの仕事やらせないの?」って直に言われても「NO!」。ご迷惑をおかけするので、まだ出せませんって断っていたんです。

まずは知識を付け、会社生活や社会人としても慣れたころに対ユーザのデビューだと考えていたんです。

教育内容の違い

4年前に入社した新人君の勉強・教育の様相とはかなり違いがあります。

時代 25年前の私 現在の新人君
環境 分散型、C/S型システムへの再構築のネタ豊富 安定稼働、開発機会なし
仕事への入り方 1PJ特化 複数システムを並行して担当
教育 自分で覚えて開拓 保守・運用のための座学と定型作業
ユーザとの接点 ほぼ客先で仕事 ほぼ自社で仕事

状況の変化によって育成計画に狂いが生じた

そんな新人君の育成を始めたのですが、しばらくして計画に狂いが出始めました。

教育を開始して半年がたったころ、新人君の女性先輩が寿退社しました。

更に、その半年後、同じチームのベテランが定年退職しました。

 

新人君の育成を始めた直後にこの予定は分かっていました。

もちろん私の上司には増員の申し入れをしましたが、結果としては現状維持でした。

すなわち、残ったメンバーで2名分の仕事をカバーしなければならないんです。

人を増やしてもらえなかった理由は「稼働率を上げれば行けるだろ」というマネージャーの判断です。

え? 2人ですよ。2人抜けたのに、どんな計算で稼働率を上げれば行けるの?

新人君を1年後に対ユーザデビューを考えていましたが、要員が潤沢にいるわけでもなく、教育半年後に1システムのユーザ窓口を担当することになったのです。

あと半年残っていた教育はそこで中断せざるを得ませんでした。

教育している・勉強する時間がないからです。

実践でレベルアップしていくことになりました。OJTです。

 

その時点で、当初計画からできていなかったことで痛手だったのはユーザ業務の勉強でした。

OJTは目の前の業務がメインとなるため、何かの事柄に絡めてユーザ業務を勉強することは時間的にも教育計画的にも難しくなります(スケジュール化できない)。

 

当初計画では、「ユーザと会話ができる下準備をしてデビュー」を考えていましたが
中途半端な状態で「ユーザの中に放り込む」ような形になりました。

ユーザと話せない

新人君は2人の仕事の一部を引き継ぎました。

ベテランの分は上位の仕事(企画・上位設計)もしていたので、それは私が受け持ちましたが、担当としての保守での改善などは全て新人君がいきなり担当を任されることになったのです。

今まで大事に大事に表に出さず育ててきた新人君を、いよいよ世に送り出す日が来ました。
そして愕然としました。

ユーザとの会話ができないのです。

正確に言うなら、コミュニケーションがうまくいかないのです。

ユーザから話を聞くことができない

システムの保守をしていると、ユーザからの問い合わせがあります。

問い合わせのレベルは様々で、システムの基本的な操作方法だったり業務のレアなケースが生じた場合の対処方法だったりです。

まずはユーザから連絡が来て話を聞くことになりますが、起きている事象を理解できないまま電話を切ってしまうことがありました。

一度話を整理したいということであれば、一旦電話を切ることも悪いわけではないと考えていますが、そうではなく、理解できないまま私のところに対処方法を聞きに来るのです。

 

例えば、「A画面のBボタンが押せないそうです。。。」だけ。

新人君は半年間の座学でシステムの勉強はしてきましたが、自分が開発したシステムでもなく、理解度もなかなか測れないわけです。なので回答できないことは問題視していません。

しかし、問い合わせを受けた時に、A画面を実際に見ていないし、仕様も確認していない。

どのような手順でその画面に遷移してきたかとか、どのような情報を入力しているのか、
または、その操作者がA画面の使用経験があるかないか 等々、単純に見える状況でも確認すべきところは諸々あるはずなのですが。

しかし、それらの確認ができないまま、丸投げしてくるのです。

私が受けた印象としては、システムの理解度云々より、問い合わせをしてきたユーザの状況と自分がすべき役割を理解できていない ということでした。

ユーザに正確に説明ができない

ユーザから問い合わせを受けた後に回答をすることになりますが、その回答がうまくできません。

例えば、「Bボタンを押せる条件として、項目Xと項目Yの両方に入力が必要」という説明をしたかったとします。

それが、新人君の説明になると「項目XとYが入力していないため、Bボタンが押せないようになっています」のようになったりします。

てにをはや語順が適切でなかったり、誤解を生じるような表現になります。

頭に浮かんでいるキーワードが先に出てしまい、後でそれをフォローするような話し方になります。

分かり難い内容になる上に、スムーズに話せないため言葉が途切れ途切れになって、余計にわからなくなってしまいます。

新人教育の反省点

新人という一括りにできる訳ではないことは認識しています。

ですが、この新人君の教育を通じて私は下記のことを反省しました。

  1. コミュニケーション能力は実践で身に付ける大切さ
    自分自身がユーザとのコミュニケーションで、これまであまり苦労したことはありませんでした。
    得意ではないですが、頑張るか頑張らないかっていう、個人の問題だと思っていたのです。
    しかし、私は新入社員当時自分でコミュニケーション能力を養われるような環境に放り込まれていて、知らず知らずのうちに体得していたのだと思います。
    この新人君は私が真逆の環境に置きました。ユーザとの接点を絶ちました。
    その間、教育したのは知識のみです。
    知識は技術者としては必須のものですが、それを有効に使わせる場を与えなかったことが一番の反省点です。
  2. 作業者にしてはならない
    システム保守の第一段階としては定型作業を覚えることは重要なことだと思います。
    ただ、失敗したのは作業の正確性を上げる努力はさせましたが、その作業の目的を意識させることと、作業の効率化の意識が希薄になってしまいました。
    従来の方法に拘ることなく、定常作業が結果として正しければ変えられるところは変えて良いということの意識付けが不足していました。
    結果として、引き継いだ作業を引き継いだとおりに淡々とやる作業者になっているところがあります。
  3. 教育責任者としての自覚不足
    結論から言えば、私自身が新人君に対して本気で取り組んでいなかったということです。
    私は上司からの指示で新人君の将来の活躍の場を想定したうえで、教育を計画して実践してきたつもりでした。やるべきとされたことはやりました。
    しかし、その新人君の本当の成長のための動き方かと言えば違ったかな と。
    ストレスまみれにならないようにとユーザとの接点を避けたのは、自分の為だったような気がします。
    本来であれば、まだ一人前でない新人君をユーザとコミュニケーションをとる機会を与え、失敗は私が責任をとるような動きをしなければならなかったと反省しています。

まとめ(現在の新人君)

現在、その新人君は入社4年目となりました。

もう新人だとは言えない経験年数となりましたが、相変わらずしゃべりは得意ではありません。

飲んでいるときは流ちょうに話せるのですが、職場・仕事での同僚やお客様との会話はたどたどしいままです。

私の教育が影響しているかなと反省しつつ、現在は社内外問わず、できるだけコミュニケーションの機会を与えています。

 

コメント