受託開発」タグアーカイブ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

と言えます。

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

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

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

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

それを避けるためには、

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

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

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

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

コーチングのスタンスは

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

というものです。

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

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

が目標となります。

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

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

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

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

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

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

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

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

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

受託開発SEの将来は?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

転職?

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

プログラマからシステムエンジニア(SE)へ、
SEからコンサルタントへ、など

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それでは。