本記事は
ブログ書き初めウィーク
1日目の記事です。
📝
告知記事
▶▶ 本記事 ▶▶
2日目
📅
はじめに
私はしがない新人アプリケーションエンジニアです。もとは文系、心理学を専攻していましたが占いという非科学的なものをやっているミステリアスさがチャームポイントだと思っています。おっちょこちょいでお茶目なところが仕事に出ないように日々気を付けながら働いています。
入社して7か月、現場配属されて3か月の私が、これまでどんな業務を経験し、どんなふうに取り組んできたのかを本ブログで紹介します。特に、苦労した点やそれをどう乗り越えたかを中心に書いていきます。
私の仕事は大きく「開発業務」と「開発以外の業務」に分かれます。まずは開発業務についてお話しします。一般的な開発の流れは、要件定義→設計→開発→検証→リリースですが、私はこれまで主に開発・検証・リリースを担当してきました。
簡単に工程を説明すると、要件定義では顧客の要望を聞き、必要な仕様や機能を決めます。設計ではその仕様をどう実現するかを細かく決め、開発では実際にコードを書きます。検証では仕様通りに動くかを確認し、リリースでは顧客が使える状態にします。
開発業務以外では、議事録作成などの新人が任されるタスクについても触れていきます。
開発
仕様把握
開発をするにあたって最初にすることは開発するものの把握です。
必要な機能の実装のためにやることをリストアップ・整理したうえで、設計書を見て認識合わせをしておきたい部分を先輩に確認します。認識を間違えたまま開発を進めると、後から気づいた際に手戻りが発生して遅延が生まれてしまうので最初の認識すり合わせが大切です。
そして、開発に関係しそうな既存のコードを読み込んでどの部分でどの機能を実装しているのか、追加機能や修正のために必要なコードはなにかを考えます。
業務では基本的にJavaを使用していますが、最初にコードを見たときは「全然読めない！」となりました。研修時にJavaは勉強しましたが、それ以外でのプログラミング経験はほとんどゼロでした。表情の読めないあの子の心を読み解く気持ちです。
研修でやった中で、コードの読み方は活かせましたが、研修での基本的なJavaのコードと実際のシステムに使用されるコードの書き方は全然違います。
読みやすくするためや保守性を高くするために、プログラマーによって工夫がされているので、コードの書き方は１つだけではないのです。
研修段階から解答の書き方がすべてだと思って覚えようとするのではなく、なぜこのコードで動くのか、他に書き方がないか意識して学べばよかったと思います。
私の場合、プログラミングで詰まったときは一つ一つ分からないコード・記法をネットで調べて類似しているコードを調査したり、周りの人に聞いたりします。
開発スケジュール計画
仕様把握ができたら、必要な機能の実装のためにやることをリストアップし、かかる時間を見積もり、いつまでに終わるかスケジュールを組みます。
最初は１つのタスクにかかる時間が全然分かりません。ですので、時間を見積もれるように実際にかかった時間を日々記録し、そこから計算するようアドバイスをいただきました。
これができたら100年先の人生計画までばっちりです！
仕事には基本的に期限が決められているので精度の高いスケジュールを立てることが必要です。遅れそうなときはすぐに報告・連絡・相談しなければなりません。
開発（プログラミング）
私はSpring Bootを使用したJavaをメインに開発をしています。コードの読み込みと同じで最初は分からないことが多すぎてしんどいです（今も）。
特にエラーが解消できない時は短気な私はとにかくイライラが止まりません（ステイステイ、落ち着いて）。
エラーでつまずいたときはまず、原因解明です。エラー文を読むことや、エラー文が示すコードを見直すこと、デバッグ機能で変数に入っているデータの動きを追い、どこの挙動がおかしいか確認します。上記の方法でとにかく手を動かして原因を探します。
原因が分かっても解決できなければネットで検索したり、周りに聞くなどします。
つい自分で解決しようと多くの時間を費やしてしまいますが、スケジュール通り進めるために自力でやる時間に区切りをつけて超えたら質問するようにしています。
やっとエラーが解決できたとなると、はい次のエラー。まあいつかは終わります。
検証
プロジェクトによっては開発者ではない第三者に検証してもらう第三者検証を行っていますが、私が参画したプロジェクトの一つでは開発から検証まで自分たちで行いました。
検証では、開発したシステムが仕様通り動作するかを確認します。動作確認に抜け漏れがないか、本当に仕様通りかを気を付けました。
正常に動作する場合だけでなく、不正な入力や操作の処理を行ったときに正しいエラーがでるか、開発者視点とユーザー視点両方に立ってあらゆるテストケースを考えます。
顧客が使用する本番環境で障害が起こると大変なことになるので、石橋をぶん殴る気持ちで慎重にテストケースを考え、実施しました。
リリース
リリースはいよいよ開発したものを本番環境に公開します。
リリースの前に本番障害を未然に防ぐため、本番リリース手順書を作成し、リリース物件に対して定められたチェック項目に問題がないかを確認した上でリリース判定会を行います。リリース判定会とリリース作業の前にそれらの資料を作成します。
私はリリース作業に一度立ち会った経験のみでリリース判定会には参加したことがなかったので最初は具体的に何をするか知りませんでした。他プロジェクトの資料を参考にしつつ、先輩に確認しつつでなんとか完成させました。
リリース判定会、リリース本番では切実に事前準備が大切だと思わされました。
どういう流れで進むのか作業を細分化し、具体的なところまで落としこまないと本番でタイムロスを発生させてしまいます。ここが私はできていなかったので反省です。
この件で障害は起きませんでしたが、想定外・事前確認ができていない手順の実行による障害が発生する可能性もあります。
次からは実際の動きを事前にシミュレーションしておこうと思いました。
開発以外
議事録
開発作業の他にも新人が任される仕事はいろいろあります。その１つが議事録作成です。
研修時には議事録作成は全部AIに任せてもいいのではないかと思っていましたが、意味がありました。
まず会議にとても集中できます。
そして会議の内容の理解はプロジェクトの理解にもつながります。会議ではアプリだけでなく、インフラのチームとも議論するため、アプリ開発だけでは触れないAWSのサービス名などの単語も議題に上がります。会議中は分からなくても会議後に調べてみると意味が分かってスッキリします。
このように自分の成長に役立ちます。
他の作業にも言えますが、議事録作成は数をこなして慣れればなんとかなります。
まとめ
ここまで読んでいただきありがとうございました。 以下結論です。
ネットコムのアプリケーションエンジニアがどんな仕事をしているか知っていただき、そこから興味を持ってくださる仕事があれば嬉しく思います。
もっと詳しく知りたい仕事があれば、他の方のブログも是非読んでみてネ☆
以上で挙げた仕事の他にも庶務などいろいろあります。私にも好きな作業が見つかるといいなと思います（探し中）。
ではまた次回（予定は未定です）！
