NOT A HOTEL Androidエンジニアが始めるGo開発 〜みんなの開発環境をぶっ壊すまで〜

この記事は、NOT A HOTELのソフトウェア開発連載「Inside the SOFTWARE TEAM」の企画で書いています。

はじめに

こんにちは、NOT A HOTELでAndroidエンジニアをしています池永です。
普段はNOT A HOTELアプリのAndroidクライアントを担当しています。先月はAndroidクライアントの実装と並行してバックエンドにも取り組み、学びながら実装まで行いました。

前半では技術領域を越えて働く意義と事例を、後半では開発中に発生したインシデントを題材に、ぼくらの対応姿勢と仕組みを紹介します。

NOT A HOTELアプリエンジニアの技術領域を超えた開発

NOT A HOTELには複数のソフトウェアプロダクトがあります。ぼくは“オーナーアプリ”のAndroid開発を担当しており、本稿では同一プロダクト内での領域越境に絞って述べます。もちろんソフトウェアプロダクトの領域を超えた事例もありますが、本稿の話題の対象外となります。

技術領域を超えた開発はこれまでも試行してきました。

• ある機能のiOSとAndroidを1人で担当する

• ある機能のバックエンドとWebフロントを1人で担当する

また、PdM（プロダクトマネージャー）が技術領域に踏み込む取り組みもあります。

技術領域を超えて働くメリット

このような技術領域を超えた開発にはいくつかの明確なメリットがあります。

◾️ドメイン知識やプロダクトへの理解
自分の担当する画面や機能がどう結びついているかを知ることができます。その結果、UI/UX、フロントエンド、バックエンドそれぞれに集中して設計していると見えてこない問題点や改善点がより早期に検知できることがあります。

◾️チーム全体の柔軟性
フロントエンドエンジニアがバックエンドに理解を持ち、バックエンドエンジニアがフロントエンドの制約を理解する──このように互いの知識が重なり合うと、チームのボトルネックが減り、変化の多いプロダクト開発でも安定したスプリントを維持できます。また開発の柔軟性だけでなく、工数の柔軟性や問い合わせ対応担当の柔軟性にもつながります。

◾️キャリアの幅
人にもよると思いますが、個人のキャリアの幅が広がるというメリットもあります。

今回のぼくの目的は2つありました。1つ目は、NOT A HOTELのバックエンドのドメイン知識を身につけ、今後の設計や運用に活かすことです。フロントの視点から必要なAPIを自身で設計したり、知識を身につけることで幅広く対応を行いたいと考えました。2つ目は、開発チームとしてより柔軟に動ける体制をつくることでした。フロントだけでなくバックエンドの領域にも関わることで、より一貫した体験づくりに貢献できると考えました。

デメリットとして、学習コストやスイッチングコストは発生しますが、AIの活用で低減できます。

領域を超えてもらうための支援

現状で一番有効だと感じたのは、AIを利用した開発環境を整えることです。慣れない言語ではAIに支援してもらうコーディングが有効です。今回の実装は9割以上をAI支援で進めました。普段の開発向けに環境を整えるだけでも十分効果があります。初期はPRレビューのコストが上がるので、AIレビューの設定を入れておくと、レビュアーとレビューイー双方の負担が軽くなります。

当然ですが、ドキュメント整備は必須です。開発環境の立ち上げは、最低限の情報が書かれていればトラブルシューティングの多くをAIが支援できます。全体の設計方針などのドキュメントは、理解を助けるだけでなく、AIによるコーディング精度の向上にも寄与します。さらに、その領域に不慣れな人でもとっつきやすいドキュメントがあると良いです。

また、細かな設計方針や運用方針の疑問を解消するための相談の場があると、学習が加速します。NOT A HOTELでは、フルリモート下のコミュニケーション活性化の一環として、ほぼ毎日夕方にSlackハドルで雑談会を行ってお
り、その場を活用しました。

AndroidエンジニアによるGo開発

ここでは具体的にどのように進めたかを紹介します。

事前学習については、「初めてのGo言語」と「Go言語プログラミングエッセンス」を読了済みだったため、いきなりGoのコードベースを読んでもそこまで理解に困ることはなく、基本はAIにコードを書いてもらい、目視でおかしさに気づいたり、疑問点を調べたりする運用で十分でした。特に「Go言語プログラミングエッセンス」は net/http、テンプレート、テーブル駆動テスト、ベンチマークなど実践的な内容が紹介されており、既存コードの理解に役立ちました。

IDEはJetBrains製のGoLandを使い、実装はClaude Codeを用いた対話型のコーディングで進めました。Android開発と体験をほぼ変えずに実装できました。AIの応答待ち時間が長いため、AndroidとGoを文字通り並行して実装する形が相性よかったです。

初めての開発環境やプロジェクトでは、「この書き方でいいのか」という疑問がたびたび起きます。今回の実装でも、例えばデータベースクエリで値が見つからない場合に NotFound エラーを返すのか、nil を返すのか、ゼロ値を返すのか。また、プリミティブな型と、型リテラルで扱いを分けるべきか。低コストなクエリの組み合わせはgoroutineで並列化すべきか。こうした点を都度「Goの一般的な慣習」「プロジェクト内の方針」「プロジェクト内の参考実装」をAIに調べてもらい、迷いを減らして実装できました。

インシデントの発生

バックエンドエンジニアの協力もあり、学習も設計も順調に進んでいました。ただ、こういう“順調に見えている”時こそ注意が必要で、そのタイミングで開発環境のデータベースを誤って削除してしまいました。これはあくまで開発環境での事故であり、ストアで公開している製品版アプリには一切影響はありませんでした。一方で開発者には、作業中のデータが急に削除されたことで一時的に作業の手を止めてしまうことになりました。

直接の原因は、クラウドデータベースに予期しないインデックスが存在していることに気づき、AIに調査を依頼したところ、その過程でAIがクラウドデータベースをリセットするコマンドを実行してしまったことでした。

もちろん今回のインシデントの影響は開発環境だけの問題であり、本番環境では、誤操作でデータが消えることが起きないように、より厳格なアクセス権限の管理を行っています。開発者の操作が本番データに直接影響しない仕組みにしているため、安心して作業を行える環境になっています。

NOT A HOTELにおけるインシデントの取り扱い

NOT A HOTELでは、全社、全部門共通でインシデントが発生した際にSlackチャンネルでの共有とレポート作成を義務付けています。部門ごとの指標で重大度を判定し、重大度に応じたフローで対応を進めます。

対応方針として、個人の責任追及や非難はしません。問題を起こした当人が謝罪することも非推奨となっています。報告しやすい雰囲気を作り、挑戦と情報共有を萎縮させないためです。再発防止策は仕組みで考え、具体的なアクションに落とし込むことで、類似インシデントの発生を防ぎます。

今回のインシデント対応

今回は「なぜ問題が起こったか」「一次対応はうまくいったか」「恒久対応はうまくいったか」の3つの視点から洗い出し、なぜなぜ分析で真因を探りました。各問題に対して対応案を出し、コストパフォーマンスの高いものを再発防止策として定めました。

例として「なぜ問題が起こったか」に対して「予期しないインデックスが何のためにあるのかの調査タスクで共有データへの破壊的変更を予測できていなかった」という原因があります。さらにこれは「AIの調査プランが長く内容を正しく把握できないままAIに実行させていた」という原因があります。このケースではAIに実行するコマンドを禁止するリストを設定したり、コマンドの実行をフックして動作を変更させる、などの対応が有効でしょう。

別の例として「一次対応はうまくいったか」に対して「バックアップからの復元ができなかった」という問題がありました。これは、開発環境のバックアップ保持期間を短めに設定していたことが影響しています。この設定は、本番環境とは用途が異なる開発環境において、運用負荷とのバランスを考慮したものです。

一方で、本番環境では十分な期間と頻度でバックアップを取得しており、万が一の際にも確実に復旧できる体制を整えています。今回のインシデントを踏まえ、開発環境についても保持期間が適切だったかどうかを見直すきっかけとなりました。

まとめ

本稿では、領域越境の実践と、インシデント対応の姿勢を紹介しました。領域越境には学習と切替えのコストが伴いますが、チームと個人の双方に大きな利点があります。インシデント対応では、個人非難ではなく仕組みでの再発防止を徹底し、挑戦し続けられる環境を守っています。今回の学びを踏まえ、これからも領域を超えてチャレンジし、さらにメンバーのチャンレジにも積極的にサポートしていきたいです。

現在、NOT A HOTELのSoftwareチームでは採用強化中です。 カジュアル面談も受け付けておりますので、お気軽にご連絡ください。