みなさん、デグレしてますか？
こんにちは、jof-fumiです！
この記事は、よりそうアドベントカレンダー 17日目の記事としてお届けします。
突然ですが、皆さんのチームでは「デグレ」が発生していますか？
私の所属する新基盤開発チームでも、ここ半年ほどデグレが増加傾向にあり、チーム全体で対策を講じています。
そんな中、あるミーティングで「自分はデグレが少ない方だと思っています」と発言してしまい、チームメンバーから「どういう思考プロセスでそうなるのか言語化してみて」と提案されました。
個人的には結構自信がある方で、前職だと自分が担当した修正の障害発生率の低さをアピールポイントしていたこともありました。
（障害を起こすことが少ないことで耐性がないため、自分の見落として障害が起きた時涙目になったこともありました。若いですね。）
この記事では、自分の普段の開発やコードレビュー時の考え方を整理し、どのようにデグレを防いでいるかを紹介します。
スタンス
私は常に次のような姿勢で作業に臨んでいます。
「自分の想像は大抵間違っているし、情報は常に不足している」
どれだけ調べても、どれだけ情報収集しても、実際に確認しない限り「確実な情報」とは言い切れないと考えています。
資料や設計書はあくまでガイドラインにすぎず、確証のないままで考えることは「想像（というより妄想）」の域を出ず、事実にはなり得ません。
情報を収集し切って、その上でコードを直接見て確証を得るまでは、仕様や動作を完全には把握できないという前提で動いています。
このようなマインドセットを基に、曖昧な「多分大丈夫」「おそらくそうだと思う」といった判断を排除し、手戻りや見落としを最小限に抑えることを心がけています。
かつて上司に言われた言葉が、今でも心に残っています。
「お前は地図みて納得するんか？現地行ったら工事中かもしれんだろ」
開発時に気をつけていること
1. 修正対象周辺の不明箇所をゼロにする
チケットだけ読んで作業を進めるのではなく、周辺機能や関連コードも調査します。
これにより、認識外の影響や見落としを防ぎます。
当たり前じゃね？と思うかもしれませんが、設計にてコンポーネントが責務でキレイに分離できている場合、チケットの記載内容だけ読めば、全体像を理解していなくとも作業自体は可能なケースもあります。
ただ、自分はそれをしないですと言う話です。業務や画面のオペレーションなど、インプットからアウトプットまでのワンセットを区切りとして、そこまでを理解し切ります。
具体例：
- フレームワークの機能で自動化されている箇所などは機能を調べて理解してから修正する
- Laravelのキューなど、フレームワークの外側で自動化された処理がどこで動いているかを確認する
- オンプレとクラウドで挙動が異なる場合は特に注意が必要です 必ずどこで何をしているからキューを実装してOKというところまで確認してから実装する
なお、「そんな余裕持って調査に臨む時間はないんだが」というケースでは、問題点が他にあるので、そちらの解消をオススメします。
2. 論理的に影響なしと言えない場合は、GREP調査を行う
他の機能に影響がある可能性が少しでもあれば、必ずコード全体をGREPして確認します。
たとえ確度の高い情報であっても、最終的な確証を得るまでは手を抜きません。
手順の例：
- 修正対象のロジックを確認
- GREPで該当箇所を調査し、関係箇所をリストアップ
- 必要に応じて周辺のコードを再確認
修正方針をもとに、以下のように論理的に説明できない場合は必ずGREP調査を行います。
「〇〇という理由より、この領域以外に影響が出ることは100％ありえない」
「〇〇というケースは、この場合発生することはないので、この領域は100％影響ない」
この判断軸を基にコードに向き合うと、必然的にロジックを理解するステップを挟むことになります。これにより取りこぼしが減り、「修正対象周辺の不明箇所がない状態で臨む」にも良い影響を与えます。
最近では、AIにコードを食わせて「説明したまえ」と投げかけると、意外としっかり説明してくれるので助かっています。AIもまだ人間に有効的で良かったですね。
ちなみに私は、「100％問題ない」と判断した後でも、一応GREP調査を行います。いくつかのサンプルを確認し、「やはり問題ない」という確証を得るステップも欠かしません。
慎重派といえば聞こえはいいですが、実際には自分を信用していないだけかもしれませんね…。
3. 影響がないと自明でも、出来る限り動作確認を実施する
特に説明するまでもありませんが、実装とテストはセットです。
ただし、私もできる限り楽はします。
例えば、チームメンバーが導入してくれた「VRT（Visual Regression Testing）」を利用して打鍵を省略したり、自動テストを活用してコンポーネントの特定のデータパターンでの検証を自動化しています。
それでも「不足しているかも」と感じた場合は、ロジックごとにケースを準備して手動確認を行います。
結局のところ、目視でリグレッションも含めた確認を行うことは欠かしません。効率化しつつも、必要最低限の確認は怠らないようにしています。
4. 修正箇所が複数ファイルから呼び出されている場合、開発作業を分割して小さい単位でPR出す
これは非常に重要な観点です。
そもそも設計が綺麗に責務で分離されていない場合、PRを分割して提出すること自体が難しいと思います。
こうした対応が困難な場合は、まず設計の見直しを検討すべきです。結合度が高い設計では、小さな機能修正であっても複数のファイルを修正せざるを得なくなり、結果的に以下の問題を引き起こします。
- 影響範囲の拡大: 予期しない箇所への影響が増加
- 作業時間の増加: 修正箇所の把握や確認に時間がかかる
- デグレの頻度増加: 修正範囲が広がることで、見落としやミスが発生しやすくなる
幸い、よりそうでは、テックリードをはじめとする開発チームメンバーが「機能を責務で分割する」意識をしっかり持っています。
そのおかげで、単独でPRを出しやすい環境が整っており、結果的にデグレのリスクを減らせていると感じています。
その他必要なこと
ここまでしっかり調査していると、「時間がかかりすぎでは？」と思われるかもしれませんが、
私は作業時間が長いと指摘されたことは一度もありません。
このポイントを解消するためには、いくつかのテクニックと知識の習得が必要です。
最初の数ヶ月で時間を潤沢に使う
チームに参画して最初のうちは、「まだ慣れていない」という理由で、ある程度時間をかけても許容されるケースが多いと思います。
この期間を活かして、システム構成が理解できるまで調査や質問を積極的に行いましょう。
また、この時期には 報連相（報告・連絡・相談）を細かめに行い、数値ベースで的確に状況を共有することを心がけます。
「時間は使っているが、やるべきことをしっかりやっている」と認識してもらえるので、最初のうちは丁寧に対応するのがおすすめです。
ただし、丁寧な報告を行うには、エンジニアリングスキルだけでなく、ビジネススキルの研鑽も必要です。
この点については、技術研鑽だけしていると抜けてしまうので、意識的に学習すると良いです。
設計に関係する勉強を進めておく
最新技術や目新しいトレンドを追いかけることも重要ですが、設計に関する勉強を進めておくと非常に役立ちます。
システムの構成を理解するための基盤が身につき、結果として調査スピードが大幅に向上します。
AIを活用する
最近では、AIを活用してさらにスピード感を上げています。
例えば、コードの解説やロジックの確認などをAIに任せることで、より効率的に作業を進めることが可能です。
まとめ
デグレを防ぐためには、
- 自分の考えを疑うマインドセット
- 影響範囲を徹底的に調べる調査力
- 可能な限り網羅的に動作確認を行う姿勢
これらが重要だと考えています。
それらをベースに、
- ツールや仕組みで楽する
-
開発を小さくしてレビューしやすくする
- それができるシンプルな設計を目指す
ということを日々考えて仕事に取り組み、
- システム構成を理解する勉強
- 時間を確保するためのビジネススキル習得
ということを意識的にインプットしておけばいいと思います。
私が実践している方法が、読者の皆さんの開発プロセス改善の参考になれば幸いです。
ぜひ皆さんも「デグレしない開発」を目指してみてください！
続き「レビュー編」は次回の記事でお届けします。お楽しみに！