まだ求人オファーとかスカウトメールくる…(´△｀)
既に120通ぐらい
通常の求人メールも沢山入ってるけれども
いくらなんでもメールが多過ぎる(´△｀)
基本
一社一社をキチンと業務内容とか
調べながらでないと
どんな求人なのかイメージ湧かない
そこで俺がどう仕事していくのか
イメージしてからでないと
返答も出来ない
単なるお給料や仕事が欲しい訳じゃなくて
沢山の多種多様な仕事に囲まれて
職場のみんなと仕事にウハウハしながら
みんなで力を合わせて一生懸命に働きたい
だから
その求人内容とか
会社のやってる仕事範疇が
とても重要で
お給料の事よりも
仕事の中身と
会社の人達と
業務内容の幅広さと
元請けなのかと
社員の多さと
顧客の多さ幅広さと
様々な業種に顧客がいるかと
とにかくスケーラビリティな
業務スタンスで仕事しているのかどうか
そうじゃないと俺の今のスキルが
今後はほとんど使えなくなる(´･_･`)
大きな仕事
多様な顧客
多様な仕事
元請け
そういうのはどれもリスクが高い
リスクが高い仕事は
やらない、やれない、実力や経験が無い
IT業界はそういう会社が大半だから
そういう会社に転職してしまうと
もう二度と
システムエンジニアリングという
システムエンジニアの
本業な仕事をやれなくなる
技術営業
案件管理
予算管理
要員計画
工程進捗管理
品質管理
課題管理
関係先との意思疎通と調整業務
そういうのが出来るのも
システムエンジニアリングだけども
それはあくまでも
どんな仕事にも必ず
仕事を日々進める為に必要な日常の業務
エンジニアリングの一部分だし
本来はピラミッド型の組織運営と併せて
幹部SE →PM →PL →PG
意思決定→計画管理→指示(指図)→自己管理
判断 判断 判断 判断
↑←←報告←↑←報告←↑←報告←↓
全体でグルグルとPDCAを回し続けて
各々が部相応に適正な裁量を発揮して
意思決定、計画、指示、報連相、
上手く機能させてかないとならない
管理職だからとか
マネージャーだからとか
システムエンジニアだからとか
プログラマーだからとか
そういうレベルで
する、しない、とか
権限や責任が有るとか無いとか
そういうものじゃない
みんな１人１人に
適切な重さの責任と裁量が
ピラミッド型で分散されてないと
みんなが理解していないと
PDCAは回らない
システムエンジニアも
チームの１員として
立場や立ち位置に合わせて
仕事を進める為の役割分担が伴う
プログラマーにだって
その役割分担の一部分が有る
働く人達みんなに役割分担が有る
仕事のマネージメントは
管理職1人だけで成り立つものじゃ無い
勘違いされがちだけれども…
仕事のマネージメントと
仕事のエンジニアリングは
役割分担が重複する部分が多いけれども
それはエンジニアリングには
マネージメントも含まれるからで
マネージメントそのものは
どんな業種の仕事にも必ず必要な事で
仕事のマネージメントと
管理職のマネージメントと
システムエンジニアリングとが
混同されがちだけれども
全く目的と本質が異なるもので
そこを混同して勘違いしていると
仕事やプロジェクトや
組織の人間関係構築や
人材育成に失敗する
長い期間でみたら
そういう失敗は
組織運営の崩壊で後戻りが出来なくなる
そういうの長いエンジニア人生の中で
アチコチで幾つも見てきたからなぁ…(´･_･`)
でもこれを上手く回せている組織ならば
大きな案件や
難しい案件も
社員の多い少ないに関わらずにやれる
経験の無い技術や分野の仕事は
それだけでかなり難しいものだけれども
どんなに大きな会社でも
こういう
マネージメントと
エンジニアリングの違いが
ごちゃ混ぜにされてて機能していないと
仕事そのものに失敗するし
人材を潰してしまう
マネージメントとエンジニアリングは
分けて考えるべきだし
その時々のプロジェクトの負荷に応じて
兼務させたり
兼務から解いて
エンジニアリングと
マネージメントを
別々に任せないと
マネージメントもエンジニアリングも
なし崩し的に崩壊していき
仕事も社内もどちらも
PDCAが回らずに
みんなの勤務時間がボロボロとか
プロジェクトもボロボロとか
課題も管理出来てなくて
幹部SEも報連相が届いて来なくて
的確な意思決定や処方を行なえないとか
そういう悲劇が起こる(´･_･`)
こうなると
人材が耐えられずに辞めていく(´△｀)
顧客からも信頼を失う
悪名高き
黒歴史に名を残すプロジェクトを生む
様々な失敗で間に合わないとか
技術的に見通しを間違えたとか
不具合だらけとか
仕様をまとめきらなかったとか
実力が足りなかったとか
打ち合わせや調査が足りなかったとか
そういうのが
悲劇なプロジェクトになると
思われがちだけど
どんな仕事やプロジェクトも
もしも問題が発生した時に
必ずお客様やメーカーや社内と
問題解決の策を話し合って
検討するべきタイミングが有るし
その必要な検討をやらないまま
ズルズルと火達磨に突入するのが
プロジェクトを黒歴史にしていく
大企業だと優秀な人材と
社員数が多いから
サポートやフォローで
テコ入れに追加出来る要員が控えていて
リカバリーに優れているし
プロジェクトへ随時
様々な監査を入れて問題を発見する
マンパワーが有る
そういう力技で凌いでいる限り
何度も同じ失敗をするし
逆に小さな会社だと
そういう暗黒プロジェクトでは
監査をする余力が無くなり
倒産や社内の人材崩壊しかねない
でも
本来はわざわざ
特別な監査チームが必要なのかな？
普段の
マネージメントが機能してて
エンジニアリングも機能してて
そうしたなら監査っていっても
幹部SEが普段から
状況把握を出来てる状態こそが
その状況把握が現実なものなのか
適時チェックしている事が監査になる
仕事に必要な日常業務そのものが
マネージメントだし
エンジニアリングだし
意思決定、計画管理、指示、報連相
それで回すPDCAの中に
適時組み込まれているのが監査で
それが機能しているか
品質が保たれているか
必要な手続きは守られているか
必要な書類は残されているか
全部が繋がってる仕事の流れ
だから
マネージメントと
エンジニアリングと
監査と
社員の労務管理とを
ごちゃ混ぜに混同して勘違いした
そういう運用をしていると
負担ばかり重くなるのかなって思う
本来は
プロジェクトの負荷や立場に合わせて
兼務したり
兼務を解いて専任させたりして
どんな状況下でもPDCAが回る
組織運営、プロジェクト体制に
臨機応変で組み換えなきゃいけない
それが要員計画の管理
要員管理に失敗すると
芋づる式に火の車になるのは
その辺りの
マネージメントとか
エンジニアリングとか
労務管理とか
ごちゃ混ぜに勘違いした運用してると
どうやっても火消しする事ができず
どんどん燃え盛る(´△｀)
システムエンジニアは万能だけど
どんなシステムエンジニアリングでも
キャパシティを超えたら無力な存在
キャパシティを超えさせない様に
マネージメントするのが
労務管理だし
社内の事業マネージメント
逆にシステムエンジニアは
なんでも万能じゃないといけないけれども
得手不得手な事も
キャパシティの上限も人それぞれ
だからこそ
組織運営のマネージメントが必ず必要
システムエンジニアの働き方を
マネージメントするのは
幹部SEでも構わないし
労務管理の管理職でも構わないし
システムエンジニアの万能性に
全てを兼務させたり
絶対権限を持たせるのは間違いの根源
組織運営のマネージメントは
ピラミッド型で各々に裁量が必要
それとプロジェクトマネージメントや
エンジニアリングとは
イコールでは無い
社内の労務管理とだって
イコールじゃない
そこら辺を間違えなければ
会社の仕事って
誰でもこなせる分野が必ず有る
どんな仕事も
経営運営する幹部
組織運営する幹部
事業運営する幹部
それらから方針を貰い計画管理する
労務管理の管理職
プロジェクトマネージャー
更に計画管理に沿って指示管理する
プロジェクトリーダー
チームリーダー
更に自己管理する
メンバー員
みんなの連携が無いと
仕事も組織も上手くはいかない
負担とリスクを増す悪循環(´･_･`)
フレキシブルに
組織やプロジェクトチームを組むってのは
そこら辺が理解を出来ていないと
到底出来っこ無い
プロジェクトマネージャーなのだか
労務管理職なのだか
エンジニアリングなのだか
そういう区切りをごちゃ混ぜに理解してると
管理職としても育たないし
エンジニアとしても育たないし
プロジェクト失敗した理由も
労務の管理職として？
プロジェクトマネージメントとして？
エンジニアリングとして？
組織運営のマネージメントとして？
それぞれで何に失敗したから
プロジェクトが失敗したのか
ピンボケしてくるし
それぞれ目的が異なるマネージメントだから
一括りにしてしまうと
プロジェクトの
管理実行面での失敗ばかり
前面に大きく浮かび上がってきて
組織運営とか
労務管理とか
エンジニアリングとか
それぞれの部分での
マネージメントの失敗は
１つも表に出て来なくなる
そういうのが続くと
会社や組織や人材を
すり減らし潰していく
そこら辺がしっかり考えられてて
しっかりと出来ている会社が良いな
臨機応変で色々な仕事に集中して
安心して沢山お腹いっぱいに
仕事に打ち込める
✧*｡( ´∩•͈ω•͈∩` )✧*｡
