Spring Day 2016 に行ってきました。
あまり多くは聴講せず、3セッションほど聴いてきたので、簡単にレポートします。

事例で知る！大規模エンタープライズ開発現場のリアル

「オフショアを活用した大規模システムの標準化」をテーマとして、事例ベースでシステム開発の標準化
メソッドを教示してくれました。私の所属しているチームの開発に役立ちそうな内容だったと思います。

このあと長く記載しているので、いきなり総括をいうと、下記の通りです。

システム開発標準化のポイント

早期の標準化ルール策定が必要
ステークホルダー（顧客のこと）を巻き込んでのルール策定が必要
ルール遵守の方法確立（破られる前提で違反ソースを検知できるシステム作る／ルールが勝手に守られる・守りやすい共通部品や仕組みづくりをするなど）

↑上２つは、新規開発かつ受託開発時に必須となるので、稼働の長い自社商材の開発にはあまり当てはまらないかも。
一番下のポッチが、とても大事なポイントだなと思いました。

　
ちなみに、スライドは公開されておらず。なので書き取りした各事例内容を下記に共有します。

事例前提

　登壇者の会社には、オフショアグループが5,6個あり、1グループで100人ほどのオフショアメンバが在籍。
　そこに並列で標準化チームが存在（開発管理課的立場。各グループに横ぐしでなにか対応する感じ）
　登壇者はその標準化チームに在籍。各オフショアグループで起きた問題に対し、原因や対策・展開を行っている。

　★標準化にあたっての心構え・・・
　　日本人と外国人は考え方が根本的に違う
　　日本人→実装前に設計ドキュメント作るの大事。バクは出る前に対策するのが大事
　　外国人→ドキュメントなくても実装できればOK。バクはでてから対策すればOK。
　　　　　ある程度育ったら、巣立ちます～（他社へ転職）
　
　　そのため、一人一人の能力をあげるように人を育てるよりも、
　　最大公約数的なルールをしっかり作り、守ってもらえる環境づくりをすることが大事。

事例1. 一覧画面を表示するとOOM

　事象： 一覧画面で何回か検索条件を入力して検索すると、OOMが起きる
　原因： 検索結果表示の上限なし
　　　　毎回、抽出結果をセッションに突っ込む（開放もしない）
　　　　メモリが足りなくなりOOM

　行うべきだったこと：

　　◇画面設計のルール策定◇
　　　検索条件入力必須
　　　表示結果制限必須（ページング機能も付与必須）

　　　★ポイント
　　　　1. ルールは設計の初期工程に作成完了しておくこと（そうしないとルール使ってくれない）
　　　　2. ステークホルダーを巻き込んでルール策定すること

　　◇開発のルール策定◇
　　　1. セッション使う際は申請させる
　　　2. CRUD図を作成させて、セッションが残り続けないようにする

　　　★ポイント
　　　　ルールは定めても必ず破られる
　　　　そのため、セッションにセットするソースを検知する仕組みを作るなど、破られ前提で対策をしておく

　　◇開発で用いれる部品作成◇
　　　セッションが不要になったら、自動で削除される部品。

　　　★ポイント
　　　　ルールを守りやすい状況にするための部品を作っておくと、ルールを守ってくれやすい

事例2.ヒストリーバック時の有効期限切れ

　事象： 画面登録後ヒストリーバックし、有効期限切れの状態で画面に従うと、データが二重で登録されてしまう
　原因： no-cacheによりpostが再送信できてしまうから

　行うべきだったこと：

　　◇ヒストリーバックを許可するかどうするかを開発内で合意形成すべき

　　◇開発標準のルール策定（ヒストリーバックを許可する場合）
　　　post redirect getで、有効期限をださなくする
　　　prgの場合、flashスコープというprgの間だけ生きるスコープに完了メッセージとかを引き継げる

　　◇共通部品の作成（戻るを許可しない）
　　　ブラウザの制御を行う。戻るボタンを見せなくする。お勧めしない

事例3.エラーハンドリング問題

　事象： 楽観ロックエラーがでてもその例外を握りつぶしてしまう実装をしている

　行うべきだったこと：

　　◇ルール標準化
　　　エラー・例外ハンドリングは開発前にルールを作っておく

　　　考えうるエラー・例外を網羅的に洗い出す
　　　↓
　　　そいつらをカテゴライズする
　　　・運用エラー（バリデートエラー）
　　　・システムエラー
　　　→誰がどのレイヤーで上記エラーを出すべきか考える

　　◇部品作成
　　　要件に関係なく、エラー・例外ハンドリングを行う共通部品を作成する
　　　＃ちなみにSpringMVCには、システムエラーのハンドリングを行うのに便利なアノテーションが用意されてる

事例4.コントローラー集約問題

　事象： ○○機能の編集画面のコントローラークラスが見当たらない。
　　　　（○○modifyとか○○updateとかって名前かな？と思って探す）
　　　　結果○○Entryという名前だった。編集なのに、新規登録みたいなこの名前なのはなぜ・・？と
　　　　オフショアメンバに聞いたところ、登録も編集も似たような画面だから集約しちゃったとのこと。

　　　　1jspに対し1controller
　　　　6jspに対し1controller
　　　　→など1つのcontrollerに対し、n個のjspという自由な作りになっていた

　行うべきだったこと：

　　◇クラス分割のルール策定
　　　・分割単位を決める
　　　　1jspに対し1controller
　　　　1業務に対し1cont

　　　★ポイント
　　　　ネーミングセンスを決めると守ってくれやすい
　

事例5.グローバル開発における言語問題

　事象： オフショアメンバ「（テストしていて・・）バリデートエラーが日本語なので読めない。
　　　　なんて書いてあるのか教えて」→日本人が都度教える。生産性が悪い
　原因： 共通部品や開発ツールがすべて日本語

　行うべきだったこと：

　　◇ログやマニュアルの英語化
　　◇もしくは、独自のツールではなく世界共通の共通部品を取り入れる
　

Spring Bootで学ぶ初めてのWEBアプリ開発

スライド：http://www.slideshare.net/terahide/spring-bootweb-69236132
Spring Bootのチュートリアルを実際に触りながらポイントを解説してくれました。
本当に超初心者向けでした。
Hello worldの出し方から始まり、RESTやWebSocketなど少しづつ段階をあげて
Spring Bootを活用して流行りの手法を実際に実装してくれました。

基本的には、Spring Bootでググって、オフィシャルサイトに行き
チュートリアルという画面に行って、そこでRESTとかで画面検索すると
REST実現用のチュートリアルがでてくるので、それに沿って行けばよいという
お手軽な勉強法です。おススメです。

LINE における Spring Framework の活用

スライド：http://www.slideshare.net/tokuhirom/linespring-framework
LINE における多くのシステム開発では、Spring Frameworkが利用されていますよ～
そのうちの1つの開発例をもとに、FWの活用方法と、サーバー・ミドルウェア構成を紹介しますよ～
という内容でした。淡々と、活用しているものの紹介が続きました。
最近の流行りとか、そのツールを選んだ理由を聞けた点は〇でした。