こんにちは。
マーケティングコーチの新井政弘です。

会社員であれば誰しも
人を指導、教育する立場に
なったことがあると思います。

新入だった人が
翌年の新入社員の
教育係になったり、

管理職が
部下の育成に
携わったりと

いろいろなケースが
あると思いますが

人を育てるということに
関しては同じことです。

育てると言いつつも
ありがちなパターンとして

指示を出したきり
放り出したまま何もせず、

後日結果だけを確認する
というパターンです。

そこで結果が芳しくないと

”なぜ”、”どうして”、と
相手を責めたてて
追いつめてしまいます。

これは、
人を育てている、
教育している、
とは言えません。

ではどうしたら
良いのでしょうか？

自分自身のことを
思い出してください。

教育担当である、あなた自身は

誰かから何かを教わったとき

直ぐに覚えられたでしょうか？
理解できたでしょうか？

その時、
どうして欲しかったでしょうか？
どうすべきだったでしょうか？

この辺のことを
思い出してもらうと

自分が教える側に立った時に、
どうすれば良いのかが
わかると思います。

それを踏まえ、
私がお勧めするのは
以下となります。

１．目的を明確にする

何のために教えているのか、
なぜ覚える必要があるのか、

が明確になっていないと
教わる側のモチベーションが
上がりません。

意味も分からず
これを教えますと言われても

覚える側もいまいち
ピンとこない筈です。

いきなり個別に
詳細な内容を教えるよりも

先ずは全体を説明してから
徐々に細かな部分に
焦点を当てる方が

教わる方も分かりやすい
ということと同じです。

２．小まめに確認する

教えたから後はよろしく、

ではなくて、

疑問点の有無や
進捗の確認等

定期的に確認することを
取り決めます。

分からないことは聞きに来て、
と言いがちですが

何が分からないかが
分からないから
聞きに行けない、

とか、
それほど親しい間柄でない場合、
聞きに行きづらい

という形になる恐れがあります。

それを避けるためにも

定期的に確認できる場を設けたり、
聞きにいったりと、

教える側が自ら積極的に
状況を確認する姿勢が
必要になります。

そうすれば、

教え方が良いのか悪いのか、

教える内容が十分なのか
そうでないのかを

知ることができ、

教える側にとっても
とても大きなものが
得られます。

以上、
上記２つのポイントを意識することで

今までとは違う成果が
明確に表れることでしょう。

こんにちは。
マーケティングコーチの新井政弘です。

業務系のシステム開発に従事しているＳＥ、
システムエンジニアの多くが所属している会社は

受託開発をメインとしている会社が
とても多いと思います。

受託開発をやりつつも、
自ら新システムの新規導入を提案でき、
なお且つ導入（開発）プロジェクトを立ち上げる
だけのリソースを持った会社ならばいいですが、

そうでない大部分の会社に所属している場合、

人月いくらで様々なプロジェクトに
”売られる”　ことになると思います。

いわゆる、”派遣”　だったり、
”業務委託”　だったり、

また、”自分一人だけ”　だったり、
”複数人でチームとして”　だったりと、

自社以外の場所でいろいろな人と一緒に
仕事をすることになります。

かつては、この現場一筋ＸＸ年、みたいな
派遣先に完全に入り込んで
プロパー社員と同じチームで
役割を分担して働く、

という形も多々ありましたが、
今はコンプライアンス上、
難しいんですかね。

作業場所からしても、
会社別に明確に分けられてしまうように
なってしまいました。

私自身の経験をお話しますと、
新卒入社の１カ月後には、
某総合電機メーカーの工場に
派遣されてました。

そこでは、システム部門に
同じ会社で自分の上司に当たる人が
既に何年も派遣されていて

その人の下につくことで
プログラミングからシステム設計、
ユーザーサポートまで

システム設計のいろはを学ぶことが
できました。

この時の経験があるから
いまだにこの世界で働けるのではないかと
感じています。

楽しくも厳しかった経験でした。

翻って、今はどうなのか？

残念ながら、少人数で短期間の
案件が多くなっているみたいです。

受託開発の世界は、ゼネコンよろしく
２次請け、３次請け、当たり前の
多重下請けが当然の世界ですので

自分の会社がその階層の
どの部分にいるのか？

がとても重要となってきます。

階層の下の方にいる場合、
その会社はただの人材派遣会社に
なっていませんか？

同じような仕事に
人月いくらで派遣されるだけ
ではないですか？

もしそうなら、仕事を通じての
スキルアップやステップアップは
難しいかもしれません。

違うことをやりたい、
新しいことを学びたい、
と思っても、

いざ面接やスキルシートの段階で
はねられてしまう可能性が高いと思います。

では、どうしたらいいか？

転職？

転職もいいかもしれません。

プログラマからシステムエンジニア（ＳＥ）へ、
ＳＥからコンサルタントへ、など

やりたいことが明確で
今の会社ではそれが無理な場合は

それが実現できそうな会社へ
転職することもありです。

また、技術者からマネージャーへ
転身を図りたい場合も同様です。

ここで言うマネージャーとは
管理職という意味ではなく、
複数のメンバーを管理して
チームとして結果を出す、

という意味でのマネージャーです。

この場合も、
今の会社でそれができるのかが
重要となってきますので

無理だと判断した場合は
転職を考えるのもいいと思います。

より階層が上位の会社であれば
チームとして仕事をする機会も
増えるでしょうし、

自分の希望も叶う可能性も高くなるでしょう。

自分の会社がある程度の規模があり、
そこそこ階層上位に位置している場合は、

自社内で希望の職種に転換できる可能性が
高いと思います。

そういう場合は、積極的に自分の希望を
アピールすることが重要です。

今時は定期的に上司と面談する機会も
多いと思いますので、それを大いに
利用しましょう。

いつまでも今までと同じ仕事だけを
やり続けるだけで給料が上がる時代では
無くなってきました。

いかにスキルアップ、ステップアップを
”自ら”行えるかが重要となっています。

多くの会社で導入されている
目標管理制度に直結しますので
本気で真剣に考えましょう。

技術者をある程度やっていると
自然とマネージメントも求められる
ようになると思いますが

ある日突然、今日からあなたは
マネージャーです。

と、言われても
多くの人は困ると思います。

そうなったときに困らないよう
常日頃から、マネージメントに関して
知識を得る習慣をつけましょう。

特にベテランと言われる、
もう中堅と呼ばれなくなった人は
必須の知識となりますので

危機感を持って習得に臨んでください。

年取っても技術者でいられることは
非常にハードルが高いものですから。

自分は先々何をやりたのか
自問することも必要です。

技術者であり続けたい人は
どうすればそうできるのか
見つける必要があります。

これは、マネージメントを学ぶより
難しいかもしれません。

どちらを選ぶのか真剣に考える時期が
もう来ているかもしれませんよ。

それでは。