Slide 1
Slide 1 text
技術的負債を
“なるべく”
作らないためのコツ
2017.06.22
@kakakakakku
Slide 2
Slide 2 text
吉田 慶章 @kakakakakku
- Makuake : CyberAgent Crowd Funding, Inc.
- DevOps Engineer 兼 技術広報
- AWS, DevOps, Rails, Certified Scrum Master
- 今年からプログラミング講師の仕事もしてます
- 趣味はブログを書くことです
http://kakakakakku.hatenablog.com/
Slide 3
Slide 3 text
https://developers.cyberagent.co.jp/blog/archives/4079/
https://developers.cyberagent.co.jp/blog/archives/6588/
Slide 4
Slide 4 text
http://lean-agile.fm/episode/22
ポッドキャストに出演して「寝不足」の話をしました
#信頼残高
#意識高い
Slide 5
Slide 5 text
個人 Trello に書いてあるノルマを
達成しないと寝てはいけない話はマジです
あー, 今日も寝てねー
Slide 6
Slide 6 text
さて
ミサワ話は置いておいて...
Slide 7
Slide 7 text
今日の勉強会のテーマ
「技術的負債」
Slide 8
Slide 8 text
また「技術的負債」の話？
もう聞き飽きてるかもしれないけど, まだまだ重要なことがある
Slide 9
Slide 9 text
今日の勉強会のテーマ
「技術的負債」
“なるべく” 作らないためのコツ
Slide 10
Slide 10 text
コツ 1
「技術的負債の分類」を理解しよう！
Slide 11
Slide 11 text
無鉄砲
→ 汚いコード
慎重
→ めったに使われないコード
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
意図的
不注意
Slide 12
Slide 12 text
無鉄砲 慎重
意図的
不注意
設計する時間が
ないんだから
しょうがない
今すぐリリースしないと
いけない
→ マニュアルで対応する
レイヤー化？
何それ？
→ 完全な技術力不足
もっとこうすべき
だったなあ
→ より良い形を模索する
Slide 13
Slide 13 text
ナイーブな技術的負債
→ 技術力不足
→ 既に紹介した「無鉄砲」と同義
不可避な技術的負債
→ 想定外のサービス成長など
戦略的な技術的負債
→ リリース日を最優先の価値とする場合など
( 個人的にはこの分類が理解しやすい )
Slide 14
Slide 14 text
コツ 2
新しい技術を導入する場合は
経験者を採用しよう！
Slide 15
Slide 15 text
重要なのは
「ナイーブな技術的負債」を避けること
Slide 16
Slide 16 text
経験者を採用しよう！
- 経験のある人と一緒に開発をすれば, 効率良く学べる
- 採用が難しい場合,
外部メンターにアドバイスをもらう
- 相談ができるだけで, 成果が圧倒的に違う
- Pattern 14. 達人を味方に
- もしくは事前にメチャクチャ素振りをしておく
Slide 17
Slide 17 text
コツ 3
改善症候群に陥らないようにしよう！
Slide 18
Slide 18 text
改善症候群
- 改善は癖になってしまうことがある
- 1ms を改善できるマニアックな改善にどこまでの価値がある？
- それ「エンジニアのエゴ」でしょ？
- それよりも, 目の前にある 1000ms の課題を優先すべき
Slide 19
Slide 19 text
ペイオフマトリックス
低 ← 難易度 → 高
高
↑
効
果
↓
低
質の良い課題を
発見するスキルが重要
Slide 20
Slide 20 text
コツはわかった, わかったけど
じゃあ, 最高の開発ができる？
Slide 21
Slide 21 text
現実はそんなに甘くない
Slide 22
Slide 22 text
技術的な議論をちゃんとしてる？
できることなら避けようとしてない？
深い議論ができてなければ, 技術的負債は無限に増える
Slide 23
Slide 23 text
コツ 4
「組織パフォーマンス」を改善しよう！
僕が好きな「組織論, 心理学, メンタリング, ファシリテーション」から紹介
Slide 24
Slide 24 text
“雑談のような質問” をしよう！
Tips 1
Slide 25
Slide 25 text
雑談のような質問
- 「わからない！」「教えて！」と言えない人が多い
- もしくは, 言えない雰囲気 (心理的安全がない) かも？
- 質問することは, 1番効率良く学ぶ方法
- 質問すればすぐにわかるのに, 数時間ググった経験ない？
Slide 26
Slide 26 text
雑談のような質問
- 答えがないような質問も雑談のようにカジュアルにする
- 議論が盛り上がってもっと良いアイデアに気付けたり
- 質問された側も調べてあげたくなる
- 質問することによって, 考えがまとまることもある
- これを「オートクライン」を呼ぶ
Slide 27
Slide 27 text
明日からすぐに実践しよう！
1日1回, 誰かに質問をしてみよう！
Slide 28
Slide 28 text
“ジョハリの窓” を意識して
相互理解を深めよう！
Tips 2
Slide 29
Slide 29 text
開放の窓
(Open Self)
盲点の窓
(Blind Self)
未知の窓
(Unknown Self)
秘密の窓
(Hidden Self)
公開された自己 気付かない自己
隠された自己 未知の自己
Slide 30
Slide 30 text
開放の窓
(Open Self)
盲点の窓
(Blind Self)
未知の窓
(Unknown Self)
秘密の窓
(Hidden Self)
公開された自己 気付かない自己
隠された自己
未知の自己
自己開示
Slide 31
Slide 31 text
ジョハリの窓 (Johari Window)
- 「自己開示」
- 自分のことを, ちゃんとメンバーに知ってもらえてる？
- 逆に, メンバーのことをどこまで知ってる？
- 仕事で大切だと思っていることなどを,
伝えたことはある？
- 秘密が多い人と仲良くなれそう？
Slide 32
Slide 32 text
開放の窓
(Open Self)
盲点の窓
(Blind Self)
未知の窓
(Unknown Self)
秘密の窓
(Hidden Self)
公開された自己 気付かない自己
隠された自己 未知の自己
フィードバック
Slide 33
Slide 33 text
ジョハリの窓 (Johari Window)
- 「フィードバック」
- メンバーからどう思われているのか, 知る機会ってある？
- 頑張ってるつもりなのに, メンバーはそう感じてないかも？
- 自分では気付かない部分に気付けることの大切さ
- フィードバックをもらうためには, 信頼関係が前提になる
Slide 34
Slide 34 text
明日からすぐに実践しよう！
1日1個, 誰かに自分の話をしてみよう！
Slide 35
Slide 35 text
“ノンバーバルなコミュニケーション” で
また話したくなる人になろう！
Tips 3
Slide 36
Slide 36 text
ノンバーバルなコミュニケーション
- ノンバーバル = 非言語
- ようするに「表情, 態度, トーンなど」のこと
- 「話したい人」と「話したくない人」の違い
- 「全然反応ないな, 話聞いてくれてるのかな？」
- うなずき, あいづち, 笑顔, 目線, ジャスチャーなど
Slide 37
Slide 37 text
明日からすぐに実践しよう！
話してくれてる人にノンバーバルで
「聞いてるよ」と伝えよう！
( プレゼンも, 聞いてる人からノンバーバルな反応があると嬉しいよ？？？ )
Slide 38
Slide 38 text
えっ...
Slide 39
Slide 39 text
自己啓発セミナー？w
他にも「アクノレッジメント」や「タックマンモデル」などの話をしたかったんだけど
Slide 40
Slide 40 text
まとめ
Slide 41
Slide 41 text
技術的負債を “なるべく” 作らない
- コツ1 :「技術的負債の分類」を理解しよう！
- コツ2 : 新しい技術を導入する場合は経験者を採用しよう！
- コツ3 :「改善症候群」に陥らないようにしよう！
- コツ4 :「組織パフォーマンス」を改善しよう！