【匠】公開ワークショップ
エンジニアリング価値を高めるためのオブジェクト指向開発のあり方
（過去プロジェクトを検証して最適解を探る）
| 日時： | 2009/9/15(火) 13:00～17:30 |
|---|---|
| 場所： | 大阪エヌデーエス大会議室 |
| 参加者： | 萩本順三氏（NDSフェロー ㈱匠BusinessPlace 代表取締役 要求開発アライアンス 理事） |
| 牛尾剛氏（㈱匠BusinessPlace チーフアーキテクト） | |
| 大阪エヌデーエス社員14名（楠本英俊、大原大宣、吉田真由美、京極直丈、佐藤渉、坂元一樹、 | |
| 井手上美季、中尾敏彦、繁田良平、中井政明、板金功、松本康寛、松本睦美、佐藤航） |
この日は、「エンジニアリング価値を高めるためのオブジェクト指向開発のあり方」のテーマのもと、エンタープライズ系の過去プロジェクトを対象とし、オブジェクト指向開発を使った最適解を探った。どうすればオブジェクト指向開発へうまく転換できるのか？現状のオブジェクト指向開発で改善できる部分はあるのか？をポイントに過去プロジェクトを振り返るのだ。
この記事ではこの会議のディスカッションの熱さや、真剣さ、そういったものを皆様にお伝えするため発言をそのまま記載するスタイルでまとめ、ワークショップ後に作成した各プロジェクトの問題点と改善のための対策を図解して見える化する形でまとめた。
Aプロジェクト
1つ目のプロジェクト（Aプロジェクト）を担当した吉田から概要を説明する。このプロジェクトはウォーターフォール開発であり、要件定義から開発そして移行と、典型的なビジネス系の開発である。もちろんオブジェクト指向開発ではない。しかし、開発工程を振り返ることで、もっとよいものを、もっといい形で作ることができたのではなかったのか？それをこの場で探っていく。
Aプロジェクトの概要
|
|
| 萩本F | 吉田さん、今振り返ってどうですか。 |
|---|---|
| 吉田 | 要求定義書にユーザの要件は個別に載っていますが、全体像が書けていなかったと思います。 |
| 萩本F | ビジネス系では、全体像が書けていないことが多いですね。ユーザから提示された要件定義書を、NDSがどう受け取ったかが大事です。それがAsIsなのか、ToBeなのか。この（要件定義の）段階で業務レベルでの最適解を決めることが重要なんです。 |
| 吉田 | お客さんが書いた業務フローがあったんですが、外部設計書にもうまく入れることができませんでした。 |
| 萩本F | もったいないですね。その業務フローをお客さんと一緒に確認しながら、シナリオを書いて、ここで業務を確定させるんです。この中から変更ポイントや、ITの活用ポイントが明確になるはずで、業務とITを含めたシステム全体像を覚悟させることが必要です。ここからシステム開発の納得感も生まれます。 |
| 楠本 | お客さんから今もその機能があるから必要だと言われると、開発初期の段階ではこちらも業務がよくわからないので、それは不要な機能だと断れないのが実状です。 |
| 萩本F |
「今あるものは必要だ」という理論は成立しません。本当に業務として必要不可欠なもの、今作るべき最低限のものを作るべきであるということ、これをキチンと最初にお客さんに理解してもらえるよう教育する必要があります。お客さん自身が不要だと決めるのがいいんです。 |
| まとめ |
ToBeの業務フローを書きながら、それに対応したシナリオを書いていく。そのシナリオを画面や帳票を使いながら業務を実現できているか検証していく。本来シナリオは業務を確定するときに書いておくべきであり、いわゆるオブジェクト指向開発でのユースケース記述は不要かもしれない、とまで萩本Fは言う。そこには、システムの全体像をより早い段階で、具体的にイメージできるレベルで描ききることが、ユーザを含めた我々の意思統一につながり、開発をスリムに効率的に進める根幹だという考え方がある。 今回のワークショップでオブジェクト指向開発への転換には業務フローを活かす必要があることがわかった（図A-1のToBe業務フロー"×"の箇所）。業務フローからシナリオや概念モデルを作成しシステム開発へつなげていく（図A-2のToBe業務フロー"○"の箇所）ことで、より上流からトレーサビリティを持ったシステム開発が可能となり、開発者も業務フローのどこをシステム化しているかが見える化されることで、よりユーザ視点を持ってシステム開発が可能となる。 また、フレームワークの構造が設計モデルに反映されていなかったためフレームワークがブラックボックス化し問題が発生した場合に発生箇所の切り分けや原因の追及に時間がかかったり、フレームワークの間違った使い方をする恐れがあった（図A-1の設計モデル"×"の箇所）。そのため、フレームワークの構造も意識して設計モデルを作成する必要があった（図A-2の設計モデル"○"の箇所）。 全体的にドキュメントに関しては指定されたものを作成している意識が強かったため、常に目的意識を持ち、誰が何のためにいつ必要とするドキュメントであるかを考えるきっかけともなった。そのためには不要なドキュメントを作らないのは当然だが、後工程まで考え必要のないものは無いかを考える必要があることもわかった。 |
| 図A-1.Aプロジェクトの現状と問題点 | 図A-2.オブジェクト指向開発へ移行するためのポイントと改善点 |
|
|
| ↑クリックで拡大 | ↑クリックで拡大 |
Bプロジェクト
| 2つ目のBプロジェクトは、オブジェクト指向開発であった。オブジェクト指向開発であったが、開発者にはオブジェクト指向を使った実感がなく、結果として余分な工数を要した。オブジェクト指向開発における、Bプロジェクトの最適解はどこにあったのかを探る。 |
|
Bプロジェクトの概要
|
| 中尾 | オブジェクト指向で開発したという実感がありません。反復開発もできていないし、まるでウォーターフォール開発のようでした。フレームワークをうまく適用できず、結果的にテスト工数がかかってしまいました。 |
|---|---|
| 萩本F | なぜでしょうか。 |
| 中尾 | フレームワークを理解していなかったと思います。機能実装だけに力を注いでしまったと思います。 |
| このプロジェクトは、ユースケース記述をRFPをした入札だったことがまず大きな特徴である。画面イメージもないので、このユースケース記述から苦労して画面を起こすことから作業が始まっていた。そのため、膨大な工数がかかったという。 | |
| 萩本F | オブジェクト指向の伝統的なやり方は、ユースケースドリブンだが、これが成功するのは欧米のように、ユーザ部門内に技術者がいる場合です。一方、匠メソッドや要求開発で目指すのは、「何をやりたいか」に着眼することです。入出力項目を明確にした画面イメージをシナリオと一緒に書く。すると無駄を省ける。画面を見れば一目瞭然なことはユースケース記述に書く必要はなくなります。 |
| 中井 | 早くからお客様に画面を見せると、細かなことにこだわって作業が進まないことが多いです。 |
| 萩本F | 画面に引きずられるのが怖いからって先送りにして、それで業務が確定できますか？後工程でひきつけられるともっと苦労しますよ。ここで抽象化すればするほど、問題が先送りになるだけです。あまりにも抽象化してしまうと、覚悟ができなくなります。そうでしょう？いったいどんなものなのかイメージもできないのに、これでOKだと誰が言えるでしょうか？結局見積もりもできないし、ブレやすい。Bプロジェクトではそのままのことが起こっています。 |
| 牛尾氏 | ユースケースは業務系の実プロジェクトでは、お勧めしていません。トレーニングをしないと書けないからです。アジャイルで開発していますが、それは簡単にモノができるからです。しかしこれも人数が増えるとうまくいきません。アジャイルは書き過ぎることを否定しています。必要なものだけを書く。私の基本姿勢はそれです。また、アジャイルプロジェクトの場合は、ストーリカードというカードを使うので、ユースケース記述は必要なかったんです。 （詳しくは牛尾氏コラム参照） |
| 萩本F | 過去の習慣やどこかの本に書いてあることが正しいと思ったらダメです。自分の頭で考える。大前提を取り払う。ここから自分なりの解が導き出せる。これが価値のあるエンジニアリングです。今のソフトウェアエンジニアリングはまだまだ叩きようがあります。完成されていないんです。 |
| まとめ |
Bプロジェクトでは、画面を作って入出力項目を確定させた後、分析モデルを作り、ここからER図に発展させた（図B-1参照）。このフェーズ（業務ToBeモデル）では、問題なくできていた。しかし、画面のないままのユースケース記述からスタートしたことが、後々、大きな問題となっている。（図B-1の"×"の箇所） そこで本来の姿としては、ToBe業務フロー作成時に画面イメージ（入出力のイメージ）を作成し、そのモックアップをユースケースとセットで作成する（図B-2の"○"の箇所）、そしてそこで業務の流れとＩＴ活用を確定させてから、分析モデルと設計モデルを作成するようにしなければならなかったと思う。 萩本Fは、ディスカッションの最後に、「そもそもユースケースとはビジネス視点でIT活用法を描いたもので、現在の日本における利用法はまちがっているんですよ。」と付け加えた。我々も学んだ技術をそのまま使うのではなく、なぜそれが必要とされているのか、オブジェクト指向の本当の価値とは何かということを、ユーザの視点でもう一度考えるきっかけとなった。 |
| 図B-1.Bプロジェクトの問題点 | 図B-2.問題点を改善するための対策 |
|
|
| ↑クリックで拡大 | ↑クリックで拡大 |
最後に、どうやって最初にお客様に納得してもらうか、という点で質問があった。
| 大原 | やはり実践していくしかないのでしょうか。 |
|
|---|---|---|
| 萩本F | 繰り返しやること、絵を描いてみせることも必要です。 | |
これまでの萩本Fの経験より開発に問題が起こるのは主に4つの原因が考えられるという。これを今のプロジェクトに当てはめ、問題点を絵にして見える化をし、対策を立てることが必要という。4つの原因は以下である。この点を踏まえ、ワークショップ後に今回の2つのプロジェクトについての問題点と対策を図解し、見える化した。（図A-1～図B-2参照）
|
||
今回のワークショップを振り返って参加メンバーからのコメントを頂いた。
| 楠本 | 今までのユースケース記述に疑いを持つことは無かったので、今回そこに改善点があることに気付き驚いた。教科書に書かれているような内容にも改善の余地がないか常に考え、納得いくエンジニアリングを今後も追及していきたい。 |
|---|---|
| 坂元 | 下流の開発工程においても、オブジェクト指向開発を活かせる場面がありそうなので意識していきたい。 |
| 中尾 | 少し考え方を変えることにより質の良いものが作れると分かった。当たり前だと思っていたことも、これで良いのか、もっと作業量を減らし、質の良いものが作れないかを考えて行きたいと思った。 |
| 繁田 | 今回のワークショップでオブジェクト指向開発は、どのような場面でも適用できることを知った。私は今後のプロジェクトでそのことを忘れずに業務に取り組んで行きたい。 |
| 吉田 | 業務フローの利用は今すぐできることではないが次のプロジェクトではその部分をしっかり意識して活かしたい。 |
| 佐藤(渉) | 価値あるエンジニアリングを目指すためには意識や視点を変える必要があると感じました。 |
| 京極 | 今回のワークショップに参加して、自分が携わったPJを客観的に見ることで、問題点や改善点を発見することが出来たので良かったです。 |
| 大原 | オブジェクト指向開発は常に進化しているのだと感じた。オブジェクト指向開発に関しては業務以外でも意識し、習得していきたい。 |
今回過去プロジェクトを振り返ることで、その時は気付かなかった問題、課題の発見とそれに対する改善点（特にユースケース記述にも改善点がある）がわかり、さらにオブジェクト指向開発へ移行するためのポイントも明らかになった。
今回気付いた内容が実際どのように活かされているかや、別のプロジェクトに対する過去の振り返り等、NDSの活動を今後もこの場を借りてレポートしていきたい。
|
～牛尾氏コラム～ 「ストーリカード」、「ユースケース記述」の違いについて |
|
「ストーリカード」、「ユースケース記述」に関しては、使える場所が違うツールだと思っています。 「ストーリカード」は、アジャイル開発（特にeXtremeProgramming）でよく使われる手法で、ユーザ様がわかる言葉で、要求を書いていきます。ですので全く厳密ではありませんし、そこから読み取れないことも多々あります。 開発者はそのストーリカードをもらったら、「計画ゲーム」というセッションで、ユーザとストーリカードを片手に「これはどういうこと？」とか話をして、その「行間」を埋めて使うツールです。ですので、コミュニケーションを多くできるアジャイル開発の現場では、簡単ですし、プロジェクトがちゃんと回り易いのでお勧めです。 つまり、お客様と近い場、もしくは同じ場にいないと使えないツールで、例えばオフショアで発注とか、ベンダーに一括発注とかしたいときは使えないと思います。 一方、「ユースケース記述」はより厳格に、システムの「振る舞い」つまり動作を記述することができますので、そういう「紙」に仕様をしっかりと記述して、紙だけで通じるようにしたい場合はストーリカードよりも向いています。ただしビジネス系だと「しっかり仕様を書く」場合は、普通の「画面仕様」とかの方がわかりやすいし、みんな慣れているので、書き方を工夫すれば、「画面仕様」の方が私は適切だと思っています。 |