Suche senden
Hochladen
とある事業の脱レガシー
•
44 gefällt mir
•
8,260 views
Hisateru Tanaka
Folgen
Melden
Teilen
Melden
Teilen
1 von 88
Jetzt herunterladen
Downloaden Sie, um offline zu lesen
Empfohlen
Selenium再入門-W3C勧告とページオブジェクトパターンと私-201707webエンジニア勉強会#2神田
Selenium再入門-W3C勧告とページオブジェクトパターンと私-201707webエンジニア勉強会#2神田
Y Watanabe
業務アプリにおける VB との付き合い方
業務アプリにおける VB との付き合い方
s_earlgrey
PHPUnit でよりよくテストを書くために
PHPUnit でよりよくテストを書くために
Yuya Takeyama
gitを使って、レポジトリの一部抽出forkしてみました
gitを使って、レポジトリの一部抽出forkしてみました
Takako Miyagawa
CakePHP3ウォークスルー
CakePHP3ウォークスルー
Tomoki Hasegawa
behatエクステンションの作り方
behatエクステンションの作り方
Ryo Tomidokoro
HTMLに学ぶ夫婦円満のコツ
HTMLに学ぶ夫婦円満のコツ
Hisateru Tanaka
Yii Framework 2.0 いま求められるRAD標準とは #phpkansai
Yii Framework 2.0 いま求められるRAD標準とは #phpkansai
Hisateru Tanaka
Weitere ähnliche Inhalte
Andere mochten auch
Wordbench fukuoka
Wordbench fukuoka
Junji Manno
AWS はぶっちゃけ安いのか?
AWS はぶっちゃけ安いのか?
manabusakai
PHPCON fukuoka 2015 CodeIgniter update
PHPCON fukuoka 2015 CodeIgniter update
Takako Miyagawa
phpspecで始めるBDD
phpspecで始めるBDD
Yuuki Takezawa
レイヤードアーキテクチャを意識したPHPアプリケーションの構築
レイヤードアーキテクチャを意識したPHPアプリケーションの構築
Masashi Shinbara
ソーシャルアプリにおけるRedisの活用事例とトラブル事例
ソーシャルアプリにおけるRedisの活用事例とトラブル事例
leverages_event
Laravel5を使って開発してみた
Laravel5を使って開発してみた
Takeo Noda
よくある業務開発の自動化事情 #jjug_ccc #ccc_cd3
よくある業務開発の自動化事情 #jjug_ccc #ccc_cd3
irof N
PHP x AWS でスケーラブルなシステムをつくろう
PHP x AWS でスケーラブルなシステムをつくろう
Taiji INOUE
Andere mochten auch
(9)
Wordbench fukuoka
Wordbench fukuoka
AWS はぶっちゃけ安いのか?
AWS はぶっちゃけ安いのか?
PHPCON fukuoka 2015 CodeIgniter update
PHPCON fukuoka 2015 CodeIgniter update
phpspecで始めるBDD
phpspecで始めるBDD
レイヤードアーキテクチャを意識したPHPアプリケーションの構築
レイヤードアーキテクチャを意識したPHPアプリケーションの構築
ソーシャルアプリにおけるRedisの活用事例とトラブル事例
ソーシャルアプリにおけるRedisの活用事例とトラブル事例
Laravel5を使って開発してみた
Laravel5を使って開発してみた
よくある業務開発の自動化事情 #jjug_ccc #ccc_cd3
よくある業務開発の自動化事情 #jjug_ccc #ccc_cd3
PHP x AWS でスケーラブルなシステムをつくろう
PHP x AWS でスケーラブルなシステムをつくろう
Ähnlich wie とある事業の脱レガシー
HCL Digital Experience 9.5 プラクティショナースタジオ概要
HCL Digital Experience 9.5 プラクティショナースタジオ概要
Software Info HCL Japan
The History of Reactive Extensions
The History of Reactive Extensions
Yoshifumi Kawai
C#の強み、或いは何故PHPから乗り換えるのか
C#の強み、或いは何故PHPから乗り換えるのか
Yoshifumi Kawai
SpringOne Platform Replay -Pivotal Cloud Foundry-
SpringOne Platform Replay -Pivotal Cloud Foundry-
CASAREAL, Inc.
Web2.0 講演スライド 2008/2/26
Web2.0 講演スライド 2008/2/26
kishida4slideshare
Integral Technology 第2回ユーザカンファレンス 〜すべてをクラウドで解析するための方法〜
Integral Technology 第2回ユーザカンファレンス 〜すべてをクラウドで解析するための方法〜
Rescale Japan株式会社
20160702 linuxでもできるc#でアプリ開発
20160702 linuxでもできるc#でアプリ開発
Takayoshi Tanaka
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
Insight Technology, Inc.
エンジニアと"協同"してサービスをつくる
エンジニアと"協同"してサービスをつくる
Ishikawa Yuya
Pinoco phptal-phpcon-kansai
Pinoco phptal-phpcon-kansai
Hisateru Tanaka
Html5時代のクリエイターのあり方
Html5時代のクリエイターのあり方
Masakazu Muraoka
Hpc server講習会第3回応用編
Hpc server講習会第3回応用編
Osamu Masutani
HCL Digital Experience 9.5 ご紹介資料
HCL Digital Experience 9.5 ご紹介資料
Software Info HCL Japan
Garden introduction for dea users public
Garden introduction for dea users public
Takehiko Amano
フロントエンド技術の変遷
フロントエンド技術の変遷
Ryo Higashigawa
201806 jawsug bgnr12
201806 jawsug bgnr12
Yuki Yoshida
HTML5時代のwebクリエイターに必要なこと
HTML5時代のwebクリエイターに必要なこと
Masakazu Muraoka
Builderscon Tokyo 2017
Builderscon Tokyo 2017
Shinichiro Takezaki
2018 builderscon airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう
2018 builderscon airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう
BrainPad Inc.
ASP.NET MVC Part 2
ASP.NET MVC Part 2
Yoshitaka Seo
Ähnlich wie とある事業の脱レガシー
(20)
HCL Digital Experience 9.5 プラクティショナースタジオ概要
HCL Digital Experience 9.5 プラクティショナースタジオ概要
The History of Reactive Extensions
The History of Reactive Extensions
C#の強み、或いは何故PHPから乗り換えるのか
C#の強み、或いは何故PHPから乗り換えるのか
SpringOne Platform Replay -Pivotal Cloud Foundry-
SpringOne Platform Replay -Pivotal Cloud Foundry-
Web2.0 講演スライド 2008/2/26
Web2.0 講演スライド 2008/2/26
Integral Technology 第2回ユーザカンファレンス 〜すべてをクラウドで解析するための方法〜
Integral Technology 第2回ユーザカンファレンス 〜すべてをクラウドで解析するための方法〜
20160702 linuxでもできるc#でアプリ開発
20160702 linuxでもできるc#でアプリ開発
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
エンジニアと"協同"してサービスをつくる
エンジニアと"協同"してサービスをつくる
Pinoco phptal-phpcon-kansai
Pinoco phptal-phpcon-kansai
Html5時代のクリエイターのあり方
Html5時代のクリエイターのあり方
Hpc server講習会第3回応用編
Hpc server講習会第3回応用編
HCL Digital Experience 9.5 ご紹介資料
HCL Digital Experience 9.5 ご紹介資料
Garden introduction for dea users public
Garden introduction for dea users public
フロントエンド技術の変遷
フロントエンド技術の変遷
201806 jawsug bgnr12
201806 jawsug bgnr12
HTML5時代のwebクリエイターに必要なこと
HTML5時代のwebクリエイターに必要なこと
Builderscon Tokyo 2017
Builderscon Tokyo 2017
2018 builderscon airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう
2018 builderscon airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう
ASP.NET MVC Part 2
ASP.NET MVC Part 2
Mehr von Hisateru Tanaka
第21回関西PHP勉強会 ReactPHPは もっと流行って欲しい #phpkansai
第21回関西PHP勉強会 ReactPHPは もっと流行って欲しい #phpkansai
Hisateru Tanaka
ダイクストラの構造化 プログラミングに学ぶ 結婚生活
ダイクストラの構造化 プログラミングに学ぶ 結婚生活
Hisateru Tanaka
PHPカンファレンス関西2014 Yii Framework 2.0 遅れてきた5番目のフレームワーク
PHPカンファレンス関西2014 Yii Framework 2.0 遅れてきた5番目のフレームワーク
Hisateru Tanaka
Grunt front-osaka-1-lt-tanaka
Grunt front-osaka-1-lt-tanaka
Hisateru Tanaka
Phpstormちょっといい話
Phpstormちょっといい話
Hisateru Tanaka
#phpmatsuri LT大会システムの中身
#phpmatsuri LT大会システムの中身
Hisateru Tanaka
&& || and or まぜるな危険
&& || and or まぜるな危険
Hisateru Tanaka
Phpcon kansani-2013-pinoco
Phpcon kansani-2013-pinoco
Hisateru Tanaka
はじめてのGit #gitkyoto
はじめてのGit #gitkyoto
Hisateru Tanaka
PhpStormを使おう --高槻からは快速急行が早くなります #jbugj
PhpStormを使おう --高槻からは快速急行が早くなります #jbugj
Hisateru Tanaka
いまどきのYiiフレームワーク
いまどきのYiiフレームワーク
Hisateru Tanaka
Kphpug beginners-2
Kphpug beginners-2
Hisateru Tanaka
関西PHP勉強会 php5.4つまみぐい
関西PHP勉強会 php5.4つまみぐい
Hisateru Tanaka
Word pressのテーマは firephpでハックすれば 良かったのか
Word pressのテーマは firephpでハックすれば 良かったのか
Hisateru Tanaka
関西Php勉強会のlimeの話
関西Php勉強会のlimeの話
Hisateru Tanaka
Yiiフレームワークを使ってみた
Yiiフレームワークを使ってみた
Hisateru Tanaka
Mehr von Hisateru Tanaka
(16)
第21回関西PHP勉強会 ReactPHPは もっと流行って欲しい #phpkansai
第21回関西PHP勉強会 ReactPHPは もっと流行って欲しい #phpkansai
ダイクストラの構造化 プログラミングに学ぶ 結婚生活
ダイクストラの構造化 プログラミングに学ぶ 結婚生活
PHPカンファレンス関西2014 Yii Framework 2.0 遅れてきた5番目のフレームワーク
PHPカンファレンス関西2014 Yii Framework 2.0 遅れてきた5番目のフレームワーク
Grunt front-osaka-1-lt-tanaka
Grunt front-osaka-1-lt-tanaka
Phpstormちょっといい話
Phpstormちょっといい話
#phpmatsuri LT大会システムの中身
#phpmatsuri LT大会システムの中身
&& || and or まぜるな危険
&& || and or まぜるな危険
Phpcon kansani-2013-pinoco
Phpcon kansani-2013-pinoco
はじめてのGit #gitkyoto
はじめてのGit #gitkyoto
PhpStormを使おう --高槻からは快速急行が早くなります #jbugj
PhpStormを使おう --高槻からは快速急行が早くなります #jbugj
いまどきのYiiフレームワーク
いまどきのYiiフレームワーク
Kphpug beginners-2
Kphpug beginners-2
関西PHP勉強会 php5.4つまみぐい
関西PHP勉強会 php5.4つまみぐい
Word pressのテーマは firephpでハックすれば 良かったのか
Word pressのテーマは firephpでハックすれば 良かったのか
関西Php勉強会のlimeの話
関西Php勉強会のlimeの話
Yiiフレームワークを使ってみた
Yiiフレームワークを使ってみた
とある事業の脱レガシー
1.
とある事業の脱レガシー ∼技術的負債を取り戻すプロジェクトの物語∼
2.
時は201x年、数年に渡る大規模リニューアルプロジェ クトを経て立ち上がった新サービス。 しかしその正体はなんと、10年前のPHP入門書を読 んだプログラマーと、20年間SQL以外書いたことが ないDBエンジニアの手による、MVCもバージョン履 歴もない動的ページの山だったのです。
3.
そこに偶然現れたある平凡な助っ人PHPエンジニア... やがて彼は、データセンターにはWebとDBの2サー バーしか存在しないのに何故かテスト環境があるとい う、次なる衝撃の事実を知るのでした...
4.
…って導入を考えてたんですが、トリを務めるとか予 想外! ちゃんとしなきゃ… なんかいろいろ中途半端ですみません
5.
たなかひさてる @tanakahisateru Pinoco developer PHPTAL contributor Firebug
translation contributor Yii framework user PhpStorm user フルスタックエンジニア(笑)
6.
レガシーとは
7.
単に下手なだけのプログラム レガシー
8.
レガシー (Legacy) 1. 遺産,遺贈(財産) 2.
受け継いだもの,遺物
9.
• なぜか置き換えできずに古いまま残されたもの • まったく役に立たなければ単に捨てられるだけ。何 らかの恩恵があるから存在する
10.
古いとわかっているのになぜ 置き換えられないのか • より良い代替物を開発できない • どうして動いているのかわからない •
既存の設計が無駄に複雑すぎて、全ての知識を吸い 上げきれない • 作りなおして失敗するよりはそのまま使うほうが安 全だ
11.
魔術的 ブラックボックス
12.
Thanks to http://to-a.ru/
13.
どうやったら 置き換えられるのか • 再現性のある設計/プロセスに変換する • 属人化せず、論理的な推論の連続で仕 組みを成り立たせる •
絡み合うレガシー部分に引きずられず、 一気通貫に進める
14.
科学的 多くのエネルギーが必要
15.
Thanks to http://to-a.ru/
16.
•レガシー = 魔術 •リプレース
= 科学
17.
レガシーシステムの デメリットを明確にする 魔術的なものの多くは次の2つに分類できます: • 科学で置き換え可能なもの …(a) •
科学的に考えると実は無駄 …(b) (a) は本質的に必要 (b) が保守工数を圧迫すること = デメリット
18.
例 この変数 $hoge は200行 前に
if でこれが入るかも しれないし、そうでなけれ ばその前の行の初期値で… ってものすごい検索とスクロールですよ ね、心折れますね $hoge = 0; if ($fuga > 100) { $hoge = 1; } // この間200行 echo $hoge;
19.
例 この変数 $hoge は200行前に
if でこれが入るかも しれないし、そうでなければその前の行の初期値で… ってものすごい検索とスクロールですよね、心折れますね $hoge = $conditionalContext->getHoge();
20.
• なんで200行もステップ解析しなきゃなんないの? • 目視で見落としない? •
これどう考えても無駄だよね • 手続きを宣言(AはBである)に変換する! $hoge = $conditionalContext->getHoge();
21.
「保守プログラマーは複雑な手続きを解析するのが仕 事だ」という思い込みの蔓延 = 魔術的概念しかなかっ た時代の信仰形態、あるいは、これまで信仰を集めて きたものは変えられないという諦め 脱レガシーとは、この組織的な思い込みモードから脱 却することである
22.
(注: フィクションです)
23.
うっかり「私の経験では」とか言っちゃう かもしれませんが、これはフィクションで す。いいですか、フィクションですからね。
24.
全4編 • 第一話 プログラミング •
第二話 開発プロセス • 第三話 インフラ • 最終回 人事
25.
• A社 =
開発/サーバー設備を提供、委託先 • B社 = 事業会社、発注元 • P氏 = とあるPHPer B社にP氏がジョインしました。
26.
第一話 プログラミング
27.
B社「このまえ依頼したフォームの改修どう?」 P氏「この2000行でいちどもfunctionを見かけてません ね」 B社「あー、全機能だいたいこの調子で組んであるよ、こ れ」
28.
index.php 画像はイメージです
29.
P氏「ああああーっもう今回改修する機能、実装はぜ んぶ作り直します」 B社「え、すごく手間かかるんじゃない?」 P氏「自分、まだ正社員じゃないですよね。てことは 工数オーバーしても個人事業主の未請求扱いですよね。 B社的には、動作保証さえしてれば、工数リスク関係 ないですよね」
30.
<?php reruire __DIR__ .
/../src/bootstrap.php ; MyApplication::create()->run(MyController::class); index.php MyController MyService index.phtml models* create access use render
31.
<?php require __DIR__ .
’/../src/bootstrap.php’; MyApplication::create()->run( MyController::class, ); index.php view.php edit.php <?php require __DIR__ . ’/../src/bootstrap.php’; MyApplication::create()->run( MyController::class, ‘view’ ); <?php require __DIR__ . ’/../src/bootstrap.php’; MyApplication::create()->run( MyController::class, ‘edit’ ); ※.htaccessとか書けませんからね
32.
• 今やっておかないと将来の自分にとって都合が悪い • だからやる •
この判断が、物語のはじまりとなった…
33.
事業会社と受託開発は 違うという読み 売上 → 予算
→ 成果 → 売上… • 運用スタッフが売上を出す ITは直接売上を出さない • ITスタッフに分配される予算は限られる • 予算と成果のサイクルに「魔術的無駄」があるとす ぐに負のスパイラルになる
34.
その後P氏の実装を原型として、徐々に他のフロント 機能もB社自身が作るようになりました。 P氏の設計を真似して、他の機能が個別に改修されて いきます。 最終的に、その手法はサイト全体でひとつに統一され、 フレームワークとなりました。 その頃には、P氏もすっかりB社の社員です。
35.
社内フレームワーク 社内フレームワークがすべて悪というわけではない 社内フレームワーク = たしかに技術的負債ではある 重要なことは、その技術的負債が: •
より多くを返済するための借り入れなのか • 返済よりも利子が高くつく種類のものでないか を見極めること
36.
レガシーシステムを含んで どうやってテストするのか • クラスをクラスでテストするPHPUnitでは、そ もそもクラスが存在しない… • アプリケーションサーバーの外から生スクリプ トの振る舞いをテストしたい •
Behatもいいんだけど…. • PHP 文法で BDD 風テストできる Codeception がオススメ
37.
Behat Codeception
38.
レガシーコードを どうやって解析したか • PhpStorm には
Find by usage (変数 /関数使用箇所検索) がある • PhpStormを開発スタッフ全員分買っ てもらいました
39.
お買い求めは こちらのサイトへ
40.
第二話 開発プロセス
41.
B社内で開発する部分が増えてきたので、バージョン 管理にGitを採用しました。 最初にサーバーがなくても、手元で使い始められるの で導入しやすかったためです。
42.
[重要] かならずGitかMercurialを使って下さい。 未経験者にはSubversionのほうが簡単だろうという のは、あまり使っていない人がいいかげんなことを 言ってるだけです。だまされないで。
43.
B社「でも枝分かれいっぱいあって難しそう」 P氏「じゃあ枝を作らなければいいんですよ」
44.
しばらく master と
pshi と yamada ブランチ(仮名) 固定で運用。 それでも、ありとなしでは雲泥の差。
45.
P氏「コード書けましたテストもOKです」 B社「よーし更新しよう」 P氏「え、それ何やってるんですか」 B社「え、いや、タイムスタンプ見て、FFFTPで変更 したファイルだけを...」
46.
うひゃぁ!
47.
git diff [prev
tag] --name-status M config/main.php M src/hoge/index.php M src/hoge/js/fuga.js A web/css/new-style.css D web/img/tmp.png それGitでできるよ
48.
git diff [prev
tag] --name-only | git checkout-index --prefix=./FTPするやつ/ --stdin それGitでできるよ
49.
タイムスタンプが いかに信用出来ないか
50.
P氏「あれ? こっちで変更してないファイル、タイム スタンプ上がってますね」 B社「もしもしA社? 昨日そっちで何かやった?」 A社「あれとこれと...
そういえば /inc あたりに...」 B社・P氏「ちょっとまって、それこっちでも使って る!」
51.
カオス
52.
P氏「テストサーバの index_2tmp.php って何です か」 B社「知らないなぁ、使ってないやつじゃない?」 P氏「じゃあこの
index3.php も要らないですね」 B社「それは本番にもあるから使ってるやつ」
53.
とめどなくカオス
54.
B社「もしもしA社? ひとつお願いしたいことが...」 A社「はい、追加費用のかからないことなら」
55.
B社「たのむからGit使ってください」 form ユーザー企業 to エンジニア
56.
作業するときはかならずチケット(課題) 管理するようにしました。 Gitでは、チケットごとに異なるブラン チを切ることにしました。 緊急でないかぎり、本番の更新は随時 ではなくまとめてやるようにしました。
57.
• 事業会社は自分のことなので真剣です • Gitの操作はプログラミング能力とは関係ありません •
チケット管理システムは意味がわかればWebのフォーム に文字を書けるだけでOKです • 問題意識、情報の運用、ソフトウェアの開発プロセスに は、本質的な情報の力が出ます 受託開発の会社は、顧客をITの素人だと思ってはいけません。 実は自分たちが長けているのは、PHPの文法とかだけだった、なんてこ とないように!
58.
• 特権的な分野で過去のやり方を守るだけ =
魔術 • 新しいやり方から次のやり方を生み出せるもの = 科学
59.
第三話 インフラ
60.
P氏「あれ? testとprodにnslookupしたら同じIPに なるんですけど...」 B社「そりゃそうさ同じマシンだもん」 P氏「え」 B社「たしか同じのにWordPressも入ってるよ」
61.
期待したもの App DB 本番 App DB テスト Blog 開発
62.
得られたもの App DB 本番 /var/www テスト /var/www_test 本番
db テスト db_test cron (本番のみ) WordPress wp_db WordPress /var/www/blog phpMyAdmin FTP
63.
やばい
64.
テスト環境だけ AWS に移動しました。 いつでも自由に停止/再起動できるようになりました。 テストが本番に影響する心配もなくなりました。
65.
テストメールが送信されないよう Mailcatcherを利用しました
66.
B社「うーんうーん」 P氏「どうしましたか」 B社「XAMPPでは動かないのになんでtestで動くの?」
67.
C:¥XAMPP
68.
• Vagrantに移行 • Maicatcherのお手軽版としてFakeSMTPを利用 •
手元でテストしたものの信頼性が格段に向上。 • テストサーバーの取り合いもなくなりました。 ここでVagrant環境とテストサーバーを、随時本番サー バーに似るようメンテし続けたことが後で効いてきます。
69.
ある日、メディア掲載に大成功し... アクセス殺到
70.
サーバーが… 死んだ…
71.
23:10 夜運用スタッフ大慌て 帰宅後の社員を巻き込んで飛び交う 深夜の社内チャット 自宅のP氏「SSHが息してないです」
72.
P氏「こうなったらA社のデータセンターに...!」 B社「翌日出勤時間の9:00まで、あそこリスタートで きる人誰もいないよ」
73.
翌日9:00まで リスタートできる人誰もいないよ
74.
ほどなくして、B社内でAWSへの完全移行が決定され るのであった… B社「自分たちのビジネスのタイミングでサーバ運用 したい!」 サーバ環境を変えてもちゃんと動きそうな期待は、テストサーバーと Vagrantで十分に積んできました。というわけです
75.
ELB EC2 (App) RDS Nginx
Apache EC2 (WordPress) Apache MySQL PHP MySQL SES これからはこいつらのEBS スナップショットからテスト環境を生成可能
76.
• ハードウェア設備は利権化しやすいポイントです。 • 変える理由に実利がともなわないと、出資者は動き ません。経営で重要なのは移行費用を回収できるか です。 •
脱レガシーには、移行コストと先の損得の見積もり を、わかりやすく比較することが重要です。
77.
最終回 人事
78.
ここまでのエピソードで もっとも重要だったこと = 人事 HOW? WHY?
79.
どのようにして P氏を採用したか • カンファレンス • 勉強会 •
コワーキングスペース 適切な情報が流れているコミュニティに 接点を持つこと
80.
なぜP氏を 採用できたか • ITによる成長力を信じる社風があること • ITに頼らずに今の事業を支えている人がいること •
タイミング (←重要)
81.
• 手が空いた優秀な人材は、それを放っておかない会 社が数多くある • 良い人材がいたとき、すぐに採用できる余裕を経営 に織り込むこと •
現場から「この人を採用したい」という声が挙げら れるようにすること
82.
その後人事はどうなったか ITの会社ではないのに、多くの良いエンジニアを多く 採用/契約できた。 • 悪いエンジニアは優秀なエンジニアを歓迎しない • 良いエンジニアは優秀なエンジニアをひと目で見分 けられる •
むしろ良いエンジニアは自分よりも優秀なエンジニ アがいたらどんどん呼びこむ
83.
え、なにこの経営者向けのオチ? 自分が所属してる会社でどうやって脱レガシーするか 聞きたかった?
84.
→ 自分の会社を、人事/社風のレイヤー で動かすことを考えて下さい
85.
• レガシーの正体は非科学です • 非科学とは社会的/組織的な迷信です •
人のメンタルを変えないかぎり、それは表面的な対 応でしかありません • 道具や教本だけに頼ると、脱レガシーだと思って採 用した最新手法が、やがて時間とともに、次のレガ シー(先代の残した魔術)となります
86.
• たとえば、Jenkinsのタスク、Chefのレシピ... • 秘伝のタレに再現性を与える行為
= 脱レガシー
87.
• 学びましょう! • 学んだことを仕事に持ち帰りましょう! •
そして人に伝え、迷信に頼らないチームにしましょ う! • 大変かもしれませんが「やりたい」という気持ちを エネルギーの源泉として!
88.
ありがとうございました
Jetzt herunterladen