Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
技術的負債を "なるべく" 作らないためのコツ / Organization Performa...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Yoshiaki Yoshida
June 23, 2017
Technology
13k
17
Share
技術的負債を "なるべく" 作らないためのコツ / Organization Performance Tips
組織パフォーマンスを改善しよう!
http://kakakakakku.hatenablog.com/entry/2017/06/24/004845
Yoshiaki Yoshida
June 23, 2017
More Decks by Yoshiaki Yoshida
See All by Yoshiaki Yoshida
技術ブロガーを育てる!ブログメンタリングで何を教えているのか / Passion for Blog Mentoring
kakakakakku
8
38k
プログラミング初心者に教えるときは「身近な比喩」が重要なのだ! / Metaphor is Important for Beginner Programmer
kakakakakku
2
5.8k
プロジェクトの成功を支える ZenHub と モブプログラミング / ZenHub and Mob Programming
kakakakakku
1
6k
楽しく!アウトプットを習慣化しよう / Let's Enjoy Output
kakakakakku
3
7k
さぁ!今すぐプロジェクトリーダーに立候補しよう / Be a Project Leader
kakakakakku
3
10k
プロジェクトをリードする技術 (Kyash 社 再演) / Project Leading is Skill for Kyash
kakakakakku
4
2.3k
プロジェクトをリードする技術 / Project Leading is Skill
kakakakakku
45
52k
Mackerel で ECS をどこまでモニタリングできるのか / Monitoring ECS with Mackerel
kakakakakku
0
14k
[2018/01/30] Redash 初心者向けハンズオン / Redash Meetup #0.1
kakakakakku
0
2.5k
Other Decks in Technology
See All in Technology
Databricks Academic Series 〜 大規模言語モデル / エージェント編 〜 / academic-series-llm
databricksjapan
0
110
サービスの信頼性を高めるため、形骸化した「プロダクションミーティング」を立て直すまでの取り組み
stefafafan
1
250
AI 時代の Platform Engineering
recruitengineers
PRO
1
110
AIが盛んな時代に 技術記事を書き始めて起きた私の中での小さな変化
peintangos
0
360
Agent の「自由」と「安全」〜未来に向けて今できること〜
katayan
0
350
20260428_Product Management Summit_Loglass_JoeHirose
loglassjoe
4
7.3k
エンタープライズの厳格な制約を開発者に意識させない:クラウドネイティブ開発基盤設計/cloudnative-kaigi-golden-path
mhrtech
0
360
AI時代の品質はテストプロセスの作り直し #scrumniigata
kyonmm
PRO
4
1.4k
Oracle Exadata Database Service on Cloud@Customer X11M (ExaDB-C@C) サービス概要
oracle4engineer
PRO
2
8k
AI時代に越境し、 組織を変えるQAスキルの正体 / QA Skills for Transforming an Organization
mii3king
5
4.1k
そのSLO 99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜 / Is that 99.9% SLO really necessary? Design philosophy of shared responsibility through prioritized SLOs
vtryo
0
160
オライリーイベント登壇資料「鉄リサイクル・産廃業界におけるAI技術実応用のカタチ」
takarasawa_
0
340
Featured
See All Featured
Faster Mobile Websites
deanohume
310
31k
The Invisible Side of Design
smashingmag
302
52k
Abbi's Birthday
coloredviolet
2
7.4k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
0
1.3k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
530
Context Engineering - Making Every Token Count
addyosmani
9
870
Statistics for Hackers
jakevdp
799
230k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Visual Storytelling: How to be a Superhuman Communicator
reverentgeek
2
530
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
0
300
RailsConf 2023
tenderlove
30
1.4k
Transcript
技術的負債を “なるべく” 作らないためのコツ 2017.06.22 @kakakakakku
吉田 慶章 @kakakakakku - Makuake : CyberAgent Crowd Funding, Inc.
- DevOps Engineer 兼 技術広報 - AWS, DevOps, Rails, Certified Scrum Master - 今年からプログラミング講師の仕事もしてます - 趣味はブログを書くことです http://kakakakakku.hatenablog.com/
https://developers.cyberagent.co.jp/blog/archives/4079/ https://developers.cyberagent.co.jp/blog/archives/6588/
http://lean-agile.fm/episode/22 ポッドキャストに出演して「寝不足」の話をしました #信頼残高 #意識高い
個人 Trello に書いてあるノルマを 達成しないと寝てはいけない話はマジです あー, 今日も寝てねー
さて ミサワ話は置いておいて...
今日の勉強会のテーマ 「技術的負債」
また「技術的負債」の話? もう聞き飽きてるかもしれないけど, まだまだ重要なことがある
今日の勉強会のテーマ 「技術的負債」 “なるべく” 作らないためのコツ
コツ 1 「技術的負債の分類」を理解しよう!
無鉄砲 → 汚いコード 慎重 → めったに使われないコード https://martinfowler.com/bliki/TechnicalDebtQuadrant.html 意図的 不注意
無鉄砲 慎重 意図的 不注意 設計する時間が ないんだから しょうがない 今すぐリリースしないと いけない →
マニュアルで対応する レイヤー化? 何それ? → 完全な技術力不足 もっとこうすべき だったなあ → より良い形を模索する
ナイーブな技術的負債 → 技術力不足 → 既に紹介した「無鉄砲」と同義 不可避な技術的負債 → 想定外のサービス成長など 戦略的な技術的負債 →
リリース日を最優先の価値とする場合など ( 個人的にはこの分類が理解しやすい )
コツ 2 新しい技術を導入する場合は 経験者を採用しよう!
重要なのは 「ナイーブな技術的負債」を避けること
経験者を採用しよう! - 経験のある人と一緒に開発をすれば, 効率良く学べる - 採用が難しい場合, 外部メンターにアドバイスをもらう - 相談ができるだけで, 成果が圧倒的に違う
- Pattern 14. 達人を味方に - もしくは事前にメチャクチャ素振りをしておく
コツ 3 改善症候群に陥らないようにしよう!
改善症候群 - 改善は癖になってしまうことがある - 1ms を改善できるマニアックな改善にどこまでの価値がある? - それ「エンジニアのエゴ」でしょ? - それよりも,
目の前にある 1000ms の課題を優先すべき
ペイオフマトリックス 低 ← 難易度 → 高 高 ↑ 効 果
↓ 低 質の良い課題を 発見するスキルが重要
コツはわかった, わかったけど じゃあ, 最高の開発ができる?
現実はそんなに甘くない
技術的な議論をちゃんとしてる? できることなら避けようとしてない? 深い議論ができてなければ, 技術的負債は無限に増える
コツ 4 「組織パフォーマンス」を改善しよう! 僕が好きな「組織論, 心理学, メンタリング, ファシリテーション」から紹介
“雑談のような質問” をしよう! Tips 1
雑談のような質問 - 「わからない!」「教えて!」と言えない人が多い - もしくは, 言えない雰囲気 (心理的安全がない) かも? - 質問することは,
1番効率良く学ぶ方法 - 質問すればすぐにわかるのに, 数時間ググった経験ない?
雑談のような質問 - 答えがないような質問も雑談のようにカジュアルにする - 議論が盛り上がってもっと良いアイデアに気付けたり - 質問された側も調べてあげたくなる - 質問することによって, 考えがまとまることもある
- これを「オートクライン」を呼ぶ
明日からすぐに実践しよう! 1日1回, 誰かに質問をしてみよう!
“ジョハリの窓” を意識して 相互理解を深めよう! Tips 2
開放の窓 (Open Self) 盲点の窓 (Blind Self) 未知の窓 (Unknown Self) 秘密の窓
(Hidden Self) 公開された自己 気付かない自己 隠された自己 未知の自己
開放の窓 (Open Self) 盲点の窓 (Blind Self) 未知の窓 (Unknown Self) 秘密の窓
(Hidden Self) 公開された自己 気付かない自己 隠された自己 未知の自己 自己開示
ジョハリの窓 (Johari Window) - 「自己開示」 - 自分のことを, ちゃんとメンバーに知ってもらえてる? - 逆に,
メンバーのことをどこまで知ってる? - 仕事で大切だと思っていることなどを, 伝えたことはある? - 秘密が多い人と仲良くなれそう?
開放の窓 (Open Self) 盲点の窓 (Blind Self) 未知の窓 (Unknown Self) 秘密の窓
(Hidden Self) 公開された自己 気付かない自己 隠された自己 未知の自己 フィードバック
ジョハリの窓 (Johari Window) - 「フィードバック」 - メンバーからどう思われているのか, 知る機会ってある? - 頑張ってるつもりなのに,
メンバーはそう感じてないかも? - 自分では気付かない部分に気付けることの大切さ - フィードバックをもらうためには, 信頼関係が前提になる
明日からすぐに実践しよう! 1日1個, 誰かに自分の話をしてみよう!
“ノンバーバルなコミュニケーション” で また話したくなる人になろう! Tips 3
ノンバーバルなコミュニケーション - ノンバーバル = 非言語 - ようするに「表情, 態度, トーンなど」のこと -
「話したい人」と「話したくない人」の違い - 「全然反応ないな, 話聞いてくれてるのかな?」 - うなずき, あいづち, 笑顔, 目線, ジャスチャーなど
明日からすぐに実践しよう! 話してくれてる人にノンバーバルで 「聞いてるよ」と伝えよう! ( プレゼンも, 聞いてる人からノンバーバルな反応があると嬉しいよ??? )
えっ...
自己啓発セミナー?w 他にも「アクノレッジメント」や「タックマンモデル」などの話をしたかったんだけど
まとめ
技術的負債を “なるべく” 作らない - コツ1 :「技術的負債の分類」を理解しよう! - コツ2 : 新しい技術を導入する場合は経験者を採用しよう!
- コツ3 :「改善症候群」に陥らないようにしよう! - コツ4 :「組織パフォーマンス」を改善しよう!