中小企業情シス稼業

2社連続で中小企業ひとり情シスやっています。 同じ境遇の方のお役に立てればと思います。

広告

2018年04月

残業せず定時で帰る8つのコツ

young-man-runaway-on-urban-street_925x

働き方改革とか言ってますが、結局個人次第ですな~

社畜、ドMだと無理!(笑)
そういう人はきっとその自覚もないでしょうけど。

定時になったらさっさと帰りたい!という強い意思をお持ちの方は以下をどうぞ。

1.いいタイミングで立つ

机片付けてかばんも持って、もう帰る気まんまんなのになかなか帰らない人がいますが、全く理解不能。

PCシャットダウンしたら、即「お疲れした!」でしょ。
タイミングが大事なんですよ。

早く帰ることを快く思わない人がいる場合は、その人が離席中、電話中を狙うと立ちやすいかも。

今日1時間2時間残業したところで、結果に差はないですよ。既に疲れ切っているし。
明日やればいいんです。

2.空気を読まない

皆さん気を遣いすぎなんですよ。余計な気を。

これまでの経験からすると、
早く帰ろうが残業しようが、同僚からの評判は何も変わらないんですよ。
合わないやつとは何やっても合わないし。


上司はその人の思想による。
昭和思想だと・・・

関連記事:
昭和思想世代の「祭り」感覚

でもそんなに差もつかない。そもそも情シスの評価低いしw

そんな上司の下でゴマをするより、さっさと帰って勉強でもして、脱出する力をためておいたほうが良くないですか?

今日早く帰っても、明日には誰も何も覚えてないよ。
皆自分のことしか考えてないから。

3.用事に思いを致す

家に帰れば、子どもを風呂に入れるとか重要な任務が待っているはず。
待ってる子どもの顔をありありと思い浮かべれば、
仕事も無いのに、ダラダラ付き合い残業してる場合じゃないでしょ。

死ぬ前に「もっと家族と過ごせば良かった」なんて後悔したくないのですよ。


独身だったら、さっさと会社を出て勉強や読書をするとか。
会社はいざというとき何も助けてくれないから、これらも
大事な用事ですよ。

前の会社の上司(専務)には、「早く帰って何やってんの?」と酔った勢いで言われたけど、家庭を顧みず、勉強もしない昭和思想の人には、想像もつかないんだろうな。
「勉強してます」なんて言わずに、苦笑いでいなしたよ。そんな大事なことを教えるのもったいなくて。

関連記事:

4.健康に思いを致す

健康が一番大事に決まってるじゃん!
もしひとり情シスだったらなかなか休めないでしょ。体調崩して休むと、仕事は一切手付かずのまま放置されて、休み明けが怖い怖い。

このあたり絶対に上は気にしてくれないよ。気にしてたら、ひとり情シスになんてしないもの。

上が気にしてくれない以上、体調を維持するのもひとり情シスの大事な仕事だよ。プロとして。
明日も朝からきちんと来ればいい。


今の日本社会は狂っているので、自分に優しくしないと壊れます。
今後は長く働かなきゃいけないし。若いうちに体壊してる場合じゃない!

健康を維持して、昭和思想世代がいなくなるのを待ちましょう(笑)

関連記事:
歯磨き大嫌い男が、歯医者に「よく磨けている」と言われるようになった理由
インプラントは基幹システムと同じ

5.トラブって残業した時の周りの対応を思い出す

ひとり情シスがハマっている時を思い返してみ。

周りが手伝ってくれたことがある?

皆いそいそと平気な顔して帰っていったでしょ。
割り切りも必要。大人なんだから。

関連記事:

6.周りに「早く帰る人」という印象を刷り込む

まずとにかく早く帰ること。ちょっと逆説的だが。

「あの人は早く帰る人だ」と思わせたら勝ち。
というかほとんどこれがすべて。

これまで残業三昧だった人にとっては、一朝一夕にはイメージ定着は難しいかもしれない。
時間をかけてやるしかない。異動や転職したタイミングだとやりやすいかもね。

イメージが定着すると、面白いことに、
 「定時間際にすいません」
 「珍しくまだいたの(嫌味ではなく)」
と周りが勝手に言ってくる。

前社で辞めた(=逃げた)上司なんかは、定時後なのに、
 「早くやってね」
とか言われてたなぁ。

俺がその後を継いだので同じ会社での話ですよ。
同じ環境なのに何故こうも周りの反応が違うのか。不思議だ。

7.周りに「仕事を速くやる人」という印象を刷り込む

仕事もしないでただ「早く帰る人」だとサボっているだけですよ~w

「早く帰る人」と同時に「仕事を速くやる人」というイメージもセットで刷り込む必要がある。
「あの人に頼むと "いつも" 最速でやってくれる」と思わせるのだ。

「いつも」というのが大事だよ。きまぐれではダメ。
サクッとやって、サクッと帰る、これ最強。



普段スピードという価値で周りに報いていると、早く帰りやすくなるのですよ。

8.必要な時は残業を厭わない

やるときはやるというイメージも大事。

定時間際にトラブルが起きた場合など、必要な残業は厭わず、淡々とやる。
人間として当たり前だが。

普段早く帰っているからこそ、残業が必要になった時に、集中力が発揮されるのですよ。
普段からダラダラ残業していたら、いざと言うときに集中できましぇーん。



メリハリをつけて仕事する人なんだ、というイメージづけができていると、
普段は定時後すぐに、席を立ちやすくなるのです。

立ってしまえば勝ち。後は脱兎のごとく・・・

皆で早く帰りましょうよ~
皆で帰れば怖くないですよ~
無理して体壊しても、会社やお上は何もしてくれないですよ~

関連記事:

ユーザ受け入れテスト/検収テスト(UAT:User Acceptance Test)を成功させるための7つのポイント

business-woman-shakes-hand_925x

まだまだ基幹システムなどを、ウォーターフォールモデルで開発するケースは多いでしょう。
その場合、UAT(受け入れテスト)はプロジェクト成功のカギを握る重要ポイントです。
事前の周到な準備が必須です。


でも、なかなか現場は動いてくれません。
「システム関係は全部情シスの仕事でしょ」というスタンスに立ち、当事者意識がないことが多いです。
「いいえ。テストは現場の仕事です。」と、言っても分かってくれません。
経営者も理解してくれません。

この不利な状況で、少しでも成功に近づけるためのポイントをまとめてみたいと思います。

1.テストにコミットするよう、現場に早くから周知する

面倒くさい内容なので、ついつい後手になりがちですが、遅れて良いことは何もありません

現場に「自分たちがやるべき作業」と早々に認識させます。早くから言っておけば、抵抗も少ないでしょう。

キックオフミーティングの場で、「テストシナリオ作成・テスト実施は各チームの責任です」と宣言しておくのが良いです。

聞く耳持たない場合は、プロジェクトオーナー(役員)から言ってもらうのも良いでしょう。

2.テストシナリオは必ず各現場チーム主体で考えさせる

テストシナリオは必ず各現場チームで考えなければいけません。

「システム関連なんだから情シスが作るべき」ということを言う人もいますが、情シスでは現場業務の細かいところまではわかりません。仮にテストシナリオを作ったとしても必ず抜け・漏れが発生し、テストをやる意味がなくなります。
量的にも、全部署のテストシナリオを情シスが作るのには無理があります。

まあこれも現場・経営者にはなかなか理解されませんが・・・


ではどうするか・・・

さすがに全チームのやる気がないことは少ないはずです。(もし全チームのやる気がないなら、プロジェクトを止めるよう、プロジェクトオーナーに相談すべきです)

まずはやる気のあるチームのテスト作成を手厚くサポートし、どんどん作業を進めさせます。
打ち合わせの場で先行しているチームの進捗を見せつけ、
「やらないならその部門が困るだけです」
やる気がないチームにプレッシャーを掛ければ焦りが出てくるはずです。


いきなり全チームの足並みを揃えることを目指さなくても良いのです。
そのためにも、上記「1.現場に早くから周知する」で時間を稼いでおくことが重要となります。
進捗の遅いチームに追い上げる時間を与えるのです。「時間が無い」と逃げる理由を与えないようにします。

3.テストシナリオは、業務的な視点で作る

テストシナリオは、画面の操作中心ではなく、業務の視点で作ります。

販売管理システムなら、オーソドックスな受注業務から、受注キャンセルや返品など、業務上ありうるパターンを考えます。

頻度の高い業務からイレギュラーな処理を考えると、仮に漏れがあってもダメージが少なくなります。

最初は作るのが大変かもしれませんが、一歩踏み出すとどんどん作業が進みます。
面倒くさがっている現場チームには「まず着手してみてください」と伝えると良いと思います。



挙げた業務ごとに具体的なテストシナリオを考えるのですが、その際は受注日や得意先コード、商品コードなどの入力値も予め記入しておきます。

例えば販売管理システムなら、受注→出荷→売上と整合性が取れていないといけないので、それを追う際には具体的なコード類が記載されているほうが良いのです。
業務内容だけの記載だと「さっき受注で何て打ったっけ?」となり、テストの精度が下がることになります。

予めコードなどをテストシナリオに記載しておくと、テスト作業自体に集中できるのです。


また明細部が空白状態で伝票登録するなど、ユーザは思わぬ操作をします。その辺りもテストに盛り込んでおくよう周知しておきます。

そうそう、情シス業務のテスト作成も忘れずに。
これは自分でやるしかないので・・・

4.テストシナリオ作成の進捗状況を上と共有する

テストシナリオの作成状況は、定期的に全体打ち合わせでチェックし、遅れているチームにプレッシャーをかけます。

それでもやらないチームは、上司や役員に報告しておきましょう。後でトラブルだらけになった時に、情シスのせいにされないためです。

やらないチームは、後で痛い目に遭うだけです。「所詮は他人事」というくらいの気持ちでいましょう。実際他人事ですしw

5.出来上がったテストシナリオを納品前にベンダーに渡す

テストシナリオが出来上がったらベンダーに渡し、納品前にテストしておいてもらいます。

先にテスト内容を渡すのは邪道なのかもしれませんが、テストの目的はバグを出すことではないのです。予めバグを取っておけるならそれで良しと考えます。


事前にカンニングさせているのに、それでもバグが出ます。それも事前にカンニングしたテストの範囲内でですよ。
ベンダーさん、それは非常に恥ずかしいことなんですよ・・・・・・・・・・

6.テスト実施は淡々と行う

テスト実施は、準備したシナリオに沿って淡々とやるのみです。
もちろん各部門で実施してもらいます。情シス業務部分のテストも忘れずに。

テストフェーズに入ると、現場では伝票類の二重入力作業も同時並行で行う場合も出てきます。
テストシナリオがきちんとできていて、テストがスムーズに実施できることがプロジェクト成功の前提になります。


逆に言えば、テストシナリオの出来が不十分だと、ここで非常に苦しい思いをすることになります。
それか形だけのスカスカのテストとなり、本稼動でバグ・課題が噴出し、しにます。

7.テストで出た根本的な課題は仕様変更と解釈する

テストをしているとさまざまな課題が出てきます。
各チームから上がってくる課題は、すべて記録しておきます。


上がってきた課題はバグなのか、仕様変更なのか。ベンダーともめる永遠のテーマです。

これまでのフェーズで、こちら(現場チームと情シス)がきちんと作業していれば、基本的に細かい不具合はバグと認定され、ベンダーもすぐに修正するはずです。


現場からの「使い物にならない!」と言った根本的なレベルの問題は、その言葉を鵜呑みにすることはできないでしょう。

要件定義や仕様策定の際にきちんと検討されていなかったためと考えられるからです。そもそも議題に挙げていなかったり、または詳細まで詰めて考えていなかったり。

遅くともテストシナリオ作成時に気づけば、ベンダーはまだ開発中ですので、交渉の余地はあったかもしれませんが。どちらにせよ手遅れなのです。


この件に限っては、珍しく(笑)ベンダー側に立ちます。

プログラム修正するにも予算はないですし、慌てて修正することで、却って別のトラブルを誘発する可能性があるからです。

本当にバグの場合、たいていベンダーはすんなり修正に応じます。(当たり前ですよね、テスト期間なんですから)
現場ユーザが「バグだバグだ」と騒ぐということは、ベンダーがそれを修正することに納得いっていないということです。つまりバグではなく、仕様変更だと考えているということです。
そして恐らくベンダーのその認識のほうが正しいです。


情シスとしては、ひとまず「本稼動後に考えましょう」と現場をなだめ、時間を稼ぎます。
(ベンダーにゴリ押しという昔ながらの手もありますが、今後を考えるとあまり使いたくないところです)

そのまま運用でカバーできるなら、本稼動後もそのままにします。
問題となり続けているなら、プログラム修正予算を確保し、実装します。


予算確保の際は、もちろんそのいきさつも経営層に説明する必要がありますので、きちんと記録しておきましょう。大金を使ったばかりなので、そう簡単に追加投資に許可は下りないでしょうから。


運用で何とかできないほど深刻な状況の場合は、本稼動の延期などをプロジェクトオーナーに相談するしかありません。
こんな状況になったとしたら「テスト以前のフェーズで何をやっていたんだ?」ということです。


ベンダーは所詮外部の人です。
こちらから積極的に議題に挙げていかないと、最後に足元をすくわれます。
それはすなわちベンダーのことは信用できず、諦めているということなのですがw

関連記事:


要件定義などでグレーゾーンを残しておいて、こちらに良いことは何もありません。
その曖昧さはすべて、QCDのどれかの形をとって、こちらに押し付けられると考えてよいでしょう。

そしてそれが露見するのが、テストフェーズなのです。



結局、テストフェーズでは、各現場グループがコミットするしかないんです。
なだめたり、脅したり、あの手この手で現場に動いてもらうしか成功の道はありません。

情シスのお願いを聞いてくれるかどうかは、プロジェクト以前の普段の信頼関係が重要になってきます。
現場からの依頼に迅速に対応したりして、普段から恩を売っておく必要があるのです。

関連記事:
中小企業情シスに向いていない人にありがちな5つの特徴
情シス必須ノウハウ!タスク管理方法
情シスでわかりやすく効率化するにはプログラミングしかない!
Accessは情シスの効率化に最適

プロジェクト開始時に周知すべき、打ち合わせでの9つのグランドルール

woman-in-glasses-at-meeting_925x

適当に集まって、適当に打ち合わせをしているだけでは、絶対に話はまとまりません。
特に具体的な成果が求められるプロジェクトでは、打ち合わせをする際のルールが必要です。

私が基幹システム導入の際に周知したグランドルールをご紹介します。

1.意見調整がつかない事項については、まず基本方針に立ち返って判断する

打ち合わせをしていると、利害関係がぶつかりあい、意見調整できないことが多々あります。
その場合は、基本方針に立ち返って判断します。

基本方針とは、例えば基幹システム導入の場合、

・現状業務の整理・見直し
    未利用、不要機能の削除
    機能の有効利用
    業務の質の向上

・導入コストの削減(限られた予算での更新)
    パッケージソフト標準機能の活用
    ※現行システム機能の全てが、そのままに新システムに移行されるわけではない

などがプロジェクト開始時に挙げられているはずです。

基本方針は、プロジェクトの憲法とも言えるものです。
意見が対立したときは、どちらの意見がこの基本方針に沿っているかで、判断すれば良いのです。

でも打ち合わせに集中していると、ついつい基本方針を忘れがちです。
基本方針の意識づけを強くするためにも、グランドルールで明文化しておくべきです。

2.どうしても意見調整がつかない場合は、プロジェクトオーナーによる全社的視点での判断を仰ぐ

プロジェクトの憲法ともいえる基本方針があるとは言え、それでも意見調整ができない場合があります。

ただでさえ社内での立場が弱い情シスは、現場に押し切られる恐れがあります。
情シス(=会社)が不利になる恐れを感じたら、プロジェクトオーナー(役員)に頼ります。
プロジェクトオーナーは、情シスの直系上司に当たることが多いですので話しやすいでしょう。
もちろん情シスが持って行きたい方向に誘導するのです。

キックオフミーティングと打ち上げの飲み会しか出席しない役員も、こういうときは利用できます。
頼られたほうも「仕方ねえなあ・・・」という感じで、嫌な気分にはならないでしょう。


打ち合わせにおいて、全てを論理的に白黒つけるのは、なかなか難しいところがあります。
情シスとしては、こういう泥臭いオプションも確保しておくべきです。

3.時間厳守、話は簡潔・明瞭に

プロジェクトに限らず、打ち合わせは時間厳守です。当たり前のことです。

私がプロジェクトリーダーの時は、時間が来たら部屋の鍵まではかけませんが、
ドアを閉めて、さっさと打ち合わせを開始します。

絶対に遅れた人を待ちません。
遅れて入ってきても、話を戻すことなくそのまま進めます。

当たり前のことです。
時間通りに来てくれた他のメンバーの時間を無駄にすることはできません。

もちろん打ち合わせが終わる時間も厳守です。
なるべく早めに終わるようにします。


それを続けていると、大抵遅刻が減ってきます。
早く集まって、早く打ち合わせを終えようとしている私の意図が伝わるのだと思います。


打ち合わせ時間をオーバーしないためには、話を簡潔・明瞭にする必要もあります。

愚痴に近い話をダラダラとされては、終わるものも終わらなくなります。
アジェンダに目を通してこない、宿題をやってこないでグダグダというのは問題外です。


現場の担当者レベルだと、普段皆の前で話す機会が少なく、うまく話せないこともあります。
分かりやすく話すこともメンバーの義務だということを明言しておく必要があります。

4.建設的な意見を出す

自分の仕事だけが大変だとばかりに、愚痴だけを言う人がいます。
こういう人は愚痴を言うのが、自分の仕事だと思っているのです。大人なのに困ったものです。

愚痴だけではなく、改善のアイデアを出し、さらに実行するまでが正社員の役割です。

関連記事:


改善するアイデアがないなら不平・不満を言うな、ということをメンバーに浸透させます。

5.プランのない意見は進行の妨げになるので排除する

いくら前向きでも、実現不可能とも言えるプランを話されても話が進まなくなります。
そもそもプランとは、QCD(Quality:品質、Cost:価格、Delivery:納期)を漏れなく満たしている必要があります。

実現不可能なプランは、QばかりでCとDが非現実的になっているはずです。

CとDの制約がある中で行うのがプロジェクトです。
ブレストではないので、極端な意見を尊重する必要はありません。


プロジェクト進行を妨げるような意見は切り捨てても良いのです。

6.あるべき論は進行の妨げになるので排除する

あるべき論は、議論の前提をひっくり返そうとするような意見、という形で現れることが多いです。
上のプランのない意見とも似ています。

あるべき論も正論であるだけに議論が進まなくなります。

正論だけ言い放って、自己満足に浸っている人には、
「別途、議論の場を ”自分で” 設けて下さい」
「このプロジェクト発足前に話し合うべき内容です」
といなします。

「お客さん」としてプロジェクトに参加しているから、のんきなことを言えるのです。
こういう人には「ご自分でどうぞ」と水を向ければ、「いえいえそれは・・・」とトーンが下がります。所詮その程度の覚悟なのです。


プロジェクト中は清濁併せ呑み、とにかくプロジェクトを少しでも前進させることに、意識を集中する必要があります。
それに協力しない意見に耳を貸さなくても良いです。

7.意見は皆がいる打ち合わせの場で言う

気が弱いんですかね、慎ましいんですかね。
会議が終わってから情シスに個人的に「さっきのは実は・・・」とささやいてくるずるい人が本当に多いです。
「で、何が言いたいの?」と思います。こういう人は情シスに代弁させたいのです。子どもか?(笑)

こんな人に関わると、情シスが厄介ごとを抱え込まされることになるので、予防線を張っておきます。


それでも「相談」と称し、絡んでくる人には、
「メーリングリストに提案を投げてください」
「次回打ち合わせの議題に入れますので、そこで説明してください」
などと返し、公の場に引きずり出すようにします。

8.ベンダーに対して「強気に言う」=「要望を言う」ではない

ベンダーに現場ユーザが、
「○○できないと困るんですけど!」と詰め寄る場面、ITのプロジェクトにありがちです。

本人は強気に言っているつもりですが、結局要望を言っているだけですから(笑)
「言ったった」とドヤ顔する人もいますが、全て開発コストに跳ね返るだけです。

情シスとしては、「あーぁ、言っちゃったよ・・・」というところですね。
QCD(Quality:品質、Cost:価格、Delivery:納期)のうち、CかDにダメージを与えるからです。プロジェクトの妨害行為とも言えます。


グレーゾーンをグレーのままで放置せず、先回りしてベンダーにぶつけ、
こちらに有利な条件を勝ち取ることが強気と言うことです。

事前に勘違いメンバーに釘を刺しておくことで、コスト増大・納期オーバーを防ぎます。

9.打ち合わせ欠席時は他の人に委任する

打ち合わせ欠席時は
「会議に出られませんので○○さんに委任します、決定には従います」
とプロジェクトリーダーに伝えるようルール化します。


情シスが苦労してスケジュール調整しているのに
「○月○日は予定があります」とだけ言い放つ人が多いです。

何が言いたいんだろう、と思います。

飲み会の日程調整でもいますよね。
幹事の苦労を尻目に「○月○日はダメ、×月×日も予定あり」とだけ言い放つ人が。
そういう人に限って来ても来なくてもいい人だったりします(笑)

「私がNGの日でも構わずやってください。また次の機会に出席します。楽しんできてください」
と先に幹事に伝えるのが大人の対応でしょう。


プロジェクトでも同じです。

はっきり言わせてもらうと、情シスに委任して欲しいんですよ。
大人なんだからそれをこちらに言わせるな、というところです。

欠席するという事は、事前に予定が分かっている、他の大事な用事があるんですよね。
こっちのプロジェクトの優先順位は低いんですよね。

だったらプロジェクト(=情シス)の決定事項に異議を唱える資格はないはずなんですよね。



厳しいようですが、これらを守ってももらわないと、プロジェクトがまともに進みません。
反感を買うのを覚悟で宣言してしまいましょう。

受け入れられないならプロジェクトリーダーを降りてもいいと思います。
どうせそんなプロジェクトは破綻してしまうでしょうから。


上記9つのルールには、内容的に重複する部分もあるのですが、細かく分類することで、「自分は正しいことを言っている」とメンバーが勘違いするのを防ぐ狙いがあります。


要するにプロジェクトメンバーに伝えたいのは、
「お客さん感覚ではなく、当事者意識を持ってプロジェクトに参加しろ」
ということです。

自分がプロジェクトを仕切る側に立ったら、言われなくても守るであろうルールばかりです。

なんと当事者意識に欠けるメンバーの多いことか・・・
同じ会社なんですから、一蓮托生だと思うんですけどね。


これらのルールについては、プロジェクトのキックオフ以降、事あるごとにしつこく確認したほうが良いです。
メンバーにとって、耳の痛い内容なので、すぐになあなあになってしまうからです。


普段の仕事や会議でも、常に意識しておくべき大事なことだと思うのですが、何故かITの時だけ明確に意識しなくてはいけないんですよね。

関連記事:
仕様策定1/3-キックオフミーティング

新人にオススメする質問のしかた

fresh-tomato-market_925x

で?

中学2年のとき転校した。

初めて登校した朝、職員室に1人でいた先生に
「今日から転校してきた○○ですけど・・・」
と言ったら、
「で?」
と返された。

”なんだコイツ?”と子どもながらに思ったが、今ならその意味がわかる。


意思表明をきちんとしなければいけなかった。
「担任の○○先生はいらっしゃいますか」
と聞かなければいけなかった。

先生は、こちらを大人として扱ってくれたのだ。
英語と美術両方を教える先生で、個性的だったというのもあるが。


そのときはちょうど担任の先生が来て、事なきを得たが、そのまま「で?」を繰り返されたらきつかった・・・

でも、そこで徹底的に叩きのめされていたら、いろいろなことに気づくことができ、
私はもっと早く成長できたかもしれない。惜しいことをした。

トラブルに積極的に関わり質問する

会社に新人が入ってくる季節になると、上記のことを思い出す。


新人は「何でも質問してもいいよ」と先輩に言われるだろう。

「質問はありません」というとやる気が無いように思われるなぁ、と思うだろうし。
(実際はそんなに質問ばかり浮かばないよな、と先輩は思っていますw)

質問するネタを考えるほうも大変だと思う。
研修のとき、無理に質問する必要はないと思う。


それよりも新人は、トラブルに積極的に関わっていくべきだと思う。
そうすれば嫌でも質問することになるだろう。


ずっと質問攻めにしろと言っているのではない。
まずは先輩の横にくっついて見てるだけでよい。
で、疑問が浮かんだら邪魔をしないタイミングで質問をするのだ。

トラブルのときは先輩も必死だから、別視点からのアイデアはありがたい。
新人はトラブルに積極的に関わっていくことで、間違いなく早く成長できる。


ただし質問のしかたがある。

YesかNoかで答えられるように聞く

例えば、
「PCがネットにつながらないんですけど・・・」
ではなく、
「PCがネットにつながらないので、OSを再起動してみたいのですがよろしいですか」
だ。(これはあくまでも例だ。こんなことは普通質問しなくてもいいが)


要は、YesかNoかで答えられる形を意識して質問すべきなのだ。

「PCがネットにつながらないんですけど・・・」は質問にすらなっていない。
厳しい言い方をすると、先輩に考えさせて時間を奪っているとも言える。


YesかNoかで答えられる形ということは、自分の考えを先輩にぶつけないといけない。
これが成長を促す。

何を聞いてよいか全くわからない、という場合もあると思うが、それでもひねり出す。
的外れでもいい。先輩に呆れられてもいい。それこそが新人の特権なのだ。


もし間違っていたりしたら、
「そのPC特別なサービスが動いてて、落とす手順があるから、やり方を教えるよ」
「ルータが落ちているかもしれないから確認するよ」
などと先輩は指示・補足してくれるはずだ。


そうすると、
「教えてもらった手順を自分なりにマニュアルにまとめてみていいですか?」
「ルータってどこに置いてあるんですか?」
という具合に次の質問ができるだろう。

これが教わるということだ。

ハマって欲しいわけではない

「自分は若い頃ハマったから、新人もハマって経験すべきだ」などとは、私は思っていない。
(たまにそういう主義の人も居るが・・・)


ハマるとトラウマになるからだ。そうすると新しいことに挑戦できなくなってしまう。
ハマるとわかっている道は避けて通って欲しいと思う。


ただ、自分の頭で考えて欲しいのだ。

「○○なんですけど」は思考停止しているのだ。
思考停止は癖になる。

新しい困難が立ちはだかるたびに、壁の前に立ち尽くしてしまう。
助けが無い状況になったとき、何も考えらなくなる。

それが怖いのだ。

先輩をうまく利用してやったぜ

「○○なんですけど・・・」をずっと繰り返し、先輩から「あぁそれは××だよ」とすぐ答えをもらう。
さらに「俺がやるよ」と先輩がそのままやってしまうこともある。
こうやって先輩にうまいことやらせたつもりになっている者もたまにいる。

ラクをするとサボるは違う。

ラクをするとは自分の中で仕事を効率化することである。
サボるとは、社内の他の人に仕事を押し付けることである。会社全体の仕事量としては変わっていない。

この新人はサボっている、と言える。

関連記事:


もちろん先輩は全てお見通しだ。
「俺がやるよ」と言われてしまうのは、その前に新人のほうから「やります」と言わないからだ。
ある意味諦められているのだ。

こんな姿勢では絶対に成長できない。
将来困るのは新人のほうだ。

先輩の利用のしかたを間違っているのだ。



もちろん先輩もすべて知っているわけではない。
これからは新人のアイデアと先輩の経験を融合させる時代なのだろう。

だが基礎的なところは先輩から吸収すべきだろう。
特に情シスは経験がものを言う職種だ。


先輩にやらせて横から見てればわかるって?
広告
広告
プロフィール
40過ぎて何とか結婚し、2015年末に子どもができた、左利き初老オヤジです。日本史を再勉強中。株、囲碁、鼻炎、眼振少々。中小企業ハッタリテキトー情シス(社内SE)。Access/ExcelVBAしか武器(?)はなし。情試はPM/SM/SA/NW。 ベンダーSEを数年やり、その後情シスに転職しました。 情シスでは中小企業ばかり3社見てきました。現職と前職ではひとり情シスです。 会社では「いないとヤバいが、評価はしない」という扱いです。 ノウハウを伝える相手もいないので、せっかくなので自分なりのコツを公開したいと思います。 同じような環境で苦労されている方のお役に立てればと思います。 「情シスの格を上げる」が目標です。 Twitterをフォローいただくと、ブログ更新時に通知されます。http://twitter.com/suiton_everyday よろしくお願いいたします。
お問い合わせ
お問い合わせはこちら
プライバシーポリシー
・当サイトに掲載されている広告について
当サイトでは、第三者配信の広告サービス(Googleアドセンス)を利用しています。
このような広告配信事業者は、ユーザーの興味に応じた商品やサービスの広告を表示するため、当サイトや他サイトへのアクセスに関する情報 『Cookie』(氏名、住所、メール アドレス、電話番号は含まれません) を使用することがあります。
またGoogleアドセンスに関して、このプロセスの詳細やこのような情報が広告配信事業者に使用されないようにする方法については、こちらをクリックしてください。

・当サイトが使用しているアクセス解析ツールについて
当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。
このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。
このトラフィックデータは匿名で収集されており、個人を特定するものではありません。
この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。
この規約に関して、詳しくはこちら、またはこちらをクリックしてください。