0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

本稿は筆者の体験であり、全てのフリーランスエンジニアを代表する話ではない事を留意されたい。

フリーランスになるとこういう状態になるよ、というお話。
年間スケジュールを公開している方の情報はあまり見ない気がするので、もしかしたら貴重資料かもしれない。
筆者の場合、1〜6月は講師業、7〜12(翌年3)月はエンジニアリングという流れになるのが多いが、今年は色々なイレギュラーが発生してしまった。

その中で、得たものもあったので共有したい。
これは「今うまくいっている全てのエンジニア」にこそ、知ってほしい。
また、エンジニア研修やOJTなどで新人指導をされている方にも考えていただきたい内容になっている。

まずは冗長な部分が多く恐縮だが、本稿はエンジニアらしく「なく」感情面を表に出していきたい。
これもまた、今までなんだかんだうまくいった経験しかしてこなかったフリーランスエンジニアのリアルである。

1月

毎年この時期は外に出て何かやる、ということがあまりないが、こと勉強会という意味では今年は全くなかった。
毎年12月にストレージの大掃除(整理)をして、その後に経歴書に1年分の活動を書いていく、という事をメインにやっているので対外的には何もやっていないように見えてしまうのがこのタイミング。
合わせて、確定申告もあり勉強会どころではない、というのが正直なところ。

また、4月からの研修案件の準備期間でもあるため、この時期は何かと忙しいことが多い。
今年に限って言えば、ゲームのリリースに合わせてのQA業務に従事していたため、全体的に炎上。
来年こそは静かな新年を迎えたいものだ。

2月

確定申告の山場。いわゆる生産活動ではないのと、頑張っても報われない(収入は増えない)上に一人で作業をするのでモチベーションがダダ下がりする時期でもある。
傍目に「税理士に丸投げすればええやん」とか「写真撮ってシステムに反映すればええやん」とか思ってた頃もあるが、実際問題として何をしていた時の領収書なのかは自分しか分からないので、逐一備考欄に書いていく作業が必要なので事実上一人でやってるようなものである。
こればかりはただひたすらに打ち込んで、撮り忘れを防ぐ意味でも物理的な意味でも領収書の山を減らすしかない。

こういう作業を辞めたいんだけど、システムではどうにも出来ない(特に備考欄を埋める)という運用上の課題がある。
本当に何とかしたい。

この辺りでQA業務も落ち着く。
本当は終わってないけど、契約の都合上、確定申告に集中したいので期間終了している。

3月

確定申告を出したらちょっと早いゴールデンウィークを楽しむ。
具体的には、12〜3月上旬まで勉強会に参加できなかった分、とりあえず遅れた分のインプットをする。
今年に関して言えば、ChatGPTの話題が爆発していたので関連情報を収集して回る作業が一番重かったように思う。
確定申告よりはよっぽどマシ。

今年の目標として「去年までの研修対象ではなかった層にもリーチする」としており、早速業界大手の力を借りて知見を広げていた。

4月

去年もお世話になったクライアントにて、別エンドの研修講師として登壇。
研修自体は4月中旬からだったので、講義設計の傍らハッカソンなどにも参画。
早い時期から「研修が終わったら現場に入れるよ」という環境ではないことと、研修で学んだ内容の発展・応用系として実務があるので、研修以外の内容も積極的にキャッチアップするために勉強会を見ておこう」という話をするために種類を選ばずに市場調査。

とはいえ、普段からこういった活動をしているので、積極的に頑張らなくても情報は持っているので多少サボっても筆者の経験値的に問題はない。
勉強会参加は、もう半分趣味みたいなものである。

今年でいえば技術系(セミナー・ハンズオン)とキャリア系で半々ぐらいの比率で参加している。

5月

振り返ってみるとやけに少ない。
→書いていて思い出したが、環境構築の問題と成績が2極化してしまってサポート講師の方々とほぼ毎日作戦会議をしていたように思う。
講義について来れなくなる新人の方は毎年一定層は出てきてしまうのだが、こういったグループへのケアやフォローアップは厚めに行うことで、成功体験に変えてうまく自信をつけてもらうようにしている。
のだが、年々「これは何のために学ぶのか」という点に意識が向かなくなっており研修中に目的を忘れやすくなってしまっているのかもしれない(と、メモに書いてあった)
特にタイパ思考が年々強くなっているため、今までの講義時間(1コマ60〜90分)が長すぎるように感じるのかもしれない。
集中力が続く人と、そうでない人とに目線を合わせて講義進行の緩急も考えなければならないが、新人ごとの「後でまた出てくるので少しずつ覚えよう」と「後でまた出てくるから今覚えておかないと苦労するよ」の考え方の違いも浮き彫りになっているような気がする。
素直なタイプだと前者を勧めても受け入れてくれるが、後者で頑なな傾向がある場合が多少扱いが難しい。

6月

通常の研修だと受講者の作品制作の期間なので暇になるはず、だが今年は忙しかった。
テストの点は取れても肝心の実技面(設計と実装)については懸念通り弱かったようで「未経験だから」とか「経験者だから」という言い訳をする受講者が一部発生してしまった。
この段階においては未経験・経験者という枠組みはあってないようなものなので、本人の気質やエンジニアという職業に対する考え方のギャップがあったのかもしれない。
来年はこれを解消できるように「教材に書いてある内容を覚えることではなく、色々な人に現場経験を聞いて、自分で「この研修期間中でなければできない事」と「研修期間後でも勉強すれば分かる事」を切り分けてもらうよう注意喚起をした方がいいかもしれない。
毎年同じ事を言っているようにも思うが、来年の受講者は今年の受講者よりも目的意識が希薄になる事を想定して、ロードマップを明確に設定してあげる事が重要になるだろう。

こんな状態なので勉強会どころではない。

7月

本来であれば遅くとも6月までの空いたタイミングで当月からの契約に向けて動いたり、10月まで長い夏休みを楽しんだり、という計画を組む。
今年はライフイベントがこの時期にあり、後者を予定していたのがたまたま当たったように思う。とても契約までやって案件稼働して、という余裕が4月〜からなかったため、前者計画だと焦っていたところだ。
とはいえ、10月に向けての相談で動き出す必要があったことから、勉強会がリクルートを兼ねての活動の場となった。

コツとしては、リクルーティングを目的にする場合は懇親会のあるオフラインイベントで登壇すること。
リファラル採用は強い。
おかげで、ゆるーくお付き合いできるクライアントとマッチングする事ができた。

8月

おかげさまで無事ビッグイベントを迎え、10月に向けて案件相談を活発化させていく。
リファラルだけでは遅いので、繋がりのあるスカウトエージェントにも連絡してガツガツやったのがこの時期。
とはいえ、自主的に時短稼働に努めていたため対外的には稼働少なめ。
月の後半には勉強会だけでなく説明会などにも顔を出して、自分を売り込む範囲を広げていく。

9月

おかげさまで優良契約を獲得し、活動にもご理解をいただけたので積極的に拡大対応をしていく。
勉強会にやたら参加しているのは方々へのご挨拶を兼ねたリアルイベントと、多くのEXPOが開催された頃だったので対外活動が増えたため。
ちょうどこのタイミングで教育からオンボーディング全般、特に採用にも噛ませていただくこととなった。

10月

先方で故あって失注となってしまい、大慌てしたのがこの頃。
先月の案件相談で契約のお断りをしてしまった手前、お付き合いのあったクライアントやエージェントに相談しにくくなった。
が、悔やんでも仕方ないので別ルートで積極的に売り込みし、人脈を拡大していく。
この頃には短期という条件が厳しすぎてエンジニア一本では難しいと判断し、職種の制限を取っ払っていく。
こうすると案件もあるところにはあるので、もし強い拘りがなければ営業に失敗した(自己都合だろうが先方都合だろうが)フリーランスは、ブランクを作らないためにもやれることはやり続けるしかない。
これが会社規模だったら、と思うと非常に辛い。

11月

9月からに引き続いて、勉強会の参加数は凄まじい。
エンジニア職に拘らない、という形で間口を広げたものの、やりたい仕事ではない事は変わらない。
改めてエンジニア職は筆者にとってやりたい職種かつ高単価だったんだな、と思い知らされる。
実際、一度天職を味わうとそれ以外の仕事についてはあまりモチベーションが上がらない。ましてや、苦手分野であり低単価ともなるとますます心理的抵抗が大きい。

が、この経験を積めて良かったと振り返っている今は思う。
ちなみに、この案件については執筆時点では現在進行形だが、いわゆる「リスキリング」を強制されてしまった社員または求職者の方は今の筆者の気持ちや感情で学んでいる可能性があることを認識した。
教育とは「受けたいから学ぶ」のではなく「仕方なく学ぶしかない」という状況が、少なくとも「リスキリング研修を受ける受講者」には存在するという事だ。
これは、今まで私が指導してきたエンジニア研修では考えなかった事なので、教育をプラス面で捉えられているうちは良いが、マイナス面(やらなければならないこと)で考えているうちは研修効果など望めるわけもない。

12月

今本稿を認めている時点で12月の半分が終わったぐらいだが、現時点ではエンジニアらしい活動はアドベントカレンダーを書いているこのタイミングぐらいだ。
他は何もしていない、とは言わないが開発に熱を入れていた時点と比べて不燃焼感はかなり強い。

とはいえ、毎年この時期は案件も収束気味で、空いた時間はストレージの棚卸しをしたり確定申告に向けて書類整理をしたり、という時期なので暇という感覚はない。
(情けない話で恐縮だが、本稿執筆時点では毎日の書き溜め記事を捌くに至っていない)

当月は案件もほぼ決まって稼働も安定しており、リアルイベントよりはオンラインセミナー中心である。
残念ながら稼働がエンジニア職ではない分、勉強会参加のハードルが上がったように感じるが、初学者や異職種の方はもっとハードルが高いのだろう。

全体所感

本年まででも、筆者個人としては「(運用)現場主義意識を持ち、システム運用ベースの開発を心がける」意識はしていた。
が、本年の後半の経験から、本当の意味で運用現場に立ってシステムを見直す機会になったので「仕様です」という言葉の意味、その重さ(運用負荷や技術的負の遺産を残すという判断をする事)を改めて認識する事となった。
また「システムではどうしようもない事」こそ、現場でどのように判断し対処するかという議論が開発現場でされていないのは問題だと感じた。
本当の顧客目線のシステムは「システムでどうしようもない事をどうやって運用対処するか」という点も意識して開発がなされるべきではないだろうか?

業務システムの例で考えてみると、80%の業務をシステム導入によって負荷削減を試みるという現行の流れ自体は否定しないが、残りの20%についてどのようにシステムに反映させるか、という点について運用と議論しているイメージがない。
とりあえず項目を用意して自由入力にして、あとはよろしくやってくれ、だとDX推進という観点からもよくない。
データを集計しやすいようにする、というネクストアクション(データ利活用)まで見据えるシステム開発ができるのが理想であるため、開発現場に現場運用・QA・データサイエンティストの知見も必要になってくるだろう。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?