こんにちは、エンジニアの松枝です。
私が所属する部署では企業が旅行検索サービスを作成できるSaaSプロダクトの開発、運用保守を行っています。ありがたいことに導入していただける顧客の数も増え、数多くの顧客プロジェクトが並走しています。
ただ、顧客数が増えるとともにSaaSプロダクトという特性上品質保証のための検証コストが高まったり、各顧客の要望に柔軟に応えるのが容易ではなくなってきました。
また開発がいくつも並走して行われ、プロジェクト間の連携がうまくとれず似たような機能の開発がそれぞれのプロジェクトで進んでしまったり、開発ブランチ運用やソースコードのコンフリクト解消に多大な時間を割く状態に陥ったりしました。
これまではプロジェクト毎に部署メンバーからそれぞれプロジェクトチームが編成され、そのチーム内でのコミュニケーションが主でした。ですので、他のプロジェクトチームがどういう開発をしているのかというのを認識できず、各々が自分のプロジェクトを遂行していく形となっていました。
これまでの教訓を生かし、SaaSプロダクトとしてあるべき姿実現に向けて現在は各顧客に専属チームを用意するプロジェクト軸から、各顧客の要望をプロダクトの機能として昇華し開発を推進していけるようプロダクト軸での開発を目指し日々業務改善を行っています。
(本文章中に出てくるプロジェクトは顧客プロジェクトを指しています)
現在行っている活動
開発前、開発中、開発後の3フェーズでそれぞれ現在行っている策について挙げていきます。
開発前
開発着手前の仕様検討の段階で顧客要望や抱えている課題を共有できる場を関係者の属性違いで複数用意しています。
プロジェクト内で要求された機能開発を担当しているエンジニアと顧客から要望を受けてくるビジネス職の方も含めプロダクト関係者全員向けに以下2つを用意しています。
- 週1の仕様検討MTG
- kigaruチャンネルと称した誰でも気軽に投稿できるチャンネル(弊社のコミュニケーションツールとしてSlackを採用しています)
１つ目のMTGでは開発要件となっている機能の概要を共有し、プロダクトの品質担保や運用保守の観点、横展開可能な形でプロダクトの機能としてどうすべきか、という議論をしています。関係者が多く集まっているため、複数の顧客観点で多角的な意見を得ることができ、議題にあげた者自身が考慮不足に気付けたり、提案した議題以上に洗練された案を持ち帰ることができます。
また、MTG参加者は自分が関与していない顧客プロジェクトでどういう機能が開発されようとしているのかを把握できます。
2つ目のSlackチャンネルでは相談・共有に対するハードルを下げるための取り組みで、つぶやきといったレベルのことでも誰もが気軽に書き込んで相談をしています。これは個々人のtimesチャンネルとは別の、プロダクト関係者が広く入っているチャンネルです。ちょっとした仕様確認や、ソースコードレベルの相談や開発環境で起こったエラーコードの共有などかなり細かい書き込みがされることが多く、新しく入ったメンバーも気軽に書き込めて助かっているという声を聞きます。
プロダクトエンジニア向けとしては上記のSlackチャンネルに加えて直接会話できる場として
- 日次の夕会
を行っています。
昨年度は参画しているプロジェクトが異なるプロダクトメンバー全員が日次で集う機会がありませんでしたが、今年度はプロダクトエンジニア全員がこの夕会に参加するようになりました。
ここでは先述のプロダクト関係者全員向けの仕様検討をするMTGの内容からより踏み込んだ実装方針に関する相談を行うことが多く、毎朝決まった時間に専用のスレッドが立つので業務中に思い付いた瞬間に書き込むことができ、共有漏れを防いでいます。
上記の各課題を共有できる場を設けることに加えて、開発規模の見積もりのみを行う専用のチケット起票も必須化し、開発着手予定の機能を一覧化しています。
このように事前に様々な粒度で開発予定の機能をプロダクト開発に携わるメンバー全員で把握していくことで、他顧客への横展開や拡張性が容易ではないような機能ができてしまうことを防ぐことに一役買っています。
さらに、実装方針の相談が活発に行われることでコードレビュー時のコンテクストキャッチアップのハードルを下げることもできています。
開発中
開発中の取り組みとして下記2つに取り組んでいます。
- 安全性を担保しつつコード管理を煩雑化させないためのブランチ運用
- プロダクト開発に携わるエンジニアによる迅速なコードレビュー運用
1つ目のブランチ運用について現在はプロダクトのmasterとして管理を1本化するようにしています。
以前はプロジェクトごとに開発ブランチを分け、タイミングを見定めて標準の開発ブランチにマージをするという方法を取っていましたが、実装の重複が発生したり、マージ作業・マージ後の動作確認に大変な労力を割くことになり、長い間masterとなるブランチが複数存在する状態が続くという課題がありました。(後述の各種ブランチの説明についても下記の記事に記載しております。)
現在はプロジェクト開発のスピード感とサービスイン済みシステムの安定感どちらも担保するため、2週間程度の期限付きプロジェクト開発用ブランチを用いる運用をしています。ソースコード管理にGitを利用しており、本流の開発ブランチであるdevelopブランチからdevelop-another(プロジェクト開発用ブランチ)を切り、プロジェクトにおける開発案件の改修はそのdevelop-anotherにマージし開発中プロジェクト専用環境へデプロイ・動作確認検証を経て、2週間の期限が来たらdevelop-anotherをdevelopブランチにマージする、というルールを設けました。
2週間程度の改修なので差分もそこまででなく、マージ時のコンフリクト解消も比較的容易に行えています。プロジェクト開発用ブランチへのマージはスピード感をもって行うことができるため、プロジェクト開発のスピードも叶えつつ、開発中プロジェクト専用環境にデプロイしテスターのチェックが入った後にdevelopブランチにマージされるため、サービスイン済みシステムへの品質を担保することができています。
2つ目のコードレビュー、つまりプルリクエスト(PR)の迅速なコードレビュー運用のためにレビューアーの数をなるべく多く確保するような取り組みを行っています。これまではPRを出した際にはプロジェクトチーム内での共有はあったものの共有先が限定的でプロダクトに携わるエンジニア全員が把握できる状態ではありませんでした。また、検証環境へのデプロイ直前にPRをマージしたいがための駆け込み的にコードレビューをするという状況になってしまっていました。
上記の課題を解決するために、今年度からプロダクト全体で出ているPRを把握するためのSlackのチャンネルを開設しました。このチャンネルはPRを出したタイミングで投稿するためのチャンネルで、チャンネルに流れてくるPRが現在プロダクト開発で出されているPRの総量となっています。開発量が可視化され、関わっていないプロジェクトでどのくらいの改修が行われているのかというのがはっきりわかるようになりました。
どうしてもプロジェクト外の人にレビューを依頼することに躊躇いを感じてしまっていましたが、専用のチャンネルを作りそこに投稿する、という運用にすることで全体に共有すること自体のハードルも下がりますし、共有する際に対応内容の優先度の共有や、要約をつけたりもしているので、レビュアーの数を確保するのに一役買っています。
この運用を開始してしばらく経った後アンケート調査を実施したのですが、PRが出されたことに気付くタイミングがチャンネルの投稿という回答が約9割に及び、半数以上の人がプロジェクト外のPRを見る機会が増えた・レビューされる機会が増えた、プロジェクト内外問わずコードレビューする回数自体増えたという回答を得ることができました。
また、PRが出されたときにタイムリーに気づくことができるのでレビューする契機が増え、レビューするタイミングがデプロイ直前のみではなくなりました。
コードレビューからデプロイまでの時間ができたので、レビューコメントに対して修正を行うのに十分な時間をとることができ、余裕を持った修正・リファクタリングを行うことができるようになりました。
さらに副次的な効果として、数多くの人が自分のPRを見るという状況と自分自身もいろいろな人のPRを見るようになり、PRをわかりやすくしようという人が増えてきました。
概要を充実させたり、gifやキャプチャで証跡を残したり、changesを少なくレビューしやすくするために機能毎にPRをわけたりなどです。
開発前の仕様や実装方針の検討をプロジェクト内で閉じず広く共有していくことに加え、開発中もコードレベルでプロジェクト内外広くコードレビューが入ることで、品質の担保をしつつ開発速度を保つ、ということができています。
開発後
開発後にどのような追加機能・機能改修が実際に行われたのかを共有する場を設けています。
これはすでにサービスイン済みシステムへの定期リリース前に行われることなのですが、リリース総量、改修内容の動作確認方法、具体的な機能内容の共有・把握をする場となっています。
スプレッドシートで管理し、いつどの定期リリースでどのような改修・機能がリリースされたのかが一覧化されています。
また対象顧客や対象機能を明記することで影響範囲の確認も行うことができます。このスプレッドシート自体はデプロイ対象のPRのマージ状況も記載しているため、デプロイ作業時にマージ漏れがないかどうかの確認にも一役買っています。
まとめ
このようにBtoBのSaaSプロダクト開発をしていくうえで、数々の困難はあるものの、多くの顧客に対してサービスを提供できる、という現状に誇りを感じ日々開発を行っています。
導入していただいている顧客の期待を超えるサービスを提供できるよう、これからも業務及びプロダクトの改善に励んでいきます。
この記事を書いた人
松枝友佳
2020年新卒入社
辛いものが大好きです、朝天辣椒という調味料にハマっています。
Discussion