私のアジャイルへの取り組みの歴史と現在

2010年に初めて XP に出会ってから4年が経過し、少なからず経験値も溜まってきました。今年からは私のノウハウを拙いながらもアウトプットをしていきます。

手始めに、私がアジャイルと出会った経緯と、これまでの取り組みを整理しておきます。

入社 ～ ウォーターフォールを使った開発演習

私は今の会社に2009年4月に新卒入社しました。私はホームページ作成のアルバイト等をしていたため、HTML, CSS, JS が多少使えましたが、ほとんど開発能力はありませんでした。

入社してから1ヶ月間、新人研修としてガチガチのウォーターフォールによる開発演習を行いました。これはひどい体験でした。誰もが意思疎通をできておらず、何度も高価な手戻りコストを支払い、最終的にはごく一部の機能しか実装できませんでした。チームの雰囲気も悪かったです。

この時に「ウォーターフォールは人間の働き方ではない」と確信しました。見当外れな予測の上に FIX されたスケジュールにチームが振り回され、生きた心地がしませんでした。しかし、当時はほかのやり方を何も知りませんでした。

EC プロジェクトへの参加

入社年の9月に EC サービスのプロジェクトに配属されました。当時の私の役割は、社内の企画担当部署の要求を協力会社に伝えるだけの SE でした。

このプロジェクトは社会人として初めて関わったプロジェクトでしたが、典型的なウォーターフォール型の過ちを犯していました。メインのコミュニケーション手段はメールやスプレッドシートで、あまりに多くの伝達ミスと仕様漏れが発生しました。リリース直前に毎回実装ミスに気付いて急いで修正するものだから、当然のように障害が発生しました。リリースは何度も遅延を繰り返しました。さらに、リリースのたびにデグレードが起き、障害が頻発しました。

協力会社はベンチャー企業だったのですが、しばしば担当者が変わりました。どうも毎日終電まで残って開発をする日々だったようで、すぐ耐えられなくなって辞めてしまっていたようです。一方で私は企画担当者の意図をブラッシュアップすることもせず、ボンヤリとした要件をただ伝言ゲームで渡すだけのダメエンジニアでした。

この頃から、「どうしてもっとうまくやれないのか？」「どうしてこんなに遅いのか？」「どうしてこんなに品質が低いのか？」という疑問を強く抱くようになりました。そしてより良いやり方を探すようになりました。

XP との出会い

2010年の初頭に 『アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング』 に出会い、初めてアジャイルプロセスを学びました。この本を読んだ時の感動は今も覚えています。プロジェクトを改善するための具体的な手法がいくつも提示され、そのアイディアに希望を見出しました。

しかしこの頃はまだ、技術的にも社会人的にも未熟で、周囲にこのアイディアの素晴らしさをうまく伝えることができませんでした。そのため、まずは個人でできることを実践し、その効果を実証することにしました。

この頃にバージョン管理、テスト駆動開発、リファクタリング、継続的インテグレーションなどの基礎スキルを習得しました。私の会社には100人以上エンジニアがいますが、当時はこうしたことを誰もやっていなかったようです。協力会社もやっていませんでした。

初めての XP チーム、そして大失敗

2010年の終盤に、社内システムの開発プロジェクトのチームリーダーに任命されました。当時の所属部署の一番偉い人が要望を出し、私を含む同期4名が開発チームとしてそれを実装しました。

この時、私は初めて XP をチームで実践しました。が、全くうまくいかず、最終的にこの案件は雲散霧消しました。

失敗の原因はいくつもありました。

まず、私以外のメンバーが誰もテスト駆動開発のスキルを持っておらず、継続的なリリースが全くうまくいきませんでした。私は開発と要件整理に手一杯で、スキルを伝播させる余裕がありませんでした。

また、要望を出す側は一番偉い人1人だけでいいはずなのに、スケジュールの都合でほとんどミーティングに現れず、別の管理職6名が代わりに窓口になるという歪な体制になっていました。本当に欲しい要件が何なのか全くわからず、作ってデモするたびにリジェクトされました。

この経験により、今となっては当たり前な以下のことを痛感しました。

  • 前もって正しい知識を学習しないと、誰も実践できない。
  • 知識やスキルの習得にはコストがかかる。
  • 「素晴らしいアイディア」を実践するのは難しい。

EC サービスの規模縮小、内製化、そして「ひとりスクラム」の開始

本業の EC サービスは十分な売上が上がらず、結局2012年1月には主要な店舗がクローズされました。しかし一部の店舗が残っていたため、システムは存続することになりました。 (この時点でプロジェクトの失敗は明らかだったのだから、システムごと廃棄するべきだったと思います)

規模と予算が縮小され、新規の開発要件が激減したため、協力会社との連携を解消して私が1人で開発・運用を担当することになりました。しかしこれは凄まじい苦行でした。

まず、システムは先述の通りつぎはぎだらけの非常に低品質なものでした。自動テストケースも無く、オブジェクト志向もまともに実践できていないメチャクチャなコードで、修正が非常に困難でした。バグも非常に多く、課金ミスやサービス障害が頻発していました。

課金と個人情報を取り扱うシステムのため、いい加減なコーディングによるミスは許されません。なぜ協力会社の人々がすぐに退職していたのかすぐに理解しました。このままではシステムに殺されると思いました。

そこで私は、当時強く関心を持っていたスクラムを採用し、一人で実践することにしました。これによってやるべきことの明確化と継続的な改善ができると考えたからです。

具体的には以下のように実践しました。

  • 不具合リストを作成し、プロダクト・バックログに並べる。
  • 2週間毎にふりかえり (レトロスペクティブ) を実践する。
  • 不具合修正の際には必ず自動テストケースを導入し、手動テストを行わないようにする。

この方法はうまくいきました。修正した部分は自動テストで保護され、確実に品質が改善できるようになりました。

この時私の支えになっていた書籍を2冊紹介します。

認定スクラムマスターの取得

EC システムの内製化には心を病む寸前まで追い詰められましたが、報酬として技術力の向上とスクラムの習得に繋がりました。

ふと社内を見渡すと、私よりひどいプロジェクトが無数に存在していることに気付きました。多くのプロジェクトは十分な利益を上げておらず、その改善策を考える暇も無いほど「価値の無い」タスクに追い立てられていました。実際会社全体は落ち目で、成長が止まっていました。

この頃には私は、もっと面白い仕事ができる会社に行こうと考えていました。ある程度エンジニアとしてのスキルが (大したレベルでは無いですが) 身に付いており、まだ20代でもあり、こんな顧客価値に繋がらないプロジェクトにいつまでも関わっていても将来に繋がらないと思っていました。

が、ふと立ち止まって考えました。スクラムを使って社内を改善することはできないか？スクラムは本当に組織レベルでも効果があるのか？こういう状況だからこそ試せるのではないか？と。

私は社内にスクラムを広める活動を始めることを決意しました。

私の会社は典型的なピラミッド構造の会社であり、若手エンジニアが好き勝手言っても上長の耳には届かないことを知っていました。そこで、少しでも肩書があった方が有利だろうと思い、2013年6月に認定スクラムマスターになりました。結果としてこの肩書は説得力の向上に若干良い効果があったと思います。

社内ワークショップの開始

2013年7月に、スクラムワーキンググループを立ち上げました。過去に社内で3ヶ月だけスクラムを実践していたプロジェクトのメンバー2人を誘いました。月1のワークショップを実践し、アジャイルプロセスを伝播し始めました。この取り組みは現在も続いています。

そのうちインターンシップ演習や新人開発研修のコーチを担当するようになりました。2013年12月には新人がスクラムチームを作って新しい Web サービスを作るという研修を実践したのですが、これまでに見たことのない成果を上げていました。恐らく従来のやり方しか知らない社員では3ヶ月かかっても完成できないであろうサービスを作り上げていました。これもまた、スクラムの効果を確信するきっかけになりました。

そして現在

現在は定期的に POStudy (プロダクトオーナーシップ勉強会) などの勉強会に参加しつつ、より良いやり方の学習と検証を続けています。

まだ十分に管理職クラスを巻き込めておらず、会社全体では依然として古いやり方が続いています。それでも、徐々にカンバンを社内で見るようになったり、アジャイルプラクティスが実践されている様子を見かけるようになってきました。

まとめ

長々と書きましたが、私がアジャイルプラクティスの啓蒙活動を初めてまだ半年しか経っていません。

今後も活動を続け、多くの人がハッピーになる仕事ができる環境を作っていくつもりです。

今年からはノウハウをアウトプットしつつ、外部の人々と頻繁に情報交換できるようにしたいと考えています。