納品のない受託開発を支える レガシーコードを作らない仕組み
•
59 likes•26,598 views
2014/9/27 レガシーコード改善勉強会でお話をさせていただきました。 http://passmarket.yahoo.co.jp/event/show/detail/01pitgwzj67m.html
納品のない受託開発を支える レガシーコードを作らない仕組み
- 1. 納品のない受託開発を支える レガシーコードを作らない仕組み SonicGarden Inc. 西見 公宏 2014/9/27 レガシーコード改善勉強会
- 2. 西見 公宏 Nishimi Masahiro As Business Programmer 2014/09/27 レガシーコード改善勉強会 2
- 3. 自己紹介 西見 公宏 Masahiro Nishimi @mah_lab 昭和58年生まれ 東京育ち 2児（双子）の父親です ブログ http://blog.mah-lab.com/（毎日更新中） 2014/09/27 レガシーコード改善勉強会 3
- 4. 2008年 2011年 2014年 大手SIerに入社 SonicGardenにジョイン 今ここ 会計ERP（Oracle EBS）のアプリSEとして従事 Oracle EBS向けソリューション開発のためオフショア 開発も経験 要素技術はHP/UX、PL/SQL、Oracle Formsなど 新規事業の立ち上げで必要となるWebサービスの開発・ 運用を行うビジネスプログラマーとして従事 要素技術はLinux、iOS、Ruby、Railsなど 企業向けCMS、医療系システム、教育事業向けシステムを 開発したり、SonicGardenが展開するサービスの開発に 従事しています 2014/09/27 レガシーコード改善勉強会 4
- 6. 今日お話する内容 1. レガシーコードの何が問題か？ • そもそもレガシーコードとは何か • レガシーコードがもたらす問題とは何か • コードだけの問題なのか？ 2. 納品のない受託開発を支える、レガシー コードを作らない仕組み • 継続して開発するビジネスモデル • 技術の共通化でアップデートを容易に • 同じ基盤を使う人間による相互レビュー 2014/09/27 レガシーコード改善勉強会 6
- 9. そもそもレガシーコードとは何か？ • 誰かから引き継いだコード（つらい） • ぐっちゃぐちゃなコード（つらい） • 仕様が分からないコード（つらい） レガシーコード改善ガイドによる定義 「レガシーコードとは、単にテストのない コードです」（はじめに、より抜粋） 2014/09/27 レガシーコード改善勉強会 9
- 14. インフラも含めて、コード Data Center Server Operation System Middleware Production Code Server Operation System Middleware Production Code DB ServerLoad Balancer Infrastructure as Code 2014/09/27 レガシーコード改善勉強会 14
- 15. 変更できないインフラがもたらす混沌 サーバ（インスタンス） メールサーバ DBサーバ テスト環境のコード 本番環境のコード Webサーバ 振り分け 共用 ü OSのバージョンアップができない ü ミドルウェアにパッチを当てられない ü テスト環境での事故が本番環境に影響 まずインフラを 再構築しなければいけな いけど、影響範囲が 分からない。。 2014/09/27 レガシーコード改善勉強会 15
- 18. 2. 納品のない受託開発を支える、 レガシーコードを作らない仕組み 2014/09/27 レガシーコード改善勉強会 18
- 19. 納品のない受託開発とは 好評発売中！ • 要件を一度に決めない • 少しずつ決めて、少しずつ開発 • 継続して開発し続ける • 事業が終わるまでソフトウェアを 提供しつづける月額定額の契約 • 顧問としてお客様に関わる • つくることが目的ではなく、事業 にコミットするのが目的 （つくらずに実現できる方法も探す） 2014/09/27 レガシーコード改善勉強会 19
- 21. 所有から利用へ Point of Sales Point of Use 品 質 時間 品 質 時間製造業 サービス業 構築 償却 買った時点が最高品質 買った時点が最高で、 そこから陳腐化がはじまるもの 常に使っている時点で最高、 最新のものを利用できる 利用中が最高品質 （常にアップグレード） すぐに利用開始 継続して利用 2014/09/27 レガシーコード改善勉強会 21
- 28. 技術の共通化でアップデートを容易に フレームワーク Ruby on Rails 言語（処理系） Ruby インフラ Heroku /AWS 全てのサービスを共通の仕組みで構築する 2014/09/27 レガシーコード改善勉強会 28
- 29. レガシー化を加速させる大きな原因 C# / .net Windows Server PHP / CakePHP CentOS Ruby / Rails Amazon Linux バラバラなシステム システムが増えれば増えるほど保守が複雑化 システムを知っている人が辞めると 誰も保守できなくなる 2014/09/27 レガシーコード改善勉強会 29
- 31. 費用対効果を高くするための技術戦略 LCC（ローコスト・キャリア）に学ぶコスト戦略 • 使用する飛行機の機種を統一することで整備費やパイ ロットの訓練費を削減 • 搭乗手続きのオンライン化などITを活用した自動化 • 乗務員が機内の清掃なども行い一人何役もこなすことに よる人件費の削減 LCCのコスト戦略を 受託開発の技術戦略に応用 2014/09/27 レガシーコード改善勉強会 31
- 33. Ruby、Railsのバージョンアップには 追随しなくてはならない • セキュリティメンテナンスが終わるとセキュリ ティパッチが提供されなくなる • 放置しすぎるとバージョンアップが難しくなる （時間によりコスト増大） 少しずつバージョンを上げていくのが重要 開発を継続的に行うビジネスモデルともマッチ 2014/09/27 レガシーコード改善勉強会 33
- 35. 納品のない受託開発のインフラ Heroku AWS(OpsWorks) • PaaSであるHerokuを利用 • OS、ミドルウェアのバージョン アップはHerokuに任せる • 特別なミドルウェアを利用しない／ 特別な非機能要件がない場合に利用 • AWS OpsWorksによってプロビ ジョニング • 全ての設定はChefレシピで管理 • 基本となるレシピを統一化すること でコストを削減 監視システム群 • 死活監視にNagios、性能監視にNewRelic、障害監視にBugsnag、 プロセス監視にmunin、バックアップ監視に自社製ツールを使用。 • 自社製ツールにはサービスの標準的な設定を管理するチェックシートがあり、それ を埋めてはじめてサービスを一般に向けて稼働させることができるようになる。 2014/09/27 レガシーコード改善勉強会 35
- 37. 基盤を共通化したとしても残る問題 • 基盤を共通化しても、利用している決済 システムなど、サービスによって異なる 部分は存在する。特定の人しか保守でき ないものはレガシーだ。 • いくらテストコードがあっても、人に よって書き方がバラバラで、他の人が理 解できないコードだと意思疎通の道具に なりえない。 2014/09/27 レガシーコード改善勉強会 37
- 39. システムの知識が共有されていないと レビューは成り立たない 共通の知識がゼロ 共通の知識がある 知らないこと 知らないこと 知ってること （共通の知識） 2014/09/27 レガシーコード改善勉強会 39 ここだけ 気にすれば 良い 全く わからん どや！
- 40. コードレビューでレガシーにしない • テストは正しい動きを伝える手段だが、正 しく伝わることまでは責任を持たない • 読まれるまで読めるコードかどうかなんて 分からない • 人の目が入ることによって、より「読める コード」になる 読めないコードがレガシー化を加速させる 2014/09/27 レガシーコード改善勉強会 40
- 41. 今日お話した内容 1. レガシーコードの何が問題か？ • そもそもレガシーコードとは何か • レガシーコードがもたらす問題とは何か • コードだけの問題なのか？ 2. 納品のない受託開発を支える、レガシー コードを作らない仕組み • 継続して開発するビジネスモデル • 技術の共通化でアップデートを容易に • 同じ基盤を使う人間による相互レビュー 2014/09/27 レガシーコード改善勉強会 41
- 42. まとめ • レガシーコードの問題点は変更が困難になるために変 更コストが増大すること。しかし、その問題の解決に はテストコードがあるだけでは不十分で、インフラも 含めて変更可能になっている必要がある。 • 納品のない受託開発では以下の仕組みでレガシーコー ド化を防いでいる • 継続してい開発するビジネスモデル • 技術の共通化でアップデートを容易に • 同じ基盤を使う人間による相互レビュー 2014/09/27 レガシーコード改善勉強会 42 テクニックではなく、 仕組みでレガシーコードにしない