マネジメント」タグアーカイブ

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

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

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

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

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

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

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

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

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

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

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

ポイント1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

とは言っても、

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

という人は、

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

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

とのことなので

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

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

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

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

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

ポイント2

*状況を把握する

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

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

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

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

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

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

週一くらいの確認では

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

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

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

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

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

そんな訳ですので、

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

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

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

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

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

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

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

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

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

それでは。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それは、

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

ということです。

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

それでは。