ウォーターフォール型での開発を継続しながら、段階的にアジャイル開発を導入
吉田氏は、作成した課題管理表をもとに現状の課題を解決する開発基盤の構築に着手。その一部の機能をアジャイル型で開発することで、現場を混乱させることなく段階的にアジャイル開発を導入していきます。
――課題管理表を作成した後、どのように改善を進めたか聞かせてください。
そもそも改善を行う最大の目標は、UI/UXをよりいっそう改善し、PDCA（Plan、Do、Check、Act）サイクルをより高速に回すことで、サイトのメディア価値を向上していくことでした。その目標を実現するにはアジャイル開発の導入がよさそうだと考えましたが、開発環境が整っていない状態では導入自体が困難だと感じていました。
そこで、課題管理表をもとに、課題を解決し、PDCAサイクルを高速化できるような開発基盤を構築することになったのです。基盤の構築では、プロジェクト管理ツールの移行、リリースを自動化するための仕組みなどをこれまでと同じウォーターフォール型で開発しました。一方、チャットを使って自動リリースの仕組みを動かす部分などを、アジャイル型で開発しました。
――なぜ、部分的にアジャイル開発を行ったのですか。
すべての開発に一気にアジャイル型を適用すると、現場に混乱を招きます。開発手法がこれまでとまったく異なるうえ、指揮系統も変わってきますから。そこで、すべてをアジャイル型に変えるのではなく、ウォーターフォール型では開発が難しいものに段階的に適用していきました。現在、スマホ版サイトは、ウォーターフォール型とアジャイル型の両方で開発しています。
――ウォーターフォール型とアジャイル型で開発する案件はどのように分けていますか。
大規模案件や難しい機能を含むシステム、既存のシステムの改修などは、これまでどおりウォーターフォール型で開発しています。
一方、これまでに前例がなく要件定義や設計が難しい場合は、プロトタイプの作成と修正を繰り返すことで機能を決めていけるアジャイル型で開発します。見た目や操作をすぐに修正できるため、UI/UXの改修もアジャイル型です。
ただ、厳格にこの基準で分けているわけではなく、案件ごとにその特性に応じて決めています。
ChatOpsによるリリースの自動化により、リリースの時間短縮、品質向上を実現
吉田氏が行った改善のひとつに、ChatOpsによるリリースの自動化があります。チャットでコマンドを叩くことにより、リリースに関わる処理が自動で実行できるという仕組みです。自動化によりリリース時間の短縮や作業の効率化が可能になり、チャットを使うことでリリース作業の見える化が実現します。
――ChatOpsによるリリースの自動化を導入した理由を教えてください。
開発現場では「リリースに時間がかかる」ことも問題になっていました。以前は手動でリリースを行っており、作業に1時間以上かかっていたんです。エンジニアにとって、開発以外の作業に1日1時間も費やさなければならないのは厳しい。そのため、1か月に一度、それまでに開発したものをまとめてリリースするという形をとっていました。
リリースの頻度が低いと、エラーの修正が遅れがちになります。また、新しい機能をユーザからの要望に応じて更改するといったことが難しくなります。リリースにかかる時間を短縮し、その頻度を上げるために、リリースの自動化を導入しました。
――なぜ、ChatOpsという手法を選択したのですか。
これまでリリースの担当者は1人で、作業が属人化しつつあり、リリースでいつどのような作業が行われているかがわかりませんでした。そのため、コミュニケーションツールを活用し、リリース作業を見える化したいと考えたのです。最も身近なツールとしてメールとチャットがありますが、メールは書くのが結構大変なので、チャットを選びました。
チャットは開発チームの誰もが利用するツールです。そこで、誰かがチャットで発言すると、それをトリガーとしてリリースが開始する仕組みを構築しました。発言があると各メンバーの端末に通知され、その内容を確認できるので、どのタイミングでどのような作業が行われているかリリースの進捗状況がわかります。
チャットによるリリースの自動化の様子。
サーバの起動・停止などを含めたリリース作業を簡単なコマンドを叩くのみで行えるようにしている。
――ChatOpsの導入で苦労したことがあれば教えてください。
ChatOpsでの自動リリースを作ること自体はそこまで時間がかからなかったのですが、ChatOpsというやり方が開発チームに浸透し、運用がうまく回るまでには苦労がありました。リリースでトラブルがあってサイトが落ちると、大きな問題になります。自動化したいのはやまやまだけど、何か起きたらどうするのか、今までの安定した方法を変える必要があるのかといった不安や抵抗感を払拭するのが大変でした。
――ChatOpsによる自動リリースを浸透させるために、どのようなことを行いましたか。
とにかく使い続けてもらいました。問題が発生しないようにまめにテストを行ったり、不満が出たら即座に解消したりしつつ、自分が立ち会うので新しい方法を試してほしいとお願いしてきました。地道な啓蒙活動でしたが、一番効果的であり、それ以外の方法はなかったと思っています。
――実際に現場に浸透するまでどれくらいかかりましたか。
2ヵ月くらいでしょうか。大きな問題が起きることなく自動リリースが実施ができていたことで、手動でやる必要はもうあまりないよね、という空気感が生まれ始めました。最初は自分がリリースを担当していたのですが、開発チームからこういう機能を入れてほしい、リリースの担当を持ち回りにしたほうがよいなどの意見が挙がるようになってきたときに、受け入れられてきたなあと感じました。
――ChatOpsによるリリースの自動化により、どんな改善の効果が得られましたか。
リリースにかかる時間が大きく短縮したことで、リリースの頻度を上げることができました。現在はウォーターフォール、アジャイル型のチームを含めると大体1週間に1度、まとめてリリースを行っています。また、リリース後にバグを発見した場合、これまでは一旦リリース前の状態に戻してから、バグを修正して再度リリースを行う必要がありましたが、今では、即座にバグを修正して最新の状態にする対策前進が可能になっています。
リリース自体の品質も向上しています。これまではリリース時間が長くならないように、リリース前のテストやコードの静的解析など処理の一部を省略していました。今ではチームが定義した「これはリリース前にやるべきだよね」という処理がほぼ実行できるようになっています。たとえばリリース前に画像のサイズを最適化する処理や、前述したソースコードの静的解析などがあります。
またリリース後にもいろいろな処理をできるようになりました。これまではログの目視チェックを手動でやっていましたが、この作業を自動化するツールを開発したりしています。
――開発チームにはどのような影響がありましたか？
リリースが短時間で効率的に実行できるようになり、リリースに対する考え方が変わったように思います。単にリリースを自動化して良かった、ではなくて、短縮した時間を使ってリリース作業自体をより良いものにしようという考え方に変わってきているように感じます。
また、チャットによりリリース作業が透明化され、誰でもリリースを実行し、リリースの前後の確認ができるようになりました。属人性が排除され、特定のメンバーに負荷がかることもありません。
