2025/05/02 (追記)
思いつきで書いてみた記事が、自分の予想よりは皆様の反応がよかったため、少しだけ追加、修正させていただきました。
特に項目「4.問題の細分化」を追記してみましたので、既にご覧になった方も寄っていっていただけると嬉しいです。
はじめに
こんにちは！
先日、「Qitta Conference」に初めて参加させていただき、様々な生い立ち、キャリア、立場の方々のお話を聞かせていただきました。
色々なお話を聞く中で、こういう業務、技術、考え方があるんだと勉強になることがたくさんありましたし、一方で大変共感する内容もありました。
私もなにかQiitaに投稿したい！と考え、「エンジニアに必要なマインド」というタイトルで記事を執筆しようと思った次第です。
読者対象
特にいわゆる駆け出しエンジニアさん、経験1,2年ぐらいの方に向けて書きたいと思います。
もちろん、中堅、つよつよ、ベテランエンジニアさんも共感、追加の内容コメントなどいただけると嬉しいです。
私の1,2年目頃の失敗や、間違っていた(と思っている)考え方、エンジニアマインドについてご紹介できたらと思います。
自己紹介
まずは、簡単に自己紹介をさせてください。
大学卒業後、新卒でとある金融機関に就職し、1年9ヶ月ほど従事しました。
金融機関で働いている中で、将来に不安を感じるようになり、エンジニアを目指すことを決意しました。
(色々理由はあるのですが、ここは脱線しそうなので、割愛させてください)
金融機関在籍中に某プログラミングスクールにて6ヶ月間学習し、A社から内定を頂き、エンジニア転職を果たします。
1年と少し経ったタイミングで現在在籍中のB社へ入社しました。
A、B社共に業務でWebアプリケーション開発を行っております。
エンジニア歴は4年目となった、27歳です。
なぜこの記事を書こうと思ったのか
この記事を読まれている皆さんはエンジニアをやっていて、楽しいでしょうか？
私は今、エンジニアとして楽しく働けています。今は！！！
上記の書き方でお察しの通り、最初の数年は苦しい思いをしました。自分は頑張っているのにうまくいかない。そんな気持ちで自分自身を押しつぶしていた時期がありました・・・
失敗マインド
ここからは、私自身が失敗したと思う考え方、マインドを紹介します。
1.完璧主義
今、昔の自分を思い出すと、これが特に成長の邪魔していたと思います。
完璧を目指してはだめです。声を大にして言いたい！
私はプログラミングスクール6ヶ月間+会社の研修を経て、業務系アプリケーションの開発にアサインされました。
その際、以下のような状態や思考と直面していました。
- 状態
- なんやこのツール。使い方わからん。
- 環境構築なにしてるんや、、、ていうか、エラー出てるけど何がどうなってるんや。
- わからんこと多すぎて、なにから聞けばいいんだ？それより、なにを聞けばいいんや？
- 思考
- エンジニアは自己解決が大事や！とにかく調べて解決しないと！
- 周りのみんなは自走して進められてるみたい。自分もできるようになるんや！
- できない人だと思われたくない。
プログラミングスクール時代や、SNSでよく目にする「エンジニアは自分で自走できなければいけない」「自分でエラーを解決しなくてはいけない」という決まり文句。
そんな言葉がどんどん自分を苦しめます。焦りも大きくなります。
また、失敗を恐れ、わからないことを聞けず、余計に理解が進まない悪循環・・・
大大大真面目にやっているからこそ強く感じてしまう、自分できない感。
私は自身の真面目なところが良いところでもあり、悪いところでもあると思います。
自分ができないことを責めなくていいです。大事なのは捉え方です。
できない自分ばかりに焦点を当てず、乗り越えた先の成長を見ましょう。
確かに最初から業務のすべてをできることに越したことはないです。
ただ、自分を含め、ほとんどの凡人は最初からエンジニアとしての業務を当たり前のように進めることはできないと思います。
失敗したっていいじゃないか！昔の自分にそう声をかけてあげたい。
歴が浅いうちにチャレンジし、失敗して、そこから色々学んできた人の方が得られるものは多いと思います。
(エンジニアとしての歴が長くなればなるほど、聞きづらい雰囲気になってくるらしいですヨ・・・)
2.期日に間に合わせることから起因する、焦り
期日を守るのって大事ですよね。
これはエンジニアに限ったことではなく、働く上で期日を守るのは大事なことです。
期日が遅れることで、チームに迷惑がかかる。さらには、お客様にも迷惑をかけてしまう。
当時の私は以下のような状態になっていました。
～とある機能の実装時～
- 状態
- あと期間、1日か。。。5日やったのに、まだ半分終わってないわ。。。
- なんやこのメソッド、何しているかようわからん！
- とりあえずこれがやりたいこと実現してるみたいだから、コピペしよう！
- 思考
- とりあえず間に合わせないと！
- 毎回理解してたら、いくら時間あっても足りん！
正直なところ、間に合わせるには上記をしないといけない場面もあるかとは思うのですが、
何と言っても身にならない。これに尽きます。
また、焦っている状態でエラーが出たとき、とにかく間のすべての手順をすっ飛ばして、1発で解決しようとする。
上記をしようとすることが自分はよくありました。
解決するのであればよくない？そのように思うかもしれません。ただ、エラーの解決には、以下のように手順を踏むことが大切だと考えます。
- エラーの内容、原因の把握
(ログに〇〇というエラーが出ている！△△ソースの15行目だ！) - エラー箇所の特定
(✕✕メソッドで引数にnullが渡ってきている！本来はユーザIDの値が渡ってきているはずなのに！) - エラーの直接原因の特定
(なぜnullが渡ってきているか？どこで渡ってきた変数の情報が格納されるべきなのか？) - 仮説を立て、どのように修正を行うかを考察
(✕✕メソッドの引数は元々、画面のリクエストで渡ってきている。そこがnullなので、View側のFormタグの記載に誤りがあるのでは？) - 仮説、修正を元に修正を実施し、挙動の確認
(Formの記載のname属性が「userId」ではなく、「user_id」になっていた！ここを修正してみる。) - 解決しなければ再度1の手順に戻る
私は、上記1 ~ 5がなかったんです。とにかく心当たりがある箇所を直して、下手したらエラーを確認せず・・・(白目
それを飛ばしてしまうと学びがないんです。
落ち着いているときはできているんですが、追い込まれたときはできていないことが多かったように思います。
結果として・・・
私は理解不足のまま初めての案件を乗り切ったせいで、「結局何をしたんだ・・・？何を得たんだ・・・？」で終わってしまいました。
成長の「せ」の字もなかったように思います。
もったいなかったなぁ。。。
期限に追われすぎても、良い成果は出ません。焦って作業したところで、ミスが多くなるだけです。
進捗報告を怠らなければ、仲間や上司がきっとサポートしてくれます。
今はサポートされる側でいいのです。
素直にアドバイスを聞き入れ、助けてもらい、その後、力をつけてgiveができるエンジニアになりましょう。
3.目的がわかっていても、それを解決する手段を理解していない。
～とある環境構築での出来事～
- 資料にこのソフト入れろってかいてある！(何をしているかはわからんが)とりあえずいれよう！
- 〇〇さんがこの設定が必要って言ってたな！まずは設定しておこう。
当時の私はこのソフトが何をしている、設定がどんな意味なのかなどを理解しないまま進めていました。
これだけを聞けば誰でも「何をやってくれてんだ」と言いたくなると思います。
なぜこのようになってしまったのかを私は考えました。
私の結論は 「目的が環境構築をする」 で止まっているからだと思います。
私の場合、 「環境構築をする(目的)ために何が必要なのか(問題)」 がわかっていなかったのです。
もっといえば、 「そのインストールしたソフトがどんな問題を解決してくれるのか(どんな手段なのか)」 それを理解せずにしていたのが、、、はい、私です。
反省し、今は・・・
今となってはあっっっったりまえなんですが、わからないことは調べる。
せめて、自分がいまどんな操作をして、それがなんの意味があるのかぐらいは理解して行う。
昔、表示された警告ポップアップをろくに読まずOKを押したら先輩に怒られたっけ。。。
もし、仮に理解しないまま様々な操作をし、エラーになってもあなたが何をして、どのような状況になったのか教えてくれないと、どんな人でもアドバイスに困ってしまいます。
前提(あなたが行った操作)が違うと、どれだけ賢いAIさんでも間違えて回答を生成してしまいます。
4.課題を細分化できない
これ、私は今でも焦り始めると、この状態に陥ります。(反省)
あまり文言を見てもイメージが沸かないと思いますので、例を出します。
あなたは、勤怠入力のアプリケーションを作ろうと考えました。
あなたの思考
さあ！作業するぞ！
アプリを作るぞ、、、アプリを作るぞ、、、！
この考え良くないです。特にエンジニアをする上であまり良くない考え方だと思います。
上記は極端な例ですが、「アプリケーションを作る」という課題にはさらに細分化していくと、解決しないといけない細かい課題がたくさんあるのです。
例えば・・・
- インフラ構成はどうするか？
- （例：オンプレミスサーバーを使うのか？ AWSやAzureなどのクラウドを使うのか？）
- 画面はどのように作るか？
- （例：HTML/CSSとJavaScriptで作るのか？ ReactやVue.jsのようなフレームワークを使うのか？）
- バックエンドの構成はどうしようか？
- （例：Spring BootやDjango、Express.jsなどのフレームワークを使うのか？）
- DBMSは何を選ぶか？
- （例：ユーザーデータを扱うならPostgreSQLやMySQLにするか？セッションやキャッシュ用途ならRedisを使うか？）
上記のように課題を分解することで、当初の「アプリケーションを作る」よりは少し見晴らしがよくなり、やるべきことが具体化されたのではないでしょうか。
このように、自分の目標達成のために、やるべきこと(課題)を少しずつ解像度を上げていくことが大切だと考えます。
これは、日々の設計や、実装、テスト、はたまた、エラー対応等の作業でも同じことが言えると思います。
もう一つ、「FTP接続し、ファイルをダウンロードする機能を実装する」という状況を考えてみましょう。
上記を実装する場合・・・
- FTPの接続情報はどうなっているだろうか？
- なにかFTP設定情報が必要なのではないか？
- FTP操作のためにはどんなクラスを利用できるのだろうか？
- 取得したファイルはどこに格納しようか？
- 認証に失敗した場合、FTPサーバはどのようなレスポンスを返すのだろう？
- エラーのハンドリングはどうしよう？
- etc...
などなど、考えれば考えるほど出てきます。上記で記載した項目でも、更に分割して細かい問題を見つけることができるでしょう。
しかし、FTP機能を実装する！と考えるより、上記のように分割したほうが自分のやるべきことが見えてきますよね？
言葉で言われるとそりゃそうだと思うかもしれませんが、私はそれができていなかったり、分割はできていても一つずつ順序立てて、対応できていないことがよくありました。
あれもやらないと！これもやらないと！・・・そんな気持ちのせいで近道しようにも、遠回りをしていたような気がします。
人間器用にいくつものことを同時考えることができないです。特に私のような凡人は。
課題の細分化を行い、自分が何をするべきか明確にした上で、一つずつ対応をするのが一番の近道であると思っています。
5.成長を感じない
(マインドとは少し離れてしまうかもしれませんが)
私は2年半ぐらいまで成長を感じない感覚がありました。まったくないわけではないんですけどね。
プラトー理論っていうのがあるみたいです。
プラトー理論 (Plateau Theory) 最初はなかなか成果が見えず（停滞期＝プラトー）、努力を続けるとある時点から一気に成長し始める
ある時期からまさしく「点と点が結ばれ、線になる」を感じる様になりました。
エンジニアは必要とされる知識の幅が広いが故に、線で物事を捉えることができないことが多いと感じます。
とある業務で手順を1から10まで細かく教えてもらっても、次のプロジェクトでは役に立たなかったなんてことがあるのではないでしょうか。
土台となる知識があるからこそ見えてくる景色も変わってくるように思います。
同じ情報に触れても、3年前の自分と今の自分では考えることや、受け取り方が全く違うと思います。
私は2年半ぐらい経ったタイミングで大きな成長を感じることができました。
逆に言えば、数年は成長を感じず、苦しいかもしれません。ただ、あまり悲観的にはならず、日々こつこつと知識を蓄えていってほしいと思います。私も頑張ります。
最後に
いかがだったでしょうか。
現状の自分のマインドで当てはまる事はありましたでしょうか。
見返すと、自分、良くないマインド持ち過ぎなのでは・・・？笑
そんなことを思ってしまいました。
私自身、よくないマインドを完璧に払拭できている訳では無いですが、理解しているだけでも違うと考えます。
あまり記事を書くことになれていないので、不慣れな部分もあったかもしれません。
文字ばかりで読みづらい記事なのが少し反省です。
また、技術の記事とかもかけたらいいなと考えています。
投稿頻度は多くないかもしれませんが、温かい目で見ていただけると幸いです。
Xやっておりますので、交流できたらありがたいです。
QittaのXへのリンクからぜひ！
ご覧いただきありがとうございました。