シス開発：システム開発に役立つ様々な視点 |
システム開発の現場、開発に関する雑誌や書籍、ウェブページなどを見ると、「おいおい」と突っ込みたくなるような発言を目にする。それは、きちんとした開発方法を知らない人が、よく言ってしまいがちな内容を見たときだ。その代表例を紹介しよう。
発言内容を単に紹介するだけだと、取り上げる意味がないので、なぜダメなのかも簡単に説明した。これを読んで、この種の発言をしないように注意しよう。実力のある開発者から、能力が低いと思われないためにも。
特に注意すべきなのは、雑誌や単行本に書いてあるダメ記述。正式に出版された内容だからといって信用するのは、賢い判断ではない。まともな開発方法を知り、書いてある内容を自分で吟味するように心掛けよう。ハッキリ言ってしまうが、有益な情報のほうが少ないと思ったほうがよい。
時間がかかるのはテストであって、デバッグではない。このように発言するのは、きちんとしたテストをやったことがないからだろう。つまり、まともな開発の経験がないのを公表しているのに等しい。
まともな開発では、設計者とは別な人がテストを実施する。そこで発見されたバグは、再現性のある形で開発者に知らされる。再現する条件が分かっているので、デバッグは短い時間で終わるのが普通だ。再現性を確保できないバグもあるが、きちんとテストしていれば非常に少ないし、テスト側で用意したテスト・パターンのうち、もっとも発生しやすいパターンが、発生条件の絞り込みに役立つ。
再現が難しいバグの発生には、もう１つの原因が考えられる。エラー処理を中心とした設計段階での検討が不十分な場合だ。最悪の状況まで考慮して設計してあれば、再現しづらいバグの発生は少ない。設計の作業が低レベルだったり、レビューを実施していない開発で起こりやすい。これも自慢できる話ではない。
この種の発言は、テストの役割すら知らない人に多いので、相当にレベルが低いと思われても仕方がない。
既存のシステムに不具合が出たり、一部の機能を改良しなければならないケースで、変更箇所が１カ所で済むと分かったときの発言。「すぐに終わる」の部分が危険な認識だ。
どんなに小さな変更でも、プログラムや設定を変更するだけでは済まない。まず、その変更が適切なのか、別な人のレビューを受けて、確証を得る必要がある。ただし、これは簡単に終わるだろう。問題なのは、きちんとテストすることだ。単体テスト、結合テスト、運用テストなど、いくつかのテストが求められる。どんなに優秀な技術者でも、システム全体を見通せるわけではなく、テストによって間違いが発見されることが多い。変更が小さくても、テストせずに本番に組み込むのは無謀だ。実際、テストせずに本番モジュールを入れ替え、サービスが停止したり、大切なデータを失った事例を何度か見た。システム開発の基本を守ってさえいれば、失敗しなくて済んだのに。
システムが大規模なほどテスト作業も大変なので、何度も変更するのは得策ではない。いろいろな改善を集め、まとめて変更するのが普通だ。回数が減るほど作業の負荷も少なくて済み、その分だけ別な作業に時間を回せる。また、回数が少ないと十分なテストが可能で、トラブルの発生も減らせる。
非常にまれだが、発生したトラブルが重要で、緊急の入れ替えを要する場合もあるだろう。そんなときでも、最低限のテストは実施する。ただし、運用テストはやらずに、本番システムで直接入れ替える。そして開発者がその場に立ち会いながら本番データで処理を進め、バグが直っているかどうか、他の不具合が発生していないかどうか、データを壊してないかなどを調べる。もし問題が発生したら元の状態に戻し、トラブルの原因を調べて、再びテストを実施する。
システム変更やトラブル対処でのテスト作業を軽減するために、開発したシステムのテスト仕様書、テストツール、テストデータなどを残しておかなければならない。少しの変更でテストするときは、その変更に関するテスト・パターンを追加し、前のパターンと一緒にテストする。そうすれば、変更によって発生する新たなバグを発見しやすい。
どんなシステムであっても、ただ１カ所直すだけのときに「すぐに終わる」わけではない。まともな開発なら、修正方法のレビューと、最低限のテストを実施するのが当たり前だ。
レビューの役割や方法をまったく理解していない発言。力ずくの開発ばかりやっていて、きちんとした開発方法を知らない可能性が大きい。
設計の各段階や、テスト方法、運用方法など、レビューによって質が高まる分野は多い。どんなに優秀な設計者でも、一部を考慮し忘れたり見逃すことがある。それを防止するのがレビューなのだ。また、レビューへ参加した全員が、開発に関する幅広い能力を向上できる。
きちんとレビューするためには、設計内容をレビューしやすく整理する必要がある。レビュー用として別な資料を用意するのは無駄なので、レビュー可能な形で仕様書をまとめるのが効率的だ。また、設計しながら仕様書を書き進むのも大切。このように作った仕様書なら、設計者本人も設計内容を把握しやすくなり、設計の質も向上する。
以上のような点から考えて、レビューに反対する人は、システム設計能力が劣る可能性が高い。レビューによって能力が高められる機会を失っているので、本人の持つべき本来の能力よりも、低い能力しか身に付けていない。大いに損をしているわけだ。
レビューを受けたくない原因として、レビュー方法が悪いケースも、少しだけならあり得る。重箱の隅をつつくような指摘ばかりで、重要な部分に目を向けない状況だ。こんな場合であっても、レビュー方法を改善すべきであって、レビューをなくすのは最悪といえる。
レビューが無駄だという人には、どんな方法でレビューを実施するのかと、レビューを受ける際に用意すべき資料の種類と内容（形式も含む）を尋ねてみよう。おそらく、きちんとしたレビュー方法も知らないし、レビューに適した資料の作り方があるなんてことすら、考えたこともないだろう。そうした無知な人の発言なので、レビューの目的や方法を教えてあげるのが親切な対応だ。それで怒り出すようなら、相手にしないほうがよいし、開発メンバーに入れるのは避けよう。
（1999年８月12日）
システム開発に関するダメ発言集 |
