お待たせしました。ブログ再開します!

[`evernote` not found]
GREE にシェア
LINEで送る

お久しぶりです。

マーケテイングコーチの新井です。

ながらく放置状態だったこのブログですがこのたび再開する運びとなりました。

今まで業務多忙につきコーチとしての活動は開店休業の状態でしたが、
ようやく、「本当に自分のやりたいことで生きていく」 ということに
決心がつきました。

やりたくないことを生活のために我慢して続けている人、
本当にやりたいことができなくて悩んでいる人、
自分は何がやりたいのか、何ができるのかわからない人、

などなど多くの人に、
もっと自由にやりたいことをしてもいいんだ
我慢しなくてもいいんだ

ということをお伝えして、

何も我慢せず、場所も時間も選ばず、自分のやりたいことで
納得いく収入を得るための方法をお伝えしたいと思います。

そのためのセミナー/説明会も定期的に開催しますので
自分を変えたい、環境を変えたい、と思う方は参加してください。

それでは、今しばらくお待ちください。

質問の仕方、それでいいですか?

[`evernote` not found]
GREE にシェア
LINEで送る

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

人の上に立つ立場になった場合、
心がけて欲しいことがあります。

それは、

質問するときに、

”なぜ?、なんで?”というフレーズを
極力使わない。

ということです。

これは、これらのフレーズを
目上の人から言われた場合、

相手に誤った印象を
与えてしまう恐れがあるからです。

例えば、

進捗が遅れている人に対して、
状況確認もせずにいきなり、

”なぜ”遅れているの?
”なんで”遅れているの?

という聞き方をすると、

聞かれた側は、

遅れている原因を
聞かれているだけなのに

なぜか怒られているような
感覚になってしまいます。

そうすると、

遅れている原因が別にある場合、

なぜ自分が責められるのか
という感覚となって、

本来の遅れている原因が
正しく報告されなくなる
恐れがあります。

また、自分に原因がある場合も

責めれているという感覚から、

言い訳だけに終始してしまう
かもしれません。

そうなると、
遅れている根本原因にまで
たどり着けず、

効果的な解決策が打てない
ということにも成り兼ねません。

何か問題が起きた時も同様です。

問題発生との報告を受けた時に

”なぜ” とか、”なんで”
といった聞き方をしてしまうと

報告者にとっては、

”お前が何かやったのか”的な
いきなり怒られているような
感覚になってしまいます。

そうなると報告者は

委縮してしまうか
腹を立ててしまうかの

どちらかになる可能性が高く

聞き出せるはずの情報も
聞き出せないという

悪循環に嵌ってしまう
可能性があります。

そうならないためにも

まず一言目は

”なぜ”、”なんで”、ではなくて

何が原因なのか、
何があったのか、

という聞き方で

あなたが原因ではない、
あなたが悪いのではない、

という明確なスタンスを
最初に相手に与えましょう。

そうすれば、

相手も安心して
本当に言いたいことが話せ、

聞きたいことが聞けるように
なるでしょう。

特に意識せずに発した質問であっても

受け取り方によっては、
詰問になってしまうということです。

感情に変化を起こさずに
事象に集中できれば

必ず建設的な言葉を
受け取ることが
できると確信しています。

このことを常に意識して
質問するようにしてください。

SEにとってOJTもやり方があります

[`evernote` not found]
GREE にシェア
LINEで送る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.目的を明確にする

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

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

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

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

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

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

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

2.小まめに確認する

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

ではなくて、

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

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

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

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

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

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

それを避けるためにも

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

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

そうすれば、

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

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

知ることができ、

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

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

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

SEやるのに資格は必要?

[`evernote` not found]
GREE にシェア
LINEで送る

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

IT系の仕事をするにあたって
資格があった方がいいか?
と言われたら、

無くてもできるけど
無いと不都合な場合も多い、

と言えます。

就職する時や転職する時など
何となく資格がないと

不利になるのではないかと
思いがちですが

資格を持っていなかったから
就職や転職で落ちた
という話はあまり聞きません。

募集要項に
”~の資格必須”とか書かれていても

他の部分でアピールできれば
問題ない場合もあります。

そうは言っても、

履歴書や経歴書に
取得資格が書ければ
気分がいいものです。

私自身、システム開発の
経験年数は長かったのですが
資格取得に熱心ではありませんでした。

ほんの数年前まで
第二種情報処理技術者、
(今でいう基本情報技術者ですね)

これしか持っていませんでした。

これも、最初に転職を意識した時に
履歴書に何も書くことが無いので

慌ててとったような気がします。

確か、20代の半ば頃だったような。

今でも、難易度が高いといわれる
資格を持っていれば

就職や転職で有利なのは
間違いないでしょう。

職歴が大したことなくても
とりあえず会ってみる
ということが有り得るかもしれません。

逆に、職歴でアピールできれば
資格は無くても
それほど不利にはならないはずです。

では、資格が無くて
不都合なときとは
どんなときかと言いますと

社内での昇格、昇進の条件に
資格取得が明記されている時や、

派遣の引合いが来たときに
有資格者のみと限定されている
場合などです。

資格とは違いますが

マネージャーになるには
TOEIC何点以上が必須とか
最近増えていますよね。

これも一種の資格と
言えるのではないでしょうか。

SAP業界でも

管理職になるための条件に
SAP認定コンサルの
取得が必須とかあります。

こうなってくると、

資格取得 = 収入UP

さらに、

資格が取れなければ
周りから置いて行かれ、

最悪、後輩に抜かれる
可能性もある。

ということで

必死にならざるを得なく
なってきます。

”自分は管理職になりたくないし、
技術で食べていきます”

と思っていても、

派遣や請負がメインの
会社だった場合、

資格が無い = 仕事が受注できない

といったケースになり兼ねません。

案件がふんだんにあって
仕事を選べる状況にあるのでしたら
問題ないのですが

そうでない場合は、
資格がないことが命取りに
なるかもしれません。

そうならないよう
日頃からの勉強が
重要になってきます。

技術の世界は
日進月歩ですので

常に学び続けることが
必須となります。

IT系の仕事を
し続けるためには

常に学び続ける姿勢と
学び続けられる環境が
重要になってきます。

自分でできることには
限界がありますので

いかに会社の協力が
得られるか、

会社を利用できるかが
とても重要です。

教育に関して
会社が利用できるのであれば
大いに利用しましょう。

フリーで活動している
エンジニアの方は

この辺りも自己責任と
なってきますので

会社員以上に厳しくなります。

どっちがいいかは
人それぞれですが

何れにしても
個人の努力は必要という点で
一致しています。

頑張りましょう。

システムエンジニアの年収は?

[`evernote` not found]
GREE にシェア
LINEで送る

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

正社員に限った話になりますが、

IT業界で働く人の年収は、
会社員であれば他の業界と
あまり変わりはありません。

業種や会社の規模によって
違いが出てきますが
それはほんの一部だと思います。

コンサルティングが中心の会社や
SNS、やゲームなど今はやりの
スマホ関連がメインの会社などは、

全体的に高給であると
言われています。

しかし、
そういった会社の場合、

労働時間も半端ないので
時間当たりの単価で比較すると

見た目ほど高給とは言えない
場合もあります。

厚生労働省のH22年調査によりますと
勤労世帯の平均所得:549万6千円
(中央値:438万円)
だそうです。

何の調査か忘れましたが
大卒30歳の平均年収は
たしか400万円台の前半
だったような気がします。

その辺を考慮してもらうと
自分の今の年収が
どんな感じなのか
判断できると思います。

今どきの会社なら、
裁量労働制でもとっていない限り
きちんと残業代がでていると
思いますので、

年収の多い少ないは
休出、残業の多寡により
かなり違いがでてきます。

コンプライアンス意識の高い会社ですと

・休日出勤をした場合は代休の取得も必要
・30時間を超える残業は申請が必要

といった形で、
昔のような仕事が終わらないなら
終わるまでやってください、

といった無理を強いる
会社は少なくなりました。

同時に、手取り給与を
増やすためにわざと残業を
するという技も
使いづらくなりました。

以上のことから、

より高い年収を期待するのであれば

規模が大きく、より元請けに近い会社に
正社員として入るのが正解だといえます。

ようするに、
身もふたもない言いかたをすれば、

だれでもが知っている会社に入れば
それなりの年収がもらえるということです。

プログラマであれ、
システムエンジニアであれ、
コンサルタントであれ、

自分の年収を上げるためには

・社内で昇進、昇格する。
・他社へ転職する

の2通りの方法が考えられます。
(とりあえず副業等は無しで)

どちらが良いかは
一概に言えませんが

何れにしても
努力と運が作用しますので

日々の仕事を疎かにしないことが
重要です。

どこでだれが見ているか
わかりませんので

毎日の仕事に全力を
投入し続けることで

他社から好条件で
誘われたり、

社内で昇進、昇格の対象に
選ばれたりと

ある日突然、
幸運が訪れるかもしれません。

その幸運を掴むために
日々の努力を惜しまない
ようにしましょう。

今や、
毎日同じ仕事をし続けるだけで
年収が上がり続ける時代ではない
ですから

自分で増やす努力をしなければ
なりません。

何をすれば良いかは
人によって様々ですが、

まずは、毎日の仕事に
全力投球しましょう。

そうすれば何かが変わるはずです。

以上が正社員の場合の
年収の上げ方になります。

それでは、正社員以外の人は
どうでしょうか。

システム開発の現場で言う
正社員以外の方というと、

契約社員かフリー(個人事業主)
の方々ですね。

また、正社員であっても
派遣をメインとしている人も
こちらに近いかもしれません。

これらの場合、

年収 = 契約金額

となりますので

契約交渉で全てが決まると言えます。

そこで単価のUPを
交渉できるようになるには

何かしらの付加価値を
付けるしか方法はありません。

今までの延長線上で
同じ仕事しかできないのであれば

良くて現状維持、
それどころか単価の引き下げも
大いにあり得ます。

それを避けるには

常に新しい知識や情報を
取り入れ続けるしかありません。

正社員であれば
そういった教育や研修を
受けられる機会もありますが

正社員以外の人たちは
全て自分自身で
何とかする必要があります。

これに時間と費用を
惜しむようであれば

収入を増やすことは
とても難しいでしょう。

全ては自分自身に
かかっています。

今の仕事を続けて
年収のアップを目指すのか。

全く違う分野へ進んで
今以上の収入を目指すのか。

全てはあなた次第です。

エンジニアもマネジメントスキルを習得すべき?

[`evernote` not found]
GREE にシェア
LINEで送る

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

受託開発が中心のソフトハウスにとって
受注案件に波があることは
常に悩みのたねです。

引合いが重なったときなど、
自社人員のみならず
協力会社やフリーの技術者たちを
かき集めることになりますが、

次の案件が決まらずに
プロジェクトが終了してしまった
ときなど、

技術者が社内で待機状態となる場合も
珍しいことではありません。

このとき、
他のプロジェクトへの応援や
社内システムのサポートなどに
参加できれば

待機人員も遊んでいることには
なりませんが、

そういったものがない場合、
何もやることがないといった
状態になりがちです。

自主的に勉強するとか
調査するとかもいいと
思いますが

待機しつつも会社に貢献している
とは言い辛いと思います。

そこで、今回私がご提案したいのは
待機人員をコーチとして
活用するという案です。

”コーチング”という言葉は
聞いたことがある人も
多いと思います。

その”コーチング”を
行う人のことを

”コーチ”、”ビジネスコーチ”、
といいます。

コーチングとは何かといいますと

”対話によって目標達成や課題解決を
図る技術である。”

と言えます。

どういうことかと言うと、

人は自分ひとりの頭で考えて
行動していると
常に同じ行動や結果になりがちです。

なぜなら、
今までの経験や知識をもとに
課題、問題を解決しようとすると

頭の中で考えることが
堂々巡りになってしまって
同じ結果になりがちです。

それを避けるためには、

今までと違う考え方を
しないといけないのですが

これは一人では非常に難しいことです。

それを質問という手法を用いて
新しい考えを気づかせることが
できるのが”コーチ”の役割です。

コーチングを行うことで
今まで一人で悩んでいたことが
解決する可能性が確実に高まります。

コーチングのスタンスは

”問題の解決策は必ずその人の中にある”

というものです。

その前提をもとに、
いかにしてその人から
考えを引き出せるか、

そして、その考えをもとに
いかに自発的な行動を
起こせるか

が目標となります。

私自身、コーチングを学び
実践したことで

メンバー自身から、悩みや問題の
解決策を引き出すことができ、

チームマネジメントを行う上で
大いに役立ちました。

よって、自社の社員が
コーチングを学び実践することで

例え待機人員であっても
他のメンバーに対して
有力なサポートとなり、

会社に貢献していることになります。

同時に、社員の生産性の向上や
マネジメントの効率化が図れ

結果的に会社全体に
さまざまなプラスの
効果を図れると確信します。

是非ともご検討ください。

ITエンジニアがやるべきマネジメントの方法とは

[`evernote` not found]
GREE にシェア
LINEで送る

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

昇格、昇進、組織変更等で
新たに部下を持つ立場になった人にとって、

部下の管理、マネジメントを行うという事は、
新たなチャレンジになると思います。

今まで自分の仕事のみを
やっていれば良かった立場から、

指導、管理する立場になるわけですから
期待と不安が入り混じっているはずです。

また、システム開発の現場では
他社の社員や、フリーの技術者の方など

様々な立場のメンバーを
取り纏める必要になることも
多いと思います。

そんなときは、
以下の2つのポイントを
心がけることで

チームマネジメントに
大きな変化が現れます。

ポイント1

*コミュニケーションを欠かさない

これは、仕事の話に限らず、
日常的にコミュニケーションをとる
ということです。

用事がある時しか話しかけない
というのではなく、

特に用が無くてもいいので
最低一日一回は会話しましょう。

自分自身の経験を思い出すと
いいかもしれません。

新入社員だったときや、
新しいチームにアサインされたとき、
などなど、

周りに知り合いがいない状況は
とても心細くて不安だったはずです。

そんな状況にいる部下に対して
上司であるあなたから
積極的に話しかけることで

早期に打ち解けることが
できると思います。

また、部下の側からの
話しかけづらい、とか

いつ話しかけていいのか
わからないという

状況を避けるという狙いもあります。

こまめにコミュニケーションを
とることで、

問題の芽を摘み取ることも
可能ですので

積極的な声掛け、話しかけを
実践してください。

とは言っても、

いきなり何を話していいのか
分からない。

という人は、

先ずは、”挨拶”から
始めてみてはいかかでしょう。

”挨拶”された人は
話しかけられたのと
同様の感覚を持つ

とのことなので

挨拶を交わす間柄になると
話しかけにくさは
大分薄まるみたいです。

コミュニケーション不足は、

・問題の誘発や、
・問題の発見を遅らせたり
・問題をこじらせたり

といいことはありませんので

先ずはこれをなくしましょう。

ポイント2

*状況を把握する

これは、部下や
配下のメンバーの作業状況を
常に把握しておくということです。

ありがちなケースとしては

各メンバーへ作業をアサインした後、
フォロー、確認をほとんどしないという
ケースがあります。

定期的(週一くらい)に進捗会議を
行っていて、そこで確認しているから
大丈夫と思っているかと思いますが、

それでは十分でない場合も多々あります。

特にスケジュール的に厳しい場合や
メンバーの数が多い場合など、

週一くらいの確認では

・効果的なフォロー
・適格な判断

ができない可能性が高くなります。

問題が起きてからの対応と
起きないようにする
こまめな確認、フォローを
比較した場合、

どちらの方が
・労力が少なくて
・周りへ与える影響が少ないか

を考えていただければ
一目瞭然となります。

そんな訳ですので、

各メンバーの作業状況をこまめに、
できれば毎日確認することを
推奨します。

メンバー全員が集まって
報告会形式でやるのも
いいと思いますが、

リーダー自ら、個別に
確認して回るというのも
いいかもしれません。

こちらの方が
各メンバーが感じる
管理されている感が
少なくなると思います。

これは、ポイント1の
日常的にコミュニケーションを
とることの一環として

行えますので
一石二鳥ですね。

問題が起きたら教えろ
との受け身の管理方法とは
真逆のやり方となりますので

慣れないうちは
大変かと思いますが

これが回りだすと
効果は大きいと思いますので
是非ともチャレンジしてみて下さい。

それでは。

エンジニアが意識すべきは技術のみではない

[`evernote` not found]
GREE にシェア
LINEで送る

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

IT系の仕事、特に
業務アプリケーション系の仕事の場合、
自社以外の場所で作業を行うケースが
非常に多くなります。

ということは多くの場合、
何らかの組織やチームに所属して
仕事をすることになるのですが

そこでの立ち振る舞いが

次の仕事を得られるか、
或いはそのプロジェクトに
最後まで残れるか否かに
大いに影響してきます。

プログラマ、システムエンジニア
(SE)、コンサルタントとして

要求された技術力があることは
当然の前提となりますが

それ以外の部分

主に人間的な部分で
評価されてしまうことは
多々あります。

デスマーチ状態のプロジェクトで
とにかく一刻も早く人が欲しい、

プログラムが書ければいい、
設計書が書ければいい、

というような場合でれば、
人間的な部分は目をつむるケースも
ありますが、

それは忙しいときの穴埋めでしかなく
次に繋がるかは疑問が残ります。

それでは、
継続的、安定的な受注に繋げるためには
どうすればよいでしょうか?

先ほど、技術者の立ち振る舞い、
特に人間的な部分が大事だと
言いました。

そこで重要になってくるのが

”コミュニケーション” です。

プログラマであれ、
システムエンジニア(SE)、
コンサルタントであれ、

コミュニケーションの部分に
難があると、

上に立つ人から
芳しくない評価を

最悪クレームを
頂戴することになります。

スキルや経歴に問題が無くても
コミュニケーションに問題あり
と烙印を押されてしまうと

次の仕事どころではなく、
早く変わりの技術者を
アサインしろとの
話になりかねません。

そのような状態は
会社としても、
技術者本人としても、

絶対に避けなければいけません。

その為に、意識して
行わなければならないポイント、

最低これだけはやっとけ、
というポイントは、

非常に古典的ではありますが

やはり、”報・連・相”に
つきると思います。

ただ黙って、黙々と
振られた作業だけを
こなしているだけでは

その他大勢の一員
でしかありません。

作業品質や納期に
全く問題が無くても

悪くはないが
積極的に高評価を
与えるほどでもない、

との評価に落ち着きがちです。

逆に、技術者側からの
アクションが少ないことで
良くない印象を与える
可能性もあります。

そこで、”報・連・相”です。

今何をやっていてどういう状況なのか?
仕事を進める上で問題はないのか?
問題がある場合、どういう状況なのか?

などなどを、
自分から積極的に発信する必要があります。

そうすることで
スケジュールの調整や
問題の早期発見につながり、

自然と技術者自身の
印象も好転していくことは
間違いありません。

とにかく、
聞かれるまで黙って
じっとしている。

という姿勢では
絶対いいことありません。

能動的、積極的に
行きましょう。

急にそんなこと言われても、、、

と仰る方々には、
私がお手伝いしますので
ご相談ください。

それでは。

エンジニア,技術者にとってキャリアプランは必須です

[`evernote` not found]
GREE にシェア
LINEで送る

システム開発の現場が
実は3Kであるとか、ブラックであるとか
最近ばれつつありますが

そういった体力勝負の現場において
開発作業の中心となるのは
やはり若手の技術者となります。

しかし、
リーダーやマネージャークラスとなりますと、
やはりそれなりに経験を積まれた方が
担当されるケースが多いです。

IT業界の受注構造は
ゼネコン同様の多重下請け構造
となっていますので

そういった上の立場にいる人は
より階層上位の会社に所属している人たち
となります。

それでは、それ以外の階層下位の
会社の年配の方々は
どこにいるのでしょう。

以前ですと、

ある程度の規模の会社であれば
四十代くらいの年齢になると
自然と現場から遠ざかって

自社内で営業支援とか管理業務とかを
担当させられるケースが
多かったような気がします。

小規模な会社や
個人事業主としてフリーの
技術者として働いている場合は、

自分自身で稼がなければ
なりませんから

自ずと技術者として
参画できるプロジェクトを
探すことになります。

しかし、リーマンショック以降、
ある程度の規模の会社であっても

自社内でのんびり管理業務を行える
ような状況ではなくなっています。

ポストの削減等により
組織構造がフラットになり、

リーダーやマネージャーに
なりにくい状況になっています。

そうなると、
四十代、五十代でも
技術者として現場に
出ざるを得ません。

その場合、
プロジェクトに参画できるか否かは
それまでの業務経歴が大きく影響します。

システムエンジニア(SE)や
コンサルタントとして、

顧客や他社のコンサルタント等と
一緒に上流工程の作業を
経験している人は

年齢に影響されることは少なく、
行先に困らないようです。

逆に上流工程の経験が少ない場合は、

年齢を重ねれば重ねるほど
新規プロジェクトへの参画へは
難しいものとなります。

そういった状況を避けるためには

長期的な計画を
技術者本人と会社の両方が持って
それに沿った形での仕事の
やり方をすべきとなります。

しかし、このやり方ができるのは
かなり恵まれた環境にいる人だけです。

自社に教育を受けられるだけの環境が無く、
費用も掛けてもらえない場合、

自ずと技術者自身が
なんとかしなければ
時間だけが経ってしまう
ことになってしまいます。

若い頃は引き合いも多く
稼働率も高かった技術者が

年を重ねるにつて
稼働率が落ちていくことは

本人にとっても
会社にとっても
辛いことであることは
間違いありません。

それを避けるためには、

繰り返しになりますが
会社も技術者本人も
先のことを見越した形での
キャリアプランを

真剣に考え、構築していく
他ありません。

私の場合は、
三十代に入ってから
真剣に考え、

マネジメントスキルを
身につけるにはどうすべきか、

マネージャーになるためには
どのような仕事をすべきかを
第一に考え、実践してきました。

転職することも
そのうちの一つでした。

今の会社にいて
5年後、10年後の
自分の姿が想像できますか?

できない場合は
どうすべきかを
考えなければなりません。

今の仕事をこの先も
ずっと続ける気がありますか。

そもそも続けられるのでしょうか?

終身雇用が一般的だった時代、
こんな事を考える必要も
無かったと思います。

しかし、残念ながら今や
与えられた仕事のみを
日々こなしているだけで

定年まで過ごせる時代では
無くなってしまいました。

自分で仕事見つけて
自分はまだ会社に貢献できる
ということを明らかにしないと

会社内に自分の居場所を
見つけることは難しく
なってしまうでしょう。

それができないと
社内失業状態となり、
最悪リストラの対象として

不本意な形で会社を去ることに
なるかもしれません。

そうならないために、
”自分の将来は自分で決める”

と決意し、

自分に何ができるか。
自分は何をしたいのか。

はっきりさせることが
重要となります。

これは簡単に分かる、
見つかるものではありません。

しかし、
これが決まれば
未来が明るくなって

精神的に一気に楽になることは
私自身経験済みです。

一人で考えるのもいいですが、
自分の良さは自分では
分からないものなので

他人の力を借りるのも
いいかもしれません。

頑張りましょう。

それでは。

エンジニア上がりのマネージャーにありがちなこと

[`evernote` not found]
GREE にシェア
LINEで送る

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

前回、技術者であり続けることは
非常に難しいということを書きました。

それでは、
技術者からマネージャーに
転身を図ることはどうなのか?

について、今回書くことにします。

誰しも後輩や転職者の教育係など、
誰かに教える立場になった経験は
あると思います。

その時、ほとんどの人は
”教え方”を教わっていないのでは
ないでしょうか。

それでもなんとなく教育が
できてしまうのは、

教えた人が、教わった人に対して
フォローしやすい環境にいるからです。

教え方がまずくても、
教えていなくても、
教わったのに忘れていても、

問題が起きたら、その都度
フォローができるので

なんとなく教育がうまくいっている
ような気がしてしまうものです。

翻って、チームをマネジメント
するときのことを思い出してください。

今までメンバーの立場であった人が
次からはリーダーになって下さいと
言われた場合、どうなるでしょうか。

きっと大きな不安に襲われるのでは
ないでしょうか。

やる気に満ち溢れている人は
そうそういないと思います。

人は誰でも未知のもの、
未経験のものに初めて触れる場合、
不安になるものです。

ですので、
初めてリーダーになる人に対して、

チームマネジメントとして
最低これをやりなさいというものを
決める必要があります。

作業管理や工数管理などの方法や、
報告資料の作り方などは
プロジェクトや会社単位で
決まっていると思います。

これらを教えたから
あとはよろしくといっても、
マネジメントの仕方を教えたことには
なりません。

リーダーが作業の割り振りだけを行って、
後はメンバー個々人に任せる。

というような、
待ちの姿勢(受動的)な
マネジメントの場合、

多くの場合、問題が発生しても
それを早期に発見することは難しく

メンバーからの報告を受けるまで
リーダーが問題を認識できないという
欠点があります。

また、プロジェクトの成否は、
メンバーの裁量に大いに関わってきます。

全てのメンバーが優秀で
能動的に働いてくれれば問題ありませんが、
そうではない場合も多いはずです。

これに対して、

リーダー自ら積極的に、
メンバーから情報を収集して、

メンバー個々人の状況を
常に把握しているという

能動的なマネジメントの場合、

問題を早期に発見できる可能性が
高まります。

また、進捗や工数の管理においても
問題の発生を予見できる可能性が
高まります。

こうしてみると、
能動的なマネジメントの方が
メリットが非常に大きいのですが

残念ながら、多くのリーダーが
受動的なマネジメントになっています。

原因としては、

・多忙すぎて動けない
・必要性を感じていない
・やりかたがわからない

などがあると思います。

今まで技術者だった人が
マネジメントを求められた場合に

このような形になってしまうケースが
多いと思いますが、

是非とも能動的なマネジメントに
チャレンジしてみてください。

その違いにきっと驚かれると思います。

キーワードは、

”積極的に”と、”能動的に”、です。

私の場合、この能動的なマネジメントを
実践するための一助として、

コーチングを取り入れたのですが
その効果はてきめんでした。

それまでとは全く違う結果となり、
私自身の評価にもつながりました。

コーチングを学んだおかげで
チームマネジメントが上手くいき、

結果的に顧客にも喜ばれて
継続的な受注に繋がりました。

また、メンバーとのコミュニケーションが
密になりますので

副次的な効果として
メンバーとの信頼感、親近感が
向上したような気がします。

このように、明らかなメリットが
ありますので、明日からでも
チャレンジしてみてください。

周りのリーダー、マネージャー、に
合わせる必要はありませんから

自分のマネジメントスタイルを
見つける上でも試す価値はあります。

リーダー、マネージャー、として
一歩上を目指しましょう。