月別アーカイブ: 2014年6月

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

[`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で送る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これに対して、

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

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

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

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

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

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

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

原因としては、

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

などがあると思います。

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

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

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

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

キーワードは、

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

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

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

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

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

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

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

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

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

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

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

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

SE,アプリケーションエンジニアであり続けるためには

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

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

会社員としてある程度の経験を積むと
自ずと自分自身の今後のキャリアについて
真剣に考える必要が出てきます。

特に、今まで技術者として
キャリアを積んできた人にとっては
非常に大きな問題となると思います。

技術者として今までと同じように
キャリアを全うするのか、
マネジメント主体に進むのか
悩む人も多いでしょう。

これはプログラマであれ、
システムエンジニア(SE)であれ、
変わらないのですが、

何れの道も簡単でないことは確かです。

私の場合は、二十代のうちは技術を学び、
三十代以降はマネジメント主体になるよう
働き方を変えていこうと考えていました。

結果として、途中転職はありましたが、
ほぼ予定通りにできたと思います。

二十代のころは、上司や先輩から
プログラミングの技術やシステム設計の
技術を学び、

三十代になると、マネジメントを経験したいため
チームを率いる形での仕事を自ら率先して
希望していました。

これは、メンバーにも恵まれたため
ほぼ全ての案件について大きな問題を
起こすことなく完了させることができました。

このときのメンバーの方々には、
いまでも感謝しています。
ありがとうございました。

私の場合は、たまたま上手くいったように
見えただけで、本当はいろいろな問題が
私の知らないところで起きていたのかも
しれません。

もしこれを読んでいる人が
二十代の人でしたら、
今は只ひたすらに学び覚えることに
集中してください。

将来マネジメントの道に進む場合に
技術を知っているかいないかで
大きな違いが出てきます。

三十代以降の人でしたら、
早く決めないとやばいです。

”マネジメントには興味ない、
これからも技術者として生きていく。”

と決断された方は、
相当な覚悟と決意を持って
それに臨んでください。

一つの技術を覚えたからといって
それで一生食えるのか、と言ったら、

今の時代は非常に難しいとしか言えません。

昔むかしの大型汎用機全盛の時代は、
COBOL言語を覚えれば、
食いっぱぐれなしと言われました。

今でも銀行や生保など
数少ない汎用機を抱えている現場などで

COBOLプログラムの保守を担当している
大ベテランの技術者がいることは確かですが

これは数少ない例外の人たちです。

また、私がいるSAP業界も
既に十数年が経過し、

一時のブームともいえる
新規導入プロジェクトのラッシュから

リーマンショックによる
プロジェクトの消失を経験し、

SAP技術者もかなりの減少と、
高齢化が顕著になっていると感じます。

SAP業界のような
かなり閉じられた世界においても
技術の変遷はありますので

常に新しいことを学び続ける
姿勢と意欲を持ち続けなければ
なりません。

ある程度年をとると
以前のような無理はできなくなりますし、
記憶力や理解力も確実に落ちてきます。

それでもなお、技術者としての道を
歩みたいという方は、

落ちてくる身体的な能力を
カバーできるだけの工夫が
必要となることを認識しましょう。

また、所属している会社によっては、
新しい技術い触れる機会が
ないかもしれません。

そのような場合は、
別途教育を受けたり、

新しい分野の仕事を
引き受けられるような
環境を作ったりと、

普段の仕事とは別に、
少なくない費用と時間を
使わざるを得ないと思います。

特にフリーで活動されている方などは
前途多難であることは確実です。

なんとなく振られた仕事をこなしていたら
いつのまにかベテランと呼ばれる
世代になってしまった。

リーダー経験もなく、一人でプロジェクトに
アサインされることがほとんど。

そんなプログラマ、システムエンジニア(SE)
の方々へ、お伝えしたいことがあります。

それは、

”考え方ひとつで未来はどんな形にもなる”

ということです。

楽ではないと思いますが、
望むことで未来はいくらでも変わります。

それでは。