トラブルシューティングの極意―達人に訊く問題解決のヒント

第9回 [ソフトウェア開発編][実例満載]現場での対応と改善の手段

この記事を読むのに必要な時間:およそ 3 分

ソフトウェアのテストこそ切り札か? ―製造工程で品質を作り込め!

難易度が高い保守フェーズの仕事

ソフトウェアの保守フェーズになると開発チームが縮退し,属人的な知識は霧散します。残った保守メンバーは担当したことのない個所のコードを修正し,やったことのない作業を実施することになります。開発時に十分なドキュメントが整備されコードが共有されていれば,迅速に障害対応できデグレードも防げるでしょう。しかし,現実にはスケジュールに追われ十分な知識伝搬ができていないケースがほとんどです。時間に追われて書かれたコードはバグを含んでいたり,修正が難しい形になっていることがままあります。保守チームは少ない人数で膨大なコードに立ち向かい手探りで修正しなければなりません。業務が止まるような障害ならなおさら余裕はありません。保守というのはある意味で新規開発よりも難易度が高く厳しい作業です。

カットオーバー後に目を覆いたくなるような障害が頻発し,保守メンバーが日々の対応に消耗していく地獄のような現場はいくつも存在します。このような事態にいたる要因はいくつもありますが,典型的なものをあげてみましょう。

仕様レス

何が正しい仕様かわからない。ユーザがバグと言っているけどプログラムのロジックをどう修正すべきかわからない。仕様はコードに表現されているという考えもありますが,コードには実装都合のロジックも入ります。ドキュメントが多すぎるのも考えものですが,保守のために必要な仕様書は整備されているべきです。

コードが汚くて複雑

forやifが深く深くネストした,長い長い巻物のようなメソッド,ローカル変数に何度も再代入を行う……そんなコードを平気で書けるプログラマ……を大量に雇って何十万行ものコードを納品する開発ベンダー。オブジェクト指向とか,ドメインモデルとか,いやこれからは関数型だとか……それ以前の構造化すらできない人たちが寄ってたかって作り上げたプロダクトコードからはもはや腐臭しかしません。

データモデルがいけてない

業務システムは,データのライフサイクルや整合性が命です。項目のまとまりや状態遷移を塾考してデータモデルを構築していないとソースコードの複雑化を招き,保守不能に陥ります。

CRUD情報もドキュメントとして整備しておきましょう。データがどの画面の処理で更新されているのか全然わからない……と思ったら,夜間バッチでしれっと更新されていた……こういうのは気づくのに時間がかかります。

実行時の情報が少ない

キー項目など常識的に考えて必要なログを出力していない,どこかで例外を握りつぶしているなど。障害調査上深刻な障壁となります。

アーキテクチャ違反

そもそもアーキテクチャがないっていうケースもままありますが……。アーキテクチャ,コーディング規約の遵守というのは,規模が大きくなるほど効いてきます。大量のコードの森を彷徨う保守メンバーにとってこれらは大切な地図なのです。業務ロジックがプレゼンテーション層に大量に書かれている,変数名が意味不明……そんなコードで動いているシステムはいくらでもあります。⁠動けばいいじゃん」という考えの人はプロダクトコードを書いてはいけません。

おわりに

ソフトウェア開発では,発生したバグをつぶすだけでなく再発防止が求められます。原因分析,作業手順見直し,ログの見直し,プログラム構造の見直し,インシデント管理ツール注3への登録などが必要となるでしょう。

トラブル発生後の対応はもちろん大切ですが,発生リスクをコントロールすることの方が効果大です。ソフトウェアの複雑性を軽減するためのモジュール化,モジュール間の依存関係の単純化,複雑な対象を分割して統治すること。これを日々の開発・保守で実践していくことでリスクが軽減され,迅速な対応が可能になります。

ソフトウェアの要件が高度化し開発スピードが求められる昨今,テストフェーズで品質を担保するという考え方から,製造工程で品質を作り込むというマインドに切り替えるべきなのです。

本稿はケースの羅列になった感がありますが,これからソフトウェア開発・保守をしていくみなさんにとって少しでも参考になれば幸いです。

注3)
ユーザがソフトウェア使えない状態を早期解決するための運用管理を支援するツール。
Software Design

本誌最新号をチェック!
Software Design 2021年10月号

2021年9月18日発売
B5判/184ページ
定価1,342円
(本体1,220円+税10%)

  • 第1特集
    [MySQL/PostgreSQL/Oracle DB対応]
    データモデリングチェックリスト48
    現場で使える設計のコツ,データの効率化手法
  • 第2特集
    挫折しないOAuth/OpenID Connect入門
    APIを守る認証・認可フローのしくみ
  • 短期連載
    PHPカンファレンス2021通信
    [2]PHP 8で動く!? 非同期処理HTTPサーバ Laravel Octaneを使ってみよう!
  • 短期連載
    GitOpsで作るKubernetesのCI/CD環境
    [最終回]より実践的なGitOpsのために

著者プロフィール

近藤正裕(こんどうまさひろ)

1968年生まれ,京都府出身。株式会社豆蔵所属:シニアコンサルタント。

個人認証システム,P2Pシステムなどの研究開発を経て,データウェアハウス・OLAP・データマイニングなどの情報系システムを手がける。現在は,システム開発の現場で,開発標準化やアーキテクチャー構築を支援する日々。現場でもTrac/Subversionを愛用。データ可視化やデータマイニング/テキストマイニングの分野をもっと仕事でやっていきたいと考えている。

アイデアプロセッサiEditを開発し,フリーソフトウェアとして公開中

バックナンバー

トラブルシューティングの極意―達人に訊く問題解決のヒント

バックナンバー一覧