こんにちは！
新卒のIです。
PCモニター購入。Type-Cで画面へ出力＆PCを充電できるので最高です！
デスク周りを新調しました！
そろそろ机の領域がギリギリすぎて、
パソコンが落ちるのも時間の問題ですね、、
てことで（？）今回はこちら！
OJTで学んでいること
私たち新卒は5月からOJT（On the Job Training）に取り組んでいます。
OJTについて軽く説明すると
「先輩たちから仕事を通して技術を学ぶ研修」という感じです。
先週はシステムイノベーション事業部のH君の内容をご紹介しましたが
私を含めTさん、Mさんは情報デザインコンサルティング事業
という括りで同じOJTに取り組んでいるため、
今回はこちらでやっているOJTについて紹介します！
１.電話帳システム
5月中は、電話帳システムを作成しました。
項目を編集したり、登録できたりします。
電話帳システムで使った技術はこんな感じです。
・Spring Boot（Javaのフレームワーク）
・JavaScript
・HTML、CSS
・postgreSQL
そして作成の流れは、
★用意していただいたコードを用いて、Spring Bootの処理の流れを理解
↓
電話番号情報を既存のコードに追加
↓
入力フォームのエラーチェック（Java、jQuery）
↓
画面装飾（CSS）
↓
登録画面の作成
↓
自動テスト
という感じでした。
パッと見た感じだと、やっていることがよくわからないと思います。。
ただ、この中でも「★用意していただいたコードを用いて、
Spring Bootの処理の流れを理解」が一番大事な作業だと
私は感じたので、詳しく紹介します。
処理の流れを理解する作業では、実際にプログラミングをするのではなく、
用意していただいたコードをデバッグ（処理を順番に追う作業）を用いて
理解することに専念しました。
ここで、「実際にプログラミングをする方が大事じゃないの？！」
と思う方がいるかもしれません。
実を言うと私たちシステムエンジニアは、コードを書くよりも
「コードを解読し機能を追加する」と言う作業の方が多いのです！
（先輩方にも確認済み）
そのため、1からコードを組み立てる能力より
既存のコードがどんな構造で、ここの処理はどういった機能で・・・
といったように、コード精査能力が問われるわけなのです。
コード精査能力がないと、どこに何の処理を追加すればいいかわかりません。
さらに、理解せずに変な場所へコードを追加すると、バグやエラーが発生し、
余計に時間がかかってしまうという事態に陥ってしまうかもしれません。
以上のことから、いかに既存のコードを理解する能力が大事か
ということが伝わったかと思います！
2.販売管理システム
6月からは販売管理システムを作成する作業に入りました。
販売管理システムでも、上長に用意していただいたコードに
追加して作業していく形です。
使っている技術自体は5月の電話帳システムとほぼ一緒なのですが、
コード量が体感的に20倍くらいでした、、
販売管理システムのソースの一部。
処理の流れを日本語で書くと処理を追いやすくなります。
実際に販売管理システムでは、
データベースのテーブル設計
↓
画面の設計
↓
処理の設計
↓
プログラムを書く
↓
テスト
こんな感じの流れで作業しました。
作業工程を見てもらえるとわかるのですが、設計に時間をかけています。
画面設計。これを見ながら製造工程に入ります。
実は設計関連で10~15日ほどかかりました。
「設計しないでさっさとプログラムを組んだ方が早いんじゃない？！」
って思った人もいるかもしれません。
しかし、しっかりと設計をしておくことで
製造する時に大きな差が出るのです！
そこで、設計についてのメリットを2つ紹介します！
■メリット1：前の工程に戻るのを防ぐ
システム開発を行う時、ほとんどの場合上流から下流へと流れます。
上流では設計や要件を定義し、下流ではプログラムを組んだり
バグやエラーがないかテストをします。
開発工程が下流に流れた時、設計が適当だと
お客さんはどんなシステムが欲しいのかを汲み取るのが難しく、
結局ミスリードを招いてしまします。
ミスリードを招いた結果、開発に行き詰まり、結局下流工程で
データベースを追加したり、画面での実装を追加したりしてしまいます。
工程があっちこっちいったりするというのが想像できたと思います。
■メリット2：後で誰が見ても開発できる
設計書は誰が見てもミスリードなく開発できるように作成します。
そうすることで、途中で開発者がいなくなったり、違う人が参画してきても
問題なく開発ができるようになっているはずです。
また開発が終わった後も、保守や運用といった工程があり
長期にわたって開発手法を知っていなければなりません。
もし、設計書がなかったらどうでしょう。
「ここの処理どんな定義で開発した？」
「私開発してないからこのシステムの対応できません！」
なんてことになり得るのです！
こうなってしまったら開発した人をわざわざ呼ばなければいけません。
さらに開発して時間が経ったら、開発者もシステムについて
覚えているのかわかりません。。
どうでしょう！
設計書がいかに大切か伝わったのではないでしょうか？！
もちろん設計以外の工程もかなり大切です。
ただ、設計についてイメージがわかないと言う方も多いと思ったので
（前の私です）今回は紹介させていただきました！
まとめ
OJTでは他にも様々な技術を学びました。
ただソースの解読作業、設計書の作成を主に紹介させていただいたのは
実際OJTで学ぶ前、私自身がイメージしにくかったからです。
どうしてもエンジニアと聞くと、プログラムをバリバリ書いて
自由自在にシステムを牛耳るイメージがあると思います。（私のことです）
しかし実際はプログラムを書く時間よりも
コードを読んで解読したりエクセルで作業してる方が多いと言う方もいます。
皆さんが使っているシステムも、意外とこういった
泥臭い作業からできているのです。
イメージとは違う！といった方もいるかもしれませんが
エンジニアの裏側といった形で伝われば幸いです！
以上です。
次はMさんです！