【体験談】初心者エンジニアの悩みを解決した、アドバイス5選

文系の大学生からシステムエンジニアになって、10年以上経ちました。

これまでのキャリアを振り返ると、順風満帆ではありませんが、周りの先輩エンジニアのアドバイスによって、何とかキャリアを歩んでこれました。

ということで、今回は新人エンジニアの頃に、先輩からもらった金言を紹介します。

この記事を読むことで、「エンジニアとしてのキャリアを今よりも楽に進めるように、また仕事に対する考え方や姿勢が変わる」と思います。

ソースコードを理解したいなら、データの流れを意識したら良いよ

「ソースコードを理解したいなら、データの流れを意識したら良いよ」と先輩から言われました。

これは3年目でまだプログラミングのことを理解していない時に、一緒にプロジェクトをしていた先輩から頂いた言葉です。

システムエンジニアになって3年経過しているので、プログラミングを学んである程度の文法は理解出来るようになっていました。しかし、会社で開発しているような大きなシステムのソースコードを見てもあまりピンと来ず、頭の中がパニックになっていました。

多分、最近システムエンジニアになった人であれば、共感する悩みだと思います。

そんな感じで一人で「ぜーぜー」と言いながら、ソースコードを眺めていると、見かねた先輩が言葉をかけてくれました。

「システムのソースコードを理解したいのであれば、データの流れを意識したら良いよ」と。

プログラムはIPO(インプット、プロセス、アウトプット)でできている

プログラムはIPOと言って、「インプット→プロセス→アウトプット」という流れでデータが入力されて、データを加工する処理がされて、アウトプットとしてデータが出力されます。

プログラミングの用語を使って解説をすると、ここで言うインプットはメソッドの引数、プロセスはメソッド内の処理、アウトプットはメソッドの戻り値となります。

例えば、プログラムAのインプットとしてデータが流れて、処理して、データをアウトプットデータとして出力した場合、次のプログラムBがプログラムAが出力したアウトプットデータをインプットデータとして処理して、次のプログラムに流します。

システムとはそのような小さなIPOが次々と繋がって、一つのシステムとなっているのです。

このアドバイスを頭の中で意識をしながら、ソースコードを読んでいくと、今までよりも少し楽にソースコードを読むことが出来るようになりました。

また大きなシステムであっても、データという観点で、一つ一つを細かく分けながら考えていくと、システムの全体像が理解しやすくなりました。

自分も後輩のエンジニアがチームに入ってきたら、必ずこの言葉をかけるくらい、役に立ったアドバイスでした。

技術的負債を残さない

開発中のエンジニアは、以下のようなあるあると葛藤しながら、働いていると思います。

こういう状況について先輩エンジニアに相談をすると、以下のような言葉が返ってきました。

「技術的負債は残してはいけない」と。「出来る時にやろう」と思っても、「出来る時は、なかなか来ない」というのです。

割れ窓理論

割れ窓理論という理論があって、「小さな問題を放置していくと大きな問題に繋がっていく」ということを示しています。

最初は技術的負債であっても、年月が経つとどんどんとスパゲッティコードになってきて、もう誰も保守が出来ない巨大なシステムになってしまうというわけです。

というわけで、出来るだけ技術的負債は残したらいけません。

先輩エンジニアは技術的負債をそのまま残すことの危険性を教えてくれました。

割れ窓理論等の話は以下の書籍に 、詳しく記載されています。

プログラマとしての視座をグンと上げてくれる良書なので、ここで一つ成長をしたいと考えている方は是非読んでみて欲しいと思います。

すぐに技術的負債を解消できない場合の対処方法

しかしながら、どうしても時間がない時だってあります。

そんな時は忘れないように、課題管理表やRedmineのようなチケット管理ツールに問題を起票します。

そして、保守案件の際などは、技術的負債を返済する時間を仕事の10%でもいいから確保出来るように計画を立てて、少しずつ対応をしていくのが良いと思います。

絶対に技術的負債をいつまでも放置していてはいけません。

顧客満足度とは「顧客が上司に褒められるようなこと」をやったら良い

会社の会議とか現場とかで、「顧客満足度を上げるように仕事をしなさい」と言われることがありました。

この記事を読んで頂いているエンジニアの方も、言われたことがあるかも知れません。

しかし若手エンジニアだった私にとっては、この言葉の意味があまりピンと来ませんでした。

「顧客満足度を上げる」と言われても、何をしたら良いのか全く分かりませんでした。

そこで先輩エンジニアに「顧客満足度を上げるって具体的に何をしたら良いのですか？」って聞いてみました。

この先輩エンジニアは顧客からの信頼も厚く、凄く仕事の出来るプロジェクトマネージャーでした。

そんな先輩エンジニアから以下のようなアドバイスが返ってきました。

「顧客満足度とは顧客が上司に褒められるようなことをやったら良いのだよ」と。

具体的には、自分たちに仕事をくれている一番関係性の近い自分たちの担当者として働いている顧客が、その上司から褒められるようなことをしたら良いと言うことでした。

「顧客が上司に褒められるようなこと」とは、どんなことか？

例えば、身近な担当者が何か上司に対して重要なプレゼンをする場合は、そのプレゼンが上手くいくように客観的なデータを出したり、想定問答集を作ったりしたら良いと言われました。

私はその話を聞いた時、「この人はこんなことまでやっているのか」と思いました。

システムエンジニアなので、システムを開発して、リリースするだけではなく、プロジェクトを円滑に回していくために、自分の役割を超えた仕事も積極的にやっていることを知りました。

私の言葉でもう少し「顧客満足度を上げるにはどうしたら良いか」ということを考えると、「自分の役割を超えて、相手の仕事の役に立つことをする」ということなのかもなと思います。

闘え

「闘え」という言葉は、当時の部長から言われた言葉です。

仕事をしていると顧客から無理な要望や、理不尽があったりすることがあります。

「顧客に言われてたことだからと言って、我慢して不利な状況で働いていると、顧客との永続的な関係性は得られない」と当時の部長に言われました。

この言葉を聞いてから、今の現状を疑わずに不利なまま働くことや、「みんながそうやっているから」と言うような非効率なことも出来るだけ、「それは違うのではないか」ということを提言して、改善案を考えるようになりました。

実際、提言をしたとしても上手く受け入れられないことも多数ありますが、闘うことを忘れずに仕事をしていると充実感が湧いてくると私は思います。

ありがとうと言われたら、「こちらこそ、ありがとう」と言う

とても不思議な人がいました。こちらが何かをやってもらって、「ありがとう」と言うと、「こちらこそ、ありがとう」と返ってくるのです。

こちらが感謝しているのに、なぜか向こうからも感謝されてしまいます。

しかし、「こちらこそ、ありがとう」と言われた自分の気持ちは凄く気持ちの良いものでした。そして、とても人当たりが良く誰からも頼られている、相手のことを尊敬するようになりました。

そして「こちらこそ、ありがとう」と言われ続けていくうちに、「この人の頼みだったら何でも聞こう」と思ってきます。この心境は凄いことだと思いました。

たった一言、感謝をされた時に「こちらこそ、ありがとう」と口癖のように言えば、豊かな人間関係を形成することが出来るということを思い知りました。

先輩からもらったアドバイスを受けて

ここまで若手の頃に先輩からもらって、今も自分の心に残っているアドバイスを紹介させて頂きました。

先輩エンジニアとしては何気なく言ったアドバイスであっても、その言葉がきっかけで大きく仕事に対する考え方や姿勢が変わり、成長をする人もいます。

皆さんも何か自分の心に残っているアドバイスがあれば、教えて頂けると幸いです。

この記事が誰かの参考になれば幸いです。