サイトの保守・運用の経験から開発現場の問題に気づく
吉田氏は、2013年4月にリクルートホールディングスへ新卒入社後、リクルート住まいカンパニーに配属され、SUUMOのキャンペーンサイトの開発や、サブサイトの保守・運用といった仕事を約1年間担当。その経験が現職において吉田氏が開発現場の改善を始めるきっかけになりました。
リクルート住まいカンパニー 吉田拓真氏
――現在どのようなお仕事を担当しているか、教えてください。
SUUMOのスマートフォン版サイトとPC版サイトの開発を進めるうえで、技術的な課題を解決し、エンジニアが単位時間内により多くのアウトプットが出せるような環境を作る仕事を主に担当しています。たとえば、スマホ版サイトの開発チームは約40人構成ですが、同時開発によるソースコードの衝突が起きないように、開発の順番を調整する、ツールによりソースコードの管理を自動化するなどの作業を行います。
――開発現場の改善はどのような理由から始められたのでしょうか。
今の業務の前に、規模が小さい複数のサイトを保守・運用していたのですが、そのときはただ保守するのではなく、問題が起きたときに二度と同じ問題が起こらないよう、抜本的な解決策を講じるといったことを行ってきました。その経験から、システムの運用および開発のプロセスは常に最適化すべきという思いがありました。今の仕事に移ったとき、最初に開発の進めにくさを感じたのですが、前の仕事と同様に最適化できるはずだと感じ、改善を始めました。
――どのような問題がありましたか？
リリースに時間がかかったり、システムが複雑で全容が把握しづらかったりといった課題がありました。現職に移ったばかりのとき、ある機能のテストを指示されたのですが、その環境がどこにあるか誰かに聞かなければわからない状態でした。ドキュメントを探しましたが、テスト環境を記述したものはどこにも見つからない。
また、ソースコードが手元になく、開発を委託していた会社にそのつどお願いしてソースコードをもらっていたため、バグが起こったときにその原因をすぐに調べられませんでした。
プロジェクト管理ツールが乱立しているという問題もありました。ツールをどのように運用して、プロジェクトがどのように進行しているかがわからない。プロジェクト管理ツールからデータを抽出してExcelで進捗管理していて、ツールを使っている意味がないといったケースもありました。
――なぜ、そのような状態になっていたのでしょうか。
同じシステムの開発に長く携わっていると、問題があることに気づきにくくなります。特に、そのやり方で開発を進めていて大きな問題が発生していなければ、次もその方法を踏襲して進めてしまいます。
私はシステムの保守・運用をしていた経験から、そこは問題だ、改善すべきだと気づくことができたのだと思います。
単にツールを導入するのではなく、まずは課題ありき
開発の現場に改善が必要と気づいた吉田氏は、まずはどのような課題があるかを自ら整理し、問題提起を行います。課題について上長の理解も得られ、上長のサポートのもと、開発現場の改善のための取り組みが始まりました。
――改善への取り組みはどのように始められたのですか。
まず、目についた課題を洗い出してみました。開発工程ごとに整理してみるといろいろな課題が散見され、このままではまずいと思い、問題提起を行ったんです。当時はまだ新人で問題提起をしやすい位置にいたし、課題とともに具体的な解決策を提示できたので、周囲から同意を得られ、改善を進めることになりました。
――新人だと逆に言い出しにくかったりしませんでしたか？
当社では、新人やベテランなどの立場に関係なく、課題に気づいて上申した人が主導して実行するという社風があり、上長も相談を受け付けてくれるし、サポートもしてくれます。上長にお伺いを立てながらではなく、自分のやりたいように進められたので、非常にやりやすかったです。
――失敗が怖いとは思いませんでしたか。
もちろん、失敗は怖いです。けれど、失敗するビジョンはありませんでした。当時は今より悪い状態を想像できなかったので（笑）、失敗を気にせず取り組めたというのもあります。
――開発現場への問題提起はどのように進められたのでしょうか。
自分で気づいたものだけでは偏りが生じるので、現場で開発を担当していたエンジニアにどんな課題があるかアンケートをとり、それらの課題をウォーターフォール型の開発工程ごとに整理した課題管理表を作成しました。たとえば、要件定義・設計工程には、課題として「コミュニケーションコストがかかりすぎ」があるという感じです。
続いて、その課題にどのような手を打つか解決策を考えます。現場ではチャットがなかったため「細かいことでもメールで連絡を取り合う」、ことだったり「進捗管理のExcelを作成するのに時間がかかる」といった課題があり、コミュニケーションコストが高くなっているようでした。ですから打ち手として「コミュニケーションで使うツールを整備する」といった方針を立てました。
そして打ち手として実際に利用するツールを決定し、改善後のあるべき姿と目標のレベルを設定します。
――課題ごとに、解決策だけでなく目指すべき姿とそのレベルを設定したんですね。
単に「ツールを導入する」では、導入したことでいったい何が解決されるかがわかりません。そのため「JIRAでプロジェクトをひとつにまとめること」など、実際の使い方をイメージできるようにあるべき姿を簡単な文章で定義するようにしました。
また、レベルは5段階に分け、現状はどのレベルか、改善後にはどのレベルになるかを設定しています。基本的には、すべての課題を解決し、レベル5の状態になることが理想ですが、開発を進めながら改善を行っているため時間がなく、リリース日などの制約があることから、直近の目標として達成可能なレベルを設定していました。
ウォーターフォール型での開発を継続しながら、段階的にアジャイル開発を導入
吉田氏は、作成した課題管理表をもとに現状の課題を解決する開発基盤の構築に着手。その一部の機能をアジャイル型で開発することで、現場を混乱させることなく段階的にアジャイル開発を導入していきます。
――課題管理表を作成した後、どのように改善を進めたか聞かせてください。
そもそも改善を行う最大の目標は、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度、まとめてリリースを行っています。また、リリース後にバグを発見した場合、これまでは一旦リリース前の状態に戻してから、バグを修正して再度リリースを行う必要がありましたが、今では、即座にバグを修正して最新の状態にする対策前進が可能になっています。
リリース自体の品質も向上しています。これまではリリース時間が長くならないように、リリース前のテストやコードの静的解析など処理の一部を省略していました。今ではチームが定義した「これはリリース前にやるべきだよね」という処理がほぼ実行できるようになっています。たとえばリリース前に画像のサイズを最適化する処理や、前述したソースコードの静的解析などがあります。
またリリース後にもいろいろな処理をできるようになりました。これまではログの目視チェックを手動でやっていましたが、この作業を自動化するツールを開発したりしています。
――開発チームにはどのような影響がありましたか？
リリースが短時間で効率的に実行できるようになり、リリースに対する考え方が変わったように思います。単にリリースを自動化して良かった、ではなくて、短縮した時間を使ってリリース作業自体をより良いものにしようという考え方に変わってきているように感じます。
また、チャットによりリリース作業が透明化され、誰でもリリースを実行し、リリースの前後の確認ができるようになりました。属人性が排除され、特定のメンバーに負荷がかることもありません。
「良いメディアを作る」ために、より優れた開発基盤を構築したい
――今後はどのようなことを行っていきたいか、展望をお聞かせください。
これまで開発現場の改善を行い、開発環境を整えてきましたが、まだ十分とは言えません。
インターネットは日進月歩の世界であり、競合サイトも当社と同様に努力を続けています。不動産サイトに限らず、インターネット上のコンテンツはコモディティ化が進みやすく、その中で生き延びていくには、競合優位性をいかに作り出すかが重要になると考えています。優れた開発基盤はそういった競争を続けるときに重要になってくるのかなと信じているので、引き続きより良いプロセス・基盤を目指していきたいなと思っています。
私の目標は「良いメディアを作る」ことです。今回はその目標に近づくために、ChatOpsを採用しましたが、これが最も優れた手段というわけではありません。さまざまな方法を模索し、活用していくことで、良いメディアを作るための努力を続けていきたいと思います。
