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