Result presentation slide

1. 自己紹介
名前： 三島
大学： 山梨大学 大学院 医工農学総合教育部 修士課程
工学専攻 コンピュータ理工学コース 2年
趣味： ゲーム（『UNI’S ON AIR』）
1人旅・バイク
出身地： 徳島県 育ちはメキシコ(スペイン語は喋れません。。。)
開発： ペットの顔認証 ユーザのレビュー分類
現状 ゴール

2. インターンシップの概要
 課題１：新機能ログ出力の機能追加（9日）
• 環境構築(1日)
• 実装(3日)
• テスト(2日)
• レビュー(4日)
 課題２：管理画面に新機能項目を追加(4日)
• 実装(4日)

3. 新機能ログ出力の機能追加(9日)
 なぜログを保存するのか？
• 各アイテムの確率の妥当性を判断
• 不具合の調査
• ユーザーからの質問に対する回答
 現状の課題
• ログ出力はまだ実装されていない

4. 新機能ログ出力の機能追加(9日)
 何をやったのか
• ログテーブルを実装
• 関連しているデータベースを理解
• 新機能のコードを理解
• テストをRspecで実装
非同期処理
記録
RDS：Log DB
timestamp : 日時
user_id : ユーザー
・・・
timestamp : 日時
user_id : ユーザー
・・・
timestamp : 日時
user_id : ユーザー
・・・

5.  テスト
• 先にテストを実装
• プルリクした時に無関係なコードでエラー
 理解しやすいコード
• プルリクした時に番犬に噛まれる
• 主観で分かり易い変数名を定義
 膨大な量のコード
• (Ruby or 自作)メソッドなのか区別がつかない
課題１を通して苦労した点
静的コード解析ツール：RuboCop
CIツール ：CircleCI

6.  テスト
• 既存コードを参照
• ローカルリポジトリを更新してプッシュ
• テストの重要性
 理解しやすいコード
• RuboCopのコマンドの後に「-a」
• 客観的なレビューの重要性
 膨大な数のコード
• 要点を絞ってコードを見て理解する力
• リファレンスを調査
• (メソッド名 or クラス名)で検索
課題１を通して学習した・感じた点
静的コード解析ツール ：RuboCop
CIツール ：CircleCI
$ rubocop -a
$ git feach
$ git rebase
$ git push –f

7. 管理画面に新機能項目を追加(4日)
 マスターデータとは
• ゲーム内で不変の共通パラメータ群
(武器の強さ、名前、アイコンなど)
 マスターデータがなぜ必要なのか？
• ゲームの構成情報を決定
• ゲームバランスの調整
 現状の課題
プランナー(非エンジニア)が操作しやすく、
マスターデータを登録できる

8.  実装
• Ruby on Rails のgemであるActiveAdminを利用
• 仕様書に基づいて項目を追加
管理画面に新機能項目を追加(4日)
 課題に対してどう対処したか？
• 値を記入からプルダウンに変更
• アイテムIDをアイテム名に変更
• 英語と日本語の表記
操作しやすい仕様を意識

9.  操作しやすいView
• 主観だと分からない
• HCIを考慮したデザイン選択が難しい
(チェックボックス、プルダウンなど)
 仕様の見方
• 複数テーブルの関連付けが難しい
課題２を通して苦労した点
RuboCopCircleCI

10. 課題２を通して学習した・感じた点
 操作しやすいView
• メンターから客観的な評価をして頂く
• 既存のコードを参照
 仕様の見方
• 新機能の全体仕様を確認
• binding.pryでデバック
• (has_many , belongs_to)メソッドで関連付け

11. インターンシップを通して感じたこと
 コミュニケーションの頻度
 当事者意識

12. コミュニケーションの頻度
 エンジニア同士のコミュニケーション
• ウェルカムランチ
• 1on1 4回
• LT会 2回
• エンジニアコミュニケーション制度
• エンジニアミーティング
 エンジニア以外のコミュニケーション
• チームランチ
• ふらり横丁
• 忘年会
9回
3回
13日間で
ほぼ毎日イベントが発生!!

13. コミュニケーションの頻度
 本の概要(Team Geek)
ソフトウェア開発を効果的かつ効率的にするためのチームの作り方
 1.5 3本柱
人間関係を円滑にするだけでなく、
健全な対話とコラボレーションの基盤となる：
謙虚(Humility)、尊敬(Respect)、信頼(Trust) HRTが大事
 2.4 成功する文化のコミュニケーションパターン
同期コミュニケーションに人数を減らし
非同期コミュニケーションの人数を増やす
 2.9 すべてはコードに通ず
コードを書くことを目的とする強いチームを作るには、膨大な
コミュニケーションが必要となる
Brian W. Fitzpatrick, Ben Collins-Sussman 「Team Geek」(オライリージャパン, 2013年)

14. コミュニケーションの頻度
 コミュニケーションを通して
技術的用語が多く出てくる
 知らない単語を調査
 日報に調査結果を記述してアウトプット
Vimはいいぞ～
効率的なインプット&アウトプットに繋がる
Datadogは〜
Mackerelは〜

15. 当事者意識
 本の概要(THE TEAM 5つの法則)
チームの成果を上げる「チームの法則」と
現代社会に対する活用方法
 チームの一員としての携わり方
• 「ログDB設計に対してどんどん意見を出してください」
• 実際のサービスに取り入れる機能を実装
 第1章 Aim(目標設定)の設定
チームが何のために存在し、
どんな影響を与えていくべきなのかをすべてのメン
バーが意識し、自発的に行動し、
成果を上げるチーム作り
麻野耕司「THE TEAM 5つの法則」(幻冬舎, 2019年)

16. 最後に
 まとめ
• 実際のサービスに使われる機能を実装
• 現場のチーム開発を体験
• 強い(成果をあげる)チームを作る文化
 感想
• 個人とチームの違いを学べた
• 現場の知識を学べた貴重な体験でした
• 目黒周辺のご飯は美味

17. ペットの顔認証 モデル図
③カスケード型分類器
②Haar-Like特徴
①画像抽出・データ作成

18. ユーザのレビュー分類 モデル図
SNS/コミュニティ
クリエイター
感情分析
・ネガティブ
・ポジティブ
レビュー分類
・操作性
・デザイン
メッセージ1
操作性/ネガティブ
メッセージ２
操作性/ポジティブ
メッセージ３
デザイン/ポジティブメッセージ1
メッセージ2
メッセージ3
曖昧性解消 提示
 「SNS」などの大量のメッセージから感情分析、レビュー分類に適用
 分析したメッセージをクリエイターに提示
• 貢献
• 概要
 効率的なユーザ意見の把握
 クリエイターのコンテンツ創造の手助け
 ユーザの利用率増加