とにかく、次に案件探すときに、こんな事やってました、がPM同等か、それに近ければPM案件入れる可能性は全然あると思ってます💪

PMを目指す方へ⭐️

最近はフリーランスでPM経験ない方から、PM案件に入りたいけどどうすれば、的な相談も受けますので、それに関して。

以下のサイトはPMP取るための経験について説明していて、この辺も参考にしています。

PMとしての経験がなくても、PM同等の経験はプロジェクトに参画していれば得られるチャンスは結構あるのでは、と思ってます。

特に、プロジェクトが上手く回ってない場合は

🤩チャンス‼️

と捉えてPMを手伝ったり、積極的に動くと良いかと。

実際炎上案件は大変ですけどね😅

study-pm.com/service/elig...

大事なのは、これも面談で突っ込まれても実際やってるので堂々と答えられるという事です。

案件探しだけに使うのでは無く、常日頃から自分のスキルを向上させるために使うとより良いかと思います。

目指せ高単価🔥笑

2️⃣常にスキルシートを意識する

転職時や、案件探すタイミングでスキルシートの相談される方が10割ですが、私がクライアントさんや知り合った方に伝えているのは、『今の業務の中で、将来スキルシートに何を出したいか逆算して行動する』という事です。

言語等の技術的な事に関しては案件にもよるので難しい部分もありますが、

✅設計、ドキュメント作成
✅チームワークを重視した行動
✅コミュニケーション
✅会議をファシリテート、進捗管理
✅後進指導

等々、スキルシートに書けそうなワードを先に意識して行動する事で、次回案件スキルシートでアピールできる事が増えます。

オンライン面談だとカンニング出来ますし、対面の場合でも嘘書くわけではないので、ある程度準備して事前に確認しておけば普通に回答出来ます。

ちょこちょこスキルシート作成依頼が来るので、ざっくりですが個人的に重視している点を2点挙げます。

1️⃣スキルシートと面談はセット

スキルシートに情報詰め込み過ぎるとと読みにくい、というのは分かりやすいかと思います。

私の場合は、アピールポイントと、ある程度抽象的に、言い換えると概要的な内容を書いてます。

多分企業の担当者も事前に細かくはチェックしてないと思ってます。

むしろ、こう書いとけばこういう質問くるだろうな、という内容にして、答えられる準備をしてます。

スキルシート＋書ききれない具体的、詳細な部分のメモを用意しています。

▪️報連相
・聞かれる前、指示が来る前に先に報告、連絡する。
・敢えて質問する。
→これは結構コミュニケーションで重要なポイントだと思います。
特に、質問される=頼られている、なので嬉しく感じて関係性が向上する事は結構あります。
嫌な顔をする人もいますが😅
分かりきった事の場合は、念のための確認、と言う形で聞いてみると良いと思います。

逆に技術力特化でも、コミュニケーションに難があると、コロコロ案件変わるケースは厳しいかなと、個人的には思います。
ただし起業や独自のプロダクト開発には向いてそうです。

▪️スタンス
・他人の仕事をとっていく。
→まず、自分の仕事を早めに終わらせる前提にはなります。
この時、チャンスがあれば上位の設計工程やマネジメントの作業を手伝わせてもらうと、経験値UPし、キャリアアップに繋がる。
・全てをチャンスと捉える。
→周りが上手くいってなかったり、普段と違う依頼来たら、それもチャンスと捉える。
上司も先輩も、他の人が出来ない部分があるなら自分がやる。

▪️チャット
・1日数回は発言する。
→特にフルリモートだと終始無言状態だと仕事してるか疑われるかも。
・グループではなく個別で質問等行う。
→個別で相談等する方が信頼関係が生まれやすい。後々優しくしてくれたりも。

主にSES案件について、新しく参画する場合は、基本的にコミュニケーション力で大半はカバー出来るように思います。
転職した場合等にも活用できると思います。

もちろん、技術やルールのキャッチアップ、周囲に溶け込む能力、柔軟性が必要ですが、いずれにしてもコミュニケーションを積極的に取って仲良くなる、信頼関係を築くのがオススメです。

以下にいくつか思い付く行動を記載します。

もちろん、見れば分かるような当たり前のコメント（〇〇を△△回繰り返すのようなもの）は不要と思いますが、あまりに記述がなさすぎたので、せめてリーダブルコードに記載されているようなレベルでは記載して欲しいですが、業務委託の身ですので意見は言ったもののエンジニアのやる気を削がないためにもその場は引き下がりました。

PMとしては、進捗が順調であれば言わなかったと思いますが、現状製造部分で品質が良くなかったり進捗が遅れているため、小さな部分でも原因を拾って改善していきたいところなわけです。

最近で言うと、フリーランスで入ってるPM案件ですが、コードにコメントがほぼ無く、私はコメントは入れるべきだ、と言う主張でした。

習慣が無いのもあり、他のエンジニアは「コードを読みやすくしていれば基本的にコメントは不要」との意見でした。

私としては、「読みやすいコードにする事」、つまり変数名や関数名の付け方等ですが、それと「コメントを書く事」は独立して考えるべきで、どちらかがあればどちらかが不要とは思っていません。

以上です。
受託開発や自社プロダクトを扱っている企業の方でしたら案件やチームが変わる事がほぼないので問題ないですが、その中でもいずれは転職や独立、起業を目指している方にとっては大事な観点だと思っています。

▪️人間関係
これは最も重要と言っても良いと思います。
全く新しい環境、メンバーのいるチームに加わるので、相性が合えばめちゃくちゃやりやすいですが、合わなければ一生合わないままの場合もあります。

前述した内容が分からない場合でも、質問しやすい関係性が築ければ問題は解消しますが、そうでない場合は努力し、ストレスを抱えながら業務を続ける必要があります。

人によっては「エンジニアならこれくらい出来て当たり前」「自分で調べろ」「そもそもコミュニケーション取りたくない」
というスタンスの方もいますので、改善は難しいです。

もちろん分からないなりに質問の仕方の工夫や、最低限の努力はする必要はあります。

▪️開発ルール、組織ルール
お作法と呼ばれたりもしますが、開発プロセスや、コーディングルール等です。
そもそも資料やルールがなく、属人化しているケースも多く、この場合はかなり苦労します。

私も以前C#.Netの案件で、言語もフレームワークも5年以上経験してましたが、案件変更した際フレームワークのバージョンの違いやプログラムの構造の違い、仕様書が無い等、大いに苦労しました笑

知人はJavaでしたが、プログラミングスクールでは全く使用しなかったアノテーションを現場でバンバン使っていて付いていけなかったとも言ってました。

▪️フレームワーク、IDE、開発ツール
例えば、Java出来ます！となっても、Spring、Spring Boot、Struts等、Javaのフレームワークだけでも10種類以上存在します。
メジャーなものある程度絞られますが、それでも案件が変わると未経験のフレームワークを使う必要は出てくるかと思います。
この辺りは使い慣れるのにそれなりに時間が掛かる事があるので、面談等で説明がなければ質問した方が良いと思います。方の工夫や、最低限の努力はする必要はあります。

▪️管理、コミュニケーションツール
プロジェクト管理ツールの例としてはRedmine、Backlog、JIRAのようなものです。特にツールを導入してない場合はExcelやGoogleスプレッドシートを使う場合もあります。

コミュニケーションツールはZoom、Google MeetやSlackが多い印象ですが、ChatWorkや Skype等を使っている場合もあります。

管理ツールやコミュニケーションツールに関しては、使用経験がなくてもすぐ使えるようになるのでキャッチアップのハードルはあまり高くないと思います。

SESで10年以上、複数案件参画してきましたので、新しく案件に参画する際に気を付けておくべき事、言い換えればつまづきやすい事をピックアップします。
開発言語自体が変わるケースについては言うまでもないと思いますので割愛します。

未経験でIT転職を検討している人や、プログラミング学習中の方等には特にお役に立てればと思います。