この度、来栖川電算のバータイムとして「開発のルールについて考えてみた」と題した報告会が開催されました。本ブログでは、この報告会で議論された内容や、どんな知見が共有されたかについてご紹介します。
※本報告会で出された意見や考察は、登壇者が個人の考えやAIとの壁打ちなどを通じて検討したものであり、来栖川電算を代表した公式な意見や、全社的な決定事項ではありません。
イベントで何をしたか：ルールの存在意義と限界の考察
報告会は、日々経験する開発上の課題や、効率化についての悩みなどを背景に、開発をルール化することの可能性を探る目的で実施されました。
まず、会社全体で画一的な開発ルールを定めることの難しさが議論されました。来栖川電算の研究系プロジェクトや開発系プロジェクトなど、プロジェクトの特性によって採用すべき手法は異なります。
そこで一律にルールを定めてしまうと、特定のチームにとって非効率となったり、ルールが守られなくなったりする可能性があります。
そのため、全社的な「ルール」ではなく、各チームが取捨選択できる「ガイドライン」や「おすすめ手法」を提示することが望ましいという結論に至りました。
「もし手法で迷うことがあったら、ここで話したルールを参考にしてみてね」という考え方です。
持ち帰られた知見 1：ルール作成における「理由」の重要性
ルールを定めることの最大のメリットは、メンバーが毎回その行動の理由や意図を考える必要がなくなり、認知負荷を下げて効率的に動ける点にあります。
しかし、報告会では、ルールを定めた理由や意図が忘れ去られ、ルールだけが残ってしまうという危険性が強調されました。理由が失われると、そのルールが現状に合わなくなった際に、アップデートしたり、撤廃したりすることができなくなり、結果としてルールが形骸化したり、場合によっては開発を妨げる「害悪なルール」になってしまう可能性があります。
したがって、チームやプロジェクト内で新しいルールを定める際には、必ず「なぜそのルールが必要なのか」という理由や意図までを明記しておくことが、将来的な柔軟な対応を可能にするために極めて重要な知見として共有されました。
開発現場の課題と具体的なアプローチ
報告会では、プルリク（PR）、レビュー、テストという主要な開発工程における具体的な問題点と、その解決に向けた考察が共有されました。
持ち帰られた知見 2：プルリク（PR）に関する課題と柔軟な対応
- プルリクの分割基準の難しさ： プルリクを「機能ごと」にまとめるか、それとも「サブ機能／担当者ごと」に細かく分けるかについて、チーム事情に応じた柔軟な判断が求められます。大規模な機能の場合、細かく分割することでコードサイズが小さくなり、レビューが容易になりますが、この場合、設計ドキュメントやインターフェース、スキーマの定義が事前に整っていることが、全体の整合性を保つための前提となります。
- 依存関係の解決： サーバーとクライアントの実装など、作業に依存関係が生じる場合、設計せずに個人の裁量で実装を進めると協調作業は困難になります,。このような結合部分の実装においては、サーバーとクライアント両方の都合を考慮してAPIインターフェースなどの設計を先行させることで、各担当者が並行して作業を開始できるようになります。
持ち帰られた知見 3：レビュー効率化とAIの役割
- レビューのスケジュール予測の困難性： レビューは、予測不可能な指摘の量や、実装者とレビューア間のコミュニケーションによるスイッチングコストが発生するため、実装に比べてスケジュールを読み込むのが難しい工程です。
- レビュー観点の整理と優先化： レビューの観点は、1. テスト通過（CIのレベル）、2. 設計通りのインターフェース/スキーマ、3. 機能の実現、4. 非機能要件（性能、保守性など）、5. バグの有無、の順に重要度を整理できるという提案がありました。
- 開発でよくあるのが「レビューが遅れがち」という問題です。その対策として、特に重要な観点（2と3：結合と機能実現）までをまず優先的に確認し、マージを許可することで、実装者は次のタスクへ進めるというアプローチが提案されました。性能や保守性（観点4）に関する修正は、優先順位の高いものが終わった後に実施すればよいという考え方です。
- AI時代におけるレビューの未来： 今後、AIが大量のコードを生成するようになると、人間のレビュー負荷が増大することが予想されます。将来的には、設計ドキュメントやインターフェース定義をAIに提供することで、AIが観点2や3の一部を自動でレビューし、人間の負荷を軽減する方向性が考えられます。人間は、アルゴリズムの選択、データ構造、そして全体的な設計の整合性といった、抽象度の高い、AIが苦手とする部分の確認に注力すべきだという見解が示されました。
持ち帰られた知見 4：テスト環境の整備とV字モデルの再認識
- テスト再現性の確保： 「自分の環境では通った」という状態では不十分であり、DevContainer（仮想環境）やクラウドサービスを利用する案件でのIaC (Infrastructure as Code)などを活用し、誰でも簡単にテスト環境を構築し、テストを再現できることが開発の前提となります。
- 要件と設計のテスト： アジャイル開発を採用している場合でも、V字モデルで示されるテストの対応関係は意識し続ける必要があります,。すなわち、要件定義を担保するためにはシステムテストが、基本設計を担保するためには結合テストが、それぞれ不可欠であるという点です。
まとめ
「開発のルール」はトップダウンで強制するものではなく、プロジェクトの性質やチームの現状に応じて柔軟に採択・調整されるべき「ガイドライン」であるという知見が強調されました。
最も重要なのは、ルールを設定する際には、その「理由」を明文化することで、ルールの陳腐化や形骸化を防ぐ仕組みを持つことです。また、AI活用が進む未来に向けて、設計ドキュメントの整備を進め、人間はより高度な抽象的な判断（全体整合性や非機能要件）に集中できるような開発体制を整えることが、今後の開発効率向上の鍵となるでしょう。