2019.8.23 時代とともに変化する技術的負債〜負債になるタイミングと予防法〜 #techplayjp https://techplay.jp/event/741963

1. 技術的負債を生み出す構造とその対処について
株式会社ソニックガーデン 西見 公宏 @mah_lab
2019/8/23 時代とともに変化する技術的負債
〜負債になるタイミングと予防法〜

2. 自己紹介
西見 公宏 にしみ まさひろ
SonicGarden
取締役 / Programmer
● 1983年生まれの35歳 / 3児の父
● 2011年からソニックガーデンにジョイン
● Rails歴10年ぐらい / Railsでの開発がメイン
● 最近はNuxt.jsとFirebaseでサクサクプロトタイピングす
ることにハマっています
● 納品のない受託開発、企画立ち上げ担当
● 新規事業を企画しているお客様からのご相談を年間
100件以上受け、プロジェクトの立ち上げを支援
本日はどうぞよろしくお願いします！

3. 株式会社ソニックガーデン
● 2011年、TIS社内ベンチャーをMBOして創業
● 社員36名、システム受託開発・自社サービス
● 「納品のない受託開発」「業務ハック」
● アジャイル・リモートワーク・ホラクラシー
中小企業テレワークチャレンジ
特別奨励賞受賞
2018年「働きがいのある会社ランキン
グ」5位ベストカンパニー賞
2016年 船井財団「グレートカンパニーア
ワード」ユニークビジネスモデル賞

4. 「オフィスがない会社」

5. 社員数は36名

6. 本日のアジェンダ
● 技術的負債を生み出す構造の例としての
「技術的負債ループ」の紹介
● ソニックガーデンを例にしたケーススタディ
● ケーススタディをふまえ、技術的負債と
どのように向き合うべきか？

7. そもそも技術的負債とは？

8. 何だか生産性が落ちてきた
パフォーマンスが何か悪い、など
そういう目に見えてきた結果の原因として
語られることが多い

9. 現象と原因の氷山モデル
画像出典:
Vvstudio - jp.freepik.com によって作成されたwater ベクトル
https://jp.freepik.com/free-photos-vectors/water
氷山に隠れた部分が技術的負債だが、普段の活動で
はなかなか気付きにくい
様々な原因が影響しあって技術的負債を蓄積させて
いるため、その構造を明らかにする必要がある
→ そのために使えるツールがループ図
このスライド以降で説明します
生産性の低下、セキュリティリスクなどが顕在化して
はじめて認識できる

10. システム思考のループ図
外部要因
問題 応急処置
波及効果
応急処置のツケが
どこかで回ってくる

11. 例のループ図の言っている意味
● 外部要因によって問題が発生する
● その問題に対して応急処置をすることで問題が一見解決し
ているように見える
● しかしその応急処置によって別の隠された問題が発生し、
一向に問題が解決しない
● なかなか解決しない問題を表現するために使えるパワフル
なツールがシステム思考のループ図

12. 技術的負債が蓄積する様子をループ図で書いてみる
ミドルウェアの
バージョンアップがで
きない
フレームワークのバー
ジョンアップができな
い
無理な設計
変更しづらさ
ライブラリの
バージョンアップがで
きない
セキュリティ脆弱性
バージョンアップの放
置
その場しのぎの
コード
その場しのぎのコードによって
バージョンアップが困難になるループ
メンテナンス性がどんどん
落ちていくループ
要素技術の幅
特定の人への負荷
書かれないテスト
人材採用
人的コスト
売上を増やすための
開発加速
無理な
期限設定
メンテされない
コード量
機能削減ができない

13. ループ図から分かること
● 要素技術の幅を増やせば増やすほど、みんながその要素技術を知ってい
るわけではなくなるため特定の人間に負荷が集中しやすくなり、結果として
バージョンアップが後手に回りやすくなる
● フレームワークやライブラリのバージョンが上がらないことで、古いバージョ
ンのコードの書き方でその場をしのごうとするが、そのコードが増えれば増
えるほどフレームワークのバージョンアップがより困難になる
● その場しのぎのコードが増えれば増えるほど変更のしづらさから無理な設
計増え、無理な設計のまま何とかしようとして、よりその場しのぎのコードが
増え続ける

14. ループ図から分かることをまとめると
● 少ない人数で多くのサービスをメンテナンスする場合は要
素技術の幅をできる限りおさえた方が良さそう
● ミドルウェア、ライブラリ、フレームワークのバージョンアップ
をこまめにおこなった方が良さそう
● その場しのぎのコードを放置すれば放置するほど酷い目に
あいそう

15. ソニックガーデンを例にした
ケーススタディ

16. ソニックガーデンの場合
自社運営のサービス 受託開発サービス
約10サービス
納品のない受託開発
約70サービス

17. よくある受託開発（一括請負）の問題
何が必要か
予想が難しい
納品したら
開発者は解散
使い始めてから
不満が出てくる
直したくても
直せない

18. 納品のない受託開発による課題解決
少しずつ
相談しながら作る
開発者にいつでも
相談できる
どんどん便利に
なっていく
安心して
事業展開できる
継続したアップデート

19. つまり納品のない受託開発とは
● 「あたかも自社サービスのエンジニアチームがいるかのよう
に」継続して開発・運用・改善をするサービス
● ローンチ後も継続して開発をサポート（むしろローンチしてか
らが本番）
● 長いプロダクトで9年以上アップデートを繰り返しながら運用
し続けている
事業が続く限り継続してお付き合い

20. 約80サービスを継続して開発・運用し続けている
自社運営のサービス 受託開発サービス
納品のない受託開発
どのような戦略で運用するべきか？

21. 技術的負債ループをふまえた問題への対策
● 要素技術の幅をできる限りおさえる
○ 技術スタックの統一化
● バージョンアップをこまめに行う
○ 自社ツールによるメンテナンス監視
● その場しのぎのコードを放置しない
○ ソースコードのオーナーシップ
○ チームで行うコードレビュー

22. 技術スタックの統一化
● Ruby, Ruby on Rails, AWS(OpsWorks)で全て運用
● 受託開発では要素技術を指定されるパターンも多いが、技
術スタックを統一化することによるノウハウの蓄積と、それ
によって安定した継続的な開発ならびに運用を提供するた
め、技術の指定は受け付けていない
● OpsWorksで利用するChefのcookbookも全案件で共通の
ものを使用している（環境の差分をなくしている）

23. 技術スタックそのものの陳腐化問題への対応
● 例えばOpsWorksがオワコンになったらどうするか？
● 本当に特定技術だけやっていたのでは時代の変化にはつ
いて行けない。時間の経過による陳腐化リスク
● ソニックガーデンでは部活という、業務時間で自分の作りた
いものを好きな技術で作って良い制度がある
○ 部活でいろいろな技術を興味本位で試すことによって、
扱える要素技術の選択肢を拡げている

24. 自社ツールによるメンテナンス監視
● 自前でメンテナンスツールを開発
● 対応テーマと対応状況を管理している

25. ソースコードのオーナーシップ
● 開発は可能な限り少人数で行っている
● コミュニケーションコストによる生産性低下を抑える狙いもあ
るが、「下手なコードを書いたら、いつか自分に返ってくる」
ので「常に最高のコードを書き続ける」というオーナーシップ
を持つことが狙い
● オーナーシップを持つだけでもコードの雰囲気は変わるが、
更に仕組みとしてコードの質を高めるため、チームコードレ
ビューに取り組んでいる

26. チームで行うコードレビュー
● かかっても10〜20分程度で見られる分量でこまめ
にコードレビューを回すようにしている
○ （大きすぎると見られない）
● プルリクに連動して社内コミュニケーションツール
（Remotty）にレビュー依頼が投稿されるようになっ
ている

27. それぞれの対策をまとめた図
コードレビュー
技術の陳腐化
部活
技術スタックの統一
オーナーシップ
キレイなコード
運用ノウハウ
適切にバージョンアッ
プされた環境
時間の経過
時間の余裕
新技術の検証

28. まとめ：技術的負債と
どのように向き合うべきか？

29. 結論として：技術的負債は根が深い問題
● 今回はシステム思考のループ図を利用して整理したが、技
術的負債が蓄積する構造は組織個別のいろいろな要因が
関連していて複雑だということがわかる。
● そのため、個別のケーススタディをそのまま採用しようとして
も、「あの会社だからできることだよね」となりがち。解決の
糸口にはなりにくい。

30. 技術的負債とどのように向き合うべきか？
● 向き合うためには、自分の組織が技術的負債を生み出して
いる構造をループ図などを活用して把握する必要がある。
個別に頑張って対応しても、何らかのフィードバックによって
根本解決に至りづらい。
● そのため誰かが頑張る、時間を特別にとって何とかするの
ではなく、全体の仕組みとして技術的負債が抑制される
フィードバックループを構築することが重要。

31. ご清聴ありがとうございました