エンタープライズ

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

システム開発の落とし穴

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

第6回
SEを見極める（2/2）

ケース5：危機管理意識は強いか

　これは当たり前のようなお題目であるが、言いたいことはこういうことである。「トラブルが起きないように綿密な設計・開発を行なうSE」と「万が一のトラブルに備えて事前にその対応策を発注側と打ち合わせするSE」のどちらがよいのかということだ。結論から言えば、トラブルが起きないように細心の注意を払うのは当たり前で、トラブルが起きても慌てないようにSEは事前に対処方法について検討しておくべきである。

　たとえば発注担当との打ち合わせの席で、SEが「この機能で処理トラブルが起こったら、ログファイルにそのステータスが記録されます。まずはそれを元にトラブル対策を行ない、さらに原因を究明します」と言い出したら、最初のうちは「なるほど……」と感心するだろう。しかし、何度も聞かされると「トラブルが起きる前提ではなく、トラブルが起きないようにシステムを作ってくれ」と思うようになるかもしれないが、ここまで説明できるSEこそがデキるSEなのである。

　トラブルが起きないようにシステムを作る気持ちはどんなSEにでもある。「とりあえず作ってバグが出たら、その都度対応しよう」などと思っている技術者はいないハズである。綿密な設計を行ない、十分に検証し、注意深く開発したとしても、ミスは起きるものなのである。トラブル発生時の対策を説明できるSEは、長年の経験から迅速にトラブル対応する術として、役に立つ仕掛けを作っているということなのだ。

ケース6：広く浅くか、何かに特化しているべきか

　プロジェクトリーダーの役を担い始める頃のSEは、技術やこれまで開発してきたシステムの業種などについて、浅くても広い知識を持っているか、あるいは何かに特化しているかのどちらかに分かれるのではないだろうか。どちらが優れているという話ではないが、向き不向きはある。

　たとえば、現在稼働中のシステムに大幅な変更を加えず、環境などもそのままに新たな機能を追加するというような場面だ。この場合なら、自社のシステム環境（たとえば自社のシステムを開発した言語、あるいは利用しているデータベースなど）について精通しているSEの方が向いているだろう。ほかの開発環境と比べる必要もないし、そういう提案も望んでいない。

　逆にまったく新規にシステムを開発するようなケースであれば、たくさんの選択肢を提示でき、それぞれについてある程度の知識を持つ、浅くても広い知識を持つSEが望ましい。いくつもの提案をしてもらい、それぞれのメリット・デメリットを比較検討し、SEと相談しながら決めていくのがベストだと思われるからだ。SEにはそれに応えられるだけの幅広い知識が必要になる。

ケース7：データの取り扱いについて慎重か

　最近、ファイル交換ソフトによるデータ流出事件がたびたびニュースに登場している。SEとしてこういう問題を起こさないことは当たり前であり、開発会社によっては情報の取り扱いについてのガイドラインが定められていることもある。

　特にシステム開発において、総合的なテストを行なう場面では、できるだけ本番環境と同じデータを利用してテストを行なうことが望ましい。つまり開発の現場で重要なデータを取り扱うことになるわけだ。そのため、データの取り扱いには厳重な注意が求められ、SEから情報をどのように取り扱うのか、ガイドラインが示されて当然である。

　ただ、いくら完璧なガイドラインがあり、厳しい監視の目を光らせていても、開発チームの中に1人でも悪意を持って流出させようとする人物がいると、それを防ぐのは難しい。そのため、プロジェクト全体として、全員がデータを慎重に取り扱わなければならないという空気を醸成できるSEかどうかも重要である。

ケース8：記録に残す習慣が身についているか

　最後に簡単に解説したいのが、互いのコミュニケーションを記録しているかどうかだ。

　この手の「言った、言わない」という揉め事は多い。ちょっとした打ち合わせの席で大事な要望が出るかもしれないし、メールのやり取りの中に書かれているかも知れない。これを防ぐために、デキるSEは仕様書や用件定義書を必要に応じて適切に加筆しているか、追加で請け負った要求についてきちんとまとめている。こうしたSEなら、言った言わないのトラブルも少ない（もちろん、言ったことがないのに『言った』と言い張るような発注側の姿勢は論外である）ので安心できる。