1. 技術的負債返しますか？
それとも開発辞めますか
〜 DevLove広島 〜
「DevLove甲子園勝手にプレイバック Ver.西 + α」
BMC 西 秀和

2. 自己紹介
• 西 秀和（３３歳）
• 経営管理センター所属 主任
• 仕事先：BIGLOBE
(月曜〜金曜は東京にいます)
• 業務システム設計・開発

3. DevLove甲子園
お邪魔してきました

4. DevLove甲子園
発表内容
（ダイジェスト）

5. 中間管理職が
いなくなったら
プロジェクトが
うまく進みだしたよ♪
経営管理センター(BMC) 西 秀和
隊トラック

6. みなさん！！
管理されてますかー？

7. お客様
１次
２次
常駐
常駐
僕
担当
主任
主任
M
お客
発注
API
設計部門
API
製造部門
担当
画面
部門
担当
M
発注
東京
広島 広島愛媛

8. S-in日までに完成した画面
１０７画面中
７画面

9. お客様
１次
２次
担当
主任
主任
M
お客
API
設計部門
API
製造部門
担当
画面
製造部門
担当
MGM
僕
S-inするまで、
帰ってくるな！
！
■命令

10. 無事にS-inできた

11. 全員で
ゴールを共有

12. WHY?
WHAT?
HOW?
現場では逆走不可
←ココを与える

13. 現場を変える
可能性を
一番持っているのは、
現場のエンジニア

14. 発表内容ここまで。

15. 中間管理職いたら
ダメなのか？

16. 数値化して管理
数値化が難しいことに弱い
現場の全てを把握できない

17. 数値化が難しいこと
現場のエンジニアが
解決するしかない！

18. 技術的負債

19. ウォード・カニンガム
最初のコードを出荷することは、借金をしに行くことと同じである。
小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加
速する。危険なのは、借金が返済されなかった場合である。品質の良
くないコードを使い続けることは借金の利息としてとらえることがで
きる。技術部門は欠陥のある実装や、不完全なオブジェクト指向など
による借金を目の前にして、立ち尽くす羽目になる
技術的負債とは？

20. Reckless
(無鉄砲)
Prudent
(計画的)
Deliberate
(意図的)
設計する時間がない
品質を犠牲にして作れ！！
問題は認識しているが、
リスクは承知の上でリリース
Inadvertent
(無意識)
負債が溜まっていく事に
気づいてない
最善を尽くしたが、
のちに最善の方法が分かる
技術的負債(四象限)

21. 技術的負債とは
どのレベルの問題を
言っているのか？

22. • 処理の共通化（共通化）
• 単体テストが可能（テストの容易性）
メソッド抽出
<- 生産性のUP
<- 品質の向上
実例

23. Reckless
(無鉄砲)
Prudent
(計画的)
Deliberate
(意図的)
設計する時間がない
品質を犠牲にして作れ！！
問題は認識しているが、
リスクは承知の上でリリース
Inadvertent
(無意識)
負債が溜まっていく事に
気づいてない
最善を尽くしたが、
のちに最善の方法が分かる
技術的負債(四象限)

24. 技術的負債が
発生する原因
技術的負債の分類
技術的負債(四象限)

25. 1.短納期
2.未熟なチーム
3.業務知識不足
原因の発生元は？

26. 1.短納期

27. Reckless
(無鉄砲)
Prudent
(計画的)
Deliberate
(意図的)
設計する時間がない
品質を犠牲にして作れ！！
問題は認識しているが、
リスクは承知の上でリリース
Inadvertent
(無意識)
負債が溜まっていく事に
気づいてない
最善を尽くしたが、
のちに最善の方法が分かる
技術的負債(四象限)

28. 「短納期」弊害
• 設計・レビューの時間が十分に取れない
• 最善の手法では間に合わない
• 似た処理をコピー&ペースト
• 仕様変更に柔軟に対応できない

29. 2.未成熟なチーム

30. Reckless
(無鉄砲)
Prudent
(計画的)
Deliberate
(意図的)
設計する時間がない
品質を犠牲にして作れ！！
問題は認識しているが、
リスクは承知の上でリリース
Inadvertent
(無意識)
負債が溜まっていく事に
気づいてない
最善を尽くしたが、
のちに最善の方法が分かる
技術的負債(四象限)

31. 「未成熟なチーム」の弊害
• チームの設計方針が安定しない
• 実装方法に統一性がない
• 後戻りが多い
• 打ち合わせ・議論が長い

32. 3.業務知識不足

33. Reckless
(無鉄砲)
Prudent
(計画的)
Deliberate
(意図的)
設計する時間がない
品質を犠牲にして作れ！！
問題は認識しているが、
リスクは承知の上でリリース
Inadvertent
(無意識)
負債が溜まっていく事に
気づいてない
最善を尽くしたが、
のちに最善の方法が分かる
技術的負債(四象限)

34. 「業務知識不足」の弊害
• データの変換している処理が多い
• データ構造が業務に合っていない
• STなどプロジェクト後半で問題が多い

35. 最近、
関わっている
プロジェクトの話

36. プロジェクト状況
• ７人チーム
(バラバラのチームからかき集めた)
• １０月に結成して２月リリース
• 初めてのビジネスモデル

37. 直ぐに問題が発生

38. チームの中心になる
共通認識がない

39. 技術的負債が
増えている事は
エンジニアが
一番理解している

40. レビューで
設計方針の
討論が起きる
コレは良いこと
(時間があれば）

41. 議論が発散
レビュー時間が長時間化
技術的負債を生む原因
作業時間を圧迫

42. 一旦、議論禁止

43. 代わりにやった事

44. 共通認識を作る

45. ドメインモデル
１４００クラス
１００テーブル

46. 技術的負債を
共有する

47. ←議論したい事
←議論はして
取組でいる事

48. チームの方針
• 毎日、１６：００から１時間だけ開催
• 1回で１議題
• ファシリテーターは持ち回り
• 朝会で今日の議題を発表
• ファシリテータが初めに問題提起と改善案を提示

49. 議論中…

50. 議論する時間を設ける利点
• １つの議題に集中して討論できる
• もめた時の受け皿になる
• みんなで決めたという納得感
• やりたい事を提案する準備の期間がある

51. 技術的負債を
見逃さない

52. KPTでは残ったProblemを捨てたらダメ

53. まとめ

54. 技術的負債の返済は
チームで挑め！！

55. なぜか？

56. 技術的負債の発生は
エンジニアの
スキルではなく状況
に左右されやすい

57. 誰か一人で
リファクタを実施

58. 未熟なチーム
業務知識が乏しいメンバは
新たな技術的負債を生む

59. 技術的負債の返済
が終わらない…

60. 技術的負債の返済
と共にチームが
成長すること
大切な事

61. 技術的負債の返済は
チームで挑め！！

62. ご静聴
ありがとうございました。