2024-12-12

毎週金曜日夕方に行われる脆弱性対応の会について

Cake.jp技術部の山内です。

みなさん、セキュリティ対策してますか？

新しいコードはある程度気をつけていても、古いコードに脆弱性が残っていたりはしませんか？

優先度が上げられず、脆弱性が残り続けていませんか？

・・・。

弊社がどうなのかはあえて明言しませんが、上記の状況を打破すべく（ほぼ言っている）、有志にて金曜日の17時から脆弱性対応という会を行なっています。

2024/05から現在（2024/11時点）まで、約半年ほど行なっています。

本日はその会について話していきます。

会の目的

会を行う目的は、大きく2つあります。

脆弱性のある箇所を減らす
セキュリティ意識を上げる

ここについては狙い通り進められていると思います。

後者の「セキュリティ意識を上げる」は、レビューでの指摘などを通して、参加者に限らず全体に広がっていっているように感じます。

セキュリティへの意識が上がったことをキッカケに、2024/07~2024/10にかけて『Webブラウザセキュリティ ― Webアプリケーションの安全性を支える仕組みを整理する』という書籍を輪読会で読んだことも、意識向上につながっていると思います。

会の流れ

この会をどのように進めているかについてですが、一人がドライバーになり、他の人はそれを見つつ意見を言う、モブプロ形式で行なっています。

ドライバーは日毎に固定で、ツールはSlackのハドルを使用して、画面共有をしています。

対応する内容は、「対応したいことリスト」が存在するので、そこから選んで対応します。

対応完了したものは、翌月曜日にリリースしています。

対応したこと

色々と対応してきていますが、主には以下を潰していっています。

SQLインジェクション対策
XSS対策
ファイルアップロードの脆弱性対策

SQLインジェクション対策は、実際に攻撃する穴があってそれを塞いでいるというよりは、そういったアクセスがあった時点でブロックするような対応を行っています。現在まで何週にもわたって対応を続けています。

他には、脆弱性対応の会と言いつつも直近で発生した不具合を調査したり、問い合わせの調査をしたりということも行っており、柔軟に対応することを決めています。

発見経路の一例

前述した内容を対応するには、それらを発見する必要があります。

脆弱性診断を受け発見された例もありますが、それ以外を一つ紹介します。

弊社では開発言語としてPHPを使用しており、現在使用しているバージョンは8.3です。

1年半前までは5.6で、この1年半で少しずつバージョンを上げてきました。

バージョンが上がるごとに言語としての厳格さが増してきており、それに伴って今まではエラーにならなかったものがエラーになるようになっていきました。

そのエラーを調べてみると攻撃を受けていた、というケースもあり発見に至りました。

そういったものも、この会で対応していっています。

効果

対応したことであげたSQLインジェクション対策の効果について触れていきます。

（XSSとファイルアップロードの脆弱性については、そこを攻撃されたという記録はなく「塞いだ！」としか言えないので、、、）

まず前提として、弊社ではWAFを導入しています。

しかしWAFをすり抜けてくる攻撃が少なくありません。

（SQL エスケープしているので、データベース改ざんなどの被害はありませんが）

それがアプリケーションサーバやデータベースサーバの負荷が上がる原因になっていました。

SQLインジェクション対策によって、攻撃がアプリケーションに到達しにくくなり、攻撃があっても、アプリケーションサーバやデータベースサーバの負荷が上がりにくくなりました。

おかげで、休日に攻撃を受けて攻撃者をブロックする、という回数が激減して嬉しい限りです。

今後について

会の拡充はそこまで考えていません。

今は、「週の終わりにそこまで気張らず」というような雰囲気でやっています。

継続的にやれている一つの要因ではあると思っています。

このまま続けていって、少しでも堅牢なサービスを目指して続けていければと思います。

引き続きセキュリティ意識を高めていって、「セキュリティ意識高い系」な開発組織になっていければと思います。

2024-11-21

Aurora MySQLのブルー/グリーンデプロイを使用してMySQLのアップデートをした流れと苦労

Cake.jp技術部の山内です。

2024/10末にMySQL8.0へのアップデートを行いました。

弊社ではAWSを使用しており、MySQL5.7のサポートが2024/10/31で切れてしまう、かつ、それ以降は追加料金が発生するという状況がありましたので、弊社でもやっと対応しました。

ということで、今回は弊社で行なったアップデート作業について書いていきます。

どのようにアップデートを行ったのか

先ほどお伝えしたように、弊社ではAWSを使用しています。そのためDBの環境として、Aurora MySQLを使用しています。

そのAurora MySQLに用意されているブルー/グリーンデプロイを使用しました。

他の手段としては、既存クラスターをそのままアップグレードする「インプレースアップグレード」、スナップショットから復元する「スナップショットリストア」などがありましたが、ダウンタイムの少なさと作業の容易さなどの観点から、ブルー/グリーンデプロイを選択しました。

本番対応までに何をしたのか、その後どのような問題があったのかについて記載していきます。

アップデート実施までの道のり

作業概要

慎重を期すためにも、いくつかのステップを踏んで行きました。

まずはローカル環境での動作確認を行いました。問題ないことが確認できたのち、テスト環境の予行練習、テスト環境のバージョンアップを行いました。

テスト環境で1週間程度運用してみて、問題がなさそうだったので、本番の予行練習、バージョンアップと進んでいきました。

一覧化すると以下になります

ローカル環境で動作確認
テスト環境のバージョンアップの予行練習
テスト環境をMySQL8にバージョンアップ
本番環境のバージョンアップの予行練習
本番環境をMySQL8にバージョンアップ

ローカル環境で動作確認

作業ブランチを作成し、そちらの環境をMySQL8に変更しました。この環境で動作確認を進めました。

動作確認方法

弊社ではPHPのバージョンアップを進めており、その際に行っていた動作確認を行いました。

主に以下のようなことをしていました。

CIでテスト実行
一括でCURLでHTMLを取得し、MySQL5.7環境とMySQL8.0環境に差分がないかdiffコマンドでチェック
TestCafeで主要どころの自動E2Eテスト

PHPバージョンアップの際に、少しずつ育てていました

バッチの一括実行で動作確認

途中終了はないか、ログにエラーは出ていないかを確認

その他気になるところは手動で動作確認

テスト環境のバージョンアップの予行練習

テスト環境のMySQLのバージョンアップを行うための予行練習をしました。念には念を。

以下手順で実施しました。

テストDBのスナップショットを取得
スナップショットから予行練習用DBを作成
予行練習用のblue/greenを作成
切り替え
切り替わりの確認

MySQLへログインしてstatusコマンドを実施

動作確認実施

上記手順で問題なく切り替えができることを確認できたので、テスト環境のアップデートを実施します。

テスト環境をMySQL8にバージョンアップ

こちらは手順としては予行練習とそこまで違いはなく、既存DBを使用するため、スナップショット周りの対応が不要になります。

blue/greenを作成
切り替え
切り替わりの確認

MySQLへログインしてstatusコマンドを実施

動作確認実施

これでテスト環境が先行してMySQL8.0になりました。1週間程度使用してみて、特に問題が出なかったので次に進みました。

本番環境のバージョンアップの予行練習

基本的にはテスト環境の予行練習と同じ手順で行いました。

テストDBのスナップショットを取得
スナップショットから予行練習用DBを作成
予行練習用のblue/greenを作成
切り替え
切り替わりの確認

MySQLへログインしてstatusコマンドを実施

動作確認実施

ここでも特に問題は見つからなかったので、いよいよ本番です。

本番環境をMySQL8にバージョンアップ

本番の手順はテスト環境のバージョンアップの手順に加え、少し本番環境らしい対応が追加されています。

メンテナンスモードに移行 new!
blue/greenを作成
バッチの停止 new!
切り替え
切り替わりの確認

MySQLへログインしてstatusコマンドを実施

動作確認実施
バッチを再始動 new!
メンテナンスモードの解除 new!
停止中に稼働するはずだったバッチの再実行 new!

ダダーッと書いていきましたが、ブルー/グリーンデプロイのおかげで、特に難しいことはなく進められました。

苦労したこと

非常に時間のかかった対応がありました。

ブルー/グリーンデプロイに失敗

エラー発生箇所

ブルー/グリーンデプロイの作成を成功させる、これに非常に苦戦しました。

blueはMySQL5.7、greenはMySQL8.0という環境で作成をしたのですが、どうやら互換性のないものが存在するらしくエラーで失敗しました（エラーメッセージを探し出せませんでした、、、）。

とあるテーブルにtinytext型のカラムがあったんですが、そのカラムの存在がエラーを発生させていました。

以下の公式リファレンスを見ても、なぜエラーになってしまうのかは理解できていません。

2.11.4 MySQL 8.0 での変更
11.3.1 文字列データ型の構文

ここにもtinytextの記載は存在する

エラーの特定

ピンポイントに、「ここが互換性ありませんよ」としてくれる手段が見つけられず、地道に特定作業をしていました。

検証用のDBをテストDBの内容に合わせる
テーブルを半分削除し、blue/greenの作成
失敗したblue/greenの削除
1に戻る

こういったサイクルをひたすら繰り返して、対象を探してました汗

最終的にカラムの特定に至るまで20回程度この作業をしていました涙

ちなみにですが、Upgrade Checker Utilityなるものが存在しますが、これでは検出されませんでした。

DMSが連携に失敗している

弊社では社員全員がDBの閲覧が可能です（個人情報などの情報は落としています）。

そのDBへの連携としてDMSを使用していますが、そこで不具合が起きていました。

エラー内容と対応

以下のエラーが出て、連携に失敗していました。

E: Error Code [10001] : Binary Logging must be enabled for MySQL server [1020418] (mysql_endpoint_capture.c:424)

結論としては、パラメータグループのbinlog_formatの設定漏れでした。

新しくMySQL8用のパラメータを作成した際にbinlog_formatをデフォルト（OFF）のままにしていたせいで、連携に失敗しました。

ですので設定をROWに変更することで無事連携に成功しました。

スッと書きましたが、この設定の反映にはインスタンスの再起動が必要なので、2日連続の深夜メンテです・・・。

さいごに

今回の対応において、サービス側では特に不具合は発見されておらず、ホッとしています。

慎重に事前準備をしたことが、サービス側での不具合なしに繋がったと思っています。

MySQL8へのバージョンアップ前は、PHPのバージョンアップも行っており、1年半かけてPHP5.7からPHP8.3まで上がりました。

PHPは8.3、MySQL8.0とかなりモダン風な開発環境になってきたなーと感じています（当社比）。

今後も開発環境のアップデートは放置せずに進めて行きたいと思っております！

2024-09-24

Cake.jpとテスト駆動開発

こんにちは、Cake.jp技術部でエンジニアをしている山内です。

この記事では、Cake.jpのエンジニアがどのような場面でテスト駆動開発（以下、TDD）を取り入れているのかについて話します。

※今回はTDDがどのようなものかは割愛させていただきます。

導入の背景

前提として、3年ほど前はテストコードがあまりない状況でした。

そこから、チームとしてレガシーコードに立ち向かうために、テストコードを書くということを推し進めていきました。

中にはTDDを実践しているメンバーもおり、週2で行なっているモブプロの中でTDDが行われ、さらに小話会（好きに技術の話をする時間）で共有されたりということを経て、社内でもTDDが広がっていきました。

個人的には、書籍などでもよく言われる「テストを書きやすいコードを書くことで、設計が良くなる」というのも感じていますし、TDDがうまくはまった時はゲーム感覚で実装できるという楽しさもあり、積極的にTDDを取り入れています。

※弊社のモブプロについて: 「コンテキストの共通化」を加速させるために1年以上モブプロを続けた結果

どのような場面で採用するか

TDDを取り入れているとは言いましたが、全ての開発で取り入れているわけではありません。

傾向としては以下のようになります。

	複雑度が高い	複雑度が低い
新規開発	◯	×
追加開発	△	×
不具合修正	△	×

複雑度が低いケースでは、TDDは行わない（テストを書かないという意味ではないです）ケースが多いです。

そういった場合は、今までやってきたことに似た実装であるケースが多いので、ササっと書いてしまっています。

複雑度が高いケースについて、それぞれ補足していきます。

新規開発 × 複雑度が高い

新規開発で複雑度が高いので、TDDチャンスです。

特に補足も必要ないと思います。

追加開発 × 複雑度が高い

ここを△としていますが、大きく分けて二つのパターンがあります。

ファットコントローラーで機能追加が辛い
それ以外

分類がアレな感じはありますが、、、

1番目のケースはそもそもテストを書くのが辛いパターンです。

弊社のサービスはコードベースだと10年選手で、当時から膨れ続けているようなコントローラーも存在します。

丁寧に剥がしていけば良いという話ではあるんですが、機能追加の頻度が高くない場合が多いので、そこまでリファクタ工数を取れないのが現状です。

不具合修正 × 複雑度が高い

こちらも△としていますが、多くの場合は不具合用のテストケースを先に追加して、それを通すための実装をしています。

テストファーストで不具合修正をしているものの、「レッド／グリーン／リファクタ」というthe TDDな開発ではないので、△としました。

成果

一言で言うと、不具合が減りました。

ただし、TDD一本で不具合が減ったというわけではありません。

僕が入社した当初（2022/08）は今と比較して、不具合が多く発生していました。

不具合が出るたびに振り返り→改善を繰り返していきまして、今では不具合が激減しました。

不具合が減った理由の一つに、TDDがあると思っています。

さいごに

Cake.jpでは、TDDに限らず良いと思ったものは積極的に取り入れていっています。

また、輪読会などで得た知識を積極的に活かしていくこともしています。

学んだことを活かすことに肯定的、かつ、積極的な良いチームだと感じています。

引き続きインプットとアウトプットを繰り返して、より良いサービスを目指していきたいと思います。

2024-09-04

IntersectionObserver APIを使った速度改善について

こんにちは、Cake.jp技術部の福井です。

はじめに

ウェブページの速度改善を行う中で、IntersectionObserver APIを利用しました。この記事では、どのようにこのAPIを活用してパフォーマンスを改善したかについて詳しく解説します。

改善前の状態と背景

前提

Cake.jpの商品ページは縦長のスクロールが必要なサイトです。デザインを変更することによる、DOMサイズの縮小を行わない方針です。

速度の問題点

商品ページを表示する速度に当初はFCP（First Contentful Paint）が8.8秒かかっており、ユーザー体験に悪影響を与えていました。特に、ページの初期描画時に大きいサイズのDOMを一度に読み込むことで、表示が遅れてしまいました。

FCPとは？ページのコンテンツが最初に描画されるまでの時間を測る指標です。

▼詳しくはこちら: FCPの説明

web.dev

技術スタック

使用技術: JavaScript
パフォーマンス問題の具体例: 初期ロード時に要素が表示されるまでに時間がかかる、ボタンを押しても反応しない

改善のアプローチ

私はFCPのスコアが悪い理由として、DOMサイズが大きすぎることに着目しました。DOMサイズ削減のため、ファーストビューに関係ないDOMを非同期で読み込む方法を検討しました。非同期で読み込む方法として、ある特定の地点に到達したらイベントが発火するIntersection Observer APIを採用し、ユーザの動作によってファーストビューに関係ないDOMを取得するかどうかを決定することとしました。

IntersectionObserver APIとは

概要

IntersectionObserver APIは、要素がビューポートや祖先要素と交差する状態を非同期で監視するためのインターフェイスです。これにより、ユーザーが要素に到達するタイミングを検知し、適切なアクションを実行できます。

▼詳しい説明はこちら: MDN Web Docs - IntersectionObserver developer.mozilla.org

IntersectionObserver APIを導入できるかどうかの3つのステップ

ファーストビュー外に多くの要素があることを確認する
- 理由: ファーストビューにある要素をIntersectionObserver APIで遅延読み込みしても、恩恵をあまり受けることができないため。ファーストビュー外の要素による効果がより大きい。
ファーストビュー外の要素を非表示にしたときに表示速度を向上できることを確認する
- 理由: DOMを描画しないことで初期描画にかかる時間を軽減できるかどうかを検証するため。非表示の要素が後からロードされることで、ページの初期表示が迅速になることを確認。
全てのブラウザに対応しているオプションが利用可能であることを確認する
- 理由: 一部のブラウザで対応していない場合、表示したい要素が正しく表示されない可能性があるため。全ブラウザ対応のオプションが利用可能であれば、互換性の問題を回避し、全ユーザーに一貫した体験を提供できる。

「IntersectionObserver API」を用いて改善することができると分かったら、次にどのように改善していくかを以下の3つのステップに整理しました。

どこまで情報を非同期で表示するのかを決める
1で決めた箇所で、ソースを分割し、コンポーネントを別のエンドポイントで呼び出せるようにする
ユーザーのスクロール位置に応じて、必要なコンポーネントを遅延ロードする

今回は、3番目の「IntersectionObserver API」を使用したアプローチについて詳しく見ていきます。

IntersectionObserverの適用とその効果

基本的なコード例

以下は、IntersectionObserver APIの基本的な使い方の例です。

    // IntersectionObserverのインスタンスを作成
    const observer = new IntersectionObserver((entries) => {
        entries.forEach(entry => {
            if (entry.isIntersecting) {
                // 要素がビューポートに入った時の処理
                entry.target.classList.add('visible');
            }
        });
    });
    // 監視する要素を指定
    const elements = document.querySelectorAll('.lazy-load');
    elements.forEach(element => {
        observer.observe(element);
    });

設定のカスタマイズ

root: 監視するビューポートの要素（省略するとデフォルトでビューポート全体）
rootMargin: 監視する領域のマージン
threshold: 要素が交差する割合（0から1の値）

具体的な実装方法

ユーザーが特定のスクロール位置に到達したときに、必要なコンポーネントを遅延ロードすることで、初期描画の速度を改善しました。これにより、ページの表示速度が当初の8.8秒から3.8秒に短縮されました。

測定方法

計測には、PageSpeed Insightsの「低速4G」設定を使用。以下のツールで測定を行いました。

ツール: Pagespeed Insights、Lighthouse
改善前と改善後の比較: FCPの指標を使用

PageSpeed Insightsとは？ モバイル端末やパソコン向けのページの実際のパフォーマンスに関するレポートと、そうしたページの改善方法を確認できます。

▼詳しくはこちら:PageSpeed Insightsの説明 developers.google.com

注意点と考慮事項

パフォーマンスのトレードオフ: Intersection Observerを使うことで、初期ロード時に一部のリソースの遅延が発生する可能性があるため、適切に調整する必要があります。
ブラウザサポート: Intersection Observer APIのサポート状況について確認することを推奨します。一部のオプションではSafariやFirefoxなどのブラウザでのサポートが限られています。

まとめ

IntersectionObserver APIを活用することで、ページのパフォーマンスを大幅に改善することができました。今後は、さらに異なるシナリオでの応用や、他のパフォーマンス改善手法との組み合わせを検討していきたいと考えています。

2024-07-29

Cake.jpのバージョンアップについて語った、PHPカンファレンス福岡2024

Cake.jpでバックエンドエンジニアをしている山内です。

2024/06/22(土)、PHPカンファレンス福岡2024に参加してきました。

弊社からは代表の高橋、私の2名で参加しました。

今回は、登壇もしてきたので、当日の発表内容や参加してみての感想を紹介します。

登壇

Cake.jpのバージョンアップの歴史を語ってきました。

https://fortee.jp/phpcon-fukuoka-2024/proposal/83f31e89-1286-4d6a-b015-c46382a6b14e

オンラインでの登壇は経験がありましたが、カンファレンス登壇は初めてでした。

緊張のせいで客席の方を見る余裕は一切なく、ひたすら手元のPC（カンペ）と映し出されるスクリーンを見ていました（笑）

発表内容

こちらが登壇した際の資料です。

https://speakerdeck.com/kechiiin/ban-nian-kaketephp5-dot-6karaphp7-dot-4madebaziyonatupusitaku-lao-togong-fu-phpkanhuarensufu-gang-2024

登壇内容を一部紹介すると、

テスト環境がコンテナ化されていなかったので、それをやった話や（P.9）

バージョンを0.1ずつ進めていった話や（P.18）

バージョンアップの際に対応したものの話や（P.46）

動作確認で工夫した話など（P.67）

こういった話をしてきました

参加の感想

登壇の感想

前述したように非常に緊張をしていました。

発表自体は概ね練習通り進めることができたのでよかったです。

多くの方の前で話す機会はそう多くはないので、良い経験になりました。

聞いてくださった方々から、感想（フィードバック）もいただけたので一部ご紹介させていただきます。

バージョンアップって本当に大変なことなんだなぁ…と思いました。色々な工夫を伺えてよかったです。ありがとうございました。

バージョンアップ大変ですがビックバンリリースをしないように進めててすごいと感じました。

バージョンアップ前後の画面htmlの比較も良いですね。

面白い発表でした

フィードバックはありがたい限りです。

機会があれば、またカンファレンスでの登壇をしたいと感じたので、今後もカンファレンスにはプロポーザルを出して行こうと思っています。

全体の感想

トークは、その他コンテンツも盛りだくさんだったため、半分くらいしか聞けませんでした汗

トーク以外の時間は主に、スポンサーブース巡りや、カンファレンスで知り合った方との交流、Ask the Speaker（トーク後の質疑応答）などに参加させていただきました。

トークを聞いて学べるというのも良い点ですが、懇親会や（非公式ですが）前夜祭などに参加して、他社のエンジニアと関われるというのもカンファレンスの醍醐味だと思っています。

今回はPR TIMESさん主催の「PHPカンファレンス福岡2024・前日Meetup」、Fusicさん主催の「PHP Conference Fukuoka After Hack!!」にも参加して、交流を楽しんできました。

トータルで非常に有意義なカンファレンスだったと感じました。

最後に

PHPカンファレンス福岡2024スタッフの皆さん、ありがとうございました。

初参加でしたが非常に楽しかったです。

Cake.jpの話

今回は個人的に参加したカンファレンスでしたが、Cake.jpでは過去、PHPerKaigi2022, PHPerKaigi2023, PHPerKaigi2024にエンジニア一同参加しています。後日、感想を言い合う会をしたりもして、学びの共有やモチベーションアップを行っています。

また、Cake.jpでは定期的にLT会をしていますので、ご参加お待ちしております！

https://cakejp.connpass.com/

2024-07-26

「コンテキストの共通化」を加速させるために1年以上モブプロを続けた結果

こんにちは、Cake.jp技術部の中村です。

Cake.jp技術部では、週に2回モブプログラミング(以下、モブプロ)を実施しています。導入してから1年以上経過して、導入してよかったこと、課題について紹介させていただきます。

1. モブプロとは

Cake.jpでは、1つの画面を3人以上のエンジニアで共有し、コーディングを行うことをモブプロとしています。一般的なモブプロと異なり、コーディングを進めていく「ドライバー」とそれを見守り、意見をいう「メンバー」に分かれて行っています。(一般的なモブプログラミングでは、「ナビゲーター」の指示の元「ドライバー」がコーディングを行っていくと思いますが、Cake.jpでは「ナビゲーター」不在で行っています。)

全エンジニアがフルリモートで業務を行っているので、Slackのハドルミーティングを使って画面を共有しています。(ハドルミーティングの画面の拡大/縮小機能、画面共有への手書き機能を駆使して行っています。)

参加者は固定せず、グループ表を作り毎回同じ組み合わせにならないように実施しています。その週に各自が割り当てられたタスクや、設計の議論、プランニングにのらなかった軽微な不具合を修正する場だったりと、そのときどきによって内容を変えながら行っています。

2. Cake.jpでなぜ取り入れたのか

Cake.jpでは大半のメンバーがフルリモートで活動しています。モブプログラミングをとりいれるにあたり、当時抱えていた3つの課題の解決を目標として導入しました。

(1) 技術的な内容を相談する場が不足

開始当初は同期のコミュニケーションが朝会しかなく、朝会が終わると非同期でそれぞれが作業するというスタンスを取っていました。朝会にはエンジニア以外のメンバーも参加していたことや、そもそもの開催時間が短いことから、コードについての相談の場がGitHubのPRでのやり取りでしか生まれ辛い状況でした。

(2) 技術の共有

チームにはCake.jpの在籍年数やエンジニアになってからの年数がまちまちのメンバーがいます。コードレビューの場では納期の観点から細かい部分についての指摘がついつい後回しになってしまったり、指摘をもらってもコードに反映ができないということがよくあり、FBサイクルがうまく働かないときがありました。

(3) プロダクトの仕様の共有

当時のチームは、3人のチームで大きめのプロジェクトが2本走っており、どちらかのプロジェクトを専任している状況でした。そういう状況下において、プロジェクトをまたいだレビューが頻繁に行われていました。そのため、以下2点の課題を感じていました。

・PRでコードはわかるけど、仕様→コードの関連性がわかりづらい。

・ドキュメントに残っていないことがある。

Cake.jpでは開発メンバーの役割として、運用業務も含まれています。障害発生時やお問い合わせへの対応をスムーズにできるようにするため、システム全体やプロジェクトの仕様を把握しておくことが重要でした。

1人1回ドライバーを担当できるように週3回からスタートさせていきました。もともとモブプロとは別でコードリーディング会というものを行っており、プロダクトコードを1つの画面で複数人で同時に読むという文化があったため、スムーズに導入することができたと感じています。

モブプロを通して、IDEの使い方の習熟度が上がったり、プロジェクトで導入した新しい技術(React)についてエンジニアの知見が広がったり、設計思想の共有(DDDを意識した設計に取り組んでいる)ができたりしていることを実感しました。

組織変更に伴いチームが合併した際に、モブプロはチームの取り組みからエンジニア全体の取り組みとして活用しています。

3. 現状出ている効果と課題

2であげた3点の課題は、一定達成されたと感じています。

(1) 朝会以外でもコミュニケーションを取ることができ、他エンジニアとの接触頻度が上がった。

(2) 技術面では、ツールの使い方を習熟したり、単体テストを書けるようになったりと効果がありました。週に一度行われているチームの振り返りでは、モブプロを行ったことにより、よりよいコーディングを行うことができた。などの意見も出ています。
自身が習得した新たな技術のよい実験場として利用されることがあり、ほかメンバーの学びにもつながりました。

(3) プロダクトの仕様共有では、仕様に精通しているメンバーと進めることでタスクの理解がより進んだ例がありました。(未然に不具合を防げているのがかなり大きいです。)

一方で会を続けていくうちにわかった課題として、

(1) 自分が持っているタスクの進行状況によって、モブプロへのタスクの持ち込みができず、ドライバーになれないエンジニアがいた。

(2) 持ち込むタスクによっては、ただ作業を見守るだけのモブプロが発生した。

これらの課題を解消するために、軽微な不具合修正タスクをストックして、持ち込みタスクがないメンバーでもドライバーができるように体制を整えました。

不具合修正のタスクはただ直すだけではなく、「生まれた背景」「原因」「修正方法」の議論を行っております。議論を通して、「コミュニケーション」・「技術の共有」・「仕様の共有」ができており、単なる不具合修正以上の効果が生まれていると感じています。

今後も継続して活動を続け、エンジニア全員で学習を続けていきたいと思っています。