JJUG CCC Spring 2025 : 技術的負債から守るSonarQube カスタムルール作成入門

アーキテクトが、自ら考えたアーキテクチャを開発者に守らせるためには、プログラムをレビューする必要があります。ただ、多くの開発者に対してガバナンスを効かせることは難しいですよね。レビューを肩代わりしてくれるソース解析ツールやSASTの中に自らの「想い」を体現したルールが必ずあるとも限りません。
このセッションでは、SonarQubeを例に自らの作ったカスタムルールを実装してみましたので、ご紹介させていただきます。

Transcript

1. おはようございます。株式会社日本総合研究所の松田です。 本日は数あるセッションの中から、こちらのセッションにご参加いただきありがとうございます。 20分と短い時間ですが、よろしくお願い致します。
2. 簡単に自己紹介になります。 私は、2004年に株式会社日本総合研究所に新卒で入社して、 最初はJavaフレームワーク開発・Oracle DBAを担当していました。 一時期、三井住友フィナンシャルグループに出向し LLMが出てくる前の機械学習・ディープランニング時代のAIの導入推進を担当していました。 現在は、出向から戻りまして、技術統括部 エンジニアリングセンターという組織で 当社における内製化推進を担当しています。
3. ということで本題に入らせていただきます。 突然ですが皆さん。。 ・Javaでコーディングしていますか？ 　もちろん、このJJUGの場でお伺いするのは愚問かと思います。 　Developerの皆さんは勿論コーディングしていますよね。 ・といいながらも、一方で、アーキテクトの皆さんはいかがでしょう？ 　あるいはプロジェクトマネージャーやプロダクトマネージャーの皆さん、 　更には次長・課長・部長の管理職の皆さんはいかがでしょう？ ・本日の話は、アーキテクトも管理職もコーディングをしたい 　という方にお薦めの話になります。
4. ・かの有名なオライリーから出ている書籍の「ソフトウェアアーキテクチャの基礎」ですが、 　この中で、アーキテクトは、アーキテクティングとコーディングのバランスを取る必要がある 　と記載されています。 　アーキテクトもプログラミングをし続けないと、アーキテクトとしてのスキルも 　劣化・陳腐化していくということかなと思っています。 ・ただ、一方で、本番システムの一部のコーディングを担当する、と 　アーキテクト自身がボトルネックになって 　プロダクト開発推進そのものに影響が出てしまうため、 　できればそれ以外のものが良いということで、この４つが挙げられていました ・PoCをやりましょうとか、コードレビューをしましょうとか、 　書かれていますが、本日は真ん中２つがこの講演には関係するかなと思っていまして、 　本日の講演のタイトルにもつけました「技術的負債」に関わる作業、 　あとは、アーキテクチャ分析や適応度関数ということで、 　アーキテクトの人がまさにやらなければいけない統制・ガバナンスですね、 　アーキテクト自らが決めたルールが確り守られているか？をどのように担保するのか、 　ここに本日のテーマであるSonarQubeが活用できるかなと思っています。
5. ・「技術的負債」とは、ということで、色々な定義があるかとは思いますが、 　本日も２つ持ってきました。 ・上の定義ですが、アーキテクトの教科書という昨年出版された本の言葉を引用させていただきますと、技術的負債とは、 　その場しのぎの解決策を取ったことによる将来の潜在的な改修コスト、 　と書かれていました。 ・あとは下段、こちらはかの有名なMartin Fowlerさんのブログに書かれているものですが 　内部品質というのがあって、既存の製品の中に不要コード、ゴミですね、 　その場しのぎの解決策をとると、ゴミが蓄積されてしまいます。 　すると、業務として使用されていないごみの部分にもかかわらず 　追加機能を開発するときにテストをしないといけなくなってしまうので ・そのため、内部品質を良くするには、 　常にごみをなくしていく努力というか必要になります。
6. ・ただ、、技術的負債はそう簡単にはなくならないです。 　アーキテクトは技術的負債を生まないように、アーキテクチャを設計し、 　手順化・標準化をしてドキュメントに落として開発エンジニアに渡すわけですが、 　その開発エンジニアが様々な理由により思い通りに受け取ってくれない場合があります。 ・もちろん外的要因もあります。 　ビジネスサイドが、どうしても早く開発したいとか、安く開発したいとか言ってくることもありますし、 　右側、開発エンジニアの感情的な課題、と書きましたが、 　例えば、チェックリストを確り読んで理解して対応してくれるのか、 　初心者だと用語が分からないかもしれないですし、オフショア先だと文化の違いや、 　プロジェクトの熱量が伝わらないことなどから、どこまでチェックリストに真摯に向き合ってくれるか 　分からないこともあります ・あとはペアプロ・モブプロも好みがある気がします。　 　ペアプロハラスメントなんていう言葉も出てきているかと思います。 　
7. ・ということで、最近は人間を介さずAIによるレビューも検討されています。 　釈迦に説法ですが、LLMが出てきて汎用AIもどんどん進化して、どんどん人間に近くなってきています。 ・汎用AIがいわゆる人間の補佐として動いてくれる時代になりました。 ・レビュー受けるとき、尊敬できない先輩よりも汎用AIの方が、前向きに、素直に 　意見聞けたりしません？　聞けるかもしれませんし、 　あとは期限が差し迫って、プロダクトを完成させなければいけない局面になって、慌ててレビュー受けるよりも、 　前々から言ってもらっておいた方が、気持ち的にも余裕をもって設計見直せますよね、 ・レビューされる方も嫌な雰囲気になったり逆ギレされなくて済む 　ということで、
8. ・ということで、シフトレフトはセキュリティ設計観点に限らず、やった方が良くて、 　かつ、ロボットやAIでなくても、ある程度自動でテストしてくれるツールがあると嬉しい、 　というわけでプログラム品質分析ツールや 　ここに並んでいる、いわゆるASTツールの出番、となります。
9. ・ということで本日はSonarQubeを使って、アーキテクト目線で技術的負債を防ぐカスタムルールを作っていきますが、 　その前に、SonarQubeについて簡単にご紹介させていただきます。 　 　SonarQubeは2006年頃、リリースされているツールです。 　当時はJava界隈では、FindBugsやCheckstyleというOSSもあって使われてましたが、 　SonarQubeとの違いとしては、SonarQubeは統合的なプラットフォームであり、 　自らもチェックルールを開発して組み込んでいますが、 　SonarQubeでは、他製品のチェックルールをプラグイン的に取り込めたり、 　結果をダッシュボードスタイルで可視化できる点が優れています。　 ・ルールも無償版でもかなりのルール数があり、Javaだと600以上あるかと思いますが、 　なかには、Spring限定のルールとか、JSPのルール等もあるので、提供されているルールを全て使えるわけではなく、 　開発するアーキテクチャに合わせて都度選択することになるかなと思います。　
10. ・となると、どのような時にカスタムルールを使うのか？ということになりますが、 　欲しいルールがないときにカスタムルールを使うことになるかと思います。 　アーキテクト目線で、守らせたいことができているか、チェックするときにカスタムルールが必要になります。 　例えば、独自のコーディングルールがある場合、 　あるいはレイヤードアーキテクチャ等でシステム全体を設計している中で、 　プログラム間の依存関係のルールが守られているかをチェックするため、 　また、特定の製品を使わせたくないから、パッケージのインポート文の中で 　選定外の製品が使われていないか、を自動的に確認することでチェックができます。 ・あと、フレームワークやミドルウェアの移植性を考えて、 　製品のSDKをそのまま使うのではなく、自プロジェクトで開発しているラッピングクラスを 　開発者に使わせたい、そのようなケースもあるかなと思います。
11. ・さて、ここからはカスタムルールの作り方について紹介してまいります。 　詳細は私が書いているQiitaの記事を読んでいただけると嬉しいのですが、 　本日、JJUGで講演するにあたり、再度、SonarQubeの2025について調査しましたが、 　Qiitaを書いた2年半前、この頃は8.9でしたが、この時から相当変わっています。 　本日、一部最新化出来ていない2年半前の情報をもとに説明している部分もありますので、 　その点は何卒ご容赦いただければと思います。 ・まずカスタムルールの全体構造、ということでクラス図がこちらになります。 ・左上のRulesPluginというPluginインタフェースを実装したクラスが、 　プラグイン全体を管理するクラスですが、 　RulesPluginクラスから、RulesDefinitionインターフェースを実装したクラスを呼び出しています。 　このプラグインに登録するカスタムチェックルールを定義しているクラスになります。 ・そして、各ルールクラスはJavaFileScannerというインターフェースを実装して作ります。 　このルールクラスをRulesDefinitionを実装したクラスで読み込むことになります。
12. ・ルールクラスの一部を抜き出しています。 　これはSQL Injectionをチェックするために、Statementインターフェースを継承していながら 　PreparedStatementインタフェースを継承していないクラスを抽出しています。 　シンプルな例にしたかったので、 　実用的な事例ではなく、あえてこのような事例を紹介させていただいています。 ・SonarQubeというか、Sonar Scanner、プログラムソースをスキャンするツールでは 　Javaのプログラムソースを頭から構文解析していく仕組みを持っています。 　その中で、VariableTreeというのがいわゆる変数のデータです。 　この変数のクラスをTypeTreeというもので取得してきて、 　ありがたいことにisSubtypeOfメソッドというのが用意されているので、 　子クラスかどうか、この場合はインターフェースですが、こちらをチェックすることができます。 ・そして、if文中がtrue、すなわちチェックしてルールに違反している場合、 　このルールクラスの親クラスである 　IssuableSubscriptionVisitorクラスのreportIssueというメソッドで問題を起票されます。　 ・またクラスに対して Ruleアノテーションを追加し、ルールIDのようなものを振っています。 　こちらのKeyが次に紹介する説明用のhtmlやjsonと対応しています。
13. ・そのhtmlのスライドになりますが、 　SonarQubeには結果をダッシュボードで出力する機能があるというお話をしましたが、 　ダッシュボードの中で検知した問題については、その説明をつけることができます。 　こちらHTMLである程度自由に記載できますが、いくつかルールがありまして、 　最初のpタグの１行は、
14. このWhat is the risk?のところに表示される内容になります。 　また、それ以降の説明はAssess the riskに書かれたり、
16. 　プログラムの修正方法については How can I fix it?のタブの中に書かれたりと、 　このhtmlを解析して、文章を分解して、SonarQubeの画面上、表示される仕様になっています。　 　h2タグのみは各項目のヘッダの役割があるため一部使えませんが、その他のタグはおおむね使えそうです。
17. ・ただし、この表示ですが最近変わっています。 　最新版と言っても2023年2月以降ですが、表示フォーマットが変わり、 　内部的にはEducationRuleLoaderというクラスの読み込み仕様になっています。 　右下の項目が分割キー項目になっていて、 　それぞれ表示されるようになります。
18. ・この説明文書ですが、1点注意があり、このHTMLを格納するフォルダですが、 　JavaRulesDefinitionクラスの中で、static finalの定数としてこのパスに直書きされていますので、ご認識ください。 　
19. ・また、HTMLで画面で表示する説明文書とともに、 　各ルールのデフォルトの属性を定義するjsonファイルも作成します。 ・タイトルもそうですが、今回はsecurity hotspotとしていますが、 　bugやVulnerabilities、Code Smellsといった種別や技術的負債解消にかかる修正時間、 　また、このルールではCriticalにしていますがデフォルトのレベル、あとはタグなど、これらを定義することができます。
20. ・次にルールの登録です。 　SonarQubeのサーバを立てて実行するときは、RulesDefinitionインタフェースを実装したクラスで登録します。 ・コーディングの方法ですが、まず、リポジトリというものを作ります。 　このリポジトリに先ほど作成したルールクラスをList型で束ねて指定して一気にロードできます。 　
21. ・そしてコンパイルして出来上がったjarを、SonarQubeの実行サーバに持って行って、 　extensionsのdownloadの下に格納して、SonarQubeを起動するだけで 　キャプチャの通り、カスタムプラグインがロードできます。 　pluginを初めて読み込む時は注意喚起するダイアルボックスが出てきますが、気にせず次に進むと 　このようにカスタムプラグインが読み込めるようになります。
22. ・そしてこちらが実行結果はなりますが、あえてPreparedStatementを使用していないJDBCのテストソースに対して 　エラーコメントが表示されているのが分かるかと思います。
23. ということで多少駆け足でしたが、纏めです。 本日は、主にアーキテクトの方に向けて、 自分が決めたルールをエンジニアに守らせたいときに使える SASTツールにおけるカスタムチェックルールの開発方法について紹介致しました。 詳細の部分、SonarQubeの起動とか、スキャンの実行のあたりはお見せできなかったので、 そちらは繰り返しの宣伝となり恐れ入りますが、 Qiitaをご参照いただけると助かります。
24. 以上で本セッションを終了させていただきます。 ご清聴いただきありがとうございました。