1. KPTの大事なこと
1.1. 意義
1.1.1. 小さい成功体験を積んで自信をつける
1.2. 姿勢
1.2.1. ちょっと良くしたい
1.3. 続けることについて
1.3.1. 続けたい
1.4. 報告の場
1.4.1. 頻度
1.4.1.1. 一週間に一度
1.4.2. 時間
1.4.2.1. 10分～15分
1.4.3. 内容
1.4.3.1. 若手が1週間KPTをやってどう感じたか話す
1.4.3.1.1. 若手1人3分
1.4.3.2. 話した内容やSlackの若手_2020に書いてある内容がKPTの内容が意義や姿勢からずれていないか先輩にチェックしてもらう
1.4.3.3. KPTの改善方法に精神論が入っていないか先輩にチェックしてもらい、改善方法の再設定や深堀りするアドバイスをもらう
2. その他
2.1. いやしの村
2.1.1. 計画
2.1.1.1. 課題を更に小さな課題に分割する
2.1.1.1.1. 電話で要件を聞いても対応できない
2.1.1.1.2. システムが分からない
2.1.1.1.3. どういう保守作業をしているのか分からない
2.1.1.2. 目標と現状の自分とのギャップを課題にする
2.1.1.2.1. 電話で要件を聞いても対応できない
2.1.1.2.2. システムが分からない
2.1.1.2.3. どういう保守作業をしているのか分からない
2.1.1.3. 目標を明確にする
2.1.1.3.1. 自分が電話での対応ができるようになる状況を目指す
2.1.1.4. 分割した課題をいつ解決するか
2.1.1.4.1. 計画
3. サンクスUP
3.1. 理想の新人は何を見ているか
3.1.1. 新人・若手の評価基準を作るためにやっている
3.1.1.1. その人は何を見ていますか？
3.1.1.1.1. 先輩の仕事
3.1.1.1.2. 笑顔
3.1.1.1.3. 会社の雰囲気
3.1.1.1.4. わくわくの仕組み
3.1.1.1.5. 売上
3.1.1.1.6. こういう新人を評価したい
3.1.1.2. その人は何を聞いていますか？
3.1.1.3. その人は何を考えていますか？
3.1.1.4. その人は何を話しますか
3.1.1.4.1. 行動なので他の人に見える
3.2. つらくなりそうなことでも正直に話す
3.2.1. 追い詰められた場合が多い
3.2.2. どういう事を考えているか
3.2.2.1. 未来
4. KPTのルール
4.1. 午前中にTryできるものを必ずTryに1つは入れる
4.2. 河岸の考えたこと(プロセス)を大事にしていく
4.3. 社長だったらこう考えるのではというものをイメージしてKPTを作る
4.3.1. 一人でKPTを回せるようになるため
4.4. TRYリスト
4.4.1. イレギュラーなことが起きて時間が後ろ倒しになりそうな場合に巻き返す方法をTryに入れてみる
4.5. 今後のP候補
4.5.1. 金谷さん一人に依存している
4.5.1.1. 金谷さんが会議などで不在の場合、進まない状況からの脱却が必要
4.5.1.1.1. そのためのTryを考える
4.5.2. 中山さんからの指摘が周りに共有されていない
4.5.3. PGの指摘が多く、品質が担保されていない
4.6. 今後のT候補
4.6.1. 新しいことを始めた時期
4.6.1.1. 自分の位置を確認してもいいのでは
4.6.2. 報告のためのTry実施はやめる
4.6.2.1. 目標達成のために必要そうなTryならやる
5. STT
5.1. PG→PTの進め方
5.1.1. 画面の指摘反映PG1本終了
5.1.1.1. 細かい手順
5.1.1.2. 指摘内容確認
5.1.1.3. 修正に掛かる時間見積もり
5.1.1.4. 画面レイアウト修正
5.1.1.5. 指摘反映PG
5.1.1.6. 動作確認
5.1.1.7. コミット→プッシュ
5.1.1.8. プルリクエストの指摘ごとにコメント記述
5.1.2. 指摘反映PGが終わった画面のPT
5.2. PT
5.2.1. エビデンス作成
5.2.1.1. 画面起動時外観
5.2.1.2. フル桁チェックエビデンス
5.2.1.3. 入力チェックエビデンス
5.2.1.4. 更新確認エビデンス
5.2.1.5. 入力項目1つずつ入力して検索、エビデンス
5.2.2. テストデータ作成
5.2.2.1. フル桁で問題が無いかチェックするため
5.2.2.1.1. 表にDB定義書のデータ貼り付け
5.2.2.2. ローカルでテストデータを作る
5.2.2.2.1. 他の人が弄る可能性があるため
5.2.2.2.2. 最新DBをDUMP化
5.2.2.2.3. DUMPファイルインポート
5.2.2.2.4. iniファイル更新
5.2.2.3. テストデータを作ったらDumpファイルを作る
5.2.2.3.1. PT完了前に作成
5.2.2.4. 懸念点
5.2.2.4.1. DB定義書の循環参照
5.2.2.5. AWSでテストデータ作る?
5.2.3. PS仕様書にチェックを入れる
5.2.3.1. 処理内容
5.2.3.1.1. 時間掛かる
5.2.3.2. 処理内容_イベント処理
5.2.3.2.1. 簡単そう
5.2.3.3. 処理内容_入力チェック
5.2.3.3.1. 簡単そう
5.2.3.4. 処理内容_メッセージ
5.2.3.4.1. 簡単そう
5.2.3.5. 画面表示_SQL
5.2.3.5.1. SQL修正?
5.2.3.5.2. PS修正していない項目がありそう
5.2.3.6. 共通テスト
5.2.3.6.1. プログラム仕様書_PTからシートコピー
5.2.3.6.2. ホワイトボックステスト
5.2.3.7. テストできないものはチェックの隣にできない理由を記述
5.2.4. UI_項目設計書
5.2.4.1. Teams上で修正
5.2.4.2. 桁数不安
5.2.5. 不具合修正
5.2.5.1. 不具合発見
5.2.5.1.1. 不具合を記録
5.2.5.1.2. 不具合を報告
5.2.5.1.3. 不具合を修正
5.2.6. テストの流れ
5.2.6.1. 画面起動
5.2.6.1.1. フル桁のテストデータ作成
5.2.6.2. エビデンス
5.2.7. 困ったこと
5.2.7.1. 各コントロールの名称を出す時
5.2.7.1.1. SGCustomerの名称
5.3. 規約の話
5.3.1. 開発規約はコスモさんの下でPGするなら当たり前に守らなければいけないこと
5.3.1.1. 他にも使えるやつほど優先度上げないといけない
5.3.1.1.1. ★の数はコスモさんの中での重要度
5.3.1.1.2. 優先度は自分の中で決める
5.3.2. 自分の中で重要だと思っているか
5.3.2.1. メモを取ってなかった
5.3.2.2. コスモさん以外でも今後も使えるものを残していってほしい
5.3.2.3. 勉強したことをアウトプット(技術的な質問などを発言)する
5.3.3. 横川さんの話
5.3.3.1. 技術的なスキル
6. 便利ツール
6.1. DB定義書からフル桁テストデータ作成
6.1.1. 過去
6.1.1.1. DB定義書からデータ型・桁数・項目名・定義名をコピーして手で貼り付け
6.1.1.1.1. 縦のデータを半自動で横に張り替えしている
6.1.2. 現状
6.1.2.1. 開いているDB定義書からDB定義書からデータ型・桁数・項目名・定義名を取得してテストデータ出力
6.1.2.1.1. シート名手動入力
6.1.3. 課題
6.1.3.1. 項目名に合わないデータが生成される
6.1.3.2. テーブル名を入力してデータ取得したい
6.1.4. 理想
6.1.4.1. DB定義書からデータ型・桁数・項目名・定義名を取得してテストデータ出力
6.1.4.1.1. 手順
6.2. EXCELからSQLのINSERT文生成
6.2.1. 現状
6.2.1.1. カラムのみカンマ区切りで連結
6.2.2. 課題
6.2.2.1. データ部分の生成ができていない
6.2.2.2. INSERT文の生成処理ができていない
6.2.3. 理想
6.2.3.1. EXCELからSQLのINSERT文生成
6.2.3.2. データ型に応じて文字型はシングルクォーテーションで囲み、数値型は囲まない
6.3. 項目を入れたらMLANG検索
6.4. DB定義書から必須項目だけフル桁のテストデータ作成
6.4.1. 現状
6.4.1.1. 開いているDB定義書からDB定義書からデータ型・桁数・項目名・定義名を取得してテストデータ出力
6.4.1.1.1. シート名手動入力
6.4.2. 課題
6.4.2.1. 主キーと副キーの
6.4.2.2. テーブル名を入力してデータ取得したい
6.4.3. 理想
6.4.3.1. DB定義書からデータ型・桁数・項目名・定義名を取得してテストデータ出力
6.4.3.1.1. 手順
6.5. 特定のセルに入力があったら自動でファイル保存する
6.5.1. 特定の列に「済」と入力されたらファイルを保存するマクロ
6.5.1.1. 現状
6.5.1.1.1. マクロの作り方が分からない
6.5.1.2. 課題
6.5.1.2.1. マクロの作り方を調べる
6.5.1.2.2. 特定の列に入力があった時に動作する処理を調べる
6.5.1.2.3. 特定の文字が入力されたら一定の動作をする記述を調べる
6.5.1.3. 理想
7. HSKの若手が目指すべき必要な能力
7.1. 全部できれば、完璧超人レベル（若手問わず目指すべきもの）
7.2. 若手問わず目指すべきもの
7.3. 能力
7.3.1. プロジェクトのスケジュールを把握している
7.3.2. 定時で仕事を終わらせられる
7.3.3. 関係会社・お客様との良好な関係を築くことができる
7.3.4. こちらにとって不利な事でもプロジェクトにとって有利なことであれば進んで発信できる
8. 2021年KPT
8.1. 11月_KPT
8.1.1. 2021/11/22(月)
8.1.1.1. ノートPCの下キーが壊れた
8.1.1.1.1. 会社の備品キーボードを貸してもらった
8.1.1.2. P
8.1.1.2.1. 新しいキーボードで打ち間違いが多発
8.1.1.3. T
8.1.1.3.1. ブラインドタッチだとミスが多い
8.1.1.3.2. キーボードを見ながらだとミスが減る
8.1.2. 2021/11/10(水)
8.1.2.1. Keep
8.1.2.1.1. 質問の内容を考えずに「わからない」「困っている」という意思表示を2回する。
8.1.2.2. Problem
8.1.2.2.1. 予定通りに作業が終わらない
8.1.2.3. Try
8.1.2.3.1. 難易度が高くなったPGに対して、質問の内容を考えずに「わからない」「困っている」という意思表示を2回する。
8.1.2.4. 次のKPT
8.1.2.4.1. 意思表示の回数を増やしたらPGのスピードが上がった
8.1.2.4.2. コスモさんが提示する工数には足りていない
8.1.2.4.3. 別のアプローチ
8.1.3. 2021/11/11(木)
8.1.3.1. KPT
8.1.3.1.1. Problem
8.1.3.1.2. Try
8.1.3.1.3. Keep
8.1.3.2. 問題
8.1.3.2.1. 社長に見積もりの時間が遅れるという意思表示ができなかった
8.1.3.3. 意思表示の種類を増やす
8.1.3.3.1. 手段
8.1.3.3.2. 機会
8.1.3.3.3. 種類
8.1.4. 2021/11/12(金)
8.1.4.1. Keep
8.1.4.1.1. 質問の内容を考えずに「わからない」「困っている」という意思表示を2回する。
8.1.4.2. Problem
8.1.4.2.1. 予定通りに作業が終わらない
8.1.4.3. Try
8.1.5. 2021/11/15(月)
8.1.5.1. どうやって工夫していくか考える
8.1.5.1.1. 課題30個
8.1.5.2. 問題から課題
8.1.5.2.1. 電話対応で事実を伝えてしまった
8.1.5.2.2. 工数の見積りが甘い
8.1.5.2.3. PG
8.1.5.2.4. 色々な人に意思表示
8.1.6. 2021/11/16(火)
8.1.6.1. 理想像
8.1.6.1.1. 発言する前に相手がどう感じるか考える
8.1.6.1.2. 自分の中だけで完結させない
8.1.6.1.3. 事実を伝えるのではなく建前を伝える事を覚える
8.1.6.2. 分解できる項目
8.1.6.2.1. 明細の行が複数ある場合は考慮した見積もりを出す
8.1.6.2.2. 遅れそうな時は再度工数の見積りをする
8.1.6.2.3. UI関係
8.1.6.3. 問題
8.1.6.3.1. 時間外にレビューを依頼して
8.1.7. 2021/11/17(水)
8.1.7.1. KPTのProblemを考える
8.1.7.1.1. 入力伝票の検索画面をやってみて起こった問題をProblemにする
8.1.7.2. 始まり
8.1.7.2.1. 画面の修正で自分の見積もりが1時間のところ、思ったより15分ほどオーバーした
8.1.7.3. 問題
8.1.7.3.1. 次の入力伝票の検索画面をやってほしいと言われた
8.1.8. 2021/11/18(木)
8.1.8.1. KPTのProblemを考える
8.1.8.1.1. 今日のできごと
8.1.8.2. 始まり
8.1.8.3. 問題
8.1.8.3.1. 工数見積もりの際にソースの中身を確認していなかった
8.1.8.3.2. レビュー前に不要な処理を全部拾いきれなかった
8.1.8.3.3. 確認回数が多かった
8.1.8.4. Try
8.1.8.4.1. 工数見積もりの際にソースの中身を確認する
8.1.8.4.2. 作業見積もりの正確性を上げたい
8.1.8.4.3. 時間を短くしたい
8.1.8.4.4. PSになさそうな処理が多くある
8.1.8.4.5. ソースを見て、PSに比べて行数が多そうかチェックする
8.1.8.4.6. ソースにある関数のヘッダコメントを見て、理解できなさそうな関数の個数をカウントする
8.1.9. 2021/11/19(金)
8.1.9.1. K
8.1.9.1.1. 修正方法を説明して、理解を貰う
8.1.9.1.2. ソースにある関数のヘッダコメントを見て、理解できなさそうな関数の個数をカウントする
8.1.9.1.3. ソースを見て、PSに比べて行数が多そうかチェックする
8.1.9.2. KPTのPとTを考える
8.1.9.2.1. Tは小さい粒度でOK
8.1.9.3. Try
8.1.9.3.1. PGで特に時間がかかっている部分を短縮したい
8.1.10. 2021/11/24(水)
8.1.10.1. K
8.1.10.1.1. ソースにある関数のヘッダコメントを見て、理解できなさそうな関数の個数をカウントする
8.1.10.1.2. ソースを見て、PSに比べて行数が多そうかチェックする
8.1.10.1.3. 修正方法を説明して、理解を貰う
8.1.10.1.4. 備品のキーボードに慣れる
8.1.10.2. P
8.1.10.2.1. 進め方のTryはできているが、技術的なTryができていない
8.1.10.3. T
8.1.10.3.1. 金谷さんにPGしている際に技術的な問題点がないか質問する
8.1.10.3.2. 金谷さんが思う河岸がPGをしている中で技術的な問題点(致命的)を1つ上げてもらう
8.1.10.3.3. 問題点を夕方のKPTでTryに落とし込む
8.1.11. 2021/11/25(木)
8.1.11.1. テーブルの使われ方・項目の役割がわかっていない
8.1.11.1.1. これを理解していないと結合条件の話ができない
8.1.11.1.2. 具体的な画面で分からないことを書く
8.1.11.1.3. なりたい自分
8.1.11.1.4. テーブルの使われ方・項目の役割がわかるとどうなるのか
8.1.11.2. P
8.1.11.2.1. 注文書番号の検索画面
8.1.11.3. T
8.1.11.3.1. 画面で使われている役割が分からないテーブルの個数を数える
8.1.11.3.2. 役割が分からない契約受渡場所マスタの役割を金谷さんに説明して理解・意見を貰う
8.1.11.3.3. 役割が分からない契約進捗データファイルの役割を金谷さんに説明して理解・意見を貰う
8.1.11.3.4. 明日のPは今日やってみて問題がなかった場合は別のProblemとTryを考える
8.1.12. 2021/11/26(金)
8.1.12.1. P
8.1.12.1.1. 前日に挙げていたTryが実施できなかった
8.1.12.1.2. メンションを入れる前に一言伝えておく
8.1.12.2. T
8.1.12.2.1. 本日のKPTをSlackにアップした後で、Tryに関係するメンバーに一言伝えておく
8.1.12.2.2. 本日のKPTをSlackにアップした後、Tryに関係するメンバーの名前をメンションに追加する
8.1.12.2.3. 役割が分からない契約進捗データファイルの役割を金谷さんに説明して理解・意見を貰う
8.1.13. 2021/11/29(月)
8.1.13.1. K
8.1.13.1.1. 修正方法を説明して、理解を貰う(こういう時にこういう事を説明するといいかなというものを新しく考えてみる)
8.1.13.1.2. ソースにある関数のヘッダコメントを見て、理解できなさそうな関数の個数をカウントする
8.1.13.1.3. ソースを見て、PSに比べて行数が多そうかチェックする
8.1.13.1.4. テンキーを使って数字を入力してみる
8.1.13.1.5. キーボードを見ながら文字を打つ
8.1.13.1.6. 画面で使われている役割が分からないテーブルの個数を数える
8.1.13.2. P
8.1.13.2.1. 設計原簿の検索画面
8.1.13.2.2. 見積もり工数内で作業が終わらない(一人で悩んだ時間が長い)
8.1.13.3. T
8.1.13.3.1. Tryの質はそのまま
8.1.13.3.2. Tryの数を増やす
8.1.13.3.3. T内容
8.1.14. 2021/11/30(火)
8.1.14.1. K
8.1.14.2. P
8.1.14.2.1. 見積もり工数内で作業が終わらない(一人で悩んだ時間が長い)
8.1.14.3. T
8.1.14.3.1. PGの作業ボリュームから分からないことに対して悩んで良いトータル時間を河岸が設定する
8.1.14.3.2. 一人で考えてから @金谷さんに話をするまでに掛かった時間を記録する
8.2. 12月KPT
8.2.1. 2021/12/01(水)
8.2.1.1. K
8.2.1.1.1. 一画面あたりこう修正するという説明を@金谷さんに最低5種類する
8.2.1.1.2. 修正方法を説明して、理解を貰う
8.2.1.1.3. ソースを見て、PSに比べて行数が多そうかチェックする
8.2.1.1.4. テンキーを使って数字を入力してみる
8.2.1.1.5. キーボードを見ながら文字を打つ
8.2.1.2. P
8.2.1.2.1. 一人で悩む時間が長い
8.2.1.2.2. 説明の文章を考えるのに時間が掛かる
8.2.1.3. T
8.2.1.3.1. データ出力SQLに掛かる自分の目算を出す
8.2.1.3.2. コスモに対して27本を1回で確認事項を投げるのか、分割して確認するのか、とそれに伴う作業イメージを@金谷さんと相談する
8.2.1.3.3. コスモさん側への確認事項の大枠を口頭で@金谷さんに説明する
8.2.1.3.4. SQLの穴空きのある項目を報告する前に@金谷さんに文章を確認してもらう
8.2.1.3.5. SQL1本あたり悩んでもいい時間を@金谷さんに相談する
8.2.1.3.6. 横展開できないイレギュラーパターンが出てきた場合は横展開できそうなものから進める
8.2.1.3.7. SQLの穴空きのある項目を報告する際に文章を考えてもいい時間を@金谷さんに相談する
8.2.2. 2021/12/02(木)
8.2.2.1. 明日朝のKPTは社長がいないのでKPTは自分で考えてSlackに書く
8.2.2.2. K
8.2.2.3. P
8.2.2.4. T
8.2.3. 2021/12/03(金)
8.2.3.1. 作業が終わりそうな光が見えたのはいつなのか
8.2.4. 2021/12/03(金)
8.2.4.1. K
8.2.4.1.1. 質問の内容を考えずに「わからない」「困っている」という意思表示をする
8.2.4.1.2. 修正方法を説明して、理解を貰う
8.2.4.2. P
8.2.4.2.1. 作業時間が目算とずれて
8.2.4.2.2. 一人で悩む時間が長い
8.2.4.2.3. 説明の文章を考えるのに時間が掛かる
8.2.4.3. T
8.2.5. 2021/12/06(月)
8.2.5.1. P
8.2.5.1.1. ビュー作成がすぐ終わると思って後回しにしていたところ、予想より時間が掛かった
8.2.5.1.2. SELECT文が流れる状態にして後でまとめてビュー作成すれば良いと自分の中で思っていた
8.2.5.1.3. ビュー1本作成に掛かる手順と時間を把握しておらず、横展開する時に予定工数よりも時間が掛かった
8.2.5.2. T
8.2.5.2.1. 横展開出来そうなものは1本作ってから見積もりを再修正して報告をする
8.2.6. 2021/12/07(火)
8.2.6.1. K
8.2.6.2. P
8.2.6.2.1. STTはAWS(クラウド)でDB管理
8.2.6.2.2. FJH(CDSS・ヘルス)のテストの時に本番環境のデータをふっとばした記憶がある
8.2.6.2.3. 月次更新の画面では更新処理を行うテーブルが20個
8.2.6.2.4. 更新処理の影響範囲の把握に時間がかかり、予定工数内に終わらない
8.2.6.2.5. DBのデータをローカルに落としてもいいか@金谷さんに相談する
8.2.6.3. T
8.2.6.3.1. 更新処理のSQLを流す前に必ずテーブルのバックアップを取る
8.2.6.3.2. 金谷さんにテーブルのバックアップを取る効率の良い方法がないかアドバイスを貰う
8.2.7. 2021/12/08(水)
8.2.7.1. K
8.2.7.1.1. 修正の方針を説明して、理解を貰う
8.2.7.2. P
8.2.7.2.1. 仕様書の記述に不備があった時に修正が必要になり、作業時間が伸びた
8.2.7.2.2. 一人で悩む時間が長い
8.2.7.3. T
8.2.7.3.1. 他作業割り込み・予定工数より時間が掛かったなどイレギュラーが発生した時にどう対応しているか@大森さんに聞く
8.2.7.3.2. 午後にやる予定のTRY
8.2.8. 2021/12/09(木)
8.2.8.1. K
8.2.8.1.1. 修正の方針を説明して、理解を貰う
8.2.8.2. P
8.2.8.2.1. 修正の際に大枠の説明ができず、相手にあまり伝わっていない
8.2.8.2.2. 金谷さん一人に依存している
8.2.8.2.3. 金谷さん以外の人（Pメンバーに説明しても同じ結果が得られる)
8.2.8.2.4. 修正方針を整理するのに時間が掛かっている
8.2.8.3. T
8.2.8.3.1. 考えを整理するのに時間が掛かっていることを金谷さんに伝える
8.2.8.3.2. 今回は足りないところを見つける目的で考えを整理する前に修正方針を説明させてくださいと金谷さんに伝える
8.2.8.3.3. 考えを整理する前に修正方針を@金谷さんに説明する
8.2.8.3.4. 考えを整理せずに修正方針を伝えた時に改善できそうなところを1つ以上書き出す
8.2.8.3.5. 一旦保留
8.2.8.3.6. 金谷さんのPTのやり方の説明からこういう風に説明するということを学ぶ
8.2.9. 2021/12/10(金)
8.2.9.1. K
8.2.9.1.1. 方針を説明して、理解を貰う
8.2.9.2. P
8.2.9.2.1. PT工程でどういう流れでテストを行うのか整理できていない
8.2.9.2.2. テストデータの作成が遅い
8.2.9.3. T
8.2.9.3.1. PTをどういう流れでどのくらい掛かりそうなのか30分でまとめる
8.2.9.3.2. まとめたものを見せながら、作業ごとにどのくらい掛かりそうか・想定している難易度など所感を@金谷さんに説明する
8.2.9.3.3. 文字型と桁数を入力したらフル桁の値を出す表を作ってテストデータを作ってみる
8.2.10. 2021/12/13(月)
8.2.10.1. K
8.2.10.1.1. PTの方針を説明して、理解を貰う
8.2.10.2. P
8.2.10.2.1. 作業が遅れそうなタイミングで報告できておらず、アドバイスを貰えるチャンスを逃している
8.2.10.2.2. テストデータの作成が見積もり工程の1/3を占めている(時間がかかっている)
8.2.10.3. T
8.2.10.3.1. 作業が遅れそうと気付いたタイミングでの報告を2回以上やる
8.2.10.3.2. 金谷さんにPT用のテストデータを素早く作る際にどういうことに気を付けているか質問する
8.2.10.3.3. テストデータ作成に掛かる時間はPT一つにどのくらいが妥当なのか金谷さんに聞く
8.2.10.3.4. 設計原簿の検索画面でテストデータの作成に2時間掛かっていたが、金谷さんに妥当性を聞く
8.2.10.3.5. あ
8.2.11. 2021/12/14(火)
8.2.11.1. K
8.2.11.1.1. PTの方針を説明して、理解を貰う
8.2.11.2. P
8.2.11.2.1. 議事録をどのくらいの粒度で書けば良いか分からず、打ち合わせの内容を理解するのに集中できない
8.2.11.3. T
8.2.11.3.1. 過去に受けた中山さんたちからの指摘をまとめる
8.2.11.3.2. 当事者意識を持って打ち合わせに参加する
8.2.11.3.3. 12/13のコスモ打ち合わせの議事録を見る
8.2.11.3.4. 議事録をどのくらいの粒度(会話全部/要点のみ、など)で取るべきか金谷さんに聞く
8.2.11.3.5. 遅れていない場合
8.2.11.3.6. 金谷さんに今回の打ち合わせで議事録を取る目的は何だったのか聞く
8.2.12. 2021/12/15(水)
8.2.12.1. K
8.2.12.1.1. PTの方針を説明して、理解を貰う
8.2.12.2. P
8.2.12.2.1. 作業が遅れそうなタイミングで報告できておらず、アドバイスを貰えるチャンスを逃している
8.2.12.2.2. Pの深堀りが少ない
8.2.12.3. T
8.2.12.3.1. 30分未満の作業でイレギュラーが起きて遅れそうな時に1回以上報告する
8.2.12.3.2. 30分以上の作業で見積もり時間の半分が経ったタイミングで、順調か遅れているかの報告を1回以上する
8.2.13. 2021/12/16(木)
8.2.13.1. K
8.2.13.2. P
8.2.13.2.1. 今後のP候補
8.2.13.3. T
8.2.13.3.1. 午前中にできるTRY
8.2.13.3.2. T:出荷先の検索のPT工数見積もりを午前中のうちに作成
8.2.13.3.3. T:出荷先の検索のPT工数見積もり表のキャプチャーをSlack(このスレッド)に貼り付ける
8.2.13.3.4. T:13時ごろ金谷さんに出荷先の検索のPT工数見積もりについて所感を聞く
8.2.13.3.5. T:テストデータ作成とホワイトボックステストで予定時間の半分が経った時点で状況報告を @金谷さんに1回以上する
8.2.14. 2021/12/17(金)
8.2.14.1. K
8.2.14.1.1. PTの方針を説明して、理解を貰う
8.2.14.2. P
8.2.14.2.1. ホワイトボックステストの作業手順が確立しておらず、見積もり時間と実作業時間に差がある
8.2.14.3. T
8.2.14.3.1. ホワイトボックステストの手順を自分がより把握するために、ホワイトボックステストの作業を分解する
8.2.14.3.2. 分解したものを見積もりにタスクとして挙げる
8.2.14.3.3. ホワイトボックステストの予定時間の半分が経った時点で @金谷さんに状況報告を1回以上する
8.2.15. 2021/12/20(月)
8.2.15.1. K
8.2.15.2. P
8.2.15.2.1. 残り7.5日で年内に予定しているPT10本が終わらない可能性が高い
8.2.15.3. T
8.2.16. 2021/12/21
8.2.16.1. K
8.2.16.2. P
8.2.16.2.1. サポートしていると自分の作業時間が減る
8.2.16.3. T
8.2.17. 2021/12/22
8.2.17.1. K
8.2.17.1.1. PTの方針を説明して、理解を貰う
8.2.17.2. P
8.2.17.2.1. 指摘反映PGで一人で悩む時間が長い
8.2.17.3. T
8.2.18. 2021/12/24
8.2.18.1. K
8.2.18.1.1. PTの方針を説明して、理解を貰う
8.2.18.2. P
8.2.18.2.1. 指摘反映PGで一人で悩む時間が長い
8.2.18.3. T
8.2.18.3.1. 聞かないと分からないことは切り分けてから1分以内に聞く、自分で考えて分かりそうなものは5分考えて分からなければ@金谷さんに聞く
8.2.19. 2021/12/23
8.2.19.1. K
8.2.19.1.1. PTの方針を説明して、理解を貰う
8.2.19.2. P
8.2.19.2.1. 指摘反映PGで一人で悩む時間が長い
8.2.19.2.2. PT工程は確認する資料が指摘対応PGの時よりも多く、確認不足で手戻りが起こりやすい
8.2.19.3. T
8.2.19.3.1. 聞かないと分からないことは切り分けてから1分以内に聞く、自分で考えて分かりそうなものは5分考えて分からなければ@金谷さんに聞く
8.2.19.3.2. PTで手戻りを起こさないようにするために、横川さんがPTを行う際に必要な資料と説明を整理する時間を10分取る
8.2.19.3.3. 素早くテストデータを作ってもらうために河岸がPT作業で使っているダンプデータを渡すか新しく作ってもらうか@金谷さんに相談する
8.2.20. 2021/12/27(月)
8.2.20.1. K
8.2.20.1.1. PTの方針を説明して、理解を貰う
8.2.20.2. P
8.2.20.2.1. 横川さんに振る作業(画面)の起動方法が複雑
8.2.20.2.2. 指摘反映PGで一人で悩む時間が長い
8.2.20.3. T
8.2.20.3.1. 一人で考え込む時間や手戻りを横川さんが起こさないようにするために、疑問点は逐一投げてもらうように依頼する
8.2.20.3.2. 今日は金谷さんが忙しいため、聞かないと分からないことは分からないことをメモして金谷さんの空き時間に聞く
8.2.20.3.3. 自分で考えて分かりそうなものは5分考えて分からなければ考えたことをメモして金谷さんの空き時間に聞く
8.2.21. 2021/12/28(火)
8.2.21.1. K
8.2.21.1.1. 困った時の意思表示・状況報告をする
8.2.21.2. P
8.2.21.2.1. 指摘対応PGの修正中にテーブル同士の紐付き方が分からなかった
8.2.21.2.2. スケジュールより見栄を優先してしまい相談しなかった
8.2.21.2.3. 悩んでいたら年末までに加工発注照会のPTが終わらない
8.2.21.3. T
8.2.21.3.1. 長時間悩まないようにするために1時間ごとに状況報告する
8.2.21.4. 成果
8.2.21.4.1. 見栄が絡むと中々行動できないという癖があることを再認識した
8.2.22. 2021/12/29(水)
8.2.22.1. K
8.2.22.1.1. 困った時の意思表示・状況報告をする
8.2.22.2. P
8.2.22.3. T
8.2.22.4. 成果
9. 2022年KPT
9.1. 2022年1月
9.1.1. 2022/01/04
9.1.1.1. K
9.1.1.1.1. 困った時の意思表示・状況報告をする
9.1.1.2. P
9.1.1.2.1. 正月休み明けで指摘対応PGの細かい所を忘れている可能性がある
9.1.1.3. T
9.1.1.3.1. 休み前に残したメモ(加工発注照会(一覧)_PTメモ)を確認しつつ、修正方針で分からないところがあれば@金谷さんに聞く
9.1.1.4. 成果
9.1.2. 2022/01/18
9.1.2.1. K
9.1.2.1.1. 困った時の意思表示・状況報告をする
9.1.2.2. P
9.1.2.2.1. 仕入発注入力の課題対応PGの残課題に難しいものが多い
9.1.2.3. T
9.1.2.3.1. 5分悩んでも分からないパターンがあれば@金谷さんに質問する
9.1.2.4. 成果
9.1.3. 2022/01/20
9.1.3.1. K
9.1.3.1.1. 困った時の意思表示・状況報告をする
9.1.3.2. T
9.1.3.2.1. 5分悩んでも分からないパターンがあれば@金谷さんに質問する
9.1.3.3. P
9.1.3.3.1. 仕入発注入力の課題対応PGの残課題に難しいものが多い
9.1.3.4. 成果
9.1.4. 2022/0/1/21
9.1.4.1. K
9.1.4.1.1. 困った時の意思表示・状況報告をする
9.1.4.2. P
9.1.4.2.1. STTの他メンバーのサポートをする際に相手が不安にならないようにする
9.1.4.3. T
9.1.4.3.1. 修正漏れを起こさないためにSQL修正後にA5mk2で実行、AppendSQLを記述した後に元ソースとWinMergeで差分を確認する(自己ダブルチェック)
9.1.4.3.2. 20日はあまり下調べできなかったため、関係する画面の資料を読み、最低限の知識を付ける
9.1.4.4. 成果
9.2. 2022年2月
9.2.1. 2022/02/04
9.2.1.1. K
9.2.1.1.1. 詰まった時の意思表示をする
9.2.1.1.2. 初めてやる事は何かやろうとする前に報告する
9.2.1.2. P
9.2.1.3. T
9.2.1.4. 成果
9.2.2. 2022/02/21
9.2.2.1. K
9.2.2.1.1. 詰まった時の意思表示をする
9.2.2.2. P
9.2.2.2.1. Gitの機能を活用しておらず、独自の時間がかかる手作業でPG修正を行っていたため、時間のロスだけでなくミスが発生していた
9.2.2.3. T
9.2.2.3.1. やっていて面倒だと思う作業は他の人がどうしているか1日1個質問する
9.2.2.4. 指摘
9.2.2.4.1. 「なぜ質問せずに自分で調べたり自分で何とかしようとしたか」についてはどんな分析をしたか
9.2.2.4.2. 1.何か問題があった時に質問せず自分で解決できそうだと思って何とかしようとするのが6割
9.2.2.4.3. 3.手作業など面倒な作業をやっている時に、システムで楽にできることを知らずにやっているのが3割ほど
9.2.2.4.4. 2.面倒な作業を改善する方法はあるとは思うものの、調べるのが面倒で改善しないまま現状維持で続けているのが1割
9.2.2.4.5. 動機
9.2.3. 2022/02/22
9.2.3.1. K
9.2.3.1.1. 詰まった時の意思表示をする
9.2.3.1.2. やっていて面倒だと思う作業は他の人がどうしているか1日1個質問する
9.2.3.2. P
9.2.3.2.1. IT課題に取り掛かる際に修正対象の画面の仕様(データ連携周り)を理解しないまま修正を行ってしまい、修正している途中でソースを読み込んで仕様を確認しながらのIT対応になってしまい、予想よりも時間が掛かった
9.2.3.3. T
9.2.3.3.1. 理解してからIT課題に取り掛かった方が修正の対応がしやすいと思うので、過去に自分がPGを行っていない画面のIT課題の場合は、IT課題前にソースを読む時間を10分用意する
9.2.3.3.2. 過去に自分がPGを行っている画面の場合でも、他の人が修正を加えている可能性があるためコミットログを見る時間を5分用意する
9.2.4. 2022/02/24
9.2.4.1. K
9.2.4.1.1. 詰まった時の意思表示をする
9.2.4.1.2. やっていて面倒だと思う作業は他の人がどうしているか1日1個質問する
9.2.4.2. P
9.2.4.3. T
10. STT
10.1. 画面遷移
10.1.1. チェック観点
10.1.1.1. 画面を表示した際に元画面が表示された場合はOK(チェック)
10.1.1.2. 画面を再度表示した際に呼び出し元画面が表示されていない(新しく画面が表示された)場合はバツ
10.1.2. メニュー
10.1.2.1. 内示登録・照会
10.1.2.1.1. 登録
10.1.2.1.2. 照会
10.1.2.2. 生産計画登録・照会
10.1.2.2.1. 委託加工
10.1.2.2.2. 製品仕入
10.1.2.2.3. 2次加工
10.1.3. 発注画面
10.1.3.1. 画面を表示した際に元画面が表示された場合はチェック
10.1.3.2. 画面を表示した際に呼び出し元画面が表示されていない場合はバツ
10.1.3.3. メニューから入力を起動した場合、一覧ボタンは表示されていないのが正しい
10.1.3.4. メニュー(加工)
10.1.3.4.1. 加工発注入力
10.1.3.4.2. 加工発注照会(一覧)
10.1.3.5. メニュー(仕入)
10.1.3.5.1. 仕入発注入力
10.1.3.5.2. 仕入発注照会(一覧)
10.2. 赤黒作成_元黒比較
10.2.1. 検査
10.2.1.1. 画面
10.2.1.1.1. 現在作成済み伝票の表示伝票番号と入力した表示伝票番号の比較
10.2.1.2. 連携
10.2.1.2.1. 最後の実績の赤黒区分と項目チェック
10.2.1.3. リカバリ
10.2.1.3.1. 最後の実績の赤黒区分と項目チェック
10.2.2. 生機
10.2.2.1. 画面
10.2.2.1.1. 現在作成済み伝票の表示伝票番号と入力した表示伝票番号の比較
10.2.3. 投入
10.2.3.1. 画面
10.2.3.1.1. 現在作成済み伝票の表示伝票番号と入力した表示伝票番号の比較
10.3. 数値項目
10.3.1. 空白・ゼロ・数値判定
10.3.1.1. 変更前空白
10.3.1.1.1. 変更後空白ではない
10.3.1.2. 変更前数字
10.3.1.2.1. ゼロより大きい
10.3.1.2.2. ゼロより小さい
10.3.1.3. 変更後
10.3.1.3.1. 数値
10.3.1.3.2. ゼロ
10.4. 実績系画面
10.4.1. 原価設定
10.4.1.1. 生機費設定
10.4.1.1.1. GetKibataCost
10.4.1.1.2. 仕入発注入力_半製品仕入(新規/修正)
10.4.1.1.3. ジャーナル共通更新(生機費設定)
10.4.1.1.4. 仕入加工場への出荷(色NG反・加工C反)の生機費設定
10.4.2. SGRenkei
10.4.2.1. 反番重複チェック
10.4.2.1.1. 再加工チェック
10.4.3. 加工投入
10.4.3.1. 検査
10.4.3.1.1. 色相判定
10.4.3.1.2. 出荷
10.4.3.2. 入力チェック
10.4.3.2.1. 黒
10.4.3.2.2. 赤
10.5. 実績更新
11. 結果
11.1. 2022/05/17
11.2. コスモの仕事で1人月の単金が貰えるようになった
11.2.1. 頑張ったことがどう作用して結果につながったか分からない
11.2.2. 頑張ったこと
11.2.2.1. 人を参考にする
11.2.2.1.1. 旧
11.2.2.1.2. 新
11.2.2.2. 軽いことでも相談する
11.2.2.2.1. 旧
11.2.2.2.2. 新
11.2.2.3. 自分にできることを増やす
11.2.2.3.1. 旧
11.2.2.3.2. 新
11.2.2.4. 自分一人で抱え込まない
11.2.2.4.1. 旧
11.2.2.4.2. 新
11.2.3. なぜ
11.2.3.1. これらの頑張りがCSN側と単金交渉を行う金谷さんに認められ、1人月の単金を貰えるようになった
11.2.4. 他の人の意見
11.2.4.1. 沼田さん
11.2.4.1.1. 頑張ったことの理由付け
11.2.4.2. 大森さん
11.2.4.2.1. 現実問題、コスモさん側から河岸を指名されて1人月貰っているわけではない
11.2.4.2.2. コスモさんと河岸の間には金谷さんがいる
11.2.4.2.3. 頑張った結果
11.2.4.3. 山岸さん
11.2.4.3.1. 結果から逆算してつなげてみればいい
11.2.4.3.2. 1人月の単金が貰えるようになったのはなぜ？
11.2.4.4. 坪内さん
11.2.4.4.1. 評価をさらに伸ばすために目標を決めるべき
12. 小数桁数
12.1. M
12.1.1. 0.00
12.1.1.1. .00をくっつける
12.2. kg
12.2.1. 0.000
12.2.1.1. .000をくっつける
12.3. 反数
12.3.1. 0.0
12.3.1.1. .0をくっつける
12.4. 金額・枚
12.4.1. 0
12.4.1.1. 小数点をくっつけない
13. 納入先
13.1. 入力不可
13.1.1. 実績あり
13.1.1.1. 納入先に入力あり
13.2. 入力可
13.2.1. 実績なし
13.2.2. 納入先に入力なし
13.3. 現状
13.3.1. 実績ありの場合は全ての行で入力不可