エンタープライズ

現役コンサルタントが語る

システム開発の落とし穴

2006年3月15日　　文●システムクリエイト代表取締役
田中徹

第4回
自社開発という選択肢（2/2）

スケジュールの作成と管理

　スケジュールはあなたとブレーンとなるSEで相談して線引きをしていくことになるが、重要なのは、いくつかのタイミングで明確に進捗が分かる尺度を持つということである。外部設計が終わった段階でレビューできる資料を作成するとか、プログラム設計が終わった段階でシミュレーションを行なうなどということがはっきりしていれば、作成するドキュメントに漏れがないことを確認できるし、すべきことが明確になる。

　またシステムの規模やシステムの性格にもよるが、たとえば社内システムで、いくつかの部署が使うことになるシステムなら、プログラムを本格的に作成する前にプロトタイプ版を作りたい。社内向けにデモを行なうことも必要であり、その分を事前にスケジュールに組み込みたい。実際の画面を目にして、初めて有効な意見が出されるという例も多いからだ。本番開始のスケジュールを考えるとプロトタイプ版を作成するということは遠回りな気がするかもしれないが、本番を迎えてから修正したり、不満を持ちながら稼動することを考えれば、決して無駄な作業ではない。

　開発作業における遅れというものは、避けては通れないものである。「綿密なスケジュールを立てたのだから、そのとおりに進捗して当たり前」という意識ではなく、「開発は遅れて当たり前。いかにその影響を最小限に食い止めるか」という考えをベースに進めた方が、トラブルがあってもその影響を最小限に食い止められるだろう。

　また、プログラム製造や設計の遅れには必ず何らかの原因がある。そして突然遅れが生じるわけではなく、その前兆が必ずある。大切なのは、遅れたときに報告がくるのではなく、遅れそうなときにその連絡がいかに早くあなたに届くかという体質を確立することだ。

　スケジュールの遅れの原因は、技術者個人のスキル不足、プログラム言語やデータベースなどツールの限界、または開発環境による制限など、理由はさまざまである。こうした理由が正確に報告されるようなプロジェクトチームであれば失敗も少ない。

　しかしながら、遅れを技術者個人に当てはめてみると、理由はともかく遅れているという事実について、それを進んで上に報告する気持ちはなかなか持ちにくい。つまり、プロジェクトの中でマイナス面をきちんと報告できる雰囲気作りが必要である。

技術者の管理

　プログラマなどからの技術的な質問には、ブレーンとなるSEが答える立場にある。あなたの行なう技術者管理で重要になるのは、勤怠を含め、情報の取り扱いやドキュメントの統一化などである。

　特に情報の取り扱いには気を配らなければならない。扱う情報が社員個人によるものや、社内機密情報などが含まれるなら、機密情報取扱に関する勉強会などを行ない、まずは社員、そして出入りする派遣社員にその意識を徹底させる。個人情報保護法の施行や新聞そのほかで情報漏洩が取りざたされている昨今、派遣で仕事をしている技術者にもその意識はあるだろうし、さらに契約書などで確認はするとしても、自分が派遣されている会社の意識が高ければ高いほど間違いが起きにくい。

テストと社内レビュー

　プログラム単体でのテストは、製造時にテストデータを作成して実施することになる。これが問題なければ次のステップである本番直前の結合テスト（＝システムテスト）に移るわけだが、早く本番を迎えたいという気持ちや、スケジュールの都合などで簡単に済ましてしまう傾向がある。

　結合テストはもっとも時間を割くべきであり、できるだけ本番に近い環境を整えて実施するのが望ましい。使用するデータも可能な限り本番と同じものをそろえる。

　こうして条件を整えた上で、複数ユーザーからの同時アクセスや繰り返し処理の対応など、徹底してテストしていく。テストすべき項目は膨大になるため、設計の前段階で作成した要件定義書と照らし合わせながらテスト仕様書を作成し、システムに実装したすべての機能を検証する。

　また、社内システムであれば主要部門の担当者などにも協力してもらい、さまざまな角度からテストしたい。結合テスト段階で機能に対しての意見や、追加要望などが出てくるかもしれない。それについては柔軟な姿勢で応えるようにしたい。

　十分な結合テストを行ない、そこで特に問題点がなければいよいよ社内教育となる。あなたが経験豊富なら別だが、やはりブレーンであるSEの手を借りるほうがベターだ。こうした場ではさまざまな意見が寄せられるが、それに対して技術者としての視点から応えてもらったり、あるいは要望を受けられるかどうかを素早く判断できるなど、プロとしての知識がモノを言うことが多いからだ。

ドキュメントの確認

　開発も終わり、本番稼動になり安定してきたら、ドキュメントの最終的なチェックを行なう。各種設計書は最新内容を反映させているか、不足はないか。データベースは分かりやすくまとめられているか、機能単位もしくはメニュー単位のドキュメントは揃っているかなど、時間をかけてチェックするわけだ。

　その際の指針としては、たとえばサブメニューを追加するという前提で、現在のシステムを知るのに十分なドキュメントが揃っているか、あるいはシステムの一部を置き換えるときに、事前検証がドキュメントだけで実施できるかといったものが挙げられる。こうした視点で見れば、必要なドキュメントが網羅されているか、そして記述された情報に漏れがないかを確認しやすい。

　多くのプロジェクトに携わってきた経験から言えば、二次開発やメンテナンスのときにドキュメントの不足で困るのは、データを中心としたプログラムの繋がりだろう。

　システムに手を加えるとき、既存のプログラムを修正するだけで済む場合は比較的作業はラクだと言える。

　逆に気を遣うのは、プログラムを追加したり、データベースにあるデータを更新するなど、既存のシステムに影響を与えないことを考慮しなければならないケースだ。こういったとき、データベースに蓄積されているすべてのデータに対して、そのデータは何を目的として格納されているのか、さらにはそれぞれのデータを作成する、あるいは更新するプログラムの一覧などが必要になる。こういった点についてきちんと書かれている仕様書や設計書があれば、メンテナンスするSEも作業の見通しが立てやすく、結果的にコストも抑えられる。決してドキュメントをおろそかにしてはならないのだ。

作業ステップを明確にすることが成功への第1歩

　自らプロジェクトリーダーとなりシステム開発を行なう場合、経験や慣れが必要な面も多いが、何をしなければならないかという指針があれば、初めてでも失敗をすることは少ないだろう。また未経験であれば、ブレーンとしてSEやシステムコンサルタントを登用すればいいだけのことだ。技術的なサポートはもちろんのこと、プロジェクト管理や危機管理といったノウハウまで学べるいい機会にもなるだろう。