杉山祐一さん「改善失敗から学ぶ，レガシープロダクトに立ち向かうチーム作り。」

サイボウズの杉山祐一さんは，「⁠改善失敗から学ぶ，レガシープロダクトに立ち向かうチーム作り。」というタイトルで発表しました（発表資料⁠）⁠。

変更前の開発体制

はじめに，杉山さんが入社した時の体制について話しました。

当時はプログラマ同士のやり取りは，リーダーを含めて3人とだけ取れる状況だったそうです。コードに集中できる良い環境とも言えたのですが，闇も見えたとのことです。たとえば次のようなことです。

「このコードは読みにくいので，リファクタリングしてもいいですか」とリーダーに尋ねると，リーダーは「技術的負債箱に入れておいて」と伝え，実際に負債箱を覗いたところ既に100件以上が溜まっている状況だったそうです。「⁠負債箱に入れたらリファクタリングを開始してよいのか？」とリーダーに尋ねると，リーダーからは「次のバージョンの開発まで待って優先度をきめて実施する」旨を伝えられたと言います。

これは，社内の開発が数か月単位でのウォーターフォール開発だったためです。開発単位の中で難しい状況が発生していたために，このようなことが起きたと説明しました。

スクラム導入と失敗

杉山さんはこのような開発を改善すべきと考え，スクラム開発を取り入れようとしました。ただ，すぐに解決することはなかったようです。

スクラム開発はスプリントを繰り返す開発手法なので，とりあえず2週間ごとのイテレーションで回してみたそうです。数回回してみたところ，理想と現実のバーンダウンチャートで状態を確認すると，タスクの残り数が増え続け，消化が全く進まない状況を示してしまいました。

これは，スクラム開発が「計画」「⁠実施」「⁠振り返り」を行う開発手法であるにも関わらず，チームの中で「振り返り」を全く行っていなかったことが原因だったとのことです。

スクラムで振り返り：QAチーム編

振り返りの結果，さらに判明したのは「QAとプログラマで認識が違っていた」ことでした。これを踏まえ，QAとプログラマを完全に分けていた体制から，QA＋プログラマの１チームで開発を進める手法を取るようになったそうです。

その結果，実装を始める前に，実装範囲とテスト範囲を確認できるようになりました。またプログラマの知識とQAの知識を共有することで，お互いの作業が理解できるようになり，以前よりも開発が進めやすくなったと言います。さらに，スプリントの範囲の中で，プログラマ側がテスト範囲を理解できるようになったので，改善提案をしやすくなったとのことでした。ただ，以前に比べて，プログラマがコードだけに集中できなくなったというデメリットも挙げていました。

スクラムで振り返り：PMチーム編

さらに振り返りをしたところ判明したのは「プログラマ＋QAのグループとPMのグループにも認識差があった」ことがわかりました。この対応も，まとめてひとつのチームで進めていく手法を取ったと言います。

結果として，改善したいことの中に，抜本的な問題（リファクタリングの類の課題など）があったとしても，短いスプリントの中でテストを実施するかを試すような，柔軟な決断ができるようになったとのことでした。なお，PMのグループ統合については「組織変更したら部長がいなくなった」ことも付け加えていました。

スクラムで振り返り：製品文言修正チーム編

製品文言の修正といった小さいタスクも，修正のタスクを出しているエンジニアチームが修正までしてしまえばいいのでは？と考え，その改善を提案したこともありました。しかし，そのまま改善の提案を提出したところ製品文言のチームに怒られてしまったそうです。これは，エンジニアチームが製品文言チームの仕事を把握できておらず，ただ仕事をおろしただけになってしまったことに気が付けられなかったことが原因だったと振り返りました。

この問題に対応するため，非エンジニアな製品文言チームに対して，開発環境構築自体をシンプルにし，もろもろのドキュメントを準備するようになったそうです。その結果，文言開発チームもGitが怖くないという状況が作り出せているとのこと。さらに，製品文言チームが開発チームに対して，困ったときにいつでも聞いてもらえる関係性が作れたのが最大の収穫になったと話していました。

失敗して学ぶチームを強くする方法

次に，グループウェアGaroonの開発において，前任から引き継いで，自動テストを導入したときの話を取り上げました。

自動テストを導入するにあたって，ベトナムと日本のエンジニアで，コード品質の意識がそもそも違った点が問題になっていたそうです。ベトナムのエンジニアはスピードを重視したいとか，テスト実装コストが無駄だという考えを持っている人が多かったと言います。たとえば，CIが落ちている状態でも，実開発を優先させてしまっていたとのことです。

チームに「ルール」を課して品質をそろえようとしていましたが，うまくいってなかったそうです。杉山さんは，最初にチームの品質への意識をそろえて，「⁠ルール」ではなく「目的意識」を共有する必要があると感じたと言います。その際，杉山さんは「伝統とは火を守ることであり，灰をあがめることではない」という言葉を引用し，目的意識を共有する必要性を強調しました。

具体的には，拠点をまたいでのコードレビュー時に，『⁠リーダブルコード』をベースとして話すようにしたとのことです。『⁠リーダブルコード』の輪講前のコードレビューでは，主観の話に落とし込まれることが多く，その主観で議論が中断されてしまう結果となってしまっていたそうです。しかし輪講後は「書籍のX章にあるように○○と書いたほうがいいよね？」と指摘できるようになり，建設的な会話が続くようになったと話しました。

ほかにも，チームで勉強できる福利厚生として著名な開発者などを呼んでみることを実施しているそうです。

すべて解決？

このようにしてGaroonの改善は進めやすくなりましたが，17年の歴史に及ぶ負債が大変だそうです。さらに，振り返りのProblemの登録数がどんどん増えているのは悪くもあり良くもあると，杉山さんは悩ましそうに話していました。

最後に，今後も失敗しないことよりも失敗から学ぶ方法について考えたいとし，「⁠Garoonのプロジェクトでは，まだまだ失敗できる余地がある。たくさん学んで失敗して，チームを広げていきたい」と述べ，発表を締めくくりました。