今後の活動について
===

# 目標

## 会社生活における希望を見せたい

- チームだから到達できるゴール
- 開発規模
- 速度
- 相互作用
- 役割の差はあれど同じメンバー
- チーム内に絶対的な強者はいない(いたらやばい)
- 尊重と信頼を忘れてはならない
- ディレクションこそ面白い
- つまるところ検討工程
- 実装工程は形にして確認工程へ進める
- 検討->実装->確認->検討->...
- リリースも確認工程のひとつと捉えることも出来る

## 成果の考え方を個人から組織へ

- チームの成果を重視
- 達成したいゴールはチーム全員のもの
- 勤務時間などルールはある
- 「時間いっぱい働くこと」は契約上のルール
- 多くの組織は内部から崩れる
- 誰かがつよつよだからといってあなたの成果は下がらない
- むしろつよつよの人から教えてもらえば成長できる
- 社内だと受講料がタダ！(相手の都合は考慮しましょう)
- つよつよの人が活躍すればあなたの給料も上がる(かもしれない)
- 会社の業績が伸びれば原資が増える
- 会社には「個人総取り」のシステムはない

## 多くの選択肢があるということを示したい

-

# 概要

- 研修期間
- 4月から2week程度
- 研修目的
- OJTをスムーズに開始できるようにする
- 大失敗をしないための事前知識を入れる
- 研修題目
- 座学
- 言語基礎学習
- 開発ツール基礎学習
- バグ取り合戦
- 会社の製品を使う

# 研修内容(座学)

## 第一部

### OJTをスムーズに開始できるようにする

- システム開発の基本的な流れを知る
- 開発進行の流れ
- ウォーターフォール型
- 要求発生 ~ 開発工程 ~ 品質検証
- Agile型
- 検討 ~ 実装 ~ 確認
- 役割と配分
- 役割
- 企画(プランナー)
- 戦略(マーケター)
- 指針(ディレクター)
- 成形(エンジニア/デザイナー)
- 助長(運用サポート)
- 蒐集(カスタマーサポート)
- 配分
- 専門分野はあるが、専属ではない
- スキルポイントの割り振りみたいな感じ
- 運用についても忘れてはいけない
- リリース後からが本番
- 維持しながら改善
- 最も重要なのはユーザデータ
- サービス開発のよくある構成と役割を知る
- クライアントサーバモデル
- [Figure]モデル図
- 情報を要求->応答されたものを表示、の流れ
- いわゆる中央集権的構造
- サーバ構成例
- [Figure]モデル図
- [Figure]クライアントの種類と応答サーバの種類
- [Figure]サーバ構成
- 社内での進め方・解決方法を知る
- 社内の進行例
- 要求の発生源が複数ある
- 優先度の付け方を考慮(交通整理係がいる)
- 社内のサーバ構成例
- コスパについての考え方
- 前振り的な感じで

### 大失敗をしないための事前知識を入れる

- 社会人としての最低限のマナー
- 言葉遣いは気をつけましょう
- 言い方次第で受け取られ方が変わる
- 「そんなつもりないのに」はよくある
- ハラスメントを理解しましょう
- ハラスメントの種類
- 加害/被害両方の可能性がある
- 当事者になった場合どうするか
- 与えたなら謝る
- 受けたなら相談する
- 誹謗中傷をしない(特に人格否定)
- 例えばこんなの
- 一般的な事例のつもりでもダメ
- そもそも攻撃する必要などない
- 絶対にやってはいけないこと一覧
- 犯罪ダメ！絶対！
- 社内機密の漏洩
- 破壊活動
- 開発的な守りごと
- 隠さない、嘘をつかない、誤魔化さない
- 自分に不利なことは多々ある
- どうせバレるし信頼を失う
- 得難く失いやすいのは信頼
- 信頼無くしてコラボレーションは生まれない
- 仕様やコードの指摘は慎重に行う
- 何においても「経緯」というものがある
- 誰も望んで改悪したいわけではない
- コードに関する指摘をされても人格否定ではない
- 不安があれば即相談
- 世の中分からないことだらけ
- 会社ルールもローカルルール
- 一歩進めばまた迷う
- 判断がつくようになるのが成長

## 第二部（チーム開発）

開発に関する話がないとつまんないのでまずはツールの話。
そこから、「ツール(手段)」を使って「ゴール(目的)」の達成へと話を進める。

### チーム開発でのツール

- 開発ツールの理解
- ツールの役割
- やりたいことはどんどん増えるが時間はないのが世の常
- ツールは問題を解決する
- ツールは人間が活躍するための助けとなる
- 開発的によく見かけるツール紹介(各所で使うものは違う)
- (足並み揃えて使うことになるものに限定)
- コミュニケーション系
- slack
- gmail / google calendar
- プロジェクト管理系
- redmine / bitbucket / jira / Kanban
- Qiita:Team / esa / confluence
- trello
- 開発系
- gitlab / github
- jenkins
- docker
- デザイン系
- Zeplin
- Sketch / figma
- InVision / Prott
- Illustrator
- ツールは日進月歩
- 過去の問題を解消した新ツールが生まれ続ける
- 既に同じようなツールは大量にある
- 新規ツールの導入
- 新しいものや便利なものに惹かれる気持ちは分かる
- メリットとコストの天秤
- メリット
- 解決できる問題
- 省略される手間/短縮される時間
- ミスの減少
- コスト
- 初期コスト
- 布教コスト/学習コスト/(ゲンナマ)
- 運用コスト
- 支援コスト/メンテコスト/(ゲンナマ)
- 定着させるという強い意思と価値があると信じる心
- 使い方と使い分け
- 何を解決したいのかを意識
- そのツールで解決したいことを明確に定義する
- ツールをどう使うかは本人次第
- 活用も悪用も出来る
- 手段でしかないので
- 雑な使い方をすると後で困る(誰かが)
- 資産(情報)を散らかすのはやめよう
- ツールを連携させるとさらに嬉しい
- 人間の手間を省く
- うっかり忘れを解消
- 悪い事例
- バグ報告をslackで行い放置(忘れられる)
- trelloに定例MTGの予定を入れる
- 個人間やりとり(DM等)で仕様検討を行う
- 開発時のツール活用事例
- CI/CD環境の構築
- プッシュ時にUT稼働
- マージ時に動作環境へ自動展開
- slackでのイベント通知
- プッシュされた / ビルド結果
- タスクの期限がきた / MTGの時間
- 売上速報（デイリー/マンスリー）
- プロトタイプツールで確認->改善

### 協働作業を知る

- 会社でチームが必要な理由
- 我々は常に他社と争っている
- 明日にも競合製品がリリースされるかもしれない
- 類似製品はすぐに出てくる
- いかに素早くリリースサイクルを回せるか
- そしてユーザの心を掴むことが出来るか
- 一人で出来ることには限界がある
- 人には多くても脳が一つと腕が二本しかない
- 常にコンディションを維持し続けることなど出来ない
- コードを書く時間は製品開発のうち5割以下
- 各々が作業すれば早い！
- アイデアが膨らみ、大きな事を成し遂げられるという自信
- あなたが思いつくことは既に誰かが思いついている
- 異なる意見が出ることで幅や深みが生まれる
- コラボレーション環境を作ろう
- チーム文化の重要性
- ミッションステートメント
- やること/やらないことを明確にする
- 同期/非同期コミュニケーション
- 意思決定の流れ
- ドキュメントがあれば何度も説明しなくてよい
- ログがあれば新来者も素早く状況把握が可能
- 環境(チーム)を作るには
- 強いチームは自然発生しない
- メンバー全員がそうしたいと思うことが大事
- メンバー全員がそうしたいと思える背景が大事
- 攻撃からも守る
- 組織変更や配置変更はよくある話
- 新規メンバーは往々にして文化を破壊しようとしてしまう
- 土台となるコミュニケーションの重要性
- あくまでも関わるのは人間
- 開発行程のほとんどで対話が必要となる
- チーム内外を問わない
- 物事がうまく進むのは会話が多い時
- 活発な議論が物事をうまく進める
- 問題の解決が早い
- 軌道修正が早い
- よりよいアイデアが降ってくる
- みんなが黙って作業しているのは危険な可能性がある
- 後で問題が発覚するなど
- 話しにくい空気が生まれてないか・・・？
- ツール上で何でも済ませられるほど人間は(まだ)進化していない
- slack や Skype は便利だけど・・・
- 文字ベースの会話は誤解を生みやすい
- 画面越しだと表面的な関係性になりやすい
- Face to Face は重要
- あたかもその場に全員いるかのようなXR技術でもなければ
- 悪の組織もわざわざ会議空間に集まるよね
- 会議だけじゃなくランチに行ったりして会話するのも大事だよ
- 心理的障壁とは
- 「なんか話しづらい」という空気
- なんか不機嫌そうだな
- 怒られるかもしれないから黙っておこう
- 恥をかくのはいやだな
- 障壁が発生する原因と影響
- 尊敬と信頼の欠如
- 一部の人により決定されていき、成果に対して無関心になっていく
- 言われたものを作るチームの出来上がり
- 障壁をなくすにはどうするか
- 話してみてから判断する
- 思い込みで判断してしまうと
- 怖そうだけど怖くないパターン
- 怒ってそうだけど人付き合いがうまくないだけのパターン
- 誰かの言動をバカにしない
- 背景の違いや経験の差はある
- そうした差は埋めていけばいいだけ
- キャラクター性を出しすぎない
- 茶化しやすい人がいるとそういう流れになりがち
- みんな理解したうえでの流れなら許容される
- 慣れていないメンバーからすれば恐怖の対象になりうる
- 肯定から入る
- 「なるほど」「いいですね」「アリ寄りのアリ」
- あなたの意見は間違っていないという安心感
- 目的とズレたりしていたら修正するか今回は見送り
- または、こうすればもっと良くなるのではという上乗せ提案で補正
- 注意を受けたとしてもあなたが否定されたわけではない
- まずかった言動は反省する
- でも必要以上に自己否定しなくてよい
- 同じ方向を向く（目的を共有する）
- 考え方や思いはそれぞれ、でも達成したいことは揃える
- チームのゴールは全員のゴール
- 一人で目立ってもゴール達成できなければ意味ない
- 全員の考え方を合わせる必要はない
- 何度でも確認し、何度でも揃える
- 軌道をずれることはしばしばある
- プロジェクトの進行を止めてでも確認すべき
- 意見の食い違いがあってもひとつに決定し、それに従う
- 同じゴールに向かっていても行き方は違ったりする
- どれにしても正解はない
- 目的達成を最も期待できるものを採用
- 間違っていたらやり直せばよい
- 「本当はイヤだけど」と考えながらやってもやらされ仕事になるだけ
- あるあるな状況だが切り替えていくしかない
- 社内に敵はいない
- (基本的にはいない)
- 相手のことを認め、同じ目的に向かうメンバーだということを忘れない
- 腹が立つことは起こりうる(必ずある)
- みんな「良くしたい」と思ってのこと
- ただ、相手の状況をよく知らなかったりする

## 第三部

### 会社(企業活動)を知る

- 企業とは営利活動
- お金を稼がないと終了
- 現金ないと倒産
- 稼いでない会社は大概別のところに資産がある
- 継続のためには世間に認められる必要がある(社会的意義は「稼ぎ方」の観点)
- 会社規模に応じて変化していく(会社も世間からの見られ方も)
- お給料はどこからくるのか
- 原資 #とは
- 賞与はどう決まるのか
- お給料を増やすには
- 会社の制度を知る
- 就業規則を見よう
- 評価制度を知ろう
- 福利厚生を知ろう
- 会社の製品を知る
- 自社の強み
- 印刷->配送の実績
- 他社より圧倒的な部分はまだない
- これから作っていくよ！
- 製品一覧
- 印刷系
- 会社が何によって成り立っているのか(売上のみを考慮)
- 主要な製品はどのように売上を出しているのか
- 既存製品と新規製品

### 開発進行Tips

- 陥りがちな心理的罠
- 知っているからといってやっているとは限らない
- この中で「言ったでしょ！」と怒られたことがないものだけ手を挙げなさい
- ついつい忘れがち
- 感情は制御が難しい
- 人間だもの
- 「常識」は人それぞれ
- 常識は育ってきた環境に依存する
- 『似非マナー講師界隈じゃ「ハンコはお辞儀させる」のが常識だから』
- [Figure]お前の中ではな
- 人間なので色々あるけどあまり気にしない
- 仕事だけじゃなくてプライベートでも色々あるもの
- 誰もが何かを抱えながら生きているので機嫌が悪い時だってある
- 今日はダメだったな。また今度やろう。
- 人にものを訊く時の注意点
- みんな前提条件が違う
- それぞれ自分のタスクをこなしている
- 知っていることには差がある
- そもそも「あなたが何をしているかを知らない」
- 理解度の差を推し量る
- あなたが知りたい分野について、実はあなたが一番熟知しているかも
- どういう問題が起きていて、何を知りたいのかを伝える
- 相手が知らないことについては説明しよう
- その結果、頭が整理されて答えに辿り着けるかもしれない
- (ラバーダックデバッグ)
- 開発における様々な需要は製品開発の環境変化に対応するため
- 我々は常に競合と戦っている
- 素早く高品質なものが必要となる
- 自動テストの重要性
- 余計なことに時間をかけられない
- チーム作りの重要性
- ユーザの価値観も変化
- 類似製品がすぐ増える
- 「機能」から「体験」へ
- 健康第一
- 瞬発力より持続力
- サービス開発は基本的に長期戦
- 納品日のような定まったタイミング以外は切羽詰まることはない
- 日々変化する状況に対応していく必要がある
- 平均値をどれだけ高くできるか
- 浮き沈みはある。人間だもの。
- 1週間、1ヶ月という期間の中でコンディションを維持する。
- 沈んでいる時は無理しない
- ダメな日はダメなもの。諦めて帰ろう！
- 調子悪いなら休もう！
- 早く快調できた方が結果的にプラスになる

# 研修内容(言語基礎)

## 特定言語の基本文法を習得

- PHP
- 教本を読んでもらう
- Hello, World!
- 各種基本文法を一度は書く
- 関数、クラス、インターフェースの概念を説明

## 課題を実践

### 基礎の確認

- FizzBuzzの実装
- 0~100 までインクリメント
- 出力： 3:Fizz, 5:Buzz 3*5:FizzBuzz
- ループの書きかえ
- FizzBuzzの修正
- 最初に作ったループ文とは別のループ文を採用すること
- 階乗の計算をする関数を作成
- 頭の体操
- 掛け算を行う関数の作成
- 「*」を使ってはならない
- 割り算を行う関数の作成
- 「/」を使ってはならない
- 結果が十分に短い時間で出せること
- (任意)剰余を参照渡しで返すようにする

### 標準関数

- 数式を関数化
- 三平方の定理を関数化
- 数学関数を使用してよいものとする
- 角辺は 短辺,長辺,斜辺 と表現する
- どの辺の値でも求められるようにすること
- 日付の変換/フォーマット
- 現在時刻(DateTime)を返す関数を作成
- タイムゾーンは実行環境に依存とする
- DateTimeを与えられたらUnixタイムに変換して返す関数を作成
- タイムゾーンはUTCとする
- 時刻文字列をDateTimeに変換して返す関数を作成
- タイムゾーンは時刻文字列に従うものとする
- 時刻文字列例: 2020-04-01T14:05:32.000Z
- Unixタイムを与えられたら時刻文字列を返す関数を作成
- タイムゾーンは日本とする
- フォーマット例: 2020-04-01 14:05:32

### オブジェクト思考

- クラスの作成
- 自分を表現するクラスの作成
- メソッドは1つ作成
- 自分を表現するものであれば何でもよい
- 例1: function fullname() { print('Salt Taro'); }
- 例2: function favorite(): String { print('pepper'); }
- 新人らしいフレッシュさを感じられると尚良い
- 社員クラス(抽象クラス)の継承
- 抽象メソッドを定義する
- 新人インターフェースに上記クラスのメソッドを宣言
- 自分クラスに新人インターフェースを適合させる
- 不足しているメソッドを定義する
- すべてのメソッドを実行した結果、本人が判別できるように努めること
- jsonパーサの作成
- jsonの解析(ファイル内のjsonを読み込み、中身をオブジェクトに置き換え)
- 型判定/型変換
- 配列の操作
- UT通過でOK
- jsonシリアライザの作成
- シリアライズしたものはファイルに保存する

# 研修内容(開発ツール)

- 各種ツールを使ってみる
- (人事?)mailer
- (人事?)slack
- git / (SourceTree)
- https://k.swd.cc/learnGitBranching-ja/
- git の練習
- 安全な操作と危険な操作の理解
- git push -f 絶対ダメ
- ローカルでは何やってもイイ
- なんか壊れたってなったら取得し直そう
- 履歴の重要性(コメントも大事)を実感
- 複数のコミットログから問題のある箇所を特定する(コメント適当)
- 複数のコミットログから問題のある箇所を特定する(コメント適切)
- markdown について軽く触れておく
-

# 研修内容(バグ取り合戦)

## 事前準備

- MAMP導入してローカル環境立ち上げ
- Larabel導入

## 第１ステージ

- エラーログを見て問題の箇所を特定->修正
- OutOfBounds
- DivisionByZero
- ArgumentCount
- BadFunctionCall
- エラーログから検索して問題の内容を把握->修正
- DOM操作

## 第２ステージ

- 操作中のバグ発見に対して、再現手順説明と修正->確認までの流れをペアで実践
- A/B でそれぞれ別のプログラムを用意する
- よくあるテストパターンに照らしてバグを仕込む
- 同値チェック
- 閾値チェック
- 異常値チェック
- レアパターン(閏年など)
- なんか期待している結果と違うんだけどパターンのバグ
- 代入ミス
- 期待する値が使われていない(スコープミス)
- 関数内での計算ミス(計算式ミス/型変換ミス)
- どういうバグなのかを特定し、説明する能力/労力によって結果の変化を知る
- (テスト手法などの話には課題としては踏み込まない)

MEMO:

- 定数の扱い（Self::のつけ忘れ）

# スケジュール

## 一週目

1. 開発部案内 & 雑談
1. 第一部 座学 & 言語基礎学習
1. 言語学習基礎
1. 言語学習基礎
1. 第二部 座学 & 開発ツール基礎学習

## 二週目

1. 言語学習基礎 & 開発ツール基礎学習
1. 自習 & バグ取り合戦概要
1. バグ取り合戦1日目
1. バグ取り合戦2日目
1. 第三部 座学 & 会社の製品を使ってみる