エンジニア初案件の振り返りをする
簡単な振り返り。
私は2021年12月に6年半ほど勤めた大手鉄道会社を辞め、2022年1月にWeb系の受託会社に入社しました。
今回は入社後、初めての案件にアサインされた時のお話です。
研修を終えて待っていたのは別世界だった
研修ではperlとjavascriptがメインでした。
業務でよく使われているのがこの2つだからです。
その他周辺知識も勉強しつつ、約2ヶ月で研修を終えました。
研修終了時点で時期は3月。年度末でみんな納期と呼ばれる地獄と彷徨っている顔をしている。
私はなんの業務アサインされるのか…。
申し訳無さと期待半分で待っていました。
すると、一人の先輩が私のところにやってきてこう言いました。
先輩「君。研修は終わった？」
私「はい。まもなく終わるところです」
先輩「ちょうどいい！じゃあ俺の案件に入ってもらおうかな！」
私「（おっ！ついに初案件が！）私でよければ！」
先輩「それは頼もしい！」
先輩「Pythonやってもらうからよろしくね」
私「はい！・・・・・・ん？」
パイソン…？。蛇かな？
冗談です。Pythonは流石に聞いたことあります。データ解析やAIで優秀なやつっていうイメージ。触ったことないけど。
先輩「ちなみにFastAPIっていう社内で誰も使ったことないフレームワーク使うけど、まあいけるっしょ！」
FastAPI？
え？社内で知っている人いない？
急に初案件はFastAPIを使ったBtoB向けのAPI構築に決まりました。
ちなみに社内で知見がある人は目の前にいる先輩だけ。
あれ、研修でやったjavascriptは？perlは？…
そんな事を言いかけた時
先輩「君はこれから俺のチームに入ってもらうけど、このチームperl一切使わないと思ってもらってOKだから（満面の笑顔）」
Oh…
ゼロから始めるPython生活
というわけで無知識から発案件がスタートしました。
まあ、案の定壁にぶつかりました。
特にきつかったこと3つ紹介します。
Pythonの書き方をしらない
当然ながらPythonの書き方を知らない私。
すでにある大量のコードをみて目が点になります。
私「なんやこの書き方…」
さらに追い打ちをかけるのが時期。3月は納期とのの戦いを迫られます。
（幸いこの案件は年度明けも続く案件だったので結果的に納期ギリギリの戦いではありませんでした）
時間と未知の領域。この２つが一気にのしかかってきた状態です。
FastAPI以前にフレームワークが理解できていない
使用技術にFastAPIというPythonのフレームワークをつかったAPIの構築でした。
実務初経験の私。当然のことながらフレームワークなんて知りません。
ただ、仕事なので知らない。できない。わからないは言い訳にしかなりません。
初案件でも一人のエンジニアとして仕事することが求められます。
Pythonの書き方を覚えつつ、期限が長くない中でいかに覚えていくかが勝負の鍵を握っていました。
今考えると一番頑張っていた時期かもしれません。今も頑張っているけど。
周辺知識が圧倒的に足りない
Pythonの学習を進めていく上で一番苦労した点だと思います。
例えばこの辺
pip, pipenv, pyenv
docker
git
sql
webサーバ（Apache, nginx）
特にPythonでよく使うpipや今回の案件で覚えたpipenv, pyenvあたりは概要、環境構築、使い方まで一通り覚える必要があり、苦労したのを覚えています。
gitやdockerは研修で勉強しましたが、当然実務で使っていくのは初めて。
ビクビクしながらコミットした記憶が蘇ります…笑
メンタルを支えていたのは先輩の存在
こんな感じだったので案件スタート時は不安しかありませんでした。
そんなメンタルを支えていたのは先輩でした。
技術力が高く、私の初歩的な質問にも笑顔で答えてくださったり、豆知識や概念的なお話もしてくださりとても感謝しかありません。
尊敬できる先輩に巡り会えたのが最終的に私の心を燃え上がらせました。
私「よっしゃ！PythonだろうがFastAPIだろが関係ねえ。やるぞ！
（ドン！！！）」
どう乗り越えたのか
ここまでただ苦しい話をしてきました。
ただ苦しかったかと言われるとそうではなく、ワクワクしていた気持ちのほうが大きかったかもしれません。
実務経験が積める
ここで言語を習得できれば活躍の場が増える
単純にPythonを触ってみたかった
これらのちょっと不純な動機から仕事は案外楽しくやっていました。
（勿論、残業や休日出勤もたまにしていました。納期近いから仕方がないね）
ここからはどうやってこの局面を乗り越えたかを紹介します。
最短で覚えて最多で出力
まずはPythonの基本文法。
これを覚えないことには始まりません。
私は考えました。
今から本を買って勉強したところで間に合わないぞ…。
じゃあどうするか。
…！
わたしは閃きました。あのサイト使えばええやん。
皆さん一度は使ったことあるだろうあのサイト。
そう、Progateです。
まさか実務経験に入った段階で使うことになるとは思ってもいませんでした。
3時間あればサクッとPythonの基本文法は習得できます。使わない手はない。
未経験時代もProgateにお世話になりましたが、間違いなく過去一番有効活用できた瞬間でした。
ありがとう。Progate。
基本を抑えたら後は実務。
私の場合、こんな感じで業務を進めていました。
わからないこと、使い方が不明なライブラリがでてきたら使い方を調べる
公式ドキュメント読んだり、先輩に聞いてみたり…。試験用のスクリプトファイルを作成。ライブラリを使った簡単な処理を書く。
デバッグしながら動作を確かめる。
実行したらどんな値が返ってくるのか、実行前に仮説を立てるのを心がけていました。
想定と違う値が返ってきたら、なぜ違う期待値と違うのか考えてから公式ドキュメントを見て回答を探します。実務コードに戻って修正を加える。
壊しても問題ないスクリプトファイルを一個作ってその中で試すことを心がけていました。
別ファイルに書くことでコメントを残したままコミットしてしまうこともないので安心です。
フレームワークや環境構築も同様です。
とにかく1~4の手順を使って最短で覚える。
環境を自分で一から作ってみてひたすら触ってみる。
自分の環境なので壊れても問題なし。また作り直せばOK。
起床から出勤までの時間や、休日は家で環境を作ってデバッグしながら動作確認を続けました。
ここらへんから【調べながら何とかしていく】。自走力がついてきたなと思います。
そんなこんなでトライアンドエラーを繰り返しながら案件を進めることができました。
その後どうなったか
この案件を終える頃のわたしはこんな感じ
私「…気づいたら社内で一番Python触っている人になっていた…」
そう。案件に入る前に思っていた社内で使える人材に近づいていたのです。
そして、他の人に教える機会もでてきました。
Pythonの書き方
環境構築手順(pipenv, Docker, rye(これは最近です))
案件が終わる頃にはPython全然わからん人からほんの少し触れる人になりました。
今も絶賛勉強中ですがあの時折れなくてよかったなと思っています。
その当時支えになっていた先輩とは私が退職するまでタッグを組んで仕事をしていました。
この経験から何を学んだか
この経験から私は大きな収穫を得ました。
未経験から転職する方や、私と同じようにエンジニア歴若い方は参考にしていただければと思います。
先輩エンジニアの方には当然の内容だと思います…。
まあ若い端くれの意見です。気楽に目を通してください。
ちょっと多いですが5点にまとめました。
人間追い込まれるくらいが丁度いい
人が変わる理由って色々あると思います。
私は人が変わる瞬間の一つは【追い込まれている状態】だと今回学びを得ました。
表現を変えるなら【やらざるを得ない状態】でしょうか。
今回、期限が迫っている中で一からスタートする状態。
普通なら諦めたり、期限を延ばす事を考えますが、これは仕事なので延ばせません。
待っているお客さまがいます。
退路を絶たれた私。あの時はとにかく集中して仕事をしていたと思います。
適度なストレスを感じているときのほうが集中できるなと体感しました。
（勿論、過度なストレスは心を壊すのでほどほどに…）
目的がある勉強をするべき
どう乗り越えたかの部分でProgateを使った話をしました。
これまでProgateを使っていたのは、未経験で何から始めたらいいか分からない時。
みんなこの道を通ってきたから自分もやる。みたいな感じでした。
今回は違います。
案件で必要になったから使った。
つまりProgateをやるという目的ではなく仕事を遂行するための手段として使ったわけです。
Dockerやgitといった周辺知識も一緒です。
未経験期間中は必要って皆言っているから…。なんとなくやっていました。
案件にアサインされた時は今必要な箇所を抑えるように。
情報の取捨選択を行うようになります。
目的がない勉強ってあまり意味ないなと思いました。
（趣味としての勉強は除きます）
勉強したところでそれを発揮できる機会がなければ、モチベーションだって下がります。
勉強するというのはある目的を遂行するための手段である。
勉強のための車輪の再開発は意味ある
車輪の再開発とは広く受け入れられ確立されている技術や解決法を無視して再び一から作ることです。
これについては賛否両論ありますが
私はどういう仕組みで動くのか試すという意味ではありだと思います。
例えば今回の案件ではすでにあるDocker環境をいただけばすぐに開発できる状態でした
しかし、休日にあえて自分で一から再現してみるということをやっていました。
まさに車輪の再開発です。
頂いたDockerFileのコマンドを一行ずつ処理を消してどんなエラーがでるのか試す。
処理を確認したらコンテナを一から作成してみる。
そんな感じですでにあるものを解体しながら動かし
もう一度組み立てるという作業をしました。
この解体してもう一度組み立てる作業の中に強烈なインプットとアウトプットが潜んでいることに気づきました。
そもそもこのコマンドってなんのために書いてあるのか。
これはどうやって調べれば出てくるコマンドなのか。
興味を駆り立てられると同時に気づいたら熱中して色々いじっている私がいました。
車輪の再開発を終えた頃には自力でDocker環境を構築できるようにもなりました。
すでに会社であるものを自分の環境下で色々触ってみることの大切さを身につけました。
公式ドキュメントから逃げない
エンジニアの方が常々言う【公式ドキュメントから逃げるな】の意味を理解したのもこの時です。
環境構築
使い方
エラー対応
基本的にこれらは公式ドキュメント見ればだいたい解決しました。
また、githubに有用な情報や解決したい質問が書いてあることもありました。
これを気に調べる順番が変わり
公式ドキュメント
GitHubのwikiやissue(場合によってはコードも読む)
Qiitaなどの技術ブログ
本
みたいな感じになりました。
2024現在は、公式ドキュメント読んだ後にChatGPTに投げてみる手段が追加されたように思います。
便利になったもんだ。
私の英語力は小学生レベルです。
ただ、ドキュメントで良くでてくる単語さえ覚えればなんとなく理解程度読めますし、
日本語翻訳にかければだいたい何言っているのかは理解できます。
公式の存在の大きさを改めて感じました。
知らないことを恥ずかしがらない・ミスすることを恐れない
いわゆる完璧症候群にならないことです。
どんなに自分の中できれいにコードが書けても、先輩からみたら足りないところがたくさんあり指摘されます。
【結局やり直しになるのであれば早い段階でフィードバックをもらう】ということを学びました。
知らないこと、理解が浅いことはどんどん調べる・質問するべきです。
「〇〇の〇〇が分からない。〇〇までは調べて〇〇だと思っている」
分からない点と自分が調べたこと。自分の推論も一緒に伝えるとなお良し。
認識が違う時はそこから先輩が教えてくれます。
質問の質を上げるということもこの案件を通じて学びました。
当時この案件を担当してくれた先輩は技術力も高く優しい尊敬できる先輩でした。
職場で尊敬できる方がいる環境にも大変恵まれたのも要因だと思っています。
メンタルが安定し、気軽に会話することが出来ます。
だから、先輩がどう仕事を進めているのか、どんなコードを書いているのかといった技術部分を吸収することができます。
育ててくれた先輩に感謝。（同時に退職してしまいすみません…）
今は私がそんな先輩になるために邁進中です。
結論： 未経験エンジニアよ。自分と周りを信じろ。きっとなんとかなる
まとまりがない振り返りになりましたが結論です。
最終的に何とかなります。
実務未経験の方。ご安心ください。
といっても毎回追い込まれてからスタートするのは良くないです。
私は環境に恵まれていたので良かったですが、こういった現場だけではないはずです。
最近は本来の締め切りのもっと前に締め切りをおいて、序盤に8割やりきるロケットスタート術で開発することを心がけています。
ロケットスタート術は中島聡さんが書かれている本です。
Microsoftで社ドラッグ＆ドロップやダブルクリックの概念を設計した方です。
（いつ見ても著者略歴が強すぎる。）
今回はここまでになります。
最後まで閲覧いただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？