新入社員ブログ 松井(第5回)

こんにちは。松井です。もうすぐ2月になりまだまだ寒い時期が続きますね。

今回はOJTについて紹介します!内部研修が終わって、8月からOJTに参加しています。OJTということで、案件に参加していますが、私の場合は基本設計から参加しました。難しい作業を割り振られることはありませんが、とにかく仕事に慣れることに苦労しました。1月末までどんなことをやってきたか、簡単になりますが紹介します!

基本設計・詳細設計

お客様との打ち合わせや社内会議を聞いてメモを取ったり、画面設計書を見ていました。また、先輩社員がテーブル定義の物理カラム名の名前をつけていました。画面設計書やテーブル定義について「おかしい!」と思ったところは迷わず先輩社員に質問していきました。例を2つ挙げると画面設計書に書いてあることがテーブル定義に書かれていないといった資料での漏れとテーブル定義には必須扱いになっているにもかかわらず画面設計書では必須ではないといった資料間による矛盾です。冷静に資料を見比べることで漏れや矛盾が無いかチェックをしていましたので、該当する部分が資料内にあるか探すのが大変でした。しかし、設計段階で漏れや矛盾を減らしたということにおいてはやりがいを感じられました!

API仕様書・詳細設計書作成

簡単な処理のAPI仕様書・詳細設計書を作成しました。最初はやり方が分からず簡単そうな画面を先輩社員に教えてもらいながら一通り作成しました。最初は簡単な仕様の詳細設計書を書きましたが、やり方が分からず先輩社員が作成した詳細設計書を参考に書くようにしました。ある程度詳細設計書を書いたら「内容は違っても他の詳細設計書にも同じことを書ける」ということを意識するようにしました。その際に自分たちが作った設計書をもとに実装されるので、「仕様が違う」ということが無いように気を付けるようにしました。

API実装・テスト

今は作成したAPI仕様書や詳細設計書を元にAPIを実装しつつ、テストして想定した挙動になっているか確認しています。研修で学んだLaravelで実装しておりますが、実際に仕事として使うのは始めてでプログラムの書き方に戸惑うことがあります。しかし公式ドキュメントやQiita等で使い方を調べて出来る限り自力でプログラムを組めるように努力しています!

今回はここまでです。次回はフォローアップ研修について紹介します。最後まで読んで頂きありがとうございます!

君はマーティン・ファウラーを知っているかい?

いかがお過ごしでしょうか。福岡拠点の野田です。
春は新しい生活がはじまる季節です。初心に返って今日はマーティン・ファウラーの話を少し。

ソフトウェアの設計の世界でマーティン・ファウラーを知らない人はいないと思います。ThoughtWorksに所属し、アジャイルソフトウェア開発宣言の起草を支援するなど、ソフトウェア開発業界に数多くの影響を与えている人です。

https://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%83%BB%E3%83%95%E3%82%A1%E3%82%A6%E3%83%A9%E3%83%BC

私がマーティン・ファウラーを初めて知ったのは、2005,6年ごろ依存性注入(DI: Dependency Injection)が話題になったころ。今では多くのフレームワークに採用され、当たり前となった概念も当時は目からうろこでした。

http://kakutani.com/trans/fowler/injection.html
https://ja.wikipedia.org/wiki/%E4%BE%9D%E5%AD%98%E6%80%A7%E3%81%AE%E6%B3%A8%E5%85%A5

DDDで基本となるValueObjectをPoEAAで紹介していたり、マイクロサービスについて語っていたり、設計の世界では伝道師的な存在だと思っています。

http://kimitok.hateblo.jp/entry/2014/11/09/211820
https://martinfowler.com/bliki/ValueObject.html

まだ知らなかった方はこれを機会に是非記事を読んでみてください。発表されてから時間の経つものが少なくないですが、いまでも通用するものが数多くあります。

気になる本家サイトは、こちら。

https://martinfowler.com/

英語サイトの日本語訳をやっている方々もいらっしゃいますので、ご参考まで。

http://bliki-ja.github.io/