ObjectSquare

[レポート]




新人SI体験記(前編)

written by

株式会社 オージス総研
山内亨和

はじめに

はじめまして。僕は去年大学を卒業したばかりの、社会人一年目のエンジニアです。
今回、広場の記事を書かせていただくことになったわけですが、まだ一年目なので記事にできるような知識も技術も経験も持ち合わせていません。経験したことと言えば、現在まで約半年間、従事しているシステム開発によるものだけです。ですので、今回行っているエンジニア人生で初のシステム開発から感じたことを記事にします。


オブジェクト小僧の苦悩

〜2000年6月中旬

僕は学生の頃、『オブジェクト小僧』でした。つまり、オブジェクト指向以外の勉強はしていなかったわけです。大学ではオブジェクト指向の授業は1つしかありませんでしたので、ほとんど一人で勉強していました。授業中は後ろの席に座って寝ているか、オブジェクト指向の本を読んでいました。

大学時代、オブジェクト指向を勉強していて最もつらかったことは、オブジェクト指向を学ぶ環境が限定されていたことです。オブジェクト指向の知識は本やインターネットから得られます。しかし、知識だけをため込んでいるだけで、オブジェクト指向を実践する機会がないことに不満を感じて始めました。次第に、頭の中の知識が飽和してきて、オブジェクト指向というものが分からなくなってしまったのです。

この状況を打破するために、オブジェクト指向の実践的な知識を得られる環境を求め、オージス総研へ入社しました。

念願がかない、現在の部に配属され、オブジェクト指向技術を採用したシステム開発に携わることになりました。しかしそこは大人の世界、甘くない。理想だけでシステムを作れないと思い知ることになったのです。


要求が決まっていない!

2000年6月下旬〜8月上旬

僕がチームに配属されたときはちょうどそのチームでプロジェクトが立ち上がる時でした。当初プロジェクトの内容を聞いていた限りでは、お客様が要件分析、及び基本設計まで終えているので、弊社のエンジニアは詳細設計から作業に入るという話でした。

しかしお客様との初顔合わせの際、お客様の話を聞いていて、本当に詳細設計から作業を始められるのだろうかと、疑問を抱き始めました。というのも、お客様からいただいた設計の資料がDFDで記述されていたのです。今回のプロジェクトではオブジェクト指向データベース(以降、ODB)を使うと聞いていました。DOAによって行われた設計から、ODBを利用することを前提にした詳細設計をできるのだろうか、ODBの利点を引き出せるのだろうかという疑問があったわけです。

その後、DFDを読んだり、要求についてヒアリングしているうちに、ペンディングになっている要求が多くあることがわかってきました。

ただ、これはお客様の事情を考えると当然のことかもしれません。今回開発するシステムはお客様にとっても初めての業務にあたる部分のシステムでした。そのため、「こんなことをやりたい」といったレベルの要求は提示できても、業務の詳細まで煮詰めきれないのかもしれません。

結局、頂いた設計資料をもとにユースケースを起こすことになりました。


分析モデル定義

2000年7月下旬〜2000年8月上旬

ユースケースの作成と並行して、分析モデルの作成を行いました。これが僕にとって初めて行ったシステム開発の仕事となったわけです。

この時はユースケースを書いている真っ最中であったため、DFDの設計書の記述を元にクラスを切り出しました。この作業には僕も含めて3人で行いました。僕はモデリングは学生のころから好きであったこともあり、この仕事ではほとんど苦労することはありませんでした。

といいながらも、作業中に一つ、難しいと感じていたことがあります。どこまでモデルを抽象化させるかということです。モデルを書き続ければ、どんどん複雑なものを定義できて、(個人的には)美しい抽象化されたモデルが作れるわけです。しかし、そのモデルは他の人から見ると、何を表現しているのかわからないものになっています。モデルを作成する目的に「プロジェクトに参加している人間内(お客様も含めて)での知識の共有」があると考えれば、自分以外の人間に理解できないレベルまで抽象化してしまったモデルは、そのプロジェクトに適していないモデルである言えるわけです。実際、何度もこういったモデルを書いていました。

それともう一つ、今になって、分析モデル作成のプロセスについて後悔していることがあります。それは分析モデル作成に直接関与していた人間がシステムを作る側の人間だけであったことです。今思えばシステムを使う側のお客様自身を巻き込んで分析モデルを作成するべきであったと考えています。

分析モデル(または概念モデル)を作成することで、私達は業務の概念の構造や責務を認識します。これをお客様の立場に置き換えると、業務のポリシーや思想を認識できるのではないかと考えています。今回のプロジェクトのような場合には、分析モデル作成プロセスにお客様を巻き込むことによって、お客様自身が業務の知識を整理する機会が得られ、それにより要求も早期確定でき、より安全にプロジェクトを進められたのではなかったのかなぁ、と遅まきながら考えています。


リスクを減らすためのプロトタイプ作成

2000年8月中旬〜下旬

今回行っているプロジェクトの中でリスクと呼べるものは3つありました。

  1. まずはお客様自身が要求を整理できていないこと。
  2. 今回のシステムがアプリケーションサーバ(J2EE)とODBで構成されるという、いまだ例のない(だろう)システム構成であること。
  3. チーム内にアプリケーションサーバやODBの知識を持つ人が少なかったこと。

これらのリスクを減らすために、1つのユースケース(とそれを実現するためのクラス群)のプロトタイプを作成することとなりました。プロトタイプを作成することで、それぞれのリスクに対して以下のような効果が上がりました。

1. 要求が不明確

2. システム構成

3. ヒューマンリソース

ちなみに、僕は分析モデルを作成していたこともあり、僕たちがEntity層と呼んでいる永続化クラスの設計、実装を行いました。僕はODBの使用経験がまったくなかったため、当初はODBのアーキテクチャに戸惑いながら開発を進めていました。ただ慣れてくるとDBに格納されていることをほとんど意識せずに永続化クラスを定義できるので開発スピードが上がっていきました。


1st Iteration開始!

2000年9月上旬〜10月下旬

プロトタイプ開発が終了し、結果が得られたところで最初のイテレーションを開始することになりました。

はじめに行ったことは、プロトタイプ開発時に作成した設計モデルを修正することでした。プロトタイプからのフィードバックでより良い設計モデルに変更する作業や新たに定義されたユースケースを満たす設計モデルに変更しなければなりませんでした。

設計が終了し実装が始まると、複数人数で開発することの難しさに直面しました。その問題とは開発者間でクラスのインターフェースを共有しなければならないことに起因しています。

1. クラスのインターフェースの変更が困難

メソッドの引数が足りなくてメソッドの定義を変えたかったことがよくあったのですが、そう簡単には変更作業を開始できませんでした。そのメソッドを使って実装している人がいるからです。そのため、変更対象のメソッドを利用している人を確認し、その変更をするとどの程度利用者の作業が遅れるのか、手戻りが発生するのかを想定した上で、変更するタイミングを決定しなければなりませんでした。


2. 自分以外の開発者が利用するクラス、メソッドには適切な名前を付けなければならない

僕がつけたメソッド名がそのメソッドの意味を適切に表現していないために、開発者がメソッドの意味を勘違いして、不適切な使い方をしてしまうことがありました。このようなことがないように、ドキュメントにメソッドの定義を記述するだけではなく、メソッドに存在意義を示すような名前を与えてやる必要があるわけです。

学生の頃は、インターフェースの変更が、プロジェクトにどのくらい影響を与えるのか考えたこともなく、またそのようなことを書いた本に出会っていなかったので、この経験は今回のプロジェクトの中で得た知識の中でも重要なものの一つとなりました。

後編に続く…

© 2000 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP