Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

レガシーシステム・レガシーソフトとむきあって

1,045 views

Published on

2018/11/22 レガシー感謝の日で発表した資料
レガシーシステムとクローンコード
チームとレガシー、チーム学習とふりかえり
「アルジャーノンに花束を」に触発されて書いたものです。
場所:豊洲アスクルさんのオフィス。
すごくきれいなオフィスでした。

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

レガシーシステム・レガシーソフトとむきあって

  1. 1. 1 レガシーシステム・レガシーソフト とむきあって レガシー感謝の日 そして、つらいレガシー開発体験に花束💐を 2018/11/22 @warumonogakari / かとうひろし
  2. 2. 2 本日のお題 • はじめに。 レガシーとは、レガシーソフト・レガシーシステムの定義 • さる国の公共システムと、クローンコード分析な話 • さる組み込み系制御ソフトのチームで取り組んでい ること • おわりに。
  3. 3. 3 そのまえに。おまえだれよ? • 妻の批判はアドバイスをモットーとする 認定 スクラムマスター(CSM)。 • 3年後によりよい開発体験を促すひとをめざ して修行中。 • 老後は猫や妖の置物を作ったり、歴史モノを かいたりできればと思います。 むかしむかし(1991~2001) さる大きなSIer勤務 ・機械学習・文字認識の研究、OCR製品開発~技術移転 ・データ分析、ソフトウェアメトリックスに関する調査研究 むかし(2001~2006) 関東・関西のさる複合機メーカ子会社勤務 ・複合機・オプションプリントコントローラーの試作~製品開発 ・共通化プラットフォームアーキテクト・開発リーダー及びマネージャ いま(2006~) 名古屋のさる複合機メーカ会社勤務 ・複合機組み込み系 Network部ソフト開発リーダー、複合機コントローラ ソフトリーダー ・Network部ソフト開発チーム エンジニアリングマネージャー 以下、スライド公開後に読めばOKな情報(公開します)
  4. 4. 4 そのまえに。おまえだれよ? • 妻 臨床心理士(スクールカウンセラー) • 妹夫婦 建築界のレガシー建築、宮大工 • 娘のように可愛がっている猫2ひき。 エラクないので、本日発表する内容は所属・ 関連する組織とは一切関係ありません。
  5. 5. 5 そのまえに。 実は初登壇。どきどき。。 • 現在どんなマサカリがとんでく るか ぷるぷるしております。 • 願わくはゴム製のマサカリで あることを。 • よろしくお願いします。
  6. 6. 6 本日のお題 • はじめに。 レガシーとは、レガシーソフト・レガシーシステムの定義 • さる国の公共システムと、クローンコード分析な話 • さる組み込み系制御ソフトのチームで取り組んでい ること • おわりに。
  7. 7. 7 はじめに。 -いろいろご意見はあるかとおもいますがこの場の定義として- • レガシーとは – 資産・遺産のこと。 • レガシーソフト・レガシーシステムとは – 数年から数十年にわたって使われているシステムおよ びソフトウェア – 有名なところではLinux、GNUソフトなどOSSも
  8. 8. 8 はじめに。 -いろいろご意見はあるかとおもいますがこの場の定義として- • レガシーとは – 資産・遺産のこと。 • レガシーソフト・レガシーシステムとは – 数年から数十年にわたって使われているシステムおよ びソフトウェア – 有名なところではLinux、GNUソフトなどOSSも • つらいレガシーソフト・レガシーシステムとは – ユーザからの新たな要求や、ハード構成の変化、デバッ クのための修正が長年にわたって繰り返された結果、ソ フトウェアエンジニアの開発体験がつらくなっていること
  9. 9. 9 本日のお題 • はじめに。 レガシーとは、レガシーソフト・レガシーシステムの定義 • さる国の公共システムと、クローンコード分析な話 • さる組み込み系制御ソフトのチームで取り組んでい ること • おわりに。
  10. 10. 10 さる国の公共システム • 20年以上にわたって開発 • 開発言語COBOL • 1883個のモジュールで構成、 全ソースコード行数100万行超 • 2001年ごろの調査(もう17年前ですね) • 当時としてはめずらしくリビジョン管理ができていた • いびつな年齢構成(逆台形/逆L字型)の開発体制 初期のころを知る50代社員でもっている(と言われていた)
  11. 11. 11 クローンコードとその計測方法 クローンコードとは • ソースコード中の重複したコード列のこと • 主にソースコードのコピペを行うことで発生 • ソフトウェア構造を複雑にし、品質を低下させるとい われている
  12. 12. 12 クローンコードとその計測方法 クローンコードとは • ソースコード中の重複したコード列のこと • 主にソースコードのコピペを行うことで発生 • ソフトウェア構造を複雑にし、品質を低下させるとい われている 計測方法 • プログラムの(部分)構文解析・字句解析を行い、パ ターンマッチャで照合 • 偶然に一致するパターンを排除するために、30行以 上一致したものをクローンコードと判定 30行という閾値は予備実験で(ソースコードを実際に見て)決めた 後に、ツール名 CCFinderとして公開。IPAの未踏事業プロジェクトのひとつ
  13. 13. 13 解析結果をすこし紹介: 年代別にどれだけクローンコードが発生したのか (1)最初のリビジョン(20~19年前)のクローンコードは多くない( 一番あるので100行あたり40数行程度;○印) (2) 5年たった時点でクローンコードがふえた (3)次の山はさらに5年たった時点。この時点で爆発的に (1) (2) (3)
  14. 14. 14 解析結果をすこし紹介:開発活動履歴との照合 1. (1)と(2)の間で一時的に減っているのは、当時は5年ごとの システム変更だったため。 2. (3)の時期は委託が実際のコードを書くようになり、さらに2 次請負・3次請負が活用しだした時期とちょうど合致 3. (3)の時期になると、システム変更間隔は随時へと (1) (2) (3)
  15. 15. 15 解析結果をすこし紹介: 流出した不具合とクローンコードの関係 • 実際に流出した不具合はクローンコードとそうでないコードと の相関はなかった • むしろクローンコードでの箇所では不具合は出ていない
  16. 16. 16 これには話にウラが。 • 流出した不具合=実際にお客さんに報告した不具合 公共システムなので不具合を流出させたら。。 • 絶対に流出させないように、関連クローンコードを全部 横並びにならべてレビューをかけるということを、この システムではやっていた(人力で) • どこが関連クローンなのかは、50代開発メンバ(の一 部)の頭の中 • 全体像を知っているのはさらに一部(わからないところ も含め)
  17. 17. 17 クローンコードと保守コスト • revision数が約4割あがり(図11)、実際に試算したところ保 守コストが(おおよそ) 3年で倍近くふえていた • 2次請負・3次請負がつくったコードを、50代社員が莫大なコ ストをかけながらチェック・デバックする • 50代社員がいなくなったらそれもできなくなる
  18. 18. 18 解析後なにしたか?:この当時やったこと • 保守性の高低:クローンコード計測ツールで算出 • 今後の変更予測:過去3年のリビジョン傾向から推測 保守性高 保守性低 今後の変更:多 今後の変更:少 本当にリファ クタしないとい けないところ Step.1 リファクタリング対象モジュールの抽出 塩漬け 問題な し 保守を つづけ る 保守性が低くて、今後も変更が高いモジュールは リファクタ、それ以外は目をつぶる
  19. 19. 19 解析後なにしたか?:この当時やったこと Step.2 リファクタリング=投資ととらえた 投資した場合と、しなかった場合の見積もり費用の算出(ざっくり) 投資した場合投資しなかった場合 費用 年数 費用 年数 リファクタすること決定
  20. 20. 20 もう少しくわしく知りたい方へ レガシーソフトウェアを対象とするクローンコードの定量的分析 http://ir.library.osaka-u.ac.jp/dspace/browse?type=author&value=Monden%2C+Akito コードクローンに基づくレガシーソフトウェアの品質の分析 http://apbilhqdmz135/wordpress/articlesharing/2015/09/30/%E3%82%AF%E3%83%AD% E3%83%BC%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AB%E5%9F%BA%E3%81 %A5%E3%81%8F%E3%83%AC%E3%82%AC%E3%82%B7%E3%83%BC%E3%82%BD%E3%83%95%E 3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%81%AE/
  21. 21. 21 ほかの類似事例は?ツールはあるの? 1000万行のコードと向き合う3つのステップ――富士ゼ ロックスはリファクタリングにどう取り組んでいるのか http://www.atmarkit.co.jp/ait/articles/1507/06/news009.html 16年間うごいているWebアプリケーションが抱えていた 技術的負い目を考察する http://tech.gmo-media.jp/post/135898835279/16th-debt 今だと SonerCube(OSS)+Understandがおすすめ ※SonerCubeでクローンコードをいい感じで計測できます
  22. 22. 22 本日のお題 • はじめに。 レガシーとは、レガシーソフト・レガシーシステムの定義 • さる国の公共システムと、クローンコード分析な話 • さる組み込み系制御ソフトのチームで取り組んでい ること • おわりに。
  23. 23. 23 現在、さる組み込み系制御ソフトの チームで取り組んでいること そのまえに 今日のお題は『アルジャーノンに花束を💐』からきて いるときいています。 『アルジャーノンに花束を💐』のテーマのひとつに、 知識と体験の学習がありますよね。
  24. 24. 24 さる組み込み系制御ソフトのチーム で取り組んでいること そのまえに 今日のお題は『アルジャーノンに花束を💐』からきて いるときいています。 『アルジャーノンに花束を💐』のテーマのひとつに、 知識と体験の学習がありますよね。 知識と体験の強化学習という側面から、チームと、 つらいレガシー・システムをかたってみようかと。
  25. 25. 25 なんで? 前のお話では、レガシーシステムをたてなおすことは できました。 でも、実は、開発メンバ(特に50代の中心メンバ)を幸 せにできたかは疑問でした。 今でも、ず~~っと もやもやしています。
  26. 26. 26 なんで? 開発メンバがかわらなければ、結局、レガシーシステ ムを刷新しても、またつらいレガシーシステムにもどっ ていくだけじゃないですか。 ちょうど『アルジャーノンに花束を💐』の主人公チャー リィのように。 開発メンバとともに学んでレガシーシステムに立ち向 かうことはできないかと。 今のチームではそんなことを取り組んでいます。
  27. 27. 27 で、機械学習 教師付・強化学習モデル 要件変更 資産 変更後 資産 評価 フィード バック 強化ス イッチ ここで強化したい対象とその際のInput・Outputって? 期待どおり動く 動かない教師付
  28. 28. 28 教師付・強化学習モデルをチームにあてはめる エンジニアチーム 要件変更 資産 変更後 資産 評価 フィード バック 状況認知 感情 チーム の行動 過去の チームの 行動 強化ス イッチ エンジニアチームと、その行動ですよね
  29. 29. 29 エンジニアチーム 要件変更 資産 変更後 資産 評価 フィード バック 状況認知 感情 チーム の行動 過去の チームの 行動 強化ス イッチ 教師付・強化学習モデルであらためてふりかえると 行動・状況認知 見落としがち 感情が強化しがち
  30. 30. 30 教師付・強化学習モデルであらためてふりかえると 開発体験 習慣化 エンジニアチー ム 要件変更 資産 変更後 資産 評価 フィード バック 状況認知 感情 チーム の行動 過去の チームの 行動 強化ス イッチ 行動・状況認知がもたらす開発体験 ひいては習慣がよりよいものになっているだろうか?
  31. 31. 31 で、レガシーソフトの場合 開発体験 習慣化 エンジニアチーム 要件変更 資産 変更後 資産 評価 フィード バック 状況認知 感情 チーム の行動 過去の チームの 行動 強化ス イッチ 想定していない度重なる要件変更
  32. 32. 32 レガシーソフトの場合 開発体験 習慣化 エンジニアチーム 要件変更 資産 変更後 資産 評価 フィード バック 状況認知 感情 チーム の行動 過去の チームの 行動 強化ス イッチ 過去のテ スト情報 の欠落 構造情報影 響範囲があ やふや 検討の結果、 資産に反映し なかったこと 赤吹き出し見落としがちな点
  33. 33. 33 レガシーソフトの場合 開発体験 習慣化 エンジニアチーム 要件変更 資産 変更後 資産 評価 フィード バック 状況認知 感情 チーム の行動 過去の チームの 行動 強化ス イッチ 過去のテ スト情報 の欠落 構造情報影 響範囲があ やふや 検討の結果、 資産に反映し なかったこと その場しのぎ の再発防止策 赤吹き出し見落としがちな点
  34. 34. 34 いつしか、チームは 開発体験 習慣化 要件変更 資産 変更後 資産 評価 フィード バック 状況認知 感情 チーム の行動 過去の チームの 行動 強化ス イッチ 度重なる 変化 過去のテ スト情報 の欠落 構造情報影 響範囲があ やふや 検討の結果、 資産に反映し なかったこと その場しのぎ の再発防止策 エンジニア烏合の衆 その場しのぎの再発防止が習慣化、つらい。。
  35. 35. 35 今やっている取り組み エンジニアチーム 要件変更 資産 変更後 資産 評価 フィード バック 状況認知 感情 チーム の行動 よその チームの 行動 強化ス イッチ 心理学と機械学習の知見から 変化があるInputと、強化スイッチの変更がカギ
  36. 36. 36 今やっている取り組み エンジニアチーム 要件変更 資産 変更後 資産 評価 フィード バック 状況認知 感情 チーム の行動 よその チームの 行動 強化ス イッチ 心理学と機械学習の知見から 変化があるInputと、強化スイッチの変更がカギ 勉強会 情報
  37. 37. 37 今やっている取り組み エンジニアチーム 要件変更 資産 変更後 資産 評価 フィード バック 状況認知 感情 チーム の行動 よその チームの 行動 強化ス イッチ 心理学と機械学習の知見から 変化があるInputと、強化スイッチの変更がカギ チームのため のふりかえり
  38. 38. 38 今やっている取り組み 開発体験 習慣化 エンジニアチーム 要件変更 資産 変更後 資産 評価 フィード バック 状況認知 感情 チーム の行動 よその チームの 行動 強化ス イッチ 心理学と機械学習の知見を参考に 変化があるInputと、強化スイッチをかえる 楽しい
  39. 39. 39 もちろん、開発基盤も整えています。 必要に応じ、リファクタリングは行っています。 劣化をふせぐために、すでにCIを取り入れました。 今、CDのスピードアップが課題です。悩んでいます。
  40. 40. 40 本日のお題 • はじめに。 レガシーとは、レガシーソフト・レガシーシステムの定義 • さる国の公共システムと、クローンコード分析な話 • さる組み込み系制御ソフトのチームで取り組んでい ること • おわりに。
  41. 41. 41 おわりに。 • レガシーソフトウェアに対し、どうやって見える化 • リファクタリングする・しないの進め方 • レガシーソフトをよくするだけでなく、チームをよくす ることも大事だと思いはじめ、取り組んでいます。 今回、組み込みソフトならではの話は、とり あげませんでしたが(時間の関係上)
  42. 42. 42 おわりに。 • レガシーソフトウェアに対し、どうやって見える化 • リファクタリングする・しないの進め方 • レガシーソフトをよくするだけでなく、チームをよくす ることも大事だと思いはじめ、取り組んでいます。 組み込みソフトも課題いっぱい、 でも、案外すてたもんじゃないですよ (^^)
  43. 43. 43 どうもありがとうございました💐 よい開発体験を。 そしてよい人生を。 ともにあゆみましょう。

×