エンジニアは日々現場で学ぶ
開発現場で学べること
第3回　システム開発の真の目的を見失わない

クロノス 山野寛
2003/12/17

エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。

■目的意識を持つ

　とある雑誌の特集で「エンジニアとして伸びる人は『目的意識』のある人」という内容の記事を読んだことがある。上司や先輩から仕事を与えられた場合、「どうやってその仕事をやるのか」を考えるのではなく、「なぜその仕事をやるのか」を考える。つまり与えられた仕事の目的を意識することのできる人がエンジニアとして伸びる人であるということだ。

　システムを開発するうえで、そのシステムにかかわるすべての人に対して「開発の目的」が存在する。それは大きく分けて「クライアントからみた開発の目的」と「開発者からみた開発の目的」の2つに分類されるだろう。もしわれわれ開発者がこれらの目的を見失ってしまえば、クライアントの期待とはかけ離れた独り善がりのシステムが出来上がってしまうかもしれない。

　そこで今回は、私が目的意識を持つことの重要性を感じた2つのエピソードを紹介しよう。

■開発者からみた開発の目的とは

　現在、筆者がかかわっている開発は、「第1回 忙しいのはユーザーだ」で紹介したとおり、クライアント（A社）とそのグループ会社とのシステム統合が要件の1つとして含まれている。システムの統合を行うということは、当然それにかかわる現場の人々の業務自体にも影響する可能性が大いにある。

　先日、われわれはグループ会社のシステム担当者を招いて、A社システムとの相違を吸収し、無理なく統合を図ることを目的に、現状の業務のヒアリングとギャップ分析を行うことにした。以下はそのミーティングで、グループ会社のシステム担当者とプロジェクトマネージャ（PM）とのやりとりの一部である。

担当者　「現在、弊社のシステムでは○○業務のために、このような機能を実現しています」 PM　　　 「申し訳ありませんが、今回の新システムではそのような機能の要件をクライアントさまから伺っておりませんので、実現できません。ですので、○○業務のやり方をクライアントさまに合わせていただきたいのですが」 担当者　「現在行っている業務のやり方を変えるということですか」 PM　　　 「そういうことになりますね」 担当者　「変えるとなると現場が混乱すると思うので困ります」 PM　　　 「困るとは誰が困るのですか？ 御社のシステムが困るのですか？」 担当者　「いえ、現場の人間が困ります」 PM　　　 「現場の方々が困るのは仕方ないのではないかと思うのですが……」

　こんな具合のやりとりが行われた。私はこのPMの発言を聞いて正直驚いた。なぜならば、システムを使う現場の人間が困るようなシステムを作ることを、その担当者に向かって断言したかのように聞こえたからだ。もし新しいシステムを導入することによって現場が混乱するのであれば、業務を改善するという目的とはかけ離れたシステムになってしまうのではないかと思った。

　PMは私の感想を裏付けるようにこう続けた。

PM　「今回の開発では、A社とグループ会社とのシステム統合を行うことに関して、A社の業務を軸として各グループ会社がそのやり方に合わせるという方向性は決まっており、それはA社の経営陣が決定した企業方針です。予算も期間も決まっている中で、すべてのグループ会社の既存のやり方を保証しながら、さらなる機能追加をすることは現実的に不可能です。もしもこのシステムを導入することによって現場が困るのであれば、それはA社の企業方針に伴う影響であると考えています。新しいシステムに既存保証を望むのであれば、経営陣に要求を上げるのがよいのではないでしょうか」

　私はその発言を聞いて納得した。つまり、今回の開発には、A社の業務を軸として、各グループ会社の業務をマッチングさせていき、クライアントの業務にないグループ会社の業務部分は個別に考慮していくという「目的」が存在するのである。私はその目的を踏まえずに「現場が混乱して困る」のであれば、「混乱しないようなシステムにする必要があるのではないか」という意識が働いたのだが、つまり今回の開発では、

• A社とグループ会社とのシステム統合が必要
• A社の業務を軸とする
• 予算と期間は決められている
• 開発の決定はクライアントの経営方針である

という要件から、われわれが目指す「開発の目的」が導き出せるのである。PMがグループ会社の担当者の要求を受け入れなかったのは、担当者の要求がこの「開発の目的」から外れているということを認識したためのものであり、私はその本来の目的を見失っていたことになる。

　私のように経験のそれほど多くないエンジニアは、クライアントの要求をつい受け入れがちになることも少なくないだろう。が、もしもわれわれ開発者側の人間が本来の開発の目的を理解していなければ、クライアントの多くの要求に対応せざるを得なくなり、開発工数の増大は当然ながら、会社が本来望む姿のシステムが完成しない危険性もあることを強く認識した出来事であった。

■クライアントからみた開発の目的とは

　今回、われわれはアジャイルな開発を目指し、通常は外部設計フェイズで行うことの多いデータベースの論理設計を、要求定義フェイズで行うようなアプローチをとることにした。もちろん、データベース設計に関してもクライアントと多くのミーティングを重ね、要求定義での最終的な納品物として作成する必要がある。

　要求分析もいよいよ佳境に入り、われわれはクライアントと行ったヒアリングによってメンバー全員で約1カ月間かけて作成した分析クラス図を基に、データベースの論理設計を行ったときのことである。

　分析クラス図からデータベースのテーブルとなり得るエンティティを抽出し、それを表にまとめてクライアントとのミーティングを行った。すると、ある理由からクライアントから予想だにしなかった要求が発生したのである。それは、「既存システムと同じテーブル構造にしてほしい」というものだった。

　今回のプロジェクトではA社全体の基幹システムをオープン化するという狙いがあり、その開発はすべてオブジェクト指向言語であるJavaで行うことが決定している。私は担当者のその発言を聞いて、「データ中心アプローチで設計されたデータベース構造をオブジェクト指向のプログラムにマッピングすることは少々無理があるのではないか。分析クラス図から抽出されたエンティティを使用せずに既存のテーブル構造を用いて開発を進めると、オブジェクト指向の利点といわれる『拡張性』や『保守性』が失われるのではないか」と思い、コンサルタントのA氏と次のような会話を交わした。

私　　「せっかく分析クラス図を作ったのに残念ですね」 A氏　「全然残念ではないですよ」 私　　「どうしてですか？ オブジェクト指向で開発を進めた方が拡張性も保守性もあるしいいと思いませんか？」 A氏　「オブジェクト指向で開発をすると、本当に保守性や拡張性があるのでしょうか？ もしかしたら既存のテーブル構造で開発を行った方が、既存システムの保守を行っている現場の人たちからすると保守性も拡張性も高いかもしれませんよね？」

　つまりA氏は、クライアントが望んでいるシステムは、「オブジェクト指向で作られたシステム」ではなくて、「保守性や拡張性に優れたシステム」であるというのである。A氏のその発言から、私が考えた「開発の目的」は、「クライアントからみた開発の目的」ではなく、ただ単に「導入する技術のちょっとした利点」にすぎなかったということに気付いた。

　私が陥りがちな思考は経験の浅いSEによく見受けられるようだ。中でもアーキテクチャを専門とする技術寄りのSEは、システム開発の最新プロセスや最新の開発技術などを、適応する場面を選ばず、むやみに使いたがる傾向があるように思われる。われわれエンジニアは、「最新の技術を導入したシステム＝クライアントの望むシステム」ではないことを常に意識しておかなければならない。そして、クライアントの望むシステムとは何かを十分考慮したうえで、それに最適な技術を導入することを検討しなければならない。

■常に目的意識を持つことを心掛ける

　開発現場では、クライアントとの折衝が多い上流工程になるほど、この「目的意識」を持つことの重要性は高いといえる。しかし設計や製造のフェイズにおいても非常に重要なことに変わりはない。近年急速に普及してきた、J2EEパターンやデザインパターンといった「開発のパターン集」も、その効果と目的をしっかりと認識し、使用に適した個所であるかどうかを十分に検討したうえで導入することをお勧めする。エンジニアの自己満足で開発したシステムでは、クライアントは決して喜ばないのである。

　あなたは「目的意識」を持って開発を行っていますか？

筆者プロフィール

山野寛（やまのひろし）●クロノスに勤務するシステム・アーキテクト。立命館大学理工学部 卒業。クライアント／サーバからWeb系システムを中心にいくつかの開発現場に参加し、ここ数年はJ2EEをメインとしたオブジェクト指向開発にアーキテクトとして設計から携わっているという。