---
# System prepended metadata

title: 今後の活動について

---

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


# 目標

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

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

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

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

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

- 

# 概要

- 研修期間
    - 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. 第三部 座学 & 会社の製品を使ってみる





