Submit Search
Upload
Dev love関西 レガシーコードへの取り組み 20140325
•
1 like
•
1,490 views
Seiichi Sugahara
Follow
at dev love kannsai
Read less
Read more
Software
Report
Share
Report
Share
1 of 63
Download now
Download to read offline
Recommended
レガシーコードとの付き合い方とテストでの話
レガシーコードとの付き合い方とテストでの話
H Iseri
テストスキルを測ってみよう
テストスキルを測ってみよう
Akira Ikeda
テストとリファクタリングに関する深い方法論 #wewlc_jp
テストとリファクタリングに関する深い方法論 #wewlc_jp
kyon mm
テストエンジニアの品格 #automatornight
テストエンジニアの品格 #automatornight
kyon mm
ザ・ジェネラリスト #5000dai
ザ・ジェネラリスト #5000dai
kyon mm
Kaizen process with test #hackt
Kaizen process with test #hackt
kyon mm
テストファースト、自動テストを導入するという事について(@社内勉強会)
テストファースト、自動テストを導入するという事について(@社内勉強会)
kyon mm
20140903 じどうかの窓口特別編 君にもなれる!?テスト自動化エンジニア
20140903 じどうかの窓口特別編 君にもなれる!?テスト自動化エンジニア
SHIFT Inc.
Recommended
レガシーコードとの付き合い方とテストでの話
レガシーコードとの付き合い方とテストでの話
H Iseri
テストスキルを測ってみよう
テストスキルを測ってみよう
Akira Ikeda
テストとリファクタリングに関する深い方法論 #wewlc_jp
テストとリファクタリングに関する深い方法論 #wewlc_jp
kyon mm
テストエンジニアの品格 #automatornight
テストエンジニアの品格 #automatornight
kyon mm
ザ・ジェネラリスト #5000dai
ザ・ジェネラリスト #5000dai
kyon mm
Kaizen process with test #hackt
Kaizen process with test #hackt
kyon mm
テストファースト、自動テストを導入するという事について(@社内勉強会)
テストファースト、自動テストを導入するという事について(@社内勉強会)
kyon mm
20140903 じどうかの窓口特別編 君にもなれる!?テスト自動化エンジニア
20140903 じどうかの窓口特別編 君にもなれる!?テスト自動化エンジニア
SHIFT Inc.
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
Shuji Morisaki
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
Takuto Wada
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編
Noriyuki Mizuno
品質基礎知識
品質基礎知識
Reiko Yamashita
テストを分類してみよう!
テストを分類してみよう!
Kenji Okumura
How to let them in house of quality
How to let them in house of quality
Takahiro Toku
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
Kosuke Fujisawa
Sta introduction in_kyoto #devkan
Sta introduction in_kyoto #devkan
kyon mm
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04
Makoto Nonaka
DeNA QA night #2 presentation
DeNA QA night #2 presentation
Yasuharu Nishi
ソフトウェアテスト入門
ソフトウェアテスト入門
Preferred Networks
Hey It's Not My TDD!
Hey It's Not My TDD!
Yasui Tsutomu
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
gree_tech
nseg第5回勉強会
nseg第5回勉強会
ko ty
私とインクス
私とインクス
Yoshimura Soichiro
企業と勉強会 @nifty エンジニアサポート
企業と勉強会 @nifty エンジニアサポート
Daichi Morifuji
テスト駆動開発入門 - C4K Meetup#2
テスト駆動開発入門 - C4K Meetup#2
Masashi Shibata
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
Tomomi Kajita
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書
Osamu Kawachi
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Dai FUJIHARA
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Rakuten Group, Inc.
ソフトウェア開発の現場風景
ソフトウェア開発の現場風景
Koichi ITO
More Related Content
What's hot
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
Shuji Morisaki
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
Takuto Wada
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編
Noriyuki Mizuno
品質基礎知識
品質基礎知識
Reiko Yamashita
テストを分類してみよう!
テストを分類してみよう!
Kenji Okumura
How to let them in house of quality
How to let them in house of quality
Takahiro Toku
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
Kosuke Fujisawa
Sta introduction in_kyoto #devkan
Sta introduction in_kyoto #devkan
kyon mm
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04
Makoto Nonaka
DeNA QA night #2 presentation
DeNA QA night #2 presentation
Yasuharu Nishi
ソフトウェアテスト入門
ソフトウェアテスト入門
Preferred Networks
Hey It's Not My TDD!
Hey It's Not My TDD!
Yasui Tsutomu
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
gree_tech
What's hot
(13)
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編
現状分析→価値開発→仕様化&テスト設計の展開事例解説:仕様&テスト編
品質基礎知識
品質基礎知識
テストを分類してみよう!
テストを分類してみよう!
How to let them in house of quality
How to let them in house of quality
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
Sta introduction in_kyoto #devkan
Sta introduction in_kyoto #devkan
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04
「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04
DeNA QA night #2 presentation
DeNA QA night #2 presentation
ソフトウェアテスト入門
ソフトウェアテスト入門
Hey It's Not My TDD!
Hey It's Not My TDD!
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
Similar to Dev love関西 レガシーコードへの取り組み 20140325
nseg第5回勉強会
nseg第5回勉強会
ko ty
私とインクス
私とインクス
Yoshimura Soichiro
企業と勉強会 @nifty エンジニアサポート
企業と勉強会 @nifty エンジニアサポート
Daichi Morifuji
テスト駆動開発入門 - C4K Meetup#2
テスト駆動開発入門 - C4K Meetup#2
Masashi Shibata
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
Tomomi Kajita
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書
Osamu Kawachi
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Dai FUJIHARA
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Rakuten Group, Inc.
ソフトウェア開発の現場風景
ソフトウェア開発の現場風景
Koichi ITO
レガシーコードでTDD力を高めよう #agilesamurai
レガシーコードでTDD力を高めよう #agilesamurai
Youtarou TAKAHASHI
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするために
Takafumi Ikeda
KDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フロー
ques_staff
TDDはじめる前に
TDDはじめる前に
Yasui Tsutomu
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
Rakuten Group, Inc.
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-
nishio
「Agileごっこ」で終わらせないために(仮)
「Agileごっこ」で終わらせないために(仮)
Taku Yajima
cedec 2015 techinical artist bootcamp vol.1
cedec 2015 techinical artist bootcamp vol.1
DigitalFrontier
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
Ryo Mitoma
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
5年しかもたない最高のシステムとの向き合い方
5年しかもたない最高のシステムとの向き合い方
Jumpei iwamura
Similar to Dev love関西 レガシーコードへの取り組み 20140325
(20)
nseg第5回勉強会
nseg第5回勉強会
私とインクス
私とインクス
企業と勉強会 @nifty エンジニアサポート
企業と勉強会 @nifty エンジニアサポート
テスト駆動開発入門 - C4K Meetup#2
テスト駆動開発入門 - C4K Meetup#2
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書
デジマ事業会社×リモートワーク×技術者組織=で生まれた魔道書
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
ソフトウェア開発の現場風景
ソフトウェア開発の現場風景
レガシーコードでTDD力を高めよう #agilesamurai
レガシーコードでTDD力を高めよう #agilesamurai
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするために
KDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フロー
TDDはじめる前に
TDDはじめる前に
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-
「Agileごっこ」で終わらせないために(仮)
「Agileごっこ」で終わらせないために(仮)
cedec 2015 techinical artist bootcamp vol.1
cedec 2015 techinical artist bootcamp vol.1
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
テストコードの DRY と DAMP
テストコードの DRY と DAMP
5年しかもたない最高のシステムとの向き合い方
5年しかもたない最高のシステムとの向き合い方
Dev love関西 レガシーコードへの取り組み 20140325
1.
レガシーコードへの取り組み 事例紹介 菅原
誠一
2.
自己紹介 菅原 誠一
•京都にある精密機器製造会社勤務 •生産技術 – 社内工場のソフト開発、保守、運用など – 工場からの問い合わせ対応 •入社10年目
3.
2007~2009年 海外ボランティア
4.
青年海外協力隊 • JICA(独立行政法人
国際協力機構)が支援する、 発展途上国でのボランティア活動。 • 派遣期間:2年 • 派遣国:70カ国 • 派遣人数:1758名(男757名、女1,001名) (2014年1月) • 職種:200種以上(農業、土木、教師など多数) • 対象年齢:20~39歳 • 派遣期間中は、現地生活費と積立金が支給
5.
モザンビーク基礎情報 • 面積:80.2万平方キロメートル(日本の約2.1倍)
• 人口:2,137万人(2007年) • 独立:1975年 • 内戦:1982年~1992年 • 首都:マプト(人口約107万人、2005年) • 民族:マクア・ロムウェ族など43部族 • 公用語:ポルトガル語 • 現地語:民族語との土着語(マクア、シャンガネ) • 宗教:キリスト教(41%)、イスラム教(17.8%)、原始宗教 • 気候:温暖(沖縄に近い)
6.
モザンビークはどこ? ① ②
③ ①ガーナ ②ソマリア ③モザンビーク
7.
CDT(CENTRO DE DESENVOLVIMENTO
TECNOLÓGICO)
8.
授業の風景 • 授業
– プログラミングI、プログラミングII • JAVA基礎、応用 – オブジェクト指向プログラミング • UML – WebプログラミングI、 WebプログラミングII • PHP、MySQL基礎、応用 • 学校の機器のメンテナンス – PCの修理、ウィルス除去
9.
生徒達(1)
10.
生徒達(2)
11.
モザンビークと レガシーコードの共通点
12.
混沌 レガシーコード勉強会 20140321.
pptx
13.
昔ながらのやり方
14.
駄目なところを探し出すときりが無い
15.
伝えたいこと
16.
良いところを探す
17.
信じる
18.
そのうち素晴らしい 景色が見えてくるはず
19.
まだ、道の半ば 今日はみなさんと一緒に レガシーコードについて考えたいと思います
よろしくお願いします
20.
本日の内容 • 私の現場のレガシーコードの紹介
• TDDの導入(2012/10~) – テストのないコード増加に歯止め – レガシーコードでのTDD作業 • 受け入れテストの自動化(2014/2~) – 大きくテストで保護 • この一年の振り返り • 今年したいこと
21.
レガシーコードとは? 『何年も前に誰かが作り、 内容が複雑で何をしているのかよく分からず、
まともな仕様書もない』 http://codezine.jp/article/detail/4103 『単にテストのないコード』 テストのないコードは悪いコードである。どれだけうまく書かれているかは関係ない。 どれだけ美しいか、オブジェクト指向か、きちんとカプセル化されているかは関係ない。 テストがあれば、検証しながらコードの動きを素早く変更することが出来る。 テストがなければ、コードが良くなっているのか悪くなっているのか本当に分からない (レガシーコード改善ガイド はじめにより)
22.
現場のレガシーコード • 言語
– C++ • クラス数 – 1446個 • コード – 642131行 • 生産技術のノウハウの塊 • 生まれから10年はたってる?(不明) • 今も日々成長している
23.
なぜ、レガシーコードに こだわるのか? •
捨てられない – 生産技術のノウハウの塊 – 誰も仕様を知らない、ドキュメントなし • 人が育たない – レガシーコードをお手本にしている現実 – 動けばいいんじゃないの? – 自分も書いてきた・・・ • モチベーション – 仕事をすればレガシーコードが増える – 新規に作り直したとしても、また、レガシーコード
24.
現場で困っていること • 新規機能追加
– 既存の振舞いを変えずに、新しい振舞いを追加する • 新しい振舞いを追加 – みんな興味ある⇒お金、時間、人 • 既存の振舞いを変えず! – ほとんど考慮されない⇒保証して当然だと思わる – 変更の規模に関わらずコストはかかる – どんどん負荷は増えていく 細々した 変更が多い 追加コスト <<<< 既存の振舞いの保証コスト
25.
目指している事 • 既存の振る舞いを保証するための工数を減らす
• 改造規模に見合った工数を実現したい • 手段 – テストの自動化 • テストの無いコードを減らしたい =レガシーコードを減らしたい!
26.
TDDの導入 2012/10~
27.
TDD技術取得 • TDD
Boot Camp – 短期間でテスト駆動を体験 – ペアプロ体験 • 2013年6月 Agile Academy 版 • 2013年8月 岡山開催 – チーム員 4名で参加 • 2013年8~12月 – 社内で読書会 – 遊び感覚でペアプロ TDDのこころ(和田卓人) • 一番ひどいコードをテストフレームに入れる
28.
レガシーコードでTDDで実践 • テストフレーム内に入らない
– 激しい依存関係 – そもそも構造がない – GUIコントロールと設備の制御が混ざっている・・・ やたら時間がかかる! • 仕事は待ってくれない・・・ • 時間がないから、TDD出来ない・・・ • TDDしたりしなかったり・・・ • どうやったら出来るかな?
29.
当時困っていたこと 新しい人の戦力化 経験による
知識 ソフトの 知識 ベテラン 新しい人 工場内ソフト ソフトの内容は 分かったけど・・・ ノウハウの塊 実物を 知らない人への 説明が難しい
30.
OJT(On-the-Job Training) と組み合わせる
• 2014/1~ • 教育を口実にペアプロとTDDの工数を確保 • Win-Win – 自分 • コーディングしながら説明 • 社内文書作成、手動テストを任せる⇒時間 • コードの内容を知っているので安心 – 新しい人 • 意味不明なコードを触ることの不安の解消 • 知らないと分からないことで費やす無駄な時間の短縮
31.
ペアプロの効果 • 集中出来る
• 思い込みによる間違いを防ぐ • 妥協できなくなる • 冷静になれる • 学習効果(予習⇒実習⇒復習) – テストフレームに入れる⇒TDD⇒書類作成
32.
実際のレガシーコードで TDD作業実録 2014/3/13~3/20
33.
仕事の流れ こんなのしたいのだけど 変更内容を検討
プログラム 社内書類作成(仕様書) テスト⇒社内審議 工場にリリース 現場責任者
34.
出荷製品の確認ソフト このソフトの機能 •工場のオペレーター用
•注文情報の参照 •製品内部情報を取得 •注文情報と製品内部情報を比較 •オペレーターに結果を表示 •確認結果を保存 製品 注文情報 間違いなく 製品が 作られていることを 確認する
35.
新製品でも この確認ソフトを使いたい 従来製品
製品C 製品A 製品B 新製品D 現場責任者
36.
調査結果 • 変更箇所
– クラス:FormMain – メソッド:CheckGas • 変更内容 – 確認するパラメータ数が従来製品と違う • 従来1~4個⇒5個 • パラメータを持っていない
37.
レガシーコードでTDD 0. 変更したいクラスをテストで保護
1. 失敗するテストケースを記述 2. コンパイル 3. テストを通過させる 4. 重複を取り除く 5. 繰り返す ココ レガシーコード改善ガイド P104 TDDのこころ(和田卓人)
38.
まず、テストフレーム内で TFormMainの実体化に挑戦 •
クラス:FormMain • 2000行 • メソッド:CheckGas • 171行 • メソッドの機能 • 製品情報を取得 – 製品との通信機能 • 注文情報と内部情報を比較 • オペレーターに結果を表示 – GUI操作
39.
格闘2時間 依存関係激しすぎる・・・ コンパイル出来ない
断念
40.
方針を変える • テストフレームに入れる対象を小さくする
• メソッドオブジェクトの取り出し(P345) – 大きなメソッドをクラスとして取り出す – 対象行数:2000行⇒171行 • コンパイル任せ(p331) – 変数がない→メンバー変数追加 – メソッドがない→インターフェースの抽出(p377)
41.
1.5時間後 捕獲成功!
42.
既存機能の保護 • 仕様化テスト(p200)
– 製品A、B、Cに対する機能の保護 製品A 製品B 製品C • 偽装オブジェクトの作成(p27) – 製品との通信 – 画面とのインターフェース • テストを書く – 製品A、B、Cに対して仕様化テスト
43.
仕様化テスト終了 作業時間5時間
44.
TDDで機能追加 • 追加したい機能のテスト書く
• テストが失敗することを確認 • テストを通過 • リファクタリング • 『メソッドオブジェクトの取り出し』で取り出したクラスを、 元のクラス(FormMain)に戻す • 作業時間3時間
45.
ふりかえり • TDDで変更
– 実体化失敗 2時間 – メソッドオブジェクトの抽出 1.5時間 – 仕様化テスト 5時間 – 機能追加 3時間 • 合計工数 11.5時間×2人 =23時間 • 従来のやり方 – 変更3時間くらい(推測) 純粋にコーディングの 工数だけを見ると 7倍以上
46.
23時間の工数は妥当か? • 従来のやり方で、誰がしても3時間?
• プログラム以外の工数11時間は新しい人に任せることが出来た • 教育には結構時間がかかる • 過去の負債はいつかえすの? 調査 プログラミング データ更新 テスト 書類作成 リリース 従来のやりかたを 続けている限り 永遠にレガシーコード はなくならい 作業の割合
47.
Windowsアプリ 受け入れテストの自動化 2014/2~
48.
レガシーコードのジレンマ コードを変更するためには、テストを整備する必 要がある。多くの場合、テストを整備するために
は、コードを変更する必要がある レガシーコード改善ガイド P19 • 対策 ペアプロ レガシーコード改善ガイド P333
49.
もっと大きな網が欲しい • 思い切ったコードの変更をしないとテストフ
レームに入らないコード • 手動テストの負荷がどんどん増えている • 手動テストのミスが多くなっている 受け入れテストの自動化 がしたい!
50.
GUIのテストは 一般的に難しいと言われているが •
工場内アプリの環境はかなり特殊 – 操作画面は変わらない – 操作画面はシンプル • 自動化出来ない要因 – 工場でないと接続できないハードウェア – 計測器の出力が必要 – 工夫すれば回避可能 • コストに見合わない? – 毎回、同じテストをしている – 手作業によるミスを頻発 • 一番知っているのは自分
51.
じゃあ、なんでやらない? • 自分が今の業務を続けている限り、今の業務は回るから
• 自動化するには、自分が今の業務から抜ける必要がある 誰か変わってくれ~
52.
自分の時間を確保 • 人を育てる
– OJT:ペアプロ、TDD • 一応、筋は通す – 上司にお願い ⇒OK – 社内の報告会でテスト自動化による工数削減を説明 ⇒なんでやらないのかと言われる • 日常の業務は次から次へとやってくる 日常業務を断つ
53.
育児時短勤務 • 2014/4/1スタート
• 8:30~15:15 • 1日6時間勤務 • 圧倒的に時間がない • 家族の事情です • 2012/10に会社に報告 吉と出るか? 凶と出るか?
54.
GUI自動化ツール • Codeer.Friendly(コーディア・フレンドリー)
– 株式会社Codeer(コーディア) • http://www.codeer.co.jp/home • 特徴 – プロダクトプロセスを、「プログラムレベル」で、テ ストプロセスから操作することができます – 小規模な結合テスト~GUIテストまで対応します • 選んだ理由 – C#でプログラム出来る – 工場内でしか使えない計測器の疑似入力を内部 メソッドを呼ぶことで実現したい
55.
この一年間の振り返り • TDD技術の取得(TDDBC、読書会)
• OJTとしてペアプロを導入、TDDを実践 • 人を育て自分の仕事を引き継ぎ • テスト自動化の準備 • 日常業務を断つ • 自分の時間を確保
56.
レガシーコード改善自体は楽しい • フレームワークに入れたときの達成感
• パズルゲームのような楽しさ • 仕様化テストを書いた後の征圧感 • 過去の作業者の思考に思いを巡らす • 劇的にコード量が減る爽快感 • コードが綺麗になっていく • コードが本来の姿を取り戻す
57.
この1年、悩んできたこと • TDDが良いと分っていても、TDD出来ない
• 自動テストにした方が良いと分っていても、自 動化出来ない • どうやったら、現場で実践できるか? • 現場特有の問題と組み合わせることで上手く 行くこともあった(OJT) • 自分の状況を利用してみたりした(時短勤務)
58.
今、感じている事 • マネージメントの問題ではないのか?
– 時間、人 • 混乱した現場⇒レガシーコードが生まれる? • 自らのマネージメントする – 自らの強みを知る • 工場、生産工程、知識 • リファクタリングが好き – 時間を管理する • 何に時間を取られているのか? – もっとも重要なことに集中する • 手作業⇒自動化
59.
参考になった本 自分の強みは何か? 時間を管理する
ストレングス・ファインダー 才能とは、無意識に繰り返される思考、感情、行動のパターン 7つの習慣実践例 今抱えている仕事を 全部吐き出す 一日の初めにスケジュール を立てる
60.
思い込みを解くゲーム あなたが今解決したいことを思い浮かべてください Step1
出来ない理由を上げてみてください (多ければ多いほどいい) Step2 文章を反転して、出来るに変えてみてください 例) 自信がないから、勉強会が出来ない ↓ 自信がないから、勉強会が出来る 自信があるから、勉強会が出来る P228 ①どの文章に自分の感情が反応しますか? そこに気づきがあるかもしれない ②無理やりにでも出来る理由を並べると、出来る気がしてくる
61.
今年の目標 • 片付けには2種類ある
– 祭りの片付け • コツ:一気に、短期間に、完璧に片付ける – 日常片付け 祭りの片付け 受け入れテストの自動化 CI環境の導入 新しい開発環境へ移行
62.
ようやく自分の強みで戦える
63.
ご清聴ありがとうございました
Download now