先日、所属会社の社員育成の一環として、外部研修に参加してきました。

私は社会人4年目、IT業界経験で言えば3年弱の若輩者ではありますが、
今現在の案件での作業状況を評価して頂き、声をかけて頂いた形になります。

私自身としては、イチ作業者としてプログラミングスキルを磨いていきたい、
という思いもありますが、管理者としてプロジェクトをまとめる職位に就きたい、
という思いも秘めている(笑)ため、炎上中のスケジュールを何とか調整し参加しました。

研修自体は二日にわたって行われ、一日目は主にスケジューリングに関するワーク、
二日目はスケジューリング含めプロジェクトマネージャーの業務に関するワークでした。

最初に個人的な結論となってしまいますが、
PL経験の無い私にとっては二段飛ばしの内容でした。
しかし、ここ最近はイチメンバーでありながら
PLのような立ち回りが求められる機会があり、PMとの連携を密に仕事を進めているため、
PMがプロジェクトを運営するにあたりPLはどういう動きをしなければならないのか、
という視点で学ぶことが多かった研修となりました。

結論はさておき、研修の中で興味をひかれた内容をいくつかご紹介したいと思います。

中韓両国の人件費が高騰した

中国のシステムエンジニアのイメージってこんな感じです。

私が仕事で一緒になった中国で遊ぶのが好きな方が言うには、

「エンジニア1人に対して美女が2人付く」

事もあるそうな。

日本でそれやったらどうなるんでしょうね、「差別だ!」という意見と
「それで稼げるならラッキー」という意見に分かれて社会問題になりそうな気がします。

私は昭和の時代を肌身で経験したことはありませんが、
「お茶汲み」ならぬ「コーヒー汲み」してくれる人なら欲しいと感じます。

休み時間は放っておいてくれていいです。

話がそれましたが、中韓では人件費が高騰し、
現在のオフショア先として最も有望なのがベトナムらしいです。

ここで資料を一つ。

上記の資料から東南アジアの中でベトナムとフィリピンの人件費が安いことが分かります。

個人的にどちらの国が日本に溶け込んでいるかを考えると、
仙台でもよく見かけるベトナム人の方が多いような気がします。

将来ベトナムで仕事をする時が来るかもしれませんね。
ちなみにベトナムの公用語はベトナム語で、英語も多少通じるようです。

WBSの線を引くことだけなら誰でも出来る

新卒レベルで聞いてたらびっくりな発言ですが、
その場にいたのは現場でのリーダークラスだったので異論は特にありませんでした。

私個人の経験から言えば確かにある程度の経験を積むことで
線だけは何となくでも引けるような気がします。

実際に仕事の現場ではたとえ新人に対してでも「この仕事、いつ頃終わりそう?」
と聞いたりしているのではないでしょうか。

私は他の業界をそれほど詳しく知らないので、もしかすると業界特有かもしれませんが、
入社から自らの作業の見積もりを行う機会は多々あるかと思います。

その経験値から、「自分ならこれぐらいで出来る」と線を引くことは出来るかと思います。

タイトルには続きがあり、

 そこに人を割り当てられるのがPMのスキル。

という形で締めくくられました。

これには「なるほどなぁ」と上から目線ではありますが感心しました。

確かに、今の現場でも作業規模を見積もる機会がありますが、
WBSとなると「自分ではこれくらいで出来るけど、この人だと…」と
悩まされることも度々です。

入社してからはまずは目の前の作業の目途を付け、
その経験から少し先までの自分の作業を見積もり、
それら経験を踏まえて他人の作業も見積もる、
そうやって成長していくんだなぁ、と感じました。

これは意識次第でプログラマーでも培っていけるスキルですので、
新入社員の方には「いつ頃まで終わる?」を催促と捉えずに頑張ってもらいたいです。

今後はフットワークの軽い会社じゃなきゃ生き残れない

これはよく言われることかもしれませんが、会社の構造を
業務に応じて柔軟に変えて行かなければ後手後手に回るというものです。

PMBOK第6版でアジャイル開発を全面的に押し出す形に

「ピンボック、ピンボック」とよく耳にはしますが、
実は私あまりよく知りませんでした…。

余談ではありますが第6版で「タイムマネジメント」が「スケジュールマネジメント」
に変更されたという話も聞きました。情報処理試験に役立てられそうです。

話は戻りますが、「富士通」が「アジャイル開発」をスタンダードに置く、
というニュースを見たのはつい一年前の事でしょうか。

今では既にその活動が本格化しているように見受けられます。

当時私もアジャイル開発の案件に参画していましたが、
これほど進めやすいシステム開発は無いな、と思いました。

それは今現在炎上中のウォーターフォールモデルを経験しても言えることです。
(ドキュメント作成の手間が半端ないって!)

ただし、アジャイル開発の欠点としては作業規模の見積もりが難しいことです。
仕変を前提として「とりあえず作ってみる、実装してみる」のスタンスであるがゆえに
より良いものを作ろうと思えば思うほど期間が膨らんでいきます。

そんな難しさを内包しつつも、情勢はアジャイルへと流れつつあるようです。

運用/保守要員はリプレイス案件で上流に関われる可能性がある

これは目から鱗でした。

個人的に「運用/保守」というのは退屈で、逆に忙しくなってはいけないモノだと思っていますが、
見方を変えれば「一番業務に精通している人」と捉えることもできます。

対象システムの稼働を常時見ているわけですからね。

当然、現行システムの事を一番よく知っているので、
どういった改善点が挙げられるのかを的確に提案することが出来る、というわけです。

逆に体制を構築する側としても「運用/保守」のエンジニアを
大切にしないといけない事を忘れてはいけません。

ゴールデンサークル

誰がどこで提唱したお話か、というのは下記をご参考ください。(手抜き)

要は「仕事への取組み方」であると私は解釈しています。

私も仕事に着手するときに、何をどのように行っていくか、まさに正すべき考え方をしています。

この仕事を完遂させたらどうなるのか、とは常日頃考えることはほぼありませんでした。

「でした」と言うのは、実は今の会社に入ってからというものの、
『ゴールデンサークル理論』に思考が近づきつつあります。

以前の案件では、
「Xamarinという新しい技術に触れることで、情報の第一人者になれる」
とまで考えていた時期がありました。

実際にはXamarinの知識もなかなか記事にすることが出来ずに
月日が経過していくのですが…。

今の案件で言えば、正直なところ開発しているシステムのターゲットは
私が心から歓迎するものではありません。むしろ憎んですらいる相手です。

そんなターゲットの為になぜ炎の真っただ中にいなければいけないのか、
そう思うことも多々ありますが、私はこれを一つの「試練」と捉えています。

好きなことを仕事にできればそれに越したことはありませんが、
会社という組織に属する以上、仕事は基本的に選べません。

そういった社会人としての経験や、
臥薪嘗胆と言うほどでもありませんが、今辛酸を舐めることで
私が本来目標としているモノへのモチベーションなどを得ている、と考えています。

今の案件を達成することで目標に一歩近づく、と考えると
どんなにつらい状況でもモチベーションを保てます。

「○○さんだけ元気です」という報告を隣の席のメンバーが上げるくらい、
私はモチベーションを保っています、むしろ生き生きとしているくらいです(笑)

感想

「プロジェクトマネジメント研修」という名目ではありましたが、
PMとして必要なスキルを学ぶと同時に、PMの下で仕事をする際に心得ておくこと、
たとえメンバーでも心得ておくことなど、様々な職位で活かせるお話を聞けました。

外部の研修も参加してみるもんですね。次回が楽しみです。

以上です。

スポンサーリンク