BT

大規模システムの保守における技術的負債とチームのモラル

作者: Ben Linders , 翻訳者 吉羽 龍太郎 投稿日 2016年2月2日 |

原文(投稿日:2016/01/26)へのリンク

Agile Testing Days 2015において、Thomas Bradford氏はテストがなく大きな技術的負債のあるモノリシックなJavaベースのシステムの保守に関する経験について語った。InfoQは、システムを保守する上での問題や作りこまれた技術的負債、なぜ別のアプローチをとったのか、どうやってチームのモラルを向上させたのかについて氏にインタビューした。

InfoQ: 巨大なJavaのシステムを保守する上での問題について詳しく教えていただけますか?何が最大の問題でしたか?

Bradford: 私が当社に来たのは最近のことで、昨年の頭にエンジニアリングのVPとして採用されました。私の任務は、開発者がほぼ10年に渡って彼らを悩ませてきた過去の品質問題に取り組むのを手助けすることです。具体的にいうと、開発者はさらなる問題を引き起こすことなしにシステムを変更したりバグを修正したりすることが出来なかったのです。

InfoQ: 抱えていた技術的負債について説明をお願いできますか?

Bradford: 今のシステムはとても短い期間で、モノリシックな形で作られたものです。結果として、テストのカバレッジはほとんど全くありませんでした。それに加えてコードはぐちゃぐちゃで、重複や信じられないほど長いメソッドのせいで理解不能だったのです。保守は悪夢のようでした。

さらに問題を複雑にしたのは、これらをコントロールする取り組みがほとんど皆無だったことです。バグは、バグを作り出したチームに渡されるのではなく、それを修正する勤労学生に渡されていました。チームはずっと「はやくしろ」と急かされていて、勤労学生のためにバグを供給していたのです。

InfoQ: どうしてやり方を変えようと思ったのですか?

Bradford: 元からいた技術リードたちとの会話の中で、彼らは、製品を2度根本から作り変え、そのたびに同じような結果になった、と話していました。そこで私は戦略面だけでなく価値観の面でもやり方を変えるよう勧めたのです。

戦略面では、このモノリシックなJavaのシステムの保守においては負債をまったく返済しておらず、システムをレンガで囲ったり開発者がうんざりして辞めてしまったりしたために、結果的になにもリリースできなくなるまで、負債に溺れていたことが分かりました。

価値観の面では、何年もかけて築き上げた熟達から彼ら開発者を解放し、未熟者として別のやり方で問題解決にあたってほしいと思っていました。

InfoQ: システムのテストカバレッジを増やすためにどんな順番で進めたのでしょうか?

Bradford: 簡単に言うと、やりませんでした。

テスト自動化によってシステムをコントロールする取り組みがありました。私が入社する前に、手動のテストマトリクスを置き換えるためにSeleniumのテストスイートの作成を外注していました。また、主にシステムの汚い部分をコントロールするためにユニットテストのカバレッジを増やそうともしていました。でも、これらの取り組みはいずれも最終的な解決策とはなりませんでした。

本当の解決策は抜本的にアーキテクチャをリファクタリング、すなわちモノリシックなサービスを分解して複数の独立したサービスにすることと、まったく異なるスタックにしていくことでした。

InfoQ: チームのモラルをどう扱いましたか?

Bradford: 私が来たとき既にチームのモラルはどん底でした。これ以上悪くなりようがなかったのです。開発者は意気消沈していて、ソフトウェアの変更を恐れていました。ソフトウェアエンジニアとして経験する感情の中で最悪なものの1つです。

でも状況はよくなってきています。開発者は信頼され、自律的になってきており、過去の恐怖を克服し、創造性を探求できるようになってきています。そして同時に、以前よりもかなり高い品質でソフトウェアを作れるようになっています。

InfoQ: 大規模な技術的負債とその状況で不幸だった開発者、という問題を扱った経験から、提言をお願いします。

Bradford: 技術的負債はコントロールできるし、早い段階からコントロールすべきです。「あとで技術的負債を解消しよう」という考えは製品側の人たちを幸せにするかもしれませんが、現実には「あとで」は「決してやらない」ことを意味します。モノリシックなシステムの内部アーキテクチャが効率的に技術的負債を返済するのにふさわしくないといった私たちが直面したような状況に気づいたら、その技術的負債を返済するよう主張し、短期的に作る機能を減らすことが、組織の長期的な失敗を避ける上で妥当かどうかを決断するよう主張してください。ほとんどの企業は事業の継続を望んでいます。

プロのソフトウェア技術者として、私たちは自分たちの仕事の質に対する責任があります。外部の関係者は「はやくしろ」とか品質を妥協するようにプレッシャーをかけてくるかもしれませんが、私たちはそのような決断の影響に耐える唯一の存在ではありません。結局そのような決断は、組織が泣きを見ることになるのです。品質を主張すること、警告をあげること、「正しい」ことをするよう主張するのは私たちの仕事です。それは、例え上位組織がそうすることに対して長期的な価値を見いだせなくてもです。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション
サイト全般について
バグ
広告
記事
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com and 株式会社豆蔵 InfoQ Japan hosted at Contegix, the best ISP we've ever worked with.
プライバシー
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.