PMOって何するの？開発案件への入り口はまだ先だった！?
◇2023年10月
開発案件を目指して受けた面談
OKをいただいたものの、
なぜかPMOとして働くことになりました・・・
▼前回の記事はこちら👇
yarebadekiru-ko.hatenablog.com
どうやら、開発案件よりもPMOが人手不足でやばい、
開発案件は設計段階が長引いて中途半端な時期だし
とりあえず3か月だけPMOに入ってほしい。
ということらしい。
3か月後には開発へスライドの予定と言ってくれてはいるし、
ここでお断りして参画案件が決まらない可能性もあるので
お受けすることにしました。
PMOとは、
Project Management Officeの略で
開発現場にいる各チームを横断する形で管理するチームのことです。
WBSというタスク管理兼、予定表のようなものを見つつ、
進捗の確認などをするのがメインでした。
チームメンバーは私を含めて3人。
私の担当は、主として
上位会社に毎週報告する週次進捗資料の作成とWBSの管理です。
WBSの管理と一言で言ってますが、
これがかなりの曲者で、
2000行弱ほどのデータ量がある激重ファイルが3チーム分。
管理フローが固まってなさ過ぎて、
不整合が起こりまくるハードモードでした。
そんな状態からか、
私に任命された大きなタスクがもう一つ。
各業務のマクロ化。
エクセルのマクロは前にいた案件でちょこーーーっと作っただけのレベルなのに、
依頼されたのは複数ファイルをまたぎ、
さらに複雑な条件分岐をいくつも必要とするレベルの難しさ・・・
こんなの一人じゃ無理だよーーー(ノД`)！！
としばらく悩んでいたのですが、
なんと
救世主が
いた！！！！！！
彼の名はM氏としておきますが、
この方がほんとーーーに
救世主かつ仏のような方でして・・・✨
立場としては、
B社の社員としてC社で働いているA社正社員の私
がC社での案件で出会った
B社のプロパーさん、となります。
ややこしいですね。
私はPMO、M氏は開発チームと
働くチームは違いましたが、同会社なので話す機会も度々ありまして
「マクロが全然進まないんです～～。。」と嘆いていたら
助けてくれたんですね。
M氏ものすごくスキル高いので、
私がごちゃごちゃやっても一向に出来上がらなかったマクロを
サクッと作ってしまいました。。。✨
しごできすぎる・・・かっけぇ・・・✨
自社のメンバーは、未経験から始めた人も多いので、
教えてもらう、というよりかは一緒に悩みながらやっていく
のほうが近いのですが、
M氏に聞けばなんでも答えが返ってくる状態。
最後の砦、絶対的安心感です。
開発チームの人も、エラー出たりしたらよくM氏に聞きに来てましたね。
しかも、スキル高いだけでなく、
フォローばっちりでめちゃくちゃサポートしてくれるんですよ。
なんなんですかほんと。人生何周目の方ですか？
って感じ。
もう、師匠と呼ばせていただくし、
勝手ながら、ついていくと心に誓いました。笑
そんなこんなで、マクロ作成係となった私のPMO生活が続きます。笑
今日も読んでくれてありがと～(^^)/
---------------------------------------------＊＊＊---
▼ランキングに参加してます。
良ければポチっと('ω')
-----＊＊＊-------------------------------------------
エンジニアへの第一歩！～開発案件参画編～
◇2023年10月
さて、お給料を上げたい！という思いから、
開発案件を目指している話です。
▼詳しくは前回のブログで。
yarebadekiru-ko.hatenablog.com
開発案件への参画は、スキルがある人なら簡単なのでしょうけれど、
初心者（ロースキル）の私にはなかなか難しいかもな、と思っていました。
現場での実務経験なし、ロースキルの私を取らなくても、
実力のあるエンジニアさんたちは周りにわんさかいるでしょうから・・・
ただ、そんな泣き言を言っていてもしょうがないので、
私は、保持しているスキルと人柄で勝負するしかないのです！！
私は、元々接客業をしていたこともあり
コミュニケーションは得意な方です。
なので、案件先との面談では、
ある程度の知識は答えられるようにしつつ、
話しやすい人・コミュニケーション能力のある人、と思ってもらえるように心がけました。
案件の参画条件の個所に
「コミュニケーションが円滑に取れる方」と書いてあることも多いので、
結構重視されている部分なのかなと思います。
そんなこんなで、9月から全部で3案件ほど面談を受けました。
もちろん、相手企業からスキル不足で断られることもありましたし、
希望条件が合わず私からお断りをした案件もありました。
そんな中、
1つの案件に参画できることになったのです！！
やったー！！
ついに・・・！
ついに私も開発案件への参画が決まりました！！！
IT業界に転職して2年と2ヶ月・・・
やったどー！！頑張るどーー！！
同期のみんなが開発案件に次々参画していく中
私まだコード触れてないよ・・・(´・ω・)💦となっていた
過去の私、さらばだ！！
でもまぁ、
参画決定がゴールじゃないですから！！
やっとスタート地点に立てたようなもので、
今までが準備運動のような期間でしたから！！！
とりあえず一旦落ち着く。
内容は、ある金融システムの新規開発で
詳細設計終盤からの参画です。
使用言語は、
画面の修正にHTML/CSS
フロント側の処理はTypeScript
バックエンド側の処理はJava とのこと。
画面単位で割り振られたタスクに対し、
画面レイアウトから処理の記述までを一貫して担当するものでした。
なんか、まんべんなく知識必要で大変そう・・・
でも、
楽しそう！！
参画前に言語の勉強しておこうかな。
HTML/CSSも最近触ってないしおさらいしとかなくちゃ！
そんな矢先、
案件先からの衝撃の一言が・・！
「後々開発案件にスライドはするけど、3か月間はPMOでもいい？」
なんてこったー！！！
次回、
「PMOって何するの？開発案件への入り口はまだ先だった！」
今日も読んでくれてありがと～(^^)/
---------------------------------------------＊＊＊---
▼ランキングに参加してます。
良ければポチっと('ω')
-----＊＊＊-------------------------------------------
あなたの「譲れない」は何ですか？時間？やりがい？それともお金？
◇2023年9月
ライブラリ管理の案件に就いて11か月。
実は私には、IT業界に転職して叶えたい目標がありました。
それは、
開発案件に就くこと。
そもそも私がIT業界に転職した理由は、
下記の記事に書いてあるのですが、
yarebadekiru-ko.hatenablog.com
やはり働いているからには
お給料というのは重要なわけでして・・・。
リモートワークが出来る業界、
ワークスタイルが選べて、比較的時間を作りやすい業界、と
IT業界のメリットは数あれど、
お給料が低いとなかなかやっていけないわけです・・・(´・ω・)
もちろん、人によって何に重きを置くのかは違ってくると思います。
子供のいる方なら、時間に融通が利くことが第一優先かもしれないし
やりがいが一番！という人もいるでしょう。
でも、私が仕事に求めるものは「お金」でした。
うちの会社は、ベンチャー企業なこともあり
お給料は高くないです。
ボーナスは寸志でしたし、資格を取ったところで資格手当なんかも付きません。
みなし残業が含まれているので、
普通に働いていたら残業代が付くこともほぼありません。
転職してまだ短いから、と思いつつも
友人の年収やボーナスの額に、
ひたすら「羨ましい・・（´・ω・）」と思う日々でした。
なので、開発案件に就きたい、という思いは、
手に職をつけたい、スキルを付けたい、という思いもありますが、
単価が高いから、という理由が大きいです。
SESの形態としては、
元請け-1次請け-2次請け のような形で自分との間に数社挟まっている場合が多いです。
もちろん、経由している会社にはマージンが発生するので、
自分にたどり着くまでに支払額がどんどん少なくなっていってしまいます。
元請けさん ▶ 1次請け ▶ 2次請け ▶ 自社 ▶ 自分
単価50万で依頼 単価40万で依頼 単価30万で依頼 給料として20万支払
みたいな感じですね。
悲しい・・・(´・ω・)
つまり、自分の手元に入るお金を増やすためには、
元請けさんが発注する単価が高い案件に就く、
ということが必須になってくるわけです。
そうなると、単価が高い案件＝開発案件
になったんですよね。
ただ、依頼主だって開発実務未経験のSEよりも、
経験豊富なSEのほうが良いに決まっています。
なので、私のようなロースキルSEは、
「この人材が欲しい！」ではなく、
「まぁこの人だったら参画してもらっても良いかな？」
と思ってもらえることをまず目指します。
ちなみに、案件参画前には参画先の企業との面談があるので、
企業側が「この人は違う」と思えばお断りされますし、
SE側も「なんか違った」と思えばもちろん断ることが可能です。
とまぁ、諸々の経緯があって、
開発案件にチェンジするべく次の一歩を踏み出そうとしたのです！
長くなりそうなので、続きは続編で！
今日も読んでくれてありがと～(^^)/
---------------------------------------------＊＊＊---
▼ランキングに参加してます。
良ければポチっと('ω')
-----＊＊＊-------------------------------------------
自分はこのままで良いのか・・？プログラマーへの道
◇2023年夏
ライブラリ管理のチームに参画して半年ほど。
リリースの手順やその他の業務についても経験を積み、
一通り問題なく出来るようになった頃。
慣れもあって、作業スピードも以前とは比べ物にならないくらい早くなったし、
頼りにしていただけることもしばしば。
有給取得の日程を相談した時に、
初めの頃は「いつでも大丈夫です」と言われていたけど
（出来ることが少ないからいなくても大した穴にならない。）
「いや、その日はいてほしい！」と言われるようになったのが
地味に嬉しかったですね。笑
「必要とされるレベルになれてる！良かった！」って。笑
自分の成長度合いとかスキルって、目に見えづらいから
こういう言葉一つで私の場合は
「あ、成長できてる。」って実感出来たりするんですよね。
自分のスキルも、ゲームみたいに数値化出来るといいんですけどね。
レベル〇〇、次のレベルまでに必要な経験値は〇〇！みたいな。
ただ、参画したての頃って、わからないことが多すぎて
毎日が学びと成長の連続って感じだと思うのですが、
半年も経てば、毎日同じ作業の繰り返しで正直飽きてきてしまうんですよね。
振られたタスクを消費しているだけじゃ面白くないですし。
そこで、私が始めたのが
「効率化」でした。
元々めんどくさがりなので、
単純作業の繰り返しとかをするのがすごく嫌だったんですよね。
当時の状況としては、
毎日やらないといけないのに、作業量が多くて面倒、とか
作業自体は簡単だけど量が多いから時間が取られる、みたいな作業がちらほらあったんですよ。
で、飴ちゃん作戦で仲良くなった（と思っている）メンバーに
「これって必要ですか？」とか
「これ、こうなったら便利ですか？」
みたいなヒアリングをして、いかに作業量を少なく、
また自動化することでいかにヒューマンエラーを失くせるか、を考えたのです！！
みんなのために！✨みたいな部分ももちろんありましたが、
半分は自分が楽したいからツール作っちゃお、みたいな感じでした(^^)
めんどくさがり屋のほうが、
業務って効率的に進んだりするんですよ。
ツールと言っても、そんなに知識もスキルも無いので
簡単なマクロしか作れなかったですが、
それでも今まで手作業でちまちましてた作業が省けるので
結構楽になりました！
VBAの知識は無かったのでネットで調べつつでしたが、
簡単なものだとしても、
自分でプログラムを書いている＝プログラミングが出来ている
というのが楽しかったです(´▽｀)
そしてVBAの知識もついたし、
この時期にやっていたことが次の案件（詳しくは後日）に繋がったので良かったです。
みんなに感謝されつつ自分のスキルも上がっちゃうという
非常に充実した期間でした。笑
もし、毎日の業務が退屈だな～なんて感じている人がいたら、
一歩踏み込んだ業務をやってみるのも良いかもしれないですね('ω')！
今日も読んでくれてありがと～(^^)/
---------------------------------------------＊＊＊---
▼ランキングに参加してます。
良ければポチっと('ω')
-----＊＊＊-------------------------------------------
成長の秘訣とは？日々の行動について。
あけましておめでとうございます。
この記事を書いているのは2024年2月6日ですが、
ブログの中ではやっと2023年になりました。
なんと1年遅れというすさまじいタイムラグでブログを綴っております。
皆様気長にお付き合いくださいませ・・
◇2023年1月
案件参画から2ヶ月。
なんと、
新規参画者の教育担当を任されてしまいました。
嘘でしょ・・・
自分の理解度も微妙な部分があるのに、
教育担当だなんて・・・！
嫌だぁぁぁぁあ！！
しかもね、ほんと、
私がこんなことを言える立場ではないのですが、
この新規参画者の方がなかなかの曲者だったんですよ・・・
当時私たちは、連絡ツールとしてTeamsを使用していたのですが、
メンションつけてチャット飛ばしているのに全然確認してくれない、とか。
やっておいてと言ったのにやってくれない、
朝会の裏で全く急ぎではない作業をしていた挙句、
その日のタスクを把握できない、とか。
うーーーーん これは困った。。。
社会人としての基礎を教育しろってことだったのかな？
他にも気になる点はいくつかあるのですが、
ここで挙げるのはやめておきます。笑
ただ、教育係をして改めて、
受け身でいつづけるのは良くないな、と痛感しました。
例えば、わからないことがあった時、あなたはどう行動しますか？
①誰かが教えてくれるのを待つ。
これは思考停止の最悪パターンだと思っています。
わからないことを放置してしまうので、
それに関連する他の個所もわからないという負のループに陥ります。
結果、全体的にわからないという状態になりそう。
②わからないことをひたすら調べ続けるも答えにたどり着かない。
これは、何もしないよりもマシかもしれませんが、時間の無駄です。
プライベートの時間ならどう行動しようが自由ですが、
業務時間内である以上は、
ある程度調べてもわからないのであれば諦めて誰かに聞いてください。
で、私なりにベストだと思っているのは、
③自分で調べてみて、それでもわからなかったら誰かに聞く、です。
わからないからと言ってすぐに答えを求める人もいますが、
それだと自分の頭にインプットはされないでしょうから、
ある程度は自分で調べるべきだと思うのです。
簡単に得た答えは簡単に頭から抜け落ちます。
上記は１つの例えですが、
答えをもらうまでぼーっと待っているような受動的な行動だけではなく、
能動的に何かをすることが大切だなと、改めて感じました。
自分の頭で考えたことって、あっていても間違っていたとしても
結構頭に残っていたりしますよね。
私から見て、仕事が出来る人は
調べるスキルが高い人が多いと感じます。
最初はね、わからないことがわからないみたいな状態になるかもしれないけど
わからないなりに調べてみることって大事ですよね。
私もこれを実践出来ているかというと怪しい部分があると思うので、
反面教師にしつつ、自分が成長するための要素として取り入れていこうと思います(^^)
めざせ思考力ハイレベル！
今日も読んでくれてありがと～(^^)/
---------------------------------------------＊＊＊---
▼ランキングに参加してます。
良ければポチっと('ω')
-----＊＊＊-------------------------------------------
構築すべきは人間関係！大阪のおばちゃん流飴ちゃん作戦
◇2022年12月
新しい案件に参画して1か月か経ちました。
ここでLIB管理のメンバーを軽く紹介すると、
リーダーのMさん
サブリーダーのHさん
ロングヘア－が印象的なTさん
私より1か月先に参画していたSさん がいます。
そこに統括リーダー的なポジションのS川さんがたまに加わる感じ。
リーダー等の役職が着くと、打ち合わせや会議がぎゅうぎゅう詰めで
1日の大半がイヤホンをして過ごすみたいなことになっちゃってます。
"念のため"出席しておく、とか
1時間のうち関係あるのは5分だけだったとか、
もうちょっとどうにかできないものですかね？
最初の1か月は、レクチャー期間。
リリースすべきものの種類が4種類あるので、
手順や準備・事後作業の内容を教えていただきます。
リリースは、1時間という決まった枠の中で行わなければならないため、
慣れないうちは時間ギリギリになってしまうこともしばしば。
操作を主導で行う作業者と、
ダブルチェックを行う再鑑者の2人ペアで行うのがルールなのですが、
慣れてくると、気の緩みからケアレスミスなんかも発生します。
気づかないとリリースが失敗したり、エラーが出てしまったりと
なかなか慎重な作業が必要になるお仕事です。
それに加えて、リリース以外の業務（どのチームがどの検証面を使用しているかの管理や、GitHubでのチームごとのブランチ管理等）についても教えていただきました。
GitHubやブランチについてよくわからない人は調べてみてね('ω')
そして、参画当初は鉄仮面だと思っていたメンバーたちは
この頃には鉄の仮面を脱ぎ捨てて、
愉快な仲間たちとまではいかずとも気兼ねなく話かけられる関係にはなっておりました。
こうなるために私が行ったこと。
それが、
飴ちゃん作戦です。
よく大阪のおばちゃんたちが「飴ちゃんいるか～？」と言いつつ
ポッケから取り出した飴をくれたりするものですが、
あれをパクりました。
甘いものもらって嫌な思いする人はいません。
個包装のお菓子なんかを持っておくと、
仕事で使い込んだ脳を癒すべく
甘いものを求めた人間たちにはとっても効果的。
そして、同じ釜の飯を食ったなんちゃらとも言いますが、
同じ袋の飴ちゃんを食べた者は、
すべからく仲間となるのです！！！笑
とまぁ、大げさに書きましたが、
普通に飴をおすそ分けしただけなのです。
大体が何か食べつつ仕事してたりしますからね、私。
ただ、こういう所から会話って始まったりするんですよね。
「これ、お土産で貰った飴なんですけど、食べますー？」から始まって、
「え～ どこのお土産なんですか？」
「韓国です～！韓国ドラマでよく出てくる飴らしくて！」
といった具合に。
やっぱり、ずーーーーっと集中し続けるのは難しいですし、
休憩がてら甘いものを食べながら雑談をする。
そういうのって、人間関係を円滑にするためには大事なことだと思うんですよ。
あの人、普段はクールだけどあんこ大好きらしいよ、とか
いつも完璧な人が実はめちゃくちゃ関西弁、とか。
仕事の会話しかしない相手よりも、
ちょっとでも雑談した相手のほうが質問しやすかったり
物事を頼みやすくなったリするじゃないですか。
ひたすら真面目に業務に取り組むのも大事ですが、
適度な息抜きや、自分が働きやすい環境作りも大事。
仕事で10時間一緒にいるよりも、
休憩で喋る数分間のほうが絶対に仲良くなれますもん。
少なくとも私はそう思っています(^^)
もし職場の人間関係に不安を感じている人がいたら、
甘いものをおすそ分けしつつ世間話をしてみてください。
何かが変わるかもしれません(´▽｀)
今日も読んでくれてありがと～(^^)/
---------------------------------------------＊＊＊---
▼ランキングに参加してます。
良ければポチっと('ω')
-----＊＊＊-------------------------------------------
同僚は鉄仮面！ショートカットキーを使いこなす若者たち
◇2022年11月
11月から新しい案件に参画します。
９月末にヘルプデスクの案件を終えてから、
実は１か月だけ自社の仕事をしていたのですが、
これについてはまた今度書くことにします('ω')
新しい案件について、
案件名としては「LIB管理」とのことですが、
正直「LIB管理とはなんぞや・・」状態です。
着任してよくよく聞いた結果、
「開発者たちが作成したソースコードをリリースする」
チームへの所属とのことでした。
つまり、
開発者さんがバグ修正や機能追加のためにコードを書く
↓
それを検証面へリリースして動作確認
↓
問題なければ本番環境へリリース
の赤字部分が主な業務内容とのことでした。
いきなり一般ユーザーさんが見ているサイト（本番環境）へ変更をかけてしまうと
不具合が起きてしまったときに大変なので
検証環境という本番環境に似せて作った環境でまずテストをするんですね～。
詳しくはお伝えできませんが、
今回の案件（N社とする）ではたくさんのシステムを扱っており
それぞれのシステムで改修した内容を各チームが自由にリリースしてしまうと
問題が起こってしまう可能性があるので、
リリースについてはリリースの専門チームを作ってそこで他の環境やリリースのタイミング等の兼ね合いを考えて一括管理するというものらしい。
リリースする内容についても種類がいくつかあり、
種類が違えばリリースの手順も全く違ってくるので
これを把握するのが最初はとっても大変でした( ﾉД`)！
そして何より衝撃だったのが、
タイトルにもなっております通り、
チームメンバーがみんな鉄仮面。
なんとも失礼な言いぐさですね。
でも、本当にそう思ったんです。
みんなパソコンに向かって一心不乱にパチパチカタカタ！
オンラインミーティングをしていると思えば、
参加してるメンバーみんな同じテーブルにいる、みたいなこともあり、
「なんなの！みんな仲悪いの！？隣にいるんだから直接話せばよくない！！？」
なんて思っていました。
前の案件が、「今日の晩御飯なんですか～？」なんて会話をしていたほど
ほっこり案件だったので、ギャップが大きすぎて戸惑いましたね。
それに、4人いるメンバーのうち3人はどう見ても20代前半にも関わらず、
ショートカットキーを使いこなし
爆速で仕事をこなしていく精鋭たちに見えました。
慣れてしまえばそんなこともなかったんですけど、
初めのうちは自分がまだ業務内容わかってないこともあって
みんな難しそうなことやってるように見えるんですよね。笑
まぁ、実際ここのチームの人たちは新卒3年目とかにも関わらず
ものすごく仕事が出来る人達であったことは確かなのですが(^^)
初日から
「やばい、ものすごくエリートの中に放り込まれてしまった・・！」
と焦ったのを覚えています。笑
参画初日は貸与されたPCのセットアップに1日を費やすことになるのですが、
実施するべき内容はマニュアルに書いてあるので、
どうしてもわからないことがない限りは質問することもなく、
特に会話の無いまま1日が終わりました。。笑
まぁ、初日はこんなもんか。
どうやってみんなと仲良くなろうかなぁ。笑
今日も読んでくれてありがと～(^^)/
---------------------------------------------＊＊＊---
▼ランキングに参加してます。
良ければポチっと('ω')
-----＊＊＊-------------------------------------------
