ベテランエンジニアが教える、ソフトウェア保守性を高める具体的な方法

2021年2月1日

はじめまして

セカンドセレクションのnomaです。

新入社員から「ソフトウェア保守性」について問われましたが、口頭で表現することが困難であると分かりました。

適切に表現出来れば新入社員にとっても私にとっても良いと考えましたので、私のエンジニア人生の具体的な経験を踏まえながら、「どうすれば保守性の高いソフトウェアを作れるのか」を、下図を基に検討してみたいと思います。

表 1 ISO/IEC9126-1で定義されているソフトウェア品質モデル

保守性とは

そもそも保守性とは「ソフトウェア品質特性項目の一つ」です。
前述の図では、修正のしやすさに関するソフトウェア製品の能力とあります。

高い保守性を備えるソフトウェアは、改版の際に低コスト・高品質な開発を実現することが可能になります。もちろんですが、不具合修正の際には修正コストを抑えることも出来ます。

よって、特に高品質な開発を目指すために、ソフトウェア技術者は成果物（設計書やソースコード）の保守性を高めることが重要になります。

リリースしてから1つも不具合がないソフトウェアというのは残念ながら存在しません。今後は現状よりもさらに「保守性」が重要な指標となることでしょう。

保守性が重要な理由

ソフトウェアは作成した時点で終わりではなく、運用後も適宜メンテナンスを実施する必要があります。大きく分けると以下の3つです。

不具合が発生し改修しなければならない場合

お客様に機能追加してほしいと依頼される場合

外部環境の変化（法改正や連携システム改修等）への対応が必要な場合

私たちが取引させていただいている大手の基幹システムでは、数年にわたりソフトウェアの改修を実施する事例もあります。

私が保守性が重要だと感じた瞬間

ところで、私の人生において「ソフトウェア保守性」が重要だと一番痛感した出来事があります。

ある制御システムでリソース管理機能をなんとかする、というお題がありました。

当時で２,３年目という若手の方が既存処理を作成していましたが、私が参画した頃にはどこかへ異動していたため、１人残ったそのシステムの有識者が頼りでした。

設計書や資料の類はもちろん無く、ひとまずソースを眺めましたが、お察しの通り、いやそれ以上の亜空間が広がっていました。これでもかという程の一本道の処理、関数と呼べる代物ではない関数、気まぐれで散乱する状態判定処理、修正したらなんか上手く出来たなぁな処理、等々。

結果的に私自身が２ヶ月程で他業務へ異動となりましたが、それまでには可能な範囲でリファクタリングを行い、各処理に意味を持たせるようにしました。

その期間は生きた心地がしませんでした。

やはり保守性、すなわち改造に強い構造は必要であると身に沁みました。件の若手の方は、この業界を続けているとなると10年近くなりますが、元気であることを願います。

ソフトウェア保守性が高いとは？

さて、ここで保守性が高いとはどのようなことかを知るために、反対に保守性が低いソフトウェアについて幾つか要素化してみます。

1.疎結合ではない	改修する場合の影響が広範囲に広がるソフトウェア構成
2.可読性が低い	他者が解読しにくいソースコード
3.トレーサビリティがない	仕様書や設計書と整合が取れない、ドキュメントがない
4.機能分担がない	処理の役割が分からない。統一性がない

これらを反転すると、以下のような4つの要素になります。

1.疎結合である	各処理が互いに影響する部分が少ないことにより、再テストも含めて改修コストを抑えることが出来る。
2.可読性が高い	他者が解読し易いソースコードであることにより、属人性が低くなる。
3.トレーサビリティがある	仕様書や設計書と整合が取れていることにより、仕様変更に関わる部分が判断し易い。
4.機能分担がある	処理の役割が明確であり、統一性があることにより改修ポイントや方針が判断し易い。

故に保守性が高いとは、機能の変更や追加が考慮されており、問題点の絞込みがしやすいことと表現出来るのではないでしょうか。

改めて、言語化することは困難であることが分かりましたが、高い保守性を意識することが重要であることも分かりました。

ソフトウェア開発におけるQCD

私たちは受託によるソフトウェア開発を主に任せて頂いておりますが、期間やコストを意識するとどうしても品質に影響が及ぶ場合があります。

その中でも低コスト・高品質な開発を実現するためには、保守性の高いソフトウェアを開発することが重要になります。

改版等で対象となるソフトウェアの保守性が低い場合、保守性を高めるためにリファクタリング（ソースコード改善）の検討も視野に入れる必要があり、影響調査や再テストに多くのコストを費やすことにもなります。保守性はソフトウェア開発におけるQCDと密接に関連している、と言うことが出来ます。

ソフトウェアの保守性を高めるためには「良い設計」と「美しい実装」が必要です。

非常に抽象的ですが、それらに集約されます。

ソフトウェア技術者としては宿命であり、厳しい道のりであり、目指すべき結果です。

具体的な保守性の高め方

では最後になりますが、日々私が意識している保守性の高め方を「設計段階」と「実装段階」に分けて幾つかポイントにしつつ、私自身への戒めとしても記載します。

設計編：設計の時に意識すること。

1.機能分担を明確にする	画面制御処理、演算処理、通信処理等のように枠割を単一化
2.インタフェースを明確にする	外部インタフェース、内部インタフェースを見分けて定義
3.仕様変更を前提とする	「種別を追加」等を意識して、修正が容易な設計
4.読みやすい文章	要点が伝わらない記載、都度ヒアリングが必要な記載は避ける
5.見やすい体裁	無理にドキュメント1つにまとめず別紙等で分ければ、長文も防ぐことが出来て、各ポイントが見やすくなることにより修正もし易くなる

実装編：実装の時に意識すること。※コーディング規約に則るのは前提。

1.設計書に追随する	「元ネタは設計書」は理解していても的外れな結果になることもある
2.仕様変更を前提とする	「種別を追加」等を意識して、修正が容易な処理構造や記載方法にする
3.第三者とのコミュニケーションツールを目指す	当人以外が見ても伝わるように、適度なコメント付与や処理構造等を心掛ける
4.英名は直訳を避ける	日本語から直訳すると意味が通じない場合があるため、よく使われる単語へ置き換える。※個人的にはローマ字も避けたい。

「良い設計」や「美しい実装」を手に入れるためにはこれだけではありませんが、これらのような内容を実直に行うことが必要です。

肝に銘じます。

まとめ

新入社員からふときかれたので改めてソフトウェア保守性について考えてみましたが、やはり奥が深いです。

私自身も日々成長する意識でソフトウェア品質の一つである「保守性」を心がけていきます。

長文を読んでいただきありがとうございました。

SSコラムでは現役エンジニアが記事を投稿しております。

もしよろしければ、セカンドセレクションの事業内容をご確認ください。

https://www.secondselection.com/