はじめに・ユニット紹介児山祥

2023年新卒入社
2023年8月素材登録プロダクトにJOIN
関連記事：https://www.forcia.com/blog/002730.html

はじめまして。エンジニアの児山と申します。
新卒でフォルシアの旅行プラットフォーム部旅行技術3-2ユニットに配属され、三ヶ月ほど経ちました。
本ユニットでは、「良いプロダクト開発」を実践するために様々な取り組みを行っていますが、今回はその取り組みについて、ユニットメンバーにお聞きしていきます！

その前に、まず私から本ユニットで扱う素材登録というプロダクトと本ユニットについて軽く紹介します。
フォルシアにはwebコネクトという旅行商品販売用のプロダクトがあり、商品の登録から販売、予約まで行うことができます。
素材登録は、このうちの旅行商品の販売に必要な情報を登録するシステムを指しています。
旅行会社が自社で保有する商品だけでなく、商品情報を提供する他のプラットフォームの情報も一つのデータベースで登録/管理できるようにしたり、データベースから検索システムにデータを連携したりする役割を担っています。
そして本ユニットは、この素材登録システムに関わるメインのエンジニアで構成されています。

本ユニットでは、プロダクト品質向上のためのディスカッションを毎週30分行っています。
私は3-2ユニットに最近配属されディスカッションに参加していますが、そもそもこのディスカッションを行うに至った背景や過去のディスカッションの成果などをもう少し詳しく知りたくなり、各メンバーに直接伺うことにしました。

今回はユニットの先輩方から伺った内容を、読者の皆さんにも共有させていただきます。

まず初めに、ディスカッションを始めた経緯について伺いました。

ディスカッションを始めた経緯とテーマ島本晃平

2013年新卒入社
2021年8月素材登録プロダクトにJOIN
関連記事：https://www.forcia.com/blog/002737.html

近年、フォルシアではSaaS型のwebコネクトというプロダクトの開発に軸足を置いています。
従来のフォルシアは受託開発に注力しており「顧客ごとに価値を最大化する」ということを重要視していました。
そこからSaaS型のプロダクトとして「マーケットに対して価値を提供し続ける」ことにチャレンジすることになりました。
そして、我々のユニットには「中長期的な観点で共通化や運用効率を意識したプロダクトを開発する」というミッションが与えられています。

これらの背景から、「中長期的な視点で良い素材登録プロダクトとは何か」をユニット内で共通の認識を持てるように、2022年3月から「プロダクトの価値」についてディスカッションをする場を設けることにしました。

ディスカッションの最初のテーマは「素材登録は誰にどんな価値を提供するか？」でした。
当時、開発中・商談中の顧客のRFPの読み合わせをしたり、webコネクト導入の経緯を伺ったり、これまでの各メンバーが担当していた顧客の商品造成に関する知見・要望の共有をしたりと、まずはすでにわかっている顧客要求をキャッチアップすることから始めました。

そして、競合プロダクトに対する優位性を作るには何が必要かの議論を進めていくと、「商品の造成」という顧客ビジネスの中核を担うシステムは「UXの追求」といった特定の観点での優位性で新規導入が獲得できるというものではない、ということが理解できました。
さらに、顧客の既存業務を全て移行し、コストメリットもあり、使いやすく、さらに独自の価値を提供できてはじめて顧客に選ばれるという、営業部長がずっと言い続けていたことが腑に落ちるようになりました。

そこからは、顧客が満足する機能群をいかに早く作るかに視点を合わせ、ディスカッションの内容も「速く・品質が高いプロダクトを作る方法」を模索する議論へと変わっていきました。

ディスカッションから始まったアクション

ここからはディスカッションから生まれたアクションについて3名の方に話を伺います。
まずは羽間さんから開発速度の把握について教えていただきます。

開発速度向上への取り組み（開発速度の把握）羽間大晃

2012年新卒入社
2021年8月素材登録プロダクトにJOIN
関連記事：https://www.forcia.com/blog/002638.html

昨今、エンジニア組織の開発速度・品質を定量化する指標として、
GoogleのDevOps Research and Assessment（DORA）による研究で提唱された”Four Keys”がトレンドになっています。
Four keysは以下の4つの指標を指します。

指標定義デプロイ頻度組織による正常な本番環境へのリリースの頻度変更リードタイムcommit から本番環境稼働までの所要時間変更障害率デプロイが原因で本番環境で障害が発生する割合（%）サービス復元時間組織が本番環境での障害から回復するのにかかる時間

参考：エリートDevOpsチームであることをFour Keysプロジェクトで確認する - Google Cloud公式ブログ

優れたプロダクトを生み出す開発チームはこれらの指標も優れていることが多いようです。
我々のチームでもこれらの指標を導入することを検討しましたが、素材登録プロダクトはまだ本番稼働しておらず、開発フェーズにありました。
1日に1回、多い時は数回デプロイされるような状況で開発速度は速いといえそうでしたが、未マージのMRが毎日30件程溜まっており、不具合も日々散見されていました。

そのような状況下でまず指標としてウォッチしたのが、「マージリクエスト（MR）がマージされるまでの所要時間」です。
我々のチームでは、チーム内のエンジニア2名からサムズアップを貰うとレビュー完了となり、マージしてよいとする運用としています。
マージまでの所要時間が長いMRを実際に皆で確認したところ、所要時間が長いMRには特徴があり、開発期限が迫って十分にレビューされないままマージされていることや不具合が発生するケースが多いように見受けられました。

具体的には、以下のような特徴です。

MRの粒度が大きく、レビューしづらい
ドメイン知識や技術知識が不足しており、レビューできない
MRを出すエンジニアの習熟度が低く、設計思想から外れた改修をしてしまっている

そこで、これらの特徴に着目し、マージまでの所要時間短縮を目指す取り組みを始めました。

続いて奥田さんからマージまでの所要時間短縮の取り組みのうち、特にMRレビュー速度向上を目指す取り組みについて伺います。

開発速度向上への取り組み（レビュー速度向上への取り組み）奥田侑紀

2022年キャリア入社
2022年7月素材登録プロダクトにJOIN
関連記事：https://www.forcia.com/blog/002662.html

素材登録プロダクトでは、プロダクトメンバー全員が週3回MRをレビューする会を開催しています。
この会の目的は、メンバー全員がプロダクトのコードに対する理解を深め、滞留MRのマージを促進するためです。

開催のきっかけは、開発途中で私を含む複数のメンバーが新たに加わり、結果としてMRの作成者に対してレビューできるメンバーの数が少ない状態となり、MRがレビューされずに滞留するようになったからです。
この問題の原因は主に2つあります。1つは、プロダクトのコードベースが非常に大きく、ドメイン知識が必要な部分も多いこと。もう1つは、プロダクトにおけるレビューやApproveの基準がメンバー間で十分に共有出来ていなかったことです。

問題解決のために、メンバー全員が集まりコードレビューをする「コードレビュー会」を始めることにしました。
レビュー会ではMR作成者が対応内容・背景、特にレビューして欲しい内容を共有し、習熟度の高いメンバーからのフィードバックや習熟度の低いメンバーからの質問をベースに議論をしながらレビューします。

コードレビュー会を続けていて下記の成果が見え、よりスムーズに開発が行えるようになりました。

滞留MRが減り、MR全体のマージまでの所要時間短縮につながった
細かい実装での困りごとなどをメンバーに相談できる機会が増えた
設計・実装方針や顧客の要求などシステムの理解を深めることにつながった
レビューの温度感・基準の共有につながった

レビュー会の実施でMRのマージまでの所要時間短縮につながったのですね。
では、開発「速度」向上ではなく「品質」向上のための取り組みについて吉田さんに伺います。

開発の品質向上のための取り組み（ディスカッションからADR作成へ）吉田侑弥

2020年新卒入社
2021年8月素材登録プロダクトにJOIN
関連記事：https://www.forcia.com/blog/002765.html

プロダクトとしての品質を論ずる上で、時にはアーキテクチャに目を向ける必要も生じます。

フォルシアでは多くの場合、個別の設計や実装方針に関する裁量権のほとんどが実装者にあります。
疑問があればチームで議論しますが、あくまでふわっとした方向性を決めるものに留まることが多いです。

素材登録プロダクトはフォルシアの中では開発人数が多く（エンジニアだけで15名程度）、十分なノウハウがない領域であり、色々な経歴を持つメンバーが手探りで進めていくようなプロジェクトであったため個人の習熟度にムラがありました。

また膨大な開発量と開発スピードが求められ、レビュー段階になって双方が納得いくまで方針レベルの議論を続けるというのも現実的ではありませんでした。
このため、実装者の方針に委ねる従来の進め方では相談、議論のコストが増え、開発速度とコード品質の両立が難しい状況にありました。

これを解決する手段として、チームでアーキテクチャ決定レコード（ADR）を残す試みを始めました。
ADRは判断が難しい問題でたびたび悩む、過去の議論が蒸し返されるといった事象を防ぐため、アーキテクチャに関する決定事項と対案、現案を採用した理由などを残す仕組みです。
過去の決定事項を変更する場合には書き換えるのではなく、古いADRを破棄した上で新しいADRを書く、という形を取ります。これにより過去の議論や変更された経緯を後から確認できます。

ユニットは開発のコアメンバーとして、アーキテクチャレベルで思想・設計の方針を整理、再考し、ADRとして記録する役割を担うようになりました。
記録したADRは開発チームに共有した上で承認され、アーキテクチャ決定となります。

ADRの効果としては初期開発が一段落した後に始めたのもあり、既存の開発フローに大きな変化を加えるまでには至りませんでした。
一方で既存のアーキテクチャへの正当性の検証という意味では意義がある活動だと感じました。
今後も継続的な追加開発が求められるサービスであり、今後の開発の指針としては十分に役立つものになっていると思います。
またメンバーが流動的なため、新規メンバーへのプロダクト説明という役割も持たせられそうでした。

ディスカッションに対するフィードバック

羽間さん、奥田さん、吉田さんにディスカッションから生まれたアクションについて伺いました。
ここからは、ディスカッションがどのようにプロダクト開発に活きているかを2名の方に伺います。

ディスカッションが実装時の参考になること/ディスカッションの利点松下祐樹

2022年新卒入社
2023年2月素材登録プロダクトにJOIN
関連記事：https://www.forcia.com/blog/002766.html

我々のユニットでのディスカッションでは、主に実装時に個々人の困ったことや、よりよいプラクティスへの探求が行われます。

1つの実現したいことに対して、あまりいい方針が浮かんでない場合や様々な方針が考えられる場合に、よい方針がないか検討してみたり、各方針のメリットやデメリットを議論することで、それぞれのアプローチについて、知見を深めることができます。

一般的なレベルでベストプラクティスとして語られていることはもちろん、そうではないアプリ特有の話やビジネスロジック、個人の経験などもふまえたうえで良し悪しについても議論することで、アプリとしてのベストプラクティスも探っていけます。

さらに、議論自体もエンジニアとしての成長につながりますが、議論した内容は直接的に実装の参考になります。
また、全員で議論し内容を共有することで、実装方針がより統一的になります。

そして、吉田さんからも紹介がありましたが、アーキテクチャレベルでの思想・設計の方針についての議論は内容をまとめあげて、ADRとして残しています。
書面として残すことで、開発初期の設計を決めていくフェーズでユニットに所属していなかった人でも知見を得ることができ、実装における道標となってくれるでしょう。

ディスカッションをさらによくするには恒川雄太郎

2021年度キャリア入社
2022年7月素材登録プロダクトにJOIN
関連記事：https://www.forcia.com/blog/002489.html

私からはチームに途中から参加した人間の視点でこのディスカッションに参加して思ったことを紹介します。
このディスカッションの場に参加して、設計に関する「よい・わるい」を考える力が鍛えられると感じています。アプリケーションやデータベースの設計に関する勘どころは独学で積み上げることが難しく、書籍などで一般論を学んでも現場で活かしづらいと思っています。

このディスカッションではメンバーが意見を交わすことで初心者は判断の下地ができ、熟達者は考えを整理できると感じています。また、現場で得られた生の経験は固有のアプリに閉じず、一般のエンジニアリングで応用できると考えており、自分にとっては有意義な時間となっています。

今後このディスカッションで類似のプロダクトをメンバーと研究してみるのもおもしろそうと考えています。
オープンな類似プロダクトをチームで触ってみて「ここがいい・わるい」を議論することで、自分たちのプロダクトのいいところを認識したり、よりよくするためのアイディアが生まれたりすると楽しそうだなと思っています。
自社のアプリを触るときはエンジニアとして中のつくりに注目しがちですが、他所のアプリを触ることでユーザ目線の気づきが得られることを期待します。

インタビュー後記

ここまでユニットメンバーから色々話をお聞きしてきました。

ユニットディスカッションのテーマが「プロダクトが提供する価値」から「開発速度・品質の向上」に変わっていき、

開発速度の計測からレビュー会による速度向上の実現
設計・思想のディスカッションから共通認識の醸成やADR作成

のようなアクションに派生していったのですね。

私がチームに参加した時には既にプロダクトがおおよそできあがっており、開発体制もある程度整っているように感じていましたが、開発を進める過程で試行錯誤した結果であることを知りました。
レビュー会やユニットディスカッションで知識の共有がされることで、確かに参加したばかりのエンジニアでも作業を進めやすかったなと改めて思いました。

しかしプロダクトが非常に大きいこともあり、こういった受け入れ体制がある中でもやはりまだ理解が難しい部分は多いので、引き続き頑張ってプロダクトの理解を深めていきたいと感じました。
また自分自身が学ぶだけでなく、今後参加する新メンバーが作業に取り掛かりやすいよう、ドキュメント作成などを通じて受け入れ環境をさらに整えていこうと思いました！