【SEのおしごと】SEに興味ある人必見!新米エンジニアはこんな感じだぞ!

レールの上からこんにちは。ひろです。

ここんところ、とある企業さんのシステムの改修案件やってます。未経験から5ヶ月で!ここまできたぁぁぁぁぁって感じですね。

でも企業さんのグループ案件として立ち上がり、何人もの手によって作られたシステムはソースが追いづらい…!

それに加えて納品するものなので、下手なコードは書けませんってことで、コードレビューではこってりしごかれます。今日は新米エンジニアの苦労を聞いて下さい←

題して「とあるエンジニアのバグ修正」はじまりぃ!(ウソ)

新米エンジニアは辛いよ

胸はってIT企業にいますけど、そう現実は甘くない。そもそも未経験で採用されて、1ヶ月ちょっとの新人研修でプログラミングの基礎にサーバー周りの知識をぶっ込まれただけの人です。

自分でRubyとか勉強してたし、ブログでウェブサーバー周りは取り扱ってたから少しは分かるんですけどね。

ちなみにこの期間は、TECH::CAMPのWEBアプリケーションコースも受講してました。めっちゃ勉強になりましたよ!ほんと目から鱗!

そんな感じだったので、C#に触れるのは2ヶ月ぶりくらいになります。コードの最後に付け加える”;”忘れなかった自分、偉いぞ!

めっさ複雑…

でもね、企業さんで使用されるような規模のシステムは、思っているよりも複雑!!Ruby on Rails使うと「あれ?アプリとか楽勝じゃん?」とか大それた勘違い起こしますけど、そんなことありません。

正直、ソースを追うのだけで精一杯です。

どんな感じかっていうと、千葉県の鋸山しか登れないのに茶臼岳(群馬県)に登らさせる感じ。わからない人はググってね。

ようするに高地トレーニングに近いです。企業さんのシステムだとデータベースとのやりとり用のクラス、ビュー用のクラス、画面側の処理、バックエンド側の処理等々…

見ているだけで頭が痛くなりますね。

例えば「〇〇のユーザー」がログインしたら「〇〇のボタン」は非表示にしたいなぁ〜みたいな案件が飛んでくるんですよ。

僕が一番はじめにすることは、ソースを追うこと。なぜかって?そもそとシステムがどんな感じに動いてるかわからないから!

ボタンの表示・非表示って簡単なようにみえるんだけど、そんなことはぜんぜんないんですよ。

ログインしたユーザーの情報を見に行かなきゃならないし、場合によってはデータベースにアクセスして、該当するデータを引っ張って来なきゃいけなくなります。

だからまずはソース読んで挙動を確認する!これが一番時間かかる…。

システムの動きを紙に書き出す

システムの動き方だいたいわかったら、次は、案件に対してどんなアプローチでコードを書けばいいかを考えます。

研修くらいだったら、適当にゴリゴリ書けば動くシステムは作れます。

でも、「そんなんじゃ仕事ではだめだ!成長しないぜ!」ってことで、実際にソースに触れる前はノートとソースを見比べて、フンフン言いながらシステムの制御や条件、流れを書き出していきます。

フローチャートをノートに書いたり、該当する箇所にコメントでフローをまとめていったりする作業です。

これしないとホント詰む。

僕みたいな新人エンジニアこそ、紙とにらめっこして頭の中を整理してから作業に取り組みましょう。

大まかに制御の条件や処理内容、処理の順序などを考えておくと後々が楽になってきます。

よく考えないでプログラミングを始めると、余計に複雑になって二進も三進もいかなくなるので、まずは方向性を定めましょう。ここ大事。

ソースを書いてく

いやっほう!ソース書くぜ!とか思ったあなた。甘いぜよ。

ソース書いてくのに間違いはないんですけど、その前に条件に使用する値の持ち方とか、改修案件用のソースが「本当にこの位置でいいのか?」ってのを考えないといけません。

ちなみに僕は、ソースコードを書き始める箇所にこまっています。だって複雑なんだもん。分かんなかったら、素直に先輩に聞きましょう。

こういうコミュニケーション能力って、エンジニアにとっては本当に大事なんです。

ってわけで、頭を使ったあと、やっとの思いでソースを書いていきます。先ほどの「ボタンの表示・非表示」の例で言うと、まずは「ユーザーの部署や権限を取得」する必要がありそうでさ。まずは、それらを取得するソースを書きましょう。

画面のベースとなる部分に情報を持っていたりするので、ちょろちょろっと追いながら確認していきます。取得されてなかったら、定数作って、データベースからやりとりするクラスに書き足して、プロパティ作って、、、と意外とやること多い。

それで「情報持ってこれたな!」ってなったら、やっと制御と処理に移るわけです。とりあえずやること多い。

ソース書くのにも準備が必要ってことですね。

ドキュメント作るよ!

エンジニアだからって、プログラミングばっかしてるわけにはいきません。具体的に何するかっていうと書類作ります。

管理表とか試験書とか、データ設計書の修正とか。やること多い。

「いついつに、どの作業で、どのクラスをイジりました〜」っていう書類を書くときは、漏れなく書きましょう。できればソース開いて書くぞ!ってなる前に、書類を修正しておくのがいいです。忘れません。

いくつか書き忘れて怒られました…。

書類についてはそんな感じ!まだまだ慣れないよね!

コードレビューで絞られる

ソースレビューは容赦がありません。納品するものなんで、当たり前っちゃ当たり前なんですけど。

そのぶん、たくさんフィードバックもらえて、自分の実力が上がったような気になるけど!

でも気になるだけであって、これから先どうなるかは分からないじゃん?赤ペン先生ってわけじゃないけど、やっぱさ、プログラミングって難しいじゃん?

ちなみにコードレビューの直しをしつつ、指摘された点を修正しながら、ソースコードを書き、そして試験書も作らなきゃならない。

何これ!やることめっさある!ってのが本音だ!

まとめ

という訳でSEに興味のある人は、こんな感じで仕事しますよ!っていうことでした。

意外とやることが多くて大変だけど、プログラミングに関わりながら、より上を目指すには、自分で書いてレビューしてもらって、ブラッシュアップするしかありません。

まあ、僕なんかよりもこってり絞られてる、意味分かんないIT企業なんてわんさかあると思うけど。試験書とかソース書いたり、フンフン言いながら頭抱えて悩まなきゃいけんけど、仕事ってそういうもんじゃん!

新人で未経験のSEさんは、一緒にがんばりましょう!

The following two tabs change content below.
ヒロフルカワ
日本の大学を中退しフィリピンの旅行会社に就職。その後、NZの大学に留学。卒業式では400人の前でスピーチをする。これまでの経験をもとに、英語・海外情報をブログで発信中。ツイッターではブログ運営・英語学習・海外情報をシェアします。社会不適合者のネジ外れぶっ飛び系。海外就職/大学留学/TOEIC840点/英検準1級。お仕事受付中のフリーライター兼、旅人。
スポンサーリンク

フォローすると更新を見逃しません

合わせて読みたい記事

合わせて読みたい記事

Facebook